Analysis of Kerberos Transactions

Analysis of Kerberos Transactions

Modern Windows clients use Kerberos authentication in the following three situations:

  • Initial computer startup. The client computer uses credentials stored in the LSA database to authenticate with an Active Directory domain controller. It then establishes a secure channel to that logon server.

    Kerberos Authentication in Mixed Domains

    A modern Windows computer that belongs to a Mixed domain will always authenticate with an Active Directory-based domain controller if one is available. This is true even if the computer must authenticate across the WAN to get to the AD-based domain controller.

    Modern Windows clients check for service locator (SRV) records in DNS every time they start. As long as they don't see any indication of an AD-based domain, they're happy to use NTLM to authenticate. But after they see SRV records, they will insist on using Kerberos.

    This behavior can come as a surprise if you've deployed hundreds or thousands of Windows 2000 and XP desktops while you are still running a classic NT4 domain. As soon as you upgrade your PDC to an AD-based domain controller, every modern Windows client will see the SRV records and go right to that AD-based domain controller to authenticate. They may come from all corners of the globe.

    You can inhibit this behavior, but to do so you must put a Registry entry in place. See Chapter 9, "Deploying Windows Server 2003 Domains," for details.

  • Service account authentication. Some services use Kerberos authentication when connecting to other servers. These so-called Kerberized applications register themselves as distinct security principals in Active Directory. Examples of Kerberized connections include LDAP connection to Active Directory, CIFS/SMB file access, and secure dynamic DNS updates.

  • Initial user logon. A user logging on to an Active Directory domain from a modern Windows computer authenticates at the same domain controller as the computer.

Let's take a look at this last transaction, a user who logs on to an Active Directory domain from a modern Windows client. The transaction details are the same for Windows Server 2003, Windows XP, and Windows 2000.

Initial User Logon Authentication

Figure shows a user logon in a single Active Directory domain. Here are the key points to watch for:

  • The user must present domain credentials to get access to a domain member computer.

  • The user's plain-text and encrypted password is never transmitted over the wire.

  • The user is issued a ticket-granting ticket (TGT) during the initial domain authentication.

Figure. Logon transaction in a single AD-based domain.


Determining the Identity of the Logon Server

You can identify a user's logon server by opening a command prompt and running SET. Here's a partial listing. The LOGONSERVER variable is in bold:

ALLUSERSPROFILE=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\Administrator\Application Data
CommonProgramFiles=C:\Program Files\Common Files
HOMEPATH=\Documents and Settings\Administrator

Procedure 11.6 traces the transaction starting from the initial logon.

Procedure 11.6 User Logon Transaction Using Kerberos

  1. The user initiates logon by pressing Ctrl+Alt+Del. This is called the Secure Attention Sequence. It wakes up Winlogon and displays the logon credentials window defined in Gina.dll. This foils any Trojan horse programs that might get in ahead of the operating system and nab a user's password.

  2. The user enters an account name and password and selects a domain in the Domain field of the logon window. As an alternative, the user could enter a User Principal Name (UPN) in the format [email protected]. Either name format results in the same actions on the part of the security system.

    UPN Versus Domain\Name Logon Format

    A persistent rumor in the Windows administrator community asserts that entering a username and domain in Winlogon results in a classic NTLM authentication, whereas entering a UPN results in a Kerberos authentication. Unlike the protestations of a certain ex-president, there is absolutely no truth to this rumor. If the local computer has authenticated in an AD-based domain, the user will be authenticated using Kerberos regardless of the logon format. The only difference between using domain\name\password and a UPN is that the UPN requires a query to a Global Catalog server to extract the username and domain. Windows Server 2003 and XP clients cache the results of this query in case a GC server is not available.

  3. Winlogon takes the user's credentials and passes them to the Local Security Authority Subsystem, LSASS, which hashes the user's password using MD4 and then works with the Kerberos package to authenticate the user.

  4. The Kerberos package takes the user's password hash and uses it to construct a TGT request that contains the preauthenticator (a timestamp encrypted with the user's password hash). (This transaction does not require Netlogon at either the client or the domain controller.)

  5. The KDC service at the domain controller receives the TGT request. If the user's name exists, the service obtains the user's password hash from Active Directory and uses it to decrypt the preauthenticator.

  6. If the KDC fails to decrypt the preauthenticator, or if the timestamp indicates that it has been replayed or is out of the acceptable time skew, the authentication fails. The KDC sends a logon failure notification to the client.

  7. If the KDC accepts the preauthenticator as genuine, it gets help from LSASS to create a PAC for the user. It places the PAC in the authentication data field of the TGT and returns it inside a reply message to the user. The TGT is encrypted with the password hash of the krbtgt account. The entire reply is encrypted with the user's password hash.

  8. The Kerberos client decrypts the reply and caches the session key and TGT in memory, not on disk. It turns the PAC over to LSASS.

  9. The LSASS uses the information in the PAC to build a local access token for the user. (It adds the SIDs of any machine local groups that have the user as a member and any local security policies that apply to the user.)

  10. When the TGT expires (the default Time-To-Live is 10 hours), the client obtains a new TGT from the KDC. This happens transparently with no service interruption unless no domain controller is available, in which case the client loses access to the domain until a domain controller can be made available.

