Joshua Fennessy

Guidelines for troubleshooting Kerberos Delegation – SharePoint and MSBI

Whether running SharePoint 2010 or SharePoint 2013, Kerberos Delegation is an important part of delivering a fully functional BI solution. It’s also not a trivial task to configure correctly. There are many layers involved and the larger the SharePoint environment, the more complex it is.

The purpose of this post isn’t to explain how to configure delegation from the ground up, that topic has been covered very well with documents such as Configuring Kerberos Authentication for Microsoft SharePoint 2010 Products. This document, by the way, is still largely relevant for SharePoint 2013, although some of the SharePoint setting have changed, the foundational elements and Active Directory settings are the same.

clip_image002
What Kerberos often seems like

Rather, the purpose of this post is to help troubleshoot an existing environment where delegation is not working properly. This task can often feel like fighting the mythical monster namesake, a Kerberos.

Troubleshooting an established environment can be a mammoth task. I’ve worked through enough of them to know how to break it into manageable pieces, which most of the time, will lead to a configuration error that can be fixed and get the environment delegating identities as expected.

My goal is, by end of this post, to help explain how to identify the major pieces of configuration, determine which pieces are or are not working, and offer some common issues and solutions to get this up and running correctly. I’ve found that by following the three or four major steps below, the majority of environments with incorrect delegation configuration will be corrected.

Verify Delegation to Data Source – Example: SSAS

clip_image004

Using a domain connected client machine, create a new connection to the domain connected SSAS server in Excel. One the data base list is populated, log into the database server and check the Security Event Log for Event 4624. If Event does not specify Kerberos as Logon Process, delegation is not configured.

Common Causes

1. Incorrect Service Principal Name (SPN) registration

2. Service account not trusted for delegation

3. Computer account not trusted for delegation

Remedies

1. Using setspn.exe, verify currently registered SPN entries and adjust as needed for data source

2. Using an account with Domain Admin rights, adjust the delegation trust level for the service account to “Trust this user for delegation to any service” or “Trust this user for delegation to specified services only”

3. Using an account with Domain Admin rights, adjust the delegation trust level for the computer accounts to “Trust this user for delegation to any service” or “Trust this user for delegation to specified services only.” Note: this should be done for any computer accounts that fall in the path from client to middle tier to data source

Verify Delegation to Web Front End

If delegation to the data source is working – Event 4624 lists Kerberos as the Logon Process – then the next step is to verify that delegation to the SharePoint Web Front End is working properly. Very similar to the data source, this test should be done on a domain connected client machine.

Open IE and browse to the root site, http://spdemo, for example. Once the page loads, log into the SharePoint WFE server and again check for Event 4624 in the Security log. Just as before, if the Logon Process does not mention Kerberos, then delegation is not configured correctly. See below for common causes.

Common Causes

1. Root site not in client machine INTRANET zone.

2. Client machine not configured to use Integrated Windows Auth

3. Service account not trusted for delegation

4. Computer account not trusted for delegation

5. SPN registration incorrect for site collection

6. Site collection authentication provider setting incorrect

7. IIS configuration incorrect

Remedies

1. Verify root site is in INTRANET zone. Add if not.

2. Check Internet Options -> Advanced tab for “Use Integrated Windows Authentication”. Select if currently unselected (will require IE restart)

3. Using an account with Domain Admin rights, adjust the delegation trust level for the service account to “Trust this user for delegation to any service” or “Trust this user for delegation to specified services only”

4. Using an account with Domain Admin rights, adjust the delegation trust level for the computer accounts to “Trust this user for delegation to any service” or “Trust this user for delegation to specified services only.” Note: this should be done for any computer accounts that fall in the path from client to middle tier to data source

5. Use setspn.exe to verify registered SPN for AppPool service account. Correct as necessary.

6. In Central Administration verify the setting for the default Authentication Provider for the site collection. Ensure that the Integrated Windows Authentication option is set to “Negotiate (Kerberos)”

7. Ensure the Application Pool is configured correctly for Kerberos delegation. See Configuring Kerberos Authentication for Microsoft SharePoint 2010 Products for detailed IIS configuration settings

Verify Delegation of Service Application – Example: PerformancePoint Services

The final step to test is the service application itself. For example, testing PerformancePoint Services would mean creating a new data source with “Per User Identity” enabled. Tracing the database while creating this should show whether or not Kerberos delegation is working.

Common Causes:

1. Service account not trusted for delegation

2. Claims to Windows Token Service

Remedies:

1. If the application is running under a different service account that the WFE or databases, then it’s possible that it’s not being trusted for delegation like the others (set correctly above). However, the Delegation tab might not be visible in AD Users and Computers. In order to make it visible, create a bogus SPN. For example, the following SPN can be used for PerformancePoint Services

setspn.exe –s PPS/SPDEMO DEMO/svc_pps
setspn.exe –s PPS/SPDEMO.DEMO.LOCAL DEMO/svc_pps

Note: In this example, this SPN does not point to a real Service Principal, but it does enable the Delegation tab in AD Users and Computers to be able to check the Trust settings.

2. If the service account is already trusted, then there is one more big section to check IF Claims authentication is being used. Note that Claims authentication is available in both SP2012 and SP2013, but enabled by default in SP2013. The following steps do not apply if Basic Authentication is being used.

Verify Claims to Windows Token Service

When claims authentication is being used in SharePoint, it’s important that everything is configured with it correctly to allow the C2WTS to create the appropriate Kerberos tickets. If it’s not configured correctly, it won’t work, but there may not be many logs pointing to that fact. This makes the service rather tricky to troubleshoot. The best way I’ve found is just to verify all of the settings when it’s believed to not be working correctly.

The white paper Configuring Kerberos Authentication for Microsoft SharePoint 2010 Products goes over this really well, but see below for a high level checklist.

  • Ensure the service account for C2WTS is a local administrator on the WFE
  • Make sure the following SECPOL settings have the service account included (Local Policies/User Rights Assessment)
    • Logon as a service
    • Act as part of the operating system
    • Impersonate a client after authentication
  • In Central Admin make sure the C2WTS service account is included in Managed Accounts
  • In Central Admin make sure the C2WTS service is configured to use the above managed account
  • In the Services snap-in make sure the Claims to Windows Token Service is dependent on Cryptography Services

Once all of those setting are verified, restart the Secure Token Service in Central Admin (Services on Server). If C2WTS had incorrect settings, and everything above in this document tested successfully, then Kerberos delegation should be working now.

What if it’s still not delegating?

If after all of the above troubleshooting has been performed and delegation is still not happening, then it time to go through the referenced White paper (Configuring Kerberos Authentication for Microsoft SharePoint 2010 Products) step and step and make sure that EVERYTHING is 100% configured correctly.

In my experience with troubleshooting a number of different environments, spending an hour to two and verifying correcting any issues with the above three areas, Data Source, WFE, Application/C2WTS, will usually result in an environment with working delegation. If not, then more time will need to be taken to go through the steps in close detail.

The good news is that SharePoint has some of the best documentation in the Microsoft landscape. If you’ve taken the time to read it all, then you’ll be very well prepared to take on the task of troubleshooting delegation in an existing environment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: