In the past few months a lot has happened to ensure kerberos is seen as viable and easier to support and troubleshoot.  I run into many consultants who it's the first thing they do in a deployment is make sure it's running Kerberos.  In a nutshell I see three reasons to use Kerberos, but there may be more.

Delegation a major component to user experience ensure that KPIs, Web Parts with backend data such as RSS, XML, or any basic remote viewers connecting to remote content or data sources will work as expected.  Essentially a pass through that provides the necessary authentication to retrieve the data based on the user credentials in the form of a ticket.

Security is what you'll find across the TechNet content as the reason to use Kerberos.  Since it requires both sets of keys it is a much more difficult authentication to fake and lasts a short enough period of time that by the time someone were to figure out how to fake the ticket, it would be way too late to use it.  Compromising the client or compromising the server does not give you all you need.

Performance is the other common thing you'll hear around Kerberos.  Since Kerberos supports a ticketing system you avoid a TON of round trips for long session lengths or where pages have lots of small payload such as hundreds or thousands of tiny images for example.  Each get that is requested in NTLM requires round trips to the DC for authentication while Kerberos would verify the user and server keys and then the session could continue with that common ticket.  Basic authentication, a very old and yet still common authentication mechanism used for cross browser is still the most common on the internet.  It is faster than both, but is not sure since first the transport is clear text so that's why it should only be used with SSL, but also the hash is stored on the client, so a compromised client could compromise the session.

I convinced Steve Peshka that this was a compelling enough scenario that we should test it to see what the performance gain might be against Kerberos.  Before I do this, let me give you the apples to apples comparison.  First the header in the Kerberos packet is a lot larger than the NTLM packet, so a short session would be faster with NTLM.  If it’s a long session with lots of resources on the page with tons of round trips and remote or slow DC, Kerberos will be a lot faster. 

Here are the results from our test which we hope to include in future performance paper.

Authentication Differences

The goal of this test was to compare the differences in throughput when using NTLM authentication versus Kerberos.  It was originally envisioned to include forms-based authentication using the SQL Membership provider that ships with ASP.NET 2.0.  Unfortunately, because of the nature of the way in which forms authentication works it wasn’t possible to come up with a like comparison based on RPS.

The farm configuration for this test consisted of two x64 Web servers with 4GB of RAM and one x64 index server with 8GB of RAM; there were also three domain controllers in the farm.  Here are the results from the test:

Steve’s Note: There is a performance gain, but only a slight one, when using Kerberos authentication. If your organization is already configured to use Kerberos authentication then it would be advantageous to use it for SharePoint.  There may also be other security-related benefits from using Kerberos that offer additional value besides the nominal performance gains.

Joel’s Note: Looking again at this test I can see how this could easily be invalidated by any real world customer environment.  This test environment had dedicated DCs, something any real environment likely won’t have.  Also, the domain controller will likely be right next to the WFEs and the ratio between the WFEs and DCs will be very high.  So I dismiss it.  It is interesting to note that this measurement is extremely environment sensitive, but why I’d do Kerberos from a performance perspective would be to reduce my dependency on domain controller traffic.  I don’t want to have to think about the network link to the domain controller and who else might be using it.  I still hold out that there’s likely a 30% performance gain by simply removing the slow poke domain controller that’s likely already overloaded and CPU burdened and the network isn’t going to be as dedicated and clear as you’d want.

New and Updated Top Kerberos Resources

There are now several good resources to Kerberos.  This one which previously existed has recently been updated with more recent understanding of how indexing and Kerberos work together and are supported: Configure Kerberos authentication (Office SharePoint Server).  A new article that was recently added drills more specifically into that topic: Prepare to crawl sites that use Kerberos authentication.  

For an in-depth explanation of how Kerberos works read Keith Brown’s “Programming Windows Security”. (Book on Amazon)

Also, a great blog by James world covering Guide to Kerberos in SharePoint 

Martin Kearn - Configuring Kerberos for SharePoint (not a bad read!)  Part II is worthy as well for Excel Services and SQL Analysis Services.I also recommend referring to the KB on switching between NTLM and Kerberos authentication methods in IIS for WSS: http://support.microsoft.com/kb/832769

