sep2004.tar

UNIX and Microsoft Single Sign-On

Simon Biles

Whether we like it or not, Microsoft is making inroads into what used to be a Unix-dominated enterprise environment and has made progress in incorporating industry standards into its latest server offerings. Kerberos is now the default authentication method in Windows 2K and up, which has opened doors to a true single sign-on service for both Windows and Unix machines without the need for any third-party solutions.

The idea behind a single sign-on solution is quite straightforward. A user will authenticate once and henceforth be able to access all of the services that they are authorized to use. These services could be network disks, printers, or service programs; the concept is the same.

Kerberos was first developed at the Massachusetts Institute of Technology in 1983; it was their solution to the security of a large-scale networking project called Athena. Project Athena was a huge step at the time in terms of the networking model being used. Contemporary systems of the time were typically based on a time-sharing model of dumb terminals connected to a mainframe. Athena, however, was a client-server model that made use of the availability of processor power on desktops for the first time. This created a whole new set of problems. Previously, security had been implicit as each terminal was directly connected to the mainframe; now information traveled freely across the network, available to anyone who wished to pick it up.

The concepts behind Kerberos were first suggested in a paper called "Using Encryption for Authentication in Large Networks of Computers" (Needham and Schroder, Communications of the ACM, 1978), and the system hinges around the request, granting, and exchange of "tickets". In order to implement a Kerberos-based, single sign-on solution, it is advisable to have some background knowledge of how Kerberos works. I apologize to those of you who are up to speed on this, but I'm going to revisit it for those who aren't. This review should also clarify some of the terms used in this article, just in case you are a bit rusty.

In the beginning, a Kerberos client will contact the "Authentication Server"; this first contact is a "Ticket Request". The request contains the name of the requesting entity (the "principal"), a time stamp, a requested duration for the ticket, and the name of the "Ticket Granting Service" from which the ticket is being requested. The next stage of the transaction is the Authentication Server, which generates a "session key". This is then encrypted along with the name of the principal, the IP Address of the principal, the ticket duration, and a timestamp into a "Ticket Granting Ticket" (TGT) using the encryption key of "Ticket Granting Service" (TGS). With me so far? Good. This TGT is then encrypted again using the principal's encryption key along with the principal's copy of the session key, the name of the TGS, and the duration of the ticket (see Figure 1).

The principal receives back the above package and, because it has been encrypted with the principal's key, is capable of retrieving the data contained within. The principal now has a session key and a TGT. This allows the next stage to begin. The principal now forwards the TGT to the TGS ("Ticket Granting Service" in case all of these TLAs are getting to you) along with a time stamp encrypted with the session key and a specific request for a service to be accessed.

The TGS processes this request and responds, encrypted with the principal's key, by sending a new set of session keys, the principal name of the service requested, the duration of the ticket, and a "Service Ticket" (encrypted with the key of the service principal). The service ticket is very similar to the TGT -- it contains a copy of the new session key, the name of the principal, the duration of the ticket, a time stamp, and the IP address of the principal (see Figure 2).

Last of all, we finally get to collect on our service. The service ticket is forwarded to the service, which checks that all of the bits match up the way they should and then provides whatever is necessary. Now, where this becomes single sign-on rather than multiple sign-on is in the "Ticket Granting Ticket". Once it has been obtained, instead of requesting authentication again, this ticket is valid to obtain other services for the duration of its lifetime.

A "Key Distribution Center" is made up of three components:

1. A database of principals

2. An Authentication Server (AS) for the creation of TGTs

3. A Ticket Granting Service

In a Windows KDC, the database role is played by the active directory, and the AS and the TGS are two services that run constantly. To replace the Windows server as the primary source of authentication, a number of steps must be taken.

To begin, you must make sure that all of your system clocks are synchronized. Kerberos takes time very seriously -- this is to prevent replay attacks being carried out -- any difference of greater than five minutes will result in a complete failure of the system. Normally, Windows machines obtain their time from the Domain Controller; to change this from a command prompt on the Windows machine, execute the following command:

w32tm /config /syncfromflags:manual /manualpeerlist:<LIST>

Replace <LIST> with your choice of NTP server (either internal or external -- as long as it is the same as the one used by the KDC).

If you already have a working Kerberos setup, feel free to skip the next section; I will cover the setup of MIT Kerberos 1.3.3 on a Linux machine to provide the KDC services. The following steps lack a lot in the way of explanation, but they are taken from the Kerberos documentation, which is available from the Kerberos site below. You can find more in-depth coverage of options there.

