BEWARE: Here there be dragons!
In the world of Microsoft BI, one of the more painful configuration tasks is to get double-hop authentication working so that you can run SQL Server Analysis Services on a separate machine to your application/web server.
There is a very detailed article from Microsoft on what you need to do and how to configure your environment to allow for double-hop authentication: http://support.microsoft.com/kb/917409. Boy is it detailed!
Implementing our own software into this environment on many occasions has allowed us to distil these complex instructions into something that is more readable and easier to follow.
What are these SPN things?
They are basically a method of addressing a service in the Microsoft Windows environment which Kerberos uses. There are some specific ones that are used by certain services, e.g. Analysis Services uses MSOLAPSvc.3/name, but they are arbitrary in nature and as long as they match what is being requested, they will work. In CALUMO, we suggest the use of CALUMO/name.
Laws of Kerberos!
These are the main rules you must adhere too when setting up Kerberos delegation
- All user accounts that will be participating in this journey will need to be delegated for authentication in Active Directory (This will be all the users of your system).
- All service accounts that are being used must be trusted for delegation (These are the accounts that run your services, e.g. IIS App Pools, Analysis Services, etc.)
- All computer accounts that will be passing credentials will need to be trusted for delegation. (This will be the middle-hop computers like your Web or Application server).
- SPN’s (Service Principal Names) must be setup correctly for the services/computers that are performing Kerberos authentication
- There cannot be any duplicate SPN’s in your Domain
- You must use NetBIOS or Fully Qualified Domain Names (FQDN) in SPN’s, you cannot use IP addresses.
I’m Ready… I Think..
Ok, so now you are ready to implement Kerberos in your environment for access to Analysis Services, arm yourself with the following details:
| Required Information | Example |
| Webserver’s fully qualified domain name (FQDN) | webserver1.company.com |
| Analysis Services Server FQDN | ssasserver1.company.com |
| The account name that is running IIS on the Webserver | LocalSystem or Network Service or domain\svcWeb |
| The account name that is running the SQL Server Analysis Services service on the SSAS server | LocalSystem or Network Service or domain\svcSSAS |
| The name of the SSAS instance if you are not running the default instance in SSAS | ssasserver1\MyInstance |
Obviously, there are many permutations of ways to setup, so I will cover a couple of the more commonly used scenarios.
Notes:
In all these scenarios, you should run the “setspn –l accountname” command to list what is already set. If what you want to set is already there, move to the next command.
You can use the “setspn –X” command to check for duplicate SPN’s before you start and resolve any conflicts.
At the end, use “setspn –l accountname” to make sure everything is set the way it is meant to be.
Scenario 1
In this scenario, all services are running as Network Service and Analysis Services is running on the default instance. The Web Server is “webserver1.company.com” and the Analysis Services Server is “ssasserver1.company.com”.
You will need to perform the following commands to setup the correct SPN’s:
- setspn –a HTTP/webserver1.company.com webserver1
- setspn –a HTTP/webserver1 webserver1
- setspn –a MSOLAPSvc.3/ssasserver1.company.com ssasserver1
- setspn –a MSOLAPSvc.3/ssasserver1 ssasserver1
Scenario 2
In this scenario, services are running as the service accounts “company\svcWeb” and “company\svcSSAS”. Also, Analysis Services is running as the instance “MyInstance”. The Web Server is “webserver1.company.com” and the Analysis Services Server is “ssasserver1.company.com”.
You will need to perform the following commands to setup the correct SPN’s:
- setspn –a HTTP/webserver1.company.com company\svcWeb
- setspn –a HTTP/webserver1 company\svcWeb
- setspn –a MSOLAPSvc.3/ssasserver1.company.com:MyInstance company\svcSSAS
- setspn –a MSOLAPSvc.3/ssasserver1:MyInstance company\svcSSAS
I’m All Done.. Right?
Pretty much…
The one last hurdle you may encounter is actually getting your browser to allow you to talk Kerberos. That is another blog topic, but I will cover the basics of getting it working with Internet Explorer.
In Internet Explorer, you need to add “http://webserver1.company.com” as a Trusted Site and then ensure the site settings are set to low or medium-low.
Good luck and feel free to email me at jsummerton@calumo.com if you have any questions.
About James Summerton
Excellent article, thanks James, we wouldn’t have been able to get kerberos working for the Calumo site at UNSW if it hadn’t been for your input.
We ran into an issue here where our SPN was set to an alias rather than a DNS ‘A’ record and that created some fun until we figured out what the problem was.
The only other thing that we came across that was a pretty big ‘gotcha’ was the fact that our AD servers (which are also the kerberos ticket issuers and need to be able to be reached independently of the webpage the user is authenticating with, if I remember correctly) weren’t reachable from outside our network, so for users connecting from home or other campuses, we had to get them connected via VPN first so that everything worked.
On the client side – I’ve only ever come across a problem with this a couple of times, but in IE under Advanced settings, “Enable Integrated Windows Authentication” needs to be selected or kerberos authentication fails.