SharePoint 2010 in Windows 2008 R2 and Kerberos

SP Configuration Wizard - Kerberos or NTLM?

There are two options when configuring SharePoint 2010 security in “classic mode” (as opposed to claims-based). You can use Basic (NTLM) or Negotiate (Kerberos). If you use NTLM, you may run into double-hop issues. This is why you will probably want to use Kerberos over NTLM (this assuming you’re not yet moving towards claims-based authentication).

So, you want to use Kerberos. During the configuration of SharePoint after installation,  in the Configuration Wizard, you will be asked to choose which security setting you want to use. If you choose Negotiate (Kerberos), and then click Next button on the wizard, you will get a prompt like the following:

SP Configuration Wizard - Kerberos or NTLM?

What this message tells you is that you or your domain administrators must configuration Security Principal Names or SPNs in Active Directory.

In case you’re wondering, here’s a summary of my SharePoint lab environment:

  • Windows 2008 Server R2 OS on all servers. AD is compatible with Windows Server 2003 features.
  • Microsoft SQL Server 2008 R2
  • SharePoint Server 2010

You can use use SetSPN tool to configure the SPNs for your SharePoint environment. Or, if you’re curious to see  what SPNs “look like” in Active Directory, you can use ADSIEdit. If you use ADSIEdit, login to the domain controller or use a server that has the Active Directory tools installed in it. When you open up ADSIEdit, expand the CN=Users tree and look for the domain account you want to setup SPNs for. The domain account that you want to setup SPNs for is typically the identity of the SharePoint Web site application pool. In the example below, I was adding SPNs to the “SP Web App Pool” account, which will be the service account used by the SharePoint Web site. Right-click the domain account in ADSIEdit and click Properties. In the Attribute Editor tab, look for servicePrincipalName.

ADISEdit - Add SPNs

Edit it and you can then add the SPNs for the domain account.  I have included a link in the Resources section on the bottom of this article to a Technet article that explains in full detail how to add SPNs in Active Directory.

In addition to adding SPNs to the service account, you must also enable delegation for the service account. Go to Active Directory and look for the service account. If you have setup SPNs for the domain account, you should see a Delegation tab on the user properties:

Service Account allowed for delegation

Check “Trust this user for delegation in specified services only”. And then select “Use any authentication protocol”. Finally, add the SPNs to the “Services to which the account can present delegated credentials” list. Links on the resources list will show you how to do this in full details.

In MOSS 2007, you have to setup SPNs for the service account and choose Kerberos as authentication mode and your SharePoint is good to go to use Kerberos. Setting up SPNs for SharePoint service accounts is nothing new. Well, in my lab environment, my SharePoint 2010 is running on Windows Server 2008 R2 with IIS7. The expected behaviour after adding SPNs was that the user (me) was prompted 3 times by the SharePoint site and only to render nothing after the 3 prompts for login. No matter how carefully I typed-in a domain account into the login prompt, I couldn’t get in!

Apparently, in IIS7, there are new settings that you have to configure in addition to setting up SPNs for the service account. You have to edit the applicationHost.config file in order to enable WindowsAuthentication. This IIS.NET article explains that IIS7 installs with windowsAuthentication disabled by default. But I have to give credit to Spence for his SharePoint article on how to enable Kerberos. Spence’s article was what actually got me moving in the right direction.

So I enabled windowsAuthentication (list of resources at the bottom of this article). When I tried to connect to the SharePoint site, I was being prompted to login!! Why?? So I typed-in domain account. On the first attempt, I was able to get into the SharePoint site.

It felt like challenge-response (NTLM) because I was prompted to login. I look at the Security Event Log of the SharePoint Web server. I see that the user logged-in using Kerberos!

Event 4624 in Security Event Log

Event 4624 showing it was Kerberos

So what now? Why was I still getting prompted to login? I forgot something–Internet Explorer security settings! I have to add the URL to my SharePoint 2010 portal in Intranet Zone sites. Also, you have to configure the “Custom Level” of the Intranet zone such that “Automatic logon onl in Intranet zone” is selected:

Internet Explorer Security Settings for Intranet Zone

If the SharePoint site is not detected as an Intranet zone, you will notice in IE status bar:

SharePoint Portal - Internet Zone

If you have admin rights to the workstation, you can probably edit the list of sites in Intranet Zones in IE Security settings and enable automatic logon in Intranet sites Well, in my setup, the workstation–what a user can change and cannot change–is controlled by group policies.

I had to create a new group policy and link it to my domain (or you can edit the default group policy for the domain if it’s just a lab environment) When editing the GPO, the path to add SharePoint sites to Intranet Zone is:

Computer Configuration>Administrative Templates>Windows Components>Internet Explorer>Internet Control Panel>Security Page>Site to Zone Assignment List

IE Site to Zone Assignment List in GPO

When you edit the Site to Zone Assignment list, you’ll be presented a dialog box. You can add the sites (typically just make it “http//*.yourFQDN” so that all sites in your lab environment are detected as Intranet sites):

Enter zone assignments in GPO

After editing GPO, propagate the new policy by restarting the workstation. After the workstation restarts, I hit the SharePoint site again and no more login prompts!! Also, notice on the status bar that the SharePoint site is detected as an Intranet site:

Portal Intranet Zone

Hopefully, this article demonstrated to you how to configure Kerberos for SharePoint 2010. Yes, claims-based authentication is supposed to be the “preferred” mode these days in SharePoint but plenty of organizations out there will stick with Kerberos (Windows integrated security) for a little while. If anything, this article serve as a jump point to other great articles out there on how to accomplish Kerberos in SharePoint. List of links below.

Resources:

1 Comment

  1. Nice job!

    Ran in to some problem when configuring kerberos for sharepoint 2013, in the end it was just me mixing up “trusted sites” and intranet så when i was in intranet zone it worked 🙂

1 Trackback / Pingback

  1. Security Event 540 doesn’t exist in Windows Server 2008 R2 — Gabe Hilado's SharePoint & ASP.NET Blog

Leave a Reply

Your email address will not be published.


*