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 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/ and HOST/. 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.
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/
Comments
Post a Comment