From 4fc384ca7931a57784163cb18a546bfc85ed3e35 Mon Sep 17 00:00:00 2001 From: Fabiano Fidêncio Date: Jul 17 2017 21:00:13 +0000 Subject: Add "sudo troubleshooting" page This is pretty much a copy & paste frm the original one, with basically a few changes: - pointing some links to pagure instead of fedorahosted Signed-off-by: Fabiano Fidêncio Co-author: Jakub Hrozek --- diff --git a/users/index.rst b/users/index.rst index ef39d67..a45e46c 100644 --- a/users/index.rst +++ b/users/index.rst @@ -8,5 +8,6 @@ and troubleshoot SSSD. :maxdepth: 1 troubleshooting + sudo_troubleshooting reporting_bugs releases diff --git a/users/sudo_troubleshooting.rst b/users/sudo_troubleshooting.rst new file mode 100644 index 0000000..48721e3 --- /dev/null +++ b/users/sudo_troubleshooting.rst @@ -0,0 +1,269 @@ +.. highlight:: none + +Troubleshooting SUDO +==================== + +Check if configuration of sudo and SSSD cooperation is correct +-------------------------------------------------------------- + +To check whether the basic configuration of sudo and SSSD is correct, +check ``/etc/nsswitch.conf`` and ``/etc/sssd/sssd.conf`` files. + +- ``/etc/nsswitch.conf`` must say that ``sss`` module 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.conf`` must say that ``sudo responder is enabled``. + Look at [sssd] section and search for line ``"services: nss, pam, + sudo"`` or similar. +- In ``/etc/sssd/sssd.conf`` check that ``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". + +Obtaining logs +-------------- + +Logs can provide many useful information when finding a solution for +your troubles. + +**a) How do I get sudo logs?** + +#. Open ``/etc/sudo.conf`` and put down the following lines: :: + + Debug sudo /var/log/sudo_debug all@debug + Debug sudoers.so /var/log/sudo_debug all@debug + +#. Run ``sudo`` +#. File ``/var/log/sudo_debug`` contains sudo logs + +**b) How do I get SSSD logs?** + +#. Open ``/etc/sssd/sssd.conf`` and enable logging by setting a debug + level in ``[sudo]`` and ``[domain/$NAME]`` section: ``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) + +What to look for in the logs +---------------------------- + +**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 descibred 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 successfuly 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 + + - Anonymous bind:: + + 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' + + - GSSAPI :: + + 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[22259] settings: debug_flags=all@debug + Mar 31 16:11:15 sudo[22259] settings: run_shell=true + Mar 31 16:11:15 sudo[22259] settings: progname=sudo + Mar 31 16:11:15 sudo[22259] 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[22259] user_info: user=$username + Mar 31 16:11:15 sudo[22259] user_info: pid=22259 + Mar 31 16:11:15 sudo[22259] user_info: ppid=22172 + Mar 31 16:11:15 sudo[22259] user_info: pgid=22259 + Mar 31 16:11:15 sudo[22259] user_info: tcpgid=22259 + Mar 31 16:11:15 sudo[22259] user_info: sid=22172 + Mar 31 16:11:15 sudo[22259] user_info: uid=$uid + Mar 31 16:11:15 sudo[22259] user_info: euid=0 + Mar 31 16:11:15 sudo[22259] user_info: gid=554801393 + Mar 31 16:11:15 sudo[22259] user_info: egid=554801393 + Mar 31 16:11:15 sudo[22259] user_info: groups=498,6004,6005,7001,106501,554800513,554801107,554801108,554801393,554801503,554802131,554802244,554807670 + Mar 31 16:11:15 sudo[22259] user_info: cwd=/ + Mar 31 16:11:15 sudo[22259] user_info: tty=/dev/pts/1 + Mar 31 16:11:15 sudo[22259] user_info: host=$hostname + Mar 31 16:11:15 sudo[22259] user_info: lines=31 + Mar 31 16:11:15 sudo[22259] user_info: cols=237 + +- What data sources are used to fetch sudo rules :: + + Mar 31 16:11:15 sudo[22259] <- sudo_parseln @ ./fileops.c:178 := sudoers: files sss + +- SSSD plugin starts here :: + + Mar 31 16:11:15 sudo[22259] <- sudo_sss_open @ ./sssd.c:305 := 0 + +- Here is sudo looking for cn=defaults :: + + Mar 31 16:11:15 sudo[22259] Looking for cn=defaults + +- SSSD is returning rules :: + + Mar 31 16:11:15 sudo[22259] 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[22259] 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[22259] <- user_in_group @ ./pwutil.c:1010 := false + +Common questions +---------------- + +**a) Setting global options with cn=defaults when sudo rules are stored +on an IPA server** + +To immitate 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 ``cn=defaults``. + +**c) it takes too long to update rules** + +Look at ``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 +``authenticate``. See ``SUDOERS OPTIONS`` section of ``sudoers.5`` manual page +for more information. + +Known issues +------------ + +**Problems with IPA-AD trust when fully qualified names are required for +IPA** + +**Fixed in 1.14.0**: +`https://pagure.io/SSSD/sssd/issue/2919 `__ + +In configurations that requires IPA users and groups to use fully +qualified names (i.e. ``username@IPA.DOMAIN`` and ``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 + +Or: :: + + [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://pagure.io/SSSD/sssd/issue/3046 `__ + +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 ``ldap_sudo_search_base`` to +``ou=sudoers,dc=example,dc=com`` + +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". + +Asking for help +--------------- + +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: + + - ``id $user`` + - ``getent group $group`` + - ``getent netgroup $netgroup`` + +Supported versions +------------------ + +Sudo integration is supported since version 1.8.6 of sudo itself and +version 1.9 of sssd. diff --git a/users/troubleshooting.rst b/users/troubleshooting.rst index df5c7d3..cf36612 100644 --- a/users/troubleshooting.rst +++ b/users/troubleshooting.rst @@ -61,6 +61,10 @@ own log files, such as ``ldap_child.log`` or ``krb5_child.log``. Keep in mind that enabling ``debug_level`` in the ``[sssd]`` section only enables debugging of the sssd process itself, not all the worker processes! +Troubleshooting sudo +-------------------- +`Troubleshooting SUDO `_ - a guide to troubleshoot sudo issues + Troubleshooting User Information --------------------------------