To check whether the basic configuration of sudo and SSSD is correct, check
/etc/nsswitch.confmust say that
sssmodule is used for sudo service. Look for line like
"sudoers: sss"(only SSSD is used),
"sudoers: files sss"(local rules first, then SSSD) or similar.
/etc/sssd/sssd.confmust say that
sudo responder is enabled. Look at [sssd] section and search for line
"services: nss, pam, sudo"or similar.
sudo provider is enabled. Look at [domain] section, sudo provider is always enabled for ldap, ad and ipa providers, unless this section contains “sudo_provider = none”.
Logs can provide many useful information when finding a solution for your troubles.
a) How do I get sudo logs?
/etc/sudo.confand put down the following lines: :
Debug sudo /var/log/sudo_debug all@debug Debug sudoers.so /var/log/sudo_debug all@debug
/var/log/sudo_debugcontains sudo logs
b) How do I get SSSD logs?
/etc/sssd/sssd.confand enable logging by setting a debug level in
debug_level = 0x3ff0
- Restart SSSD
- Run sudo
- Log files are stored in
/var/log/sssd/sssd_$NAME.log(domain log) and
/var/log/sssd/sssd_sudo.log(sudo responder log)
a) SSSD sudo responder – sssd_sudo.log:
Was a rule returned to sudo at all? :
[sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning $num-rules rules for [user-1@LDAP.PB]
What filter was used to fetch rules from cache? :
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=user-1)(sudoUser=#10001)(sudoUser=%group-1)(sudoUser=%user-1)(sudoUser=+*)))]
You can then use this filter to lookup in SSSD cache to see what rules were returned :
# when using yum yum install ldb-tools # when using dnf dnf install ldb-tools ldbsearch -H /var/lib/sss/db/cache_$domain.ldb -b cn=sysdb '$filter'
SSSD cache uses LDAP-like format equal to sudo format described in man sudoers.ldap
b) SSSD domain – sssd_$domain.log
How many rules were found? :
[sdap_sudo_refresh_load_done] (0x0400): Received $num-rules rules
What sudo rules were downloaded from server? :
[sssd[be[LDAP.PB]]] [sysdb_save_sudorule] (0x0400): Adding sudo rule $rule-name
Were all matching rules stored? :
[sdap_sudo_refresh_load_done] (0x0400): Sudoers is successfully stored in cache
What filter was used to fetch rules from server? :
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=client.sssd.pb)(sudoHost=client)(sudoHost=10.34.78.77)(sudoHost=10.34.78.0/24)(sudoHost=2620:52:0:224e:21a:4aff:fe23:1394)(sudoHost=2620:52:0:224e::/64)(sudoHost=fe80::21a:4aff:fe23:1394)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\2A*)(sudoHost=*[*]*))))][dc=ldap,dc=pb]
You can then use ldapsearch with this exact filter to see what rules were downloaded
ldapsearch -x -H ldap://ldap.example.com -b dc=ldap,dc=example,dc=com '$filter'
Simple bind :
ldapsearch -x -D "cn=Directory Manager" -w "$password" -H ldap://ldap.example.com -b dc=ldap,dc=example,dc=com '$filter'
ldapsearch -Y GSSAPI -H ldap://ldap.example.com -b dc=ldap,dc=example,dc=com '$filter'
c) sudo debug logs – sudo_debug
Information about user that is attempting to run sudo :
Mar 31 16:11:15 sudo settings: debug_flags=all@debug Mar 31 16:11:15 sudo settings: run_shell=true Mar 31 16:11:15 sudo settings: progname=sudo Mar 31 16:11:15 sudo settings: network_addrs=10.71.4.192/255.255.255.0 fe80::250:56ff:feb9:7d6/ffff:ffff:ffff:ffff:: Mar 31 16:11:15 sudo user_info: user=$username Mar 31 16:11:15 sudo user_info: pid=22259 Mar 31 16:11:15 sudo user_info: ppid=22172 Mar 31 16:11:15 sudo user_info: pgid=22259 Mar 31 16:11:15 sudo user_info: tcpgid=22259 Mar 31 16:11:15 sudo user_info: sid=22172 Mar 31 16:11:15 sudo user_info: uid=$uid Mar 31 16:11:15 sudo user_info: euid=0 Mar 31 16:11:15 sudo user_info: gid=554801393 Mar 31 16:11:15 sudo user_info: egid=554801393 Mar 31 16:11:15 sudo user_info: groups=498,6004,6005,7001,106501,554800513,554801107,554801108,554801393,554801503,554802131,554802244,554807670 Mar 31 16:11:15 sudo user_info: cwd=/ Mar 31 16:11:15 sudo user_info: tty=/dev/pts/1 Mar 31 16:11:15 sudo user_info: host=$hostname Mar 31 16:11:15 sudo user_info: lines=31 Mar 31 16:11:15 sudo user_info: cols=237
What data sources are used to fetch sudo rules :
Mar 31 16:11:15 sudo <- sudo_parseln @ ./fileops.c:178 := sudoers: files sss
SSSD plugin starts here :
Mar 31 16:11:15 sudo <- sudo_sss_open @ ./sssd.c:305 := 0
Here is sudo looking for cn=defaults :
Mar 31 16:11:15 sudo Looking for cn=defaults
SSSD is returning rules :
Mar 31 16:11:15 sudo Received 3 rule(s)
…and sudo is evaluating them by matching sudoHost, sudoUser, … attributes to current user
hostname is OK :
Mar 31 16:11:15 sudo sssd/ldap sudoHost 'ALL' ... MATCH!
if something does not match, you will see line ending := false; you need to guess the test from function name :
Mar 31 16:11:15 sudo <- user_in_group @ ./pwutil.c:1010 := false
a) Setting global options with cn=defaults when sudo rules are stored on an IPA server
To imitate global options, create a rule named
cn=defaults in LDAP tree or rule named
defaults in IPA and
set sudoOption attribute as you wish.
b) !authenticate does not work
A common problem is when you set
!authenticate option to a specific rule but
sudo -l command that lists all rules still requires authentication. If you want
sudo -l to be password-less you need to set
!authenticate also in
c) it takes too long to update rules
man sssd-sudo to see how sudo rules are cached in SSSD.
d) what is alternative to options in command definition in sudoers
In sudoers, you can define an allowed command together with many options, such as: :
%wheel ALL=(ALL) ROLE=unconfined_r TYPE=unconfined_t ALL john ALL=(ALL) NOPASSWD: ALL
These all have their equivalent as a sudo option that can be placed in
sudoOption attribute. Usually it is only lower cased value of this command option, with an exception of
NOPASSWD which is referenced as
SUDOERS OPTIONS section of
sudoers.5 manual page for more information.
Problems with IPA-AD trust when fully qualified names are required for IPA
Fixed in 1.14.0: https://github.com/SSSD/sssd/issues/3960
In configurations that requires IPA users and groups to use fully qualified names (i.e.
groupname@IPA.DOMAIN) sudo is not able to resolve the users or groups in sudo rules correctly.
Example configuration: :
[sssd] domains = IPA.DOMAIN default_domain_suffix = AD.DOMAIN
[domain/IPA.DOMAIN] use_fully_qualified_names = True
Sudo rule won’t work since 1.13.4 if it contains non-POSIX group with IPA provider
Won’t fix, intentional: https://github.com/SSSD/sssd/issues/4079
We switched to IPA sudo rules schema stored at
cn=sudo in SSSD 1.13.4. The slapi-nis plugin that is used to generate the compat tree
ou=sudoers unfold members of non-POSIX group and stores each as
sudoUser: member value. This makes sudo rules work even with non-POSIX group if the compat tree is used.
To re-enable this functionality, you can switch SSSD to fetch sudo rules from the compat tree again by setting
The correct way to reference a non-POSIX group in sudo rule is to include it by a POSIX one which is referenced by sudo as “sudorule —\POSIX group <— non-POSIX group”.
Most of the sudo related user cases that we have in past years was actually only a misconfiguration of sudo rule or the client system. If you are not able to track down the issue yourself, feel free to ask one of the developers on SSSD mailing list or #sssd IRC channel on freenode. To speed things up, please prepare the following information:
- Description of the problem and what have you found out. You should at least know whether the issue lies on sudo (rules are send to sudo but it unexpectedly rejects access) or sssd (the rule is not even send to sudo) side with the use of previous debugging information.
- sudo and SSSD logs
- LDIF of rules that are expected to work but don’t
- Any additional information you deemed helpful – e.g. group membership, output of the following commands:
getent group $group
getent netgroup $netgroup
Sudo integration is supported since version 1.8.6 of sudo itself and version 1.9 of sssd.