[Samba] wbinfo -r reports strange gids on AD member

[Rowland penny]

On 21/01/2020 21:17, Christian via samba wrote:
> On 21.01.2020 21:57, Rowland penny via samba wrote:
>> On 21/01/2020 20:43, Christian via samba wrote:
>>> On 21.01.2020 21:23, Rowland penny via samba wrote:
>>>> On 21/01/2020 20:02, Christian via samba wrote:
>>>>> Hi Rowland and Louis,
>>>>>
>>>>>>> Dear list,
>>>>>>>
>>>>>>> on a unix domain member, I get
>>>>>>>
>>>>>>> root at member:~# wbinfo -r some_user
>>>>>>> 10513
>>>>>>> 10020
>>>>>>> 10018
>>>>>>> 10517
>>>>>>> 10206
>>>>>>> 10220
>>>>>>> 3001
>>>>>>>
>>>>>>> However, GID 3001 does not exist in our AD...
>>>>>> Well, no it wouldn't, it is being mapped with this:
>>>>>>
>>>>>> idmap config * : range = 3000 - 7999
>>>>>>
>>>>>> It is one of the Well Known Sids
>>>>>>
>>>>>>>      On the other hand, GID
>>>>>>> 10559 (corresponding to some_group) appears to be missing from the
>>>>>>> list.
>>>>>>> Also, getent group some_group reports some_user as member. On other
>>>>>>> domain members, no issue, just two of them. This is debian buster
>>>>>>> with
>>>>>>> Louis's 4.10.11 packages.
>>>>>> This could be just down to the users not having logged in.
>>>>>>> The winbindd related parts of smb.conf are:
>>>>>> Please don't post what you think is relevant, post the entire
>>>>>> smb.conf
>>>>>> ;-)
>>>>>>>             winbind expand groups = 2
>>>>>>>             security = ADS
>>>>>>>             winbind enum users = yes
>>>>>>>             winbind enum groups = yes
>>>>>>>             winbind use default domain = yes
>>>>>>>             winbind nss info = ad
>>>>>> The 'winbind nss info' isn't used any more and it doesn't have a
>>>>>> value
>>>>>> 'ad'.
>>>>> OK. Removed that.
>>>>>>>             winbind refresh tickets = yes
>>>>>>>             kerberos method = system keytab
>>>>>>>             idmap config * : backend = tdb
>>>>>>>             idmap config * : range = 3000 - 7999
>>>>>>>             idmap config XXX:backend = ad
>>>>>>>             idmap config XXX:schema_mode = rfc2307
>>>>>>>             idmap config XXX:range = 10000 - 999999
>>>>>>>             idmap config XXX:unix_nss_info = yes
>>>>>>>             idmap config XXX:unix_primary_group = yes
>>>>>>>             username map = /etc/samba/user.map
>>>>> wbinfo -G 3001
>>>>> S-1-5-32-545
>>>>>
>>>>> That is "users", confirming the theory. Why would it do that?
>>>> Because it is supposed to ;-)
>>>>
>>>> The '*' domain is meant for the Well Know Sids and anything outside
>>>> the main domain, so anything that cannot be mapped gets an ID in the
>>>> range set in smb.conf (in your case 3000 - 7999)
>>>>
>>>>>> What is in the 'user.map' ?
>>>>> !root = XXX\Administrator
>>>> Good.
>>>>> Entire smb.conf (except for share definitions):
>>>>>
>>>>> [global]
>>>>>            bind interfaces only = Yes
>>>>>            interfaces = lo eth0
>>>>>            realm = XXX.XXXX
>>>>>            workgroup = XXX
>>>>>            netbios aliases = printserv
>>>>>            hosts allow = XXX/24
>>>> Is the 'XXX' above the same 'XXX' as in the workgroup line ?
>>> Yep.
>> Lets say that the 'XXX' is 'SAMDOM', this is incorrect in the 'hosts
>> allow' line, it should be a hostname or an IP, try reading the
>> smb.conf manpage (man smb.conf)
>>>>>            wins server = XXX.XXX.XXX.XXX
>>>> Sorry, but you do not use wins with AD.
>>> OK. Will remove.
>>>>>            winbind expand groups = 2
>>>>>            security = ADS
>>>>>            winbind enum users = yes
>>>>>            winbind enum groups = yes
>>>> You only need the 'winbind enum' lines to get 'getent passwd' &
>>>> 'getent group' to display all users and groups, it also can slow
>>>> things down, I would remove them.
>>> OK. Will do.
>>>> Unless you are having problems with folders and files getting the
>>>> wrong ownership, I wouldn't worry about the supposedly strange gids.
>>> Hm. Maybe I gave a poor description of the problem. User some_user is a
>>> member of the group some_group (gid 10559) acoording to AD (ldapsearch
>>> and LAM and other domain members).
>>>
>>> groups some_user
>>>
>>> does not reflect that on this particular AD member. some_group is
>>> missing from the list. However, some_user does show up in
>>>
>>> getent group some_group. In the output of wbinfo -r some_user, I do not
>>> get the gid of some_group, but instead 3001. Other groups are fine.
>>>
>>> So the problem is that one of the user's groups is missing, and instead
>>> 3001 is showing up... Other members of the group have their membership
>>> displayed correctly by the groups and wbinfo -r commands. Thanks,
>>>
>>> Christian
>> You cannot rely on group membership unless the user has actually
>> authenticated to the computer. You could try changing 'winbind expand
>> groups' to 4. However, unless the user cannot access something that
>> belongs to the supposedly missing group (and the group membership is
>> the only way the user can connect), I wouldn't worry about this.
> Ah. Maybe this is the point? In sshd_config, I am giving acceess based
> on group membership. The problem popped up because the user was not able
> to log in, though he is a  member of the group that is allowed access...
> Thanks,
>
> Christian
>
>
>
This is different, this should work, but I am not the expert here, I 
think you need Louis, if I recall correctly, he does this in production.

So, over to you Louis ;-)

Rowland