Steel /stēl/ Verb: Mentally prepare (oneself) to do or face something difficult.

Vagrant.configure("2") do |config|

  if Vagrant.has_plugin?("vagrant-triggers")
    config.trigger.before :destroy do
      info "Removing system from RHSM if it is registered."
      run_remote "/usr/sbin/subscription-manager unregister"
    end

   config.trigger.after :up do
     info "Registering system to CU Boulder Satellite in the Vagrant Organization."
     run_remote "rpm -Uvh http:///pub/katello-ca-consumer-latest.noarch.rpm && subscription-manager register --org '' --activationkey ''"
    end
  end
end

certutil -L -d /etc/pki/nssdb/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

IPA CA                                                       CT,C,C
IPA Machine Certificate - host.example.com                   u,u,u

On FreeIPA, Postfix and a Relaying SMTP Client

I wanted to configure a number of my hosts to relay all their e-mail through an SMTP gateway that was already configured to allow Kerberos authentication (GSSAPI). The problem was, the SMTP clients were all over the internet IP space (both IPv4 and IPv6). Opening up subnets to allow relaying didn't seem like the smartest idea, as in some locations I didn't control all of the subnet, and opening up for each individual IP was a real pain and would not scale well. So I turned to using authentication in the Postfix SMTP client.

Relaying using authentication in the Postfix client is possible using name/password maps. However, I wanted to use Kerberos (GSSAPI) for the client authentication. Using Kerberos allows me to centrally control the resources. If a machine were to walk off my network, I can revoke all the Kerberos credentials associated with that machine, and it will no longer function. Besides, Kerberos is just sexy.

However, Kerberos being Kerberos, this configuration is a bit trickier and less straightforward than most. It took some back and forth with some helpful users on the Postfix e-mail list who eventually pointed me in the right direction. The following documentation is the result of that work.

Be forewarned, there may in fact be more efficient ways to do this. If you know of some, please post them up in the comments section.

Environment:

• RHEL 6.4 x86_64 systems.
• Red Hat IPA Server (FreeeIPA) version 3.0 (although just a straight Kerberos back end would work as well).
• Postfix 2.6.6
• SELinux is enabled and in enforcing mode

Our infrastructure will be very basic, an SMTP client host, an SMTP server, and an IPA server. We will have client.example.com, smtp.example.com, and ipa.example.com. The IPA server is just acting, in this instance, as a simple Kerberos server, so you can substitute your own Kerberos server there and not use IPA if you need.

smtp.example.com and client.example.com, are already tied into the IPA infrastructure. For our purposes this just means that they can easily use Kerberos.

Your mileage may vary with other environments, the general principals should be the same, however, the specifics of the Postfix configuration and file locations are apt to change.

Server Configuration:

Configuring a Postfix mail server to use Kerberos is a well documented process, so I will not cover the steps required for that configuration here. With my specific server configuration all authentication must be done over TLS. This is probably the only thing that is different than most standard configurations.

A regular connection to the SMTP server does not advertise authentication:

telnet smtp.example.com 587
Trying 192.168.1.100...
Connected to smtp.example.com.
Escape character is '^]'.
220 smtp.example.com ESMTP Postfix
EHLO example.com
250-smtp.example.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

However using STARTTLS you get the authentication advertisements:

openssl s_client -host smtp.example.com -port 587 -starttls smtp -quiet
depth=0 O = EXAMPLE.COM, CN = smtp.example.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 O = EXAMPLE.COM, CN = smtp.example.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 O = EXAMPLE.COM, CN = smtp.example.com
verify error:num=21:unable to verify the first certificate
verify return:1
250 DSN
EHLO example.com
250-smtp.example.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-AUTH PLAIN GSSAPI LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN


Client Configuration:

Install Postfix:

Postfix must, of course, be installed and running on the client host.

sudo yum install postfix


Modify Postfix's Configuration:

After installation, we modify the /etc/postfix/main.cf file and add the directives needed for the SMTP client configuration:

smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_session_cache_database = btree:${data_directory}/smtp_tls_session_cache
smtp_tls_security_level = secure
smtp_tls_mandatory_ciphers = high
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_mechanism_filter = gssapi
relayhost = smtp.example.com
import_environment =
                     MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ LANG=C
                     KRB5CCNAME=FILE:${queue_directory}/kerberos/krb5_ccache

We will go through these directives individually:

