Using Kerberos for SharePoint

Authentication
Pav Cherny

A lthough SharePoint offers multiple authentication options and authentication zones, the two
most common choices for enterprise implementations in intranet scenarios are NTLM and
Kerberos. Both of these protocols are used with Integrated Windows authentication in a classic
challenge/response scheme. NTLM relies on IIS generating a token with a challenge, sending it
to the client, the client responding with a token, and a domain controller validating that response.
NTLM requires user names and passwords to be encrypted before they are transmitted, and also
requires re-authentication (a new token) when accessing a new network resource. Kerberos, on
the other hand, relies on a ticketing system where a client and server access a trusted authority
called a Key Distribution Center (KDC), which responds to client requests and grants tickets that
the client can use to access network resources. Kerberos does not require re-authentication for
accessing multiple resources.

Much of the documentation out there advocates using NTLM unless there is a compelling need,
such as for sites with a high security service level agreement. Even in this case, if you dig
deeper, the more obvious answer is presented for using NTLM: it’s easier to implement, requires
no additional steps, and likely reduces support issues. For example, KB 832769 says, “… or if
you cannot configure the service principal name (SPN), choose NTLM authentication. If you
choose Kerberos authentication and cannot configure the SPN, only server administrators will be
able to authenticate to the SharePoint site.” The guidance is technically accurate, but it does
seem to suggest that configuring SPNs is overly complex, or that you should stay away from
Kerberos unless someone makes you implement it. But the reality is that if you understand the
principles, implementing Kerberos is not that hard.

There are many good reasons why you should transition to Kerberos, or use Kerberos from the
beginning in a new implementation, but in most cases it comes down to either performance or
security. As user load or topology complexities increase, NTLM can introduce performance
issues because NTLM-based authentication inherently requires multiple round trips between IIS
and a domain controller for many SharePoint usage scenarios, such as a Web application
accessing a SharePoint Web Part or custom Web service. The potential for performance issues is
especially true if the domain controller is accessible over a slow or high-latency link. In terms of
security, a ticket-based system (Kerberos) with explicit delegation of network resources is more
secure by design than only encrypting user credentials. It is also faster because it uses a single
ticket to access multiple network resources.

Many installations start with NTLM instead of Kerberos because planning topologies, server
sizing, Security Support Providers (SSPs) and other details already seem daunting, and adding
even more complexity seems like it will be too much to handle. This reservation has its
justifications. After all, Kerberos-enabled implementations are not free of issues. Just look at the
KB articles 871179, 962943, and 832769 for some possible issues, which may be as severe as a
stop error on a blue screen. Even existing documentation, such as the detailed guide for Kerberos
implementation from Microsoft, does not include details about IIS version 7 and later, which
implement a kernel-mode authentication feature and change the way SPNs are handled. But
don’t worry, if you understand the fundamental concepts of how SharePoint uses Kerberos, it’s
relatively straightforward to implement and configure. This article covers the essential
architecture components and includes some configuration details to help you get started.
Microsoft has already published documentation with step-by-step details and KB articles 832769
and 953130 that you can use for additional reference.

Authentication Components and Dependencies

Let’s start by looking at dependencies in the SharePoint architecture that deal with Integrated
Windows authentication. At the most basic level, with NTLM or Kerberos, there is a client
making requests to a SharePoint-enabled .aspx Web page, which uses .NET and IIS in the
background. The page in turn relies on data from the SQL Server configuration and content
databases. The way IIS handles requests in the SharePoint 2007 context as they relate to
authentication is shown in Figure 1. When a client browser makes a Web request, this initiates a
thread in IIS, and objects relating to the request, such as the token contained in the IIdentity
object, which is contained in the IPrincipal object, are attached to the thread. Programmatically,
the IIdentity and IPrincipal objects are accessed through the HttpContext.User property, and both
the objects and property are set by authentication modules that are part of the .NET pipeline, as
shown in Figure 1.

Figure 1 Common Authentication Components and Data Flow in SharePoint

