Windows Server


Kerberos: The Network Authentication Protocol    



Kerberos: The Network Authentication Protocol




Kerberos: The Network Authentication Protocol


The Microsoft Windows Server 2003 operating system implements the Kerberos version 5 authentication protocol. Windows Server 2003 also implements extensions for public key authentication. The Kerberos authentication client is implemented as a security support provider (SSP) and can be accessed through the Security Support Provider Interface (SSPI). Initial user authentication is integrated with the Winlogon single sign-on architecture. The Kerberos Key Distribution Center (KDC) is integrated with other Windows Server 2003 security services running on the domain controller. The KDC uses the domain’s Active Directory directory service database as its security account database. Active Directory is required for default Kerberos implementations.


1) Kerberos 5: Only Supported for IE 5.5+

Kerberos 5 is supported for Internet Explorer browsers continuing IE 5.5 and then later browsers.

2) Kerberos doesnot works on Internet

This is important to note that the Kerberos protocol is not supported on Internet.




Kerberos uses as its basis the Needham-Schroeder protocol. It makes use of a trusted third party, termed a key distribution center (KDC), which consists of two logically separate parts:

An Authentication Server (AS) and a Ticket Granting Server (TGS). Kerberos works on the basis of "tickets" which serve to prove the identity of users.

The KDC maintains a database of secret keys; each entity on the network — whether a client or a server — shares a secret key known only to itself and to the KDC. Knowledge of this key serves to prove an entity's identity. For communication between two entities, the KDC generates a session key which they can use to secure their interactions.


The security of the protocol relies heavily on participants maintaining loosely synchronized time and on short-lived assertions of authenticity called Kerberos tickets.

What follows is a simplified description of the protocol. The following abbreviations will be used:

     AS = Authentication Server

     TGS = Ticket Granting Server

     SS = Service Server

     TGT = Ticket Granting Ticket

Briefly, the client authenticates to AS using a long-term shared secret and receives a ticket from the AS. Later the client can use this ticket to get additional tickets for SS without resorting to using the shared secret. These tickets can be used to prove authentication to SS.

In more detail:

User Client-based Logon Steps:

1.      A user enters a username and password on the client machine.

2.      The client performs a one-way function (Hash mostly) on the entered password, and this becomes the secret key of the client.

Client Authentication Steps:

1.      The client sends a cleartext message to the AS requesting services on behalf of the user. Sample message: "User XYZ would like to request services". Note: Neither the secret key nor the password is sent to the AS.

2.      The AS checks to see if the client is in its database. If it is, the AS sends back the following two messages to the client:

o        Message A: Client/TGS Session Key encrypted using the secret key of the user.

