[Samba] Group, idmap, unix_primary_group ...

Rowland penny rpenny at samba.org
Wed Jan 29 17:44:16 UTC 2020

On 29/01/2020 16:54, Allen Chen wrote:
> On 1/27/20 5:55 AM, Rowland penny via samba wrote:
>> On 27/01/2020 10:25, Marco Gaiarin via samba wrote:
>>> Mandi! Rowland penny via samba
>>>    In chel di` si favelave...
>>>> NO, NO, NO
>>>> The AD part is correct, but as I said, there isn't really a Unix 
>>>> primary
>>>> group, all Unix users have their own user private group e.g. user 
>>>> 'fred'
>>>> would have a private group called 'fred'. This is not allowed in AD
>>> Aaaahhhh... now i've understood what you are saying... no, sorry, this
>>> is a misunderstaning... the use of 'private groups' is a 'convention'
>>> of (rather all, indeed) modern distribution, where the add user
>>> scripts (adduser, useradd) create a 'private group' for every users, i
>>> think to manage better 'user separation'.
>>> But these are NOT 'private groups', they are only groups created with
>>> the same name of the users.
>>> UNIX (or POSIX ;-) have the concept of 'primary group' (fourth field in
>>> /etc/passwd) and 'other groups' (fourth field in /etc/group).
>> No, that is the users private group
>> cat /etc/passwd | grep adminuser
>> adminuser:x:1000:1000:adminuser,,,:/home/adminuser:/bin/bash
>> cat /etc/group | grep '^adminuser'
>> adminuser:x:1000:
>> However, people call it the 'primary group'
>>>>> So the only 'corner case' we have to take into account if we set a
>>>>> POSIX primary group with gidNumber, and we forget to add it to 'other
>>>>> membership' (eg, as 'memberOf'): in this case we can lead to a
>>>>> situation where Windows/AD and POSIX membership diverge, because the
>>>>> group in 'gidNumber' is not know to windows.
>>>> I think that means; the gidNumber you give to a user must be the 
>>>> gidNumber
>>>> of group i.e. a group must have this gidNumber
>>> This indeed. But i mean that if i add as gidNumber group 12345, that is
>>> a windows group 'Some Group', and i forgot to add 'Some Group' to
>>> 'members', UNIX see 'Some Group' because is the primary group, but
>>> windows don't see it because is not in 'member'.
>>> As a 'good practice' i've ever had the UNIX primary group also listed
>>> as 'supplimental group', so this is not a trouble at all...
>> I just give groups a gidNumber and then make users members of these 
>> groups
>>>>> Clearly, final question, all this for member server; and for AD?
>>>> For a Unix domain member, yes and if 'AD' means 'Samba AD DC', then 
>>>> again
>>>> yes.
>>> No, i mean: normally i don't add any 'idmap config' stanzas in
>>> smb.conf of a DC, so in particular no 'unix_primary_group = yes'.
>>> So i suppose a DC simply ignore 'gidNumber'.
>> No, a DC looks to idmap.ldb for IDs unless the user has a uidNumber 
>> in their object, or a group has a gidNumber.
>> An example:
>> root at dc4:~# getent passwd rowland
>> SAMDOM\rowland:*:10000:10000::/home/SAMDOM/users/rowland:/bin/bash
>> There is a slight problem with this, on a DC a group can be a group 
>> and a user. This is because on Windows, a group can own things (try 
>> that on a Unix machine). It is done like this so groups can own 
>> things in Sysvol, one of these groups is Domain Admins, so this is 
>> why I suggest not giving this group a gidNumber as it will turn the 
>> Windows group, that can own things, into a Unix group that cannot.
>> Rowland
> Hi Rowland,
> On my samba 4.7 AD DC, I have gidNumber=512 for "Domain Admins", and 
> gidNumber=513 for "Domain Users":
> # /usr/local/samba/bin/ldbsearch -H /usr/local/samba/private/sam.ldb 
> sAMAccountName="Domain Admins" | grep -i gid
> gidNumber: 512
> # /usr/local/samba/bin/ldbsearch -H /usr/local/samba/private/sam.ldb 
> sAMAccountName="Domain Users" | grep -i gid
> gidNumber: 513
> Are there any issues with this on my DC server?
> Thanks - Allen
In my opinion, yes. Windows allows groups to 'own' things, something 
that Unix doesn't

Now, from my tests, Domain Admins 'owns' things in Sysvol and if you 
examine Domain Admins object in idmap.ldb:

dn: CN=S-1-5-21-1768301897-3342589593-1064908849-512
cn: S-1-5-21-1768301897-3342589593-1064908849-512
objectClass: sidMap
objectSid: S-1-5-21-1768301897-3342589593-1064908849-512
xidNumber: 3000010
distinguishedName: CN=S-1-5-21-1768301897-3342589593-1064908849-512

Compare this with Domain Users object:

dn: CN=S-1-5-21-1768301897-3342589593-1064908849-513
cn: S-1-5-21-1768301897-3342589593-1064908849-513
objectClass: sidMap
objectSid: S-1-5-21-1768301897-3342589593-1064908849-513
xidNumber: 100
distinguishedName: CN=S-1-5-21-1768301897-3342589593-1064908849-513

Domain Admins is 'type' ID_TYPE_BOTH, which means the group is both a 
group and a user

Domain Users is 'type' ID_TYPE_GID, which means it is a just a group.

However, if you have 'idmap_ldb:use rfc2307  = yes' set in the DC's 
smb.conf and give Domain Admins a gidNumber attribute, this will 
override the groups object in idmap.ldb and turn the group into just a 
group and a Unix group cannot 'own' any files or directories.

My way around all this: Create another group (I use a group called 'Unix 
Admins'), give this group a gidNumber and make this group a member of 
Domain Admins. Then, on Unix, use this group wherever you would normally 
use Domain Admins.

Wonderful thing, nested groups and inheritance ;-)


More information about the samba mailing list