The following process details the data flow:

 1. A client browser initiates a connection to a SharePoint front-end server (handled by IIS
with .NET) through an HTTP GET request as anonymous.
2. If the zone is configured for anonymous access (such as for Internet scenarios), IIS
continues to process the request. Otherwise, IIS returns error 401.2 and requests
authentication from the client browser.
3. The client browser receives the request and, depending on the zone and associated
options, authenticates the client. A common method is by calling
AcquireCredentialsHandle and prompting for a username/password, and then passing an
auth token back to SharePoint via IIS.
4. IIS is waiting for a response in the HTTP conversation and accepts the auth token, and
then either authorizes or denies access. At this point, IIS passes the request to SharePoint
through .NET.
5. If the requested page has a Web Part that needs to access the back-end SQL databases,
SharePoint authenticates with the SQL Server and accesses the databases. The nature of
the SQL authentication varies with the configuration options. For example, you can
configure SQL Server authentication or Integrated Windows authentication using NTLM
or Kerberos. I cover the Kerberos and NTLM specifics later in the article.

The key takeaway from the authentication mechanisms in SharePoint is that three layers play a
part: the client browser, IIS with .NET and SQL Server. In order to return a compiled .aspx page,
authentication and authorization take place both between the client and between IIS and the SQL
Server. Sometimes the process is simplified, such as when using NTLM in a scenario where SQL
Server resides on the same physical server as IIS. In that case, there is only a single hop from the
client to IIS. For more information about authentication in .NET, see Explained: Windows
Authentication in ASP.NET 2.0.

NTLM and Kerberos

Now that we have covered the underlying mechanism that Windows Server, IIS, and .NET use in
authenticating and authorizing users, let’s examine how that fits into the context of Integrated
Windows authentication with NTLM and Kerberos. As already mentioned, the key difference
between NTLM and Kerberos is that whereas NTLM uses a challenge/response mechanism
requiring authentication and authorization for accessing each network resource, Kerberos uses a
ticket system that authenticates once and then authorizes through delegation. Don’t worry if this
difference seems unclear, I’ll cover the specifics next. Figure 2 shows how SharePoint handles
requests when using NTLM.
Figure 2 NTLM Authentication in SharePoint

As Figure 2 suggests, using NTLM requires a domain controller that is able to authenticate
users. If the domain is operating in native mode, by default a global catalog is required on the
domain controller or on another server. This is yet another potential performance issue, in
addition to the double-hop concern, because after a domain controller is contacted, it proxies
authentication requests to a global catalog server if the global catalog is not locally available.
With slow links, this can use up a lot of resources and bandwidth. You can try to squeeze some
extra performance with NTLM authentication, such as by changing the value of the
MaxConcurrentApi registry entry, but it doesn’t resolve the fundamental need in NTLM to rely
on a challenge/response scheme, and the associated performance issues under high loads.

The details of NTLM authentication for accounts in the same domain are as follows:

1. The process starts as mentioned earlier, when a client browser initiates a connection to a
SharePoint server running IIS with .NET using an HTTP GET request, and attempts to
authenticate as anonymous.
2. IIS rejects the anonymous request with a 401.2 error and sends back a request to
authenticate with NTLM (WWW-Authenticate: NTLM).
3. The client browser receives the request and calls InitializeSecurityContext to create the
Auth token that includes domain and computer name, and then sends the auth token to
IIS.
4. IIS accepts the details and sends an NTLM challenge to the client.
5. The client responds with the response to the challenge (auth token again), encrypted with
the password of the user.
6. At this point, IIS needs to talk to the domain controller. It sends the client’s user name,
challenge, and challenge response.
7. The domain controller retrieves the password hash for the user and compares t to the
challenge response, which was encrypted using the user’s credentials. If there’s a match,
the domain controller returns a successful authentication to IIS, and IIS can talk to the
client browser.
 8. From here, the Web application authenticates with the SQL Server and can access the
content database that contains the data for the .aspx page.

