I’ve already discussed how to set up a KDC in my earlier post on NFSv4 (I also explained how to Kerberize NFS). Let’s talk about setting up other services, such as SSH, LDAP, and Postfix (using Dovecot SASL for authentication). RHEL6 makes this dead drop simple, and many services have GSSAPI support built right in. GSSAPI, in turn, talks Kerberos. You create a few host principals, create a few new keytabs, and add a few lines here and there to configuration files. With a working KDC, most services can be configured in a few minutes at most. Rolling it out to every user and computer on a network will take a little more time, but most of that work can be scripted.

Kerberizing SSH with Host Principals

SSH will need a host principal in the form host/computer.domain.com on every computer running SSHD. As an example, assume I have a computer named Server and a computer named Client. I’ll create a host principal on Server called host/Server.domain.com. This will allow a user logged into Client to SSH into Server. It’ll also allow a user on Client1, Client2, and Server2 to do the same. However, if I want a user on Server to be able to log into Client, I will also have to create the principal host/Client.domain.com.

First, create the principal using kadmin. This can be done from any computer capable of talking to the KDC with an admin principal (my KDC is configured to allow users with the user principal form username/admin to perform administrative actions), or it can be done locally on the KDC without an administrative principal using kadmin.local.

# kadmin -p username/admin
kadmin: addprinc -randkey host/computer1.domain.com

Repeat the addprinc command for each computer you want to SSH into with Kerberos. Now, log into one of these computers and run kadmin again. This time, we’ll use ktadd to add the correct host principal to the local keytab. In this example, we’ll log into Computer1 and add Computer1′s host principal to the local keytab.

# kadmin -p username/admin
kadmin: ktadd host/computer1.domain.com

To configure Computer2, log into Computer2 and repeat the command, substituting Computer2 for Computer1. When you’re done configuring all your computers, each computer will have its own host principal and only its own host principal in its keytab file. You can verify this by running klist -k on each computer. Here is an example output for Computer1 (it’s normal to see multiples, since each one is actually a different encryption key):

# klist -k
   2 host/computer1.domain.com@DOMAIN.COM
   2 host/computer1.domain.com@DOMAIN.COM
   2 host/computer1.domain.com@DOMAIN.COM
   2 host/computer1.domain.com@DOMAIN.COM

The only thing left to do now is to configure /etc/ssh/sshd_config and /etc/ssh/ssh_config on each computer. Find and correct the following lines in /etc/ssh/sshd_config:

GSSAPIAuthentication yes
GSSAPIKeyExchange yes
GSSAPICleanupCredentials yes

After restarting SSHD, test the connection from a different machine with the following command:

ssh -v -K computer1.domain.com

If it worked, you should not be prompted for a password (assuming you have a valid ticket) and it should print out something like the following:

debug1: Next authentication method: gssapi-keyex
debug1: Authentication succeeded (gssapi-keyex).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env XMODIFIERS = @im=none
debug1: Sending env LANG = en_US.utf8
Last login: Tue Jan 31 14:21:21 2012 from computername.domain.com

You should also be able to run klist and see a ticket. If the login worked, but you don’t have a ticket, your KDC was not configured to issue forwardable tickets. This can be fixed. If the login worked, but it says Authentication succeeded (gssapi-with-mic), you’re still using Kerberos, but you’re probably trying to connect to a computer that doesn’t support GSSAPIKeyExchange, which is a relatively new addition to Linux.

You can now either edit /etc/ssh/ssh_config to tell SSH to use Kerberos automatically for every SSH connection or you can edit your personal ~/.ssh/config to enable it for your user account only. The lines and format are the same:

Host *
   GSSAPIAuthentication yes
   GSSAPIKeyExchange yes
   GSSAPIDelegateCredentials yes

To tell SSH to only use these options for local computers on the network (the Kerberos negotiation can add an extra unwanted delay), you can edit the first line to read Host *.domain.com. However, this means you will have to type the FQDN every time you use ssh. Alternatively, you can use the -K flag every time, which would eliminate the need to edit any client configuration files at all.

