[Samba] Fwd: Need the ability to edit Samba SIDs.

[Zombie Ryushu]

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.