2

I'm having issues getting LDAP sudoers rules to work. My environment is:

  • Active Directory on Windows Server 2012 R2
  • Ubuntu 16.04.2
  • SSSD 1.13.4-1ubuntu1.5
  • sudo 1.8.20-3 (latest as of the posting, tried both LDAP and non-LDAP versions)

I followed these instructions to create a sudo_debug.log (sanitized):

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)
...

From this log, you can see that:

  • the sudoers rules are getting from AD to sudo (2 rules, the one displayed matching an AD entry)
  • the match fails on the linuxadmins group

However, the user is in the linuxadmins group (sanitized, but "user" matches):

$ getent group linuxadmins
linuxadmins@domain.com:*:1157001133:user@domain.com,otheruser@domain.com

The only odd thing about this log is that it sudo_get_grlist appears to return only the user's Primary Group domain users@domain.com. This would explain the lack of a match.

Has anyone seen this before? Any idea if the list of groups is resolved inside sudo (that I should continue to wait on my question to sudo-users) or somewhere else like SSSD (that I should find their list)?

1

Yeah, the lack of primary groups is probably the issue. The fact that getent group works is irrelevant, sudo uses the initgroups output which is more or less what you get when you call id.

And you're also right that sssd-users is the best one: https://lists.fedorahosted.org/admin/lists/sssd-users.lists.fedorahosted.org/

We even fixed our troubleshooting guide not so long ago at https://pagure.io/docs/SSSD/sssd/, the direct link is https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html

  • I actually contacted sudo-users but will also follow up on sssd-users if I get blocked there. The id command actually shows all of the right groups as well, but thanks for confirming the diagnostic step. – claytond Jul 3 '17 at 16:29
0

In CentOS 7, I was having the same issue of id only showing primary groups, e.g.:

id DOMAIN\\administrator

uid=485400500(administrator) gid=485400513(domain users) groups=485400513(domain users)

I was reading this reference (link) and editing my /etc/sssd/sssd.conf, and realized I was missing a few recommended configuration options. Before, I had only:

[domain/AD.DOMAIN]
id_provider = ad

so I added the other flags mentioned by the reference just underneath it:

auth_provider = ad
chpass_provider = ad
access_provider = ad

Unfortunately I don't know which one of them is responsible for the improvement, but if I had to guess it would be auth_provider = ad. Now id has this result:

id DOMAIN\\administrator

uid=485400500(administrator) gid=485400513(domain users) 
groups=485400513(domain users),485400518(schema admins),485400519(enterprise 
admins),485400512(domain admins),485403117(sudoers),485400520(group policy 
creator owners),485400572(denied rodc password replication 
group),485401624(esx admins),485401679(wseremotewebaccessusers), 
485401680(wseallowshareaccess),485401681(wseallowcomputeraccess),
485401682(wseallowmediaaccess),485401683(wseallowadd inaccess),485401684(wseallowdashboardaccess),
485401685(wseallowhomepagelinks),45401686(wsealertadministrators),
485401687(wseremoteaccessusers),485403103(ipamad mins)
  • My issue was not with id (which shows the right groups) but a deeper issue inside sudoers. In your case, auth_provider should default to the value of id_provider and chpass_provider should default to auth_provider (as stated in the relevant sections of the man page). access_provider, by contrast, should default to permit (same page). It's possible that you worked around a bug but, in general, id_provider should be sufficient. – claytond Apr 19 '18 at 14:31
  • Great, thank you for the info! Network authorization on Linux is still somewhat mysterious to me, it's taken me a long time to even get as far as I have. I'm going to leave it up just in case it helps someone else. – AveryFreeman Apr 21 '18 at 17:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.