In a recent conversation with Tom Wisnowski Sr. Consultant in MCS, I found out he had put together his thoughts and discovery on the topic and was going to be publishing this to ICE (intellectual capital exchange) an internal SharePoint powered portal focused on sharing IP.  After reviewing the doc, I found a lot of value in it and he supported me sharing it with you.  Below are the main sections from his paper.

SharePoint And Kerberos 2007

Why Use Kerberos

 Before diving into the details of how Kerberos works, and how one configures SharePoint (or any web application) to use it, let’s take a quick moment to talk about Kerberos in general and why you might want to use it.

Typically there are two main reasons to use Kerberos:

·         Delegation of client credentials. Kerberos allows a client’s identity to be impersonated by a service to allow the impersonating service to “pass” that identity to other network services on the client’s behalf. NTLM does not allow this delegation (aka “the single hop rule”). This is important in SharePoint when you want to pass the clients credentials to backend applications integrated with SharePoint, for instance SQL reporting services.

·         Better performance. Kerberos requires less traffic to the domain controllers in comparison to NTLM. Once a client gets a service ticket for a service from the Key Distribution Center (KDC -Domain controller on a windows network) it can reuse that ticket to authenticate with the service without having to go back to the domain controller for a new ticket. NTLM requires trips to the DC on every authentication request. This problem is exacerbated in NTLM when multiple domain trusts have to be crossed to authenticate a client.

Keep in mind this is not an exhaustive list of the advantages of using Kerberos. There are other reasons like better security, mutual authentication, cross platform interoperability, and transitive cross domain trust to name a few. However, in most cases one typically finds delegation and performance to be the primary drivers in adoption of Kerberos.

In short, Kerberos is a ticket based authentication system. The idea is that a client can prove its identity to a specific service by presenting that service a special “service ticket” which contains a session key that can be used to both prove the identity of the client and to sign or encrypt the traffic between the server and client. Before getting into the guts of how Kerberos works, there are a few things everyone must know:

·         Kerberos never passes the client’s (or server’s) credentials on the wire. The tickets used in the authentication process do not contain any usable credentials. Client and service names are in the tickets but are not of any use without the master keys (passwords hashes) belonging to those resources

·         All principals in a Kerberos Realm have master keys. Master keys are derived from the principal’s password and are not the password itself.

·         Service tickets the client receives from the KDC are mainly unreadable by the client because they are encrypted using the service’s master key, not the client’s master key.

·         Client’s request service tickets for a given service by identifying the service using a service principal name (SPN)

·         Service principal names are not URLs. They may look like URLs, and Internet Explorer may use the URL to build a SPN, but in reality SPN’s are not URLs. SPNs follow a specific schema: 

{service class}/{host}{:port}  {realm\svc identity}

 The port part is optional. Examples:

1.       MSSqlSvc/sqlmachine.contoso.com:1433

2.       http/intranet.contoso.com

A service principal name must only be registered to ONE service account. This is extremely important and contradicts many articles on configuring Kerberos. Here’s an example of what not to configure:

SETSPN –A http/www.contoso.com contoso\account1

SETSPN –A http/www.contoso.com contoso\account2  <- very bad, this registers the SPN (http/www.contoso.com) under a second service account

o    In fact, in Windows Server 2008, SETSPN now has a new command (setspn  -s) to check for duplicate SPN’s before registering a SPN. Kudos to the developers who added that must have feature!

·         Delegation is not required but optional. Kerberos “enables” delegation but does not require it to function. You only need delegation when one Kerberos enabled service needs to pass the identity of client to another Kerberos enabled service on behalf of the client.

·         There are currently two major issues with Kerberos on Windows that require either special “workaround” configuration or Hotfixes (see Appendix A and B)

o   Services endpoint resolution using DNS CNAME instead of A records – There is a known issue where clients will build a SPN using the host name returned by a DNS query regardless of the existence of a CNAME. 

o   Services that use non standard (80 & 443) ports – There is a known defect where clients will construct SPNs without port numbers. 

·                It good practice to register both the short and FQDN of the URL when registering the associated SPN. Even if you don’t plan on using one or the other, its good practice to have both (e.g. http/intranet and http/intranet.contoso.com)