At this point, the console logon is complete. Winlogon passes control over to Userinit, which downloads and processes Registry-based group policies and then fires off the Explorer shell in the user's security context. Any subsequent processes spawned by the user get the user's access token.

Authentication When Accessing Member Servers

Following domain authentication, the user then accesses resources on member servers in the domain. Let's take a look at what happens. The key points to watch for are as follows:

  • The client must go back to its logon server to get a session ticket for the target server.

  • The client presents the session ticket to the member server inside the first connection transaction along with an authenticator and a mutual authentication request.

  • The member server decrypts the ticket, validates the authenticator, and responds with an authenticator of its own. It also creates a local access token for the user.

  • The client validates the server's authenticator.

Procedure 11.7 traces the transaction from the point where the user reaches out to touch a network resource.

Procedure 11.7 Server Access Transaction Using Kerberos

  1. The user opens My Network Places, navigates to a server icon, and double-clicks the icon.

  2. The network redirector calls on LSASS to get a Kerberos ticket for the target server. LSASS turns right around and calls on the Kerberos security package for help.

  3. The Kerberos package gets a copy of the cached ticket-granting ticket (TGT) and uses it to build a session ticket request specifying the target server's name. The request is encrypted using the session key that came with the TGT.

  4. The KDC receives the request and decrypts it with its copy of the session key. If the decryption fails, the KDC knows that someone has hijacked the ticket. If the contents do not pass CRC (Cyclic Redundancy Checking), the KDC knows that someone fiddled with the contents.

  5. The KDC then builds a ticket for the target server. The ticket contains a new session key specific to this particular transaction. The KDC delivers the ticket to the client in a reply message. The ticket itself is encrypted with the target server's password hash. The entire reply is encrypted with the user's password hash.

  6. The Kerberos package decrypts the reply and caches the session key and the ticket. It uses the session key to build an authenticator. It includes the authenticator and the ticket in an access request that it hands over to the network redirector.

  7. The redirector builds a Server Message Block (SMB) message asking the server to create a session and to let the client connect using that session. It includes the Kerberos access request with that initial SMB message.

  8. The target server extracts the access request from the SMB and passes it to LSASS, which calls on the local Kerberos package to decrypt the ticket and validate the authenticator.

  9. When the client has been validated, the Kerberos package extracts a copy of the session key from the ticket and uses it to build an authenticator of its own, which it returns to the client in an access reply.

    At the same time, the server extracts the PAC from the authorization data field of the ticket and gives it to LSASS, which uses it to build a local access token for the user. (LSASS adds the SIDs of any machine local groups that have the user as a member and any local security policies that apply to the user.)

  10. The client validates the authenticator returned by the server and then completes the SMB session setup.

  11. When the session ticket expires (10 hours by default), the Kerberos package obtains another ticket from the KDC. It does this transparently to the user unless a domain controller is not available, in which case the user loses access to the member server.

Viewing Kerberos Tickets