• smtp_tls_CAfile: This points to a file containing the Certificate Authority (CA) certificates. By default the location listed above is the central CA location for RHEL systems. This will allow the SMTP client to verify the authenticity of the cert presented to it upon connection if the certificate is signed by one of the well known CAs in the file. If you are using self signed certificates issued by the IPA CA you will need to add the CA certificate to the ca-bundle in order for TLS verification to work.
• smtp_tls_session_cache_database: This btree file keeps a cache of the TLS information for connections allowing easier build up and tear down of connections.
• smtp_tls_security_level: This directive sets the security level for the TLS session. We choose to use secure here. Because we control both the client and the server verification of certificates should work. As well, we are forced to use the secure option because otherwise the session may be hijacked as GSSAPI inside of TLS does not perform channel binding which may allow session hijacking.
• smtp_tls_mandatory_ciphers: This directive sets the ciphers we choose to use for communication between the client and the server. We set this to high on the assumption that because we control both the client and server these ciphers will work. Because we don't have to inter-operate with the larger internet we can be much more restrictive in terms of what we will allow.
• smtp_sasl_auth_enable: This enables SASL authentication for the SMTP client, it also necessitates the next directive being in place.
• smtp_sasl_password_maps: This directive points to the hash mapped location of the SASL password file, we will configure that file in the next step.
• smtp_sasl_mechanism_filter: This directive is probably not strictly necessary. The client and the server will look for authentication methods that they both share by default, however this will assure that only GSSAPI (Kerberos) is used.
• relayhost: Of course this points to the location for e-mail to be relayed through.
• import_environment: This directive sets a number of environmental variables to be imported and passed to the SMTP client. Most important is the KRB5CCNAME, which points to the location of the Kerberos credential cache. The other variables are just the defaults that are normally imported.

Create the SASL Password Map:

We now create a mapping of host names to the associated credentials. This file needs to exist, however, in our case the credentials don't really matter as that is handled by Kerberos.

Edit /etc/postfix/sasl_passwd:

#Destination                Credentials
smtp.example.com            gssapi:nopassword
smtp.example.com:submission gssapi:nopassword

Though there is no real sensitive information in this file, it is always best to restrict access unless needed. Because Postfix accesses this file before it drops its privileges, you can set the ownership to root. So we change permissions to root:root, and set the permissions to mode 640:

sudo chmod 640 /etc/postfix/sasl_passwd
sudo chown 0:0 /etc/postfix/sasl_passwd

Run postmap to convert the file to a hash DB:

sudo postmap hash:/etc/postfix/sasl_passwd


Create and Retrieve the keytab:

There is nothing really special about using IPA in this section, I am simply relying on the IPA convenience tools. If you are running a straight Kerberos environment you can do the same thing easily using kadmin.

Make sure that you have a ticket as a user that has admin privileges in IPA, or as the admin user.

ipa service-add smtp/client.example.com

Retrieve the keytab:

ipa-getkeytab -s ipa.example.com -p smtp/client.example.com -k smtp.keytab

Move the keytab into the proper location and set the ownership and permissions:
There is no standardized Kerberos keytab location on the system (that I know of) so I tend to create an /etc/keytabs directory and store the keytabs there. You can place your keytabs wherever you like as long as the permissions are correct and SELinux doesn't deny access.

sudo mkdir -m 755 /etc/keytabs/
sudo mv smtp.keytab /etc/keytabs/
sudo chown postfix:postfix /etc/keytabs/smtp.keytab
sudo chmod 440 /etc/keytabs/smtp.keytab
sudo restorecon -Rv /etc/keytabs/


Create the Credential Cache:

Create a location for the Kerberos credential cache to exist. Placing it in /var/spool/postfix/kerberos/ works with the current SELinux policy. Below is the policy directives allowing access to the postfix_spool_t label:

sesearch -s postfix_smtp_t -t postfix_spool_t --allow
Found 2 semantic av rules:
allow postfix_smtp_t postfix_spool_t : file { ioctl read write getattr lock append open } ;
allow postfix_smtp_t postfix_spool_t : dir { ioctl read getattr lock search open } ;

So we create /var/spool/postfix/kerberos/ and chown it to postfix:postfix mode 755:

sudo mkdir -m 755 /var/spool/postfix/kerberos/
sudo chown postfix:postfix /var/spool/postfix/kerberos/


Create the Kerberos Cron Job:

You now need to add in a cron job running as the postfix user to update the tickets using the keytab:

sudo crontab -u postfix -e

This cron job fetches a ticket granting ticket (TGT) on system reboot and once every 12 hours. My policy allows for Kerberos tickets to be valid for 24 hours so this is a bit of overkill. cron contents:

@reboot kinit -c FILE:/var/spool/postfix/kerberos/krb5_ccache -k -t /etc/keytabs/smtp.keytab smtp/$(uname -n)
* 0-23/4 * * * kinit -c FILE:/var/spool/postfix/kerberos/krb5_ccache -k -t /etc/keytabs/smtp.keytab smtp/$(uname -n)

There may be a more concise way to express this in cron, but I don't know it.

At this point you should have a /var/spool/postfix/kerbers/krb5_ccache file owned by the postfix user. If you don't, you are going to need to trouble shoot what happened. Try running the kinit command above using sudo and see if the file appears, check /var/log/messages for any errors.

All the constituent parts are now in place. Restart Postfix on the client system and test.

sudo service postfix restart


Test:

At this point your mail client should be configured to use Kerberos for authentication against your mail server. Assuming your mail server is properly configured, things should just work.

Attempt to send a test e-mail from the client host and check /var/log/maillog on both the client and the server for any messages. If Kerberos authentication is working properly you will see the authentication type listed as gssapi on the SMTP server.

If things are not working, a handy way to get a real low level view of exactly what is going on is with the use of debug_peer_list directive in /etc/postfix/main.cf. You add this directive in and reload Postfix, from the server side you will see exactly what commands are being received and vice versa on the client side:

#For the client
debug_peer_list = smtp.example.com
#For the server
debug_peer_list = client.example.com


Fin.