Unable to setup password-less login via GSSAPI integration in Red Hat Enterprise Linux 8
Environment
- Red Hat Enterprise Linux 8
- SSSD integrating with an AD domain
- Password-less login via GSSAPI integration
Issue
- We are starting to install Red Hat Enterprise Linux 8, using System Security Services Daemon (SSSD) to integrate with an Active Directory (AD) domain. Unlike Red Hat Enterprise Linux 7 systems, we are unable to login without password, using GSSAPI integration.
- Even with a valid Kerberos ticket on Red Hat Enterprise Linux 8, I still have to input my password to login with my account that is linked to AD. I can login without a password in Red Hat Enterprise Linux 7 and below.
- I am unable to login without a password to my user unless I clear the Kerberos credentials cache and generate a new ticket.
- I can perform password-less login if the case of the login credentials (username, hostname, principal, etc) match exactly to their configured values. If any of the credentials have a different case from their configured values (e.g. The_Admin@EXAMPLE.COM versus the_admin@EXAMPLE.COM), login requires a password.
Resolution
-
The issue is currently being investigated by Red Hat engineering in the public Bugzilla report BZ1961182.
- Please note while the report may be public, engineering may make particular comments private and inaccessible to the public for security reasons.
- For updates on this particular issue, please do not hesitate to follow this knowledge-base article and/or engage your respective Red Hat support representative.
Workaround
-
The following modifications to Kerberos configurations,
/etc/krb5.conf
on the problem client systems is known to workaround the issue;includedir /etc/krb5.conf.d/ includedir /var/lib/sss/pubconf/krb5.include.d/
Root Cause
authconfig
in Red Hat Enterprise Linux 7 and below was replaced withauthselect
in Red Hat Enterprise Linux 8 in order to simplify setup and troubleshooting efforts. Withauthconfig
, it addedincludedir /var/lib/sss/pubconf/krb5.include.d
in/etc/krb5.conf
when configuring SSSD.authselect
does not do this currently.
Diagnostic Steps
To reproduce this issue
- Install Red Hat Enterprise Linux 8 (either as a virtual machine or as a physical system)
- Configure SSSD to allow authentication with a remote provider and have the system join to an AD domain
- Attempt to SSH into the system via password-less authentication
- Implement the workaround noted in the Resolution section and restart SSSD
- Attempt to SSH into the system via password-less authentication
What to look for
With either the issue reproduced as noted above or reproduced in your environment, the following are logs and command outputs to look for
-
SSH
-
The following is debug SSH login output to a Red Hat Enterprise Linux 8 system experiencing the issue
$ ssh -vvv me@rhel8-example-system [...] debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<[...]> debug3: receive packet: type 6 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug3: send packet: type 50 debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic <--- debug3: send packet: type 50 debug2: we sent a gssapi-with-mic packet, wait for reply debug3: receive packet: type 60 debug3: send packet: type 61 debug3: receive packet: type 61 debug3: send packet: type 66 debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password <--- [...]
-
Compared with SSH login to a Red Hat Enterprise Linux 7 system
$ ssh -vvv me@rhel7-example-system [...] debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic <--- debug3: send packet: type 50 debug2: we sent a gssapi-with-mic packet, wait for reply debug3: receive packet: type 60 debug3: send packet: type 61 debug3: receive packet: type 61 debug3: send packet: type 66 debug3: receive packet: type 52 debug1: Authentication succeeded (gssapi-with-mic). <--- [...]
-
-
Kerberos
-
Check the Kerberos ticket info for mismatching values/cases;
[the_admin@example-system:~]$ klist -f Ticket cache: KCM:000000000000:00000 Default principal: The_Admin@EXAMPLE.COM <--- [the_admin@example-system:~]$ ssh `hostname` the_admin@example-system's password: ^C
-
In the above, the username is
the_admin
but the ticket is forThe_Admin
, a case mismatch. Because the case does not match, the ticket maps toThe_Admin
and does not map tothe_admin
. -
Clearing the Kerberos cache and generating a new ticket may enable a proper case match:
[the_admin@example-system:~]$ kdestroy -A && kinit Password for the_admin@EXAMPLE.COM: [the_admin@example-system:~]$ klist -f Ticket cache: KCM:0000000000 Default principal: the_admin@EXAMPLE.COM <--- [the_admin@example-system:~]$ ssh `hostname` [the_admin@example-system:~]$
-
In the above, the principal had a matching case to the login so login was successful without a password.
-
-
Configurations
-
Check
/etc/krb5.conf
for the appropriate configuration line:grep -c '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf 0
-
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Comments