LDAP Sudoers w/ AD & SSSD (returns only primary group)
Solution 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
Solution 2
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)
Related videos on Youtube
Jan Vilimovsky
Updated on September 18, 2022Comments
-
Jan Vilimovsky over 1 year
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 Groupdomain [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)? -
Jan Vilimovsky almost 7 yearsI actually contacted
sudo-users
but will also follow up onsssd-users
if I get blocked there. Theid
command actually shows all of the right groups as well, but thanks for confirming the diagnostic step. -
AveryFreeman about 6 yearsGreat, 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.