Kerberos

It is used as the preferred authentication protocol for Windows 2000 and Windows Server 2003 domains.Kerberos is a more secure protocol than its predecessor, NTLM.

Kerberos Tracking

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.

Download and install the Resource Kit utilities Kerbtray.exe and Klist.exe put a copy 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.

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.

The capture shows the DNS query, looking for the Lightweight Directory Access Protocol (LDAP) service.

The LDAP query for the Netlogon service, and receiving the answer.

Next, we see 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).The TGT 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.

A successful logon event from the domain controller, note the time on the event and compare it to the time of the Kerberos message.

The member server caches the TGT and can use it when necessary to request access to services. This 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 and follow up with a look at the Security Event log for this time.

A successful TGT request for the Administrator

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.

Kerbtray.exe, run the tool, this places an icon on the taskbar, which can then be opened by clicking it to reveal the tickets in the cache, below shows the list of tickets in the cache and the Administrator account’s TGT ticket.

Kerberos Tray (KerbTray.exe) (RK)

The Kerberos Tray tool lists all cached Kerberos tickets and allows you to view the tickets' properties as well as to purge tickets. This information may help in resolving problems with authentication and access to network resources. (If an AD-based computer has not obtained the initial ticket-granting-ticket (TGT) from a Kerberos Distribution Center (KCC) during the first logging on to the domain, or if the cached tickets have expired and haven't been renewed, the computer won't be authenticated to access the resources.) For Kerberos authentication to be performed successfully, you should ensure that all computers have time settings synchronized with a common time service (within five minutes of delta).

The tool starts in minimized mode, and you can find its icon on the system tray (in the right bottom corner of the screen). If you move the mouse cursor over the icon, the time left on the initial TGT will be displayed.

In this window, you can see the information about all cached tickets and their properties

The Purge Tickets command clears the entire ticket cache (thus, KerbTray differs from the Kerberos List tool, which is able to delete tickets selectively). No warnings are issued before clearing the cache, so be cautious! While the cache is empty, you may be prevented from being authenticated to resources, and a logoff/logon is required.

Note: The utility's window is not updateable. Therefore, if you believe that new tickets might appear (while connecting to a new resource or new services), close the window and open it again.

Let us discuss the main ticket's properties, which are displayed by the tool.

The Client Principal field contains the name of the current logon account. If the ticket cache is empty, this field displays the "No network credentials" message.

All tickets obtained since logon are listed in the scrolling window. The properties of the selected ticket are displayed on the tabs below.

The strings below the scrolling list contain the name of a security principal for the selected ticket. If the ticket time is over, the "Expired" string is displayed and no properties are shown on the tabs.

The Names tab contains:

Client Name — requestor of the ticket. In most cases (while accessing resources in the current domain) this is the same name that is displayed in the Client Principal field.

Service Name — the security principal (account) name for the service. The samAccountName attribute of the account's directory object stores this name.

Target Name — one of the service names contained in the multi-valued servicePrincipalName attribute of the computer's directory object. This is the service name the ticket has been obtained for.

The time when the ticket was obtained (Start time) and its expiration time (End time) are shown on the Times tab. Interpretation of the Flags tab requires a more profound understanding of Kerberos protocol. The Initial flag is set only for the ticket that was obtained without the TGT.

One of the first requests is for the services of the local computer. 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 ofthe user. 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.

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.

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.

The Names tab provides the following information:

■ Client Name Who requested the ticket.■ Service Name The account principal for the service requested. The servicename for the initial TGT is krbtgt.■ Target Name The service name for which the ticket was requested, such as CIFS.

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

Results of a normal Kerberos test

Results of a failed test

QuestionYou are the network administrator for a single Active Directory domain. The domain contains three Windows Server 2003 domain controllers, 20 Windows Server 2003 member servers, and 750 Windows XP Professional computers. The domain is configured to use only Kerberos authentication for all server connections.

A user reports that she receives an "Access denied" error message when she attempts to connect to one of the member servers. You want to test the functionality of Kerberos authentication on the user's client computer.Which command should you run from the command prompt on the user's computer?

A. netshB. netdiagC. ktpassD. ksetup

Answer B

Explanation: Netdiag is a command-line diagnostic tool that you can use to test network connectivity. It performs a series of tests to determine the state and functionality of a network client. You can use the results of these tests, and network status information provided by Netdiag to assist you in isolating network and connectivity problems on your Windows 2000-based workstation or server computer. The netdiag command is used to run a diagnostics test against your server to see if anything is not working correctly.

Incorrect AnswersA. With the Netsh.exe tool, you can direct the context commands you enter to the appropriate helper, and the helper then carries out the command. A helper is a Dynamic Link Library (.dll) file that extends the functionality of the Netsh.exe tool by providing configuration, monitoring, and support for one or more services, utilities, or protocols.The helper may also be used to extend other helpers.C. If you want to configure your UNIX hosts to use a Windows 2000-based server as a Kerberos Key Distribution Center (KDC), you must generate a Kerberos keytab file. You can use the Ktpass utility, which is included with the Microsoft Windows 2000 Resource Kit, to create a keytab file for your UNIX host.D. KSetup is a command-line tool that configures Windows 2000 clients to use an MIT Kerberos server instead of using a Windows 2000 domain for user authentication.