[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]: Kerberized SSH

At this point, most of the infrastructure is in place. Now I could tie some other services together with this infrastructure. For my servers (not the kerberos KDC and LDAP directory), I’ve configured kerberized SSH. It’s a good starting point to see the benefits of single sign-on. Continue reading “[Network Administration]: Kerberized SSH”

[Network Authentication]: OS X Kerberos Authentication and LDAP Authorization

I’ve also enabled Kerberos authentication and LDAP authorization on my OSX machine in addition to Linux machines. OSX supports Kerberos out of the box and deploys it for authentication against an OSX server. Also, the native OpenDirectory implementation is OpenLDAP, so we should be able to talk with our LDAP directory. Additionally, we’ve generated the directory entries with the records that we’ll need for OSX authorization, we just need to enable it. Continue reading “[Network Authentication]: OS X Kerberos Authentication and LDAP Authorization”

[Network Administration]: Linux Kerberos Authentication and LDAP Authorization

Once principals are added to the Keberos Database, and the account information is added to the LDAP directory, then the client Linux machines can be configured to access the information and allow for network accounts to be used. Continue reading “[Network Administration]: Linux Kerberos Authentication and LDAP Authorization”

[Network Administration]: Kerberos Authentication Service

First thing that I need is a system for authentication. This means a method where systems can verify the identity of anything that wants to access services. This is different than authorization, which will determine what services are granted access. I’m just saying services instead of machines since being able to log into a machine does not necessarily mean that the user would have access to every service that a machine can provide. I’ll be using a system developed at MIT called Kerberos. Continue reading “[Network Administration]: Kerberos Authentication Service”

[Network Administration]: Revamped Network Infrastructure

In the past couple of weeks, I’ve revamped my local network and how it’s tied together. I’ll document the steps here on the site. There are a number of pieces that were added to what I’ve described before.

One of the goals was to separate out some of the more security critical pieces from machines that provide services either available on the local network, or providing services on the internet. Security was one of the things that i didn’t like about how it was set up previously. Also, it was hacked together more than i would have liked.

Here are some of the pieces and I’ll describe each of them in later posts.

  • DNS:
    DNS or Domain Name System, in addition to other things, associates domain names and other information with ip addresses. This allows translation of computer names to their appropriate address so that they can be located on a local network, or on the internet. It also provides information for other services such as email routing, and kerberos servers
  • Kerberos authentication:
    Kerberos is an authentication protocol that works on the principal that a third party will verify the authenticity of a client and server to each other in a secure and encrypted manner.
  • LDAP directory:
    LDAP is a directory which stores the account information and determines authorization to different services. It is general purpose, and can also store other information for dissemination to machines on our network. It will provide information about users and group accounts among other information.
  • Network Accounts: Our directory will need to be populated with the proper network account information.
  • Client configuration: Our machines will need to be configured to access the proper servers for both Linux and OSX. Also, client machines are configured to load networked directories based on autofs maps in our LDAP directory.
  • Kerberized SSH: Once we have the accounts configured we can use enable kerberized SSH to allow for remote access to servers using our kerberos tickets to connect. This allows us to connect without having to always enter a password or provide a public key, but rather use our tickets to authenticate us.
  • Kerberized Postfix MTA: I’m using the kerberos authentication to allow for submission of mail for delivery by my mail clients.

Some notes about the setup. I’ve moved the more – what I would call – critical services to their own machine. For this I’m using a very lightweight machine. A Zotac ZBOX nano AD11.

ZOTAC ZBOX AD11

For what I’m thinking of using it for, it’s perfect. It takes up almost no space and I’m planning on having the machine on all of the time, but not being used all of the time. Also, I’m not planning on using it for anything that would be considered a heavy load. It has a tested power consumption of 11W at idle, and that’s the main thing that I’m looking for. And its really quiet, despite what the reviews say. It has 64GB of disk and built in gigabit Ethernet which is fast and easy.