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

Zombie Ryushu zombie_ryushu at yahoo.com
Tue Jul 2 14:59:34 UTC 2019

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
> 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?

More information about the samba mailing list