Bugzilla – Bug 790
Sudoers only finds Primary Group (AD, SSSD)
Last modified: 2017-07-05 11:23:38 MDT
Sudoers is not matching the `linuxadmins` group even though the user is a member. Based on the logging in sudo_debug.log (sanitized), it appears that sudo_get_grlist is only returning the Primary group (and not linuxadmins): Jun 19 14:53:28 sudo[60452] Received 2 rule(s) Jun 19 14:53:28 sudo[60452] -> sudo_sss_filter_result @ ./sssd.c:225 ... Jun 19 14:53:28 sudo[60452] sssd/ldap sudoHost 'ALL' ... MATCH! ... Jun 19 14:53:28 sudo[60452] val[0]=%linuxadmins ... Jun 19 14:53:28 sudo[60452] sudo_get_grlist: looking up group names for user@domain.com ... Jun 19 14:53:28 sudo[60452] sudo_getgrgid: gid 1157000513 [] -> group domain users@domain.com [] (cache hit) ... Jun 19 14:53:28 sudo[60452] user_in_group: user user@domain.com NOT in group linuxadmins Jun 19 14:53:28 sudo[60452] <- user_in_group @ ./pwutil.c:1031 := false Jun 19 14:53:28 sudo[60452] user user@domain.com matches group linuxadmins: false @ usergr_matches() ./match.c:969 Jun 19 14:53:28 sudo[60452] <- usergr_matches @ ./match.c:970 := false Jun 19 14:53:28 sudo[60452] sssd/ldap sudoUser '%linuxadmins' ... not (user@domain.com) ... Verification that the user is in linuxadmins (also sanitized, but "user" matches): $ getent group linuxadmins linuxadmins@domain.com:*:1157001133:user@domain.com,otheruser@domain.com I found a couple archived sudo-users items mentioning the primary group but, for example, changing the order in nsswitch didn't seem to make any difference for me. I also tried the mailing list but got no response/acknowledgement so my @gmail address may have gotten spamboxed. The environment is: - LDAP provider: Active Directory on Windows Server 2012 R2 - Ubuntu 16.04 - SSSD 1.13.4-1ubuntu1.5 - sudo 1.8.20-3 (latest, tried both LDAP and non-LDAP versions)
When sudo looks up a user's groups, it either uses the getgroups() system call or uses the getgrouplist() function. By default, sudo will use getgroups() as long as the number of groups is less than the max for NFS. In that case it uses getgrouplist(). You can control this via the group_source setting in sudo.conf. In your debug log is there a line like: groups=... That info is logged by plugin@info and should show you the list of the user's groups as sudo sees them. Also, is you run the "groups" command as that user, does it list linuxadmins as one of the groups?
I assume this is the group line to which you refer: Jul 2 22:45:34 sudo[43850] <- get_user_groups @ ./sudo.c:492 := groups=1157000512,1157000513,1157000519,1157000572,1157001118,1157001133,1157001137,1157001145,1157001146,1157001152,1157001153,1157001166 And "groups" does show the right group (domain sanitized): domain users@domain.com domain admins@domain.com enterprise admins@domain.com denied rodc password replication group@domain.com dnsadmins@domain.com linuxadmins@domain.com deployers@domain.com graylog@domain.com graylogadmins@domain.com testing@domain.com workflow@domain.com linuxusers@domain.com However, in the LDAP rules section, I'm still seeing getgrgid only run on one (primary) group: Jul 2 22:45:34 sudo[43850] sudo_get_grlist: looking up group names for user@domain.com ... Jul 2 22:45:34 sudo[43850] sudo_getgrgid: gid 1157000513 [] -> group domain users@domain.com [] (cache hit)
It looks like sudo is getting the correct group IDs so I don't know why you'd only see a single call to sudo_getgrgid(). Do you see any lines in the debug log like: sudo_get_grlist: user user@domain.com is a member of group ... It's hard to tell what is going on from small snippets of the debug log. You might try setting the match_group_by_gid option which changes how groups get matched. If the problem is ID -> name group resolution this may help.
Created attachment 495 [details] Full (Sanitized) Debug Log FWIW here's a full debug log. I tried to capture just `sudo -v` for the focal user. In some places, you can see the whole list enumerated (interesting as <group>@domain.com). Does the rule need to include the @domain.com section? In the `sudoers` file it does not so I assumed that this code would follow the same conventions.
The debug log shows that group ID 1157001133 resolves to group name linuxadmins@domain.com so I think you do need to include the @domain part in the rule. The lines tagged with "sudo_get_grlist:" show all the names of the groups tthat he user is a member of.
OK. I tried changing the entry in LDAP to `%linuxadmins@domain.com` but the rule doesn't even load: Jul 5 11:40:58 sudo[42228] Received 1 rule(s) ... Jul 5 11:40:58 sudo[42228] val[0]=%deployers This is the second (unchanged) rule. I couldn't find anything about escaping so I tried `\@` which didn't help. Do I need to follow up with the sssd folks to clarify escaping for this character? FWIW if this approach ultimately requires `@domain`, it will differ from the current `/etc/sudoers` behavior.