Bug 1926622

Upstream issue: https://github.com/SSSD/sssd/issues/5482
Upstream PR: https://github.com/SSSD/sssd/pull/5494

Verification steps:

1. Install IPA server, may be with --with-mkhomedir to simplify test

2. Add pam_sss_gss configuration to /etc/sssd/sssd.conf to [pam] or [domain/..] section

pam_gssapi_services = sudo, sudo-i
pam_gssapi_indicators_map = hardened, sudo:pkinit, sudo-i:otp

3. Add pam_sss_gss.so to /etc/pam.d/sudo

# cat /etc/pam.d/sudo
#%PAM-1.0
auth sufficient pam_sss_gss.so debug
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    optional     pam_keyinit.so revoke
session    required     pam_limits.so
session    include      system-auth

4. Restart SSSD

5. Enable SSSD debug logs

sssctl debug-level 9

6. Switch to 'admin' user

su - admin

7. obtain Kerberos ticket and check that it was obtained using SPAKE pre-authentication:

export KRB5_TRACE=/dev/stderr
kinit admin


8. Create sudo configuration that allows an admin to run SUDO rules:

ipa sudocmd-add ALL
ipa sudorule-add testrule
ipa sudorule-add-allow-command testrule --sudocmds 'ALL'
ipa sudorule-mod testrule --hostcat=all
ipa sudorule-add-user testrule --users admin

9. Now try 'sudo -l' as admin while there is 

sudo -l

You would see pam_sss_gss debug output and if successful, output of 'sudo -l':

pam_sss_gss: Initializing GSSAPI authentication with SSSD
pam_sss_gss: Switching euid from 0 to 1169800000
pam_sss_gss: Trying to establish security context
pam_sss_gss: SSSD User name: admin
pam_sss_gss: User domain: ipa.test
pam_sss_gss: User principal: 
pam_sss_gss: Target name: host.test
pam_sss_gss: Using ccache: default
pam_sss_gss: Acquiring credentials, principal name will be derived
pam_sss_gss: Switching euid from 1169800000 to 0
pam_sss_gss: Authentication successful
Matching Defaults entries for admin on master:
    !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION
    LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/var/lib/snapd/snap/bin

User admin may run the following commands on master:
    (root) ALL


10. As root, check content of sssd_pam.log:
# fgrep gssapi_ /var/log/sssd/sssd_pam.log |tail -10

It should contain something like
(2021-02-09  9:15:31): [pam] [pam_cmd_gssapi_init_done] (0x0400): Trying GSSAPI auth: User[admin], Domain[ipa.test], UPN[], Target[host.test]
(2021-02-09  9:15:31): [pam] [pam_cmd_gssapi_init_done] (0x0400): Returning [0]: Success
(2021-02-09  9:15:31): [pam] [gssapi_handshake] (0x0400): Security context established with [admin]
(2021-02-09  9:15:31): [pam] [gssapi_get_indicators] (0x0400): attribute's [auth-indicators] value [hardened] authenticated
(2021-02-09  9:15:31): [pam] [gssapi_get_indicators] (0x0400): authentication indicators: [hardened]
(2021-02-09  9:15:31): [pam] [pam_gssapi_check_indicators] (0x0400): indicator [hardened] is allowed for PAM service [sudo]
(2021-02-09  9:15:31): [pam] [pam_cmd_gssapi_sec_ctx] (0x0400): Check if acquired service ticket has req. indicators: 0
(2021-02-09  9:15:31): [pam] [pam_cmd_gssapi_sec_ctx] (0x0400): Checking that target user matches UPN
(2021-02-09  9:15:31): [pam] [pam_cmd_gssapi_sec_ctx_done] (0x0400): User [admin] match UPN [admin]. Authentication was successful.
(2021-02-09  9:15:31): [pam] [pam_cmd_gssapi_sec_ctx_done] (0x0400): Returning [0]: Success

An empty list of indicators associated with a PAM service can be built by not providing an indicator in the pam_gssapi_indicators_map. For example, for 'sudo' below there is no indicator associated which means indicator check is not done for 'sudo':

pam_gssapi_services = sudo, sudo-i
pam_gssapi_indicators_map = sudo-i:hardened

For empty list of indicators associated with the PAM service the output would be this:
(2021-02-09  9:18:07): [pam] [pam_cmd_gssapi_init] (0x4000): Requesting GSSAPI authentication of [admin] in service [sudo]
(2021-02-09  9:18:07): [pam] [pam_cmd_gssapi_init_done] (0x0400): Trying GSSAPI auth: User[admin], Domain[ipa.test], UPN[], Target[host.test]
(2021-02-09  9:18:07): [pam] [pam_cmd_gssapi_init_done] (0x0400): Returning [0]: Success
(2021-02-09  9:18:07): [pam] [gssapi_handshake] (0x0400): Security context established with [admin]
(2021-02-09  9:18:07): [pam] [gssapi_get_indicators] (0x0400): attribute's [auth-indicators] value [hardened] authenticated
(2021-02-09  9:18:07): [pam] [gssapi_get_indicators] (0x0400): authentication indicators: [hardened]
(2021-02-09  9:18:07): [pam] [pam_cmd_gssapi_sec_ctx] (0x0400): Check if acquired service ticket has req. indicators: 2
(2021-02-09  9:18:07): [pam] [pam_cmd_gssapi_sec_ctx] (0x0400): Checking that target user matches UPN
(2021-02-09  9:18:07): [pam] [pam_cmd_gssapi_sec_ctx_done] (0x0400): User [admin] match UPN [admin]. Authentication was successful.
(2021-02-09  9:18:07): [pam] [pam_cmd_gssapi_sec_ctx_done] (0x0400): Returning [0]: Success

e.g. the difference would be in the error code of '[pam_cmd_gssapi_sec_ctx] (0x0400): Check if acquired service ticket has req. indicators:'. '0' is success (EOK), '1' is error (EPERM), '2' is 'not applied' (ENOENT), '22' is an internal failure (EINVAL).

Pushed PR: https://github.com/SSSD/sssd/pull/5494

* `master`
    * 5ce7ced269c7b3dd8f75122a50f539083b5697ae - pam_sss_gss: support authentication indicators

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (sssd bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:1666