Bug 13371 - idmap_rid: default group always set to "Domain Users" not evaluating PrimaryGroupID ldap attribute
idmap_rid: default group always set to "Domain Users" not evaluating PrimaryG...
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Winbind
4.8.0rc2
All All
: P5 normal
: ---
Assigned To: Samba QA Contact
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-04-06 20:29 UTC by David Mulder
Modified: 2019-07-18 15:40 UTC (History)
6 users (show)

See Also:


Attachments
potential fix (4.07 KB, patch)
2018-04-06 20:39 UTC, David Mulder
no flags Details
retrieve the primary group ID when using idmap_rid and there is no cached netlogon (15.38 KB, patch)
2019-02-07 15:28 UTC, David Mulder
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Mulder 2018-04-06 20:29:39 UTC
How to reproduce:

- make sure to configure a other primary group for a user
  in AD
- join windows domain
- create a mapping based on RID, like:

        idmap config * : backend = tdb
        idmap config * : range = 10000000000-19999999999
        idmap config VMASHFORD : backend = rid
        idmap config VMASHFORD  : range = 1000000-4000000

- remove all caches

net cache flush
 
- check in ldap the users assigned primary id

~# kinit -k S12SP3-WB\$@VMASHFORD.SUSE.DE
~# ldapsearch -H ldap://win2012 -b dc=vmashford,dc=suse,dc=de '(&(objectClass=person)(sAMAccountName=tami))' primaryGroupID | grep primaryGroupID
primaryGroupID: 1104

~ # wbinfo -i VMASHFORD\\tami
VMASHFORD\tami:*:1001103:1000513::/home/VMASHFORD/tami:/bin/bash

- as we have a low RID from 1000000 we need to add this to the uid/gid
  values -> primaryGroupID = 1104 + 100000 = 1001104
  so the right group should be

~ # wbinfo --gid-info=1001104
VMASHFORD\unix:x:1001104:

- however we get back the "Domain Users" group

~ # wbinfo --gid-info=1000513
VMASHFORD\domain users:x:1000513:
Comment 1 David Mulder 2018-04-06 20:32:11 UTC
I traced this issue back to this commit:

commit 241c81b2763392439043261cf179cd2c8793faed
Author: Volker Lendecke <vl@samba.org>
Date:   Mon Jan 2 15:56:48 2017 +0000

    winbind: Remove "query_user" backend function
    
    Signed-off-by: Volker Lendecke <vl@samba.org>
    Reviewed-by: Uri Simchoni <uri@samba.org>
    Reviewed-by: Andreas Schneider <asn@samba.org>

The rid backend was using the query_user() function in source3/winbindd/winbindd_ads.c to fill in the correct gid and GECOS.
Comment 2 David Mulder 2018-04-06 20:39:20 UTC
Created attachment 14107 [details]
potential fix

Attached is a potential fix.
Comment 3 Volker Lendecke 2018-04-09 06:12:15 UTC
I had hoped that we could at some point get rid of the ads_cached_connection function. Now we have to re-add a user of it again. This sucks :-(
Comment 4 David Mulder 2018-04-09 14:56:48 UTC
I don't know that this is even the right approach. Volker, can you think of a better way to fix this?
Comment 5 Ralph Böhme 2018-04-19 20:32:09 UTC
(In reply to David Mulder from comment #0)
Is there a real-world scenario where this actually causes problems?
Comment 6 Björn Jacke 2018-12-11 13:43:07 UTC
the primary group matters: First obvious case is when unix users create files they have the primary group as the owning group by default. Is the fetching of the primary group bringing a considerable overhead compared to the current case where we're not fetching it?
Comment 7 Andreas Schneider 2019-01-16 15:34:11 UTC
This is the idmap_rid plugin we hand in a rid and get a uid or gid. I don't see why it needs to find out the primary group at all.

This seems to be totally the wrong place. It might be that we have an invalid assumption somewhere else but the rid module is a dumb module.

However we should at least get the uid and gid for a user to correctly work on unix platforms and it looks like winbind needs to get us that information and store it somewhere.
Comment 8 Andreas Schneider 2019-01-16 15:40:35 UTC
Take a look at: bce19a6efe11980933531f0349c8f5212419366a

This commit introduced that the primary group for a user is the Domain Users rid:

sid_append_rid(&info->group_sid, DOMAIN_RID_USERS);

When the information is available, we will update it. However we might need to query the the default rid and cache it to fill it in if possible.
Comment 9 David Mulder 2019-01-23 17:33:46 UTC
(In reply to Andreas Schneider from comment #8)
We ended up forward porting this behavior for customers who need it (using a different set of patches then what is attached), with the understanding that this behavior is going away. Apparently there have been discussions with the samba team (I'm not sure who, I wasn't involved) and it was decided this would not be pushed into master, etc. Maybe this bug is a duplicate (with more discussion maybe)?
Comment 10 Amit Kumar 2019-02-07 06:36:59 UTC
(In reply to David Mulder from comment #9)
Does "potential fix" attached to bugzilla resolves the problem, Have you tested it at your end?
Comment 11 David Mulder 2019-02-07 15:08:04 UTC
(In reply to Amit Kumar from comment #10)
No, that patch does work temporarily, from my understanding, but it is not reliable.
Comment 12 David Mulder 2019-02-07 15:28:20 UTC
Created attachment 14836 [details]
retrieve the primary group ID when using idmap_rid and there is no cached netlogon

These are the patches that we're using.
Comment 13 David Mulder 2019-02-07 15:30:59 UTC
Here are some samba-technical discussions that happened about this issue:
https://lists.samba.org/archive/samba-technical/2016-November/116972.html
https://lists.samba.org/archive/samba-technical/2017-March/119066.html
Comment 14 Louis 2019-02-08 15:29:44 UTC
Hai, 

I've seen the same on the list wednesday.

I've tested this also and it also happends with backend = ad. 
I've tested this on 4.8.8 and 4.9.4 

Samba List subject: 
[Samba] unix_primary_group = yes don t work

I've never noticed it because Windows default is "Domain users"  as primary group.


Greetz, 

Louis