Test setup: # bind system to KDC (ie. AD) # ensure the system for kerberos (make sure you can kinit as your user) # add the following to the pam-auth-update templates (/usr/share/pam-configs/sss-gssapi) (note I added debug to increase verbosity for this test, this is not needed for general use)
Name: SSS GSSAPI authentication Default: yes Priority: 900 Auth-Type: Primary Auth: [success=end default=ignore] pam_sss_gss.so debug Auth-Initial: [success=end default=ignore] pam_sss_gss.so debug # run pam-auth-update to enable the module # add to /etc/sssd/sssd.conf under the kerberos realm/domain section, restart sssd [domain/realm section] pam_gssapi_services = sudo, sudo-i [pam] pam_response_filter = ENV:KRB5CCNAME # add yourself to the /etc/sudoers.d/user_[username] user1 ALL=(ALL) ALL Testing that pam_sss_gss.so is properly authing: # login as your user, view (or gain) kerberos credentials (klist to verify valid ccache, kinit to gain creds if needed) # run sudo -i or sudo [command]. this should execute the sudo without issue eg: user1@working-host1:~$ echo $KRB5CCNAME user1@working-host1:~$ kinit us...@example.com user1@working-host1:~$ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: us...@example.com Valid starting Expires Service principal 03/20/25 22:49:12 03/21/25 08:49:12 krbtgt/example....@example.com renew until 03/21/25 22:49:09 user1@working-host1:~$ sudo -i pam_sss_gss: Initializing GSSAPI authentication with SSSD pam_sss_gss: Switching euid from 0 to 1234556 pam_sss_gss: Trying to establish security context pam_sss_gss: SSSD User name: us...@example.com pam_sss_gss: User domain: example.com pam_sss_gss: User principal: pam_sss_gss: Target name: h...@working-host1.example.com pam_sss_gss: Using ccache: default pam_sss_gss: Acquiring credentials, principal name will be derived pam_sss_gss: Switching euid from 1234556 to 0 pam_sss_gss: Authentication successful root@host1:~# # exit back to user session, view krb ccache. a valid service ticket for host/working-host1.example.com will be seen. test to verify blocking access without valid kerberos creds: (intentional failure test) # login as your user, destroy all krb creds: kdestroy -A # verify creds are destroyped/ccache is empty with klist -A # run sudo -i or sudo [command]. this should execute sudo as usual via the pam stack, asking for alternative credentials based on the pam-auth-update configuration user1@working-host1:~$ echo $KRB5CCNAME user1@working-host1:~$ kdestroy -A user1@working-host1:~$ klist klist: No credentials cache found (filename: /run/user/1234556/krb5cc) user1@working-host1:~$ sudo -i pam_sss_gss: Initializing GSSAPI authentication with SSSD pam_sss_gss: Switching euid from 0 to 1234556 pam_sss_gss: Trying to establish security context pam_sss_gss: SSSD User name: us...@example.com pam_sss_gss: User domain: example.com pam_sss_gss: User principal: pam_sss_gss: Target name: h...@working-host1.example.com pam_sss_gss: Using ccache: default pam_sss_gss: Acquiring credentials, principal name will be derived pam_sss_gss: Unable to read credentials from [default] [maj:0x70000, min:0x96c73a8d] pam_sss_gss: GSSAPI: No credentials were supplied, or the credentials were unavailable or inaccessible pam_sss_gss: GSSAPI: No Kerberos credentials available (default cache: FILE:/run/user/1234556/krb5cc) pam_sss_gss: Switching euid from 1234556 to 0 pam_sss_gss: System error [5]: Input/output error Please insert smart card access is blocked. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2103623 Title: pam_sss_gss fails to work when KRB5CCNAME is not set To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/2103623/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
