How to reproduce:
- make sure to configure a other primary group for a user
- 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
~ # wbinfo -i VMASHFORD\\tami
- 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
- however we get back the "Domain Users" group
~ # wbinfo --gid-info=1000513
I traced this issue back to this commit:
Author: Volker Lendecke <email@example.com>
Date: Mon Jan 2 15:56:48 2017 +0000
winbind: Remove "query_user" backend function
Signed-off-by: Volker Lendecke <firstname.lastname@example.org>
Reviewed-by: Uri Simchoni <email@example.com>
Reviewed-by: Andreas Schneider <firstname.lastname@example.org>
The rid backend was using the query_user() function in source3/winbindd/winbindd_ads.c to fill in the correct gid and GECOS.
Created attachment 14107 [details]
Attached is a potential fix.
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 :-(
I don't know that this is even the right approach. Volker, can you think of a better way to fix this?
(In reply to David Mulder from comment #0)
Is there a real-world scenario where this actually causes problems?
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?
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.
Take a look at: bce19a6efe11980933531f0349c8f5212419366a
This commit introduced that the primary group for a user is the Domain Users rid:
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.
(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)?
(In reply to David Mulder from comment #9)
Does "potential fix" attached to bugzilla resolves the problem, Have you tested it at your end?
(In reply to Amit Kumar from comment #10)
No, that patch does work temporarily, from my understanding, but it is not reliable.
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.
Here are some samba-technical discussions that happened about this issue:
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.
It looks if we download source and build https://www.samba.org/
Issue present: samba-4.9.15
Issue not present: samba-4.10.0