Unable to setup password-less login via GSSAPI integration in Red Hat Enterprise Linux 8

Solution Unverified - Updated -

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 with authselect in Red Hat Enterprise Linux 8 in order to simplify setup and troubleshooting efforts. With authconfig, it added includedir /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

  1. Install Red Hat Enterprise Linux 8 (either as a virtual machine or as a physical system)
  2. Configure SSSD to allow authentication with a remote provider and have the system join to an AD domain
  3. Attempt to SSH into the system via password-less authentication
  4. Implement the workaround noted in the Resolution section and restart SSSD
  5. 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 for The_Admin, a case mismatch. Because the case does not match, the ticket maps to The_Admin and does not map to the_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