Setting up SAP BusinessObjects single sign-on based on WinAD logins.

February 3, 2015 by: David Lai

sso feature image

Single sign-on (SSO) is an important feature that I highly recommend all organizations to setup in their SAP BusinessObjects implementations. It allows users to move between services securely and uninterrupted without specifying their credentials each time. SSO effectively joins these individual services into portals and removes the service boundaries – switching from one application to the next appears seamless to the user.

In this article we will walk through step by step instructions on setting up single sign-on with SAP BusinessObjects 4.1+.

Listed here are the technical specifications used to accomplish single sign-on in our guide.

  • Domain controller server name: BOBJDOMAIN.BOBJ.COM (Windows Server 2012)
  • SAP BusinessObjects server name: BOBJSERVER.BOBJ.COM (Business Objects 4.1 SP3 server on Windows Server 2012)
  • Client Machine: CLIENT-MACHINE1.BOBJ.COM (Windows 7)
  • Domain name: BOBJ.COM
  • SAP BusinessObjects web application server: Tomcat
  • Service Account Name: bissoservice
  • Service Account Password: b1Password
  • Windows Active Directory group: Test Group
  • Test account name: testuser (member of Test Group)
  • Test account password: Helloworld2015


Setup manual Windows AD sign on

First we need to be able to manually log in to our SAP BusinessObjects server with users configured using Windows Active Directory from the domain controller server.

Step 1

First we need to create an Active Directory service account. Open the Server Manager on the domain controller server.


Go to the Active directory Users and Computers management tool.


Create the service account that will handle the sign on requests. To do this, right-click the Users folder, select New and then User.

Fill in the following information

  • First name = BISSO
  • Last name = Service
  • User logon name = bissoservice
  • password = b1Password


Once the bissoservice user has been created, we need to edit the delegation properties.  Right click on the bissoservice user and select Properties. Click on the Delegation tab, and then select Trust this user for delegation to any service (Kerberos only).


Step 2

Now we need to create three Service Principal Names (SPN) for the service account. This can either be done on the domain controller server or BusinessObjects server. In this example, we will run the SPN create commands on the domain controller server. On the domain controller server, open up the Command Prompt.

Type the following commands:

First change to the root

cd \

Run the following setspn command so that it allows Tomcat to communicate with the Active Directory. The “-a” option means to add. The first SPN will be called BICMS.

setspn -a BICMS/ bissoservice

If successful, it will display a message saying that it has registered the Service Principal Name and it has updated the object. Now we need to set a second SPN for Tomcat and link it to the new user account.

setspn –a HTTP/bobjserver bissoservice

Finally, we need to qualify the server address.

setspn –a HTTP/ bissoservice

Now we need to verify that the SPN are created by using the “l” list command.

setspn –l bissoservice


 Step 3

Next we will create a test user and test group that we will be using for the WinAD authentication.

On the domain controller server we will add the following user

  • First name = TEST
  • Last name = USER
  • User logon name = testuser
  • password = Helloworld2015


Create a group called User Group. To do this, right click on the Users folder, select New and then Group.

create user group

Add the testuser to the User Group by right clicking on the User Group and selecting Properties.


and then adding it from the Members tab.


You will need to make sure the From this location: is BOBJ.COM and testuser is entered into the text area.


Step 4

We will now setup WinAD authentication on the BusinessObjects server.

Log into the CMC with a user that has administrator privileges. Go to the Authentication area.


Click on Windows AD to go to the Windows Active Directory authentication options.


Click on the check box beside Enable Windows Active Directory (AD).


Click on the double quotes beside AD Administration Name.


Enter the service account information as well as the domain name. In our case the service account is bissoservice and the domain is BOBJ.COM.


Now type in the group we are going to map in. Beside the Add AD Group (Domain\Group) text field, type the AD Group Name. In this example, we are going to type in BOBJ\USER GROUP. Click the Add button. Note that we can also type USER GROUP as the default domain is already set at BOBJ.


Under Authentication Options, select Use Kerberos authentication. Now we need to type in the Service Principal Name from Step 2 into the text field. In this example, we are going to type BICMS/bissoservice.BOBJ.COM. Also, make sure the check box beside Enable Single Sign-On (SSO) for the selected authentication mode is checked.


Under Alias Update Options, select Create New Alias when the Alias Update Occurs. Under the New Users Options, select New users are created as named users. At the bottom of the window, click the Update button.


Step 5

