 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.
|
