Cover V10, I12

Article
Sidebar

dec2001.tar

Integrating Windows 2000 and UNIX Using Kerberos

Alex Withers

More systems administrators than ever work in a heterogeneous computing environment, and it has recently become more complex to integrate hosts into such a mixed environment. One of the main reasons for this increased complexity is because of the explosion of Microsoft and Linux products in the data center. Linux doesn't have problems talking to existing UNIX machines, and Novell has helped Linux by developing a client for their software, but if you want existing Linux or UNIX machines to talk to a Microsoft box, you may run into trouble. (Samba has been one of the options for integration, however it is not a Microsoft-supported product. Nonetheless, Samba works great and can accomplish many needs in the integration of Windows and Linux/UNIX machines.)

With Windows 2000, we saw an effort on Microsoft's behalf to help integrate their products into UNIX environments. Some would argue that Microsoft's efforts have been dubious at best and that Microsoft has ulterior motives. Although the latter may be true, the first is not altogether accurate. Windows 2000 boxes can indeed talk to UNIX-type boxes when authentication is needed, because Microsoft has adopted the Kerberos standard as its authentication mechanism. Therefore, in an ideal situation, Windows 2000 clients can authenticate to a Kerberos box, and a UNIX client can authenticate to a Windows 2000 Active Directory server. However, I found little or no documentation to get a UNIX box to authenticate to a Windows 2000 box.

