The user's supplementary domain groups aren't being converted to GIDs in SAMBA_3_0. The SIDs are saved in the nt_user_token, but they're never added to the Unix group list. These are needed for ACL checks and probably other things. Calling to add_supplementary_nt_login_groups at the end of make_server_info_info3 in auth_util.c seems to do the trick, but I'm not sure why it has been excluded in the past. Add this to the end of make_server_info_info3 in auth_util.c: add_supplementary_nt_login_groups(&(*server_info)->n_groups, &(*server_info)->groups, &token);
Ken, I'm unable to reproduce this from the latest CVS. A user who is a member of no extra groups is given the token: NT user token of user S-1-5-21-1606980848-1677128483-854245398-1149 contains 5 SIDs SID[ 0]: S-1-5-21-1606980848-1677128483-854245398-1149 SID[ 1]: S-1-5-21-1606980848-1677128483-854245398-513 SID[ 2]: S-1-1-0 SID[ 3]: S-1-5-2 SID[ 4]: S-1-5-11 UNIX token of user 10017 Primary group is 10000 and contains 2 supplementary groups Group[ 0]: 10000 Group[ 1]: 10000 If I add the user to a group and re-authenticate I get this token: NT user token of user S-1-5-21-1606980848-1677128483-854245398-1149 contains 6 SIDs SID[ 0]: S-1-5-21-1606980848-1677128483-854245398-1149 SID[ 1]: S-1-5-21-1606980848-1677128483-854245398-513 SID[ 2]: S-1-1-0 SID[ 3]: S-1-5-2 SID[ 4]: S-1-5-11 SID[ 5]: S-1-5-21-1606980848-1677128483-854245398-1127 UNIX token of user 10017 Primary group is 10000 and contains 3 supplementary groups Group[ 0]: 10000 Group[ 1]: 10000 Group[ 2]: 10010
cc me
Hmm. Here is what I got *before* I added my patch: [2003/07/28 14:54:48, 5] auth/auth_util.c:debug_unix_user_token(504) UNIX token of user 100003 Primary group is 202052 and contains 1 supplementary groups Group[ 0]: 202052 [2003/07/28 14:54:48, 10] auth/auth_util.c:debug_nt_user_token(490) NT user token of user S-1-5-21-2220038185-3617674260-943656220-500 contains 9 SIDs SID[ 0]: S-1-5-21-2220038185-3617674260-943656220-500 SID[ 1]: S-1-5-21-2220038185-3617674260-943656220-513 SID[ 2]: S-1-1-0 SID[ 3]: S-1-5-2 SID[ 4]: S-1-5-11 SID[ 5]: S-1-5-21-2220038185-3617674260-943656220-512 SID[ 6]: S-1-5-21-2220038185-3617674260-943656220-519 SID[ 7]: S-1-5-21-2220038185-3617674260-943656220-520 SID[ 8]: S-1-5-21-2220038185-3617674260-943656220-518 I'll have to get the latest cvs and remove my change before testing again.
I also noticed that the add_supplementary_nt_login_groups() isn't actually called from anywhere. Presumably it used to though.
When I removed my patch, it still don't get the user's groups. But I may have some other problem. Now I get: [2003/08/05 23:00:10, 5] auth/auth_util.c:debug_unix_user_token(505) UNIX token of user 100003 Primary group is 202052 and contains 1 supplementary groups Group[ 0]: 202052 [2003/08/05 23:00:10, 3] lib/util_seaccess.c:se_access_check(268) se_access_check: user sid is S-1-5-21-2220038185-3617674260-943656220-500 se_access_check: also S-1-5-21-2220038185-3617674260-943656220-513 se_access_check: also S-1-1-0 se_access_check: also S-1-5-2 se_access_check: also S-1-5-11 se_access_check: also S-1-5-21-2220038185-3617674260-943656220-512 se_access_check: also S-1-5-21-2220038185-3617674260-943656220-519 se_access_check: also S-1-5-21-2220038185-3617674260-943656220-520 se_access_check: also S-1-5-21-2220038185-3617674260-943656220-518 Note that it's se_access_check. There was no display of the NT user token at all. There are lots of paths that could cause that, so it'll take some digging.
Ken, Are you running in domain mode with winbindd? Tim, what was your setup like? I've got a hunch that this is the difference.
what platform are you running on? I noticed that initialise_groups() has had the winbind_initgroups() called removed and replaced with a simple initgroups(). Ahh...I'll bet it is a problem with libc running through getgrent and finding all the secondary groups groups on your platform. Does the domain server have RestrictAnonymous set? If we make initializse_groups() in the current code match what it did in 2.2 we should be ok, because winbind_getgroups() grabs the users group membership from the cached info3 struct returned by the net_sam_logon() reply.
I'm running on NetBSD, with winbindd in domain/ads mode. NetBSD doesn't support nsswitch. So I've had to hack libc directly to add support for getgrent, getpwent, etc. It's worked fine until recently, though, so you've probably spotted the change. OTOH, if this is a problem peculiar to me, I can take care of it locally. I wanted to make sure it wasn't a more generic problem, though.
I'm putting in place work around to make us more robust on systems where the secondary group lookups fail through glibc. Besides we have all this information stored in netsamlogon_cache.tdb after a user first logs onto the system. Much more effecient that getgrent(). Ken tested the patch and it works for his case.
For the record, my setup was winbindd in rpc domain on Linux.
originally reported against 3.0.0beta3. CLeaning out non-production release versions.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.