AAA: Authentication, Authorization and Accounting

Introduction

From an administration point of view you would like Windows, Mac OS X and GNU/Linux to access the network from a centrally managed and maintained system. The holy grail would be a single system that maintained the user information, while still being diverse enough to accommodate the different needs (like software updates, user policies, etc.) of the different systems.

Next to that it would be very user friendly if we could have a single-sign-on system, instead of having users memorizing (they don't write passwords down, do they?) a bunch of passwords for all the different services they use.

AAA

The basis for interoperability is AAA, which stands for authentication, authorization and accounting.

Authentication: is the process of checking that the identity that is being claimed is actually true. Meaning that if I say that I am Dennis Leeuw, there has to be some proof that I really am Dennis Leeuw. In real life this is easy. When I ordered my passport from the government, they checked if I was truly the one I claimed to be. So now wherever I go I take my passport with me to help me get into airplanes etc. My passport is my ticket (proof of who I am) to the world. In most computer systems you have a user name and password that tries to accomplish the same.
Authorization: is the process of giving access to services. Which means checking if I have access to e.g. a building during certain hours. To stay within my previous analogy, as soon as I come the passport check at the airport, they do not only check that I am who I claim to be but they also ask for my airplane ticket. Which means they check that I am allowed to use the airport service. In the computer world this is a bit more complex, here we have to deal with UIDs, GIDSs and access rights, but the principal is the same.
Accounting: is keeping track of the things I did. For the airplane company that would mean, they will check if I am on the plane, or that they have to unload my luggage. In the computer world it means that systems have to write to log files to keep track of what happened, so e.g. a human can have a look.

Since both Mac OS X and GNU/Linux are UNIX based, they should be the most flexible in their solutions. So we first had a look at Windows with Active Directory. Active Directory is built around LDAP and Kerberos, which both have their free and open source counter parts and Apple has the Open Directory product. So making MS Kerberos inter operate with both GNU/Linux and Mac OS X should be possible, after all there is a Kerberos RFC (RFC-1510), even GSSAPI is a standard (RFC-1964), thus interoperability shouldn't be an issue.

An overview of how the different systems implement the A's using kerberos and LDAP:

GNU/Linux

Windows

Apple

Product

Active Directory

Open Directory

Authorization

OpenLDAP (NSS)

MS LDAP (AD)

OpenLDAP (NSS)

Authentication

MIT or Heimdal Kerberos V.4 and V.5 (PAM)

MS Kerberos (AD) V.5

MIT Kerberos (own or existing realm) V.5 (PAM?)

Non-kerberized

SASL/GSSAPI

SSPI (MS GSSAPI with extensions and very Windows-specific data types.)

SASL

	GNU/Linux	Windows	Apple
Product		Active Directory	Open Directory
Authorization	OpenLDAP (NSS)	MS LDAP (AD)	OpenLDAP (NSS)
Authentication	MIT or Heimdal Kerberos V.4 and V.5 (PAM)	MS Kerberos (AD) V.5	MIT Kerberos (own or existing realm) V.5 (PAM?)
Non-kerberized	SASL/GSSAPI	SSPI (MS GSSAPI with extensions and very Windows-specific data types.)	SASL

The authentication solution: Kerberos

Kerberos is a software suite designed by the M.I.T. (http://www.mit.edu/kerberos.html). They solved in 1989 a very complex part of authorization; how do you make sure that someone is who he claims to be in our automated world.

This scheme was picked up by Microsoft for their Active Directory server and also by Apple for their Open Directory server. This means that the desktop systems we are interested in all support Kerberos in one way or the other. This makes it the ideal starting point for our purposes.

The kerberos system is tied to the different services by PAM to have a general abstraction layer. There are currently two major implementations, one used by Debian based systems (http://www.eyrie.org/~eagle/software/pam-krb5/) and one used by Red Hat based systems (http://pam-krb5.sourceforge.net).

The authorization solution: LDAP

OpenLDAP is an open source implementation of the Light Weight Directory Access protocol. To use LDAP for authorization purposes we need to add LDAP support to the Name Service Switch. On Red Hat based systems the implemention of PADL Software Pty Ltd is used (http://www.padl.com/OSS/nss_ldap.html), on Debian also the spin-off is available (http://arthurdejong.org/nss-pam-ldapd/).

The accounting solution: ?

Still a part to solve