Geeks With Blogs
Satya Srikant Mantha Reflecting DAX NET and SQL Server

What is Kerberos Authentication?

Kerberos (or Cerberus) was a three-headed dog in Greek Mythology which guarded the gates of Haides (King of underworld God of Death). Kerberos was responsible to prevent ghosts of the dead from leaving the underworld.

The Kerberos Protocol was created by MIT as a solution to network security problems like:

1) Insecure unencrypted password over the internet

2) Firewalls, which assumes that the bad guys are outside the network, what about the Bad Guys within the network.

The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. After a client and server has used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business.

The Kerberos protocol has three-faces just like the Greek mythology hound:

1) Client – The User

2) Key Distribution Center (KDC) – divided into two parts Authentication Service (AS) and Ticket Granting Service (TGS)

3) The Server to which the client wishes to logon.


The Kerberos authentication process is divided into three exchanges:

1) AS Exchange:Initially, the user must negotiate access by providing a log-in name and password in order to be verified by the AS portion of the KDC within their domain. The KDC has direct access to Active Directory user account information. Once successfully authenticated, the user is granted a Ticket to Get Tickets (TGT) that is valid for the local domain. The TGT has a default lifetime of 10 hours and may be renewed throughout the user’s log-on session without requiring the user to re-enter his password. The TGT is cached on the local machine in volatile memory space and used to request sessions with services throughout the network. 

2) TGS Exchange: The user presents the TGT to the TGS portion of the KDC when desiring access to a server service. The TGS on the KDC authenticates the user’s TGT and creates a ticket and session key for both the client and the remote server. This information, known as the service ticket, is then cached locally on the client machine. The TGS receives the client’s TGT and reads it using its own key. If the TGS approves of the client’s request, a service ticket is generated for both the client and the target server. The client reads tits portion using the TGS session key retrieved earlier from the AS reply. The client presents the server portion of the TGS reply to the target server in the client/server exchange coming next.

3) Client/Server Exchange: Once the client user has the client/server service ticket, he can establish the session with the server service. The server can decrypt the information coming indirectly from the TGS using its own long-term key with the KDC. The service ticket is then used to authenticate the client user and establish a service session between the server and client. After the ticket’s lifetime is exceeded, the service ticket must be renewed to use the service.

There are other variants of the Kerberos which work on cross domain authentications however this text intends to give a brief about the Kerberos authentication process.

Installation Scenario

Consider a topology in which you are installing SQL Server Analysis Services and Reporting services on separate servers other than the AOS which is on another server. These two servers should trust each other in the active directory. You need to configure your servers for Kerberos Authentication to ensure that the cubes and the reports in the Enterprise Portal to work.

We will discuss in this post regarding a specific topology which is as follows:



We have two servers in this scenario, One of which hosts the enterprise Portal, the AOS and the Development Tools for Enterprise Portal. The other server hosts the SQL Server and all its components along with the Microsoft Dynamics AX 2009 reporting Extensions and Analysis Extensions.

Configure the Domain Controller

Raise the Domain Functional level on your domain controller. Now what does this mean and why it is necessary? Domain functional levels provides the means by which you can enable additional domain-wide Active Directory features, remove outdated backward compatibility within your environment, and improve Active Directory performance and security. Raising a Domain Functional Level essentially means that the domain master concept no longer exists, and the domain controllers are regarded as peers to each other. If you are considering raising the domain functional level within your environment to Windows Server 2003, you should remember that after the domain functional level is raised, you cannot add any older versions of the server operating system into the domain. I would recommend this task in coordination with your Domain Controller as downgrading is not possible and this is a one time task.

For Windows Server 2008 domain controller
1. To open the Active Directory Domains and Trusts snap-in, click Start, click Administrative Tools, and then click Active Directory Domains and Trusts.
2. In the console tree, right-click the domain for which you want to raise functional level, and then click Raise Domain Functional Level.
3. In Select an available domain functional level, do one of the following:

  • To raise the domain functional level to Windows Server 2003, click Windows Server 2003, and then click Raise.
  • To raise the domain functional level to Windows Server 2008, click Windows Server 2008, and then click Raise.

Important: There is a known issue, if SQL Server Analysis Services and  SQL Server Reporting Services are running on separate servers, you must configure your domain controller to run using the Windows Server 2003 domain functional level.

Enable Kerberos Authentication in Office SharePoint Server

Use the following procedure to enable Kerberos authentication in Office SharePoint Server.
1. Click Start, click Administrative Tools, and click SharePoint Central Administration.
2. Click the Application Management tab.
3. Under Application Security, click Authentication Providers.
4. Select the Web application that you want to configure with Kerberos authentication from the Web Application list.
5. Under Zone, click Default.
6. Under IIS Authentication Settings, click Negotiate (Kerberos), and then click Save.
7. Repeat steps 4-6 until you have specified Negotiate (Kerberos) authentication for, at a minimum, the content application and the Shared Service Provider (SSP) application.
8. Close SharePoint Central Administration.
9. Click Start, and then click Run.
10. In the Run dialog box, enter iisreset, and then press Enter.


Configure Service Principal Names

Kerberos authentication requires that you specify certain properties in Active Directory about how and where a service should run. In the context of Active Directory, this is called configuring a service principal name (SPN). What we will do here is to create SPN for HTTP service on the server computer running SQL Server Analysis Services service. Using SetSPN.exe utility which is available in Windows Server 2003 Service Pack 1 or higher on enterprise Portal Computer and SQL Server computer, we will specify the server name, domain name, and application pool account for the HTTP service and the SQL Server Analysis Services service.

Lets assume the SQL Server’s FQDN is “” and for the AOS server it is, you need to run the following commands at command prompt with domain administrator logins on to these systems:

For HTTP Service Principal name:

1) Setspn.exe –A HTTP/AOS domain\apppoolaccount

2) Setspn.exe –A HTTP/ domain\apppoolaccount

3) Setspn.exe –A HTTP/SQL <SSRS service account>

4) Setspn.exe –A HTTP/ <SSRS service account>

Important: Note that I specified <SSRS service account> for SPNs of SQL server, this is due to the fact that the SQL Server 2008 Reporting Services does not use an application pool. Hence the SPN for Reporting services must be set on the Reporting Services service account.

For SQL Server Analysis Services service principal name:

1) Setspn.exe –A MSOLAPSvc.4/SQL <SSAS Account>

2) Setspn.exe –A MSOLAPSvc.4/ <SSAS Account>

Important: <SSAS Account> refers to a domain account or computer name (in case Analysis Services is running on NetworkService account)

Configure Accounts in Active Directory

In this section we will configure user accounts and application pool accounts for Kerberos authentication. I would recommend doing this step in coordination with your Domain controller. There are two steps which needs to be taken:

1) Disable delegated authentication :

a) In Active Directory Users and Computers, right-click a user account and select Properties.
b) On the Delegation tab, under Account Options, clear the Account is sensitive and cannot be delegated check box (if applicable), and click OK.

2) Enable delegated authentication for IIS application pool accounts:

a) In Active Directory Users and Computers, right-click a user account and select Properties.
b) On the Delegation tab, under Account Options, check the Account is sensitive and cannot be delegated check box (if applicable), and click OK.

Deploy ODC files and Configure Kerberos Authentication

To the deployed ODS files on the Enterprise Portal Server edit all the connection strings in ODC files to  include ;SSPI=Kerberos.

Configure Component Services

Use this procedure to configure Component Services on the Enterprise Portal Web server.
1. On the Enterprise Portal Web server, open Component Services (Start > Administrative Tools > Component Services).
2. Locate the IIS WAMREG admin Service (Component Services > Computers > My Computer > DCOM Config > IIS WAMREG admin Service).
3. Right-click this service and click Properties.
4. Click the Security tab.
5. In the Launch and Activation Permissions section, click Edit.
6. In the Launch Permission dialog box, click Add.
7. In the Select Users, Computers, or Groups dialog box, type the domain user account that you specified as the IIS application pool service account, click Check Names, and then click OK.
8. In the Permissions for UserName list, select the Allow check box that is next to Local Activation, and then click OK.


Configure SQL Server Reporting Services 2008

1. Open the configuration file in a text editor such as Notepad. By default the file is located here: <Installation directory>\Reporting Services\ReportServer\
2. Under <AuthenticationTypes> remove the NTLM entry and add the following types: <RSWindowsKerberos /> <RSWindowsNegotiate />
3. Save your changes and close the file.

After such a long process if everything goes well, you should be able to view the SQL Server Analysis Service reports and reporting server reports in Role Center pages. It took me a couple of days study to get everything right. By the way, my favourite screen to check this is the Role Center page of the Finance tab. 


Posted on Tuesday, July 21, 2009 12:53 AM Enterprise Portal Administration | Back to top

Comments on this post: Kerberos Authentication for Role Centers pages in Microsoft Dynamics AX 2009

# re: Kerberos Authentication for Role Centers pages in Microsoft Dynamics AX 2009
Requesting Gravatar...
MSOLAPSvc.4 should actually be MSOLAPSvc.3 as per 917409.
Left by Anne on Dec 30, 2009 3:55 AM

# re: Kerberos Authentication for Role Centers pages in Microsoft Dynamics AX 2009
Requesting Gravatar...
Hi Anne,

During several installations I did with SQL Server 2008 Analysis services i have used MSOLAPSvc.4 instead of MSOLAPSvc.3. Surprisingly this has worked for me. The setup presented in my blogs are purely an outcome of what I have tried. I went thorugh the KB article 917409 you mentioned which pushes me back to think why MSOLAPSvc.3 didn't work in my case.
I have to come back to you regarding this.

Kind Regrads,
Satya Srikant Mantha
Left by Satya Srikant Mantha on Dec 30, 2009 1:59 PM

# re: Kerberos Authentication for Role Centers pages in Microsoft Dynamics AX 2009
Requesting Gravatar...
When configure reporting Services, use the bcproxy account as execution account, and set the SPN to this user.
Left by Nils-Petter on Jan 11, 2010 12:49 AM

# re: Kerberos Authentication for Role Centers pages in Microsoft Dynamics AX 2009
Requesting Gravatar...
Does a user now access Analysis Services with their own ID or a Service account?
Left by Danie Swart on Aug 12, 2010 1:17 AM

# re: Kerberos Authentication for Role Centers pages in Microsoft Dynamics AX 2009
Requesting Gravatar...
This helped me to work the reporting services, i still need to test the analysis service. But i have a website which is using to run all the reports in the reporting services in intranet. that one is not working in windows intgerity. its working in basic authentication. i modified the dcom in the as well.
any idea to make it working in integreated security??

thank you for your help.
Left by bisjom on Oct 17, 2010 6:30 PM

Your comment:
 (will show your gravatar)

Copyright © ssmantha | Powered by: