Troubleshooting SSSD, realm, kerberos, and SSH

SSSD (System Security Services Daemon) allows Linux systems (specifically, Red Hat, CentOS, and Fedora) to verify identity and authenticate against remote resources. If you have a CentOS or Red Hat enterprise system, and you need to authenticate against a domain controller such as FreeIPA or Active Directory, SSSD is the way to go. I use SSSD on CentOS 7 systems, but it is now available on CentOS 6 as well. A few years ago, adclient (an open-source project from Centrify) was your only option to make a CentOS 6 server authenticate against Active Directory. adclient seems to have reached end of life, so SSSD is definitely the path forward.
I won’t repeat the procedure for using Active Directory as an identity provider on a Red Hat 7 system. Instead, I want to provide a few troubleshooting tips, since limited information is available on SSSD and related tools.

SSSD Troubleshooting

You can increase the verbosity of output from SSSD by setting the debug_level=N directive in /etc/sssd/sssd.conf. N is a number from 1 to 10. You must put this directive in EACH section of the config file.
Let’s re-join the realm, with verbose output:

realm list
realm leave mydomain.local
realm join --verbose --user=bobsmith mydomain.local

If you’ve joined successfully, you should be able to get information on a domain user:

getent passwd bobsmith@mydomain.local

bobsmith@mydomain.local:*:123456789:123456789:Bob Smith:/home/bobsmith@mydomain.local:/bin/bash

id bobsmith@mydomain.local

Now, Bob tries to log in with:

ssh bobsmith@linux-host-01

However, Bob can’t log in, and the following errors appear in /var/log/secure:

Mar  9 18:36:12 linux-host-01 sshd[10488]: Invalid user bobsmith from 172.12.33.123
Mar  9 18:36:12 linux-host-01 sshd[10488]: input_userauth_request: invalid user bobsmith [preauth]
Mar  9 18:36:16 linux-host-01 sshd[10488]: Failed password for invalid user bobsmith from 172.12.33.123 port 55972 ssh2
Mar  9 18:36:18 linux-host-01 sshd[10488]: Connection closed by 172.12.33.123 [preauth]

What’s going on? Go back to the information that you got from the getent command. Note that the system thinks the user is named bobsmith@mydomain.local, but he’s logging in without specifying the domain! Bob should be able to log in with:

ssh bobsmith@mydomain.local@linux-host-01

That’s annoying, and his home directory name will be bobsmith@mydomain.local. The solution is to add the following lines to /etc/sssd/sssd.conf so that user names don’t require a FQDN:

use_fully_qualified_names = False
fallback_homedir = /home/%u

Kerberos troubleshooting

# Get a Kerberos ticket from AD
kinit bobsmith@MYDOMAIN.LOCAL
# Show the ticket
klist
# Show keys in a keytab file
klist -kt /etc/krb5.keytab

The keys should resemble this:

KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   3 03/10/2016 11:33:14 host/linux-host-01.mydomain.local@MYDOMAIN.LOCAL
   3 03/10/2016 11:33:14 host/linux-host-01@MYDOMAIN.LOCAL