Once again, I have had to make Kerberos works. This time, I had to configure Kerberos authentication on a SQL Server 2008 R2 Failover Cluster installation running Windows Server 2008 R2, having one SQL Server named instance and an Analysis Services named instance too, inside the same Application or Resource Group.

Because I was configuring Kerberos on SQL Server / Analysis Services to be used by MOSS 2010, I was following the Configuring Kerberos Authentication for Microsoft SharePoint 2010 Products guide. However, after this configuration was applied, Kerberos wasn’t working at all. Therefore, the users could work properly using the (traditional) NTLM Authentication instead of Kerberos Authentication.

Eventually, I found out a Workaroud to make Kerberos works on that environment: Enable the Kerberos delegation on the Service accounts and Computer account and restart the Cluster (well, I do believe the only required step was to enable the Kerberos delegation on the Service accounts, but I’ve been making a lot of changes before that, so I’m not 100% sure). It doesn’t make sense, because I only need Kerberos authentication (instead of both, Kerberos authentication and Kerberos delegation too), but it works for me.

Environment Description

I had an Active Directory environment having one Domain Controller running Windows Server 2003 R2 (that’s the GUILLESQL domain). The Forest Functional level was Windows 2000 and the Domain Functional level was Windows Server 2003.

I have a two Nodes Failover Cluster running Windows Server 2008 R2 (Node names: VSQL11 and VSQL12). That Cluster has one Application or Resource Group for MSDTC, and other Application or Resource Group for both SQL Server and Analysis Server. Note that SQL Server and Analysis Services are named instances instead of default instances.

The Virtual Name for SQL Server and Analysis Services was MSSQLSERVER01 (having MSSQLSERVER01.guillesql.local as FQDN), and the name resolution was working properly (forward and reverse). The named instance was MSSQLSERVER01 too, so to connect to SQL Server or Analysis Services we had to specify MSSQLSERVER01\MSSQLSERVER01 as Server Name.

SQL Server and Analysis Services were running under the same domain user account (GUILLESQL\SERVICE_SQL, just a domain user account, without any special permission or right), meanwhile the SQL Server Browser was running under Local System.

Kerberos configuration, as described on the MOSS 2010 Kerberos Guide

As described on the MOSS 2010 Kerberos Guide, we had to configure the required SPNs (using the setspn.exe tool), and after that, the Kerberos Authentication would work (or not).

So I ran the following SetSPN commands for creating the SPNs for SQL Server and Analysis Services:

SetSPN -S MSOLAPSvc.3/MSSQLSERVER01:MSSQLSERVER01 GUILLESQL\SERVICE_SQL

SetSPN -S MSOLAPSvc.3/MSSQLSERVER01.guillesql.local:MSSQLSERVER01 GUILLESQL\SERVICE_SQL

SetSPN -S MSSQLSvc/MSSQLSERVER01:50326 GUILLESQL\SERVICE_SQL

SetSPN -S MSSQLSvc/MSSQLSERVER01.guillesql.local:50326 GUILLESQL\SERVICE_SQL

Because of the fact that we are configuring SPNs for named instances, for SQL Server we had to specify the TCP port used by SQL Server, meanwhile for Analysis Services we had to specify the instance name (instead of the TCP port).

However, after this configuration was made, Kerberos wasn’t working.

Kerberos configuration: additional steps

By my own experience in other Kerberos configurations, I tried to enable the Kerberos Delegation on the Cluster computer accounts (VSQL11, VSQL12 and MSSQLSERVER01) using the Active Directory Users and Computers (ADUC) tool. I’m talking about the “Trust this computer for delegation to any service (Kerberos only)” option or the “Trust this computer for delegation” option, depending of the domain functional mode.

However, Kerberos wasn’t work yet (I restarted the servers, having the same result).

Then, I tried to enable the Kerberos Delegation on the service accounts (GUILLESQL\SERVICE_SQL) using the Active Directory Users and Computers (ADUC) tool. I’m talking about the “Trust this user for delegation to any service (Kerberos only)” option or the “Account is trusted for delegation” option, depending of the domain functional mode. Note that the Delegation tab will be available for a user account only if the user account has any Service Principal Name (SPNs) registered. So because we had just registered the SPNs for SQL Server and Analysis Services, we had available the Delegation tab for the GUILLESQL\SERVICE_SQL user account.

I restarted the servers, and then, SQL Server and Analysis Services started to authenticate using Kerberos.

That's all for today. I hope you enjoy the reading ! Cheers