[Network Administration] : Postfix and LDAP recipients

Given that I’ve already put my addresses into the LDAP directory, I’m going to use that to pull my recipients for local delivery. There is information on the Postfix website, here and here.

Appropriate section of /etc/postfix/main.cf

# DELIVERY CONFIGURATION
#
# all main to the domain is slated for local delivery
mydestination = $mydomain, $myhostname, localhost.$mydomain, localhost
# Set aliases to the postfix configuration directory
alias_maps = hash:${config_directory}/aliases
alias_database = hash:${config_directory}/aliases
# Local recipients are stored in ldap
# Alias maps also needs to be added here to accept mail for aliases locally
local_recipient_maps = ldap:${config_directory}/ldap-recipients.cf $alias_maps

The file ldap-recipients.cf file has the information to connect to the LDAP server.

server_host = <SERVER>
search_base = ou=users,dc=example,dc=com
version = 3
query_filter = mail=%s
result_attribute = uid
start_tls = yes
tls_require_cert = yes
tls_ca_cert_file = <CA certificate chain>

We require the verification of the LDAP certificate, so we need to specify the certificate chain.

[Network Administration] : Kerberized IMAP

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.

GSSAPI

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 “imap” service.

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 smtp and 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.

Kerberized IMAP server accounts - Apple Mail

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 “host” service.

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.

[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.

GSSAPI

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.

# SASL CONFIGURATION
#
# 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.

# TLS CONFIGURATION
#
# 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.

# ACCESS CONTROL CONFIGURATION
smtpd_client_restrictions =
	permit_mynetworks,
	permit_sasl_authenticated,
	permit_tls_clientcerts,
	reject

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

#/etc/postfix/sasl/smtpd
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.

[Network Administration] : Ubuntu and encrypted swap space

Installing Ubuntu 14.04LTS, I’ve gotten the following error:
the disk drive for /dev/mapper/cryptswap1 is not ready yet or not present
The message is annoying, but worse, the swap partition is not encrypted.
I was able to get around this by editing the /dev/crypttab to list the /dev/ path to the drive instead of the UUID in the cryptswap1 entry:

# 				
cryptswap1 UUID=2f36a43f-0d3e-4c2e-92ad-ac12603c1ff0 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

was changed to:

# 				
cryptswap1 /dev/mapper/cerf--vg-swap_1 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

I still get the message, but the swap space is encrypted now.

cerf:~> sudo swapon --summary
Filename				Type		Size	Used	Priority
/dev/mapper/cryptswap1                  partition	8314876	0	-1