Kerberizing LDAP with Host Principals

Since Kerberos relies heavily on a user database backend like LDAP, there are a multitude of ways the two services can be configured to interact. You can create your KDC inside an LDAP database, you can store information about Kerberos principals in LDAP user fields, or you can use Kerberos to authenticate LDAP lookups. I'm only going to focus on the last bit there, using ldapsearch as an example to show GSSAPI in action. In RHEL6, ldapsearch tries to use SASL by default (SASL actually supports several mechanisms besides GSSAPI/Kerberos, but we'll configure it to only accept GSSAPI). You can disable SASL by using the -x flag to enable simple authentication, which is what we had been doing prior to Kerberizing our network, but why would anyone want to do that when we could be using glorious Kerberos?

First, we're going to perform the (increasingly familiar) task of creating the host principal for ldap. In this case, we will create one that uses the format ldap/ldapserver.domain.com:

# kadmin -p username/admin
kadmin: addprinc -randkey ldap/ldapserver.domain.com

Log into the ldap server and create a keytab for ldap. We will use an ldap specific keytab in /etc/openldap/ldap.keytab:

# kadmin -p username/admin
kadmin: ktadd -k /etc/openldap/ldap.keytab ldap/ldapserver.domain.com

Change the ownership and permissions for our new keytab:

# chown ldap:ldap /etc/openldap/ldap.keytab
# chmod 640 /etc/openldap/ldap.keytab

We're halfway there. Now we have to configure slapd to use GSSAPI. OpenLDAP has migrated to using a directory structure for slapd configuration. I prefer to edit something more human readable, though, so I edit /etc/openldap/slapd.conf and generate a new /etc/openldap/slapd.d only as necessary. Add or correct the following lines in /etc/openldap/slapd.conf:

sasl-secprops noanonymous,noplain,noactive
sasl-regexp uid=([^/]*),cn=GSSAPI,cn=auth uid=$1,ou=people,dc=domain,dc=com

The first line will prevent SASL from advertising undesired methods such as DIGEST-MD5. The second line will need to be configured to match your environment. When you run ldapsearch with SASL, it sends the user id to slapd in the form uid=username,cn=GSSAPI,cn=auth. This will map it into the form uid=username,ou=people,dc=domain,dc=com, which is the structure most ldap servers use. We throw away anything after the user id with a wildcard, so a principal that looks like username/admin will work just as well as username.

If you have ACLs set up, here is a way to add an access line for Kerberos administrators, shown alongside a more typical access line, assuming you use the syntax username/admin:

access to *
  by dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" write
  by group/groupOfUniqueNames/uniqueMember="cn=ldapadmins,ou=groups,dc=domain,dc=com" write
  by * read

Here you see the same cn=GSSAPI,cn=auth suffix from the sasl-regexp line, but now we're specifically looking for the /admin suffix after the user id.

The only thing left to do is to generate the new /etc/openldap/slapd.d configuration folder and restart slapd. If you were planning to store Kerberos information in LDAP, this would be an ideal time to add a Kerberos schema. I use the following commands to do the generation and restarting, although I usually paste it on one line, separating each command with semicolons:

# service slapd stop
# rm -rf /etc/openldap/slapd.d/
# mkdir slapd.d
# slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/
# chown -R ldap:ldap /etc/openldap/slapd.d/
# chmod -R go-rwx /etc/openldap/slapd.d/
# service slapd start

To test if Kerberos support is working, you should be able to run ldapsearch with GSSAPI SASL. Try a command like the following:

# ldapsearch uid=username

You should get something that looks like this, followed by the information about the username you're querying:

SASL/GSSAPI authentication started
SASL username: user@DOMAIN.COM
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base  (default) with scope subtree
# filter: uid=username
# requesting: ALL
#

You can check to see if you got a ticket with klist. You should see the host principal ldap/ldapserver.domain.com. If so, you have successfully Kerberized ldap!

