Overview

Below is a brief introduction to Kerberos Authentication.  This introduction is by no means complete.  This introduction is included because it will help you understand why the security enhancements to Windows authentication have been made and how they improve security.

Kerberos is the default method of authentication in Windows.  It is authentication between security principals. Most often it is used as a method for a Principal to authenticate to a Service. Security principals are referenced by either a User Principal Name (UPN) or Service Principal Name (SPN). An example of a user principal name would be: joe@contoso.com.  An example of a Service Principal Name would be http/web01.contoso.com.

Kerberos authentication leverages a trusted entity called a KDC or Key Distribution Center.  The KDC is responsible for authenticate the client and creating tickets that are used by the client to authenticate themselves to a service.  The KDC logically consists of an Authentication Service (AS) and a Ticket Granting Service (TGS).  The AS is responsible for authenticating users and computers and then issuing a TGT.  The TGS is responsible for issuing service tickets, often called TGS tickets to the authenticated computer or user.

User Principal Names (UPN)

A User Principal Name is an attribute on a user object called userPrincipalName.  Below is an example of viewing the UPN through Active Directory Administrative Center.

Below is an example using the Get-ADUser cmdlet with the UserPrincipalName property to get the UPN for the user joe.

Typically UPNs are derived from the forest root domain name for example: <user>@<forestrootdomain>.  However, you can add additional UPN suffixes in the Active Directory Domains and Trusts mmc as illustrated below. 

When additional UPN suffixes are added you can choose which suffix you would like to use, as illustrated below.

Service Principal Names (SPN)

Service Principal Names are used typically as a way to identify services running on a computer or services running under a service account. The service principal names are registered under the account which the service runs under.  If a service runs under a computer account it would be registered on the computer object.  If a service runs under a service account, then the SPN is registered on the service account.

Service Principal Names are in the following format:

< service type >/< host name >:< port number >

Although port number is typically excluded, unless the service is running on a non-standard port.  An example for a web server again would be http/web01.contoso.com, an example for a SQL Server would MSQLSvc/SQL01.contoso.com:1433. 

In addition there is a HOST name which is essentially an alias for a number of SPNs.  The Active Directory Configuration determines which SPNs to which Host is aliased. This is determined by the attribute sPNMappings, on the CN=Directory Services,CN=Windows NT,CN=Services,CN=Configuration,<DN of the Forest>. By default HOST can serve as an alias for all of the SPNs listed in the table above.

Service Principal Names can be viewed and modified using a number of tools, including Active Directory Administrative Center, ADSIEdit.msc, setspn.exe, and PowerShell.

Below is an example using Active Directory Users and Computers to view the ServicePrincipalName attribute:

And, an example of viewing SPNs with the setspn.exe tool:

Setting SPNs

SPNs can also be added to an object.  Below is an example of adding the http/web01 SPN to a Service Account named svcWeb using the setspn.exe tool.

Checking for Duplicate SPNs

Having the same SPN registered on multiple Active Directory objects will cause authentication issues.  This is due to the fact that when the Domain Controller looks up the SPN it will see it registered in multiple place and will be unable to “know” which object to issue the service ticket. When this happens a KDC Event 11 is logged in the event log.  To check for duplicate SPNs in the forest, use the following syntax with the setspn.exe tool:

Setspn –F –X

Kerberos Authentication Process

Below is a screen shot that of a network trace showing the interaction between the client and the KDC during the Kerberos Authentication Process.

STEP 1: AS Ping

An AS_REQ is sent is sent without a pre-authenticator.  An AS_REQ is normally sent to the DC in order to get a TGT which can later be used to get service tickets to services the principal to which the principal is going to authenticate. However, the purpose of this first AS_REQ is to intentionally create a failure condition.  The reason for creating the failure condition is to get a list of the symmetric ciphers that the KDC supports.

STEP 2:  KDC_ERR_PREAUTH_REQUIRED

The KDC Responds with an Error: KDC_ERR_PREAUTH_REQUIRED.  Included in the response is a list of cipher suites that the KDC supports.

STEP 3: KRB_AS_REQ

Client encrypts a time stamp with it’s long term key, this is call the pre-authenticator.  Additional information includes the client’s name as well as the target service name (sname) which is this case would be krbtgt. Since the KDC resides on a Domain Controller it has knowledge of the long term keys (passwords) for all users and computers in the domain.  Hence, KDC is able to decrypt the Pre-Authenticator and validate that timestamp is within 5 minutes of the Domain Controller’s current time. If the timestamps is outside of the 5 minutes, the following error is sent to the client: KRB_AP_ERR_SKEW. As seen in the following network trace, if the client receives the KRB_AP_ERR_SKEW from the client it will submit a new KRB_AS_REQ with the timestamp of the KDC which is included in the packet that includes the error message.

STEP 4: KRB_AS_REP

The KDC then creates the Ticket Granting Ticket (TGT), this will be used later by the Client and the DC when the client request service tickets.  The TGT contains: Privilege Account Certificate (PAC) and a Session Key.  The TGT is then encrypted with long term key of the KRBTGT account.  A copy of the session key is also then encrypted with the client’s previously established session key.  This encrypted session key is inserted into the response along with the TGT and sent to the client.

STEP 5: KRB_TGS_REQ

The client sends a request to get a ticket to a services.  The request will be made for a Service Principal Name (SPN).  The client’s TGT is included with the request.  The TGT of course allows the client to prove to the KDC that the client was previously authenticated by the KDC. However, an additional authenticator is included with this message and encrypted with the session key that the user previously received from the KDC during the KRB_AS_REP. The KDC decrypts the TGT, by first decrypting the session key with the long term key of the KRBTGT account.  Then uses the session key to decrypt the TGT, as well as the authenticator. The KDC then needs to locate the SPN in the directory.  If the service runs under and account that is associate with the computer such as SYSTEM or NetworkService the SPN for the service will be registered on the Computer object in Active Directory.  If the service runs under a service account the SPN will be registered on a User object in Active Directory. If the SPN is not registered then the request will fail.  The only exception to this is if the SPN maps to the HOST SPN that is registered on that principal under which the service is running.  If the SPN is registered on multiple objects the request will fail, a KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN error will be sent to the client and a KDC Event ID 11 will be logged on the KDC. 

STEP 6: KRB_TGS_REP

KDC creates the KRB_TGS_REP by creating a TGS ticket for the service.  The TGS ticket includes a new session key and PAC, which is encrypted with the longterm key of the principal hosting the service to which the client is attempting to authenticate. There message also includes another copy of the session key which is encrypted with the session key of the client that was previously generated by the KDC and included in the KRB_AS_REP.

STEP 7: KRB_AP_REQ

Now the client will attempt to authenticate with the service it will send a message to the service that includes the TGS ticket previously created by the KDC as well as an authenticator encrypted with the shared session key. The KRB_AP_REQ message is typically imbedded in the protocol with which the client is trying to communicate through.  For example if the client is accessing a file share you will see the KRB_AP_REQ embedded in SMB communication.  The server on which the service runs on validates the authenticator and then determines if the client is authorized to access the service.

STEP 8: KRB_AP_REP

If mutual authentication is requested, the service sends a response which includes an authenticator as well as the clients previously sent authenticator, both of which are encrypted with the shared session key.  Much like the KRB_AP_REQ this message is embedded in the protocol for which authentication is attempting to be established.

Conclusion

STEPS 1-4 are not performed for any authentication.  The TGT that the client receives from the KDC by default is valid for 10 hours.

-Chris