[Samba] Group, idmap, unix_primary_group ...

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
type: ID_TYPE_BOTH
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
type: ID_TYPE_GID
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 ;-)

Rowland