How the Kerberos Version 5 Authentication Protocol Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How the Kerberos Version 5 Authentication Protocol Works

In this section

• Kerberos SSP Architecture

• Kerberos Physical Structure

• Kerberos Processes and Interactions

• Network Ports Used by the Kerberos V5 Protocol

• Related Information

The Kerberos Network Authentication Service version 5, defined in RFC 1510, provides a means of verifying the identities of principals on an open, potentially insecure network. This section discusses how the RFC standard Kerberos version 5 authentication protocol is used in Windows Server 2003.

This section is divided into four subsections:

• Kerberos SSP Architecture illustrates how the Microsoft Security Support Provider Interface (SSPI) in Windows Server 2003 provides a mechanism of generic routines that can access the Kerberos Security Support Provider (SSP).

• Kerberos Physical Structure discusses components of the Windows Server 2003 implementation of Kerberos authentication. These components include keys, tickets, and the Key Distribution Center (KDC).

• Kerberos V5 Authentication Protocol Processes and Interactions illustrates how the Kerberos protocol is used in different situations, details what is included in Kerberos messages, and discusses other related technologies. The examples will show the complete process, including related components and processes that are not defined by the Kerberos Network Authentication Service. Some processes—such as how to find an authentication service, what credentials information is passed, and where credentials information is stored—are specific to Windows systems and might or might not differ in other implementations of the Kerberos protocol.

• Network Ports Used by the Kerberos V5 Protocol tabulates networks ports used during Kerberos authentication.

Kerberos SSP Architecture

Windows Server 2003 implements the Kerberos V5 authentication protocol as a Security Support Provider (SSP), a dynamic-link library (DLL) supplied with the operating system. Windows Server 2003 includes an SSP for NTLM authentication as well. By default, both SSPs are loaded by the Local Security Authority (LSA) on a Windows Server 2003 computer when the system boots. The system can use either SSP to authenticate network logons and client/server connections. Which SSP is used depends on the capabilities of the computer on the other side of the connection and the preferences of the individual application that is being used.

The Microsoft SSPI is the foundation for authentication in Windows Server 2003. That is, applications and infrastructure services that require authentication use SSPI to provide it.

The SSPI is the implementation of the Generic Security Service API (GSSAPI) in Windows Server 2003. For more information about GSSAPI, see RFC 2743 and RFC 2744 in the IETF RFC Database.

The default SSPs in Windows Server 2003—Negotiate (SPNEGO), Kerberos, NTLM, Schannel, and Digest authentication protocols—are plugged into the SSPI in the form of DLLs. Additional SSPs can be plugged in if they can interoperate with the SSPI.

SSPI Architecture graphic

The SSPI in Windows Server 2003 provides a mechanism that carries authentication tokens over the existing communication channel between the client and server. When two parties need to be authenticated so that they can communicate securely, the requests for authentication are routed to the SSPI, which completes the authentication process, regardless of the network protocol currently in use. The SSPI returns transparent binary large objects, which are then passed to the other side of the connection by the application, at which point they can be passed to the SSPI layer on that side. Thus, the SSPI enables an application to use various security models available on a computer or network without changing the interface to the security system.

The following table describes the SSP components that are plugged into the SSPI. Each of the protocols in the table is used in different ways in Windows Server 2003 to promote secure communication in an insecure network environment.

SSP Layer Components

Component	Description
Kerberos V5 authentication	An industry-standard protocol that is used with either a password or a smart card for interactive logon. It is also the preferred authentication method for services in Windows 2000 and Windows Server 2003.
NTLM authentication	A challenge-response protocol that is used to provide compatibility with versions of Windows earlier than Windows 2000.
Digest authentication	An industry standard that is used in Windows Server 2003 for Lightweight Directory Access Protocol (LDAP) and Web authentication. Digest transmits credentials across the network as an MD5 hash or message digest.
Schannel	An SSP that implements the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) Internet standard authentication protocols. Schannel is used for Web-based server authentication such as when a user attempts to access a secure Web server.
Negotiate	An SSP that can be used to negotiate a specific authentication protocol. When an application calls into SSPI to log on to a network, it can specify an SSP to process the request. If the application specifies Negotiate, Negotiate analyzes the request and picks the best SSP to handle the request based on customer-configured security policy.

Kerberos SSP

Windows Server 2003 implements the Kerberos V5 authentication protocol as an SSP, a DLL supplied with the operating system. The system uses the Kerberos SSP, Kerberos.dll, as its first choice for authentication. After the LSA establishes a security context for an interactive user, another instance of the Kerberos SSP can be loaded by a process running in the user's security context to support the signing and sealing of messages.

Because the Kerberos protocol is the preferred authentication protocol for Windows Server 2003, all domain services support the Kerberos SSP, including:

• Active Directory queries using the Lightweight Directory Access Protocol (LDAP)

• Remote server or workstation management using RPC calls

• Print services

• Client-server authentication

• Remote file access using the Common Internet File System/Server Message Block (CIFS/SMB)

• Distributed file system management and referrals

• Intranet authentication to Internet Information Services (IIS)

• Security authority authentication for Internet Protocol Security (IPSec)

• Certificate requests to Certificate Services for domain users and computers

Kerberos Physical Structure

Kerberos authentication provides a mechanism for mutual authentication between a client and a server on an open network—a network in which packets transmitted along the network could be monitored and modified at will. In order to provide secure authentication, Kerberos authentication uses symmetric keys, encrypted objects, and Kerberos services.

This subsection will cover the following topics:

• Keys Used in Kerberos Authentication

• Kerberos Tickets

• The Authenticator

• Credentials Cache

• Key Distribution Center

• The Kerberos Realm

Kerberos Components

Keys Used in Authentication

Why are keys needed?

The Kerberos protocol relies heavily on an authentication technique involving shared-secret keys. The basic shared-secret concept is quite simple: If a secret is known by only two people, then either person can verify the identity of the other by confirming that the other person knows the secret.

For example, suppose that Alice often sends messages to Bob, and that Bob needs to ensure that a message from Alice really has come from Alice before he acts on its information. They decide to solve their problem by selecting a password and agreeing to share the secret password between the two of them, but not with anyone else. If a message purported to be from Alice can somehow demonstrate that the sender knows the password, Bob can verify that the sender is indeed Alice.

The only question left for Alice and Bob to resolve is how Alice will show that she knows the password. She could include it somewhere in her messages, perhaps in a signature block at the end—Alice, Our$ecret. This would be simple and efficient and would be effective if Alice and Bob could be sure that no one else is reading their mail. Unfortunately, their messages pass over a network used by people like Carol, who uses a network analyzer to scan traffic in hope that one day she might spot a password. Thus, Alice must not prove that she knows the secret by including it in her message. To keep the password secret, she must show that she knows it without revealing it.

The Kerberos protocol solves this problem with secret key cryptography. Instead of sharing a password, communication partners share a cryptographic key, and they use knowledge of this key to verify one another's identity. In order for the technique to work, the shared key must be symmetric—that is, a single key must be capable of both encryption and decryption. One party proves knowledge of the key by encrypting a piece of information; the other proves knowledge of the key by decrypting the information.

Kerberos authentication relies on several keys and key types for encryption. Key types can include long-term symmetric keys, long-term asymmetric keys, and short-term symmetric keys. The authentication protocol was designed to use symmetric encryption, meaning that the same shared key is used by the sender and the recipient for encryption and decryption.

Long-Term Symmetric Keys: User, System, Service, and Inter-realm Keys

The long-term symmetric keys are derived from a password. The plaintext password is transformed into a cryptographic key by passing the text of the password through a cryptographic function. (All implementations of the Kerberos version 5 authentication protocol must support DES-CBC-MD5. Other algorithms are permissible.) The result of the cryptographic function is the key.

User keys

When a user is created, the password is used to create the user key. In Active Directory domains, the user key is stored with the user's object in the Active Directory. At the workstation, the user key is created when the user logs on.

System keys

When a workstation or a server joins a Windows domain, it receives a password. In the same manner as a user account, the system account's password is used to create the system key.

Service keys

Services use a key based on the account password they use to log on.

All KDCs in the same realm use the same service key. This key is based on the password assigned to the krbtgt account. Every Active Directory domain will have this built-in account.

Inter-realm keys

In order for cross-realm authentication to occur, the KDCs must share an inter-realm key. The realms can then trust each other because they share the key.

Active Directory domains that have a parent-child relationship share an inter-realm key. This inter-realm key is the basis of transitive trusts in Windows 2000 and Windows Server 2003. If a shortcut trust is created, the two domains will exchange a key specifically for their trust.

Kerberos SSP encryption key lengths

Kerberos SSP supports different encryption types and key lengths depending on the task to be completed and the options specified. Although the size of the key determines the degree of protection the key provides, key size does not significantly impact the size of the ticket. The following table lists the key lengths that Kerberos SSP supports for the various types of encryption.

Key Lengths for Encryption Types

Encryption Algorithm	Key Length
RC4-HMAC	128
DES-CBC-CRC	56
DES-CBC-MD5	56

Long-Term Asymmetric Keys: Public Key

Currently, public-key certificates stored on smart cards are the only long-term asymmetric keys in the Microsoft implementation of Kerberos authentication.

Short-Term Symmetric Keys: Session Keys

The session keys used for ticket-granting tickets (TGTs) and service tickets are short-lived and used only as long as that session or service ticket is valid.

Kerberos Tickets

The main component of Kerberos authentication is the ticket. The Kerberos messages are used to request and deliver tickets. There are two types of tickets used in Kerberos authentication, TGTs and service tickets.

Kerberos Ticket Requests

The Kerberos client sends ticket requests to the KDC:

Requested Ticket Type	KDC Service That Receives Request
TGT	Authentication service
Service ticket	Ticket-granting service

The ticket requests include:

• Requested properties (flags), such as whether the ticket is renewable.

• Requested encryption method.

Ticket-Granting Tickets

The KDC responds to a client's authentication service request by returning a service ticket for itself. This special service ticket is called a ticket-granting ticket (TGT). A TGT enables the authentication service to safely transport the requester's credentials to the ticket-granting service.

A TGT is:

• A user's initial ticket from the authentication service.

• Used to request service tickets.

• Meant only for use by the ticket-granting service.

TGTs are encrypted with a key shared by the KDCs. The client cannot read tickets. Only KDC servers can read TGTs to secure access to user credentials, session keys, and other information. Like an ordinary service ticket, a TGT contains a copy of the session key that the service (in this case the KDC) will use in communicating with the client. The TGT is encrypted with the KDC's long-term key.

From the client's point of view, a TGT is just another ticket. Before it attempts to connect to any service, the client first checks its credentials cache for a service ticket to that service. If it does not have one, it checks the cache again for a TGT. If it finds a TGT, the client fetches the corresponding TGS session key from the cache, uses this key to prepare an authenticator (described later in this document), and sends both the authenticator and the TGT to the KDC, along with a request for a service ticket for the service. In other words, gaining admission to the KDC is no different from gaining admission to any other service in the domain—it requires a session key, an authenticator, and a ticket.

From the KDC's point of view, TGTs enable it to avoid the performance penalties of looking up a user's long term key every time the user requests a service. The KDC looks up the user's long-term key only once, when it grants an initial TGT. For all other exchanges with this client, the KDC can decrypt the TGT with its own long-term key, extract the session key, and use that to validate the client's authenticator.

Service tickets

A service ticket enables the ticket-granting service (TGS) to safely transport the requester's credentials to the target server or service.

The KDC responds to the client's request to connect to a service by sending both copies of the session key to the client. The client's copy of the session key is encrypted with the key that the KDC shares with the client. The service's copy of the session key is embedded, along with information about the client, in a data structure called a service ticket. The entire structure is then encrypted with the key that the KDC shares with the service. The ticket—with the service's copy of the session key safely inside—becomes the client's responsibility to manage until it contacts the service.

A service ticket is used to authenticate with services other than the TGS and is meant only for the target service.

A service ticket is encrypted with a service key, which is a long-term key shared by the KDC and the target service. Thus, although the client manages the service ticket, the client cannot read it. Only the KDC and the target service can read tickets, enabling secure access to user credentials, the session key, and other information.

Note

• The KDC is simply providing a ticket-granting service. It does not keep track of its messages to make sure they reach the intended address. No harm will be done if the KDC's messages fall into the wrong hands. Only someone who knows the client's secret key can decrypt the client's copy of the session key. Only someone who knows the server's secret key can read what is inside the ticket.

When the client receives the KDC's reply, it extracts the ticket and the client's copy of the session key, putting both aside in a secure cache (located in volatile memory, not on disk). When the client wants admission to the server, it sends the server a message that consists of the ticket, which is still encrypted with the server's secret key, and an authenticator, which is encrypted with the session key. The ticket and authenticator together are the client's credentials to the server.

Benefits of service tickets

The server does not have to store the session key that it uses in communicating with clients. It is the client's responsibility to hold a ticket for the server in its credentials cache and present the ticket each time it wants access to the server. Whenever the server receives a service ticket from a client, the server can use its secret key to decrypt the ticket and extract the session key. When the server no longer needs the session key, it can discard it.

The client does not need to go back to the KDC each time it wants access to this particular server. Service tickets can be reused. To guard against the possibility that someone might steal a copy of a ticket, service tickets have an expiration time that is specified by the KDC in the ticket's data structure.

How long a ticket is valid depends on the policy for the realm. Although the RFC recommends a maximum ticket lifetime of one day, in both MIT Kerberos 5 Release 1.3.1 and the Windows 2000 or Windows Server 2003 implementations of the Kerberos protocol, tickets are good for no longer than 10 hours by default, about the length of a normal logon session. When the user logs off, the credentials cache is flushed and all service tickets—as well as all session keys—are destroyed.

What Is in a Ticket?

For our purpose here, it is enough to list the fields in a ticket and to describe the information they contain. The exact data structures for tickets as well as messages can be found in RFC 1510.

The first three fields in a ticket are not encrypted. The information is in plaintext so that the client can use the information to manage tickets in its cache.

Ticket Contents

Field Name	Description
Ticket Version Number	5
Realm	Name of the realm (domain) that issued the ticket. A KDC can issue tickets only for servers in its own realm, so this is also the name of the server's realm.
Server Name	Name of the server.
	The following fields are encrypted with the server's secret key.