Kerberizing Dovecot and Postfix with Host Principals

Dovecot, which is what we use for POP3, happily supports GSSAPI. We're going to give Dovecot its own keytab file, just like we did for LDAP. We'll create host principals with pop/ and smtp/ prefixes. (IMAP users should create a host principal that begins with imap/ instead of pop/.)

# kadmin -p username/admin
kadmin: addprinc -randkey pop/mailserver.domain.com
kadmin: addprinc -randkey smtp/mailserver.domain.com

On the mail server:

# kadmin -p username/admin
kadmin: ktadd -k /etc/dovecot/dovecot.keytab pop/mailserver.domain.com
kadmin: ktadd -k /etc/dovecot/dovecot.keytab smtp/mailserver.domain.com

Change the ownership and permissions for our new keytab:

# chown dovecot /etc/dovecot/dovecot.keytab
# chmod 640 /etc/dovecot/dovecot.keytab

Now we'll configure dovecot to use this keytab and use GSSAPI for user authentication. Edit /etc/dovecot/conf.d/10-auth.conf (or /etc/dovecot/dovecot.conf if 10-auth.conf does not exist) and add or edit the following lines:

auth_gssapi_hostname = mailserver.domain.com
auth_krb5_keytab = /etc/dovecot/dovecot.keytab
auth_mechanisms = gssapi

The value you choose for auth_gssapi_hostname here should match whatever you used in the host principals you created. If you need to support non-Kerberos users, auth_mechanisms will support several options. Here's what you would need to support both Kerberos principals and users with regular shadow passwords:

auth_mechanisms = plain gssapi

Next, we'll edit /etc/dovecot/10-master.conf to add support for authenticating postfix SMTP. Add or edit the following lines:

unix_listener /var/spool/postfix/private/auth {
  mode = 0666
  user = postfix
  group = postfix
}

We're done with configuring dovecot. Time to move on to configuring postfix! We'll edit /etc/postfix/main.cf and add or edit the following lines:

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

By default, postfix tries to use Cyrus SASL, but we want to use Dovecot, which we've already configured with a keytab and host principals. Some email clients don't follow the RFC correctly (*cough* old versions of Outlook and Outlook Express *cough*), so if you need to support them, you can add broken_sasl_auth_clients = yes to this list. smtpd_sasl_path tells postfix to use Unix sockets to communicate, but it's possible to use inet instead if you want to listen on a TCP port. If you decide to use inet, use something like inet:127.0.0.1:someport for smtpd_sasl_path. You'll then have to configure dovecot to listen on that port by replacing the unix_listener section we added to 10-master.conf something that looks like this:

inet_listener {
  port = someport
}

That's all you'll need to get postfix to talk to dovecot for SASL. Go ahead and restart the service. Time to try everything out! The version of Thunderbird shipped with RHEL6 supports Kerberos. (Sadly, Claws Mail does not, though I otherwise adore that program.) If you've already been using Thunderbird, open up your Account Settings and look for Authentication Method under Server Settings. Choose Kerberos/GSSAPI from the drop down list. (I'd hope you were already using SSL/TLS or STARTTLS for Connection Security.) Then under Outgoing Server (SMTP), select your server, click edit, and do the same for its Authentication method drop down list. If you'd previously been using passwords and told Thunderbird to remember them for you, you'll have to delete them from its Password Manager. You'll find the list of saved passwords in Edit -> Preferences. Go to the Security tab, then select Passwords. You'll see a button labeled Saved Passwords.

Try "Get Mail." Look at your tickets with klist as usual. You should see a ticket that looks like pop/mailserver.domain.com@DOMAIN.COM. Try sending a message and look at your tickets again. You should see a ticket that looks like smtp/mailserver.domain.com@DOMAIN.COM. If so, you're done! If not, log into the mail server and look at your maillog to find out where it all went wrong.

This entry was posted on Tuesday, January 31st, 2012 at 8:10 pm and is filed under HOWTOs, Reading Materials. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.