In this section we provide a quick overview of the software needed for our setup.
The first piece of our puzzle is Kerberos. Right now there are two open source implementations of Kerberos: Heimdal and MIT Kerberos. Heimdal is an implementation of the Kerberos protocol implemented by KTH (Royal Institute of Technology in Stockholm), while MIT Kerberos is provided by MIT (Massachusetts Institute of Technology) as its name implies.
As we have explained in the introduction, Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography, so a client can prove its identity to a server (and vice versa) across an insecure network connection. After a client and server has used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business.
Why have we chosen Heimdal instead of MIT Kerberos?
Heimdal supports storing its database in LDAP, so we can centralize all our data in just one place, and what is more, we will be able to create a new Kerberos principal just creating the appropriate entry in LDAP.
MIT has been historically problematic regarding threading issues, although this seems to be changing in their later releases.
Kerberos will provide us with an authentication protocol, but what about authorization information? We still need to store this information in a centralized manner to ease out administration tasks. This is where LDAP comes into place. We will be using LDAP as a directory service where we will store the information regarding all the users in our network, including the typical Unix/Linux account information.
OpenLDAP is an open source implementation of the Lightweight Directory Access Protocol (LDAP). The suite includes:
slapd - stand-alone LDAP server
slurpd - stand-alone LDAP replication server
libraries implementing the LDAP protocol, and
utilities, tools, and sample clients.
OpenLDAP has become the de facto standard in open source directory services.
Quoting from http://asg.web.cmu.edu/sasl/: SASL is the Simple Authentication and Security Layer, a method for adding authentication support to connection-based protocols. To use SASL, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If its use is negotiated, a security layer is inserted between the protocol and the connection.
In our environment SASL will be used to provide authentication support to accesses to our LDAP server. Furthermore, SASL, in combination with Kerberos, using GSSAPI (Generic Security Services Application Programming Interface) will be able to provide single sign on capabilities to all the Kerberos enabled servers located in our network.
The pam_krb5 module is a PAM module designed to allow smooth integration of Kerberos 5 password checking with applications built using PAM. We will be using this module so every user trying to access our network is authenticated against Kerberos.
The nss_ldap module is a NSS module that will let us get the authorization information (user id, groups) from our LDAP server.
Here we have the Gentoo packages with their corresponding versions used to implement the system described in this HOWTO:
app-crypt/heimdal-0.6.2-r1
The ebuild currently included in portage for heimdal-0.6.2 doesn't provide support for the LDAP integration provided by Heimdal. Furthermore, Heimdal in its current version doesn't support storing principals in several directory levels, although this functionality will be included in the next major version of the package. I have created an ebuild that supports the Heimdal-LDAP integration via the ldap USE flag, and that patches the current heimdal sources to support storing principals in several directory levels. This ebuild is available at http://bugs.gentoo.org/show_bug.cgi?id=58799 (hopefully this will become app-crypt/heimdal-0.6.2-r2). Should you compile heimdal from sources using another distribution, you should patch the sources with the patch you may found at the URL provided. This patch will become obsolete as soon as Heimdal releases its next major version.
The current ebuild has another problem: it doesn't provide header files in the place cyrus-sasl expects to find them, so saslauthd cannot be compiled with the kerberos5 mechanism. This is also solved in the ebuild provided in the URL above.
There seems to be some problems with IPv6 stuff in Heimdal kadmind I haven't been able to solve nor clearly identify. The only solution I have found is to take away IPv6 support in the kernel and emerge heimdal with -ipv6 USE flag (that means compiling heimdal using --without-ipv6 when running configure).
app-crypt/pam_krb5-20030601
net-libs/nss_ldap-215-r1
dev-libs/cyrus-sasl-2.1.18-r2
net-nds/openldap-2.1.26
These are the versions I have used while writing this HOWTO, so the setup described in this HOWTO is guaranteed (of course read the disclaimer) to work with the versions showed above. Anyway, this setup could work with other (earlier or later) versions of these packages, although I haven't tested it.