Flags	Options that specify how and when the ticket can be used. See table below for details about ticket flags.
Key	The session key used to encrypt and decrypt client and target server messages.
Client Realm	Name of the requester's realm.
Client Name	Requester's name.
Transited	Lists the Kerberos realms that took part in the authentication of the client during cross-realm authentication.
Authentication Time	Time of initial authentication by the client. The KDC places a timestamp in this field when it issues a TGT. When it issues tickets based on a TGT, the KDC copies the authentication time of the TGT to the authentication time of the ticket. An application could have a policy to reject tickets that were based on "old" TGTs, requiring the client to obtain a new TGT and then a new service ticket.
Start Time	Time after which the ticket is valid.
End Time	Ticket's expiration time.
Renew Till	(Optional) Maximum end time that can be set in a ticket with a RENEWABLE ticket flag.
Client Address	(Optional) One or more addresses from which the ticket can be used. If omitted, the ticket can be used from any address.
Authorization-Data	(Optional) This field contains authorization data for the client. In MIT's implementation of the Kerberos protocol, this field normally contains access restrictions. For example, if this were a ticket for a print server sent by a client wishing to print a file, the file name could be included here, restricting the print server's access on behalf of the client to only this file. In the Microsoft implementation, this field is significant because it contains the user's SID and the SIDs of groups the client belongs to—data which is used to build the client's access token (the privilege attributes for the client). The Kerberos service does not interpret the contents of this field. Interpretation is left up to the service requesting credentials.

The following table lists and describes the Kerberos ticket Flag field. The Flag field is a bit-field in which options are set by turning a particular bit on (1) or off (0). Although the field is 32 bits long, only 11 ticket flags are of interest to Kerberos administrators.

Ticket Flags

Flag	Description
FORWARDABLE	(TGT only). Tells the ticket-granting service that it can issue a new TGT—based on the presented TGT—with a different network address based on the presented TGT.
FORWARDED	Indicates either that a TGT has been forwarded or that a ticket was issued from a forwarded TGT.
PROXIABLE	(TGT only). Tells the ticket-granting service that it can issue tickets with a network address that differs from the one in the TGT.
PROXY	Indicates that the network address in the ticket is different from the one in the TGT used to obtain the ticket.
MAY-POSTDATE	(TGT only). Tells the ticket-granting service (TGS) that a postdated ticket can be issued.
POSTDATED	Indicates that the ticket has been postdated.
INVALID	Indicates that the ticket is invalid and must be validated by the KDC before use. A postdated ticket is flagged as invalid until its valid start time.
RENEWABLE	Used in combination with the End Time and Renew Till fields to cause tickets with long life spans to be renewed at the KDC periodically.
INITIAL	Indicates that a ticket was issued using the authentication service (AS) exchange and not issued based on a TGT.
PRE-AUTHENT	Indicates that the client was authenticated by the KDC before a ticket was issued. This flag usually indicates the presence of an authenticator in the ticket. It can also flag the presence of credentials taken from a smart card logon.
HW-AUTHENT	Indicates that the initial authentication required the use of hardware.

What information clients have about tickets

A client needs to have some information about what is inside tickets and TGTs in order to manage its credentials cache. When the KDC returns a ticket and session key as the result of an authentication service (AS) or ticket-granting service (TGS) exchange, it packages the client's copy of the session key in a data structure that includes the information in the following ticket fields: Authentication Time, Start Time, End Time, and Renew Till. The entire structure is encrypted in the client's key and returned with the KRB_AS_REP or KRB_TGS_REP messages.

Kerberos authorization data for Windows accounts

The Kerberos protocol describes a number of fields to be used in the authentication exchange. One of these, the optional authorization data field, is intended to be specific to the end service, in this case, Microsoft authorization. The Microsoft implementation follows the Kerberos specification (RFC 1510) by using the authorization field to store information about user identity and group membership. This information is stored in Microsoft authorization data that is generated by a domain controller during an AS or TGS request. The Microsoft authorization data includes the following groups of information:

• Credential information. Information about the ticket and the client, such as Group IDs, which list relative IDs (RIDs) that belong to the client for his or her domain and groups.

• Client information. Ensures that the ticket belongs to the client who is submitting it.

• Supplemental credentials. Returned by the KDC service to enable PKINIT.

• Signatures. The Microsoft authorization data contains two digital signatures, one for the domain controller and one for the server offering the service. These signatures are used to prevent clients or untrusted services from generating their own forged Microsoft authorization data.

• PAC-request pre-authentication data. Normally, the Microsoft authorization data is included in every pre-authenticated ticket received from an AS request. However, a client can also explicitly request — with the privilege attribute certificate (PAC)-request pre-authentication data field — to include or not include SIDs. If the field is present, the account SIDs will be included. If the field is not present, SIDs will not be included.

For more information about Microsoft authorization data present in Kerberos tickets issued by Windows domain controllers, see "Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access Control to Resources," a Windows Development (General) topic on MSDN.

How the KDC limits a ticket's lifetime

Each ticket has a start time and an expiration time. At any time after the start time but before the expiration time, a client holding a ticket for a service can present the ticket and gain access to the service, no matter how many times the client has used the ticket before. In order to reduce the risk that a ticket or the corresponding session key might be compromised, administrators can set the maximum lifetime for tickets. The maximum lifetime for tickets setting is an element of Kerberos policy.

When a client asks the KDC for a ticket to a service, the client can request a specific start time. If this time is missing from the request or is a time in the past, the KDC sets the ticket's start time field to the current time.

Whether or not a client specifies a start time, its request must include a desired expiration time. The KDC determines the value in a ticket's End Time field by adding the maximum ticket life fixed by Kerberos policy to the value in the ticket's Start Time field. It then compares the result with the requested expiration time. Whichever time is sooner becomes the ticket's end time.

What happens when tickets expire

The KDC does not notify clients when service tickets or TGTs are about to expire. Furthermore, other than keeping short-term records needed to prevent replay attacks, it does not keep track of transactions with clients.

If a client presents an expired service ticket when requesting a connection to a server, the server returns an error message. The client must request a new service ticket from the KDC. After a connection is authenticated, however, it no longer matters whether the service ticket remains valid. Service tickets are used only to authenticate new connections with servers. Ongoing operations are not interrupted if the service ticket used to authenticate the connection expires during the connection.

If a client presents an expired TGT when requesting a service ticket from the KDC, the KDC responds with an error message. The client must request a new TGT, and to do that it needs the user's long-term key. If the client did not cache the user's long-term key during the initial logon process, the client might have to ask the user for a password and derive the long-term key.

Renewable TGTs

When tickets are renewable, session keys are refreshed periodically without issuing a completely new ticket. If Kerberos policy permits renewable tickets, the KDC sets a RENEWABLE flag in every ticket it issues and sets two expiration times in the ticket. One expiration time limits the life of the current instance of the ticket; the second expiration time sets a limit on the cumulative lifetime of all instances of the ticket.

The expiration time for the current instance of the ticket is held in the End Time field. As with non-renewable tickets, the value in the End Time field equals the value in the Start Time field plus the value of the maximum ticket life specified by Kerberos policy. A client holding a renewable ticket must send it—presenting a fresh authenticator as well—to the KDC for renewal before the end time is reached. When the KDC receives a ticket for renewal, it checks the value of a second expiration time held in the Renew Till field. This value is set when the ticket is first issued. It equals the value in the tickets Start Time field plus the value of the maximum cumulative ticket life specified by Kerberos policy. When the KDC renews the ticket, it checks to determine if the renew-till time has not yet arrived. If it has not, the KDC issues a new instance of the ticket with a later end time and a new session key.

This means that administrators can set Kerberos policy so that tickets must be renewed at relatively short intervals—every day, for example. When tickets are renewed, a new session key is issued, minimizing the value of a compromised key. Administrators can also set cumulative ticket life for a relatively long period—one week or one month, for example. At the end of that time, the ticket expires and is no longer valid for renewal.

The Authenticator

Whenever a client sends a ticket to a target server—whether the server is the TGS or some other network server or resource—the client also includes an authenticator in the message. The authenticator verifies that the client listed as the sender in the ticket really is the ticket's source.

Why is an authenticator necessary?

The target server can trust the contents of the ticket because the ticket is encrypted with the target server's secret key. However, the target server cannot trust that the ticket was really sent by the client specified in the ticket. The ticket could have been stolen and is now being included in an imposter's message.

How does the authenticator work?

• The authenticator is encrypted with the session key created by the KDC to be used between the client and the target server. Only the client and the target server can access the session key.

• The target server uses its secret key to decrypt the ticket, finds the session key inside the ticket, and uses it to decrypt the authenticator.

• If the target server can successfully decrypt the authenticator and if the authenticator's data is accurate, then the target server will trust the source of the ticket.

The authenticator's timestamp

The timestamp is perhaps the most important piece of data in the authenticator. A domain's Kerberos policy and policies established by applications typically require that the timestamp be within minutes of the time on the target server. Otherwise, the authenticator and the ticket will be rejected. This helps prevent message replay.

Although no authenticator is included in the initial authentication service request message (explained later in this document), the message does include the client's timestamp in the pre-authentication field.

What is in an authenticator?

The following table lists and describes authenticator fields. The exact data structures for authenticators as well as messages can be found in RFC 1510.

Authenticator Fields

Field	Description
Checksum	A checksum of the data from the ticket-granting service request (KRB_TGS_REQ) or application server request (KRB_AP_REQ) message that the authenticator was a part of. This helps validate that the message sender was really the client.
Subkey	In a KRB_AP_REQ, this field specifies a subkey that the target server and the client will use to encrypt further communications, instead of using the TGS-supplied session key.
Sequence Number	An optional field that could be used to prevent replays. This sequence number might be based on the client nonce, for example.
Authorization Data	This optional field can include authorization data for specific applications. This is not the same as the Authorization Data field that carries the user's privilege attribute certificate (PAC).

Credentials Cache

On computers running Windows 2000, Windows XP, or Windows Server 2003, tickets and keys obtained from the KDC are stored in a credentials cache, an area of volatile memory protected by the LSA. The credentials cache is never paged to disk. All objects stored there are destroyed when a security principal logs off or when the system is shut down.

The credentials cache is managed by the Kerberos SSP, which runs in the LSA's security context. Whenever tickets and keys need to be obtained or renewed, the LSA calls the Kerberos SSP to accomplish the task.

Note

• In Windows XP and Windows 2000 with Service Pack 2 or later, TGT renewal is triggered when the TGT is used within 5 minutes of its expiration.

• In Windows Server 2003, periodically the system will automatically renew expiring TGTs.

The LSA also keeps a copy of an interactive user's hashed password. If the user's TGT expires during a logon session, the Kerberos SSP uses the LSA's copy of the hashed password to obtain a new TGT without interrupting the user's logon session. The password is not stored permanently on the computer, and the local copy of the hashed password is destroyed when the user's logon session is destroyed.

Hashed passwords for services and computers are handled differently than above. As in Windows NT, hashed passwords are stored in a secure area of the computer's registry. The registry is also used to store hashed passwords for user accounts on the local system, but local accounts are used only for access to computers in standalone mode, never for network access.

Key Distribution Center

The Key Distribution Center (KDC) is a service that runs on a physically secure server. The KDC maintains a database with account information for all security principals in its realm (the Kerberos equivalent of a Windows Server 2003 domain). Along with other information about each security principal, the KDC stores a cryptographic key known only to the security principal and the KDC. This key—also called the long-term key—is used in exchanges between the security principal and the KDC. In most implementations of the protocol, the long-term key is derived from a user's logon password.

As in other implementations of the Kerberos protocol, Microsoft implements the KDC as a single process that provides two services:

Authentication service (AS)

The AS issues TGTs good for admission to the ticket-granting service in its domain. Before network clients can get tickets for services, each client must get an initial TGT from the authentication service in the user's account domain.

Ticket-granting service (TGS)

The TGS issues tickets good for admission to other services in the TGS's domain or to the ticket-granting service of a trusted domain. When a client wants access to a service, it must contact the ticket-granting service in the service's account domain, present a TGT, and ask for a ticket. If the client does not have a TGT valid for admission to that ticket-granting service, it must get one through a referral process that begins at the ticket-granting service in the user account's domain and ends at the ticket-granting service in the service account's domain.

Windows Server 2003 implements the Key Distribution Center (KDC) as a domain service. It uses the domain's Active Directory as its account database and gets some information about users from the global catalog.

The KDC is located on every domain controller, as is the Active Directory directory service. Both services are started automatically by the domain controller's Local Security Authority (LSA) and run in the process space of the LSA. Neither service can be stopped. Windows Server 2003 ensures availability of these services by allowing each domain to have several domain controllers, all peers. Any domain controller can accept authentication requests and ticket-granting requests addressed to the domain's KDC.

The security principal name used by the KDC for an Active Directory domain is krbtgt, as specified by RFC 1510. An account for this security principal is created automatically when a new domain is created. The account cannot be deleted, nor can the name be changed.

A password is automatically assigned to the krbtgt account. The password for the krbtgt account is used to derive a secret key for encrypting and decrypting the TGTs that the KDC issues. Passwords for domain trusts are either automatically assigned or provided when the trust is established. The password for a domain trust is used to derive an inter-realm key for encrypting referral tickets. (Referral tickets are discussed later in this document.) Although passwords for domain trusts are changed automatically, passwords for trusts with non-Windows realms and the krbtgt accounts must be changed either manually or through a script.

All instances of the KDC within a domain use the domain account for the security principal krbtgt. A client addresses messages to a domain's KDC by including both the service's security principal name, krbtgt, and the name of the domain. Both items of information are also used in tickets to identify the issuing authority. For information about name forms and addressing conventions, see RFC 1510 in the IETF RFC Database.

Session Key Distribution: the Session Key

If each client were to need a unique key for every service, and if each service were to need a unique key for every client, key distribution could quickly become a tough problem to solve. Furthermore, the need to store and protect so many keys on so many computers would present an enormous security risk. Hypothetically, a network of n accounts would require n(n-1)/2 keys, where n is an integer greater than 1. Thus, a network of only 10 users, services, and systems would need 45 keys; a network of 100 accounts would need 4,950 keys. Every new user, service, or system would generate a new key pair for each interaction.

The name of the Kerberos protocol suggests how it solves the problem of key distribution. Kerberos (Cerberus), in Greek mythology, was the fierce, three-headed dog that guarded the gates of the Underworld. The Kerberos protocol—like Kerberos the guard—has three heads: a client, a server, and a trusted third party to mediate between the other two. The trusted intermediary in the protocol is the Key Distribution Center (KDC).

When a client wants to connect to a server, the client sends a request to the KDC, and the KDC distributes a unique, short-term session key for the two parties to use when they authenticate each other. The server's copy of the session key is encrypted in the server's long-term key. The client's copy of the session key is encrypted in the client's long-term key.

KDC Configuration

RFC 1510 recommends the following values for KDC configuration:

KDC configuration

Configuration Element	RFC 1510 Recommendation	Active Directory Domain Default Setting
Maximum ticket lifetime	One day	600 minutes (10 hours)
Maximum renewable lifetime	One week	Seven days
Empty addresses	Only when suitable restrictions appear in authorization data	Support empty addresses

For more information about Kerberos policy settings, see Account Policy Settings.