Download the MIT Kerberos source code from:

http://web.mit.edu/kerberos/www/

Decompress the source, configure using ./configure, make and make install.

There are two significant configuration files that are installed -- /etc/krb5.conf and /var/Kerberos/krb5kdc/kdc.conf. For the purposes of this simple example, the only changes that need to be made are in the krb5.conf to change the names of the Kerberos servers (kerberos.example.com and admin.example.com) to the name of the machine on which you are running Kerberos. Once this is done, you need to initialize the Kerberos database (as root):

kdb5_util create -s

You'll get an initialization message and will be prompted for the master key. Don't forget what you type here! Loss of this password will result in the loss of your Kerberos realm. Conversely, don't make it dumb; if someone else gets this password, all your security will be lost.

Now we will use the kadmin tool to create an admin user. Start a local version of kadmin by typing:

kadmin.local

(Until you start the kadmind daemon, you will be unable to use plain kadmin, as it will have nothing to which to connect). Add in a new administrative principal by entering:

addprinc user/admin

where user is the username that you want to use. Enter and confirm the password when prompted. To get out of kadmin, type:

quit

Now you need to kick off the KDC process, type:

krb5kdc

Check that all is running well by typing:

kinit user/admin

using the username you created earlier -- this should sort you out with a TGT for that principal. Still with me? Good.

The next step is to create a keytab file; without this you can't start kadmind. Start kadmin.local again and, at the kadmin prompt, type:

ktadd -k /var/kerberos/krb5kdc/kadm5.keytab kadmin/admin kadmin/changepw

Exit kadmin by typing "exit" at the prompt and start kadmind by typing:

kadmind

Okay, you now have a KDC capable of answering authentication requests. So, how do we make this the central location for MS Client authentication? To begin, you need to install a tool called ksetup. Ksetup was part of the Windows Server 2003 Resource Kit available from Microsoft and is compatible with XP and 2000. However, in Microsoft's infinite wisdom it seems to be no longer. I scanned the Web and found it available for download, and a copy is available at:

http://www.computersecurityonline.com/kerberos/

To authenticate, there must be a principal for the computer in the KDC. To create this on the KDC, type:

kadmin -q "ank -pw password host/domain-name"

where password is the password for the new principal, host is the name of the machine, and domain name is the domain of the machine. Now, on the Windows machine, enter the following to set up the Kerberos configuration. Set the realm name:

ksetup /setdomain EXAMPLE.COM

where EXAMPLE.COM is the name of your Kerberos realm. Then add the KDC server:

ksetup /addkdc EXAMPLE.COM kerberos.example.com

With the name of your realm and your KDC server in the relevant places, set up the machine's password as specified in the previous step:

ksetup /setcomputerpassword password

You must reboot the machine for these settings to take effect. You'll need to log in as Administrator on the local machine until you can configure the user mappings. To do this, type:

ksetup /mapuser * *

This will map principals to local accounts of the same name. At this point, you should have a single sign-on solution. Logging onto the Windows will now query the Kerberos realm for authentication, and Kerberos tickets will be issued.

Your single sign-on solution is now complete; this will provide access controls to any services or resources that are protected by the Kerberos system. Older Windows resources, however, that use the older NTLM (NT Lan Manager) security system will be oblivious to Kerberos. Normally, the Windows 2003 Server would deal with these older clients through an NT domain controller emulator. However, you would have to configure a Samba server on Unix. The 2003 Server also passes out information stored in the Active Directory with regard to local and group security policies and other Windows-specific settings.

Microsoft, however, has decided to embrace standards, and the Active Directory is an LDAP server. The schema of the Active Directory is available for download from Microsoft, and as such it is possible to implement it in any LDAP server. The latest versions of Samba also have some support for Active Directory emulation as well. I hope this will allow you to keep the Microsoft wolf away from your Unix-based door for a bit longer.

For further information, I suggest reading the Kerberos Documentation, the Microsoft document "Building Security and Directory Solutions for Unix Using the Windows Server 2003 Active Directory Kerberos and LDAP Services" available from the Microsoft Web site, the Samba documentation, and the OpenLDAP documentation.

Simon Biles is the Director of Computer Security Online Ltd., an infosec and Linux consultancy based in Oxford, England. Simon will be lecturing at ISESTORM in Las Vegas in October 2004. For more information, or to download any of the things mentioned in the article, please visit: http://www.computersecurityonline.com.