[Samba] BUG : ldif "dn" prefixes case sensitivity (and primaryGroupID module)

Rowland Penny rowlandpenny at googlemail.com
Sun Oct 12 01:45:27 MDT 2014 

On 12/10/14 05:35, steve wrote:
> On 11/10/14 20:21, Rowland Penny wrote:
>> On 11/10/14 17:54, steve wrote:
>>> On 11/10/14 17:38, Rowland Penny wrote:
>>>> On 11/10/14 16:25, steve wrote:
>>>>> On 11/10/14 09:54, Prunk Dump wrote:
>>>>>> 2014-10-09 10:07 GMT+02:00 Rowland Penny
>>>>>> <rowlandpenny at googlemail.com>:
>>>>>>> On 09/10/14 06:45, Prunk Dump wrote:
>>>>>>>>
>>>>>>>> 2014-10-08 19:14 GMT+02:00 Rowland Penny
>>>>>>>> <rowlandpenny at googlemail.com>:
>>>>>>>>>
>>>>>>>>> On 08/10/14 16:45, Prunk Dump wrote:
>>>>>>>>>>
>>>>>>>>>> Hi samba team !
>>>>>>>>>>
>>>>>>>>>> I have found a very strange bug when changing my user's
>>>>>>>>>> primaryGroupID
>>>>>>>>>> with ldif files. The bug is very easy to reproduce :
>>>>>>>>>>
>>>>>>>>>> 1) Create a user, create a group, add the user to the group
>>>>>>>>>> -------------------------------
>>>>>>>>>> ~# samba-tool user add stduser
>>>>>>>>>> User 'stduser' created successfully
>>>>>>>>>>
>>>>>>>>>> ~# samba-tool group add stdgroup
>>>>>>>>>> Added group stdgroup
>>>>>>>>>>
>>>>>>>>>> ~# samba-tool group addmembers stdgroup stduser
>>>>>>>>>> Added members to group stdgroup
>>>>>>>>>> -------------------------------
>>>>>>>>>>
>>>>>>>>>> 2) Get the group sid, and change the user's primaryGroupID with
>>>>>>>>>> the dn
>>>>>>>>>> prefixes in lower case :
>>>>>>>>>> -------------------------------
>>>>>>>>>> ~# ldbsearch -H /usr/local/samba/private/sam.ldb 
>>>>>>>>>> '(cn=stduser)' cn
>>>>>>>>>> primaryGroupID memberOf
>>>>>>>>>> dn: CN=stduser,CN=Users,DC=my,DC=example,DC=com
>>>>>>>>>> cn: stduser
>>>>>>>>>> primaryGroupID: 513
>>>>>>>>>> memberOf: CN=stdgroup,CN=Users,DC=my,DC=example,DC=com
>>>>>>>>>>
>>>>>>>>>> ~# wbinfo --name-to-sid=stdgroup
>>>>>>>>>> S-1-5-21-1691533938-518786298-626738373-3385 SID_DOM_GROUP (2)
>>>>>>>>>>
>>>>>>>>>> ~# cat /tmp/chggrp.ldif
>>>>>>>>>> dn: cn=stduser,cn=Users,dc=my,dc=example,dc=com
>>>>>>>>>> changetype: modify
>>>>>>>>>> replace: primarygroupid
>>>>>>>>>> primarygroupid: 3385
>>>>>>>>>>
>>>>>>>>>> ~# ldbmodify --url=/usr/local/samba/private/sam.ldb
>>>>>>>>>> /tmp/chggrp.ldif
>>>>>>>>>> Modified 1 records successfully
>>>>>>>>>> -------------------------------
>>>>>>>>>>
>>>>>>>>>> 3) Now it's impossible to remove the user from the "Domain 
>>>>>>>>>> Users"
>>>>>>>>>> group ! And there are errors in the ldb base !
>>>>>>>>>> The group membership is one time written with lower case 
>>>>>>>>>> prefixes
>>>>>>>>>> and
>>>>>>>>>> one time with upper case prefixes :
>>>>>>>>>> -------------------------------
>>>>>>>>>> ~# samba-tool group removemembers "Domain Users" stduser
>>>>>>>>>> Removed members from group Domain Users
>>>>>>>>>>
>>>>>>>>>> ~# samba-tool group listmembers "Domain Users" | grep stduser
>>>>>>>>>> stduser
>>>>>>>>>>
>>>>>>>>>> ~# samba-tool dbcheck | grep stduser
>>>>>>>>>> ERROR: incorrect DN string component for member in object
>>>>>>>>>> CN=Domain
>>>>>>>>>> Users,CN=Users,DC=my,DC=example,DC=com -
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <GUID=a2af069a-8569-4019-9101-1872cccf4ae2>;cn=stduser,cn=Users,dc=my,dc=example,dc=com 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ERROR: orphaned backlink attribute 'memberOf' in
>>>>>>>>>> CN=stduser,CN=Users,DC=my,DC=example,DC=com for link member in
>>>>>>>>>> CN=Domain Users,CN=Users,DC=my,DC=example,DC=com
>>>>>>>>>> -------------------------------
>>>>>>>>>>
>>>>>>>>>> !! If the dn prefixes are written in upper case like below, 
>>>>>>>>>> there
>>>>>>>>>> are
>>>>>>>>>> no problems !!
>>>>>>>>>> -------------------------------
>>>>>>>>>> ~# cat /tmp/chggrp2.ldif
>>>>>>>>>> dn: CN=stduser,CN=Users,DC=my,DC=example,DC=com
>>>>>>>>>> changetype: modify
>>>>>>>>>> replace: primarygroupid
>>>>>>>>>> primarygroupid: 3385
>>>>>>>>>> -------------------------------
>>>>>>>>>>
>>>>>>>>>> The problem occur when the primaryGroupID is changed and when 
>>>>>>>>>> the
>>>>>>>>>> "memberOf" attribute need to be added. The case is not checked.
>>>>>>>>>>
>>>>>>>>>> Thanks !
>>>>>>>>>
>>>>>>>>> Hi, why are you trying to remove a user from Domain Users ? I
>>>>>>>>> take it
>>>>>>>>> that
>>>>>>>>> you don't want them to access the network etc. If you examine
>>>>>>>>> **any** AD
>>>>>>>>> user, you will not find a 'memberOf' attribute pointing to 
>>>>>>>>> 'Domain
>>>>>>>>> Users',
>>>>>>>>> also you do not add or remove the 'memberOf' attribute, AD does
>>>>>>>>> this for
>>>>>>>>> you
>>>>>>>>> when you add/remove a user to/from a group.
>>>>>>>>>
>>>>>>>>> You can change a users primarygroupid, but there is little point
>>>>>>>>> to this
>>>>>>>>> and
>>>>>>>>> it entails a lot of hassle, I would suggest doing what most 
>>>>>>>>> people
>>>>>>>>> do,
>>>>>>>>> create a group, add the user to this group and then use ACL's to
>>>>>>>>> restrict
>>>>>>>>> access to members of this group on any shares etc.
>>>>>>>>>
>>>>>>>>> Rowland
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> To unsubscribe from this list go to the following URL and read 
>>>>>>>>> the
>>>>>>>>> instructions: https://lists.samba.org/mailman/options/samba
>>>>>>>>
>>>>>>>>
>>>>>>>> Thank you for the help !
>>>>>>>>
>>>>>>>> I come from the Linux world and I'm not very experienced in the AD
>>>>>>>> practices. I did not know that changing the primary group in 
>>>>>>>> Windows
>>>>>>>> AD was so marginal.
>>>>>>>
>>>>>>>
>>>>>>> It is not recommended to remove a user from the domain Users group,
>>>>>>> but you
>>>>>>> can change the primarygroupid but most people don't bother, see 
>>>>>>> here
>>>>>>> for why
>>>>>>> (note it talks about removing the Domain Users group, but the
>>>>>>> reasoning is
>>>>>>> the same):
>>>>>>>
>>>>>>> http://social.technet.microsoft.com/Forums/windowsserver/en-US/69bbe556-b694-44dc-9a5e-2d53171073d0/are-there-any-issues-with-removing-the-domain-users-group-from-the-local-users-group-on-windows?forum=winserversecurity 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> You also seem to be falling into the trap of thinking that
>>>>>>> changing the
>>>>>>> primarygroupid will affect linux, it won't, your users primary unix
>>>>>>> group
>>>>>>> comes from the 'gidNumber' attribute.
>>>>>>>
>>>>>>>>
>>>>>>>> I use Samba4 mainly to manage Linux clients where the primary 
>>>>>>>> group
>>>>>>>> (gid) concept is fundamental. When I set the POSIX gid parameters
>>>>>>>> for
>>>>>>>> my users I thought that I need to change the windows 
>>>>>>>> primaryGroupID
>>>>>>>> for database consistency. But it seems that winbind does not need
>>>>>>>> this.
>>>>>>>>
>>>>>>>> The example above is just for demonstrate the bug. I don't want to
>>>>>>>> remove my user from the "Domain Users" group. I encounter the
>>>>>>>> problem
>>>>>>>> when I want to change the user's primary group from GroupA to
>>>>>>>> GroupB.
>>>>>>>> After that, as the database is corrupted, I can't remove the 
>>>>>>>> user of
>>>>>>>> GroupA.
>>>>>>>
>>>>>>>
>>>>>>> In my opinion (for what is worth), the bug is that you can actually
>>>>>>> remove a
>>>>>>> user from Domain Users with samba-tool.
>>>>>>>
>>>>>>>>
>>>>>>>> I will correct my scripts so that the primaryGroupID is not 
>>>>>>>> changed.
>>>>>>>> But the bug remain in samba4.
>>>>>>>>
>>>>>>>> Do you think that I need to do a bug report ? Or this situation
>>>>>>>> is too
>>>>>>>> marginal ?
>>>>>>>>
>>>>>>>> Thank again and excuse my English.
>>>>>>>
>>>>>>> Your English is pretty good, so don't worry.
>>>>>>>
>>>>>>> Rowland
>>>>>>>>
>>>>>>>> Baptiste.
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> To unsubscribe from this list go to the following URL and read the
>>>>>>> instructions: https://lists.samba.org/mailman/options/samba
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Sadly, after some experimentations, things are not as simple as they
>>>>>> seem ...
>>>>>>
>>>>>> 2014-10-09 10:07 GMT+02:00 Rowland Penny
>>>>>> <rowlandpenny at googlemail.com>:
>>>>>>> You also seem to be falling into the trap of thinking that
>>>>>>> changing the
>>>>>>> primarygroupid will affect linux, it won't, your users primary unix
>>>>>>> group
>>>>>>> comes from the 'gidNumber' attribute.
>>>>>>
>>>>>> On my linux clients a use winbind to make the pam ( authentication )
>>>>>> and nss (name <-> id mapping) job. And winbind always use the
>>>>>> primaryGroupID to set the unix gid (it take the primaryGroupID -> 
>>>>>> get
>>>>>> the corresponding group -> get the group gid). I can't find any 
>>>>>> option
>>>>>> to make winbind use the "gidNumber" attribute instead of
>>>>>> "primaryGroupID". So I have to change the primaryGroupID of my users
>>>>>> otherwise they have not the correct gid number.
>>>>>>
>>>>>> 2014-10-09 10:07 GMT+02:00 Rowland Penny
>>>>>> <rowlandpenny at googlemail.com>:
>>>>>>> In my opinion (for what is worth), the bug is that you can actually
>>>>>>> remove a
>>>>>>> user from Domain Users with samba-tool.
>>>>>>
>>>>>> I can now confirm that the bug come trom a bad case checking when
>>>>>> changing the primary group ID. ldbmodify accept dn with lower case
>>>>>> prefixes :
>>>>>>
>>>>>> dn: cn=stduser,cn=Users,dc=my,dc=example,dc=com
>>>>>>
>>>>>> or upper case prefixes :
>>>>>>
>>>>>> dn: CN=stduser,CN=Users,DC=my,DC=example,DC=com
>>>>>>
>>>>>> Bug if I change the primary group ID of a user using lower case
>>>>>> prefixes, it corrupt the ldb database. I have made a bug report :
>>>>>>
>>>>>> https://bugzilla.samba.org/show_bug.cgi?id=10863
>>>>>>
>>>>>> Thank you very much for your help. Finally I will check the case of
>>>>>> all the ldif files generated by my scripts.
>>>>>>
>>>>>> Baptiste.
>>>>>>
>>>>>
>>>>> Hi
>>>>> Sorry to come in late. The sequence of events is important so that 
>>>>> the
>>>>> schema doesn't get confused:
>>>>> create new group
>>>>> assign gidNumber to new group
>>>>> create new user
>>>>> add new user to new group
>>>>> remove user from Domain\ Users
>>>>> change the new user's primaryGroupID to the RID of the new group
>>>>> add the user back to Domain\ Users
>>>>> HTH,
>>>>> Steve
>>>>>
>>>>>   * ShareThis <javascript:void(0)>
>>>>>
>>>>> b
>>>> Hi Steve, apart from not having to remove/add the user to/from Domain
>>>> Users, that is the order to do it.
>>>>
>>>> Rowland
>>>>
>>> Hi Rowland
>>> If we don't, we get 'Unwilling to perform', but we're using ldifs. And
>>> it's 4.1.7. I wonder if this is a timing issue? I mean, if we put some
>>> sleep() to the script before we do the ldbmodify(ies). Can't test ATM:)
>>> Cheers,
>>> Steve
>>>
>> Hi Steve, If I have a user that has the primarygroupid of '513' and use
>> my script, it gets changed to the RID of whatever group I choose. This
>> is provided that the group already has a gidNumber.
>>
>> This is how my script works:
>>
>> ldbchangePrimaryGroupID <username> <groupname>
>>
>> Checks if user exists in AD
>> Check if group exists in AD and also has a gidNumber
>> Get the groups RID
>> Checks the users primaryGroupID isn't already set to the groups RID
>> If user isn't already a member of group then add user to group via an
>> ldif and ldbmodify
>> Now change the users primarygroupid via an ldif and ldbmodify
>>
>> Have you noticed what else happens when you do this ?
>>
>> Rowland
>>
>
> No, not noticed. Do tell us:) But still no. Maybe it's a 4.1.7 quirk 
> but we have to remove the user from Domain\ Users first. Or, it's a 
> timing and recovery issue. I know when we were testing the betas and 
> rcs we had to sleep a lot before doing the next change on the dbs nd 
> even longer before it percolated through to nss.

Ah, but that is what changes ;-)

If you examine CN=Domain\ Users after you add a new user, the new user 
doesn't show as being a member, but when you change the primarygroupid 
it does, also the users membership of the new primarygroupid group is 
removed, all of this is done automatically.

>
> There's also a nasty spin-off for this in that the user's files have 
> to have their ownership, and so acls changed. I'm wondering what use 
> cases really make this worthwhile. We've implemented it because we've 
> been told we have to have it. I'm glad we've never had to go live with 
> it.
>
> Could the OP share his use case?

I personally cannot see what he is trying to achieve, I thought that the 
easiest way to allow/deny access was via ACLs.

Rowland
> Cheers,
>

More information about the samba mailing list