For more information about KDC configuration, see RFC 1510 in the IETF RFC Database.

Pre-authentication

By default, the KDC requires all accounts to use pre-authentication. However, pre-authentication can be disabled for individual accounts when necessary for compatibility with other implementations of the protocol.

Active Directory as a KDC account database

The account database that the KDC needs in order to obtain information about security principals is provided in Windows Server 2003 by the domain's Active Directory. Each principal is represented by an account object. The encryption key used in communicating with a user, computer, or service is stored as an attribute of that security principal's account object.

Only domain controllers are Active Directory servers. Because each domain controller keeps a writeable copy of the directory, you can create accounts, reset passwords, and modify group membership at any domain controller. Changes made to one replica of the directory are automatically propagated to all other replicas. Windows 2000 and Windows Server 2003 do not, however, implement the Kerberos replication protocol. Instead, the systems replicate the information store for Active Directory using a proprietary multi-master replication protocol over a secure channel between replication partners.

Physical storage of account data is managed by the Directory System Agent (DSA), a protected process integrated with the LSA on the domain controller. Clients of the directory service are never given direct access to the data store. Any client wanting access to directory information must use one of the supported Active Directory Service Interfaces (ADSI) to connect to the DSA and then search for, read, and write directory objects and their attributes.

Requests to access an object or attribute in the directory are subject to validation by Windows 2000 or Windows Server 2003 access control mechanisms. Like file and folder objects in the NTFS file system, objects in Active Directory are protected by Access Control Lists (ACLs) that specify who can access the object and in what way. Unlike files and folders, however, Active Directory objects have an ACL for each of their attributes. Thus, attributes for sensitive account information can be protected by more restrictive permissions than those granted for other attributes of the account.

The most sensitive information about an account is, of course, its password. Although an account object's password attribute stores an encryption key derived from a password, not the password itself, this key could be just as useful to an intruder. Therefore, access to an account object's password attribute is granted only to the account holder, never to anyone else, not even administrators. Only processes with Trusted Computer Base privilege—processes running in the security context of the LSA—are allowed to read or change password information.

In order to hinder an offline attack by someone with access to a domain controller's backup tape, an account object's password attribute is further protected by a second encryption using a system key. Administrators are given the option to choose where the system key is stored and which of several algorithms is used to encrypt password attributes. You can store the system key on removable media so that it can be safeguarded separately, or store it—protected by a dispersal mechanism—on the domain controller.

Service Principal Names

SPNs can only be registered by a domain administrator, with one exception—a system account can register an SPN for its computer account.

In Windows 2000, SPNs were canonicalized to the SAM account name—for example, Server1, Server1$. This caused issues when clients requested tickets for a service with a non-canonical name. The system was unable to detect the existing cached service ticket and would request a new service ticket for the service. In Windows Server 2003, on the other hand, the SPN requested is used without canonicalization.

SPNs are unique identifiers for services running on servers. Every service that will use Kerberos authentication needs to have an SPN set for it so that clients can identify the service on the network. If an SPN is not set for a service, then clients will have no way of locating that service. Without properly set SPNs, Kerberos authentication is not possible.

An SPN is registered in Active Directory under a user account as an attribute called Service-Principal-Name. The SPN is assigned to the account under which the service the SPN identifies is running. Any service can look up the SPN for another service. When a service wants to authenticate to another service, it uses that service's SPN to differentiate it from all of the other services running on that computer.

This is why SPNs are so crucial to constrained delegation (discussed later). When you set up a computer for delegation, one step of the process is to list the services on other computers that the computer is allowed to delegate to. This list forms a type of ACL. The services running on the other computers are identified by the SPNs that are issued to those services.

Additionally, in Windows Server 2003, KDCs will not issue a service ticket for an account that does not have an SPN. If a service account were simply a user account with a human-generated password, then that account would be more vulnerable to an offline dictionary attack. For an account without an SPN, the KDC will return KDC_ERR_S_PRINCIPAL_UNKNOWN. However, the context of the error will be KRB_ERR_MUST_USE_USER2USER, which has the description of "Server principal valid for user-to-user only."

In general, SPNs should be set at the time of account creation. Setting an SPN on an account is as important—from a security standpoint—as creating that account. Special accounts that were created for services are useless until an SPN is set on those accounts for whatever service will be running under them.

The following table lists, in alphabetical order, the built-in SPNs that are recognized for computer accounts.

Built-in SPNs Recognized for Computer Accounts

SPN	SPN	SPN	SPN
alerter	http	policyagent	scm
appmgmt	ias	protectedstorage	seclogon
browser	iisad	rasman	snmp
cifs	min	remoteaccess	spooler
cisvc	messenger	replicator	tapisrv
clipsrv	msiserver	rpc	time
dcom	mcsvc	rpclocator	trksvr
dhcp	netdde	rpcss	trkwks
dmserver	netddedsm	rsvp	ups
dns	netlogon	samss	w3svc
dnscache	netman	scardsvr	wins
eventlog	nmagent	scesrv	www
eventsystem	oakley	schedule
fax	plugplay

These SPNs are recognized for computer accounts if the computer has a host SPN. Unless they are explicitly placed on objects, a host SPN can substitute for any of the above SPNs.

Requirements for setting an SPN

Because multiple services can run simultaneously under the same account, setting an SPN requires four unique pieces of information. These four pieces of information uniquely identify any service running on a network and can be used to mutually authenticate to any service.

For each SPN that is set, the following information is required:

• The type of service, formally called a service class. This enables you to differentiate between multiple services running under the same account.

• The account under which the service is running.

• The computer on which the service is running, including any aliases that point to that computer.

• The port on which the service is running (optional if the default port for the service of that type is used such as port 80 for HTTP).

The syntax of an SPN itself is service/hostname:port, where:

• Service is the service class of the SPN.

• Hostname is the computer to which the SPN belongs.

• Port is the port on which the service that the SPN is registered to runs.

KDC key version numbers

Users can change their passwords, and therefore their keys, at any time. This poses a problem for all existing credentials that are encrypted with the older key, because the credentials would no longer be usable if the user expected to use the new key. Although this is merely inconvenient to users—who can simply get new tickets—long-running services such as batch jobs would be interrupted if there was no one available to get a new ticket with the new key for the job. To address this problem, clients keep a copy of their older key for a period of time after switching to a new password.

When parties exchange encrypted communications, they need a way to determine which keys to use to decrypt the data they have received. If there is only one key, this is easy. However, when there are many keys, some of which correspond to the same account—such as when passwords are changed—then this task becomes difficult. One way to find the right key is to try all available keys, but this wastes time and computing resources, particularly if the client has many keys to try.

To streamline this process, encrypted data includes a header that has information including a sort of serial number that is associated with the key and the encryption type used to encrypt the data. When a client receives an encrypted communication, it includes information about whose key set to use, as well as which particular key version to use to decrypt the data. This way, even if a ticket is encrypted with an older key, the recipient can still decrypt it by looking at the key version number, finding the correct key version, and decrypting the ticket. Eventually, tickets with outdated keys expire, and the system gradually shifts to using the new key in all cases, creating no problems for the user.

New to Windows Server 2003 is the read-only attribute ms-DS-KeyVersionNumber. When a password is changed, the key version number is incremented and the current value can be queried using ms-DS-KeyVersionNumber. Windows 2000 KDCs will always issue tickets with a key version number equal to 1. Windows Server 2003 KDCs only keep track of the latest key version number for a principal account because there is no reason for the KDC to use outdated keys.

Key version numbers also enable Windows Server 2003 to provide more informative errors when a message cannot be decrypted. In general cases, when information can not be decrypted, the system provides the error KRB_AP_ERR_MODIFIED, meaning that the encrypted information is not accessible, but with no further information. For example, the data could have been modified in transit, the data could have been malformed initially, or there could be no available key. Each of these possible causes requires troubleshooting at different locations and using different techniques.

On the other hand, using key version numbers can enable the system to communicate the source of the failure. For example, if the client has no key to match the key version number included in the header, the system responds with the error KRB_AP_ERR_BADKEYVER. This error message specifically informs the client that the appropriate key version is not available. The client can then resolve the failure by resetting the password, which resets the keys.

The key version number is generated each time a password is changed on long-lived keys—such as the key that results from a user password, the keys for computer accounts, or the keys for domain trusts. Key version numbers also are provided because they are required for compliance with the Kerberos RFC (1510).

Key version numbers are constructed from the update logon timestamp attribute which is updated in the SAM when a password is changed. The update logon timestamp is a 32-bit value that identifies the version of the keys generated from the password. Key version number functionality based on update logon timestamps is only available in domains that have Windows Server 2003 domain functionality.

Kerberos Realms and Active Directory Domains

With the release of Windows 2000, Active Directory domains became the implementation of Kerberos realms.

The RFC 1510 describes Kerberos realms and their organization as follows:

"The Kerberos protocol is designed to operate across organizational boundaries. A client in one organization can be authenticated to a server in another. Each organization wishing to run a Kerberos server establishes its own 'realm.'"

"Realms are typically organized hierarchically. Each realm shares a key with its parent and a different key with each child. If an inter-realm key is not directly shared by two realms, the hierarchical organization enables an authentication path to be easily constructed. If a hierarchical organization is not used, it might be necessary to consult some database in order to construct an authentication path between realms."

"Although realms are typically hierarchical, intermediate realms might be bypassed to achieve cross-realm authentication through alternative authentication paths (these might be established to make communication between two realms more efficient). It is important for the end-service to have information about which realms were transited when deciding how much faith to place in the authentication process. To facilitate this decision, a field in each ticket contains the names of the realms that were involved in authenticating the client."

It is clear from the RFC's discussion that the concept of Kerberos realms has similarities—such as organizational boundaries and trusts—to attributes of the Windows NT domains. Active Directory domains use inter-realm-key-based trusts and a hierarchical design. These inter-realm (also called inter-domain) keys are the basis of transitive trust in Active Directory domains.

Note

• In literature documenting Windows operating systems, the term "domains" might be used in place of place of the term "realms." In such cases, the term "realms" will be used to denote non-Windows Kerberos realms in the environment.

In Kerberos authentication, Active Directory domains fulfill all the requirements of Kerberos realms.

Kerberos Processes and Interactions

This subsection will cover the following topics:

• Kerberos V5 exchange and message summary

• Windows Server 2003–based examples:

  • Local logon

  • Domain logon

  • Single domain authentication

  • Simple cross-domain authentication

  • Cross-realm authentication and shortcut trusts

  • Untrusted domain

  • Delegation

• Kerberos V5 message details:

  • Authentication service exchange

  • Ticket-granting service exchange

  • Client/server authentication exchange

  • Credentials message

• Required technologies for Active Directory domains:

  • Kerberos and IP transport: UDP/TCP

  • DNS name resolution

Kerberos V5 Exchange and Message Summary

The RFC standard Kerberos version 5 authentication protocol communication sequences consist of six (five required and one optional) messages. These messages compose three types of exchanges (also known as sub-protocols), which are examined more closely later in this section.

Kerberos Exchange and Message Summary

The Authentication Service Exchange

1. Kerberos authentication service request (KRB_AS_REQ)

The client contacts the Key Distribution Center's authentication service for a short-lived ticket (a message containing the client's identity and—for Windows clients—SIDs) called a ticket-granting ticket (TGT). This happens at logon.

2. Kerberos authentication service response (KRB_AS_REP)

The authentication service (AS) constructs the TGT and creates a session key the client can use to encrypt communication with the ticket-granting service (TGS). The TGT has a limited lifetime. At the point that the client has received the TGT, the client has not been granted access to any resources, even to resources on the local computer.

Why use a TGT? Could the AS simply issue a ticket for the target server? Yes, but if the AS issued tickets directly, the user would have to enter a password for every new server/service connection. Issuing a TGT with a short lifespan (typically 10 hours) gives the user a valid ticket for the ticket-granting service, which in turn issues target-server tickets. The TGT's main benefit is that the user only has to enter a password once, at logon.

The Ticket-Granting Service Exchange

3. Kerberos ticket-granting service request (KRB_TGS_REQ)

The client wants access to local and network resources. To gain access, the client sends a request to the TGS for a ticket for the local computer or some network server or service. This ticket is referred to as the service ticket or session ticket. To get the ticket, the client presents the TGT, an authenticator, and the name of the target server (the Server Principal Name or SPN).

4. Kerberos ticket-granting service response (KRB_TGS_REP)

The TGS examines the TGT and the authenticator. If these are acceptable, the TGS creates a service ticket. The client's identity is taken from the TGT and copied to the service ticket. Then the ticket is sent to the client.

Note

• The TGS cannot determine if the user will be able to get access to the target server. It simply returns a valid ticket. Authentication does not imply authorization.

The Client/Server Exchange

5. Kerberos application server request (KRB_AP_REQ)

After the client has the service ticket, the client sends the ticket and a new authenticator to the target server, requesting access. The server will decrypt the ticket, validate the authenticator, and for Windows services, create an access token for the user based on the SIDs in the ticket.

6. Kerberos application server response (optional) (KRB_AP_REP)

Optionally, the client might request that the target server verify its own identity. This is called mutual authentication. If mutual authentication is requested, the target server will take the client computer's timestamp from the authenticator, encrypt it with the session key the TGS provided for client-target server messages, and send it to the client.

Local Logon Example

Users can log on to computers with either a domain account or an account local to the computer. When the user logs on with an account local to the computer, the user's credentials are authenticated using the local account database. Because the local computer does not act as a KDC, and because local logon does not require network access (for example, to contact a KDC), local authentication uses NTLM to authenticate the account.

Local Logon Sequence

1. After the Graphical Identification and Authentication (GINA) dynamic-link library has collected the user's logon information, it passes that information to the LSA for authentication.

2. The LSA simply passes the information on to the SSPI.

3. The SSPI does not determine whether the user is logging on locally or through a domain account. Because the Kerberos SSP is the default authentication provider, the authentication request is first passed to the Kerberos SSP.

4. The Kerberos SSP verifies that the logon target name is the same as the local computer name. If so, the Kerberos SSP returns an error message to the SSPI that no logon servers are available, just as if it had checked the network for a KDC and found none.

5. The SSPI now sends the request to the next security provider, NTLM. The authentication process used by the NTLM SSP is identical to versions used in Windows NT.

Domain Logon Example

If the user is a member of a domain, then the account database is on a domain controller. If you are logging on to one of the domain controllers for the domain you belong to, then the process it the same as for local logon as described above. If instead you are logging on to a member server or a domain controller of another domain, then Kerberos authentication will used if possible.

Users never directly access the system. The system impersonates the user and accesses resources based on the resource permissions granted to the user. This is a standard security feature of all versions of Windows NT, Windows 2000, and Windows Server 2003. The user logging on to a workstation never directly accesses even local resources. The local system impersonates the user just as a remote system would.

