ObjectSharp Blogs

You are currently viewing

Max Yermakhanov's Blog

The adventures of an IT professional in the world of developers


Implementing Kerberos for SharePoint running on Windows Server 2008 and IIS7

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:

Comments

  • Pritish March 9, 2009 7:50 PM

    Hello, when I use the domain name in the setspn command, it returns this error "Failed to crack name wss_srvc_account@DOMAIN into the FQDN. DS_NAME_RESULT items: 1 DS_NAME_ERROR_DOMAIN_ONLY Error (0xff688b80):

    e.g.

    ">setspn -A http/WSSSERVER1 DOMAIN\WSS_SRVC_ACCOUNT"

    however when I drop the domain preface to the account name, the setspn output is

    "Registering ServicePrincipalNames for CN=WSS_SRVC_ACCOUNT, OU=Service Accounts, OU=ABC Resources, DC=DOMAIN, DC=com

        http/WSSSERVER1

    Updated Object"

    .. which is a little scarier than the previous output. Any idea why this is occurring? (ps - i used caps and your substituted names for the hostname, account name, etc.)

  • Pritish March 10, 2009 12:27 PM

    Max - suggesting a couple things to disambiguate the application.config section and xml file to edit:

    1. e.g. \windows\system32\inetsrv\config\applicationhost.config

    2. there are many sections that you'll find similar text to the aforementioned security section.  perhaps give a full xpath query to the path you are recommending admins to edit; e.g. system.webServer/security/authentication/WindowsAuthentication is pretty close (I think there is a hyphen typo in your posting of the path)

Leave a Comment

(required) 
(optional)
(required) 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS