Additional Blogs by Members
Showing results for 
Search instead for 
Did you mean: 
Former Member


This document combines steps from the XI 3.1 admin guide(s) with the latest best practices we learnt from SAP support while doing the proof of concept. This is for XI 3.1 SP3 version of Business Objects and a Java version of Infoview. The following steps will also configure Business Objects for single sign-on (both Desktop Intelligence and Infoview) for multiple domains.

To enable AD authentication with Kerberos on multiple domain you need a 2 way Forest trust (Transitive trust) between the default domain and the external domain. See SAP note #1323391 for requirements.

Service account

Prior to configure SSO you must have a service account:

1.        Create a service account on AD domain. Check ‘User cannot change password’ and ‘Password never expires’ options.

2.        Create SPN for manual logon (CMS) and access points for SSO:

Note: In this example we have our AD domain account as “bouser”.

Our default domain is BODOMAIN.COM

Our BO server name is “bonodename” and its IP is [valid IP Address]

To create the SPN, these below commands need to be run on the AD domain in a command line:

ktpass –out sso.keytab –princ bouser@BODOMAIN.COM –pass XXXX –kvno 255 –ptype KRB5_NT_PRINCIPAL –crypto RC4-HMAC-NT

setspn –a BOCMS/bouser.BODOMAIN.COM bouser

setspn –l bouser

setspn –a HTTP/bonodename bouser

setspn –a HTTP/[valid IP Address]bouser


When finish run the following command to see all the created SPN:

setspn –l bouser

3.        Open the account properties click the Delegation tab and select “Trust this user for delegation to any service (Kerberos only).”
Note: You will not see the Delegation tab until after you have entered the SETSPN command.

Granting the service account rights

In order to support AD and Kerberos, you must grant the service account the right to act as part of the operating system. This must be done on each machine running a Server Intelligence Agent (SIA) with the following servers:

Ø    CMS

Ø    Crystal Reports Processing Server (required only for SSO2DB)

Ø    Report Application Server (required only for SSO2DB)

Ø    Web Intelligence Processing Server (required only for SSO2DB)

1.      On the Business Objects machine, click Start > Control Panel > Administrative Tools > Local Security Policy.

2.      Expand Local Policies, and then click User Rights Assignment.

3.      Double‐click Act as part of the operating system.

4.      Click Add.

5.      Enter the name of the service account you created, then click OK.

6.      Repeat the above steps on each machine running a Business Objects Enterprise server.

Adding the Service Account to the servers’ Local Administrators group:In order to support Kerberos, the service account must be part of the local Administrators group for each server that has a SIA with one of the following services deployed:


Ø  Crystal Reports Processing Server (required only for SSO2DB)

Ø  Report Application Server (required only for SSO2DB)

Ø  Web Intelligence Processing Server (required only for SSO2DB)

1.      On the desired machine, right‐click My Computer and click Manage.

2.      Go to System Tools > Local Users and Groups > Groups.

3.      Right‐click Administrators, then click Add to Group.

4.      Click Add and type the logon name of the service account.

5.      Click Check Names to ensure that the account resolves.

6.      Click OK, then click OK again.

7.      Repeat these steps for each business Objects server that has to be configured.

Configuring the servers to use the service account:

1.      In the Central Configuration Manager (CCM), stop the Server Intelligence Agent (SIA).

2.      Double‐click the SIA to view its properties.

3.      On the Properties tab, in the Log On As area, deselect the System Account check box.

4.      Provide the user name and password for the service account you created earlier, click Apply, then click OK.

5.      Restart the SIA.

6.      If necessary, repeat steps 1 through 5 for each SIA that is running a service that has to be configured

Set up AD authentication in the CMC:

Set up AD Authentication as stated in the admin guide. This part is easy and I don’t need to go over it in details.

At this point you need to have a default domain group mapped from AD. Verify that the users are created. The group scope you are mapping should be either global or universal not local.

Configuring server

1.        Create file called bsclogin.conf in c:\WINNT directory (If C:\WINNT does not exist create it)