Because the local system relies on impersonation, the user who logs on to the domain must be authenticated as a valid local user. The only new component added to the domain logon process is Kerberos authentication prior to building an access token.

The authentication process for a domain user to access their computer is very similar to the process used to authenticate access to network resources—that is, the user must obtain a valid ticket for the local workstation.

• The Kerberos client requests and then receives a TGT from the KDC.

• The Kerberos client uses the TGT to request and then receive a service ticket for the local workstation from the KDC.

• The service ticket for a network resource would be encrypted with the system or service key depending on whether the resource is a system or service. The workstation has a system key created when the computer joined the domain. The service ticket for the workstation is encrypted with this key.

• The local LSA builds an access token from the credentials contained in the service ticket and then grants or denies the user access.

How Logging on the Workstation Works

Suppose the user has a network account in the domain tailspintoys.com. The user's workstation also belongs to tailspintoys.com. The user logs on to the network by pressing CTRL+ALT+DEL, which is the Secure Attention Sequence (SAS) on computers with a standard Windows configuration.

In response to the SAS, the workstation's Winlogon service switches to the logon desktop and calls the GINA DLL, a component loaded in Winlogon's process. The GINA is responsible for collecting logon data from the user, packaging it in a data structure, and sending everything to the LSA for verification. Other parties can develop replacement GINAs, but in this case Winlogon has loaded the standard component supplied with the operating system, MSGINA.DLL. Winlogon calls it, and the GINA displays the standard logon information dialog box.

The user types a user name and password. From the domains in a drop-down list, the user selects tailspintoys.com. When the user clicks OK to dismiss the dialog box, MSGINA returns the logon information to Winlogon. Winlogon sends the information to the LSA for validation by calling LsaLogonUser. This procedure is standard for any user logon regardless of the authentication method used.

At this point, the LSA begins to use the Kerberos V5 authentication protocol.

Kerberos Keys

A user key is derived from a password. After it receives a data structure with the user's logon data, the LSA converts the plaintext password to a cryptographic key by passing the text of the password through a cryptographic function. (All implementations of the Kerberos version 5 authentication protocol must support DES-CBC-MD5. Other algorithms are permissible.) The result of the cryptographic function is the user key.

The LSA saves the user key in the user credentials cache, where it can be retrieved when needed for TGT renewal or for NTLM authentication to servers that are not capable of Kerberos authentication.

In order to validate the user's logon information and set up the user's logon session on the computer, the LSA must obtain:

• A TGT good for admission to the ticket-granting service.

• A service ticket good for admission to the computer.

The LSA obtains these tickets by working through the Kerberos SSP, which exchanges messages directly with the KDC in tailspintoys.com. (The workstation has located a KDC through a DNS query. Every domain controller is a KDC and registers its role with DNS.)

The TGT is obtained in an authentication service (AS) exchange; the service ticket is obtained in a ticket-granting service (TGS) exchange.

Obtaining a TGT in the authentication service exchange

Message 1: Authentication Service Request

The Kerberos client on the workstation sends the message KRB_AS_REQ to the KDC in tailspintoys.com.

The message includes:

• The user principal name.

• The name of the account domain.

• Pre-authentication data encrypted with the user's key derived from the user's password.

Retrieving the user key

The KDC gets its copy of the user key from the user's record in its account database. When it receives a request from the Kerberos client on the user's workstation, the KDC searches its database for the user, pulls up the account record, and takes the user key from a field in the record.

This process—computing one copy of the key from a password, fetching another copy of the key from a database—actually takes place only once, when a user initially logs on to the network. Immediately after accepting the user's password and deriving the user's long-term key, the Kerberos client on the workstation requests a service ticket and TGS session key that it can use in subsequent transactions with the KDC during this logon session.

Verifying the user's identity

The KDC decrypts the pre-authentication data and evaluates the timestamp inside. If the timestamp passes the test, the KDC can be assured that the pre-authentication data was encrypted with the user key and thus verify that the user is genuine.

After it has verified the user's identity, the KDC creates credentials that the Kerberos client on the workstation can present to the ticket-granting service. For more information about how domain controllers create credentials in a Windows environment, see "How Access Tokens Work" in the Access Tokens Technical Reference.

Message 2: Authentication Service Reply

The KDC replies with KRB_AS_REP containing a service ticket for itself. This special service ticket is called a ticket-granting ticket (TGT). Like an ordinary service ticket, a TGT contains a copy of the session key that the service (in this case the KDC) will use in communicating with the user. The message that returns the TGT to the user also includes a copy of the session key that the user can use in communicating with the KDC. The TGT is encrypted in the KDC's long-term key. The user's copy of the session key is encrypted in the user's long-term key.

KRB_AS_REP Message Contents

The message includes:

• A TGS session key for the user to use with the TGS, encrypted with the user key derived from the user's password.

• A TGT for the KDC in tailspintoys.com, encrypted with the TGS key.

  The TGT includes:

  • A TGS session key for the KDC to use with the user.

  • Authorization data for the user.

  The authorization data includes:

  • The SID for the user's account.

  • SIDs for security groups which the user is a member of in the domain tailspintoys.com.

  • SIDs for universal groups in the enterprise that include either the user or one of the domain groups the user is a member of.

When the client receives the KDC's reply to its initial request, the client uses its cached copy of the user key to decrypt its copy of the session key. It can then discard the user key derived from the user's password, for it is no longer needed. In all subsequent exchanges with the KDC, the client uses the TGS session key. Like any other session key, this key is temporary, valid only until the TGT expires or the user logs off. For that reason, the TGS session key is often called a logon session key.

From the client's point of view, a TGT is just another ticket. Before the client attempts to connect to any service, the client first checks the user credentials cache for a service ticket to that service. If it does not have one, it checks the cache again for a TGT. If it finds a TGT, the LSA fetches the corresponding logon session key from the cache, uses this key to prepare an authenticator, and sends both the authenticator and the TGT to the KDC, along with a request for a service ticket for the service. In other words, gaining admission to the KDC is no different from gaining admission to any other service in the domain—it requires a session key, an authenticator, and a ticket (in this case, a TGT).

From the KDC's point of view, TGTs enable the KDC to avoid the performance penalties of looking up a user's long term key every time the user requests a service. The KDC looks up the user key only once, when it grants an initial TGT. For all other exchanges with this user, the KDC can decrypt the TGT with its own long-term key, extract the logon session key, and use that to validate the user's authenticator.

Obtaining a service ticket in the ticket-granting service exchange

Message 3: Ticket-Granting Service Request

The Kerberos client sends the message KRB_TGS_REQ to the KDC in tailspintoys.com.

The message includes:

• The name of the target computer.

• The name of the target computer's domain.

• The user's TGT.

• An authenticator encrypted with the session key the user shares with the KDC.

Message 4: Ticket-Granting Service Reply

The KDC responds to the user's request to connect to a server by sending both copies of the session key to the user. The user's copy of the session key is encrypted with the key that the KDC shares with the user. The workstation's copy of the session key is embedded, along with information about the user, in a data structure called a service ticket. The entire structure is then encrypted with the key that the KDC shares with the user. The ticket—with the user's copy of the session key safely inside—becomes the workstation's responsibility to manage.

KRB_TGS_REP Message Contents

The KRB_TGS_REP message includes:

• A session key for the user to share with the computer encrypted with the session key the user shares with the KDC.

• The user's service ticket to the computer, encrypted with the computer's secret key.

  The service ticket includes:

  • A session key for the computer to share with the user.

  • Authorization data copied from the user's TGT.

When the Kerberos client receives the KDC's reply, it extracts the ticket and the user's copy of the session key, putting both in the user credentials cache (located in volatile memory, not on disk).

Note

• The KDC is simply providing a ticket-granting service. It does not keep track of its messages to make sure they reach the intended address. No harm will be done if the KDC's messages fall into the wrong hands. Only someone who knows the user's secret key can decrypt the user's copy of the session key. Only someone who knows the client's secret key can read what is inside the ticket.

Getting the User's Credentials to Winlogon

After credentials reach the workstation, the Windows Server 2003 access token creation process is the same as that of Windows NT versions. The LSA on the workstation receives the user's service ticket, decrypts the service ticket with the system key stored in its credentials cache, and then extracts the authorization data. The privilege attribute certificate (PAC) is taken from the service ticket and used to create the user's access token. The LSA then queries the local SAM database to discover whether the user is a member of any security groups local to the computer, and whether memberships in those groups grant the user any special rights on the local computer. It adds any SIDs returned by this query to the list taken from the ticket's authorization data. The entire list is then used to build an access token, and a handle to the access token is returned to Winlogon, along with an identifier for the user's logon session and confirmation that the logon information was valid.

Winlogon creates a window station and several desktop objects for the user, attaches the user's access token, and starts the shell process the user will use to interact with the computer. The user's access token is subsequently inherited by any application process that the user starts during the logon session.

When the user logs off, the credentials cache is flushed and all service tickets—as well as all session keys—are destroyed.

Single Domain Authentication Example

The process used to access resources and services on another system works basically the same as the logon example above except that the service ticket will need to be sent to the remote system. Except for the Kerberos authentication, security access checks are nearly identical with those of Windows NT 4.0 and earlier versions.

In the following example, both the user and service are in tailspintoys.com, the user has already logged on, and the user has requested and received a ticket for the workstation. The client wants to access \\server\shared folder to read a file. The process follows this sequence:

• Client and server negotiate a security package to use for authentication. They choose Kerberos.

• The client sends the service ticket (containing user credentials in the PAC) to the server.

• If the server accepts the ticket (that is, is able to decrypt the ticket with its secret key), then the server creates an access token for the user based on the PAC.

• The client redirector sends a server message block (SMB) message requesting file access.

• Server security compares file permissions with the user's credentials and grants or denies access.

After Workstation Logon

When the user attempts to use the service on the remote server, the user has already logged on to the local workstation. Thus, the user's credentials cache will have a TGT and a session key for the domain the user's account resides in. This TGT is used to request a ticket for the service.

Message 3: KRB_TGS_REQ

Because the TGT will expire within a few hours, the Kerberos client must check the expiration time before requesting additional tickets. If the TGT is expired, then the Kerberos client must send a KRB_AS_REQ to get another TGT.

The Kerberos client on the user's workstation requests credentials for the service by sending the KDC a Kerberos ticket-granting service request (KRB_TGS_REQ). This message includes the user's name, an authenticator encrypted with the user's logon session key, the TGT obtained in the AS exchange from workstation logon, and the name of the service for which the user wants a ticket.

Note

• The KRB_TGS_REQ message will typically be sent to the same domain controller that issued the TGT. However, TGS requests can be made to any domain controller. Thus, if the original KDC becomes unavailable, the client can discover a new KDC through a DNS query and then send a KRB_TGS_REQ there.

When the KDC receives KRB_TGS_REQ, it decrypts the TGT with its own secret key, extracting the user's TGS session key (logon session key). It uses the session key to decrypt the authenticator and evaluates that. If the authenticator passes the test, the KDC extracts the user's authorization data from the TGT and creates another session key for the client to use with the service. The KDC encrypts one copy of this new session key with the user's TGS session key. It embeds another copy of the session key in a ticket, along with the user's authorization data, and encrypts the ticket with the service's key. The KDC then sends these credentials back to the client in a Kerberos ticket-granting service reply (KRB_TGS_REP).

Message 4: KRB_TGS_REP

When the Kerberos client receives the reply, it uses the user's TGS session key to decrypt the session key to use with the service, and stores the key in its credentials cache. Then it extracts the ticket to the service and stores that in its cache.

Message 5: Kerberos Application Request (KRB_AP_REQ)

The Kerberos client on the user's workstation requests service from the service by sending the service a Kerberos application request (KRB_AP_REQ).

KRB_AP_REQ Message Contents

This message contains:

• An application option flag indicating whether to use session key. (The setting of this flag is one of the options in configuring Kerberos applications. The user is never asked.)

• An application option flag indicating whether the client wants mutual authentication.

• The service ticket obtained in the TGS exchange.

• An authenticator encrypted with the session key for the service.

Message 6: KRB_AP_REP (Optional)

The service receives KRB_AP_REQ, decrypts the ticket, and extracts the user's authorization data and the session key. The service uses the session key to decrypt the user's authenticator and then evaluates the timestamp inside. If the authenticator passes the test, the service looks for a mutual authentication flag in the client's request. If the flag is set, the service uses the session key to encrypt the time from the user's authenticator and returns the result in a Kerberos application reply (KRB_AP_REP). If the flag is not set, then no response is needed.

When the client on the user's workstation receives KRB_AP_REP, it decrypts the service's authenticator with the session key it shares with the service and compares the time returned by the service with the time in the client's original authenticator. If the times match, the client knows that the service is genuine.

Building an access token from a Kerberos service ticket

After credentials reach the server, the Windows Server 2003 token creation process is the same as that of earlier Windows versions. After the server authenticates the client using Kerberos authentication, the PAC is taken from the service ticket and used to create the user's access token.

Remote resource authorization

After the service has an access token for the user, it still needs to verify that the user is authorized to do what the user wants to do. Except for the Kerberos authentication, security access checks are nearly identical with those of Windows NT 4.0 and earlier versions:

1. The client redirector sends an SMB message requesting file access.

2. Server security compares file permissions with the user's credentials and grants or denies access.

3. If access is granted, the connection proceeds.

During the connection, the session key can be used to encrypt application data, or the client and server can share another key for this purpose.

Simple Cross-Realm Authentication and Examples

The functions of the KDC are divided into two distinct services: an authentication service whose job is to issue TGTs, and a ticket-granting service whose job is to issue service tickets. This division of labor enables the Kerberos protocol to operate across domain boundaries. A client can get a TGT from the authentication service of one domain and use it to get service tickets from the ticket-granting service of another domain.

The Basic TGS Referral Process

Clients typically need to request access to services outside of a single Kerberos realm. Whether in a pure Active Directory forest or in a mixed Kerberos environment, the referral process is the same. When a client requests a service ticket for a server in a remote Kerberos realm, the request is sent to the KDC in the client account's realm. The KDC determines that the server is in another realm, so it cannot issue a service ticket. This can only be done by a KDC in the target server's realm. So, instead of issuing the service ticket, the KDC in the client account's realm issues a TGS referral.

The TGS referral message is a normal KRB_TGS_REP message containing:

• A TGT for another trusted realm.

• Information indicating the KRB_TGS_REP is a referral to another TGS.

The client recognizes that the KRB_TGS_REP is a referral message and sends the TGT in a new KRB_TGS_REQ message to the remote realm to get the service ticket it needs.

Cross-Realm Authentication Between Two Realms

