Using Kerberos for SharePoint Authentication

[LEFT][B]Inside SharePoint[/B]

[B]Using Kerberos for SharePoint Authentication[/B]

[B]Pav Cherny[/B]


Although 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 [URL="http://technet.microsoft.com/library/cc262350.aspx"]sites with a high security service level agreement[/URL]. 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, [URL="http://support.microsoft.com/kb/832769"]KB 832769[/URL] 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 [URL="http://support.microsoft.com/kb/871179"]871179[/URL], [URL="http://support.microsoft.com/kb/962943"]962943[/URL], and [URL="http://support.microsoft.com/kb/832769"]832769[/URL] for some possible issues, which may be as severe as a stop error on a blue screen. Even existing documentation, such as the [URL="http://technet.microsoft.com/library/cc263449.aspx"]detailed guide for Kerberos implementation[/URL] 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 [URL="http://technet.microsoft.com/library/cc263449.aspx"]documentation with step-by-step details[/URL] and KB articles [URL="http://support.microsoft.com/kb/832769"]832769[/URL] and [URL="http://support.microsoft.com/kb/953130"]953130[/URL] that you can use for additional reference.
[B]Authentication Components and Dependencies[/B]

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 [B]Figure 1[/B]. 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 [B]Figure 1[/B].

[IMG]http://i.technet.microsoft.com/ee914605.Figure%201%28en-us,MSDN.10%29.png[/IMG]
Figure 1[B] Common Authentication Components and Data Flow in SharePoint[/B]
The following process details the data flow:

[LIST=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.[*]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.[*]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.[*]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.[*]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.[/LIST]
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 [URL="http://msdn.microsoft.com/library/aa480475.aspx?ppud=4"]Explained: Windows Authentication in ASP.NET 2.0[/URL].
[B]NTLM and Kerberos[/B]

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. [B]Figure 2[/B] shows how SharePoint handles requests when using NTLM.

[IMG]http://i.technet.microsoft.com/ee914605.Figure%202%28en-us,MSDN.10%29.png[/IMG]
Figure 2[B] NTLM Authentication in SharePoint[/B]
As [B]Figure 2[/B] 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:

[LIST=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.[*]IIS rejects the anonymous request with a 401.2 error and sends back a request to authenticate with NTLM (WWW-Authenticate: NTLM).[*]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.[*]IIS accepts the details and sends an NTLM challenge to the client.[*]The client responds with the response to the challenge (auth token again), encrypted with the password of the user.[*]At this point, IIS needs to talk to the domain controller. It sends the client’s user name, challenge, and challenge response.[*]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.[*]From here, the Web application authenticates with the SQL Server and can access the content database that contains the data for the .aspx page.[/LIST]
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. [B]Figure 3[/B] shows the various components involved and the data flow in Kerberos-based authentication in SharePoint.

[IMG]http://i.technet.microsoft.com/ee914605.Figure%203%28en-us,MSDN.10%29.png[/IMG]
Figure 3 [B]Kerberos Authentication[/B]

[LIST=1][*]As with NTLM, a client browser makes an HTTP GET request as anonymous using a host name (FQDN or alias).[*]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.[*]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.[*]If the KDC locates a matching SPN, it encrypts the ticket and returns it.[*]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.[*]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.[*]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.[*]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.[/LIST]


[B]Understanding SPNs[/B]

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 [B]Service-Principal-Name[/B]. 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 [I]service class/host: port.[/I] 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/[I]<NetBIOSname>[/I] and HOST/[I]<FQDN>[/I]. 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.
[B]Back-End Configuration[/B]

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/[I]<NetBIOS_Name>[/I]:1433 and MSSQLSvc//[I]<FQDN-hostname.domain.local>[/I]: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 [B]servicePrincipalName[/B] attribute directly. To create the two SPNs, run [B]setspn-A
[/B]
[CODE][B]MSSQLSvc/[I]<NetBIOS_Name>[/I]:1433 [I]<domain>[/I]\[I]<username>[/I][/B] and [B]setspn-A MSSQLSvc/[I]<FQDNe>[/I]:1433 [I]<domain>[/I]\[I]<username>[/I][/B][/CODE]

[B][/B], 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 [URL="http://technet.microsoft.com/library/cc263449.aspx#section3"]Configure Kerberos authentication for SQL communications[/URL].
[B]Front-End and Application Server Configuration[/B]

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. [B]Figure 4[/B] lists a sample of resource types and the SPNs that need to be registered for each one.

[IMG]http://i.technet.microsoft.com/ee914605.InsideSharePointTable%28en-us,MSDN.10%29.png[/IMG]
Figure 4 [B]SPNs for a Basic MOSS Farm[/B]

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 [URL="http://technet.microsoft.com/library/cc263449.aspx"]Configure Kerberos authentication (Office SharePoint Server)[/URL].
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 [URL="http://support.microsoft.com/kb/917409"]917409[/URL], and [URL="http://support.microsoft.com/kb/920783"]920783[/URL].
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 [B]iisreset /noforce[/B] to apply the changes to the application pools, and to enable Kerberos for SSPs[B].[/B]
[B]Changes in IIS 7 and Windows Server 2008[/B]

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
[CODE]
.
<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled="true" useKernelMode="true" [B]useAppPoolCredentials="true"[/B] />
</authentication>
</security>
</system.webServer>


[/CODE]
Don’t forget to run [B]iisreset /noforce[/B] to apply the changes and check for the latest updates for issues, such as the blue screen update detailed in KB [URL="http://support.microsoft.com/kb/962943"]962943[/URL].
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.
[B]Conclusion[/B]

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.

[B]Pav Cherny[/B] i[I]s 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.[/I]
[/LEFT]