Share via

Kerberos and Self-Service Password Reset

  • Article

The following section is presented to explain Kerberos and how it pertains to Self-Service Password Reset.

What is Kerberos?

The Kerberos authentication protocol provides a mechanism for authentication — and mutual authentication — between a client and a server, or between one server and another server. The Kerberos authentication protocol originated at MIT more than a decade ago, where it was developed by engineers working on Project Athena. The Kerberos protocol is more secure, more flexible, and more efficient than NTLM. The benefits gained by using Kerberos authentication are:

  • Delegated Authentication

  • Interoperability

  • More efficient authentication to servers.

  • Mutual authentication

Kerberos authentication has the following authentication dependencies:

  1. Operating System - client must be XP or later and server must be 2000

  2. TCP/IP connectivity - network connectivity must exist between client, domain controller and target server

  3. DNS - DNS must be functioning for the client to obtain the FQDN. The FQDN is used to access the domain controller.

  4. Active Directory

  5. Time Service

  6. SPN - Service principal names (SPNs) are unique identifiers for services running on servers.

What are SPNs?

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.

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.

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:

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

  2. The account under which the service is running.

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

  4. 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:

  1. Service is the service class of the SPN.

  2. Hostname is the computer to which the SPN belongs.

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

How are tickets decrypted

A client makes a HTTP Request to an IIS server running SharePoint. The IIS server denies the request with a 401 Authorization Required and indicates to the client that it supports Kerberos authentication. The client then requests a Service Ticket from the KDC on a Domain Controller. This is done by sending the SPN for that service to the DC. The DC finds the domain account that matches the SPN and creates a ticket for the client. The ticket is encrypted with the password for the domain account of the receiving application, for example the SharePoint service account. The DC returns the Service ticket to the client. The client, then sends the ticket to IIS, in the authentication header to prove the identity of the client. To decrypt the ticket IIS must know the password of the domain account, in this case, the SharePoint service account. The password for this account is encrypted and stored in the applicationHost.config file. IIS will then decrypt the ticket.

Kernel-Mode Authentication

With the release of IIS 7.0 on Windows Server 2008 and IIS 7.5 on Windows Server 2008 R2 a new mode kernel-mode authentication was introduced. This means that the ticket for the responding service is decrypted using the Machine account (Local System) of the IIS Server. It no longer depends on the application pool Identity for this purpose by default. You no longer need to worry about the correlation between HTTP SPNs and the Application pool Identity that was required in the earlier versions of IIS.

By default, UseKernelMode Authentication is set to true automatically on the applicationHost file after the password registration and password reset portals have been installed.

SPNs and Self-Service Password Reset

Setspn -S HTTP/passwordregistration.corp.contoso.com corp\SSPR1$Setspn -S HTTP/passwordreset.corp.contoso.com corp\SSPR1$

Delegation and Self-Service Password Reset

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.

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.Delegation is possible only with the Kerberos protocol. Thus, all parties involved in delegation scenarios must use the Kerberos protocol.

In order to make a Forefront Identity Manager 2010 R2 deployment more secure, certain service accounts, namely the FIM Service account and the SharePoint Service account should be setup to use constrained delegation. However, with regard to the FIM Password Service account, this is not the case. As mentioned above, the web application pool account, or the FIM Password Service account does not need any SPNs set on it. Likewise, it does not need to be setup for delegation. This is because the FIM Service account is already aware of the FIM Password Service account. For more information on the FIM Service and portal communication see the FIM 2010 R2 Password Registration Portal and FIM 2010 R2 Password Reset Portal topics.