Understanding Kerberos
Kerberos
is a complex authentication protocol described in RFC 1510. It is used
as the preferred authentication protocol for Windows 2000 and Windows
Server 2003 domains. Windows XP Professional, Windows 2000, and Windows
Server 2003 computers that are domain members will preferably use
Kerberos authentication. Knowledge of the authentication process allows
you to determine the following:
Whether Kerberos is being used. Kerberos is a more secure protocol than its predecessor, NTLM.
Whether Kerberos errors represent normal functions, Kerberos problems that need to be corrected, or symptoms of attack.
Whether
Kerberos errors or issues mean problems with replication, Active
Directory operation, DNS, or other critical network services.
Reading the RFC and
even reading a shortened version of the algorithm is instructive, but it
is much more fun to follow Kerberos logons using Network Monitor, the
Security Event log, and Resource Kit utilities Kerbtray.exe and
Klist.exe. The following sections introduce Kerberos by using these
tools to monitor logon sessions. Be sure to complete the exercises so
that you can observe Kerberos activity firsthand.
Hands-On Kerberos Tracking
To track logon, you must first prepare and start the tools that will be used.
Ensure that
auditing of logon events and account logon events is turned on for
domain controllers and domain computers. This should be done in the
Default Domain Policy. Make sure the policy has been updated.
Download and install the Resource Kit utilities Kerbtray.exe and Klist.exe. Make sure a copy is available on the logon client.
Start Network Monitor and start a capture prior to logon.
Optionally,
make a folder on the domain controller to store network captures and a
copy of the Security Event log. This folder can be temporarily shared to
download these files to the server for examination. This way, you can
study them while observing the details in the local Security Event log
and looking at the tickets in the Kerberos cache. It is much easier than
constantly moving between two computers or setting up a terminal
session.
For the purposes of
our example captures, from which screen shots for the figures were
taken, a folder was created and named Captures. In addition, a small
text file was created with the words “Hello World” in it. After the
capture was started on the domain controller, the client server, a
domain member server, was rebooted. Then the Administrator account was
used for logon to the domain from the member server. After successful
logon, the capture was stopped and saved to the folder. A copy of the
Security Event log was also saved to the folder.
Kerberos at Computer Boot
When a domain member server running Windows 2003 Server starts, it must
authenticate to the domain controller. The first step is a query to
find a domain controller. Figure 2 shows the DNS query, looking for the Light-weight Directory Access Protocol (LDAP) service.
Figure 3 shows the LDAP query for the Netlogon service, and receiving the answer.
Next, the server
sends a UDP query to the Kerberos port, 88, on the DC, and is answered
by the DC. This is the server’s request for a Ticket Granting Ticket
(TGT). Figure 4
shows a portion of this packet. Of course, the TGT is necessary and
must be presented before any resources can be accessed. The request is,
in essence, the “Hey, here I am! Let me in the door!” speech and
includes the server’s credentials. The server’s account password is used
as the key in a cryptographic hash of a timestamp. A plaintext copy of
the timestamp also accompanies the hash.
On the domain
controller, the server time from the unencrypted timestamp is compared
to the DC’s time. By default, if the time is off by more than 5 minutes,
the logon is rejected. (If Kerberos fails, NTLM might be attempted, for
example, when mapping drives.) If the time is OK, the Kerberos
Distribution Center (KDC) uses its copy of the server’s password to
create a cryptographic hash of the unencrypted timestamp. The two
hashes, one made by the server, one by the KDC, are compared. If they
match, the server is authenticated because only the server and the DC
have a copy of the server’s password.
The
KDC sends a TGT to the server in another UDP packet. Once again, the
packet is unreadable in Network Monitor. This situation is appropriate,
but how do you know the ticket request and ticket packets are truly
being used for this purpose? Now the Security Event log can help. Figure 5
displays a successful logon event from the domain controller. Note the
time on the event and compare it to the time of the Kerberos message
displayed in Figure 4.
The
member server caches the TGT and can use it when necessary to request
access to services. In fact, that is exactly what happens next. The
server requests service tickets from the KDC. If you examine additional
records in the security log near the TGT request, you will find that a
request for a service ticket is successful as well.
At this point, the
server uses the TGT to obtain a service ticket for access to its own
resources. The Kerberos packets in the capture do not reveal any
interesting information—the data is encrypted. You should also note the
connection to download representative policy modules.
Kerberos at User Logon
Next, when a domain user—in this case, the Administrator—logs on, the
process repeats. Credentials are presented and a TGT is requested. If
the credentials are approved, the TGT is issued. In the Network Monitor
log, more UDP frames are bound for port 88 on the domain controller,
followed by a response. Check the time of these frames (Figure 6) and follow up with a look at the Security Event log for this time.
Figure 7 shows the successful TGT request for the Administrator.
Now
life gets interesting. The TGT for the Administrator account, like the
TGT for the system, is stored in the Kerberos ticket cache. It is used
when the Administrator account requests access to services. You can
examine your ticket cache by using the Kerbtray.exe utility. To use
Kerbtray.exe, you run the self-installing file by double-clicking it and
then clicking the executable to run the tool. This procedure places an
icon on the taskbar, which can then be opened by clicking it to reveal
the tickets in the cache. Figure 8 shows the list of tickets in the cache and the Administrator account’s TGT ticket.
One of the first requests is for the services of the local computer. In Figure 11-17,
notice that tickets are listed for several services: Host, IAM$, Common
Internet File System (CIFS), and LDAP. All these services were
requested at logon and represent the Administrator’s ability to access
the local computer (Host and IAM$), to access a share on the domain
controller (CIFS), and to make LDAP queries to the directory service
(LDAP).
Requests for service
tickets include the TGT and another authenticator. Because the TGT is
cached, you might wonder whether it could be captured and possibly used
in a replay attack. The use of a new authenticator protects the KDC.
Because the time on the server has changed, the authenticator message,
the timestamp, will always be current, and the KDC can check that it is
within the time skew policy of its domain. (Time skew
is the difference between the KDC’s time and the client’s; if it is off
by more than the policy skew time, the Kerberos request is rejected.)
Kerberos Role in Authorization
Kerberos is an authentication protocol, but it does play a role in
authorization. If you map a drive to a share on a computer, the Kerberos
TGT requests a session ticket for the CIFS Server service on the
computer, implemented using the CIFS protocol. If a Network Monitor
capture is made, you can trace the steps in accessing the share.
However, the service
ticket does not give users access to the share. The ticket authenticates
users only to the server. It says, in essence, that the users are who
they say they are, and the server does not have to check in with the
domain controller to verify this information. A portion of the service
ticket is encrypted using the password hash for the server, so the
server can decrypt it. Remember, the DC stores password hashes for
computers as well as users. Because the server can decrypt the ticket,
the server recognizes that it is valid and must come from a DC, because
the DC is the only other entity that has the server’s password.
Where does the
authorization information come from? The service ticket, although it is
only validation of user identity, does contain information useful for
authorization. This information is the same as that collected by the KDC
when the user first presented domain credentials, the user’s security
identifier (SID), and the SIDs of the groups of which the user is a
member. The file server uses this information to create the access
token, and then the file server can determine whether the user has the
proper permission to access the share and the folders and files
underneath.
You can use the
Security Event log to determine whether access was allowed or denied,
and Kerbtray.exe shows the CIFS service ticket in the cache. Note that
the CIFS service ticket in the cache is issued for a specific server. If
the user attempts access to a share on this server—or a reconnection if
the connection has been broken—this service ticket can be used. If the
user attempts access to another server, a new service ticket must be
obtained. Once again, the service ticket requests are not viewable.
However, Kerbtray.exe can be used to verify that a service ticket is
issued. Figure 11-17 shows a CIFS service ticket.
Examine
the properties of tickets in the cache. Note that both service tickets
and TGT tickets are renewable. If a service ticket expires, a new one
can be obtained transparently if a valid TGT is in the cache. If,
however, there is no valid TGT, a new one must be obtained and the user
will need to log on again. To determine the time frames, select the
Times tab and check the Kerberos policy for the domain. This same
process occurs on computers running Windows 2000 and Windows XP
Professional that are joined in a domain.
You can use another
Resource Kit utility, Klist.exe, to obtain a list of tickets in the
cache. You can run Klist from the command line and thus can incorporate
it in a script. You can place the records in a text file (use the
command Klist.exe > Textfile.txt). Klist.exe does not show as much
information as Kerbtray.exe, but it does have a unique advantage. You
can use the Klist.exe Purge command to purge tickets, and you will be
able to selectively retain or purge tickets one at a time.
Additional Uses for Kerberos Tools
Kerbtray.exe and
Klist.exe provide a wealth of information. In addition, you can also use
Netdiag to determine how Kerberos is functioning. These tools are all
relatively simple to use.
Understanding Kerbtray
If the Kerbtray icon shows only question marks, you know that no
Kerberos tickets are in the cache. This situation can occur if a
computer is not connected to the network or if no domain controllers are
available.
Double-click the
Kerbtray icon to see a list of tickets obtained since logon.
Right-clicking the tool presents two useful menu commands, List Tickets
and Purge Tickets. Selecting List Tickets has the same effect as
double-clicking the Kerbtray icon. If you select Purge Tickets, you will
have to log on again to use Kerberos to access resources.
The Kerbtray display
shows the name of the client principal (the user) who has obtained the
tickets and shows a list of tickets for services. Selecting a ticket
reveals its target: for which resource this ticket is used. The bottom
of the screen provides information about the selected ticket, such as
names, times, flags, and encryption types. Figure 8 shows the Names tab. Figures 9, 10, and 11 show examples of the other tabs.
The Names tab provides the following information:
Client Name Who requested the ticket.
Service Name The account principal for the service requested. The service name for the initial TGT is krbtgt.
Target Name The service name for which the ticket was requested, such as CIFS.
The Times tab provides the following information:
Start Time The time when the ticket becomes valid.
End Time The time when the ticket expires. An expired ticket cannot be used to authenticate to a service.
Renew Until
If the ticket is renewable, the maximum lifetime of the ticket. Tickets
can be renewed before the end time and renew until times expire. This
functionality is transparent to the user.
Kerberos flags
indicate the status of a ticket, as well as define the uses the ticket
might have. The Flags tab provides the following information:
Forwardable The authentication information can be forwarded and the user will not have to enter a password to use the ticket.
Forwarded
The Ticket Granting Service (TGS) of the KDC sets this flag if a client
presents a ticket with the FORWARDABLE flag set and requests that the
FORWARDED flag be set.
Proxiable
The information in this ticket can be passed on and a remote server can
be given permission to perform a remote request on behalf of a client.
The TGS issues a new service ticket with a different network address (a
service ticket for another computer on behalf of a client).
Proxy
If a ticket is issued to another computer on behalf of a client (a
proxiable ticket was received), the new ticket is marked as a proxy
ticket. An application server can be set to provide an audit trail based
on this flag, and flags can be set to require additional authentication
from any agent presenting the proxy.
May Postdate
May Postdate is necessary in a TGT if a postdated ticket needs to be
issued based on one presented. To clarify, a service ticket is normally
requested for some service access that is required immediately. A
postdated ticket is one that will not be usable for a while. Its start
date is sometime in the future.
Postdated A postdated ticket is one whose start date is sometime after its issuance date.
Invalid
The ticket is not valid. A postdated ticket is issued with this flag
set. It must be returned to the KDC to be validated before it can be
used. The KDC validates the ticket only after its start date has passed.
Initial
The ticket issued is not based on presentation of a TGT. An example is
the first service ticket for the krbtgt. It is the TGT. No TGT is
present when it is issued.
Renewable A renewable ticket can be used for a longer period. A new authentication does not have to take place.
HW Authenticated Authenticated provides more information about the initial authentication.
Preauthenticated Shows the initial authentication request information.
OK As Delegate
The server (not client) listed in the ticket is a suitable recipient of
delegation. The user’s credentials are forwarded only to services that
are marked OK As Delegate.
The Encryption Types tab provides the following information:
Understanding Klist Klist is used at the command line to either display or purge tickets. There are a few choices:
Klist Tgt displays the TGT tickets.
Klist Tickets displays all tickets.
Klist Purge deletes all tickets in the cache.
When the Klist Tickets command is used, the following information is displayed:
Server and domain for the ticket (the service principal name).
Kerbticket encryption type—the encryption type used to encrypt the Kerberos ticket.
End time—after this time the ticket is no longer valid.
Renew-time—if the ticket is renewable, this time shows the entire lifetime of the ticket.
You can obtain more information about the TGT tickets by using the Klist Tgt command.
Servicename
krbtgt—the name of the service the ticket can be used for. Since this is
a TGT, krbtgt is the only service that will show.
Targetname—the service for which it is requested.
Fullservicename—the canonical name of the account principal for the service.
DomainName—domain name of the service.
Targetdomainname—if
the ticket is cross-realm (meant for another domain for example, the
TGT is for another domain in the forest, not the domain the user’s
account is in).
AltTargetDomainName—the
service principal name or SPN of the service that was given—the service
context under which the ticket was generated.
Ticket flags—a list of flags set on the ticket in hexadecimal. (Use the KerbTray tool to see them in English.)
KeyExpirationTime—ticket expiration date.
Starttime—time when the ticket is valid.
EndTime—time when the ticket becomes not valid.
RenewUntil—maximum lifetime of the ticket.
TimeSkew—the reported time difference between the client computer and the server computer.
You can gather a wide
range of troubleshooting information by using Klist.exe and
Kerbtray.exe. For example, you can determine whether a ticket is valid,
whether Kerberos was used, and if so, whether Kerberos was used to
attempt to authenticate a domain.
Using Netdiag to Verify Kerberos Health
After you are familiar with Kerberos processing and the records in
Network Monitor, the Security Event log, Kerbtray.exe, and Klist.exe,
how can you best monitor Kerberos? You can’t spend hours every day
ensuring that all is in order. The trick, of course, is not to examine
the thousands—perhaps millions—of records every day, but to look for
warnings that might mean a Kerberos problem when viewing the logs and
captures. You can use Netdiag to get a quick reading of Kerberos health
on a server.
Netdiag runs a large
number of tests, and one of them is the Kerberos test. If you run
Netdiag from the command line, a minimal amount of information will
provide the results of the Kerberos test. If something is wrong, it is
reported. Running the specific test and using the /v switch for verbose,
or /debug for more information, provides a list of tickets, an
authentication test, domain information, and so on. Use the following
statement to print this information to a file.
Netdiag /test:Kerberos /debug > ktest.txt
Figure 12 shows the results of a normal Kerberos test, and Figure 13 shows the results of a failed test.
