Kerberos in the Enterprise

Authenticating with Kerberos against Active Directory

Purpose

The purpose of this lesson is to introduce the use of Kerberos in a typical enterprise, by showing how Microsoft Windows and Active Directory use Kerberos and other IETF-standard "realm control" protocols. By using DNS and Kerberos clients available in Linux, you can explore your company's network and start down the road to understanding standards-based interoperability.

Introduction

If your company uses Windows desktops, there's an excellent chance they are also using Active Directory. And if they're using Active Directory, then you are already using Kerberos every time you log in. Furthermore, every time you change your password, you are using the Change Password protocol, which uses Kerberos. In turn, Kerberos and Change Password are directly supported by DNS and NTP. In this lesson we will use your Windows domain username and password to work with Kerberos credentials from Active Directory. Additionally, you will be able to use the Change Password protocol to change your password and explore how NTP and DNS are leveraged.

The Realm Control Protocols

First, let's start by listing the "realm control" protocols with links to their IETF RFC's. Please keep in mind that most of these RFC's have ancillary RFC's that, for example, add new features using defined extension mechanisms. The RFC's listed here are base RFC's and are recommended as good starting points.

Determining Your Realm

In Windows, there is a concept of "domain," which determines boundaries for administration of user accounts. Since Windows 2000, the concept of domain has been matched to the concept of DNS domain. Windows now uses this domain name as what Kerberos traditionally calls the "realm." Our first active task will be to determine the domain name used in Windows so that we can then use DNS to locate our KDC's.

From a command prompt in Windows, use ipconfig or the longer ipconfig/all to find your "DNS Suffix." This "DNS Suffix" is what is being used as your Kerberos realm. Please make note of the DNS Suffix. This should be the last step you need Windows for.

Using 'ipconfig':

C:\>ipconfig

Windows IP Configuration
...
Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . : EXAMPLE.COM
...

Using 'ipconfig/all'.

C:\>ipconfig/all

Windows IP Configuration

        Host Name . . . . . . . . . . . . : MYHOSTNAME
        Primary Dns Suffix  . . . . . . . : example.com
        Node Type . . . . . . . . . . . . : Hybrid
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No
        DNS Suffix Search List. . . . . . : example.com
...

Using a DNS Client to Find KDC's

Windows uses DNS SRV records to find KDC's for a given domain (realm). On Linux, we, too, can use DNS to find KDC's by using the 'dig' command. The two commands, below, demonstrate the command format required to use the realm name determined, above, to query DNS for KDC's. Kerberos supports operation over both UDP and TCP, hence the two different commands.

$ dig SRV _kerberos._tcp.example.com
$ dig SRV _kerberos._udp.example.com

If all goes well, the answer section of the DNS response will contain SRV records pointing to KDC's on your network. For example, the following snippet shows that my network has at least two KDC's supporting TCP, equal weight, and operation over the standard Kerberos protocol port '88'.

...
;; ANSWER SECTION:
_kerberos._tcp.example.com. 600 IN SRV    0 100 88 kdc01.example.com.
_kerberos._tcp.example.com. 600 IN SRV    0 100 88 kdc02.example.com.
...

Configuring Kerberos

Now we are ready to edit the /etc/krb5.conf file, where Kerberos configuration is stored. While there are many configuration options, at a minimum your Kerberos client needs to know 2 things:

1. What realm your workstation is in
2. How to find KDC's

Here is an example krb5.conf which sets our realm to EXAMPLE.COM and which lists how to find 1 KDC.

[libdefaults]
        default_realm = EXAMPLE.COM

[realms]
    EXAMPLE.COM = {
        kdc = kdc01.example.com
    }

Using DNS to Perform KDC Discovery

Since we're on an Active Directory network, we can use a technique called "KDC Discovery" which uses DNS SRV records to find KDC's. Here is the note from the man page.

dns_lookup_kdc
    Indicate whether DNS SRV records shoud be  used  to  locate  the
    KDCs  and  other  servers for a realm, if they are not listed in
    the information for the realm.  The  default  is  to  use  these
    records.

Since dns_lookup_kdc is actually the default, we don't need to list anything to configure KDC's. Here is a complete krb5.conf:

[libdefaults]
        default_realm = EXAMPLE.COM

Using NTP to Prevent Clock Skew

Kerberos requires that all clocks are synchronized. Part of the process of Kerberos credential validation is to make sure that credentials are being used with a certain window, called the clock skew. The default value is 5 minutes. This reduces the amount of time an attacker has to try a variety of attacks against Kerberos. However, it does mean that you must maintain clock synchronization between hosts on your network. Otherwise, Kerberos authentication will fail with such error messages as:

kinit: krb5_get_init_creds: Too large time skew

Fortunately, it is easy to maintain clock consistency with the ntpd server, which is available by default in most Linux distributions.

The following commands illustrate the 'ntpdate' command to perform a one-time clock synchronization.

$ sudo yum install ntpdate
$ sudo ntpdate ntp.example.com
25 Jul 16:22:06 ntpdate[DIRxSRVx10:8158]: step time server 10.0.0.1 offset 402569.951826 sec

Using Kerberos to Obtain a Ticket

Now that we've configured the realm, worked out how to find a KDC, and made sure our clocks were synchronized, we are ready to try some basic ticket acquisition with the 'kinit' command.

Open a shell and type in 'kinit'. By default, your Linux username will be appended to the realm from the krb5.conf. This means that your Linux username has to match your username in Active Directory. You can specify the username on the command line:

$ kinit hnelson
Password for hnelson@EXAMPLE.COM:

You will be prompted for your Windows/Active Directory password.

Kerberos errors are notoriously vague. One common error message occurs if you use your NETBIOS (Windows) domain name, such as EXAMPLE, when Kerberos wants the FQDN, EXAMPLE.COM.

$ kinit hnelson@EXAMPLE
Password for hnelson@EXAMPLE: 
kinit(v5): KDC reply did not match expectations while getting initial credentials

If you are using the wrong username or type in an incorrect password, you may see "Preauthentication failed ..."

$ kinit hnelson@EXAMPLE.COM
Password for hnelson@EXAMPLE.COM: 
kinit(v5): Preauthentication failed while getting initial credentials

If you don't get any message, your ticket has likely been issued. You can now use 'klist' to see details of your ticket cache.

The following command will list Kerberos V5 tickets (-5) in the user's ticket cache, with flags (-f), encryption types (-e), and addresses (-a), to give us maximum insight.

$ klist -5fea

Here's a full example:

$ klist -5fea
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: hnelson@EXAMPLE.COM

Valid starting     Expires            Service principal
01/30/07 12:55:30  01/30/07 22:55:39  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 01/31/07 12:55:30, Flags: RIA
        Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5 
        Addresses: (none)

To destroy your ticket cache you use 'kdestroy'.

$ kdestroy
$ klist -5fea
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)

Changing Your Password with Change Password

You can now use 'kpasswd' to change the password for your Active Directory user. This uses the RFC 3244 Change Password protocol. The Change Password protocol is also what Windows uses when you change your password. Similar to 'kinit', 'kpasswd' will look for Change Password servers using the 'kpasswd_server' setting in the [realms] section of the krb5.conf file under the current realm.

[realms]
    EXAMPLE.COM = {
        ...
        kpasswd_server = kdc01.example.com
    }

Since we're assuming you have Active Directory, your Change Password servers are your KDC's, in which case KDC Discovery will work. The following commands will use DNS SRV records to find Change Password servers:

$ dig SRV _kpasswd._tcp.example.com
$ dig SRV _kpasswd._udp.example.com

If all goes well, the answer section of the DNS response will contain SRV records pointing to Change Password servers on your network.

...
;; ANSWER SECTION:
_kpasswd._tcp.example.com. 600 IN SRV     0 100 464 kdc01.example.com.
_kpasswd._tcp.example.com. 600 IN SRV     0 100 464 kdc02.example.com.
...

Your default principal will be determined from your ticket cache. You will be prompted for your password and then given an chance to change your password to a new one.

$ kpasswd
Password for hnelson@EXAMPLE.COM: 

Conclusion

You have now used DNS, Kerberos, NTP, and Change Password from Linux interacting with Microsoft Active Directory. Hopefully you have gained some insight into how important these protocols are to providing enterprise infrastructure.