To understand how cross-realm authentication works, first consider the simplest case: a network with only two realms, East and West. If administrators for these realms are members of the same organization, or if for some other reason they are willing to treat the other realm's users as their own, they can enable authentication across realm boundaries simply by sharing an inter-realm key. (In Active Directory domains this happens automatically when two domains establish a trust relationship.) After the inter-realm key is shared, the ticket-granting service of each realm is registered as a security principal with the other realm's KDC. As a result, the ticket-granting service in each realm can treat the ticket-granting service in the other realm as just another service, something for which properly authenticated clients can request and receive service tickets.

When a user with an account in West wants access to a server with an account in East, the process is:

1. The Kerberos client on the user's workstation sends a request for a service ticket to the ticket-granting service in the user account's realm, West.

2. The ticket-granting service in West determines that the desired server is not a security principal in its realm, so it replies by sending the client a referral ticket—a TGT encrypted with the inter-realm key that the KDC in West shares with the KDC in East.

3. The client uses the referral ticket to prepare a second request for a service ticket, and this time sends the request to the ticket-granting service in the server account's realm, East.

4. The ticket-granting service in East uses its copy of the inter-realm key to decrypt the referral ticket. If decryption is successful, it sends the client a service ticket to the desired server in its domain.

Three-Realm Referral Example

The referral process is more complicated on networks with more than two realms. In theory, the KDC in each realm could establish a direct link to the KDC in every other realm on the network, in each case sharing a different inter-realm key. In practice, however, the number and complexity of these relationships could become unmanageable, especially on a large network. The Kerberos protocol solves the problem by making direct links unnecessary. A client in one realm can get a ticket to a server in another realm by traveling a referral path through one or more intermediate realms.

Three-Realm Referral

For example, consider a network with three realms, east.tailspintoys.com, west.tailspintoys.com, and tailspintoys.com. The KDC in east.tailspintoys.com does not share an inter-realm key with the KDC in west.tailspintoys.com, but both KDCs do share inter-realm keys with tailspintoys.com. In this case, when a user with an account in west.tailspintoys.com wants access to a server with an account in east.tailspintoys.com, the referral path begins at the KDC for the user account's realm, west.tailspintoys.com, passes through an intermediate realm, tailspintoys.com, and ends at the KDC for the server account's realm, east.tailspintoys.com. The client must send its request for a service ticket three times, to three different KDCs. The three TGS exchanges are:

1. The client requests the KDC for west.tailspintoys.com to give it a ticket to the server in east.tailspintoys.com.

   The KDC for west.tailspintoys.com replies by sending the client a referral ticket to the KDC for tailspintoys.com. This ticket is encrypted in the inter-realm key that west.tailspintoys.com shares with tailspintoys.com.

2. The client requests the KDC for tailspintoys.com to give it a ticket to the server in east.tailspintoys.com.

   The KDC for tailspintoys.com replies by sending the client a referral ticket to the KDC for east.tailspintoys.com. This ticket is encrypted in the inter-realm key that tailspintoys.com shares with east.tailspintoys.com.

3. The client requests the KDC for east.tailspintoys.com to give it a ticket to the server in east.tailspintoys.com.

   The KDC for east.tailspintoys.com can decrypt the TGT from tailspintoys.com. The TGT has the user's credentials and verifies that they have not been tampered with because they were encrypted with a key only the two KDC have. The KDC for east.tailspintoys.com sends back a ticket for the server.

For a detailed look at the complete authentication process, see the next example, "Cross-Realm Authentication and Shortcut Trusts."

Cross-Realm Authentication and Shortcut Trusts Example

What happens if there are multiple trusted Kerberos realms between the client's logon realm and the target server's realm? In this case, the client receives a TGS referral for the nearest trusted realm along the shortest path to the target realm. The client must send the KRB_TGS_REQ message requesting a service ticket for the target server to each intervening realm. A KDC in each intervening realm issues another TGS referral to the client until the client has a TGT for a KDC in the target realm. The following example describes an Active Directory domain environment.

Three Domain Cross-Realm Authentication Example

Suppose the user logs on at a workstation in west.tailspintoys.com. The user wants to connect to a shared file on a server in east.tailspintoys.com. Two steps occur before the cross-realm authentication steps:

• The user uses Explorer to request a connection to \\server\shared folder.

• DNS resolves that the target server is located in east.tailspintoys.com.

Cross-Realm Authentication: Three Domains

To authenticate the user's identity to the server, the user needs a service ticket. Only the KDC in east.tailspintoys.com can issue this ticket. Although the user needs a TGT for that KDC, its initial ticket request needs to go to the local KDC for west.tailspintoys.com. The Kerberos SSP on the user's workstation must obtain a TGT for the server's domain and then use the TGT to get a ticket for the server.

This involves a referral process that proceeds as follows:

1. The user's Kerberos client sends a KRB_TGS_REQ message to a local KDC in west.tailspintoys.com, specifying server@east.tailspintoys.com as the target.

   The message includes:

   • The name of the target computer.

   • The name of the target computer's domain.

   • A TGT for admission to the KDC in west.tailspintoys.com.

   • An authenticator encrypted with the TGS session key the user shares with that KDC.

   The Kerberos client compares the location with its own workstation's domain. Because they are different, the client sets a flag in the KDC Options field of the KRB_TGS_REQ message for NAME_CANONICALIZE, which indicates to the KDC that server might be in another realm.

2. The user's local KDC (for west.tailspintoys.com) receives the KRB_TGS_REQ and sends back a referral ticket for tailspintoys.com. The local KDC:

   1. Notes the flag setting.

   2. Verifies the user's TGT.

   3. Looks up the path to the server—in this case, a computer object in east.tailspintoys.com.

   4. Builds a tree of known domains until it has a structure including east.tailspintoys.com.

   5. Queries LSA for a trust list.

   6. Constructs the shortest path between its domain and east.tailspintoys.com based on the domain tree and the trust list.

   7. Constructs a new TGT for the user.

      Unless there is a direct trust between west.tailspintoys.com and east.tailspintoys.com (which there is not in this example), the TGT is issued for the next intervening domain along the shortest path to east.tailspintoys.com. In this example, the next intervening domain is tailspintoys.com.

      The TGT also has a referral flag set, so the KDC will be informed that the KRB_TGS_REQ is coming from another realm. This flag also tells the KDC to fill in the Transited Realms field.

   8. Constructs a KRB_TGS_REP message containing these four items:

      

   • A TGT for tailspintoys.com, encrypted with the inter-realm key shared between west.tailspintoys.com and tailspintoys.com.

   • A session key for the user to share with the KDC in tailspintoys.com, encrypted with the user's TGS session key.

   • A pre-authentication field data type of KERB-PA-SERV-REFERRAL, which tells the user's Kerberos client that the enclosed ticket is a referral TGT.

   • Pre-authentication data (the realm name for the referral — in this case, tailspintoys.com).

3. The user's Kerberos client receives the KRB_TGS_REP and sends KRB_TGS_REQ to the KDC in tailspintoys.com. The Kerberos client:

   1. Notes that this is a referral and gets the referral realm (tailspintoys.com).

   2. Sends a KRB_TGS_REQ message to a KDC in tailspintoys.com with the TGT, the NAME_CANONICALIZE flag set, and a request for a service ticket to server.

   The message includes:

   • The name of the target computer.

   • The name of the target computer's domain.

   • A TGT for admission to the KDC in tailspintoys.com.

   • An authenticator encrypted with the session key the user shares with that KDC.

4. A KDC in tailspintoys.com goes through the same process as the KDC in west.tailspintoys.com, returning a TGT for east.tailspintoys.com in a TGS referral to the user.

   

5. The user's Kerberos client sends a KRB_TGS_REQ along with the TGT it received from the tailspintoys.com KDC to a KDC in east.tailspintoys.com.

6. The KDC in east.tailspintoys.com replies with KRB_TGS_REP.

   The message includes:

   • A session key for the user to share with the server, encrypted with the session key the user shares with the KDC in east.tailspintoys.com.

   • A service ticket for admission to the server encrypted with the server key shared with the KDC.

   The service ticket includes:

   • A session key for the server to share with the user.

   • Authorization data copied from the user's TGT, plus data for the local domain, east.tailspintoys.com.

   The authorization data includes:

   • The SID for the user's account.

   • SIDs for groups in west.tailspintoys.com that include the user.

   • SIDs for universal groups that include either user or one of the user's groups in west.tailspintoys.com.

   • SIDs for groups in east.tailspintoys.com that include the user, one of the user's groups in west.tailspintoys.com, or one of their universal groups.

7. The user's Kerberos client sends the server a KRB_AP_REQ message.

   The message includes:

   • The user principal name.

   • A service ticket to the server.

   • An authenticator encrypted with the session key the user shares with the server.

Note

• If the user had asked for mutual authentication, then the server would reply with KRB_AP_REP. The reply message would include an authenticator encrypted with the session key the server shares with the user.

The same process takes place when a user logs on to a remote domain and needs a service ticket for the local workstation. The KDC in the logon domain issues a referral to the next realm between it and the workstation's realm, and so on, until the client can request a service ticket from the KDC in the workstation's realm.

Effects of Shortcut Trusts

You can optimize the inter-realm authentication process in your Active Directory forest by shortening the trust path with shortcut trusts. In this example, the user has an account in it.west.tailspintoys.com. The user has logged on to the domain account and has collected a TGT for the KDC in it.west.tailspintoys.com. Suppose the user needs access to a document stored in a public folder on a server in the domain it.east.tailspintoys.com.

Forest Configuration

Without shortcut trusts, the referral path to retrieve a service ticket would be:

1. it.west.tailspintoys.com

2. west.tailspintoys.com

3. tailspintoys.com

4. east.tailspintoys.com

5. it.east.tailspintoys.com

The following illustration shows how the referral path would change with the addition of a shortcut trust.

Forest Configuration with Shortcut Trusts

If Shortcut Trust 1 is created, then the referral path to retrieve a service ticket would become:

1. it.west.tailspintoys.com

2. west.tailspintoys.com

3. east.tailspintoys.com

4. it.east.tailspintoys.com

Do shortcut trusts always affect the shortest referral path?

If the shortest path to a realm would be to use an explicit trust that is positioned in the tree below the current domain, that path will not be used. This is because the shortest-path algorithm can only make use of explicit trusts that are at or above the current position in the tree.

If only Shortcut Trust 2 is created then the referral path to retrieve a service ticket would remain:

1. it.west.tailspintoys.com

2. west.tailspintoys.com

3. tailspintoys.com

4. east.tailspintoys.com

5. it.east.tailspintoys.com

This shortcut trust would only shorten the path from test.it.west.tailspintoys.com to east.tailspintoys.com and it.east.tailspintoys.com. But from test.it.west.tailspintoys.com and east.tailspintoys.com it would reduce the number of exchanges from five to two.

Untrusted Domain Examples

To use Kerberos authentication in a remote untrusted domain, the user must supply credentials as part of the connection request. Otherwise, the KRB_TGS_REQ message fails, and the system tries the next security provider, typically NTLM.

Client Does Not Use Alternative Credentials

Suppose user 1 is logged on to west.tailspintoys.com and wants to access a shared file on user 2's Windows Server 2003 server in sales.contoso.com, an untrusted domain.

1. User 1 opens Windows Explorer and simply tries to map a network drive to \\User2\shared folder without providing the credentials with which to connect.

2. The KRB_TGS_REQ goes to user 1's local KDC just as it would if sales.contoso.com were a trusted domain.

3. When the KDC attempts to build a domain tree and trust list, the attempt fails because there is no trust.

4. User 1 might or might not get an error message because the system automatically reverts to the next security provider. If NTLM is available, it is used. If NTLM authentication is successful, user 1 might connect, but Kerberos authentication will not have been used.

Client Uses Alternative Credentials to Send KRB_AS_REQ Directly to Untrusted KDC

User 1 can enter credentials. The Kerberos client responds differently when the user includes new credentials.

• A different ticket cache is created for each different set of credentials.

  Note

  • If user 1 connects to an untrusted resource using different credentials (for example, Administrator), a new ticket cache is created for these credentials. The tickets in this cache are not currently viewable with either Kerberos Tray or Kerberos List.

• If user 1 has used the credentials recently, a ticket cache might already exist. If so, the client checks for an existing TGT for the untrusted domain. It cannot use an existing TGT from user 1's normal ticket cache.

• The client sends a KRB_AS_REQ message to get a TGT from the KDC in the target server's realm. If the supplied credentials are correct, this request is processed normally, without the need for any TGS referrals.

Delegation Examples

The Need for Delegation

A client might need to let an application or a service connect to other servers or services on its behalf. A client might use a front-end server, for example, that then needs to authenticate with a back-end server. The front-end server needs to authenticate to the back-end server with the client's credentials, because if it authenticated under its own service account, it would have different authorization than the user.

A multi-tier client/server application presents a special situation for the Kerberos protocol. In this kind of application, a client might connect to a server that must itself connect to a second server on the back end. For this to happen, the first server must have a ticket to the second. Ideally, the ticket should limit the first server's access on the second server to whatever the client—instead of the server—is authorized to do.

The Kerberos protocol deals with this situation through a mechanism called delegation of authentication. Essentially, the client delegates authentication to a server by telling the KDC that the server is authorized to represent the client. The concept is similar to the concept of impersonation in Windows NT.

Traditionally, the Kerberos protocol enabled delegation to be accomplished using one of two mechanisms:

• Proxy tickets. The client can get a ticket for the back-end server and then give it to the front-end server. Tickets obtained in this way—by a client for a proxy—are called proxy tickets. The difficulty with proxy tickets is that the client must have information about the name of the back-end server.

• Forwarded tickets. The client can give the front-end server a TGT that the server can use to request tickets as needed. Tickets obtained in this way—with credentials forwarded by a client—are called forwarded tickets. This second method overcomes the difficulty (that the client must have information about the name of the back-end server) presented by the first method.

Windows Server 2003 supports two new extensions for delegation:

• Protocol transition extension. The protocol transition extension allows a kerberized service (that is, a service designed to use Kerberos authentication features) to obtain a Kerberos service ticket on behalf of a Kerberos principal to the service itself without requiring the principal to initially authenticate to the KDC with a credential.