You'll find two tools in the Resource Kit that help troubleshoot Kerberos transactions by listing the ticket-granting tickets and tickets obtained by a client:

  • Kerbtray. This utility places an icon in the System Tray that you can double-click to view a list of tickets and details about the ticket contents. Figure shows an example.

    Figure. Kerbtray window showing ticket list.


  • KLIST. This command-line utility is derived from the classic MITv5 Kerberos utility of the same name. Here is an example listing:

    C:\>klist tickets
    Cached Tickets: (2)
       Server: krbtgt/[email protected]
          KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
          End Time: 11/25/2001 19:55:37
          Renew Time: 12/2/2001 9:55:37
       Server: [email protected]
          KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
          End Time: 11/25/2001 19:55:37
          Renew Time: 12/2/2001 9:55:37

Cross-Domain Authentication

One of the most powerful features of Kerberos is its capability to handle transitive cross-realm authentications. This means that a user in one domain can access a security object (NTFS file or folder, AD object, Service, or Registry key) in any other domain in a forest as long as an administrator has configured the object's security to authorize access.

Figure shows an example of a cross-domain authentication transaction. In the example, a user in a child domain in one tree is trying to access a shared folder on a member server in a child domain in another tree. The roots of the two trees share a two-way trust.

Figure. Forest of domains showing cross-domain authentication.


Domain controllers in one domain cannot issue session tickets for member servers in another domain. Recall that domains form separate naming contexts in Active Directory. A domain controller only has access to its own naming context. (A global catalog server has a partial replica of every Domain naming context, but the GC does not contain all the information necessary to build a session ticket.)

For the same reason, Kerberos clients from one domain cannot go directly to a KDC in a remote domain to obtain a session ticket to a server in that domain. The client has no credentials in the remote Domain naming context.

The local domain controller supports cross-domain access by obtaining a cross-realm TGT from its parent domain on behalf of the user. It returns this cross-realm TGT to the client along with a referral to the parent domain.

The domain controller can obtain the cross-domain TGT thanks to a Kerberos feature called delegation. Using delegation, a service on one machine can obtain TGTs or session tickets on behalf of a user on another machine. This is a powerful feature and one that represents a security vulnerability if it is not handled correctly. We'll take a closer look at delegation in the next topic.

The client follows up on the referral by submitting the cross-realm TGT to a domain controller in the parent domain and asking once again for a session ticket to the target server. If the server is not in that domain, the domain controller obtains a cross-realm TGT either to its own parent or to the top domain in the tree that contains the target domain.

Using this process, the client "walks the tree," asking each domain in its path for a ticket to the target server and obtaining a cross-realm TGT and a referral until it finally arrives at the domain that contains the target server. At this point, the client submits its cross-realm TGT to a domain controller in the target domain. The domain controller validates the TGT and issues a session ticket to the target server.

Part of the validation performed by the domain controller includes a determination that each domain transited (crossed by) by the client is trusted by domains on either side. The domain controller knows the domains transited by the client because that information is stored in the cross-realm TGT. The domain controller knows the forest structure based on partition information in Active Directory (also known as knowledge).

From this point, the transaction proceeds very much like a regular Kerberos transaction. The client submits the session ticket and an authenticator to the member server and is granted access. The PAC in the session ticket originated in a remote domain, so the user will only be authorized to access resources on the server if someone has added the user to the DACL on the resources.

Short-Cut Trusts

The example in the previous section demonstrated how transitive, two-way Kerberos trusts make it possible for a user to access resources anywhere in the forest by logging on to one domain.

In an extensive, multi-domain environment, you may experience performance problems with cross-domain authentication. This slowdown is caused because the client is forced to communicate across the WAN when it walks the tree to get cross-realm authentication, as shown in Figure.

15. Forest showing short-cut trust between two child domains.


If the delays are too long and your users complain, you can shorten the process by creating a short-cut trust between one domain and another in a forest. The short-cut trust tells the KDC that it can go directly to the target domain for a cross-domain TGT and avoid walking the tree.

Kerberos Delegation

In the classic NTLM authentication shown in Figure, there is no support for pass-through authentication from one server to another server. This limits the ability of NT to support so-called n-tier applications. N-tier applications use a middle server to field user requests and then pass the request to one or more back-end servers.

16. Forest showing short-cut trust between two child domains.


Because of the restrictions in NTLM, applications such as web front ends or Object Resource Brokers (ORBs) are required to log on to the back-end server using credentials stored at the middle server. This is commonly done using accounts and passwords embedded in ODBC connections or ActiveX Data Object (ADO) connections or third-party application data structures.