o        Message B: Ticket-Granting Ticket (which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the TGS.

3.      Once the client receives messages A and B, it decrypts message A to obtain the Client/TGS Session Key. This session key is used for further communications with TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS's secret key.) At this point, the client has enough information to authenticate itself to the TGS.

Client Service Authorization Steps:

1.      When requesting services, the client sends the following two messages to the TGS:

o        Message C: Composed of the Ticket-Granting Ticket from message B and the ID of the requested service.

o        Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Client/TGS Session Key.

2.      Upon receiving messages C and D, the TGS retrieves message B out of message C. It decrypts message B using the TGS secret key. This gives it the "client/TGS session key". Using this key, the TGS decrypts message D (Authenticator) and sends the following two messages to the client:

o        Message E: Client-to-server ticket (which includes the client ID, client network address, validity period and Client/Server Session Key) encrypted using the service's secret key.

o        Message F: Client/server session key encrypted with the Client/TGS Session Key.

Client Service Request Steps:

1.      Upon receiving messages E and F from TGS, the client has enough information to authenticate itself to the SS. The client connects to the SS and sends the following two messages:

o        Message E from the previous step (the client-to-server ticket, encrypted using service's secret key).

o        Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted using client/server session key.

2.      The SS decrypts the ticket using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, SS decrypts the Authenticator and sends the following message to the client to confirm its true identity and willingness to serve the client:

o        Message H: the timestamp found in client's Authenticator plus 1, encrypted using the Client/Server Session Key.

3.      The client decrypts the confirmation using the Client/Server Session Key and checks whether the timestamp is correctly updated. If so, then the client can trust the server and can start issuing service requests to the server.

4.      The server provides the requested services to the client.




Single point of failure: It requires continuous availability of a central server. When the Kerberos server is down, no one can log in. This can be mitigated by using multiple Kerberos servers.

Kerberos requires the clocks of the involved hosts to be synchronized. The tickets have time availability period and, if the host clock is not synchronized with the clock of Kerberos server, the authentication will fail. The default configuration requires that clock times are no more than 10 minutes apart. In practice, Network Time Protocol daemons are usually used to keep the host clocks synchronized.

The administration protocol is not standardized, and differs between server implementations. Password changes are described in RFC 3244.

Since the secret keys for all users are stored on the central server, a compromise of that server will compromise all users' secret keys.



Kerberos Authentication Dependencies


Operating System

Kerberos authentication relies on client functionality that is built in to the Windows Server 2003 operating system, the Microsoft Windows XP operating system, and the Windows 2000 operating system. If a client, domain controller, or target server is running an earlier operating system, it cannot natively use Kerberos authentication.


TCP/IP Network Connectivity

For Kerberos authentication to occur, TCP/IP network connectivity must exist between the client, the domain controller, and the target server. For more information about TCP/IP, see “TCP/IP Technical Reference .”


Domain Name System

The client uses the fully qualified domain name (FQDN) to access the domain controller. DNS must be functioning for the client to obtain the FQDN.

For best results, do not use Hosts files with DNS. For more information about DNS, see “DNS Technical Reference .”


Active Directory Domain

Kerberos authentication is not supported in earlier operating systems, such as the Microsoft Windows NT 4.0 operating system. You must be using user and computer accounts in the Active Directory directory service to use Kerberos authentication. Local accounts and Windows NT domain accounts cannot be used for Kerberos authentication.


Time Service

For Kerberos authentication to function correctly, all domains and forests in a network should use the same time source so that the time on all network computers is synchronized. An Active Directory domain controller acts as an authoritative source of time for its domain, which guarantees that an entire domain has the same time. For more information, see “Windows Time Service Technical Reference .”


Service Principal Names

Service principal names (SPNs) are unique identifiers for services running on servers. Every service that uses 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, clients have no way of locating that service. Without correctly set SPNs, Kerberos authentication is not possible. For more information about user-to-user authentication, see “How the Kerberos Version 5 Authentication Protocol Works ,” and search for “The User-to-User Authentication Process.”







Protocol Transition


The following items summarize the protocol transition implementation details that are described in this document:

The protocol transition extension can be initiated in two ways:

Programmatically through the LsaLogonUser function or the WindowsIdentity class object. This approach is recommended when the initial user-authentication mechanism is not one of Windows-integrated authentication protocols. The process must have the Act as part of the operating system privilege for the function to create an impersonation-level token. If the process does not have the Act as part of the operating system privilege, an identification-level token is created.


Using existing Windows-integrated authentication protocols for the initial user logon procedure with credentials, and using Kerberos protocol transition for subsequent user authentication to other services. The Kerberos SSP initiates the protocol transition extension if the user token that you created for initial logon is an impersonation-level token.


You must run the operating system process that initiates protocol transition on a computer that is running Windows Server 2003.


You can use protocol transition both in and across Active Directory forests.


When you use protocol transition in an Active Directory forest, all domain controllers that are located in the user and service accounts trust path and that are used for the protocol transition process must be running Windows Server 2003. To meet this requirement, use one of the following methods:

Upgrade all of the domain controllers that are in the domain that is participating in protocol transition to computers that are running Windows Server 2003. This approach requires that all of the domain controllers in the domain are running Windows Server 2003.



Upgrade all of the domain controllers in the Active Directory sites that are participating in protocol transition to computers that are running Windows Server 2003. This approach does not require that all domain controllers that are in the domain are running Windows Server 2003. This approach is recommended if you cannot upgrade all of the domain controllers in the domain to Windows Server 2003, and if you can isolate the applications that require the protocol transition extension to a certain number of Active Directory sites for which you can upgrade all of the domain controllers.


When you use protocol transition across Active Directory forests, both forests must be operating at the Windows Server 2003 forest functional level and two-way forest trust must be established between the forests.



Constrained Delegation


The following items summarize the constrained delegation implementation details that are described in this document:

The constrained delegation extension is affected by the following domain policies that are set in Active Directory:

The requesting service must be trusted for constrained delegation (the T2A4D flag must be set for the requesting service) if Kerberos is not used as the initial user authentication protocol.


The requesting service must be authorized to delegate to the target service (the target service must be on the requesting services A2D2 list).


You cannot use constrained delegation between services whose accounts are in different domains. All domain controllers in the domain must be running Windows Server 2003, and the domain must be operating at the Windows Server 2003 functional level. The accounts of users accessing the services do not have to be in the same domain as the services


Delegation is a security pattern that occurs frequently in n-tier applications. At the time when this document was published, Kerberos was the only widely-adopted authentication protocol that possessed the delegation property. In this document, the Kerberos extensions on computers that are running Windows Server 2003 are discussed. The document also describes how the extensions allow many applications to use the authentication protocol. The sample code illustrates how n-tier Web services and applications can use the new feature. Protocol transition provides application designers with increased flexibility and security by enabling applications to support different authentication mechanisms at the user authentication tier, and by switching to the Kerberos protocol for security features, such as mutual authentication and constrained delegation, in the subsequent application tiers.


Constrained delegation gives administrators the ability to specify and enforce application trust boundaries by limiting the scope where application services can act on a users behalf. This flexibility to constrain a services authorization rights helps improve application security design by reducing the opportunities for compromise by untrusted services.


Constrained vs. General Delegation:

General delegation will allow the first hop server to request Kerberos tickets on the client behalf to any other resource in the forest.

Constrained delegation is not supported by all Kerberos aware applications. The domain functional level must be 2003. It allows the administrator to selectively allow an account to request Kerberos tickets limited to specific services on specific servers. This is a much more secure method of delegating Kerberos delegation. The service accounts and the computer accounts hosting the applications need to be in the same domain. If the service account is a user account the delegation tab maybe missing. Until the account has a service principal name registered for it there will not be a delegation tab and you will not be able to setup constrained delegation.




No TrackBacks

TrackBack URL: http://www.skar.us/site/mt-tb.cgi/3203

Leave a comment


Author Bio          ★★★★★

Author Name:         ebhakt
Author Location:    India
Author Rank:          Writer
Author Status:        
The Green leave stands!!



  • eBooks
  • Games
  • Softwares
  • Tools
  • Tweaks
  • Wallpapers
  • Warez
  • Games
  • Tools
  • Wallpapers
    System Administration
  • dll Center
  • Scripts
  • Tools
  • .extensions database
  • Write-up
  • Download Database
  • Jobs
  • Lists
  • Polls
  • Glossary

01000011 01110010 01100001 01100011 01101011 01111010 01101000 01100001 01100011 01101011