Windows AD authentication for Business Objects using Kerberos

Hi All,

Hope you continue to read our Series of blogs. Let me discuss something about Single Sign-on implementation in Business Objects in this blog.

Configuring Windows Active Directory SSO with the SAP BusinessObjects XI 3.1 is one of the challenges for a Business Objects Administrator. If you go with java based BO deployment, utmost care should be taken as Java is case sensitive.

What is Single sign-on?

Single sign-on (SSO) is a user authentication process that permits a user to enter one name and password to access multiple applications. This authenticates the user for all the applications they have been given rights to and eliminates further prompts.

Role of Kerberos in SSO

Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications by using secret-key cryptography where a user authenticates to an authentication server that creates a ticket. This ticket is actually sent to the application which can recognize the ticket and the user is granted access.

This blog refers

TESTSERVER - BusinessObjects server installed with Windows 2008 server. The version is XI 3.1 SP3

ADSERVER – Active Directory server installed with Windows 2003 server. Its Domain Functional Level is 2003.

BOLAB-ADMIN – Service Account used to run Business Objects Service.

Steps for configuring Windows AD authentication

Below is the general overview of the steps, which are required to configure the Business objects windows authentication using Kerberos.

• Setting up a service account
• Configure the service account rights
• Register Service Principle Name (SPN)
• Configuring the Server Intelligence Agent to use the service account
• Configure the AD plug-in
• Configure Tomcat web.xml file
• Configure the Krb5AuthLoginModule and krb5.ini
• Configure the Tomcat Java option

Setting up a service account

To configure Business Objects Enterprise using Kerberos and Windows AD authentication, we require a service account which should be a domain account that has been trusted for delegation. We can either use an existing domain account or create a new domain account. The service account will be used to run the Business Objects Enterprise servers.

Setting up a service account with delegation on a Windows 2003 Domain

• Create an account on the domain controller or use an existing account.
• Right-click on the user accounts, then select Properties.
• Click the Delegation tab.
  • Select the Trust this user for delegation to any service(Kerberos Only

1.     Configure the service account rights

In order to support the Active Directory authentication, you must grant the service account the right to act as part of the operating system and log on as a service. This must be done on each machine running the Server Intelligence Agent Service.

To configure this

1. Click Start -> Administrative Tools -> Local Security Policy

2. Then Local Policies and then click User Rights Assignment.

3. Double-click Act as part of the operating system and click Add User or Group button.

4. Add the user account that has been trusted for delegation and clicked OK.

5. Double-click Logon as service and click Add and click Add User or Group button.

6. Add the user account that has been trusted for delegation and clicked OK.

In order to support Kerberos, we must grant the service account the right to act as part of the operating system. This must be done on each machine running the below servers:

• CMS
• Page Server
• Report Application Server
• Web Intelligence Report Server

Adding the Service account to the Administrators Group

• On the desired machine, right-click My Computer and then click Manage.
• Go to Configuration > Local Users and Groups > Groups.
• Right-click Administrators and then click Add to Group
• Click Add… and enter the logon name of the service account.
• Click Check Names to ensure the account resolves.
• Click Ok and then click OK again.
• Repeat these steps for each Business Objects server that has to be configured.

2.     Register Service Principle Name (SPN)

If you are deploying Business Objects Services in a network that uses the Kerberos protocol for mutual authentication, you must create a Service Principal Name (SPN) for the Business Objects services if you configure it to run as a domain user account. The SETSPN utility is a program that allows managing the Service Principal Name (SPN) for service accounts in Active Directory.

• Open a command prompt and enter this command:

SETSPN.exe –A BOBJCentralMS/HOSTNAME serviceaccount

Replace HOSTNAME with the fully qualified domain name of the machine running the CMS service, for example Testserver.NA.HEXAWARE.COM. Replace service account with the name of the service account that runs the CMS service. In this case it is BOLab-Admin.

SETSPN.exe –A BOBJCentralMS/TESTSERVER.NA.HEXAWARE.COM BOLab-Admin

• Once run, we should receive a message similar to the below:

Registering ServicePrincipalNames for CN=ServiceCMS, CN=Users, DC=DOMAIN, DC=COM BOBJCentralMS/HOSTNAME.DOMAIN.COM Updated object

To get a listing of what is currently registered for the account.

SETSPN.exe –L BOLab-Admin

I will discuss more about the subsequent steps in the upcoming blog.

Read More about  Windows AD Authentication