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. >
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) Virtually every RID except for a few does not match its Unix UID. with things like: UID 1074 with RID 3006 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.
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 3006This 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