This file should contain the following lines:

  1. {
  2. required debug=true;


2.        Create a file called krbi5.ini in the same directory as the previously created file. You may need to refer to the admin guide for more help on creating this file. But this is an example of a krbi5.ini file for 2 domains with 2 way forest trust.



default_realm = BODOMAIN.COM

dns_lookup_kdc = true

dns_lookup_realm = true

udp_preference_limit = 1

default_tgs_enctypes = rc4-hmac

default_tkt_enctypes = rc4-hmac


  1. BODOMAIN.COM  = {


default_domain = BODOMAIN.COM











The default realm is the default domain.

Kdc is the domain controller.

4.        To verify the krb5.ini can successfully receive a ticket (this does not verify multi-domain issues) Navigate from DOS command line to the Boinstall\javasdk\bin directory. By default this is c:\program files\business objects\javasdk\bin

Run kinit username hit enter and type your password

Kinit bouser@BODOMAIN.COM

If the KDC in the krb5.ini is correct you should receive a ticket

If an error occurs please search our KB/notes or open a message with support if necessary.

Configuring Tomcat

In order for InfoView to work you must ensure your web/app has access to the bsclogin.conf and krb5.ini.

The steps to accomplish this will vary depending on web/app. For this document we will assume the default tomcat is being used.

Add the following lines to the tomcat java options.

Tomcat must be restarted to test.\winnt\bsclogin.conf\winnt\krb5.ini

Change to the BO server registry

1.      Back-up your registry : Run à regedit à Export àgive a name and save the file somewhere

2.      Navigate to HKEY_LOCAL_MACHINE/SOFTWARE/Business Objects/Suite 12.0/Enterprise/secWinAD

3.      Right click, New, in the string value enter: UseFQDBForDirectoryServers True

4.      Restart SIA

Map the other domain group in the CMC as follows:

1.      Other domain name\group name

At this point, a manual login with the other domain should be possible. It’s a good time to test.

Java Infoview configuration

2.      Server.xml — For Tomcat servers it is necessary to increase the default HTTP Header size in the server.xml. Kerberos login requests contain group information and this requires a larger header size. 16384 is usually large enough but if your AD contains users that are a member of many groups (50 or more AD groups). You may need to increase this size to 32768.

Default path is c:\program files\business objects\tomcat55\conf\server.xml

In the server.xml you will want to define any “non-SSL HTTP/1.1 Connector on port 8080” or “SSL HTTP/1.1 Connector on port 8443” (if using SSL) have maxHttpHeaderSize=”16384” or higher (if needed).

3.      Web.xml – This is where the vintela filter is enabled. The changes below consider a default web.xml.

Default path is c:\program files\business objects\tomcat55\InfoViewApp\WEB-INF\web.xml

In most cases when using SSO you will want to change your authentication default to secWinAD, siteminder must be set to false, and vintela to true.

a.          Remove open and close comments from auth filter (bold <!-- )

b.          Set the idm.realm to your service account domain. MUST be in ALL CAPS (“BODOMAIN.COM”)

c.          Set your idm.princ to the service account (“bouser”)

d.          Comment out the legacy logging (bold <!-- )

e.          Uncomment Filter mapping

f.           Save web.xml

NOTE: If in the same cluster deployed on the exact same version/patch then this file can be copied between machines. It may be copied from different environments again if the product/version are exactly the same and the CMS name is modified to = the destination environment. It may not be copied if any patch is different, or any different/additional products (that modify the .war files) have been installed.

Verifying web.xml settings

If the settings don’t seem to have an effect, open the web.xml with a browser such as IE. Review the changed settings (the values what are uncommented should show up in dark text. Commented values will appear grayed out)

5.        Configuring Java Options for vintela server components

Then 2 more options must be added to the tomcat java options

The wedgetail.sso.password is the password for the vintela SSO account

The DJCSI.kerberos.debug options will enable a start up trace of the vintela filter.



At this point, you should test SSO from client machine on both domains.

Desktop Intelligence SSO

6.        Login to Deski once using the AD credentials.

7.        Login again without username and password.



XI 3.1 Admin Guide:

Configuring Manual Kerberos Authentication and –or SSO in Distributed Environment

Configuring Vintela SSO in Distributed Environments: Complete Guide: