6.6 Auditing

Although it is certainly important to ensure that your machines are secure from outside attack, you also need to periodically audit the activity of your KDC to look for any malicious activity. Depending on your KDC vendor, the amount of logging that occurs by default can vary from none (Windows 2000's default configuration) to a lot (Heimdal & MIT). In this section, we will examine the information that KDCs log, how to enable logging on your KDC, and how to read and understand the resulting log files.

The logging facilities built in to these KDC implementations not only serve auditing purposes, but they play a big role in debugging issues that may arise during the operation of your Kerberos system. First, let's take a look back at the Kerberos protocol exchange. At each point where the KDC is contacted, the KDC usually provides an option to log that information to a file.

6.6.1 Enabling Logging

Each KDC has different auditing options, and different procedures for enabling auditing.

6.6.1.1 MIT

To enable logging in the MIT KDC, the krb5.conf file can contain a [logging] stanza with several variables that control where the logging output goes. Here are the variables:

kdc

The kdc variable controls where the log for the KDC's authentication service and Ticket Granting Service is sent. The logs produced in the file specified in the KDC variable contain all of the transactions between users, servers, and the KDC.

admin_server

The admin_server variable controls where the logs for the kadmin server are sent. The logs produced in the file specified in the admin_server variable contain all of the transactions between Kerberos administrators and the KDC that are performed through the kadmin interface.

Each option can take several different arguments, depending on the type of file, device, or syslog facility you wish the logs to be sent to. If you want logs sent to several destinations, you can list them, one at a time, on separate lines.

FILE= filename

FILE :filename

These options send the specified logs to a file called filename. In the first form with a "=", the file is overwritten each time the KDC starts. The second form, specified with a ":", indicates that the file will be appended to each time the KDC starts.

STDERR

This option specifies that the logs should be sent to the standard error output of the KDC.

CONSOLE

This option specifies that the logs be sent to the console of the KDC machine.

DEVICE= devicename

This option specifies that the logs be sent to the devicename. This can be used to send logs to a particular terminal, or printer.

SYSLOG :severity:facility

This option specifies that the logs be sent to the syslog service on the KDC. The severity and facility arguments are optional, and can be used in combination with syslog.conf to send KDC output to its own file, or relay to another syslog server. The available severities and facilities vary by operating system vendor, but the syslog manpage will list the options available for your OS. By default, the severity is ERR and the facility is AUTH.

Let's take a look at an example:

[logging]
 kdc = FILE:/var/log/kdc.log
 kdc = SYSLOG:NOTICE
 admin_server = FILE:/var/log/kadmin.log
 admin_server = CONSOLE

In this example, all of the KDC activity (authentication service and ticket granting service) are logged to a file named /var/log/kdc.log, to which something is appended to every time the KDC restarts. In addition, KDC activity is logged to syslog, under the AUTH facility and the NOTICE severity. All kadmin requests and responses are logged to /var/log/kadmin.log as well as the system console.

6.6.1.2 Heimdal

The controls for the Heimdal KDC logging facility are located in the krb5.conf file. The options are similar to the MIT KDC logging options, but have a few important additions. Just like the MIT KDC, all of these options are contained in a [logging] stanza in the configuration file.

Each variable in the logging section of the Heimdal krb5.conf configuration file is named after the program that is generating the logs. That is, the logs from the kdc program are sent to the destination specified by the kdc variable. Similarly, logs from the kadmind program are sent to the destination specified by the kadmind variable, and so on. In addition, a "default" variable is provided as a catchall for messages that do not have a more specific destination specified. The destination specifications are as follows:

FILE= filename

FILE :filename

These options send the specified logs to a file called filename. In the first form with a "=", the file is overwritten each time the KDC starts. The second form, specified with a ":", indicates that the file will be appended to each time the KDC starts.

STDERR

This option specifies that the logs should be sent to the standard error output of the KDC.

CONSOLE

This option specifies that the logs be sent to the console of the KDC machine.

DEVICE= devicename

This option specifies that the logs be sent to the devicename. This can be used to send logs to a particular terminal, or printer.

SYSLOG :severity:facility

This option specifies that the logs be sent to the syslog service on the KDC. The severity and facility arguments are optional, and can be used in combination with syslog.conf to send KDC output to its own file, or relay to another syslog server. The available severity and facility arguments are system-dependent By default, the severity is ERR and the facility is AUTH.

In addition, each destination may be preceded by an optional logging level. Logging levels are integers, numbered from zero upwards; zero is the minimum of detail. To specify a logging level, prefix a destination with the range of logging levels (for example, 1-5) followed by a slash. If only one logging level is given, then only messages sent to that level will be logged to the destination.

Here is an example:

[logging]
 kdc = 0/FILE:/var/log/kdc.log
 kdc = 1-/SYSLOG:DEBUG
 kadmind = FILE:/var/log/kadmin.log
 kpasswdd = FILE:/var/log/kpasswdd.log
 default = FILE:/var/log/kerberos.log

In this example, KDC logs with a logging level of zero are sent to /var/log/kdc.log, while messages with a higher logging level are sent to syslog, facility AUTH, severity DEBUG. Messages sent from kadmind are stored in the /var/log/kadmin.log file and kpasswdd logs are sent to /var/log/kpasswdd.log. All other messages from applications using Heimdal Kerberos are sent to /var/log/kerberos.log. In all cases, the log file is appended to when the respective programs restart.

6.6.1.3 Windows domain controllers

Windows 2000 domain controllers do not log any authentication requests by default. Windows Server 2003 is somewhat better in this regard since it logs successful authentication requests by default, but it does not log any denied requests. Thankfully, Microsoft provides very detailed logging facilities that can be enabled. A Windows domain controller can log the Kerberos KDC activity as well as domain logon and logoff events. We'll take a look at both, from a Kerberos perspective.

First, let's enable the logging of authentication requests for your domain. The first thing to configure is the Security Log's maximum log file size. On Windows 2000, machines in your domain will only keep a 512 KB rotating log file by default (overwriting events that are more than 7 days old). With today's large hard drives, there is no reason to constrain log files to less than a megabyte, so we'll increase the file size limit to 10 megabytes in this example.

To change the maximum log file size for the security log, follow these steps:

You will now see the window shown in Figure 6-6.

Figure 6-6. Active Directory Group Policy event log settings

By double-clicking on Maximum security log size, you'll be presented with a dialog box. Click "Define this policy setting" and set a maximum size (in this case, 10240 Kbytes). If you would like to change the log retention options, you can change the "Retain security log" and "Retention method for security log" settings in this window.

Next we'll enable auditing for our domain. There are two different auditing options included in Windows, rather obscurely named "logon auditing" and "account logon auditing." They both audit authentication requests, however, they audit different parts of the login process, and store the information on different hosts. Confused yet? Let's take a look at the two choices:

Logon Auditing

This setting toggles the auditing of local Windows login events. These login events are not constrained to Kerberos-based logins; logon auditing will record login events for every type of authentication that Windows supports, such as NTLM. This type of logging is similar to a Secure Shell (or other application-level) log on a Unix box; it records the start and finish of a user's login session. Therefore, logon auditing occurs on the individual severs that users log in to, and the corresponding audit logs only appear in that server's Event Log.

Account Logon Auditing

This setting enables auditing similar to the other KDC's we have mentioned here. Every time a Kerberos ticket is granted, either through the Authentication Service or the Ticket Granting Service, the domain controller writes the details about that ticket to its Security Log when this setting is enabled. Since there is no concept of a "login session" in Kerberos, there is no way to determine when a user "logs out," and consequently the duration of users' login sessions, with this option alone. However, this option does provide for a nice centralized log of all Kerberos-based authentication requests, since the account logon audit records are written to the domain controllers' event logs, instead of the individual servers' event logs.

Okay, now that we've cleared that up, let's continue on to enable these audit policies on your domain. We're going to start at the same Group Policy window that we opened in the previous exercise.

From the Group Policy window, navigate to Computer Configuration, Windows Settings, Security Settings, Local Policies, Audit Policy. You'll see a window similar to the one shown in Figure 6-7.

Figure 6-7. Active Directory Group Policy audit policy settings

From this window, you can configure both the "Audit logon events" and "Audit account logon events." It is recommended that both successful and failed attempts should be logged for these events.

6.6.2 Understanding the Logs

Now that you've set up the auditing mechanism on your Kerberos KDC and your KDC is busy logging all of its activity, you need to periodically review these logs for suspicious activity. Enabling the logging activity on your KDC is useless unless the logs are actually analyzed at some point, either automatically by a script that has preset thresholds for suspicious activity, or by hand. In this section, we'll examine the log messages emitted by each Kerberos implementation covered in this book, and describe what each message means.

Each implementation has a dramatically different log format, but since there are only a few protocol exchanges in Kerberos, the number of different log messages is relatively low. Each log message can be directly connected to an exchange between the KDC and a Kerberos client.

6.6.2.1 MIT

Each time the MIT KDC starts up, it logs the interfaces and ports on which it is listening to the defined KDC log file:

Jul 31 03:04:40 www.wedgie.org krb5kdc[10543](info): setting up network...
Jul 31 03:04:40 www.wedgie.org krb5kdc[10543](info): listening on fd 7: 192.168.1.83 
port 88
Jul 31 03:04:40 www.wedgie.org krb5kdc[10543](info): listening on fd 8: 192.168.1.83 
port 750
Jul 31 03:04:40 www.wedgie.org krb5kdc[10543](info): set up 2 sockets
Jul 31 03:04:40 www.wedgie.org krb5kdc[10544](info): commencing operation

In this case, the KDC is listening on both the Kerberos 5 and Kerberos 4 well-defined ports. Similarly, every time the KDC is shut down cleanly, it logs this fact to the log file as well:

Jul 31 15:11:57 www1.wedgie.org krb5kdc[779](info): shutting down

Now, let's take a look at what is logged during Kerberos protocol exchanges. First, let's take an example user using Kerberos 5, who is obtaining a TGT when he starts his day. The following message is recorded in the log:

Jul 30 23:18:26 www1.wedgie.org krb5kdc[10544](info): AS_REQ (3 etypes {16 3 1}) 192.
168.1.83(88): ISSUE: authtime 1028085506, etypes {rep=16 tkt=16 ses=16}, 
jgarman@WEDGIE.ORG for krbtgt/WEDGIE.ORG@WEDGIE.ORG

Let's examine this output piecemeal. First, we have the date, time, and hostname of the KDC. This information appears whether the log is being sent to a file or via syslog. Next, we have the name and process ID of the KDC, as well as the severity of the message (in this case "info").

The next part of this message describes the request that was made to the KDC. It begins with the type of request (AS_REQ, for an Authentication Service request). Then, it follows by listing the encryption types that the client claims to support. In this case, the client listed three encryption types that it understands. Each encryption type is specified by its numeric identifier. A complete listing of currently defined encryption types and their numeric identifiers can be found in the Kerberos Encryption Specifications document, which is on the Kerberos Clarifications site at http://www.kerberos.isi.edu. In this particular example, the encryption types supported by the client are DES-CBC-CRC (1), DES-CBC-MD5 (3), and DES3-HMAC-SHA1 (16). Next, we see the requesting IP address, followed by the port on the KDC that the request arrived on.

The next section of this message indicates the KDC's response to the request. In this example, the KDC issued (ISSUE) a ticket valid beginning at authtime (indicated by the standard Unix time_t value, seconds past January 1, 1970). This ticket's encryption types for the reply, the ticket itself, and the session key, are all DES3-HMAC-SHA1. Finally, we see the principal that requested the ticket (jgarman@WEDGIE.ORG) and the service for which the ticket was issued (krbtgt/WEDGIE.ORG@WEDGIE.ORG, since the user requested a TGT).

If the realm requires pre-authentication for this user, the KDC first logs a NEEDED_PREAUTH instead of an ISSUE response, then, upon successful pre-authentication, logs the ISSUE response, as in the following example:

Aug 01 09:29:09 www1.wedgie.org krb5kdc[17734](info): AS_REQ (3 etypes {16 3 1}) 192.
168.1.6(88): NEEDED_PREAUTH: afsadmin@WEDGIE.ORG for krbtgt/WEDGIE.ORG@WEDGIE.ORG, 
Additional pre-authentication required
Aug 01 09:29:11 www1.wedgie.org krb5kdc[17734](info): AS_REQ (3 etypes {16 3 1}) 192.
168.1.6(88): ISSUE: authtime 1028208551, etypes {rep=16 tkt=16 ses=16}, 
afsadmin@WEDGIE.ORG for krbtgt/WEDGIE.ORG@WEDGIE.ORG

Now, once the user has their TGT, he wishes to connect to a remote server, and so requests a service ticket:

Aug 02 10:35:37 www1.wedgie.org krb5kdc[17734](info): TGS_REQ (3 etypes {16 3 1}) 
192.168.1.83(88): ISSUE: authtime 1028298937, etypes {rep=16 tkt=16 ses=16}, 
jgarman@WEDGIE.ORG for host/www1.wedgie.org@WEDGIE.ORG

This message is very similar to the message emitted when requesting a TGT. The only difference between the two messages is that this message is of type TGS_REQ (Ticket Granting Server request) rather than AS_REQ. All of the rest of the fields represent the same data as they did for the AS_REQ.

Now, let's take a look at the messages that turn up in the log when things start going wrong. First, we'll take a user who doesn't exist in the Kerberos principal database. When he tries to kinit, the following message is logged:

Aug 02 12:07:19 www1.wedgie.org krb5kdc[17734](info): AS_REQ (3 etypes {16 3 1}) 192.
168.1.83(88): CLIENT_NOT_FOUND: root@WEDGIE.ORG for krbtgt/WEDGIE.ORG@WEDGIE.ORG, 
Client not found in Kerberos database

Here, we see an AS_REQ message with a response of CLIENT_NOT_FOUND. A similar message is emitted when a valid user attempts to obtain a ticket for a service that does not exist in the KDC database:

Aug 02 13:43:28 www1.wedgie.org krb5kdc[17734](info): TGS_REQ (1 etypes {1}) 192.168.
1.83(88): UNKNOWN_SERVER: authtime 1028298840,  jgarman@WEDGIE.ORG for afs/net.
wedgie.org@WEDGIE.ORG, Server not found in Kerberos database

6.6.2.2 Heimdal

Each time the Heimdal KDC starts up, it outputs the network ports it listens on to the KDC log file:

2002-08-04T14:44:51 listening on IPv4:127.0.0.1 port 88/udp
2002-08-04T14:44:51 listening on IPv4:192.168.1.83 port 88/udp
2002-08-04T14:44:51 listening on IPv4:127.0.0.1 port 88/tcp
2002-08-04T14:44:51 listening on IPv4:192.168.1.83 port 88/tcp
2002-08-04T14:44:51 listening on IPv4:127.0.0.1 port 750/udp
2002-08-04T14:44:51 listening on IPv4:192.168.1.83 port 750/udp
2002-08-04T14:44:51 listening on IPv4:127.0.0.1 port 750/tcp
2002-08-04T14:44:51 listening on IPv4:192.168.1.83 port 750/tcp
2002-08-04T14:44:51 listening on IPv4:127.0.0.1 port 4444/udp
2002-08-04T14:44:51 listening on IPv4:192.168.1.83 port 4444/udp
2002-08-04T14:44:51 listening on IPv4:127.0.0.1 port 4444/tcp
2002-08-04T14:44:51 listening on IPv4:192.168.1.83 port 4444/tcp

By default, the Heimdal KDC acts as a Kerberos 5 KDC, Kerberos 4 KDC, and a Kerberos 5-4 ticket translator. Now let's continue with an example protocol exchange in which a client requests a TGT:

2002-08-04T15:40:09 AS-REQ jgarman@WEDGIE.ORG from IPv4:192.168.1.83 for krbtgt/
WEDGIE.ORG@WEDGIE.ORG
2002-08-04T15:40:09 Using des3-cbc-sha1/des3-cbc-sha1
2002-08-04T15:40:09 sending 606 bytes to IPv4:192.168.1.83

All of the Heimdal messages begin with a date, followed by the T delimiter and the time. The first message indicates that the KDC received an Authentication Service request (AS-REQ) for the principal jgarman@WEDGIE.ORG. Next, it lists the originating IP and the service ticket the client requests.

The next message indicates the encryption types that the KDC will use in responding to the request: in this case, triple DES. Finally, if the KDC accepts the request, it emits the last message indicating the size of the response and the IP address of the client.

If the KDC requires pre-authentication, the following messages will be sent to the log upon successful client authentication:

2002-08-04T17:02:09 AS-REQ jgarman@WEDGIE.ORG from IPv4:192.168.1.83 for krbtgt/
WEDGIE.ORG@WEDGIE.ORG
2002-08-04T17:02:09 No PA-ENC-TIMESTAMP -- jgarman@WEDGIE.ORG
2002-08-04T17:02:09 sending 282 bytes to IPv4:192.168.1.83
2002-08-04T17:02:09 AS-REQ jgarman@WEDGIE.ORG from IPv4:192.168.1.83 for krbtgt/
WEDGIE.ORG@WEDGIE.ORG
2002-08-04T17:02:09 Looking for pa-data -- jgarman@WEDGIE.ORG
2002-08-04T17:02:09 Pre-authentication succeded -- jgarman@WEDGIE.ORG
2002-08-04T17:02:09 Using des3-cbc-sha1/des3-cbc-sha1
2002-08-04T17:02:09 sending 624 bytes to IPv4:192.168.1.83

The first three messages indicate the original request, and the error response sent back by the KDC to the client requesting pre-authentication. The final five lines are similar to the non-pre-authentication case, with the addition of the pa-data and pre-authentication succeded messages. Requesting a service ticket generates similar output:

2002-08-04T17:17:42 TGS-REQ jgarman@WEDGIE.ORG from IPv4:192.168.1.83 for
afs@WEDGIE.ORG [forwardable]
2002-08-04T17:17:42 sending 527 bytes to IPv4:192.168.1.83

Note that the ticket options that the client requested are listed on the TGS-REQ line.

6.6.2.3 Windows domain controllers

As we discussed earlier, the log files for the two different audit options (logon auditing and account logon auditing) are stored on different machines' Event Logs. The account logon auditing produces audit logs that are similar to the other KDC implementations we've covered. Since the account logon auditing is generated by the Kerberos KDC service running on the domain controllers, we're going to examine what those logs look like.

There are several Kerberos-related log events that account logon auditing emits. They are listed below:

• 672 Authentication Ticket Granted

• 673 Service Ticket Granted

• 674 Ticket Granted Renewed

• 675 Pre-authentication Failed

• 676 Authentication Ticket Request Failed

• 677 Service Ticket Request Failed

Any Kerberos client looks the same from the perspective of account logon auditing. It doesn't matter whether the requesting machine is running Windows or Unix; as long as it contacts the KDC running on one of your domain controllers, the KDC service will log both the successful and failed attempts at requesting tickets. So, let's dive in and examine some sample event logs.

Here's an example of a Windows machine successfully authenticating a user "jgarman" in the WEDGIE.ORG realm:

Event Type: Success Audit
Event Source: Security
Event Category: Account Logon 
Event ID: 672
Date:  10/1/2002
Time:  11:55:10 PM
User:  NT AUTHORITY\SYSTEM
Computer: DESKTOP
Description:
Authentication Ticket Granted:
  User Name:  jgarman
  Supplied Realm Name: WEDGIE.ORG
  User ID: WEDGIE\jgarman
  Service Name:  krbtgt
  Service ID:  WEDGIE\krbtgt
  Ticket Options:  0x40810010
  Ticket Encryption Type: 0x3
  Pre-Authentication Type: 2
  Client Address:  192.168.1.17

The sequence of event log entries begins with a 672 event, signifying that the Authentication Server has issued a TGT. Note that the User field contains SYSTEM, not the end user for whom the ticket was issued. The username component of the requesting principal is contained in the User Name field, which is mapped to an NT-style user name in the User ID field. Unfortunately, this implies that if you want to filter the Event Log to show activity relating to a particular user name, you're out of luck. Also note that the Computer field always lists the domain controller's NetBIOS name (in this case DESKTOP), not the requesting machine's name, once again negating any ability to intelligently filter through the standard Event Viewer interface.

The Service Name field contains the first component of the principal we've been issued a ticket for: in this case simply, "krbtgt." This service name is mapped to a username in the Active Directory, and the resulting name is used for the Service ID field, much like the User Name is mapped to a User ID.

Finally, we see the ticket options (in easy-to-read hexadecimal format).

After the client receives this TGT, it requests service tickets. There are quite a few that Windows requests, and their names are strange to those used to working with Kerberos on Unix machines. Let's take a look at one:

Event Type: Success Audit
Event Source: Security
Event Category: Account Logon 
Event ID: 673
Date:  10/1/2002
Time:  11:55:10 PM
User:  NT AUTHORITY\SYSTEM
Computer: DESKTOP
Description:
Service Ticket Granted:
  User Name:   jgarman
  User Domain:  WEDGIE.ORG
  Service Name:  WEB$
  Service ID:  WEDGIE\WEB$
  Ticket Options: 0x40810010
  Ticket Encryption Type: 0x17
  Client Address:  192.168.1.17

As you can see, this Event ID is 673, indicating that the client contacted the Ticket Granting Service for a service ticket. In this case, a service ticket is granted to the WEB$ service (this is simply the NetBIOS name of the target machine, with a dollar sign appended).

Finally, let's examine an example failed authentication attempt. Since Windows requires pre-authentication by default, you can detect password or brute-force attacks against your KDC by watching for event 675, Pre-authentication Failed messages. Here is an example:

Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon 
Event ID: 675
Date:  10/4/2002
Time:  11:56:07 PM
User:  NT AUTHORITY\SYSTEM
Computer: DESKTOP
Description:
Pre-authentication failed:
  User Name:  Administrator
  User ID:  WEDGIE\Administrator
  Service Name:  krbtgt/WEDGIE
  Pre-Authentication Type: 0x2
  Failure Code:  24
  Client Address:  192.168.1.1