• Constrained delegation extension. The constrained delegation extension allows a kerberized service to obtain service tickets (under the delegated user's identity) to a subset of other services after it has been presented a service ticket obtained either through KRB_TGS_REQ or the protocol transition extension.

Whether the KDC will allow clients to obtain proxy tickets or forwardable TGTs is a matter for Kerberos policy.

Note

• Technically, both proxying and forwarding are proxies, so different Kerberos documents might discuss both types as proxy. In other documents, forwarding the user's identity is also known as delegation. In many Microsoft documents, including the Microsoft Windows 2000 Server Resource Kit Distributed Systems Guide, both proxying and forwarding are referred to as types of delegation. The terminology is not critical, but you should be aware that terms are used differently by different organizations.

What Delegation Does for the Client

Delegation of authentication allows the client to send its identity in the form of a Kerberos ticket to the front-end server. The front-end server can then impersonate the client and authenticate with the back-end server as if the front-end server were the client.

Delegation is not limited to a single pair of a front-end and a back-end server. A client can delegate its identity to a service that can then authenticate with any number of back-end services. It is also possible for the client to delegate its identity to Service A, and for Service A to in turn delegate the client's identity to Service B, for Service B to delegate the client's identity to Service C, and so on.

The simpler case—in which the client delegates its identity to a front-end server so that the front-end server can authenticate in the client's security context to a back-end server—is more common.

Delegation of Authentication

In Windows NT, a service can impersonate clients when accessing resources on the computer where the service process is running. In Windows 2000 and Windows Server 2003, a service can use the Kerberos protocol's delegation feature to impersonate clients on other computers, as well. For delegation of authentication to work, three conditions must be met:

• The computers that host the client process, the service process, and the processes for back-end services must all be running Windows 2000, Windows XP, or Windows Server 2003 in an Active Directory domain.

• The client's account must be enabled for delegation.

• The service's account must be enabled for delegation.

To configure a client's account for delegation

1. Right-click the object that represents the user in Active Directory Users and Computers.

2. Click Properties, and then click the Account tab.

3. In the Account options list, be sure that the Account is sensitive and cannot be delegated option is not selected.

For accounts in domains that are Windows 2000 mixed, Windows 2000 native, or Windows Server 2003 interim functional level

To configure a service's account for delegation, determine whether the service runs under the host computer's Local System account or under its own domain user account.

To configure a service's account for delegation if the service runs under the Local System account

1. Right-click the computer object in Active Directory Users and Computers.

2. Click Properties.

3. Click the General tab.

4. Select Trust computer for delegation.

To configure a service's account for delegation if the service runs under its own domain user account

1. Right-click the user object in Active Directory Users and Computers.

2. Click Properties.

3. Click the Account tab.

4. In the Account options list, select Account is trusted for delegation.

For accounts in domains that are Windows Server 2003 functional level

To configure a service's account for delegation, determine whether the service runs under the host computer's Local System account or under its own domain user account.

To configure a service's account for delegation if the service runs under the Local System account

1. Right-click the computer object in Active Directory Users and Computers.

2. Click Properties.

3. Click the Delegation tab.

   Note

   • If the service's account is missing the Delegation tab and you have confirmed the domain is Windows Server 2003 functional level, then the SPN for the service account has not been registered. Use Setspn to register the service account's SPN.

   • If the Trust this user for delegation to any service (Kerberos only) option is selected, then the account is using unconstrained delegation, which is not recommended.

   • If the Trust this user for delegation to specified services only option is selected, then the account is using constrained delegation.

   • If the Use Kerberos Only option is selected, then the account is using constrained delegation without protocol transition.

   • If the Use any authentication protocol option is selected, then the account is using constrained delegation with protocol transition.

To configure a service's account for delegation if the service runs under its own domain user account

1. Right-click the user object in Active Directory Users and Computers.

2. Click Properties.

3. Click the Delegation tab.

4. If Do not trust this computer for delegation is selected, select the appropriate option:

   • If the Trust this computer for delegation to any service (Kerberos only) option is selected, then the account is using unconstrained delegation, which is not recommended.

   • If the Trust this computer for delegation to specified services only option is selected, then the account is using constrained delegation.

   • If the Use Kerberos Only option is selected, then the account is using constrained delegation without protocol transition.

   • If the Use any authentication protocol option is selected, then the account is using constrained delegation with protocol transition.

Differences Between Proxy and Forwarding

Both proxy and forwarding are types of delegation. The credentials message (KRB_CRED) is used to deliver both proxy tickets and forwarded tickets. The KRB_CRED message is detailed later in this topic.

Proxy is limited use.

The client gives a front-end server a ticket and a key for a specific back-end server. The front-end server can authenticate as the client with this specific service only.

Forwarding is general use.

The client sends a TGT and a key for a TGS to the front-end server. The front-end server requests service tickets to wherever it needs to on the client's behalf. The service that receives the client's TGT is the client as far as the KDC is concerned.

Proxy requires that the client have information about the name of the back-end or target server or service. Rather than require that the client keep track of all possible back-end server names, most services use forwarded tickets, as described below.

When the user's identity is forwarded to another service, a special type of authentication called user-to-user authentication might be required. This special case is discussed later in this section.

Proxy

For a service to handle a request for a client, the service might need to complete that request in the context of the client. Proxy allows the client to send its identity in the form of a Kerberos ticket to the front-end server. The front-end server can then impersonate the client and authenticate with the back-end server as if the front-end server were the client.

What are proxy tickets?

Service tickets obtained by a client for a service to impersonate it are called proxy tickets. When the KDC issues a TGT to a client, it checks Kerberos policy to see if proxy tickets are allowed. If they are, the KDC sets the PROXIABLE flag in the TGT that it issues to the client.

The client obtains a proxy ticket by presenting a TGT to the ticket-granting service and asking for a ticket to the back-end server. The client's request includes a flag signaling that it wants a proxy ticket and also includes the name of the server that will represent the client. When the KDC receives the client's request, it creates a ticket for the back-end server, sets the PROXY flag in the ticket, and sends it back to the client. The client then sends the ticket to the front-end server, which uses the ticket to access the back-end server.

Client sends a front-end service a service ticket and session key for a back-end service

In a proxy situation, the client wants a front-end service to authenticate as the client with a specific back-end service. Delegation is limited to a specific target. For example, the client knows that it must authenticate with SQL. It also knows that SQL will need to use the client's credentials to authenticate with a specific database on another server.

To authenticate with these services, the client requests a service ticket for the database. In the request, the client specifies that this will be a proxy ticket and gives the KDC the name of the SQL server. The client sends the proxy ticket to the SQL server along with a session key for the database. The SQL server then authenticates with the database as if it were the client.

Note

• Proxy requires that the client know the name of the back-end or target server or service. Rather than require that the client keep track of all possible back-end server names, most services use forwarded tickets, as is described in the following proxy process.

The illustrated message sequence in the following figure assumes that Client has already authenticated with Proxy. Now, Client wants Proxy to access Server on its behalf.

Messages in the Proxy Process

The message sequence for the proxy ticket is:

1. Client sends a request for a proxy ticket for Server to the TGS in the KDC. The request includes the client's TGT, a request for the ticket to be flagged as a proxy, and the addresses for which the ticket is valid. The addresses are those of the client computer and Proxy.

2. The TGS sends the proxy ticket and a session key for Server to Client.

3. Proxy needs the Server ticket and a valid Server session key. Client sends both of these to Proxy in a KRB_CRED (Kerberos credentials) message.

4. Proxy can now attempt to access Server as the workstation. The KRB_AP_REQ message is identical to the one the client would have sent if it were trying to access Server directly. The message contains the Server service ticket and an authenticator.

   Server decrypts the ticket with its secret key, finds the session key, and uses the session key to decrypt the authenticator. If this succeeds, Proxy is authenticated as Client.

5. If the authenticator passes the test, the service looks for a mutual authentication flag in the client's request. If the flag is set, the service uses the session key to encrypt the time from the user's authenticator and returns the result in a Kerberos application reply (KRB_AP_REP). If a mutual authentication flag is not set, no response is needed.

Forwarding

The difficulty with proxy tickets is that the client must have information about the name of the back-end server. This difficulty is overcome by a second method of delegation—forwarding—that enables the client to give the front-end server a TGT that it can use to request tickets as needed.

What are forwarded tickets?

Forwardable TGTs obtained from a client that enable the service to impersonate the client are called forwarded tickets.

If a client wants to delegate the task of obtaining tickets for back-end servers to a front-end server, it must ask the KDC for a forwardable TGT. It does this through an AS exchange, indicating to the KDC the name of the server that will act on the client's behalf. If Kerberos policy permits forwarding, the KDC creates a TGT for the front-end server to use in the client's name, sets the FORWARDABLE flag, and sends the TGT back to the client. The client then forwards the TGT to the front-end server.

When the front-end server requests a ticket to the back-end server, it presents the client's TGT to the KDC. When the KDC issues a ticket, it sees the FORWARDABLE flag in the TGT, sets the FORWARDED flag in the ticket, and returns the ticket to the front-end server.

How the client's TGT and TGS session key are sent to front-end services

Proxy is limited in that the client must have information about the target server's name. Forwarding relieves the client of this burden. Rather than ask the KDC for a service ticket specifically for the server, the client sends its TGT—with the FORWARDED flag set—and TGS session key to the delegate server.

When the delegate server has the client's forwarded TGT and TGS session key, it can request from the KDC directly any service tickets it needs for any additional servers or services. The client does not need to be involved. With the client's forwarded TGT, the delegate server can fully impersonate the client, and can request service tickets on the client's behalf and in the client's security context for any services.

The Forwarded Ticket and Delegation

In Windows 2000, Windows XP, and Windows Server 2003, Kerberos delegation allows a service running under the local system security context to take on the client's identity and authenticate as the client to another service.

A server that has a client's forwarded ticket is the client. Thus, the forwarded ticket enables the server to request new tickets from the TGS. Because a TGT is required to request new tickets, the forwarded ticket is the client's TGT. Then, when a client forwards its TGT to another server, the client is said to have delegated its identity.

There are two forwarding situations:

• The client delegates its identity to a service that logged on with its own credentials, has its own user account, and knows its own password.

• The client delegates its identity to a service that was started in a user context, is using that user's credentials, but did not log on and does not have information about the user's password (for example, DCOM's "activate as activator"). This situation requires a special authentication mode called user-to-user authentication, which is discussed in the next section.

Messages in the Forwarding Process

The normal message sequence for a forwarded ticket is illustrated above.

1. The client requests a TGT with valid addresses for the client and the delegate. The TGT is requested as forwardable.

2. The KDC sends a TGT with valid addresses for the client and the delegate. The TGT is flagged as forwardable.

3. The client uses the TGT to request service ticket for the delegate server.

4. The KDC sends a service ticket for the delegate server.

5. The client uses the service ticket to connect to the delegate server and requests mutual authentication.

6. The client authenticates the delegate server.

   If the authenticator passes the test, the service looks for a mutual authentication flag in the client's request. If the flag is set, the service uses the session key to encrypt the time from the user's authenticator and returns the result in a Kerberos application reply (KRB_AP_REP). If no mutual authentication flag is set, then no response is needed.

   Up to this point, the messages are the same as a normal client-server authentication.

7. After the user is authenticated and authorized, the client sends the delegate server its TGT and a session key to be used in messages to the TGS. The KRB_CRED message is used to deliver the TGT and session key.

   The delegate server now has the user's TGT and the correct session key for the user/TGS session; so Delegate can now request tickets to other resources in the user's name.

   The delegate server requests and receives a service ticket for Server from the KDC. In the request, the delegate server sends the user's TGT and an authenticator encrypted with the user/TGS session key.

8. The delegate server sends the service ticket to Server. The ticket contains the user's credentials. The accompanying authenticator is encrypted with the TGS-supplied Delegate/Server session key.

   Server receives the authentication request and authenticates Delegate—that is, authenticates the user the delegate server is impersonating. Server will then build an access token based on the user's identity.

9. If the authenticator passes the test, the service looks for a mutual authentication flag in the delegate's request. If the flag is set, the service uses the session key to encrypt the time from the user's authenticator and returns the result in a Kerberos application reply (KRB_AP_REP). If no mutual authentication flag is set, then no response is needed.

User-to-User Authentication

The Kerberos authentication protocol supports authentication between clients, as specified in RFC 1510, when a client is running as a service that another client needs to access. In versions of Windows earlier than Windows 2000, NTLM is the only protocol that supports this type of user-to-user authentication.

It is often the case that a computer or service running in one of the new security contexts provided by Windows Server 2003 must run in a different security context to authenticate to a remote computer. For example, a local service running in the current user context would authenticate to a remote system as an Anonymous user.

User-to-user is the most complex Kerberos authentication. The following figure illustrates some typical user-to-user situations.

Typical User-to-User Situation

A typical situation requiring user-to-user authentication is illustrated above.

1. A user logs on and starts an application called Service A and forwards this application its identity. Service A can now access network resources on the user's behalf.

2. Then Service A, acting as the user, now starts another application called Service B. Service B shares Service A's identity of the user.

Three network entities now share the user's identity: the client, Service A, and Service B. Service B is unique, however, in that it is the only one of the three that did not have to log on.

When Service A started Service B, it did so with the user's existing identity. Service B will be associated with the user in Active Directory services, but Service B does not have information about the user's password or user key. Service B already has a copy of the user's TGT and the client/TGS session key, so it never needs to have information about the user's password.

Why is this a problem?

How will the user be able to authenticate with Service B? In normal authentication, the user would send Service B a ticket supplied by the TGS and an authenticator encrypted with the User/Service B session key. Service B should decrypt the ticket, get the session key, and decrypt the authenticator.

The problem is that Service B cannot decrypt the ticket because it does not have a copy of the user key. The solution to the problem is user-to-user authentication.

The User-to-User Authentication Process

As illustrated above, the user-to-user authentication process follows this sequence:

1. The user requests a ticket for Service B. The TGS checks with Active Directory to find the user account associated with Service B. Because Service B is impersonating, that account would be the user. Thus, the TGS checks the user object, gets the user key, and uses it to encrypt the service ticket.

2. The user sends the service ticket to Service B.

3. Even though Service B has the user's credentials, it does not have information about the user's password, cannot calculate the secret key, and thus cannot decrypt the ticket. The result is that the user cannot authenticate with Service B and so cannot use the application.

   Service B responds to the KRB_AP_REQ message with an error. With the error, Service B sends the user its TGT (which is the user's TGT in this case), along with a request for a new ticket encrypted with the session key from Service B's TGT rather than Service B's secret key.

4. The user requests a new ticket for Service B from the TGS. In the request message, the user sends its TGT, Service B's TGT in the Additional Tickets field, and the ENC-TKT-IN-SKEY flag, which is an optional request to encrypt the ticket with the additional ticket's session key.

   The TGS associates the additional ticket with Service B, because that is the target server in the ticket request. The KDC looks up Service B, finds that it is associated with the user object, gets the user key, and decrypts Service B's TGT. The TGS gets the session key from Service B's TGT, creates a new ticket for the user to use, and encrypts it with the session key.

5. The user sends the new KRB_AP_REQ to Service B and authentication proceeds normally.

What happens when another user tries to connect to Service B?

The situation is not very different. Service B is using user 1's identity but does not have information about user 1's password, so it cannot decrypt a presented service ticket.

When user 2 asks the KDC for a service ticket to Service B, the KDC will send user 2 a service ticket that will be encrypted with user 1's secret key, because Service B is impersonating user 1.

When user 2 presents the ticket to Service B, Service B will respond with the same error message as when user 1 originally tried to connect. The error message will contain Service B's TGT (that is, user 1's TGT) and request a new service ticket encrypted with its session key.

Thus, it does not matter who tries to connect to Service B. The service ticket is encrypted with user 1's key regardless of the requester's identity. Because Service B never has information about user 1's password, it never has the user key and cannot decrypt the ticket.

Note

• User-to-user tickets are not cached.

Kerberos Protocol Transition

Kerberos protocol transition allows a kerberized service (that is, a service designed to use Kerberos authentication features) to obtain a service ticket to itself on behalf of a Kerberos principal because no user credential is required for the transition to happen.

Kerberos protocol transition is enabled programmatically through the Win32 API LsaLogonUser(). A new logon message type (KerbS4ULogon) and a new logon information structure (KERB_S4U_LOGON) have been defined to be passed into the LsaLogonUser() call. A successful call into LsaLogonUser() will return a Windows access token. For more information about LsaLogonUser(), see "LSA Authentication" in the Microsoft Platform SDK on MSDN.

Two variants of an access token can be returned depending on whether the caller process possesses the user right, Act as part of the operating system:

• Without Act as part of the operating system, a security impersonation level of SecurityIdentification is returned.

• With Act as part of the operating system, a security impersonation level of SecurityImpersonation is returned.

An identification token allows the process to determine the identity and privileges associated with a user whereas an impersonation token also allows the process to take on the token user's identity and operate under that user's identity. With an impersonation level token, the caller process can use the service ticket obtained through protocol transition to obtain service tickets to other kerberized services if the service account has been configured correctly to use the constrained delegation extension.

The programmatic mechanism described above is the way that applications can be enabled to take advantage of protocol transition. In addition, the applications should also be configured to run as kerberized services.

Kerberos Constrained Delegation

In the Windows 2000 delegation model, the KDC does not limit the scope of services that a Kerberos principal's identity can be delegated to. That is, after a service account is trusted for delegation, it can request service tickets on behalf of a given user to any other service accounts. This unrestricted way of performing delegation does not provide for an application to specify a subset of service accounts that it deems trustworthy to delegate to. Thus, applications can be exposed to broader impersonation risks.

Impersonation might span across resource domains that have differing levels of security policy requirements, and some of those security policies might be weaker than the application's security requirements. From the domain administrator's point of view, it is risky to enable unconstrained Kerberos delegation in the enterprise, because there is no way to exclude untrusted servers from participating in delegation.

With constrained delegation, on the other hand, domain administrators can configure service accounts to only delegate to specific sets of service accounts. In Windows Server 2003, the ms-DS-Allowed-To-Delegate-To attribute is added to service accounts to help enforce constrained delegation. The ms-DS-Allowed-To-Delegate-To attribute lists the service principal names (SPNs) of other service accounts that a given service account is allowed to delegate to. When a Windows Server 2003 KDC processes a service ticket request via the constrained delegation extension, it will verify that the target service account is one that is listed in the ms-DS-Allowed-To-Delegate-To attribute.

Thus, with the addition of the constrained delegation extension, Windows Server 2003 supports two modes of delegation:

Unconstrained delegation

Legacy mode of delegation is still supported only if the user has initially entered a user credential to obtain a TGT. This is not any different from the Windows 2000 implementation.

Constrained delegation

Can be enabled for a Kerberos principal when the principal has a TGT that is acquired through the normal process of authenticating to the KDC when:

• A user has initially entered a user credential to obtain a TGT.

• Another service account has obtained a service ticket on behalf of the principal through the protocol transition extension.

Constrained delegation is the only delegation mode supported with protocol transition and only works in the boundary of a domain.

You can configure a service account to use protocol transition in conjunction with constrained delegation by choosing Trust this user for delegation to specified services only and Use any authentication protocol on the Delegation tab of the account. If these options are selected for a service account, the account can use the protocol transition extension to obtain a service ticket enables it to obtain service tickets to a pre-configured subset of kerberized services. An additional requirement is that the impersonated user account must not be marked as Account is sensitive and cannot be delegated on the Account tab.

The following sections detail the contents of individual messages in each of the three Kerberos exchanges.

Authentication Service Exchange Message Details

Authentication Service Exchange

Message 1: The Authentication Service Request

The initial message sent to the AS requesting a TGT is the KRB_AS_REQ message. This message and its corresponding response contain the most detail. Subsequent messages have less because they contain similar fields and data.

KRB_AS_REQ message contents

Although the same message structure is used for the initial KRB_AS_REQ message and for the KRB_TGS_REQ message (in which the client asks for a ticket for a target server), some of the fields are not be used for the KRB_AS_REQ message.

Authentication Service Request Message Fields

Field	Description
Protocol Version	5
Message Type	KRB_AS_REQ
Pre-authentication Data	The intent of these fields is to provide pre-authentication before the KDC sends the client a ticket. This is to prevent brute force or dictionary attacks on the user's password. Note that these fields are used in the KRB_TGS_REQ message for the TGT and the authenticator.
PAData Type	PA-AS-REQ or PA-PK-AS-REQ.
PAData Value	The AS_REQ includes a client timestamp encrypted with the user key. In this case, the data type will be PA-AS-REQ. If a Smart Card is used, the user's public certificate signed with the user's private key will be placed in this field. The data type will be PA-PK-AS-REQ in this case.
Request Body
KDC Options	The client can request that the TGT have certain optional features. The KDC options are detailed in the table below.
Client Name	Name of the requester.
Realm	Realm (Active Directory domain) of the requester.
Server Name	In the KRB_AS_REQ, this will be the KDC name. The client is specifically requesting a ticket for the TGS.
From	(Optional) If the ticket were postdated (not supported by Windows 2000, but is supported in Windows Server 2003), this field would specify the time from which the ticket would be valid.
Till	This is the requested expiration time. The KDC does not have to honor this request if the requested expiration time violates the domain's Kerberos policy.
Renew Time	(Optional) The requested renewal time.
Nonce	A random number generated by the client. The nonce can be used as the basis for sequence numbering or as an additional authenticator. The nonce supplied here will be returned in the encrypted portion of the KRB_AS_REP message. The client will compare the nonces to make sure they match.
Encryption Type	The desired encryption algorithm to be used.
Addresses	IP addresses from which ticket will be valid.
Encrypt Authorization Data	Not used for KRB_AS_REQ.
Additional Tickets	Not used for KRB_AS_REQ.

The Encrypt Authorization Data field is not likely to be used in Microsoft implementations because the user key—or a private key if sending a certificate after logging on with a smart card—is used to encrypt a timestamp. The Additional Tickets field is only used in Kerberos authentication in some special cases, such as user-to-user authentication for distributed applications.

KDC option flags for the KRB_AS_REQ and KRB_TGS_REQ messages

These flags are very similar to the ticket flags discussed earlier (see the Ticket Flags table in the Kerberos Tickets topic), because you use KDC options to define the requested ticket flags. Many of these options are used in both the KRB_AS_REQ and KRB_TGS_REQ messages. Some are used only in the KRB_TGS_REQ message.

Key Distribution Center Option Flags

Flag Bit	Flag Value	Flag Meaning
1	FORWARDABLE	Ticket can be forwarded. Allowed addresses are specified in the message's Addresses field.
2	FORWARDED	Ticket is a forwarded ticket.
3	PROXIABLE	Ticket can be proxied.
4	PROXY	Ticket is a proxy ticket.
5	ALLOW POSTDATE	Ticket can be post-dated. When the service wanted the ticket to be activated, it would send a TGS request with the VALIDATE flag set (below). Not supported in Windows 2000, but supported in Windows Server 2003.
6	POST-DATED	Ticket is post-dated. Not supported in Windows 2000, but supported in Windows Server 2003.
8	RENEWABLE	Ticket can be renewed.
15	NAME_CANONICALIZE	Indicates to the KDC that the client is prepared to receive a reply with a different client or server principal name than was sent in the request. This flag is used in referrals. It also alerts the KDC that the target server might be in another realm. The KDC option flag NAME_CANONICALIZE is important for cross-realm authentication.
27	RENEWABLE OK	This flag means that it is okay to issue a renewable ticket if a ticket with the requested expiration time cannot be provided. However, it does not mean that the ticket requested should be renewable. That flag is set by flag bit 8.
28	ENC-TKT-IN-SKEY	Encrypt ticket in session key. Normally, tickets are encrypted with the target server key. However, in user-to-user authentication, the ticket is encrypted with the session key taken from a provided TGT. This flag is used in that situation.
30	RENEW	This is not used for the KRB_AS_REQ message. If a ticket is flagged RENEWABLE and needs to be renewed, this flag would be set and the ticket needing renewal would be included with the KRB_TGS_REQ message.
31	VALIDATE	Only used with postdated tickets. Not supported in Windows 2000, but supported in Windows Server 2003.

Message 2: The Authentication Service Response

The KRB_AS_REP message returns the TGT and a session key to the client.

The TGT is encrypted with the TGS's secret key, so only the TGS can decrypt it. This is important because the TGT contains the SIDs associated with the user and will be used to create the user's access token. This sensitive information needs to be protected from tampering.

The message also contains the short-lived session key that the client will use to encrypt data to the TGS or decrypt data from the TGS.

The session key is actually included in the message twice, as is true of much of the message's data. The client needs the session key, so it is included and encrypted in the user's secret key. The user will then be able to decrypt and use the session key. Another copy of the session key is included within the service ticket for the TGS (the TGT).

When the client has a valid TGT and a session key for the TGS, the client can request additional tickets for the local workstation or for network servers or services.

KRB_AS_REP message contents

This data structure is used for both the KRB_AS_REP message and the KRB_TGS_REP message. Thus, the field contents might change depending on the message type.

Authentication Server Reply Message Fields

Field	Description
Protocol Version	5
Message Type	KRB_AS_REP
Pre-authentication data	For the KRB_AS_REP message, this field will normally be empty. One exception is if the client logged on with a smart card. In this case, because the user did not enter a name and password, the LSA does not have the user's password. So, the user's NTLM password and credentials are passed back to the LSA in this field (hashed and encrypted with the user's key).
Client Realm	Realm or domain of the requester.
Client Name	Name of the requester.
Ticket	The encrypted ticket is placed here. For the KRB_AS_REP message, this will be the TGT encrypted with the TGS's secret key. Every domain controller will be a KDC and therefore will run the AS and TGS services. The client can connect to any TGS in the domain to request service tickets. Because the TGT is encrypted with the TGS's secret key, and because every TGS in the domain will need to be able to decrypt the TGT, every TGS's secret key must be identical. Thus, every domain controller will have a user account called krbtgt. This is the service account for the KDC, and its password (randomly selected and periodically changed) is used to create the TGS's secret key.
	The rest of the message fields are encrypted with the user's key. The client cannot read the encrypted ticket and might need to verify the ticket information. Furthermore, the client needs to have information about start times and end times so it can determine when to request renewal or replacement tickets. Therefore, the seven fields from Authentication Time to Client Addresses are all included in the ticket and copied here into these fields.
Key	This is the session key the user will use to encrypt and decrypt TGS messages.
Last Requested	The last time a ticket was requested. This is similar to a "last logged on" time. This can be used to track how frequently a client is requesting tickets. A Kerberos policy can be set that limits how frequently ticket requests can be made. Such limits can help prevent brute force attacks.
Nonce	The nonce from the KRB_AS_REQ nonce field will be copied here.
Key Expiration	When the user's key will expire. This is used for password aging.
Flags	These are the flags set in the ticket, based on the flags requested in the KRB_AS_REQ message and the domain's Kerberos policy.
Authentication Time	The time the ticket was issued.
Start Time	(Optional) At what time the ticket is valid.
End Time	At what time the ticket expires (although it can be renewed if the ticket is renewable).
Renew Till	(Optional) At what time the ticket absolutely expires (cannot be renewed past this time).
Server Realm	Requested server's realm (domain).
Server Name	Requested server's name
Client Addresses	(Optional) Addresses from which the ticket will be valid. This is important in several situations. Normally, a ticket is only valid if sent from a specific address. In Windows 2000, the KDC did not propagate the addresses to the ticket. Because of this, two new registry keys that affect Client Addresses were created for Windows Server 2003: KdcUseClientAddresses. Not created by default, this setting will configure the KDC to propagate client addresses to tickets. KdcDontCheckAddresses. Not created by default, this setting will configure the KDC to skip checking client addresses. This feature might be used in network address translation (NAT) scenarios. If the client computer is multi-homed, the ticket needs to be valid from every IP-enabled adapter, so the addresses are added here (and in the address field in the ticket). If a ticket is proxied or forwarded, it will be used on the client's behalf from another address (or perhaps several addresses). These addresses will also be included in this field.

Ticket-Granting Service Exchange Message Details

Ticket-Granting Service Exchange

Message 3: The Ticket-Granting Service Request

After the client has received a TGT, the client can begin requesting service tickets for local or network resources.

The primary contents of the KRB_TGS_REQ message are the TGT, the name of the target server for which a service ticket is requested, and the authenticator.

KRB_TGS_REQ message contents

As noted earlier in this section, the KRB_TGS_REQ message uses the same structure as the KRB_AS_REQ message, so many of the fields are used identically. The most important differences are the pre-authentication fields (PAData Type and PAData Value). The TGT and the authenticator are placed in the PAData Value field.

• The authenticator is encrypted with the session key.

• The TGT is encrypted with the TGS's secret key (the key based on the krbtgt user account).

The same message structure is used for the initial KRB_AS_REQ message and for the KRB_TGS_REQ message. However, some fields used in the KRB_TGS_REQ message were not used in the KRB_AS_REQ message. The following table lists and describes the fields used in the ticket-granting service request message.

Ticket-Granting Service Request Message Fields

Field	Description
Protocol Version	5
Message Type	KRB_TGS_REQ
Pre-authentication Data	The intent of these fields is to provide some authentication before the KDC sends the client a ticket. This is to prevent brute force or dictionary attacks on the user password. Note that this field is used in the KRB_TGS_REQ message for the TGT and the authenticator.
PAData Type	PA-TGS-REQ
PAData Value	TGT and authenticator.
Request Body
KDC Options	The client can request that the ticket have certain optional features. The requested options take the form of a bit string. (See the Key Distribution Center Option Flags table above.)
Client Name	(Optional) Name of the requester.
Realm	Realm or domain of the requester.
Server Name	(Optional) Requested server name.
From	(Optional) If the ticket were postdated (not supported by Windows 2000, but supported in Windows Server 2003), this field would specify the time from which the ticket would be valid.
Till	This is the requested expiration time. The KDC does not have to honor this request, if the requested expiration time violates the domain's Kerberos policy.
Renew Time	(Optional) The requested renewal time.
Nonce	A random number generated by the client. The nonce can be used as the basis for sequence numbering or as an additional authenticator. The nonce supplied here will be returned in the encrypted portion of the KRB_TGS_REP message. The client will compare the nonces to make sure they match.
Encryption Type	The desired encryption algorithm to be used.
Addresses	(Optional) IP addresses from which ticket will be valid.
Encrypt Authorization Data	(Optional) In the KRB_TGS_REQ message, this will specify a key to use to encrypt any pre-authentication data.
Additional Tickets	(Optional) In a KRB_TGS_REQ for user-to-user authentication, a TGT will be included in this field. The TGS will use the session key from this TGT — instead of the service's secret key — to encrypt the service ticket.

The TGS decrypts the ticket with the server key, then retrieves the session key from the ticket and uses it to decrypt the authenticator.

Only the TGT and the authenticator are encrypted in this message. A checksum is computed using the contents of fields in the request body, and that checksum is encrypted within the authenticator.

Message 4: The Ticket-Granting Service Response

The TGS response includes the ticket from the requested target server and a session key for the client and the target server with which to encrypt and decrypt their session messages.

The ticket is encrypted with the target server's secret key, so the client cannot decrypt and modify the ticket.

The message containing the session key for use with the target server is encrypted with the session key being used by the client and the TGS. The client can decrypt the new session key and use it to encrypt the authenticator that it will send to the target server along with the new ticket.

KRB_TGS_REP message contents

As noted earlier in this section, the KRB_TGS_REP and KRB_AS_REP messages are identically structured and the fields are similarly used. The major difference is that the ticket in the Ticket field is not a TGT. Instead, it is the service ticket for the target server.

Ticket-Granting Server Reply Message Fields

Field	Description
Protocol Version	5
Message Type	KRB_TGS_REP
Pre-authentication Data	In a KRB_TGS_REP message, application-specific data might be placed here.
Client Realm	Realm or domain of the requester.
Client Name	Name of the requester
Ticket	The encrypted ticket is placed here. For the KRB_TGS_REP message, this will be the service ticket encrypted with the target server's secret key.
	The message fields below are encrypted with the TGS session key.
Key	This is the session key the user will use with the application server.
Last Requested	The last time a ticket was requested. This is similar to a "last logged on" time. This can be used to track how frequently a client is requesting tickets. A Kerberos policy can be set that limits how frequently ticket requests can be made. Such limits can help prevent brute force attacks.
Nonce	The nonce from the KRB_TGS_REQ nonce field will be copied here.
Key Expiration	(Optional) When the user's key will expire. This is used for password aging.
Flags	These are the flags set in the ticket, based on the flags requested in the KRB_TGS_REQ message and on the domain's Kerberos policy.
Authentication Time	The time the ticket was issued.
Start Time	(Optional) At what time the ticket is valid.
End Time	At what time the ticket expires (although it can be renewed if the ticket is renewable).
Renew Till	(Optional) At what time the ticket absolutely expires (cannot be renewed past this time).
Server Realm	Requested server's realm (domain).
Server Name	Requested server's name.
Client Addresses	(Optional) Addresses from which the ticket will be valid. If a ticket is proxied or forwarded, it will be used on the client's behalf from another address (or perhaps several addresses). These addresses will also be included in this field.

Client/Server Authentication Exchange Message Details

Client/Server Authentication Exchange

Message 5: The Application Server Request

After the client has requested and received a TGT from the AS, and has requested and received a service ticket from the TGS, the client is ready to send the ticket to the target server.

The KRB_AP_REQ message contains an authenticator encrypted with the session key that the client and target server share, the service ticket encrypted with the target server's secret key, and the optional mutual authentication request. The mutual authentication response, which takes the form of a KRB_AP_REP message, is only necessary if the client requires verification that the target server is truly the recipient of the KRB_AP_REQ and subsequent messages.

Note

• If the target service requires user-to-user authentication, the initial service ticket will be rejected along with a copy of the target service's TGT. The client will then make a new KRB_TGS_REQ message containing the target service's TGT and requesting a new service ticket that is encrypted with the session key contained in the target service's TGT, instead of with the target service's secret key.

KRB_AP_REQ Message Contents

Application Server Request Message Fields

Field	Description
Protocol Version	5
Message Type	KRB_AP_REQ
Application Options Fields
Use Session Key	During user-to-user authentication, after the client has obtained a new ticket for the target service, the client will send a new KRB_AP_REQ with this flag set. This tells the target service to use its session key to decrypt the ticket. (See the User-To-User Authentication section above.)
Mutual Authentication Required	If this flag is set, the target server will respond with the KRB_AP_REP message, which will authenticate the target server to the client.
Other Message Fields
Ticket	The service ticket for the target server, encrypted in either the target server's secret key or in its session key, depending on whether user-to-user authentication is required.
Authenticator	The client's timestamp and other data, encrypted with the session key that the client and target server share.

Message 6: The Optional Application Server Response

This message is optional unless mutual authentication is required. The message is used if the client needs to verify the target server's identity. This is requested in an application options field (Mutual Authentication Required) of the KRB_AP_REQ message. If this is requested, the target server will take the client computer's timestamp from the authenticator, encrypt it with the session key that the TGS provided for client/target server messages, and send it to the client.

Note

• Most Windows services request mutual authentication.

How do the contents of the KRB_AP_REQ message prove to the client that the target server was the actual recipient of the client's authentication request? The authenticator is encrypted with the client/server session key. The session key is inside the service ticket. The service ticket is encrypted with the secret key shared by the server and the TGS. Thus, the only way the server can get access to the client's timestamp in the authenticator is to have information about the shared secret key, and the server would only have information about the secret key if it truly was the server and not an imposter.

To summarize, the steps in the mutual authentication process are:

1. The server receives the service ticket and the authenticator in KRB_AS_REQ.

2. The server uses its secret key to decrypt the ticket.

3. The server retrieves the session key from the ticket.

4. The server decrypts the authenticator with the session key.

5. The server retrieves the client's timestamp from the authenticator.

6. The server creates the mutual authentication message, includes the client's timestamp, encrypts the message with the session key, and sends KRB_AS_REP to the client.

7. The client decrypts this message with the session key, and thus the server is authenticated.

KRB_AP_REP message contents

The mutual authentication message is sent to authenticate the target server to the client.

The main information is simply a copy of the client's timestamp from the authenticator—that was previously included in the KRB_AP_REQ message—encrypted with the session key that the client and the target server share.

The application might require a new key for encrypting subsequent messages, replacing the session key, in which case the new key would need to be given to the server.

Application Server Reply Message Fields

Field	Description
Protocol Version	5
Message Type	KRB_AP_REP
	The following message fields are encrypted with the session key
Client Time	Current time on Client (from the authenticator).
CUSEC	Millisecond part of client time (from the authenticator).
Subkey	(Optional) Specifies a key to encrypt client sessions with application server.
Sequence Number	(Optional) Application-specific, so used if sequence number was specified in the authenticator.

Credentials Message Details

Credentials Message

The Kerberos credentials message is used to transport a user's ticket and session key securely to the service impersonating it. The ticket—because it is already encrypted—can simply be sent, but the session key will need to be encrypted.

KRB_CRED encryption

• The user's service ticket for Server is encrypted with Server's key (the key that Server shares with the KDC).

• The user's session key for Server is encrypted with the session key that the client and Delegate share. Server needs to use the session key, so it needs to be able to decrypt it.

KRB_CRED message contents

Credentials Message Fields

Field	Description
Protocol Version	5
Message Type	KRB_CRED
Ticket	The encrypted ticket is placed here. For the KRB_TGS_REP message, this will be the service ticket encrypted with the target server's secret key.
	The following message fields are encrypted with the session key that the client and Delegate share.
Key	This is the session key the client will use with the application server.
Principal Realm	(Optional) Name of the delegated principal's realm (domain).
Principal Name	(Optional) Delegated principal's name.
Flags	(Optional) These are the flags set in the ticket.
Authentication Time	(Optional) The time the ticket was issued.
Start Time	(Optional) At what time the ticket is valid.
End Time	(Optional) At what time the ticket expires (although it can be renewed if the ticket is renewable).
Renew Till	(Optional) At what time the ticket absolutely expires (cannot be renewed past this time).
Server Realm	(Optional) Requested server's realm (domain).
Server Name	(Optional) Requested server's name.
Client Addresses	(Optional) Addresses from which the ticket will be valid. If a ticket is proxied or forwarded, it will be used on the client's behalf from another address (or perhaps several addresses). These addresses will also be included in this field.
Nonce	The nonce from the KRB_TGS_REQ Nonce field will be copied here.
Timestamp	Time when KRB_CRED was generated.
USEC	Millisecond part of timestamp.
Sender Address	(Optional) Addresses, application-specific.
Recipient Address	(Optional) Addresses, application-specific.

To summarize, when proxying or forwarding, the credentials message contains three necessary items to impersonate the user. When proxying, the KRB_CRD message contains the:

• Proxy service ticket.

• User's session key with target server.

• Information that a normal user would have as the result of AS exchange.

When forwarding, the KRB_CRED message contains the:

• User's forwarded TGT.

• User's TGS session key.

• Information that a normal user would have as the result of TGS exchange.

With a valid ticket, session key, and other client information, the service is ready to impersonate the client, whether proxying or forwarding.

Kerberos and IP Transport: UDP/TCP

According to RFC 1510, when a client contacts the KDC, it should send a User Datagram Protocol (UDP) datagram to port 88 at the KDC's IP address. The KDC should respond with a reply datagram to the sending port at the sender's IP address.

UDP is a connectionless transport protocol, making it a logical choice where an exchange of messages must precede a connection. UDP is also well suited to applications with one message and one response, such as the exchanges between clients and the KDC, so long as each message fits into a single datagram. However, UDP works best when datagrams are transmitted as single units—when each datagram fits into one frame. The capacity of a frame varies with the medium. The Maximum Transmission Unit (MTU) for an Ethernet frame is 1500 octets. Thus, if the physical network is Ethernet, it follows that Kerberos messages sent as UDP datagrams can carry up to 1500 octets of data.

On the other hand, Windows authorization data can easily total more than 1500 octets. Because Windows authorization data is needed only by computers with the Windows operating system, Windows-specific data is omitted from tickets to computers with other operating systems. Messages containing tickets to computers with other operating systems are well within the limits of UDP transport, so that is how they are transmitted. Messages containing tickets for computers running Windows are likely to exceed the limit, so those messages are transmitted using the Transmission Control Protocol (TCP), which has much greater capacity.

This physical limit constitutes two different transport possibilities when computers with the Windows operating system send Kerberos messages on an Ethernet network.

• Messages below the 1465 maximum UDP payload are sent as normal UDP datagrams without incident.

• Messages that exceed the 1465 byte limit establish a TCP connection using port 88.

Finding the KDC: DNS Name Resolution

RFC 1510 specifies that IP transport should be used for messages between clients and the KDC. When the Kerberos SSP on a client computer wants to send an initial authentication service (AS) request, it needs to find an IP address for the KDC in the user account's domain.

To do that, the Windows client needs the Domain Name System (DNS) name of a server where the KDC service is running. If the DNS name can be resolved to an IP address, that is where the Kerberos SSP sends its message. Otherwise, the Kerberos SSP generates an error indicating that it can find no such domain.

Why Do Windows Systems Use DNS?

• The client computer needs the IP address of the KDC in the user account's domain.

• Windows systems use DNS to find IP addresses.

• Every Active Directory domain controller runs the KDC service. Domain controllers are advertised in DNS service locator records (SRV RR) as defined in RFC 2052.

Therefore, all that is needed to find a domain's KDC is to locate a domain controller's IP address by querying DNS for the SRV RR for domain controllers.

How the Kerberos SSP locates a KDC

1. If the Netlogon service is running, the Kerberos SSP asks Netlogon for the name of a domain controller (using the DsrGetDcName internal API).

2. If the domain controller's IP address is not found in the local cache, DNS is queried. The response will contain the DNS names of one or more domain controllers, along with their IP addresses.

   Clients that do not support the SRV record type in their DNS resolver can do a standard host record (A RR) lookup on ActiveDirectorydomainname. The response will contain the IP addresses of all domain controllers for the domain.

3. If the computer is a domain controller, the Kerberos client assumes that the KDC is running locally. If the KDC does not start or is not running, the Kerberos SSP finds another KDC in the domain.

4. After the client locates a domain controller, the KRB_AS_REQ message is sent to the KDC service on that domain controller.

Retrying

The Kerberos client retries up to three times to contact a KDC. It initially waits 10 seconds for a reply, and will wait an additional 10 seconds on each retry. After a failure, the Kerberos client forces discovery of another KDC.

Note

• In Active Directory domains, the KDC service runs on every domain controller. In addition to being KDC servers, domain controllers are also Lightweight Directory Access Protocol (LDAP) servers. Both services are registered in DNS service locator records (SRV resource records). Clients can find a domain controller by querying DNS for SRV resource records with the name _ldap._tcp.dc._msdcs.DnsDomainName. The KDC service can be located by querying DNS for SRV resource records with the name _kerberos._udp.DnsDomainName. Clients that do not support the SRV record type in their DNS resolver can query for a host record (an A resource record) with the name of the domain.

Locating MIT Kerberos KDCs

Computers running Windows 2000, Windows XP, and Windows Server 2003 can participate in Kerberos realms that are based on the MIT Kerberos version 5 reference implementation.

If the specified logon realm is determined to be an MIT Kerberos realm, then the Kerberos SSP retrieves the list of MIT KDCs from the registry.

The servers in the list are cycled through on each new request for a KDC without any attempt to verify if the KDC is running on the server.

Computers running Windows Server 2003 can participate in Kerberos realms that are not Active Directory domains. In this case, the KDC will not be on an Active Directory domain controller, so the DNS names for KDC servers must be stored in the client computer's registry. The Kerberos SSP looks in the registry for the DNS domain name of the user's realm, and then resolves the name to an IP address by querying a DNS server.

Windows Server 2003 includes Kerberos Setup (ksetup.exe), which you can use to configure clients to participate in Kerberos realms that are not Active Directory domains. To find more information about Kerberos Setup, see "Security Management Tools" in the Windows Support Tools section of the Tools and Settings Collection.

Network Ports Used by the Kerberos V5 Protocol

Network Ports Used During Kerberos Authentication

Service Name	UDP	TCP
DNS	53	53
Kerberos	88	88

Related Information

The following resources contain additional information that is relevant to this section.

• Active Directory Collection

• DNS Technical Reference

• Account Policy Settings

• Domain and Forest Trusts Technical Reference

• Windows Time Service Technical Reference