>> continued from previous page
Scenario: POP/IMAP via Active Directory/Kerberos
The second scenario is to configure a Linux server so any connections to it via POP (Post Office Protocol) or IMAP (Internet Message Access Protocol) e-mail services will be authenticated via Kerberos to a Windows server. This allows you to set up a Linux server in a Windows domain to handle e-mail access, thus avoiding the need to buy a Windows-based e-mail solution. Several e-mail clients--such as Microsoft's Outlook Express, Netscape Messenger and Qualcomm Eudora--can be configured to use the Linux server for outgoing and incoming e-mail, and can even communicate to the server via SSL to ensure privacy of the passwords. This will work only with a Windows Active Directory domain. Our setup is shown in "POP Service Authentication via Kerberos".
Note that authenticating SSH connections via the Active Directory/Kerberos domain is just as easy as authenticating POP and IMAP connections via the SMB domain. In fact, any other authentication mechanism is just as simple (this is the ultimate value of PAM). You probably want to authenticate all services provided by the Linux server in the same mechanism, whether that is the SMB authentication for pre-Windows 2000 domains, or the Active Directory/Kerberos authentication for Windows 2000 Active Directory domains or for Kerberos domains.
To achieve this, we'll need another PAM module called pam_krb5. To make sure it's installed in a Red Hat Linux 7.2 system, run the command rpm -q pam_krb5, which should produce pam_krb5-1.46-1.
Then we need to configure Kerberos on the Linux server, but first we need some information. We must know the KDC (Key Distribution Center), which is the name or IP address of the Windows PDC. For our purposes, the KDC is pdc.domain.net. In the event of compromise of the DNS servers, you may wish to use the IP address of the KDC. We'll also use this as the Kerberos administration server.
The other thing we need to know is the name of the realm. The realm is the Kerberos equivalent to the Windows Active Directory's name, which in turn is often the DNS domain name. The Active Directory name is not always the same as the DNS domain name, but it is encouraged at PDC setup time. For our purposes the realm is DOMAIN.NET. (Realms must be capitalized.)
With this information, edit the file /etc/krb5.conf, which has a number of sections in this file. Each section is delineated with a section-name string that takes the form of [section_name]. Your /etc/krb5. conf file may have more sections than those listed here. If so, leave those sections alone. Modify or add the appropriate sections to look like "/etc/krb5.conf Settings on Linux Server," right.
Next, we need the Windows PDC to support our Kerberos PAM module. Using the Active Directory Users and Computers application, create a user account named after the client computer (not a computer account). Use the Linux server's DNS host name in the first name, full name and user logon name fields. You may want to place restrictions on the account but be sure to test your changes thoroughly.
We'll call the client machine (and its domain account) linux. You should create a new cannister/ group in the domain for these user-machines so it is clear which accounts are for actual domain users and which are these Kerberos user-machine accounts.
We'll need to install the Windows 2000 support tools, which are on the server CD in a directory called support, to run the ktpass application. It will be in \Program Files\Support Tools. This tool generates a keytab file for Kerberos services that use the Windows 2000 KDC. Run the following on a command line on the PDC:
ktpass -princ host/ linux@ DOMAIN.NET -mapuser linux -pass <PASSWORD> -out linux.keytab
Note the use of the user-machine account name linux and the realm DOMAIN.NET, as well as the password, which should be the same as the one you used when you created the linux user-machine account. The output of the program should look something like this:
Successfully mapped host/linux to linux.
Key created.
Output keytab to linux.keytab:
Keytab version: 0x502
keysize 48 host/linux@ DOMAIN.NET ptype 1 (KRB5_NT_PRINCIPAL) vno 1 etype 0x1 (DES-CBC-CRC) keylength 8 (0xa27a8af1fe67ec07)
Account has been set for DES-only encryption.
Then securely copy this file to the Linux host, storing it as /etc/krb5.keytab. The keytab file provides a mapping between what is known as a Kerberos Principle and a user in the Active Directory. Do not overwrite an existing keytab, or you'll lose other Kerberos-based access. Use ktutil to do that.
Be sure that your system clocks are synchronized (within two minutes) to the KDC systems clock. Otherwise, Kerberos authentication will fail because of clock skew errors. This can be done using an NTP (Network Time Protocol) server.
The hard part is done. The next step, configuring the POP and IMAP servers to use the Kerberos authentication, should be familiar by now. First make sure the POP and IMAP services are installed as in "Modified POP PAM Configuration".
This modification will apply both to regular POP and to POP over SSL. If you prefer IMAP, the same change should be made to /etc/pam.d/imap. If you are using the SSL variants of the protocols, there is no need to create an SSL certificate and key pair. Red Hat 7.2 ships with them. However, the certificate is what is known as a self-signed certificate, and this will cause the e-mail clients to tell their users that they do not recognize the authority of the certificate signers.
See the Red Hat 7.2 documentation for information on using a certificate signed by a universally recognized certificate authority.
Make sure that the POP or IMAP service is running by editing /etc/xinetd.d/ ipop3, /etc/xinetd.d/pop3s, /etc/xinetd.d/imap, /etc/ xinetd.d/imaps (for POP access, POP-over-SSL access, IMAP access and IMAP-over-SSL access, respectively). Make sure that each file has in it a line that says disable = no.
Then restart xinetd to activate the e-mail servers:
/etc/init.d/xinetd restart
Finally, configure your e-mail client to use POP or IMAP, either standard or over SSL, to connect to the Linux server. Again, we must ensure that the user accounts on the Linux server have been created to match those in the Windows Active Directory domain. Configure the e-mail client to send the Windows user ID and password, and you should have access to your Linux-based e-mail via your Active Directory credentials.
Jeremy Impson is an associate network engineer at the Center for Nomadic Computing and Mobile Networking at Lockheed Martin Systems Integration in Owego, N.Y. Send your comments on this article to him at jeremy.impson@lmco.com.