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

[Zombie Ryushu]

On 07/02/2019 11:30 AM, Rowland penny via samba wrote:
> On 02/07/2019 16:20, Zombie Ryushu wrote:
>> On 07/02/2019 11:14 AM, Rowland penny via samba wrote:
>>> On 02/07/2019 15:59, Zombie Ryushu wrote:
>>>> 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
>>>>> 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 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?
>>>>
>>> You cannot change an AD objects RID, the RID is set by the system and
>>> if you could change the RID, the object would become a different
>>> object.
>>>
>>> I personally think that you need to go back to egroupware and explain
>>> your problem to them, they need to fix this. They seem to be doing
>>> something that could be done better, by using PAM for instance.
>>>
>>> Rowland
>>>
>>>
>> You're right, I am going to report this to the eGroupware developers,
>> but it could be weeks or months to get a patch to fix the problem, but
>> for now, even if I have to use an unorthodox solution like exporting the
>> users as an LDIF and then changing the RID, then re-importing them,
>> thats still faster than the alternative. Please, actually answer my
>> question to fix the RID, somehow, some way.
>>
> Perhaps if I typed louder ?
>
> YOU CANNOT CHANGE AN AD OBJECTS RID, YOU WILL BREAK YOUR AD
>
> You will probably not be able to import your changed ldif, the
> 'objectsid' attribute is set by the system.
>
> The only way that I think you could do this is to go back to your
> NT4-style PDC, change the user & group RID's to match the UID & GID's,
> then run the classicupgrade again. Even then I am unsure if this will
> work.
>
> Rowland
>
>
>
I get the message. I'll look into alternate ways to fix this.