In this article, I will show how to get UNIX to authenticate to a Windows 2000 box using Kerberos 5. By "UNIX", I am referring to the platforms on which I have successfully tested and implemented this -- mainly Red Hat Linux 7.1 and HP-UX 11.0. Because Kerberos 5 is standard across all UNIX-style platforms, these examples should work on all platforms of UNIX, distributions of Linux, and open source BSDs. (The only caveat involves the configuration of PAM because that varies by platform and distribution; some platforms, such as OpenBSD, don't even use PAM by default.)

This article also focuses more on the Linux and UNIX side of things than Windows 2000, which means I will discuss getting UNIX and Linux machines to authenticate as clients to a Windows 2000 Active Directory server. For those familiar with Kerberos, the Windows 2000 box will be the KDC (key distribution center). If you're not familiar with Kerberos, this article only requires a working knowledge. See the Kerberos sidebar, read David Smith's article "Implementing Kerberos" in this issue of Sys Admin, or visit MIT's Kerberos site:

http://web.mit.edu/kerberos/www/
This article assumes that you've set up a Windows 2000 Active Directory server according to your needs. Nothing needs to be done during the install or setup, so presumably any AD server will work for this task. Practically speaking, you will want your Domain Controller to be your KDC, because this is where the accounts will reside. I will use an example AD domain "SOMEPLACE.COM". This is the top-level name space for my example AD setup. There is only one AD server in this example, and its DNS name is "ad.someplace.com" with an IP address of "10.0.0.1". Note that the AD domain "SOMEPLACE.COM" is also the Kerberos realm. The Kerberos client (our UNIX-type box) will be called "client.someplace.com" with an IP address of "10.0.0.2", and we will set it up to authenticate to the AD server.

Setting up the AD server is simple and only requires a couple of steps. Each UNIX machine that is going to authenticate using Kerberos 5 must have a user account on the AD server. Simply add a user and make sure its first name and login name are the host name of that UNIX machine. Make sure the correct domain is selected in the field next to the login name. For our example, the UNIX machine "client" would get a first name of "client", a login name of "client@someplace.com", and "mypass" as a password. Now that the account has been created, the next step is to generate the keytab file. You must first make sure that the Kerberos configuration utilities are installed; it's the package found on the Windows 2000 distribution media under the support/tools directory. To install the package, simply run "setup.exe". This package will give you one utility in particular -- Ktpass. Simply open a command shell and change to the root directory. The following command will create a keytab file:

C:\> Ktpass -princ client/client@SOMEPLACE.COM -mapuser client -pass
mypass -out client.keytab
This creates the keytab file and places it in your root directory. Notice that the principle (denoted with the -princ argument) has a root that is "client", an instance "/client", and the realm "SOMEPLACE.COM". It is important to make sure that the realm is typed in all caps. Now that the keytab file has been generated, it needs to be transferred securely to "client.someplace.com".

Next, we configure the UNIX machine, "client.someplace.com". The first step is to create an /etc/krb5.conf file. Any UNIX machine using Kerberos 5 should have an example file in place, but creating the file is simple. This file is the main configuration file for all Kerberos 5 applications that use the Kerberos 5 library. It contains vital information such as the location of TGSs (Ticket Granting Service) and KDCs (Key Distribution Center). The file is divided into sections where each section is labeled with a heading ([heading]). Under the headings, we have tag = value and tag = {subtag = value ... etc.}. The first section in the file should be the "libdefaults" section. In this section, we specify some simple configuration options that, in our example, would look like:

[libdefaults]
      default_realm = SOMEPLACE.COM
      dns_lookup_realm = true
      dns_lookup_kdc = true
      default_tkt_enctypes = des-cbc-md5
      default_tgs_enctypes = des-cbc-md5
As mentioned above, the AD domain SOMEPLACE.COM is also the realm. Specify the realm by using the "default_realm" tag. The other tags are pretty self-explanatory -- use DNS to look up names and tell the libraries which default encryption technique is to be used. The next section, "realms", is defined in order to configure the realm specified earlier:

[realms]
     SOMEPLACE.COM = {
                 kdc = ad.someplace.com:88
                 kpasswd_server = ad.someplace.com:464
     }
There's not much to this. We're specifying where the KDC can be found for our default realm. Notice that it is the address of the AD server followed by a port number. This is where the tickets are issued, and thus the KDC in this example is the TGS. We also specify the address of the kpasswd server followed by a port number. This will allow users to use the "kpasswd" utility for changing their Kerberos passwords. It is also be a good idea to make sure that these ports exist in your /etc/services file:

kerberos      88/tcp        kerberos5 krb5  # Kerberos v5
kerberos      88/udp        kerberos5 krb5  # Kerberos v5
kpasswd      464/tcp        kpwd            # Kerberos "passwd"
kpasswd      464/udp        kpwd            # Kerberos "passwd"
There is one more section necessary before configuration is finished. This section, called "domain_realm", is used for translation. It contains relations that map subdomains and domain names to a Kerberos realm name. For example, on the host "foo.someplace.com", notice that the host name does not contain the subdomain "HR.SOMEPLACE.COM" (which happens to be the realm). So, we need to provide a mapping of ".someplace.com =HR.SOMEPLACE.COM". This section is very important and if it's not provided, it can cause a failure to connect to the KDC. In our example, we would use the following:

[domain_realm]
     .someplace.com = SONEPLACE.COM
This completes configuration of the client, but there are many more options available. The krb5.conf(5) man page provides more information.

It's now time to put the keytab file we generated on the AD server to use by integrating it with the client's existing keytab file. This step involves using the ktutil utility on the client. Run ktutil as root, and you should be presented with the following prompt:

Ktutil:
Integrating the keytab requires three simple steps:

ktutil:  rkt client.keytab
ktutil:  wkt /etc/krb5.keytab
ktutil:  q
Read the keytab file, write it to the master keytab file /etc/krb5.keytab, and quit the program. Nothing else is required, and Kerberos 5 should be fully operable on the client.

For a user to get tickets from the KDC, he or she must have an account on the AD server. Once the account is created and the user has logged into the client, he can now be authenticated using Kerberos. A ticket is usually granted by using the kinit utility, which requests the user's password on the AD server. A user can also change his Kerberos password by using kpasswd, which will essentially change the password used on the AD server. Consider the following scenario -- what if I wanted the user to log in using his AD login name and password so that he has one login name and password for multiple platforms? Thus, in our example, a user by the name of "jsmith" would use this login name and the same password on both "client.someplace.com" and "ad.someplace.com". The password resides on only one box, "ad.someplace.com", and the authentication method has the advantage of using a secure method. One way of doing this is by using PAM.

On UNIX systems PAM allows for multiple types of applications to authenticate a user. PAM provides an additional layer to the system so that the administrator has more control over authentication. Because most of the popular applications go through this layer, we can authenticate using Kerberos by having PAM do this for us. So when a user logs in using telnet, ftp, ssh, imap, etc., they will all authenticate with PAM, which in turn will use Kerberos behind the scenes for authentication. This three-layer model will allow all services on the UNIX box to authenticate using Keberos.

Using PAM, we are only concerned about the UNIX client, because a Kerberos server does not use PAM. The module discussed here is "pam_krb5", which can be used by PAM-ified applications to authenticate a user. You might undermine the security of your network if you allow all applications to authenticate with PAM. For example, consider a situation where a pop3 client that sends a plaintext password over the network and the pop3 server uses PAM, and thus pam_krb5, to authenticate that client. For better security, you must use Kerberized services that take advantage of GSS-API. But if you simply want a way to check passwords without worrying about security, then all applications that use PAM will authenticate through Kerberos.

Before configuring PAM, make sure that Kerberos is working by obtaining credentials from the KDC. If everything appears to be working, then it's time to configure PAM. Essentially, this is what it should look like under Linux:

auth        required      /lib/security/pam_env.so
auth        sufficient    /lib/security/pam_krb5.so
auth        sufficient    /lib/security/pam_unix.so nullok md5 \
                               shadow likeauth use_first_pass
auth        required      /lib/security/pam_deny.so
I have left this example as generic as possible since different distributions of Linux will have PAM set up differently. For instance, under Red Hat 7.x, all PAM configuration files are found under the /etc/pam.d directory. Each application has its own configuration file but they all refer to /etc/pam.d/system-auth. Check the documentation for more information on your distribution. Here I have only altered the "auth" section of the PAM configuration file. PAM acts like a stack, so the modules are run from top to bottom with the conditions in the second field. The first module simply sets up an environment. The second module, "pam_krb5", is set to "sufficient", which means that if the user authenticates with his user name and password, then it returns success and the user is able to log in with Kerberos 5 credentials. The third module is checked but since the second module is "sufficient", it really doesn't matter whether the user authenticates successfully. But if the pam_krb5 module fails, this can allow the user to log in provided that his account and password match with the /etc/passwd scheme.

Note that just because the third module is "sufficient" it doesn't mean that user doesn't need an account. Any user authenticating to the client must have an account with the same user name as on the KDC but doesn't need a password. Thus, the accounts on "client.someplace.com" should all have a "*" in the password field for /etc/passwd or /etc/shadow, etc. Otherwise, you have to change the "sufficient" field to "required" and the passwords have to be the same on both machines. For example, if "jsmith" telnets in and enters a user name and password that exists on the KDC, he will then be able to log in. If root telnets in but there is no "root" account on the KDC, then the pam_unix module will use the username and password that was given to pam_krb5. The pam_unix module will see whether the root username and password are valid and allow a login if they are. In this particular setup, the user names must be the same on all machines. All machines must also have an account for that user, but the password resides on only one machine.

Configuration on an HP-UX, FreeBSD, or Solaris box is similar to the Red Hat configuration. Here is an example snippet pulled out of the "auth" section of /etc/pam.conf on an HP-UX 11.0 box:

login     auth  sufficient /usr/lib/security/libpam_krb5.1
login     auth  sufficient /usr/lib/security/libpam_unix.1 \
                              use_first_pass
su        auth  sufficient /usr/lib/security/libpam_krb5.1
su        auth  sufficient /usr/lib/security/libpam_unix.1 \
                              use_first_pass
OTHER     auth  sufficient /usr/lib/security/libpam_krb5.1
OTHER     auth  sufficient /usr/lib/security/libpam_unix.1 \
                              use_first_pass
Depending on the configuration of your machine, there may be other entries (i.e., ftp and dtlogin) in the "auth" section. However, they should all be the same -- "sufficient" for "libpam_krb5" and "sufficient" for "libpam_unix". The path and name of the module may differ depending on machine and configuration. When configuring PAM, be sure to not inadvertently lock yourself out or create a way to bypass security. In any case, always check the pam_krb5(8) man page and the documentation for pam_krb5 and the other PAM modules that come with your system.

Once PAM is configured, test it against multiple cases that might apply in your environment. It is a good idea to thoroughly test the security of your setup before setting out for production use. Users should now be able to log in to the client using multiple services (ssh, pop3, imap, etc.) and be authenticated by a Windows 2000 Active Directory server.

Thanks

I would like to thank Greg Francis for all his help and for providing the time and equipment.

Resources

Kerberos in the Red Hat Linux 7.1 Reference Guide: http://www.redhat.com/support/manuals/ \
RHL-7.1-Manual/ref-guide/ch-kerberos.html

MIT's Official Kerberos Page: http://web.mit.edu/kerberos/www/

Microsoft's Kerberos Interoperability Page: http://www.microsoft.com/windows2000/techinfo/ \
howitworks/security/kerbint.asp

A Linux-PAM Page: http://www.kernel.org/pub/linux/libs/pam/

Alex Withers works as an intern at INEEL (a DOE lab) for the Cyber Security team. He will be returning to Gonzaga University to finish his education and then marry his wonderful fiance Anne. He can be reached at: awithers@gonzaga.edu.