·                The SharePoint crawler CAN crawl Kerberos enabled sites.  However, this requires the CNAME and potentially the non default port workarounds (See Appendix A and B)

·                The SharePoint SSP Web Services CAN be configured to use Kerberos. Again, this requires the CNAME and non default port workarounds plus it requires that the services are ran on server with no other Kerberos enabled, non-default port web applications (that are not using host headers).

·                Watch out for SETSPN pitfalls. It’s really easy to typo a SPN in the SETSPN tool. Further, if the service account being registered has the same name as a computer object, SETSPN will register the SPN with the computer object, not the correct service account. Always check SPNs are set correctly using ADSI edit when in doubt.  

Let’s walk through the steps of authenticating with a Kerberos enabled service. In this example the environment is made of:

a)      Alice and her workstation – this workstation is joined to the domain “contoso.com” and Alice has a user account “contoso\alice” in the contoso domain

b)      Websvr1 – this is a Windows server running IIS in the contoso domain. The web server is running the SharePoint Web Front End role.

c)       Intranet IIS Application Pool –This is the IIS app pool that is running the intranet portal web application  It has the following configuration:

a.       The application pool identity is “contoso\bob”

b.      The intranet portal IIS web site runs on port 80

c.       The IIS web site has 2 host headers:

                                                               i.      Intranet

                                                             ii.      intranet.contoso.com

d.       Within SharePoint, the SharePoint web application has 2 public URLs (Alternate Access Mappings)

                                                               i.      Intranet Zone: http://intranet

                                                             ii.      Custom Zone: http://intranet.contoso.com

d)      Contoso.com Domain Controller – This is the server running the Active Directory service for contoso.com. In the windows environment, the AD also serves as the Kerberos Key Distribution Center (KDC). The KDC runs two primary services, the Authentication Service (AS) and the Ticket Granting Service (TGS).  The Active directory maintains accounts for both contoso\alice and contoso\bob. Contso\bob has 2 service principal names (SPN) associated to it:

a.       http/intranet

b.      http/intranet.contoso.com

Now we will walk through the steps Alice will go thru to authenticate with the contoso intranet SharePoint site using Internet Explorer:

1)      Alice logs into here workstation and sends a KRB_TGT_REQ  to the KDC-  Her workstation requests a ticket granting ticket (TGT) from the authentication service (AS). Note that the authentication service does not have to actually authenticate Alice (no credentials are sent on the wire). In the request, Alice includes a special number called a nonce (“number used once”) to be used later to authenticate the KDC’s response.

2)      Alice receives a KRB_TGT_REP from the KDC - She gets a special ticket called a “ticket granting ticket” (TGT) from the authentication service which is encrypted with ticket granting ticket service’s master key so only the TGS can decrypt it. With the ticket she gets additional information encrypted with Alice’s master key (account password hash). The additional information consists of multiple fields but two fields are critical:

a.       The nonce - this is the number sent with the request in step 1. If Alice can successfully decrypt the addition info using her master key and the nonce she receives matches the nonce she sent, she can be sure the KRB_TGT_REP actually came from the trusted domain controller because only Alice and the Domain controller (authentication authority) know her master key.

b.      The session key - to use for future communication with the TGS. 

3)      Alice uses internet explorer to navigate to http://intranet - Her internet explorer security settings are configured to trust http://intranet as an intranet site and the intranet zone is configured to automatically logon in the intranet zone. Note that if Alice browses to http://intranet.contoso.com Internet Explorer’s default behavior is to put this site in the Internet zone which is not configured by default to logon with the current user’s credentials. Kerberos is still going to work in this scenario, but Alice will be prompted for her credentials. If Alice wants to use http://intranet .contoso.com without be prompted for username and password, she can

a.       Add http://intranet.contoso.com to her intranet sites

b.      Add http://intranet.contoso.com to her trusted sites and change the security settings of trusted sites to automatically logon using the current user name and password *

c.       Change the security settings of the internet zone to automatically logon using the current username and password *

* These options are not recommended as they are more likely to inadvertently reveal information about client to sites outside of the intranet. 

