SharePoint 2010 supports two authentication mode: Classic mode and Claims based. Today I’m going to explain how to configure Kerberos authentication for an web application with classic mode Authentication. I’ll try to explain how to configure Kerberos for an web application with Claims based authentication later.
Step 1: Create/Configure Web Application
In this step you need to create an web application with required configurations. However, you can convert an existing web application to use Kerberos authentication if the web application app pool user is a domain user. But as mentioned already, the configuration explained in this post applies for an web application with Classic Mode Authentication.
Create a new web application
In creating new web application for using Kerberos Authentication you need to consider the following options:
- Use classic mode Authentication as shown below (You can use Claims Based Authentication but then the steps described in this post might not work. For Claims Based Authentication you need different sets of configuration):
Figure 1: Create site with ‘Classic Mode Authentication’
- Use Negotiate (Kerberos) as Authentication Provider in ‘Create Web Application’ page as shown below:
Figure 2: Create site with Negotiate (Kerberos) Authentication provider selected.
- Use domain username for app-pool account. Don’t use Predefined (like Network Service, Local System etc) user account. This is important to use domain user name as you will configure Kerberos against this app-pool username.
Figure 3: User domain user name for App-pool account.
- One recommendation. Make the site url to be Fully Qualified Domain Name. For example, my server name was sohel-server and domain name was sohel.com. I’ve modified my full site name from default http://sohel-server:5000 to http://sohel-server.sohel.com:5000. This will help you identifying if the Only Kerberos is used for authentication instead of NTLM.
Configure an existing web application
If you have an existing web application that you want to move to Kerberos from NTLM you need to make sure your site meets the following criterion:
- The web application uses a domain user in application pool account instead of predefined account like Network Service, Local System. If your web application doesn’t use domain user then you can create a new web application with domain user name as application pool account. Changing the application pool account might make your web application malfunctioning.
- If you existing web application uses Classic Mode Authentication then configuration in this post should work. However, if you are using Claims based Authentication then you need to configure Security Token Service (STS) which in not mentioned in this post. If you are using Classic Mode, then you can continue this post as this post describes Kerberos for an web application with Classic Mode Authentication.
If you meet the above mentioned criterion, then you can change the authentication of the site to Kerberos. To change the Authentication Provider to Kerberos, navigate to Central Admin site then click “Application Management” => Manage Web Applications => Select your web application => Click Authentication Provider from ribbon button as shown below:
Figure 4: Change Authentication Provider
In the Authentication provider windows click on the zone you want to configure the Kerberos Authentication. Then you will be shown ‘Edit Authentication’ window. If your web application is using NTLM you can change the Authentication to Kerberos as shown below:
Figure 5: Change NTLM to Kerberos
When you change the authentication type from NTLM to Kerberos you will be prompted with message saying “” as shown below. You don’t need to worry, we’ll configure other settings to use Kerberos. So just click ok button when the message appears and then save the settings.
Figure 6: Warning appears during Authentication changes from NTLM to Kerberos
Step 2: Configure Service Principal Name (SPN) in Active Directory
So your web application is configured for Kerberos Authentication but you need to configure Service Principal Name (SPN). Simply SPN is an unique identifier for each service (HTTP, SQL, AD etc) running in the server. An SPN is a combination of service name, host name and port name. The original format for SPN is
<Service Name>/<DNS Host>:Port
- HTTP/<DNS Host Name>:Port
- HTTP/<DNS FQDN>:Port
In my case the SPN are:
- HTTP/sohel-server:5000
- HTTP/sohel-server.sohel.com/5000
However, if you are using any port other than 80, you need to add four SPNs (two for 80 port and two for your non-80 web application port). Whether you use Kerberos for 80 port, you need to add SPNs for default port. So though I’m configuring Kerberos for HTTP port 5000, I need to configure Kerberos for 80 port also. The following SPNs are need to configured for my example.
- HTTP/sohel-server
- HTTP/sohel-server.sohel.com
- HTTP/sohel-server:5000
- HTTP/sohel-server.sohel.com:5000
How to set SPN?
- Make sure you installed ‘Active Directory Lightweight Directory Services’ from Server Role to get the ADSI Edit UI for editing SPN values. You can add the ‘Active Directory Lightweight Directory Services’ from Server Manager => Add Roles as shown below:
Figure 7: Install ‘Active Directory Lightweight Directory Services’ from ‘Add Server Role’
- To setup SPN, Run the command “adsiedit.msc” in either command prompt or from Run. You will get the ADSI Edit window.
- In ADSI Edit window, expand the ‘Default naming context’ and expand CN=Users and find the user you used for application pool in web application.
- Right click on the user entry CN=UserName and select properties window. Then find the property ‘servicePrincipalName’ and click edit as shown below:
Figure 8: Set SPN through servicePrincipalName
- Finally add the SPNs in the edit window as shown below:
Figure 9: Add SPN values as value of attribute ‘servicePrincipalName’.
- Press OK and then apply to close the dialog.
Step 3: Enable delegation
In some cases you may need to enable delegation of credentials. To enable delegation, open the Active Directory users and Computers from ‘Administrative Tools’ menu. Find the user used in Application pool under ‘Users’ node. Right click on the user and click Properties to get the properties window. Then in the properties window go to ‘Delegation’ tab and select ‘Trust this user for…’ as shown below:
Figure 10: Enable delegation
Step 4: Configure Internet Explorer
Finally you need to configure Internet Explorer (IE) to use current windows user to access the SharePoint site.
- Go to Tool => Internet Options. Then select ‘Local Intranet’ and click Sites as shown below:
Figure 11: Setup IE for adding the SharePoint site to local Intranet
- After ‘Local Intranet’ dialog select ‘Advanced’ and then you’ll find the way to add sites to local intranet. Add ‘*.yourdomain’ in the local intranet zone as shown below:
Figure 12: Adding my domain (sohel.com) to local intranet.
- Now close the Internet Options dialog. Then open the ‘Internet Options’ dialog from Tools => Internet Options. Then go to Security tab and select ‘Local Intranet’ and select ‘Custom Level’. Then At the end of the ‘Security settings’ window, select ‘Automatic login only in Intranet zone’ as shown below:
Figure 13: Enable automatic login for Intranet zone
Conclusion
Configuring Kerberos authentication may depends on many factors. So I can’t guarantee than each and every steps described here will work for everybody. But the overall sets of configurations are same. You need to configure SharePoint site, You need to configure SPN, You need to enable delegation (if required), you n need to configure Internet Explorer. You can get elaborate description of configuring Kerberos Authentication with SharePoint 2010 from the link:
http://www.microsoft.com/download/en/details.aspx?id=23176.