The problem with this sort of configuration is that all the user accounts essentially multiplex through the middle server into a single account that touches the backend servers. This creates a security problem if the application on the middle server is somehow compromised. You also lose accountability for user access to the back-end server.

Kerberos makes it possible for a middle server to obtain a user's credentials and to use those credentials when accessing a back-end server. This can be done in one of two ways:

  • Forwardable tickets. In this configuration, the middle server asks the client to obtain a session ticket for the back-end server. The middle server then uses this ticket to make connection to the application running on the back-end server. The ticket must be flagged as forwardable for this trick to work.

  • Proxiable tickets. In this configuration, the middle server asks the client to obtain a ticket-granting ticket for the domain and to give that TGT to the middle server. The middle server then uses the TGT to obtain a session ticket to the back-end server on behalf of the user. This TGT must be flagged as proxiable.

The difference between forwardable and proxiable tickets is the difference between lending a friend $10 for lunch and giving the friend a power of attorney and your checkbook.

The middle server can obtain Kerberos tickets to make it appear to be any user in the forest, so it occupies a highly secure position. For this reason, standard servers cannot obtain forwardable or proxiable tickets. A server must be flagged as "Trusted for Delegation" before it can obtain Kerberos tickets on behalf of a user.

Additional Kerberos Benefits

You might look at all these Kerberos features and say to yourself, "Fine. I like them. But we still have thousands of Windows 98 and NT4 workstations and hundreds of NT4 servers and we aren't going to be upgrading them overnight. I guess we'll have to forgo all those nifty features for a good, long while."

Fortunately, you don't have to wait as long as you might expect. As soon as you shift the domains in your forest to Native, the downlevel clients can participate in transitive trusts. In Native, domain controllers use transitive Kerberos trusts to obtain cross-domain TGTs and tickets on behalf of downlevel clients. Here's how it works.

When an LM or NTLM client attempts to touch an NT server in another Native domain, the server in the remote domain uses NTLM pass-through authentication to contact a domain controller in its domain.

The domain controller uses delegation to walk backward through the tree to obtain a cross-realm TGT on behalf of the client. This TGT is sufficient to authenticate the user in the remote domain.

The domain controller then completes the pass-through authentication and informs the member server that the user has been authenticated. It includes a classic NT data structure with the user's SIDs and security privileges that it obtained from the PAC in the cross-realm TGT.

Here's the bottom line. If you have Native domains in your forest, your NT, Windows 9x, and Samba clients get the following benefits:

  • Domain Local groups can be placed on local ACLs.

  • Users on the downlevel can access resources on any server in any domain (assuming they are on the local ACLs).

The reason this doesn't work in Mixed is because the Active Directory domains retain their classic NT limitations. After all, a client might authenticate on a classic BDC rather than an Active Directory domain controller and that eliminates the possibility of a cross-realm transaction.

Kerberos Policies

You can change certain Kerberos parameters by setting group policies. The policies are set in the Default Domain group policy. They are located under Computer Configuration | Windows Settings | Security Settings | Account Policies | Kerberos Policies. The polices are as follows:

  • Enforce user logon restrictions. Each member server in a domain has a set of local account policy restrictions. These restrictions stipulate things like local logon permissions and who has permission to access the computer across the network. By default, the KDC validates that a user meets a server's local account restrictions prior to issuing the user a session ticket to the server. This adds more steps to the logon process but saves traffic by preventing the user from getting a session ticket that cannot be used anyway because of the local restriction.

  • Maximum lifetime for service ticket. A service ticket is the same as a session ticket. Every session ticket has a default Time-To-Live of 10 hours. You can shorten this interval, but be careful not to make it too short or you will force the clients to obtain new tickets too often. The setting must be longer than 10 minutes and shorter than the Maximum lifetime for user ticket setting.

  • Maximum lifetime for user ticket. A user ticket is the same as a ticket-granting ticket. By default, a TGT has a 10-hour lifetime, after which it must be renewed. The minimum setting is 10 minutes and should not be set lower than the Maximum lifetime for service ticket setting.

  • Maximum lifetime for user ticket renewal. By default, TGTs can be renewed for a period of seven days. After that, the TGT expires and a new TGT must be obtained.

  • Maximum tolerance for computer clock synchronization. By default, the maximum clock skew is five minutes. This value should not be changed.

     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows