To go with the Kerberized Postfix that I’ve put in place, I also added Kerberized IMAP to it as well. This will allow me to authenticate the IMAP server with my Kerberos tickets. This works similarly. I’m using Carnegie Mellon’s Cyrus IMAP server (although CMU has migrated all of it’s accounts over to Google since). The Cyrus server supports GSSAPI natively, and other mechanisms through their SASL implementation. Using GSSAPI, I can now connect from my mail client and access my IMAP mailbox using my already granted ticket.
Configuration of this is straightforward. There is a configuring and testing GSSAPI authentication page on the Cyrus website which I worked through. The service that I’m using is imap, which is the service that the IMAP server and the client is looking for. I’ll need to tell the Cyrus server to support GSSAPI:
# Force PLAIN/LOGIN authentication only # (you need to uncomment this if you are not using an auxprop-based SASL # mechanism. saslauthd users, that means you!). And pay attention to # sasl_minimum_layer and allowapop below, too. # #sasl_mech_list: PLAIN sasl_mech_list: GSSAPI
I’ll need to install the saslauth daemon for Cyrus SASL like I did for the Postfix MTA, which is available in the sasl2-bin package on Ubuntu.
sudo apt-get install sasl2-bin
I still need to generate the service principal and the the keytable for the “
kadmin> addprinc -randkey imap/tomlinson.internal.example.com kadmin> ktadd -k /etc/krb5.keytab imap/tomlinson.internal.example.com
As an aside, since I’m using the same server for MTA and IMAP, the keytab will contain the keys for both the
imap service principals.
Now, if I’m granted a ticket as a user I can connect to the server with my ticket, and the Kerberos system will take care of the authentication, and I’ll be granted access to the server for submitting mail.
On the client side, I’ll need to tell it that I want to use my Kerberos tickets for connecting to my mailbox. For example, Apple Mail supports this method of authentication. You’ll need to tell it that you are using GSSAPI as the authentication mechanism.
PLAIN authentication via Kerberos5
For connections from outside where ticket exchange cannot work, I use
PLAIN authentication via Kerberos 5 based SASL. To enable this, I add the PLAIN mechanism to Cyrus IMAP to it’s list of SASL mechanisms.
# Force PLAIN/LOGIN authentication only # (you need to uncomment this if you are not using an auxprop-based SASL # mechanism. saslauthd users, that means you!). And pay attention to # sasl_minimum_layer and allowapop below, too. # #sasl_mech_list: PLAIN sasl_mech_list: GSSAPI PLAIN
In this case now, I can authenticate myself either with ticket exchange, or with a password which is authenticated against the Kerberos server. I still need to have the saslauthd daemon running, however, I will need to have a service principal for the “
kadmin> addprinc -randkey host/tomlinson.internal.example.com kadmin> ktadd -k /etc/krb5.keytab host/tomlinson.internal.example.com
There are now a number of service principals in the system keytab : imap, smtp, and host.
The saslauthd daemon will need to be setup and configured. It uses the
/etc/default/saslauthd file for configuration during startup. This is configured to select “kerberos5” as the mechanism.
# # Settings for saslauthd daemon # Please read /usr/share/doc/sasl2-bin/README.Debian for details. # # Should saslauthd run automatically on startup? (default: no) START=yes # Description of this saslauthd instance. Recommended. # (suggestion: SASL Authentication Daemon) DESC="SASL Authentication Daemon" # Short name of this saslauthd instance. Strongly recommended. # (suggestion: saslauthd) NAME="saslauthd" # Which authentication mechanisms should saslauthd use? (default: pam) # # Available options in this Debian package: # getpwent -- use the getpwent() library function # kerberos5 -- use Kerberos 5 # pam -- use PAM # rimap -- use a remote IMAP server # shadow -- use the local shadow password file # sasldb -- use the local sasldb database file # ldap -- use LDAP (configuration is in /etc/saslauthd.conf) # # Only one option may be used at a time. See the saslauthd man page # for more information. # # Example: MECHANISMS="pam" MECHANISMS="kerberos5" # Additional options for this mechanism. (default: none) # See the saslauthd man page for information about mech-specific options. MECH_OPTIONS="" # How many saslauthd processes should we run? (default: 5) # A value of 0 will fork a new process for each connection. THREADS=5 # Other options (default: -c -m /var/run/saslauthd) # Note: You MUST specify the -m option or saslauthd won't run! # # WARNING: DO NOT SPECIFY THE -d OPTION. # The -d option will cause saslauthd to run in the foreground instead of as # a daemon. This will PREVENT YOUR SYSTEM FROM BOOTING PROPERLY. If you wish # to run saslauthd in debug mode, please run it by hand to be safe. # # See /usr/share/doc/sasl2-bin/README.Debian for Debian-specific information. # See the saslauthd man page and the output of 'saslauthd -h' for general # information about these options. # # Example for chroot Postfix users: "-c -m /var/spool/postfix/var/run/saslauthd" # Example for non-chroot Postfix users: "-c -m /var/run/saslauthd" # # To know if your Postfix is running chroot, check /etc/postfix/master.cf. # If it has the line "smtp inet n - y - - smtpd" or "smtp inet n - - - - smtpd" # then your Postfix is running in a chroot. # If it has the line "smtp inet n - n - - smtpd" then your Postfix is NOT # running in a chroot. OPTIONS="-c -m /var/run/saslauthd"
In this scenario, the client configuration is easy. It will perform password based authentication to the IMAP server.