If you’ve ever tried to configure Kerberos in the Central Administration Web page for a basic
installation, you know that after choosing Kerberos instead of NTLM, the resulting message tells
you to configure an application pool account to explicitly permit Kerberos unless the application
pool is running under the context of Network Service. This is due to the way Kerberos-based
authentication works in requiring SPNs. In both WSS and MOSS, a Web application is really an
IIS Web site assigned to an application pool that runs under the context of a built-in or user
account. It is possible, but not a best practice, to assign multiple Web sites to the same
application pool. Unless you make a change, IIS uses the Network Service account for
application pools and not a unique domain account. However, for Kerberos to work in
SharePoint, you must set a unique SPN against the application pool account.

In practical terms, Kerberos-based communication relies on having a client and a server capable
of supporting Kerberos, a KDC to act as the in-between authorizer, and SPNs. The technical
details are slightly more complex. For example, Kerberos also requires either DNS integrated
with Active Directory or BIND with SRV records, TCP/IP, and a time service. Chances are, if
you’re using Windows Server 2003 or 2008 with integrated DNS, you already have the
necessary components and just need to configure them. Figure 3 shows the various components
involved and the data flow in Kerberos-based authentication in SharePoint.

Figure 3 Kerberos Authentication

1. As with NTLM, a client browser makes an HTTP GET request as anonymous using a
host name (FQDN or alias).
2. A front-end server responds with a 401.2 error and the WWW-Authenticate: Negotiate
header and/or the WWW-Authenticate: Kerberos header, which indicates that it supports
Kerberos authentication. You must configure this explicitly on front-end servers in
Central Administration, as I cover later.
3. The client contacts the KDC on the domain controller and requests a ticket for the SPN
based on what the browser client sent as the hostname.
4. If the KDC locates a matching SPN, it encrypts the ticket and returns it.
 5. The browser client creates the authenticator and sends it with the service ticket to the IIS
server, which in turn decrypts the ticket, determines identity, and checks the permissions
(access control list) on the requested resource to see if access is permitted.
6. If access is permitted, IIS, through the Web Application service, contacts the SQL Server
and the service requests a ticket for the SQL Server from the KDC.
7. If an SPN is found, the KDC returns the ticket, which the Web application uses to query
the content database, and through delegation impersonates the user.
8. The SQL Server checks the ticket from the Web application, and validates it. Upon
success, SQL Server sends the data back to the server, and .NET can compile the aspx
page and send it to the browser.

Understanding SPNs

SPNs provide one of the more challenging aspects of Kerberos configuration because they are
registered with the KDC as unique identifiers for the client resources that are authorized to
access specific server resources. Both clients and servers in Integrated Windows authentication
inherently trust the KDC because in almost all cases, it is also a domain controller, and the KDC
needs a method to determine whether to grant a ticket for a request or not—and this is the SPN.
As already mentioned, when you set a domain user account for an application pool, you must
also set an SPN against it in order for anyone to access the Web application associated with the
application pool.

An SPN is a unique identifier string for a service that runs on a server. It is stored in Active
Directory in the multi-valued attribute of a user account called Service-Principal-Name.
Multiple services on a host or multiple hosts are distinguished by their unique SPNs. Perhaps I
am overemphasizing the importance of SPNs, but it is for good reason. Incorrectly configured
SPNs break Kerberos authentication. If you set two identical SPNs, or forget to set an SPN, or
misconfigure a part of an SPN, authentication doesn’t work.

Let’s look at an example of an SPN to see how Kerberos uses them. An SPN is composed of
three parts: the service class that identifies the type of service, the computer name of the host on
which the service runs, and the port. Putting those components together, the syntax is service
class/host: port. For SharePoint, the two relevant names are HTTP and MSSqlSvc. The service
names are not arbitrary and are defined as specific aliases for a service. The host name part is the
FQDN or NetBIOS name, optionally including the port. When registering SPNs, it is a best
practice to register an SPN for both NetBIOS and FQDN host names so that regardless of the
method clients use, they can access resources on the target host.

