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 [email protected]
...
Jun 19 14:53:28 sudo[60452] sudo_getgrgid: gid 1157000513 [] -> group domain [email protected] [] (cache hit)
...
Jun 19 14:53:28 sudo[60452] user_in_group: user [email protected] 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 [email protected] 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 ([email protected])
...

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
[email protected]:*:1157001133:[email protected],[email protected]

The only odd thing about this log is that it sudo_get_grlist appears to return only the user's Primary Group domain [email protected]. 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)?

claytond
  • 161
  • 1
  • 7

2 Answers2

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

U880D
  • 1,120
  • 10
  • 24
jhrozek
  • 301
  • 1
  • 1
  • 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 03 '17 at 16:29
1

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)
Rui F Ribeiro
  • 55,929
  • 26
  • 146
  • 227
AveryFreeman
  • 193
  • 2
  • 10
  • 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](https://www.systutorials.com/docs/linux/man/5-sssd.conf/)). `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