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

[AWS] Mail Relay

I got my AWS account up and running.

Getting set up

First, I got an AWS account on the site. It was pretty easy, and free to start. I don’t expect to have any issues in terms of compute time, so it should be really cheap.

I did use IAM to setup some other accounts so that I don’t need to use my AWS account every time I wanted to log in. There is a user guide here. Following that, I gave myself an admin account that I could then use to administer everything else. I’m planning on using it for some other items than just an MTA, so I wanted to separate them.

After getting my accounts setup, I needed to find a suitable AMI to run. What I eventually want is an Ubuntu image that I can load postfix onto. There is a Ubuntu community page to find a suitable image to run on the EC2 machines that you can search by release. There are a number of official releases that they provide for EC2 use. I’m using ami-1cf1db59, which is a 64-bit 12.04 LTS release

Now that I’ve picked out my AMI, I launched it into their farm. My account only supports VPC, so that’s where it’s going. I just used the web console for this. I selected a t1.micro machine. At the end, I got a key pair(.pem RSA private key) that I downloaded to my machine. I’ll need that in a little bit.

[Update]: You can also bring up a new AMI from the command line using a command like:

$EC2_HOME/bin/ec2-run-instances ami-acf9cde9 -g <SECURITY_GROUP> -k <KEY_PAIR>

[Update]: For t1.micro instances, you’ll have to pass it on the command line as the m1.small instance is the default:

$EC2_HOME/bin/ec2-run-instances ami-acf9cde9 --instance-type t1.micro -g <SECURITY_GROUP> -k <KEY_PAIR>

The key pair is the one that will be loaded that allows you to SSH into the instance. You will need to create one beforehand. You can do this with the ec2-add-keypair command. The security group describes the ports that are open. If you are using the default, you may need to open ports to communicate with it. You can use the command ec2-authorize, or ec2-modify-instance-attribute to change the security group after the fact. Note, if you use ec2-modify-instance-attribute to change the security group, you need to give it the ID, and not the name. You can get the ID from the ec2-describe-group command.

Getting the command line working

It took me a while to get the command line tools working. I installed the EC2 command line tools which I got from the Amazon website. It doesn’t have any real instructions. There are some on the web that you can find.

I had to add some information into my csh environment.

AWS stuff
# Tell it where java is
setenv JAVA_HOME /usr
# Optionally, set up paths for command line tools.
setenv AWS_HOME /usr/local/aws
setenv EC2_HOME $AWS_HOME/ec2

# Setup ec2 wide env
setenv EC2_URL https://ec2.us-west-1.amazonaws.com

# Load the access keys into the environment for EC2 command line tools.
setenv AWS_ACCESS_KEY
setenv AWS_SECRET_KEY

Most of the stuff that I found on the web used EC2_PRIVATE_KEY and EC2_CERT, but according to the EC2 user guide, these are deprecated, and should no longer be used. The new options to use AWS_ACCESS_KEY and AWS_SECRET_KEY instead. Personally, I find this a little annoying as this means that my keys are in my environment instead of read from a file.

I did have to add the EC2_URL env variable so that I can connect with the us-west-1 server farm which I’m using. The default is the east coast one. I’m in California, so it’s the closest to me.

IP addresses

I got an elastic IP address from amazon. I can now assign this to my instance. This is a static IP address that is associated with my account. I can move this from instance to instance as I need. It’s kinda like a static IP address that I get from Amazon that I can use as I see it.

I got an EIP with the allocate address command
ec2-allocate-address -d vlc

I had to add the VPC option as the domain since that’s what I’m using.
I then associate this with the instance
ec2-associate-address -i <INSTANCE-ID> <IP_ADDRESS>

The address in the command above is what is returned from the allocate address command in the previous step. The instance ID can be determined either from the EC2 web console, or from the ec2-describe-instances command.

After this, I updated my DNS records for my domain to point at the EIP that I associated with my running instance.

Getting into the machine

I can now ssh into my machine.
ssh -i <PRIVATE_KEY> <USER@SERVER>

The private key is what was generated when the instance was started. It should be a .pem file. In my case the user to log in was “ubuntu”, but it probably depends on the image that you’re using.

apt-get install postfix
configure as internet to smarthost

http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall

References