[Network Administration] : Kerberized Postfix

I updated my mail server and connected this into the kerberized system that was put in place earlier. Previously I had my mail accounts defined in a MYSQL database, which worked alright, but was really more of a hassle since any password changes needed to be done both in the system, and in the mysql database which was used by postfix. Either I had a single password, and needed to update both databases if it was changed, or I had to let them diverge. I’ll need an authentication mechanism so that I can submit mail from the mail client (MUA) for delivery. This time, I connected postfix, which I use as my MTA, to the Kerberos server to do the authentication. Postfix supports SASL mechanisms for authentication and can use it for both GSSAPI and PLAIN authentication against the Kerberos system. The postfix website has a whole page describing use of SASL with Postfix. I used Cyrus SASL from Carnegie Mellon University to do the authentication.


The GSSAPI mechanism provides access to the Kerberos implementation for authentication. It uses the granted ticket instead of a password. The following from /etc/postfix/main.cf will setup Postfix to use Cyrus SASL. There is more documentation fore each of the parameters on the postfix website. The first line provides the name of the SASL file to read. The second line specifies that we’re using the Cyrus SASL implementation. The third line specifies that we are enabling it for authentication. The last two lines will determine which mechanisms are advertised for use. There is more information here describing what the options mean.

# We enable sasl authentication so that clients can connect from
# by password to submit mail (ex. clients outside of subnet/realm)
smtpd_sasl_path = smtpd
smtpd_sasl_type = cyrus
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = no anonymous

The next section sets up TLS for communication with the MUA to allow for mail submission. The Postfix website also has a page for TLS support. We disable the default CAs from being appended to the list of CA’s that we use for certificate verification (tls_append_default_CA=no). This is because I only want to allow for certificates that are signed by a specific CA to be used for TLS negotiation, otherwise all valid certificates that are signed by CA’s that we trust in the system will pass the TLS check, which isn’t what I want. I’m also forcing TLS communication with any clients that want to connect. I can get away with this because I also have a mail gateway that listens on port 25 (long story – Comcast blocks port 25 so I need something running outside that can relay into my network on a different port — I’m using the submission port: 587). Also, I’ve required that authentication mechanisms are only accepted on TLS encrypted session by setting smtp_tls_auth_only = yes.

# Don't trust third party CAs (we have our own)
tls_append_default_CA = no

# For STMPD transport
smtpd_tls_loglevel = 1
smtpd_tls_security_level = encrypt
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_received_header = yes
smtpd_tls_cert_file = /usr/local/etc/ssl/certs/smtp/${myhostname}.pem
smtpd_tls_key_file =  /usr/local/etc/ssl/private/smtp/${myhostname}.key
smtpd_tls_CAfile = /usr/local/etc/ssl/ca/foodclaw_CA1_cert_chain.pem
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_cache

Once I’ve set up being able to authenticate, I can now use this to control client access to the server. I’ve allowed SASL authenticated clients to connect the SMTPD server.

smtpd_client_restrictions =

I specified the SASL file above. It’s simple and only looks like this:

pwcheck_method: saslauthd
mech_list: GSSAPI 

This says that I’m going to be using GSSAPI for authentication, and am using saslauthd as the authentication daemon. I’ll need to install the saslauth deamon, which is available in the sasl2-bin package on Ubuntu.

sudo apt-get install sasl2-bin

That’s about it. However, in order to get this to work, I still need to generate all of the service tickets and install them on the machine. The service name for GSSAPI based authentication is “smtp“.

kadmin> addprinc -randkey smtp/tomlinson.internal.example.com
kadmin> ktadd -k /etc/krb5.keytab smtp/tomlinson.internal.example.com

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 the mail server for mail submission. For example, Apple Mail supports this method of authentication. You’ll need to tell it that you are using GSSAPI as the authentication mechanism.

Kerberized SMTP server accounts - Apple Mail

Note that Apple mail also allows for specifying a client certificate which can also be used for authenticating to the server to have it deliver mail.


2 thoughts on “[Network Administration] : Kerberized Postfix

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s