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

[Rowland penny]

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.

Rowland