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. The origin of the wrong SIDs is actually OpenLDAP. The same SIDs were migrated over. 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. 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. This is because they were wrong in OpenLDAP, and when the Classic Upgrade was run, that carried over. Now I need to find a way to correct all of them.
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. The origin of the wrong SIDs is actually OpenLDAP. The same SIDs were migrated over. 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. 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. This is because they were wrong in OpenLDAP, and when the Classic Upgrade was run, that carried over. Now I need to find a way to correct all of them.
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