We are now going to verify that the group USER GROUP and the testuser has been added to Business Objects.

In the CMC, go to Users and Groups and you will see that the testuser has been added under User List and USER GROUP has been added under the Group List.

Step 6

Before we can test if the WinAD users can log in, we must configure the BusinessObjects server appropriately.

In the BusinessObjects server, add the user that we just created to the Local Administrator group. To do this, first go to Computer Management.

computer management

Double click on the Administrators group and then click on Add…


Make sure the From this location: has BOBJ.COM inside, then enter the service account name bissoservice into the text area.


You will then see the service account in the local Administrators group. Click Apply and then OK


Step 7

Still on the BusinessObjects server, we need to edit the local policy for the service account. To do this go to the Search menu and type local, then select Local Security Policy.


Expand the Local Policies folder, click on the User Rights Assignment folder, and then double click on the policy Act as part of the operating system.


On the properties window click on Add User or Group…, make sure the From the location: field contains BOBJ.COM, and then enter the service account bissoservice into the text area.


The service account is now part of the local policy. Click Apply and OK.


Step 8

The next step requires us to modify the Central Configuration Manager (CCM) so that it uses the service account bissoservice.

In the BusinessObjects server type “central” in the text search field and then click on the Central Configuration Manager (CCM) icon.


We need to stop the Server Intelligence Agent (BOBJSERVER). Click on the Server Intelligence Agent (BOBJSERVER) and click the stop button.


Now we need to change this server from running as a local account to the user account we just created, the bissoservice account. Under the Log On As section, uncheck the check box beside System Account. Type in the appropriate service account name and password. Click the Ok button to apply the changes.


Start the Server Intelligence Agent (BI4) server again by pressing the start button.


To test if the WinAD testuser account is working, click on Manage Servers. Login with the testuser account and make sure Windows AD is selected for the Authentication type.


An empty manage servers window should pop up. As long as you don’t get an error message it means that the WinAD login is working!


Step 9

The next step is to create 2 files (krb5.ini and bsclogin.conf), and have tomcat read them during start up so that Java applications such as BI Launchpad and Central Management Console recognize WinAD logins.

On the BusinessObjects server, go to C:\Windows and create a new file called bsclogin.conf.

