On 02/07/2019 15:59, Zombie Ryushu wrote:> On 07/02/2019 10:49 AM, Rowland penny via samba wrote: >> On 02/07/2019 15:37, Zombie Ryushu via samba wrote: >>> On 07/02/2019 10:17 AM, Rowland penny via samba wrote: >>>> On 02/07/2019 14:40, Zombie Ryushu wrote: >>>>> On 07/02/2019 09:32 AM, Rowland penny via samba wrote: >>>>>> On 02/07/2019 13:52, Zombie Ryushu via samba wrote: >>>>>>> On 07/02/2019 06:10 AM, Rowland penny via samba wrote: >>>>>>> >>>>>>>> On 02/07/2019 10:31, Zombie Ryushu via samba wrote: >>>>>>>>> I have a Samba problem with eGroupware. Samba 4 is screwing >>>>>>>>> with my >>>>>>>>> >>>>>>>>> eGroupware UIDs causing Havoc. Samba 4 uses the last four >>>>>>>>> Digits of >>>>>>>>> the >>>>>>>>> SID rather than the UID Number. >>>>>>>> If you are running Samba as an AD DC, then Unix UID != RID (what >>>>>>>> you >>>>>>>> are referring to as the 'last four Digits') >>>>>>>> >>>>>>>> >>>>>>>>> ?? I need to know how to alter my user >>>>>>>>> entry SID so that the last four digits of the SID is congruent >>>>>>>>> with >>>>>>>>> the >>>>>>>>> UID Numbers of my users. >>>>>>>> Do not even think of doing this, it will break AD. >>>>>>>>> To fix this; I need the ability to edit the last digits of the >>>>>>>>> SID. >>>>>>>>> I've >>>>>>>>> tried shutting down the Samba server and using ldbmodify, but that >>>>>>>>> isn't >>>>>>>>> working. The SiD is in some sort of strange Hash. pdbedit and >>>>>>>>> samba-tool >>>>>>>>> gives me the error: ?? - samldb: objectSid must not be specified! >>>>>>>>> >>>>>>>>> I'm, quickly approaching the need to re-provision my entire >>>>>>>>> Domain, >>>>>>>>> because I Have already corrected this stuff in my older OpenLDAP >>>>>>>>> system. >>>>>>>>> I'd have to re-run Classic Upgrade. I'd rather not lose all my >>>>>>>>> progress. >>>>>>>>> Please help! >>>>>>>> Classicupgrade is probably the way to go. >>>>>>>> >>>>>>>> Sounds like you need to tell us just how you are running Samba >>>>>>>> at the >>>>>>>> moment. >>>>>>>> >>>>>>>> Rowland >>>>>>>> >>>>>>>> >>>>>>> I am running Samba 4 as an AD, on one system, but I have a legacy >>>>>>> OpenLDAP system that runs Samba in NT PDC mode that I am migrating >>>>>>> from. >>>>>>> There are two Domain Controllers, one migrated, one is not. >>>>>> You can only migrate from one NT4-style PDC (in fact you can only >>>>>> have >>>>>> one PDC in a domain, multiple BDC's are allowed), so unless you have >>>>>> two NT4-style domains, you can turn the PDC's off. If you do have two >>>>>> NT4-style domains, then you will need to classicupgrade to two AD >>>>>> domains. >>>>>>> The origin of the wrong SIDs is actually OpenLDAP. The same SIDs >>>>>>> were >>>>>>> migrated over. >>>>>> No, it sounds like they were the correct SID's >>>>>>> eGroupware is one of the few programs with an outright Samba 4 >>>>>>> (Active >>>>>>> Directory) Mode. >>>>>>> >>>>>>> In OpenLDAP mode, eGroupware will use uidNumber. in Samba 4 AD mode, >>>>>>> eGroupware will use the last digits of the SID to determine the >>>>>>> eGroupware ID. >>>>>> The last 4 digits of the SID are known as the RID, but seeing as >>>>>> egroupware is a Unix package, why didn't they use the 'uidNumber' & >>>>>> 'gidNumber' attributes, if you classicupgraded from an LDAP PDC, you >>>>>> will have these in AD >>>>>>> everything from E-mail ACLs for Thunderbird, to Calender Items and >>>>>>> Contacts use this as a Primary key in its database. >>>>>>> >>>>>>> So what has been happening, is that if, say the Unix UID is 501, >>>>>>> and the >>>>>>> Object SID ends in 998, eGroupware will assume the UID is 998. >>>>>> The SID shouldn't end in '998', all normal AD users, groups etc start >>>>>> at '1000', it is the Windows 'system' users & groups that start at >>>>>> 500, see here: >>>>>> >>>>>> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Rowland >>>>>> >>>>>> >>>>> The rationale is that not every Samba AD is RFC2307 Compliant. >>>> Whilst this is technically correct (you have to specify >>>> '--use-rfc2307' when provisioning), all the RFC2307 attributes are >>>> standard in the Samba AD schema. >>>>> And you >>>>> are right, All SIDs start at 1000 and go up, and most of my users >>>>> have a >>>>> UID of more than 1000 except for two. Never the less, I've tried >>>>> the SQL >>>>> method to fix this by selecting the Affected rows, and determine >>>>> that to >>>>> make a much bigger mess than I started out with. >>>> You cannot change a SID, it is what identifies an object (user, group >>>> etc) in AD, it usually looks like this: >>>> >>>> S-1-5-21-xxxxxxxxxx-yyyyyyyyy-zzzzzzzzzz-AAAA >>>> >>>> Everything but the 'AAAA' identifies the Domain, the 'AAAA' is what >>>> identifies the object to AD. >>>> >>>> What are the two numbers (RID's) you wish to change ? >>>> >>>> Rowland >>>> >>>> >>>>> Is there anyway to fix this? I have a rather large eGroupware database >>>>> hanging onthis. >>>>> >>> I have more than two RIDs that I need to change. I have two RIDs that >>> have a value of 502 and 998. (lower than 1000) >> '502' is the RID for 'KRBTGT', you do not need this user in >> egroupware, DO NOT CHANGE THIS OBJECT'S SID >> >> Haven't a clue who '998' is, unless it is something like 'vmail' >> >>> Virtually every RID except for a few does not match its Unix UID. with >>> things like: UID 1074 with RID 3006 >> This is very, very common, which is why I think using the RID to >> identify a user on Unix isn't a good idea. >>> eGroupware thinks the RID = UID. This is causing Database Havoc. I need >>> to be able to situate things so my UID and RID are the same. >> This is egroupware's problem and I think they need to fix it, I mean >> 'classicupgrading' an NT4-style domain is fairly common and likely to >> get more common. >> >> Rowland >> >> >> > This still doesn't totally answer my question, for the ones that are > 1000+ I need to be able to change their RID to match their UID. So how > do I do that for those users? >You cannot change an AD objects RID, the RID is set by the system and if you could change the RID, the object would become a different object. I personally think that you need to go back to egroupware and explain your problem to them, they need to fix this. They seem to be doing something that could be done better, by using PAM for instance. Rowland
On 07/02/2019 11:14 AM, Rowland penny via samba wrote:> On 02/07/2019 15:59, Zombie Ryushu wrote: >> On 07/02/2019 10:49 AM, Rowland penny via samba wrote: >>> On 02/07/2019 15:37, Zombie Ryushu via samba wrote: >>>> On 07/02/2019 10:17 AM, Rowland penny via samba wrote: >>>>> On 02/07/2019 14:40, Zombie Ryushu wrote: >>>>>> On 07/02/2019 09:32 AM, Rowland penny via samba wrote: >>>>>>> On 02/07/2019 13:52, Zombie Ryushu via samba wrote: >>>>>>>> On 07/02/2019 06:10 AM, Rowland penny via samba wrote: >>>>>>>> >>>>>>>>> On 02/07/2019 10:31, Zombie Ryushu via samba wrote: >>>>>>>>>> I have a Samba problem with eGroupware. Samba 4 is screwing >>>>>>>>>> with my >>>>>>>>>> >>>>>>>>>> eGroupware UIDs causing Havoc. Samba 4 uses the last four >>>>>>>>>> Digits of >>>>>>>>>> the >>>>>>>>>> SID rather than the UID Number. >>>>>>>>> If you are running Samba as an AD DC, then Unix UID != RID (what >>>>>>>>> you >>>>>>>>> are referring to as the 'last four Digits') >>>>>>>>> >>>>>>>>> >>>>>>>>>> ?? I need to know how to alter my user >>>>>>>>>> entry SID so that the last four digits of the SID is congruent >>>>>>>>>> with >>>>>>>>>> the >>>>>>>>>> UID Numbers of my users. >>>>>>>>> Do not even think of doing this, it will break AD. >>>>>>>>>> To fix this; I need the ability to edit the last digits of the >>>>>>>>>> SID. >>>>>>>>>> I've >>>>>>>>>> tried shutting down the Samba server and using ldbmodify, but >>>>>>>>>> that >>>>>>>>>> isn't >>>>>>>>>> working. The SiD is in some sort of strange Hash. pdbedit and >>>>>>>>>> samba-tool >>>>>>>>>> gives me the error: ?? - samldb: objectSid must not be >>>>>>>>>> specified! >>>>>>>>>> >>>>>>>>>> I'm, quickly approaching the need to re-provision my entire >>>>>>>>>> Domain, >>>>>>>>>> because I Have already corrected this stuff in my older OpenLDAP >>>>>>>>>> system. >>>>>>>>>> I'd have to re-run Classic Upgrade. I'd rather not lose all my >>>>>>>>>> progress. >>>>>>>>>> Please help! >>>>>>>>> Classicupgrade is probably the way to go. >>>>>>>>> >>>>>>>>> Sounds like you need to tell us just how you are running Samba >>>>>>>>> at the >>>>>>>>> moment. >>>>>>>>> >>>>>>>>> Rowland >>>>>>>>> >>>>>>>>> >>>>>>>> I am running Samba 4 as an AD, on one system, but I have a legacy >>>>>>>> OpenLDAP system that runs Samba in NT PDC mode that I am migrating >>>>>>>> from. >>>>>>>> There are two Domain Controllers, one migrated, one is not. >>>>>>> You can only migrate from one NT4-style PDC (in fact you can only >>>>>>> have >>>>>>> one PDC in a domain, multiple BDC's are allowed), so unless you >>>>>>> have >>>>>>> two NT4-style domains, you can turn the PDC's off. If you do >>>>>>> have two >>>>>>> NT4-style domains, then you will need to classicupgrade to two AD >>>>>>> domains. >>>>>>>> The origin of the wrong SIDs is actually OpenLDAP. The same SIDs >>>>>>>> were >>>>>>>> migrated over. >>>>>>> No, it sounds like they were the correct SID's >>>>>>>> eGroupware is one of the few programs with an outright Samba 4 >>>>>>>> (Active >>>>>>>> Directory) Mode. >>>>>>>> >>>>>>>> In OpenLDAP mode, eGroupware will use uidNumber. in Samba 4 AD >>>>>>>> mode, >>>>>>>> eGroupware will use the last digits of the SID to determine the >>>>>>>> eGroupware ID. >>>>>>> The last 4 digits of the SID are known as the RID, but seeing as >>>>>>> egroupware is a Unix package, why didn't they use the 'uidNumber' & >>>>>>> 'gidNumber' attributes, if you classicupgraded from an LDAP PDC, >>>>>>> you >>>>>>> will have these in AD >>>>>>>> everything from E-mail ACLs for Thunderbird, to Calender Items and >>>>>>>> Contacts use this as a Primary key in its database. >>>>>>>> >>>>>>>> So what has been happening, is that if, say the Unix UID is 501, >>>>>>>> and the >>>>>>>> Object SID ends in 998, eGroupware will assume the UID is 998. >>>>>>> The SID shouldn't end in '998', all normal AD users, groups etc >>>>>>> start >>>>>>> at '1000', it is the Windows 'system' users & groups that start at >>>>>>> 500, see here: >>>>>>> >>>>>>> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Rowland >>>>>>> >>>>>>> >>>>>> The rationale is that not every Samba AD is RFC2307 Compliant. >>>>> Whilst this is technically correct (you have to specify >>>>> '--use-rfc2307' when provisioning), all the RFC2307 attributes are >>>>> standard in the Samba AD schema. >>>>>> And you >>>>>> are right, All SIDs start at 1000 and go up, and most of my users >>>>>> have a >>>>>> UID of more than 1000 except for two. Never the less, I've tried >>>>>> the SQL >>>>>> method to fix this by selecting the Affected rows, and determine >>>>>> that to >>>>>> make a much bigger mess than I started out with. >>>>> You cannot change a SID, it is what identifies an object (user, group >>>>> etc) in AD, it usually looks like this: >>>>> >>>>> S-1-5-21-xxxxxxxxxx-yyyyyyyyy-zzzzzzzzzz-AAAA >>>>> >>>>> Everything but the 'AAAA' identifies the Domain, the 'AAAA' is what >>>>> identifies the object to AD. >>>>> >>>>> What are the two numbers (RID's) you wish to change ? >>>>> >>>>> Rowland >>>>> >>>>> >>>>>> Is there anyway to fix this? I have a rather large eGroupware >>>>>> database >>>>>> hanging onthis. >>>>>> >>>> I have more than two RIDs that I need to change. I have two RIDs that >>>> have a value of 502 and 998. (lower than 1000) >>> '502' is the RID for 'KRBTGT', you do not need this user in >>> egroupware, DO NOT CHANGE THIS OBJECT'S SID >>> >>> Haven't a clue who '998' is, unless it is something like 'vmail' >>> >>>> Virtually every RID except for a few does not match its Unix UID. with >>>> things like: UID 1074 with RID 3006 >>> This is very, very common, which is why I think using the RID to >>> identify a user on Unix isn't a good idea. >>>> eGroupware thinks the RID = UID. This is causing Database Havoc. I >>>> need >>>> to be able to situate things so my UID and RID are the same. >>> This is egroupware's problem and I think they need to fix it, I mean >>> 'classicupgrading' an NT4-style domain is fairly common and likely to >>> get more common. >>> >>> Rowland >>> >>> >>> >> This still doesn't totally answer my question, for the ones that are >> 1000+ I need to be able to change their RID to match their UID. So how >> do I do that for those users? >> > You cannot change an AD objects RID, the RID is set by the system and > if you could change the RID, the object would become a different object. > > I personally think that you need to go back to egroupware and explain > your problem to them, they need to fix this. They seem to be doing > something that could be done better, by using PAM for instance. > > Rowland > >You're right, I am going to report this to the eGroupware developers, but it could be weeks or months to get a patch to fix the problem, but for now, even if I have to use an unorthodox solution like exporting the users as an LDIF and then changing the RID, then re-importing them, thats still faster than the alternative. Please, actually answer my question to fix the RID, somehow, some way.
On 02/07/2019 16:20, Zombie Ryushu wrote:> On 07/02/2019 11:14 AM, Rowland penny via samba wrote: >> On 02/07/2019 15:59, Zombie Ryushu wrote: >>> On 07/02/2019 10:49 AM, Rowland penny via samba wrote: >>>> On 02/07/2019 15:37, Zombie Ryushu via samba wrote: >>>>> On 07/02/2019 10:17 AM, Rowland penny via samba wrote: >>>>>> On 02/07/2019 14:40, Zombie Ryushu wrote: >>>>>>> On 07/02/2019 09:32 AM, Rowland penny via samba wrote: >>>>>>>> On 02/07/2019 13:52, Zombie Ryushu via samba wrote: >>>>>>>>> On 07/02/2019 06:10 AM, Rowland penny via samba wrote: >>>>>>>>> >>>>>>>>>> On 02/07/2019 10:31, Zombie Ryushu via samba wrote: >>>>>>>>>>> I have a Samba problem with eGroupware. Samba 4 is screwing >>>>>>>>>>> with my >>>>>>>>>>> >>>>>>>>>>> eGroupware UIDs causing Havoc. Samba 4 uses the last four >>>>>>>>>>> Digits of >>>>>>>>>>> the >>>>>>>>>>> SID rather than the UID Number. >>>>>>>>>> If you are running Samba as an AD DC, then Unix UID != RID (what >>>>>>>>>> you >>>>>>>>>> are referring to as the 'last four Digits') >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> ?? I need to know how to alter my user >>>>>>>>>>> entry SID so that the last four digits of the SID is congruent >>>>>>>>>>> with >>>>>>>>>>> the >>>>>>>>>>> UID Numbers of my users. >>>>>>>>>> Do not even think of doing this, it will break AD. >>>>>>>>>>> To fix this; I need the ability to edit the last digits of the >>>>>>>>>>> SID. >>>>>>>>>>> I've >>>>>>>>>>> tried shutting down the Samba server and using ldbmodify, but >>>>>>>>>>> that >>>>>>>>>>> isn't >>>>>>>>>>> working. The SiD is in some sort of strange Hash. pdbedit and >>>>>>>>>>> samba-tool >>>>>>>>>>> gives me the error: ?? - samldb: objectSid must not be >>>>>>>>>>> specified! >>>>>>>>>>> >>>>>>>>>>> I'm, quickly approaching the need to re-provision my entire >>>>>>>>>>> Domain, >>>>>>>>>>> because I Have already corrected this stuff in my older OpenLDAP >>>>>>>>>>> system. >>>>>>>>>>> I'd have to re-run Classic Upgrade. I'd rather not lose all my >>>>>>>>>>> progress. >>>>>>>>>>> Please help! >>>>>>>>>> Classicupgrade is probably the way to go. >>>>>>>>>> >>>>>>>>>> Sounds like you need to tell us just how you are running Samba >>>>>>>>>> at the >>>>>>>>>> moment. >>>>>>>>>> >>>>>>>>>> Rowland >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I am running Samba 4 as an AD, on one system, but I have a legacy >>>>>>>>> OpenLDAP system that runs Samba in NT PDC mode that I am migrating >>>>>>>>> from. >>>>>>>>> There are two Domain Controllers, one migrated, one is not. >>>>>>>> You can only migrate from one NT4-style PDC (in fact you can only >>>>>>>> have >>>>>>>> one PDC in a domain, multiple BDC's are allowed), so unless you >>>>>>>> have >>>>>>>> two NT4-style domains, you can turn the PDC's off. If you do >>>>>>>> have two >>>>>>>> NT4-style domains, then you will need to classicupgrade to two AD >>>>>>>> domains. >>>>>>>>> The origin of the wrong SIDs is actually OpenLDAP. The same SIDs >>>>>>>>> were >>>>>>>>> migrated over. >>>>>>>> No, it sounds like they were the correct SID's >>>>>>>>> eGroupware is one of the few programs with an outright Samba 4 >>>>>>>>> (Active >>>>>>>>> Directory) Mode. >>>>>>>>> >>>>>>>>> In OpenLDAP mode, eGroupware will use uidNumber. in Samba 4 AD >>>>>>>>> mode, >>>>>>>>> eGroupware will use the last digits of the SID to determine the >>>>>>>>> eGroupware ID. >>>>>>>> The last 4 digits of the SID are known as the RID, but seeing as >>>>>>>> egroupware is a Unix package, why didn't they use the 'uidNumber' & >>>>>>>> 'gidNumber' attributes, if you classicupgraded from an LDAP PDC, >>>>>>>> you >>>>>>>> will have these in AD >>>>>>>>> everything from E-mail ACLs for Thunderbird, to Calender Items and >>>>>>>>> Contacts use this as a Primary key in its database. >>>>>>>>> >>>>>>>>> So what has been happening, is that if, say the Unix UID is 501, >>>>>>>>> and the >>>>>>>>> Object SID ends in 998, eGroupware will assume the UID is 998. >>>>>>>> The SID shouldn't end in '998', all normal AD users, groups etc >>>>>>>> start >>>>>>>> at '1000', it is the Windows 'system' users & groups that start at >>>>>>>> 500, see here: >>>>>>>> >>>>>>>> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Rowland >>>>>>>> >>>>>>>> >>>>>>> The rationale is that not every Samba AD is RFC2307 Compliant. >>>>>> Whilst this is technically correct (you have to specify >>>>>> '--use-rfc2307' when provisioning), all the RFC2307 attributes are >>>>>> standard in the Samba AD schema. >>>>>>> And you >>>>>>> are right, All SIDs start at 1000 and go up, and most of my users >>>>>>> have a >>>>>>> UID of more than 1000 except for two. Never the less, I've tried >>>>>>> the SQL >>>>>>> method to fix this by selecting the Affected rows, and determine >>>>>>> that to >>>>>>> make a much bigger mess than I started out with. >>>>>> You cannot change a SID, it is what identifies an object (user, group >>>>>> etc) in AD, it usually looks like this: >>>>>> >>>>>> S-1-5-21-xxxxxxxxxx-yyyyyyyyy-zzzzzzzzzz-AAAA >>>>>> >>>>>> Everything but the 'AAAA' identifies the Domain, the 'AAAA' is what >>>>>> identifies the object to AD. >>>>>> >>>>>> What are the two numbers (RID's) you wish to change ? >>>>>> >>>>>> Rowland >>>>>> >>>>>> >>>>>>> Is there anyway to fix this? I have a rather large eGroupware >>>>>>> database >>>>>>> hanging onthis. >>>>>>> >>>>> I have more than two RIDs that I need to change. I have two RIDs that >>>>> have a value of 502 and 998. (lower than 1000) >>>> '502' is the RID for 'KRBTGT', you do not need this user in >>>> egroupware, DO NOT CHANGE THIS OBJECT'S SID >>>> >>>> Haven't a clue who '998' is, unless it is something like 'vmail' >>>> >>>>> Virtually every RID except for a few does not match its Unix UID. with >>>>> things like: UID 1074 with RID 3006 >>>> This is very, very common, which is why I think using the RID to >>>> identify a user on Unix isn't a good idea. >>>>> eGroupware thinks the RID = UID. This is causing Database Havoc. I >>>>> need >>>>> to be able to situate things so my UID and RID are the same. >>>> This is egroupware's problem and I think they need to fix it, I mean >>>> 'classicupgrading' an NT4-style domain is fairly common and likely to >>>> get more common. >>>> >>>> Rowland >>>> >>>> >>>> >>> This still doesn't totally answer my question, for the ones that are >>> 1000+ I need to be able to change their RID to match their UID. So how >>> do I do that for those users? >>> >> You cannot change an AD objects RID, the RID is set by the system and >> if you could change the RID, the object would become a different object. >> >> I personally think that you need to go back to egroupware and explain >> your problem to them, they need to fix this. They seem to be doing >> something that could be done better, by using PAM for instance. >> >> Rowland >> >> > You're right, I am going to report this to the eGroupware developers, > but it could be weeks or months to get a patch to fix the problem, but > for now, even if I have to use an unorthodox solution like exporting the > users as an LDIF and then changing the RID, then re-importing them, > thats still faster than the alternative. Please, actually answer my > question to fix the RID, somehow, some way. >Perhaps if I typed louder ? YOU CANNOT CHANGE AN AD OBJECTS RID, YOU WILL BREAK YOUR AD You will probably not be able to import your changed ldif, the 'objectsid' attribute is set by the system. The only way that I think you could do this is to go back to your NT4-style PDC, change the user & group RID's to match the UID & GID's, then run the classicupgrade again. Even then I am unsure if this will work. Rowland