4)      IIS denies Alice’s request and returns HTTP 401.2 – Internet Explorer does not automatically send the user’s credentials with a request until the server requests authentication. Since Alice’s first request was sent without credentials IIS denies the request and returns a 401.2. IIS negotiates the authentication protocol with Internet Explorer by adding a WWWAuthenticate header in the response. If the web site is configured for both Kerberos and NTLM, IIS will return 2 WWWAuthenticate headers (Negotiate, NTLM).

5)      IE send a KERB_TGS_REQ to the KDC – IE attempts to authenticate with the web site (http://intranet) by requesting a service ticket for the service running that web site. Services in Kerberos are identified by their Service Principal Name (SPN) and every service ticket request must contain a SPN. IE will include the following in the request

a.       Ticket Granting Ticket – received in step 2. Remember this ticket was encrypted with the TGS’s master key so Alice cannot tamper with it. In the ticket will be both the session key given to Alice in step 2 and the client name (alice@contoso.com)

b.      Authenticator – Alice’s client name (alice@contoso.com ) and the current timestamp.

c.       Service Principal Name - the service that Alice is requesting a Kerberos ticket for (e.g. http/intranet.contoso.com).

d.       A nonce  - used to authenticate the response  

Everything except the TGT is encrypted using the session key Alice was sent in step 2. When the KDC’s TGS receives the request, it will decrypt the ticket granting ticket and use the session key inside the TGT to decrypt the rest of the request. If the client name in the TGT matches the client name in the authenticator and the timestamp is within a reasonable range (5 minutes) the TGS can be assured the request is coming from Alice because only Alice knows the session key (from step 2).

6)      Alice receives a KERB_TGS_REP – the response from the TGS will contain the service ticket for the http/intranet.contoso.com service and will be encrypted using the service’s master key, which is the master key of the identity the services is running as (i.e. contoso\bob). This is why you have to register SPNs in Active Directory, so the TGS knows what domain account to use when encrypting the service ticket. This is also why registering the same SPN with multiple accounts is a very bad thing; if the TGS cannot resolve a single domain account given an SPN, which one should it use to encrypt service tickets for that SPN? 

The rest of the response is encrypted with the session key discovered in step 2. It contains:

a.       The session key to use when communicating to http/intranet.contoso.com

b.      The nonce sent with the request – this validates the response. Only the TGS knows the session key (because it was sent in the ticket encrypted with the TGS’s mater key) so if the nonces match the message must have come from the TGS.

7)      Alice resubmit’s the web request (http://intranet) with the KERB_AP_REQ message – the Kerberos application request is “piggy-backed” on the web request in the “authorization” header sent with the http request. The application request contains the service ticket (encrypted with contoso\bob’s master key) along with an authenticator encrypted with the session key Alice received in step 6 (i.e. the KERB_TGS_REP).  Since Bob knows his master key, he is able to decrypt the service ticket, extract the session key and use it to decrypt the authenticator. If the client name in the authenticator matches the client name in the service ticket, and if the timestamp in the authenticator is within bounds the messages is validated and Alice is authenticated. Additional transmissions between Alice and Bob can now be either signed or encrypted using the session key exchanged in the request.

8)      The server returns the HTTP response - Standard web response. Optionally, the server can be authenticated by Alice if the server responds with a KERB_AP_REP message piggy-backed on the HTTP response

* note that the Kerberos request and response messages contain additional information not mentioned here for brevity

Configuring Kerberos for SharePoint

The following is a step by step explanation of how to configure a SharePoint farm to use Kerberos for authentication:

Environment Assumptions

·         The topology consists of 5 servers (SQL not included): 2 Web Front Ends, 2 Query Servers, and 1 index server

·         All servers are in a single domain “contoso.local”

·         The example has single web application called “intranet” (excluding the default MOSS web apps – CA, MySite, SSP, etc), with a single zone running on a default port (port 80)

·         IIS is configured to use host headers with the web applications running on default ports

·         Delegation is not required. A follow-up paper will discuss advanced topics like delegation.

·         The central administration and the Query/Index services are running on separate machines. If not, Kerberos cannot be configured for both services*

·         The load balancer passes the original host header back to the load balanced web front ends

*without either a hotfix, running on default ports, or running with the same service account. This is due to the non default port issue.

<Update 3/26 to add appendices>