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
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. 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. Is there anyway to fix this? I have a rather large eGroupware database hanging onthis.
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. >