Implementing Kerberos for SharePoint running on Windows Server 2008 and IIS7

0Comments

Before I start writing how to set up Kerberos authentication in SharePoint, let me explain our set up a little bit, i.e. server names, account names and so on that will be used in this guide:

WSSSERVER1 – SharePoint web front server

WSSSERVER2 – another web front server (optional)

DBSERVER1 – database server running Microsoft SQL Server 2005 SP2

Domain\wss_srvc_account – User account used to run SharePoint services

Domain\sql_srvc_account – User account used to run SQL services on database server

Domain\wss_apppool – User account used to run SharePoint web application pool

Domain\mysite_apppool – User account used to run My Site web application pool

Domain\sspadmin_apppool – User account used to run Shared Services Provider web application pool

 

To set up a Kerberos authentication in SharePoint (WSS or MOSS) you need to do a bunch of small configuration changes:

  1. Make sure that you have host headers set up for your SharePoint sites. For example, in case of Windows SharePoint Services you will have only the main SharePoint website, whereas in case of Microsoft Office SharePoint Server 2007 you will have main SharePoint website, My Site website, and Shared Services Provider Sites. For the sake of simplicity, let's call those host headers: http://sharepoint, http://mysite, http://sspadmin respectively.
  2. Update Alternate Access Mappings to point websites to website host headers. In other words, replace http://servername:2222 entry with http://sharepoint

     

  3. Add SPN records for:
    1. Hostnames and FQDN of computer account(s) of your SharePoint server(s), for example
      Setspn.exe -A HTTP/WSSSERVER1 DOMAIN\wss_ srvc_account
      Setspn.exe -A HTTP/WSSSERVER1.domain.local DOMAIN\wss_srvc_account
      Setspn.exe -A HTTP/WSSSERVER2 DOMAIN\wss_ srvc_account
      Setspn.exe -A HTTP/WSSSERVER2.domain.local DOMAIN\wss_srvc_account
    2. Hostnames and FQDN of computer account of your SQL server, for example
      Setspn.exe -A MSSQLSvc /DBSERVER1:1433 DOMAIN\sql_srvc_account
      Setspn.exe -A MSSQLSvc /DBSERVER1.domain.local:1433 DOMAIN\ sql_srvc_account
    3. Host headers for your SharePoint websites, for example
      Setspn.exe -A HTTP/INTRANET DOMAIN\wss_apppool
      Setspn.exe -A HTTP/ INTRANET. domain.local DOMAIN\wss_apppool
      Setspn.exe -A HTTP/MYSITE DOMAIN\mysite_apppool       (Do not apply in case of WSS)
      Setspn.exe -A HTTP/MYSITE. domain.local DOMAIN\mysite_apppool       (Do not apply in case of WSS)
      Setspn.exe -A HTTP/SSPADMIN DOMAIN\sspadmin_apppool       (Do not apply in case of WSS)
      Setspn.exe -A HTTP/SSPADMIN. domain.local DOMAIN\sspadmin_apppool       (Do not apply in case of WSS)

       

    1. Configure "Trust for Delegation" on all computer accounts and user accounts used in SharePoint configuration. To configure "Trust for delegation":
      1. Open Active Directory Users and Computers management console
      2. Right click on a user or computer account that require ""Trust for Delegation" configured and click on Properties
      3. Where you find this option in the GUI depends on the Active Directory functional level. In case of Windows 2000 domain, the option is under Account tab for user accounts and General tab for computer accounts. In case of Windows 2003 domain, the option is under a separate Delegation tab. Note: Delegation tab is only visible for accounts that have SPNs registered

         

  4. Configure Component Services to allow Local Launch and Activation permissions for IIS WAMREG Admin Service for all application pool accounts used in SharePoint configuration. To configure Component Services setting go Control Panel >> Component Services >> Computers >> My Computer >> DCOM Config >> properties of the "IIS WAMReg Admin Service" >> Security tab >> edit "Launch and Activate Permissions" >> add "Local Launch" and "Local Activation" permissions for all the application pool accounts

     

  5. Because in IIS7 HTTP.sys is handling the authentication, it is by default done under the LocalSystem account regardless of the application pool account you're using. However, because even a single SharePoint server configuration is now considered a web farm, we should use a domain account to run SharePoint application pools. As a result we need to modify applicationhost.config file to configure the useAppPoolCredentials attribute in system.webServer/security/authentication/Windows-Authentication configuration section to true.

    <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true"/>

     

     

  6. Once you have made a change to applicationhost.config file you might start getting errors 6398, 7076, 6482 in your Event Viewer. To get rid of those errors you need to apply hotfix KB946517. This hotfix is currently is available for Windows Server 2003, XP and Vista and it is under development for Windows Server 2008. I have used Vista version of the hotfix on Windows Server 2008 and it seems to have worked fine (knocking on wood...)

     

  7. Now you're ready to switch your SharePoint web applications to Kerberos authentication. Open SharePoint Central Administration >> Application Management >> Authentication Providers >> choose your web application >> change authentication to Negotiate (Kerberos)

     

     

  8. In case of MOSS, to change your Shared Services Provider web application to use Kerberos authentication run the command: stsadm.exe -o SetSharedWebServiceAuthn –negotiate. Stsadm.exe is usually placed under C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin.

 

 

That's it, you should now have your web applications using more secure Kerberos authentication. You can use Fiddler (http://www.fiddlertool.com/Fiddler2/version.asp) to verify that your web application is in fact using Kerberos authentication. Here are a few links that will help you might find useful:



Related resources:

By Max on August 1, 2008 at 9:16 AM
Tagged: , , , ,