FOCUS AND CONTEXT

This article is focused on SharePoint 2013 but the same rules can be applied to SharePoint 2010 with some restrictions.

This is not a why or what is Kerberos article as that is well documented already in http://download.microsoft.com/download/B/B/F/BBF0C6F3-6E36-4979-8C43-DE165AD7AE34/SP2010%20Kerberos%20Guide.docx

The focus of this article is that you would like to configure Kerberos for all the BI functionality in SharePoint. It is a step by step checklist to ensure your Kerberos configuration is correct.
It also focuses on configuring as few items as possible so that you do not have to set 100's of Service principle names as that leads to lower security, duplication and misconfiguration.

I have highlighted in orange where I show examples of my account names and URL's which must be replaced by your account names and URL's

The highlights in blue are important points to note.

IF YOU WOULD LIKE A STEP BY STEP PRESENTATION THIS IS AVAILABLE ON CHANNEL9.MSDN.COM (http://channel9.msdn.com/Events/SharePoint-Conference/2014/SPC422)

SQL 2012 IMPACT

There are some fundamental changes in SQL 2012 that affect SharePoint and as such the Kerberos configuration requirements are simpler.

Reporting services has always been the caveat as it has never actually been managed by SharePoint.
With SQL 2012, Reporting services is now a Service Application in SharePoint and is therefore managed by SharePoint.
This means that it is load balanced by SharePoint, requires constrained delegation and as such does not have a separate Reporting Services Config file to update.

The new reporting Services mode is called SQL Reporting Services SharePoint Mode (previously known as Integrated Mode).

I will therefore detail the configuration using Constrained Delegation for all components as I do not see the point of using mixed delegation i.e. Constrained and Basic together as most BI components in SharePoint 2013 require Constrained.

NOTES

The details below make a few assumptions:

  1. Recommended Practices have been followed,
  2. All services have been configured with an AD Service Account
    Whilst services can run with Local system it is not a recommended practice and does complicate the Kerberos configuration
  3. All configuration requirements for Kerberos are configured on all SharePoint servers in the farm regardless of role.
  4. This configuration details configuring Kerberos for 1 web application in the Farm. If you need more then you will need to setup a URL for each.
  5. SharePoint services must not be updated in the services console – USE THE SHAREPOINT UI ONLY.

REQUIRED STEPS

  1. Identify all data sources i.e. where will you be getting your data from? (SQL, SQL Analysis Services, etc.)
    While this seems obvious, every customer I have ever been to fails to declare all sources
    You will need Server Name + Instance, Port (SQL only) and Service Account used that is physically running the service (If it is Local System then it is not configured correctly and must be changed to an AD Service Account) 
    e.g. SQL01\SP_Instance port 40000 Service Account svc_SQLService

  2. Create a friendly URL and register it in DNS e.g. BI.BLUE.COM (replace with your URL on your Domain).
    This should be registered in DNS as a Host A record (Not a CNAME) and the IP should be the Web Front End or if using a Load Balancer then your load Balancer IP.

  3. Configure Claims to Windows Token Service Account.

    Create an AD account to be used by the Claims to Windows Token Service Account e.g. SP_C2WTS
    Open a SharePoint PowerShell prompt as Administrator and run the following command:
    $w = Get-SPWebApplication -Identity http://bi.blue.com (Put the URL of your web application)
    $w.GrantAccessToProcessIdentity("blue\sp_c2wts") (Put your service account name)

    1. Change the account in the SharePoint UI running the Claims to Windows token Service
      1. Navigate to Security in Central Admin,
      2. Click on managed Accounts and add the new C2WTS account as a Managed Account,
      3. Click Security again and Click on Service Accounts,
      4. Click the Drop Down and Select Claims to Windows Token Service,
      5. Select the new Managed Account SP_C2WTS and click OK. (Wait a few minutes for it to complete)
      6. Set the following permissions on all SharePoint servers in the farm (All must be done) – this is completed under Local Security Policy on each server

        1. Grant Log on as a service (this should have happened automatically)
        2. Impersonate a User (this should have happened automatically)
        3. Act as part of the operating system (If its greyed out then your domain admin will need to update the group policy to allow it)

    2. Local admin on all SharePoint servers
    3. STOP and START the Claims to Windows Token Service (From SharePoint UI) on all servers in the Farm. Simply navigate to Services in Farm and select each server from the link in the top right corner and Stop and Start each one individually waiting for them to finish

  4. Grant permission for the account running the application pool for the Service Application

    e.g. Excel Services Service Application, Reporting Services Service Application, etc.
    1. For Analysis services this User must be Granted SQL Analysis Services Administrator access (Unfortunately this is required as Read permission is insufficient for the delegation of credentials)
    2. Check which account is being used by navigating to Central Admin Security and then select Service Accounts and from the drop down list validate each service or application pool.
    3. In my example I have an account SP_Services and that account is granted Admin permissions on Analysis Services and granted “SP_DataAccess” on SQL to the SharePoint web application content database(s).
    4. Validate that the account has the following permissions on each SharePoint server
      (This should be completed automatically but should be validated under the Local Security Policy)
      1. Grant Log on as a service
      2. Impersonate a User
    5. Grant process identity access to the Service account
      $w = Get-SPWebApplication -Identity http://bi.blue.com (Put the URL of your web application)
      $w.GrantAccessToProcessIdentity("blue\sp_Services") (Put your service account name)

  5. If using PowerPivot – Setup the PowerPivot account
    Change the account running the PowerPivot browser service to use an AD Account
    (This is completed through the SQL Server Configuration manager) and restart the service (This will take a few minutes and it will not be accessible during this time).

  6. Check for existing Service Principal Name
    (check each account prior to configuring as some may already exist and duplicates / misconfiguration break Kerberos)
    This also impacts SQL connectivity as misconfiguration of Kerberos will throw invalid SSPI context errors in SQL as SQL will automatically use Kerberos if SPN’s are registered. It also self-registers the SPN’s if Local System is used.
    SPN’s have to be set for the NetBIOS (Short name) and FQDN (Fully qualified name)
    e.g. SETSPN –S HTTP/bi.blue.com blue\sp_webappSETSPN –S HTTP/bi blue\sp_webapp

  7. Configure SPN's
    1. CONFIGURE SPN'S (SHAREPOINT SQL SERVER)
      Details required: SQL Instance name, Static Port and SQL Service account
      e.g. My SQL instance is SQL01\SQL2012 and my service account is SP_SQL and my port is 40000 (Replace the red with your server and account details).
      The 1st one is on my instance name
      setspn -s MSSQLSvc/SQL01:SQL2012 SP_SQL
      setspn -s MSSQLSvc/SQL01.blue.com:SQL2012 SP_SQL

      and the 2nd one is on port
      setspn -s MSSQLSvc/SQL01:40000 SP_SQL
      setspn -s MSSQLSvc/SQL01.blue.com:40000 SP_SQL

    2. CONFIGURE SPN'S (SQL Analysis Services Multidimensional) (Server name and Instance required)
      e.g. SQLAS01\Multi
      setspn -s MSOLAPSvc.3/SQLAS01:MULTI SQL_AS
      setspn -s MSOLAPSvc.3/SQLAS01.blue.com:MULTI SQL_AS
      setspn -s MSOLAPDisco.3/SQLAS01 SQL_AS
      setspn -s MSOLAPDisco.3/SQLAS01.blue.com SQL_AS

    3. CONFIGURE SPN'S (SQL Analysis Services Tabular)
      (Server name and Instance required)
      e.g. SQLAS01\Tabular
      setspn -s MSOLAPSvc.3/SQLAS01:Tabular SQL_AS
      setspn -s MSOLAPSvc.3/SQLAS01.blue.com:Tabular SQL_AS

    4. CONFIGURE SPN'S (SQL Analysis Services PowerPivot)
      (Server name and Instance required - POWERPIVOT)
      e.g. APP01\POWERPIVOT
      setspn -s MSOLAPSvc.3/APP01:POWERPIVOT SQL_AS
      setspn -s MSOLAPSvc.3/APP01.blue.com:POWERPIVOT SQL_AS
      setspn -s MSOLAPDisco.3/APP01 SQL_AS
      setspn -s MSOLAPDisco.3/APP01.blue.com SQL_AS

    5. CONFIGURE SPN'S (SQL Server - DataWarehouse)
      (Server name, Instance and Port is required)
      e.g. SQLAS01\SQL_SQLDW and my port is 41000
      setspn -s MSSQLSvc/SQLAS01:SQLDW SQL_SQLDW
      setspn -s MSSQLSvc/SQLAS01.blue.com:SQLDW SQL_SQLDW
      setspn -s MSSQLSvc/SQLAS01:41000 SQL_SQLDW
      setspn -s MSSQLSvc/SQLAS01.blue.com:41000 SQL_SQLDW

    6. HOST HEADER / AAM
      This is the same DNS entry you already configured)
      e.g. http://bi.blue.com and my account is sp_webapp (This is the account that is running the application pool in IIS that requires Kerberos)
      setspn -s HTTP/bi.blue.com sp_webapp
      setspn -s HTTP/bi sp_webapp

    7. FAKE SPN
      (These are the accounts configured to run the Service Application app pools and the Claims to Windows Token Service)
      FAKE SPN’s are used just to enable the delegation tab in Active Directory. (It doesn't matter what you use for the service name here - only the accounts matter)
      e.g. sp_services and sp_c2wts
      setspn -s SP/EXCEL sp_services
      setspn -s SP/C2WTS sp_c2wts

  8. Set Constrained Delegation
    (Constrained delegation must be set for any account running the Service Application pools for the services that require Kerberos as well as the Claims to Windows Token Service account and the Account running PowerPivot SQL Service)
    In my case this is SP_Services and SP_C2WTS and SQL_AS (only for PowerPivot Data Sources - this is a change with Excel 2013 as the connection refreshes with the worksheet)
    The Domain Admin is required here and must log in to a Domain Controller.
    1. Find the SP_Services(Replace with your account name) account and click on the Delegation tab
      1. Click on “Trust this user for delegation to specified services only”
      2. Use any authentication protocol
      3. This is where it can get confusing and you need to make sure you have all your service accounts ready that you setup previously.
        (These are the ones you ran SETSPN for)
      4. Start with your first Data Source and type in your service account name (NOT SERVER NAMES) e.g. SP_SQL , SQL_AS, SQLDW_SQL and click OK.
      5. You will then be prompted with all the SPN’s and you need to select only the ones you need here i.e. the ones that are noted above.
      6. The worst case scenario here is if the account you use is utilized for many services and you will see many SPN's.
      7. Select the required SPN’s (The ones you added above) and click ok.
      8. Click “Apply” button after each add i.e. when you want to select another account otherwise you will get an error.
      9. Repeat this process selecting each account that you need to delegate to i.e. all the data sources and the web application. It’s all about where you want to allow it to delegate to.
      10. Now select the Claims to Windows Token Service Account e.g. SP_C2WTS (Replace with your account) and repeat the exact steps you did for the SP_Services account. (Technically for the SP_C2WTS you can exclude the Web Application but for simplicity sake I made the process the same)

      11. For my PowerPivot Service account SQL_AS I was connecting to a SQL Data Warehouse and my Analysis Services so you only set constrained for the destination data source so in my case I looked up SQL_SQLDW and "selected all", clicked ok and applied constrained delegation.

  9. Change Web Application to Kerberos
  1. Navigate to Central Admin,
  2. Select web applications,
  3. Highlight the Web application (Do not click on the link – click next to it to highlight it and select it),
  4. Select Authentication providers and click Windows,
  5. Scroll down and change NTLM and select Kerberos
  6. Open a Command Prompt as Administrator and run IISRESET (USERS WILL LOSE CONNECTIVITY AND THEIR CURRENT SESSIONS SO DO THIS DURING SCHEDULED DOWNTIME)

DUPLICATE SPN CHECK SIDE NOTE
I have attached a duplicate SPN check script that also assists in listing what you have set against each account.
It will list the Constrained delegation, delegation and duplicate SPN's (If duplicates are detected this means that the service in question will fail to generate a Kerberos context).

  1. Unzip the attached dhcheck.zip file to dhcheck.vbs (Please note that although this does a READONLY call I cannot take responsibility for it's execution)
  2. Provide the file to your AD Admin
  3. They must open an Administrative Command Prompt and execute the command as follows "CScript dhcheck.vbs accountname" (Replace with your Account you want to check)