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
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.bobj.com 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/bobjserver.bobj.com 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.
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
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.
com.businessobjects.security.jgss.initiate
com.sun.security.auth.module.Krb5LoginModule 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.
[libdefaults]
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
[realms]
MYDOMAIN.COM =
kdc = MYDOMAINCONTROLLERHOSTNAME.MYDOMAIN.COM
default_domain = MYDOMAIN.COM
In our example we use
[libdefaults]
default_realm = BOBJ.COM
dns_lookup_kdc = true
dns_lookup_realm =true
default_tgs_enctypes = rc4-hmac
default_tkt_enctypes = rc4-hmac
udp_preference_limit=1
[realms]
BOBJ.COM =
kdc = BOBJDOMAIN.BOBJ.COM
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:
-Djava.security.auth.login.config=c:\windows\bscLogin.conf
-Djava.security.krb5.conf=c:\windows\krb5.ini
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.
Step 2
Navigate to <Installation\SAP BusinessObjects\tomcat\webapps\BOE\WEB-INF\config\default>
Copy the file global.properties and paste it to <Installation\SAP BusinessObjects\tomcat\webapps\BOE\WEB-INF\config\custom>
Now open up the file global.properties with the editor of your choice.
Search and modify the lines that match the settings below.
sso.enabled=true
siteminder.enabled=false
vintela.enabled=true
idm.realm=BOBJ.COM
idm.princ=bissoservice
idm.allowUnsecured=true
idm.allowNTLM=false
idm.logger.name=simple
idm.logger.props=error-log.properties
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:
-Dcom.wedgetail.idm.sso.password=b1Password
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.
-Djcsi.kerberos.debug=true
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
http://BOBJSERVER.BOBJ.COM:8080/BOE/BI
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!!
Source: http://docphy.com/business-industry/business/setting-sap-businessobjects-single-sign-based-winad-logins.html
No comments:
Post a Comment