Edit bsclogin.conf and insert the following code into the file. { required debug=true;


Then create another new file in C:\Windows called krb5.ini.

Edit krb5.ini and insert the following code into the file.

default_realm = MYDOMAIN.COM
dns_lookup_kdc = true
dns_lookup_realm = true
default_tgs_enctypes = rc4-hmac
default_tkt_enctypes = rc4-hmac
udp_preference_limit = 1
default_domain = MYDOMAIN.COM

In our example we use


default_realm = BOBJ.COM

dns_lookup_kdc = true

dns_lookup_realm =true

default_tgs_enctypes = rc4-hmac

default_tkt_enctypes = rc4-hmac





default_domain = BOBJ.COM


Now that we are finished configuring the 2 files, we must configure Tomcat to take into account the 2 files krb5.ini and bsclogin.conf.

First you will need to stop Tomcat.


Then open up Tomcat Configuration through the search menu


Click on the Java tab. Under the Java Options section, we are going to add some additional lines. Type in the following text:\windows\bscLogin.conf\windows\krb5.ini

Restart Tomcat


Step 10

We are going to test if we are able to manually log into the BI Launch Pad with a WinAD account.


Enter in the correct login credentials for testuser and make sure that the Authentication type is set at Windows AD.

If you log into BI Launchpad successfully that means manual Windows AD has been set up correctly! Congratulations!!


Setup single sign-on

Now that we have set up Windows AD correctly, we want to enable single sign-on so that users don’t have to manually log in every time they want to use SAP BusinessObjects.

Before we start you must stop the Tomcat server

Step 1

For Tomcat servers you must increase the default HTTP header size in the server.xml because Kerberos login requests contain group information. The more AD groups a user belongs to, the larger the http header must be to accomodate the size of the kerberos packet. The default is 16384 and is large enough in most cases, however if you are a member of many groups (let’s say over 50) you will need to increase the size in multiples of 16384. For our example we will set the max header size at 65536.

Navigate to <Installation\SAP BusinessObjects\tomcat\conf> and edit the server.xml file.


Find the Connector Port 8080 tag which is our default HTTP and at the end of it add the following line of text:



Step 2

Navigate to <Installation\SAP BusinessObjects\tomcat\webapps\BOE\WEB-INF\config\default>

Copy the file and paste it to <Installation\SAP BusinessObjects\tomcat\webapps\BOE\WEB-INF\config\custom>

Now open up the file with the editor of your choice.

Search and modify the lines that match the settings below.








Step 3

Open up Tomcat Configuration.

Click on the Java tab. Under the Java Options section, we are going to add extra lines. Type in the following text:


The “wedgetail” tag enables us to embed the password from the service account into the Java options so that it can communicate with Active Directory. When we get single sign-on to work, we will need to remove this because the password is hard coded in these options and anyone with access is able to view the password for this account. To solve this, we will need to create a non-readable file and store it there.

The following line is only used for testing purposes to see if the setup works.



Navigate to <Installation\SAP BusinessObjects\tomcat\logs> and delete all the .log files.

Restart Tomcat from the Central Configuration Manager.

Step 4

Our next step is to check the log files if the server is communicating with Active Directory server. Open the stderr.log file in <Installation\SAP BusinessObjects\tomcat\logs>. Search for CREDENTIALS OBTAINED. If you are able to find it for the service account, in this case bissoservice, then Tomcat is able to successfully communicate with the Active Directory server.


Step 5

Now we want to test out the single sign-on with a client machine.

Using any client machine that has access to the domain BOBJ.COM, log into the machine with testuser.

Using any web browser of your choice, enter the BI Launchpad URL


You should be able to log in without any input or request for your user name or password. This time it passed the user name and password to Active Directory, authenticated it and TEST USER, who is logged onto this client machine, signed in automatically.


Congratulations! You have successfully implemented single sign-on in SAP BusinessObjects with Windows AD authentication!!


23 Responses to “Setting up SAP BusinessObjects single sign-on based on WinAD logins.”
  1. Nice job with the instructions David. It took a long time for me to understand the WinAD SSO configuration process and created a document myself with the instructions early in 2014. Although you have some minor differences compared to my documentation, the steps are covered and explained well in your post.

  2. Ariel says:

    Hi David,
    First of all, congrats on your website. Second, I wonder if you can provide some tools to ‘debug’ or troubleshoot as I followed your instructions but getting some errors.

    • David Lai says:

      Hi Ariel,
      Unfortunately for this type of setup it’s hard to use a debugging tool. What kind of issues are you having on the SSO setup?

  3. Anuj Jain says:

    Hi David,

    Excellent explanation. After reading your blog, It was really easy to understand and SSO Setup.

    Appreciate your knowledge.


  4. Shivam Kumar says:

    Hi David,

    Its a very well explained article. Do you have a similar set of instructions to set up SSO using LDAP authentication?

    • David Lai says:

      Hi Shivam,
      Thanks for the compliments. Unfortunately at the moment there is no documentation for SSO using LDAP. Maybe I’ll write up an article when I get more time.

      • Aaron says:

        Hi David,

        Thank you for article. We will be waiting SSO using LDAP documentation also. There is no explantion on internet for this type.

        • David Lai says:

          Hi Aaron,
          Thanks for the feedback. When I have time I will write an article on doing SSO with LDAP

          • ivan montano says:

            I am setting up SSO with sapbo 4.1 sp6 on RHEL 6.4, and I could configured SSO with Launch Pad, but I couldn’t with RichClient. I could configured to manual configuration, it means I can log on using AD user and password with an AD user and selecting LDAP in combobox in richclient, but it is not working the SSO. Please advice me if it is possible to do it or I just can do it manually?

  5. Mahboob Mohammed says:

    Hi David,

    This is simply great. Appreciate your effort to write this up. Is it OK to copy this content and use (with few updates obviously) as documentation for what I’m doing at my client site? I’m going to do the same thing next week there.

    Don’t you have a like button? :-)

    Mahboob Mohammed

  6. Vikrant Kulkarni says:


  7. Chandra says:

    A very handy guide which helped me massively in setting up Windows SSO for a very large energy client’s global BO reporting platform. Thanks, David and hats-off to you for keeping it very simple.

    To everyone who needs to get this configured, follow the steps line by line and its 1 in a million chance that you would fail!




  8. Jesse says:

    Great detail and well done…!!! I do have a questions for you relating to the SPN.

    What is the steps for multiple Tomcat servers in relationship to the service account ID.

    I would not expect to create a different ID for each SPN as it relates to different Tomcat servers ?

    I would think that you can apply additional URL references to the same service account and share the same service account across many Tomact servers?

    Is that correct? We currently have 4 specific environments relating to dev, testing, production and prod fix.

    I have been unable to find anyone that points that out with any AD BO setup.

    Many thanks and great job!


    • David Lai says:

      Hi Jesse,
      You will need to ensure that setspn is done on all the tomcat servers to the same domain controller.
      SAP BusinessObjects tomcat should automatically perform single sign on when the above is done correctly.
      You’ll also need to make sure the java runtime parameters and Kerberos config files in the Windows directory are setup correctly.

  9. Zuko says:


    How do I setup the same so of SSO on Dashboard 4.1 like when I take snapshot to swf or pdf I don’t want to pop up that BO login screen for credentials

  10. Vishal says:

    I would like to setup SSO using windows login to BOBJ, we use SAP for our security, does above method would work for the setup? Seems like the above setup is for for BOBJ security on AD

  11. ReneG says:

    Hi David
    Thanks very much for the post, excellent structure and walk through!

    Got one query, it’s a detail issues, but it seems to halt my configuration here. Windows AD is working, SSO for BILaunchpad is NOT. I can logon to the Web tier (server) with my credentials, and use SSO to logon to client tools such as WebI rich client and even CCM.

    The one step it seems to fall apart again is your Single Sign on configuration Step 4:
    I’ve never seen this in the stderr.log file.

    Also, if I do a manual Windows AD logon to BI launchpad, the logon is loged in stdout.err, NOT stderr.log (as vintella logging would suggest, I’ve seen SSO authenticated logins on other servers logged in the stderr.log file).

    Section from stderr.log file:

    [DEBUG] Thu Nov 10 09:42:27 EST 2016 jcsi.kerberos: Available KDC found: /10.10.xx.xx:88
    [DEBUG] Thu Nov 10 09:42:27 EST 2016 jcsi.kerberos: Sending message to KDC: /10.10.xx.xx:88
    [DEBUG] Thu Nov 10 09:42:27 EST 2016 jcsi.kerberos: Sending TCP request: /10.10.xx.xx:88
    [DEBUG] Thu Nov 10 09:42:27 EST 2016 jcsi.kerberos: connected; sending length and request…
    [DEBUG] Thu Nov 10 09:42:27 EST 2016 jcsi.kerberos: sent request; reading response length…
    [DEBUG] Thu Nov 10 09:42:27 EST 2016 jcsi.kerberos: read length; reading 116-byte response…
    [DEBUG] Thu Nov 10 09:42:27 EST 2016 jcsi.kerberos: — got 116-byte response, initial byte = 0x7e
    [DEBUG] Thu Nov 10 09:42:27 EST 2016 jcsi.kerberos: Message sent sucessfully to KDC: /
    log4j:WARN No appenders could be found for logger (org.apache.axis2.deployment.WarBasedAxisConfigurator).
    log4j:WARN Please initialize the log4j system properly.

    Seems to be an issue with the Tomcat logging/appending?? Either way, SSO fails….

    The configuration files are as per your examples (and SAP’s), all steps preceding work, again Win AD authentication works, SSO works locally on server…..

    Not sure if this helps at all, thanks for your help in advance!


    • Ted P says:


      I had the same issue as you, my problem was when I saved the file I saved it as Once I spotted that, I renamed it and everything worked. Hope this helps.

  12. Kathy says:

    Excellent!!!!! Very detailed. It was a great help for me so far.

    I do have a question and hoping you could help me out. I’m on Step 10, before the single sign on setup, and having issues. I can’t get the test account to do a AD log on in CMC. The same test account is fine in the Central Configuration Manager for Tomcat.

    What could be the problem? how can I troubleshoot that?

    I’d appreciate your help.

  13. Kathy says:

    Excellent !!!! It was so helpful for me so far.

    I do have a question for you and hoping that you could give me some suggestions or help. I’m currently on Step 10, right before setting up single sign on. The test account I used when in Central Config Manager for Tomcat works fine. But when I tried the same user name in CMC with Windows AD authentication, I get an error. “account information not recognized: Active Directory Authentication failed to log you on.

    Can you give some idea on how to troubleshoot this?

    Thanks so much!

  14. Lasse says:


    Could someone please elaborate on how to set the delegation to a Specific service instead of the above mentioned:

    Trust this user for delegation to any service (Kerberos only).

    Isn’t there some security riscs by delegate to any services?



Leave a Reply

9 − = four