I found out today that SSSD doesn’t support multiple domains in the way I thought it did. I thought I could tell SSSD to try Kerberos first, and if it failed, try LDAP. What isn’t documented ANYWHERE, but is instead buried in a mailing list post, is that if you use the same LDAP server/id_provider for both domains, SSSD won’t perform the lookup a second time for the LDAP domain. It just dies horribly and silently (I haven’t found SSSD error messages terribly enlightening). In the same mailing list post, it was suggested that different search bases for Kerberos and LDAP users be used, or that usernames be fully qualified. In the first case, different search bases would allow me to use Kerberos as my primary domain, but fully qualified usernames would only work if Kerberos was the second domain. I can see I have more testing to do. In any case, you can read the relevant post on Fedora Hosted, where the poster explains the reason for this decision. In any case, I’m glad I found the post, because man sssd.conf mentions no such limitations.
SSSD supports LDAP and Kerberos with ease. Once I’d ironed out the wrinkle with multiple domains and shelved that problem for another day, I made much better progress on my testbed machine. Here’s an example sssd.conf that will support a Kerberos domain:
[sssd]
config_file_version = 2
services = nss, pam
domains = kerberos
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
[pam]
reconnection_retries = 3
[domain/kerberos]
id_provider = ldap
ldap_uri = ldap://ldapserver.domain.com
ldap_search_base = dc=domain,dc=com
ldap_id_use_start_tls = true
auth_provider = krb5
chpass_provider = krb5
krb5_server = kerberos.domain.com
krb5_realm = DOMAIN.COM
krb5_ccname_template = FILE:%d/krb5cc_%UThe [nss] and [pam] sections are straight out of the default config file. The important line to change right at the top of the config file is domains, which should be set to whatever you’ll call your Kerberos section. I named mine [domain/kerberos] because I’m boring that way, so I used domains = kerberos. You could also have named it [domain/awesome] and it would still work as long as your domains line read domains = awesome. The domain/ prefix is the important part.
Once we’ve pointed domains to look at [domain/kerberos], we’ll set up a few options. First, we’ll set up the id_provider to use ldap. SSSD is smart enough to get some of its information from /etc/openldap/openldap.conf, so although we use TLS, I don’t have to tell SSSD where to find our certificate files. Instead, I give it our URI, the search base, and I set ldap_id_use_start_tls to true to make sure it uses TLS. Now we’ll move on to the Kerberos specific part. First, we set auth_provider and chpass_provider to krb5 to make sure it talks to Kerberos instead of falling back to LDAP for authentication or storing passwords. Then we set krb5_server to our Kerberos server (it can be a comma separated list, if you have backup KDCs on your network). krb5_realm should be self explanatory. I’ve modified krb5_ccname_template to use the simpler form /tmp/krb5cc_someuserid. The default is to create a file with a unique suffix, which isn’t what I wanted.
Once you’re done editing /etc/sssd/sssd.conf, start (or restart) the service and ensure it runs at boot:
# /sbin/service sssd start
# /sbin/chkconfig sssd onSSSD assumes that you’ve configured pam to use its pam_sss module to make everything possible. If you’re using a default RHEL6 install and haven’t touched /etc/pam.d/password-auth-ac or /etc/pam.d/system-auth-ac, everything should be configured correctly. Check both files to make sure you have an auth, an account, a password, and a session line for pam_sss.so in each.
You should now be able to log into your computer and automatically get a Kerberos ticket, either from the command line or from GDM. You can test this by wiping out your tickets with kdestroy, dropping down to a command line, and logging in. You should be able to run klist and see a ticket.