Earlier, I mentioned that unless you run an application pool under the Network Service account,
you need to explicitly register SPNs. This is because when a computer joins an active directory
domain, SPNs are automatically created for the computer account in the format
HOST/<NetBIOSname> and HOST/<FQDN>. Because the Network Service account acts as a
computer on the network, the SPNs are valid for it. However, it is not a best practice to use the
local Network Service account because of security concerns and because it can break some
scenarios. For example, if you’re restoring or attaching a content database that was configured
with the Network Service account, you must add the account to the local Administrators group
on the SQL Server, and then remove it again after attaching the database. Most of the existing
documentation recommends using domain accounts.

Back-End Configuration

You must first configure Kerberos authentication on SQL Server whether you are transitioning
an existing farm or installing a new one. The SQL Server must meet the requirements already
mentioned, such as being joined to the domain, having access to a domain controller that is also a
KDC, and so on. For most environments, these requirements are met by default when using
Active Directory with integrated DNS. You do not need to configure Kerberos explicitly if your
environment uses only front-end SharePoint servers and no application servers, such as ones
running Excel Services or SQL Reporting Services. The default SPN created when the SQL
Server is joined to the domain is enough for basic front-end/back-end connectivity.

Configuring Kerberos is relatively straightforward on SQL Server. First, you set the relevant
SPNs, then verify that Kerberos is being used and not the default NTLM. You should set the
NetBIOS name and the FQDN in the format MSSQLSvc/<NetBIOS_Name>:1433 and
MSSQLSvc//<FQDN-hostname.domain.local>:1433, assuming your instance uses the default
1433 port. Although you can use either the setspn tool or ADSIEdit to set the SPNs, setspn is
often a better choice because it validates the syntax of your input to make sure it is correct. With
ADSIEdit, in contrast, you write the SPNs into the servicePrincipalName attribute directly. To
create the two SPNs, run setspn-A MSSQLSvc/<NetBIOS_Name>:1433
<domain>\<username> and setspn-A MSSQLSvc/<FQDNe>:1433
<domain>\<username>, where the user name is the SQL Server service account.

To confirm that SQL Server traffic is using Kerberos, you can trace the traffic with a packet
analyzer such as Wireshark, use a tool such as Kerbtray.exe, or check the event logs. If you
connect to the SQL instance using SQL Server Management Studio, the Security event log
should show Event ID 540, in which the logon process and authentication package use Kerberos.
For more information, see Configure Kerberos authentication for SQL communications.

Front-End and Application Server Configuration

After ensuring that Kerberos works in SQL Server, you can move on to configure SharePoint by
setting SPNs for application pools, enabling Kerberos for SSPs and Web Applications, and
completing some final configuration steps. The SPN configuration is similar to what you do for
the SQL Server service account, but there are many more SPNs to configure. Recall that SPNs
are constructed based on what a user enters in the address bar of the client browser, so you must
set SPNs for each entry a user may make in the address bar to access a site. This includes
FQDNs, NetBIOS names, and aliases in the form of host headers. Figure 4 lists a sample of
resource types and the SPNs that need to be registered for each one.
Figure 4 SPNs for a Basic MOSS Farm

There are a few things you should keep in mind in setting SPNs. First, the SPNs are registered
for a SharePoint-enabled Web site just as they would be for any IIS Web site. It’s important to
specify the correct host name and account under which the application pool runs for each site. If
you’re using multiple host headers, make sure SPNs are set for all of them. Second, it’s not
necessary to specify ports for HTTP and HTTPS, but you should specify any custom ports. And
third, there are some additional dependencies you may need to configure, such as a registry
change for IIS to support forming SPNs with custom ports, and an update to support SSPs. You
can find more details in Configure Kerberos authentication (Office SharePoint Server).

There are two more major steps you should complete for Kerberos to work in the
environment. You must configure computer accounts and some service accounts for delegation,
and you must configure your farm for Kerberos in Central Administration. The idea of
delegation in Kerberos is that if a user makes a request to a final resource, and some intermediary
accounts must process the request, then those intermediary accounts can be trusted to delegate on
the user’s behalf. You can configure an account for delegation by using Active Directory Users
and Computers as a domain administrator. Select Trust this user/computer for delegation to any
service (Kerberos) under the Delegation tab of the user or computer account. You should enable
delegation for the front-end, application, and SQL Server computer accounts, for the application
pools (SSPAdmin, MySite, various Web Apps), and for the farm service account.

In addition, you need to set permissions in Component Services. Under the default properties, set
Impersonation Level = Delegate. Under IIS WAMREG Admin Service, navigate to the Security
tab, and grant Local Activation permissions to the application pool accounts. For more
information, see KB 917409, and 920783.

After you enable delegation, it’s time to wrap up the configuration details by enabling Kerberos
as the preferred protocol for SSPs and Web applications. For a new installation, you can do this
for the Central Administration site in the SharePoint Products and Technologies Configuration
Wizard. Otherwise, navigate to Authentication Providers under Application Management in
Central Administration, click Default and set the method to Negotiate (Kerberos). Don’t forget to
run iisreset /noforce to apply the changes to the application pools, and to enable Kerberos for
SSPs.

Changes in IIS 7 and Windows Server 2008

So far, I have kept the discussion mostly limited to SharePoint 2007 on Windows Server 2003
and IIS 6. If you move to Windows Server 2008 and IIS 7, there are some changes in the
architecture that may require some additional configuration steps. Perhaps the most notable
change is that IIS 7 supports kernel-mode Kerberos authentication. In kernel-mode
authentication, the Network Service account (really, this is the same as the computer account
already mentioned) decrypts tickets unless you specify otherwise. Kernel-mode authentication is
enabled by default when you migrate to IIS 7 or install a new farm. Recall that the Network
Service account is a local account. If you are running a single server, then decryption works. In a
farm, however, it fails because you need to use domain accounts that can be verified against the
KDC. This change also means that you can do protocol transition (enabling clients to use non-
Kerberos authentication to IIS, and IIS uses Kerberos for back-end communication) by using the
Network Service account, as it already has LocalSystem privileges.

To configure Kerberos in your SharePoint farm that is running IIS 7, you need to manually
change the %WinDir%\System32\inetsrv\config\ApplicationHost.config file— there is currently
no GUI option. The relevant entry is as shown here.

<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled="true" useKernelMode="true"
useAppPoolCredentials="true" />
</authentication>
</security>
</system.webServer>

Don’t forget to run iisreset /noforce to apply the changes and check for the latest updates for
issues, such as the blue screen update detailed in KB 962943.
There is one more configuration detail you should be aware of if your configuration uses identity
impersonation (<identity impersonate="true" /> in web.config) and the Integrated Mode pipeline.
In this case, you need to set validateIntegratedModeConfiguration to false or run .aspx pages in
Classic Mode pipeline.

Conclusion

Even though Kerberos authentication entails some additional configuration steps and knowledge
beyond what NTLM requires, the trend is to move toward Kerberos. Microsoft is including it
checked by default in II7, and there’s great support for it in general because it is an open
standard. Using Kerberos is well worth the effort. There’s plenty of existing documentation for
deployment, verification, and troubleshooting, which strengthen the case for Kerberos. And you
don’t have to make extensive changes to reap the benefits of mitigating performance hits due to
excessive authentication hops, and to enjoy the security of Kerberos.

Pav Cherny is an IT expert and author specializing in Microsoft technologies for collaboration
and unified communication. His publications include white papers, product manuals, and books
with a focus on IT operations and system administration. Pav is President of Biblioso
Corporation, a company that specializes in managed documentation and localization services.

Related Content

• How the Kerberos Version 5 Authentication Protocol Works

• Inside SharePoint: Decentralizing Site Administration
• Inside SharePoint: Building Your SharePoint Infrastructure