Active Directory SSO for SAP BusinessObjects BI4
So following my previous post on AD SSO with BusinessObjects XI 3.1 and a lot of interest in updating the post to provide step-by-step guidance for BI4 AD SSO, below please find another SSO cheat sheet for BI4. I have used the latest KB note on AD SSO which is 1631734, written by Steve Fredell.
Please note that in this example below, I am assuming that Tomcat is being used for the web application server, and it is by default installed on the same instance as the BusinessObjects BI4 application. In a distributed scenario, certain actions will take place on the Web App instance, and others on the BusinessObjects BI4 instance.
Instead of just letting you walk through the process yourself, I also wanted to give you a more visual guide. So below, please find a DSLayer special edition, video walkthrough of this guide:
Firstly, let’s define our server names and IPs (you must obviously adjust these and the commands below to reflect your server names and IPs:
- Domain Name: DOMAIN (FQDN: DOMAIN.INTERNAL)
- Service Account: biservice (password: Password1)
- Domain Controller: adserver.DOMAIN.INTERNAL
- BusinessObjects Server: bi4server.DOMAIN.INTERNAL
- BusinessObjects AD Group: DOMAIN\UserGroup
Step 1
Create an Active Directory service account, biservice (pass: Password1). Ensure the user config has ‘Password never expires’ option checked on.
On the BusinessObjects server, add the DOMAIN/biservice user to the Local Administrators group. Also assign the biservice user the right ‘Act as part of Operating System’ in the Local Security Policy snap-in.
Step 2
Run the following command on the Active Directory server to create appropriate Service Principal Names (SPNs):
- setspn -a BICMS/biservice.domain.internal biservice
- setspn -a HTTP/bi4server biservice
- setspn -a HTTP/bi4server.domain.internal biservice
Verify the SPNs have been created by running ‘setspn -l biservice’.
Step 3
Change the user config of ‘biservice’ user in Active Directory configuration, and under the Delegation tab, turn on ‘Trust this user for delegation to any service (Kerberos only)’.
Step 4
Under the AD Authentication area in the Central Management Console, take the following actions:
- Enable Windows Active Directory (AD)
- AD Administration Name = DOMAIN\biservice
- Default AD Domain: DOMAIN.INTERNAL
- Add AD Group: DOMAIN\UserGroup
- Use Kerberos Authentication
- Service principal name = BICMS/biservice.domain.internal
- Enable Single Sign On for selected authentication mode
Click Save to save all your entries. Check under the Groups area to make sure your AD group has been added.
Step 5
Modify the Server Intelligence Agent (SIA) process on the BusinessObjects server to run as the DOMAIN\biservice user.
Step 6
Test this by logging into Web Intelligence Rich Client by using an AD user who is part of the group. SSO should occur once you select ‘Windows AD’ authentication and click OK (no need to input your username or password).
Step 7
Create a file called ‘bscLogin.conf’, save it into C:\Windows\ directory on the BusinessObjects server, and put the following content into it using Notepad:
com.businessobjects.security.jgss.initiate { com.sun.security.auth.module.Krb5LoginModule required debug=true; };Create a file called ‘krb5.ini’, save it into C:\Windows\ directory, and put the following content into it using Notepad:
[libdefaults] default_realm = DOMAIN.INTERNAL dns_lookup_kdc = true dns_lookup_realm = true default_tgs_enctypes = rc4-hmac default_tkt_enctypes = rc4-hmac udp_preference_limit = 1 [realms] DOMAIN.INTERNAL ={ kdc = ADSERVER.DOMAIN.INTERNAL default_domain = DOMAIN.INTERNAL }Verify this file is completed correctly by navigating to C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win64_x64\jdk\bin\ folder on the BusinessObjects server, and execute ‘kinit biservice’ in a command prompt. If a new ticket is stored, the file is correct.
Step 8
Stop Tomcat. Modify the BI Launch Pad’s .properties file to reveal the authentication dropdown. Navigate to C:\Program Files (x86)\SAP BusinessObjects\Tomcat6\webapps\BOE\WEB-INF\custom and create a file called ‘BIlaunchpad.properties’ with the following text:
authentication.visible=true authentication.default=secWinADOpen up the Tomcat Options, and add the following lines to the Tomcat Java Options:
-Djava.security.auth.login.config=c:\windows\bscLogin.conf -Djava.security.krb5.conf=c:\windows\krb5.iniStart Tomcat, then try and do a manual logon to BusinessObjects, and check Tomcat trace logs for a ‘commit succeeded’.
Step 9
Stop Tomcat. Modify C:\Program Files (x86)\SAP BusinessObjects\Tomcat6\conf\server.xml, by adding ‘maxHttpHeaderSize=”65536″‘ in Connector Port 8080 tag.
Navigate to C:\Program Files (x86)\SAP BusinessObjects\Tomcat6\webapps\BOE\WEB-INF\config\custom and create a file called ‘global.properties’ with the following text:
sso.enabled=true siteminder.enabled=false vintela.enabled=true idm.realm=DOMAIN.INTERNAL idm.princ=biservice idm.allowUnsecured=true idm.allowNTLM=false idm.logger.name=simple idm.logger.props=error-log.propertiesOpen up Tomcat Options Add the following lines to Tomcat Java Options:
-Dcom.wedgetail.idm.sso.password=Password1 -Djcsi.kerberos.debug=trueDelete logs in C:\Program Files (x86)\SAP BusinessObjects\Tomcat6\logs\ and C:\SBOPWebapp_BIlaunchpad_IP_PORT\.
Start Tomcat, go to C:\Program Files (x86)\SAP BusinessObjects\Tomcat6\logs\, check stdout.log has ‘credentials obtained’ shown.
Test silent single sign on is now working in a browser (not on the BusinessObjects server).
Step 10
Copy BIlaunchpad.properties and global.properties from C:\Program Files (x86)\SAP BusinessObjects\Tomcat6\webapps\BOE\WEB-INF\config\custom to C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\warfiles\webapps\BOE\WEB-INF\config\custom so that patches don’t overwrite them and SSO stops working.
Step 11
Create a keytab on the AD server by running the following command:
ktpass -out bosso.keytab -princ biservice@DOMAIN.INTERNAL -pass Password1 -kvno 255 -ptype KRB5_NT_PRINCIPAL -crypto RC4-HMAC-NTCopy this file to c:\windows of BOBJ server.
Stop Tomcat.
Add the following line to C:\Program Files (x86)\SAP BusinessObjects\Tomcat6\webapps\BOE\WEB-INF\config\custom\global.properties
idm.keytab=C:/WINDOWS/bosso.keytabOpen up the Tomcat Configuration, remove the Wedgetail line in Java Options, restart tomcat and make sure ‘credentials obtained’ still showing up in stdout.log.
Now check silent single sign on still operating correctly.
Step 12
Remove debug=true from the C:\windows\bscLogin.conf file, and also remove the debugging line in Tomcat Configuration, Java Options.
Conclusion
Hopefully this walkthrough gives you a good idea of what is required to get AD SSO working on BI4.
Don’t forget to look at SAP note 1631734. Also included in the SAP note is troubleshooting assistance for each step.
April 25th, 2012 at 9:03 PM
Hi Mayur,
Thanks for your comment but I’m afraid it’d be too difficult to try and troubleshoot this. If you log a support case with SAP, you should be able to get this resolved quickly.
Cheers, Josh
April 24th, 2012 at 6:51 AM
Hi Josh,
Great keynote, I was going through each step with BO 4.0(fixpack 13) SSO and on step 9 i check the log and did saw credentials obtained, however when i try single sign on on browser it returned following error, Can you please help me out set upHTTP Status 500 – com.wedgetail.idm.sso.ProtocolException: com.wedgetail.idm.spnego.server.SpnegoException: com.dstc.security.util.asn1.Asn1Exception: Bad tag encountered: 78
April 22nd, 2012 at 11:15 PM
Did some further research and found out that the domain and DC information should be in uppercases. -:)
Thanks!!!
April 22nd, 2012 at 10:56 PM
Great video!!! However the kinit test failed with exception: krb_error 21 Message stream modified (41)
April 14th, 2012 at 12:57 PM
Hi Pat,
I’m afraid I can’t provide much help – if you have multiple DCs available make sure you put all of them in the appropriate config file, if only one is specified and it drops off the network, the SSO will stop working.
Thanks, Josh
April 13th, 2012 at 3:52 AM
Josh -
Thanks again. On to a BO4 test install. I can SSO into Designer, I can create a ticket via kinit. But SSO fails, account not recognized, from Launchpad, I am however validated if I enter my password. Lauchpad trace indicates Cannot get kdc for realm Myrealm.org.
Any clues or directions before i open a message?
Thanx Pat w
April 3rd, 2012 at 8:56 PM
Hi Tejus, as long as there is shared trust between the two domains, you should be able to add a new AD group in the CMC, such as DOMAIN2\Group1 and it should authenticate ok.
Thanks, Josh
March 30th, 2012 at 9:15 PM
How do we add an new domain to the AD configuration ?
We already have windows AD working for a domain and would require groups of another domain to access BO? Is this possible?
March 30th, 2012 at 4:24 PM
Hey Ethan,
Yes I haven’t done it for BI4 as yet, but in XI 3.1 you were able to leverage the AD authentication on the CMC login page (similar setup to InfoView), but I believe SSO was not possible – this is a design feature I understand, in that any administration shouldn’t be SSO.
Cheers, Josh
March 30th, 2012 at 4:23 PM
Hi Ethan,
Thanks for that – yes any typos etc please send through
Cheers, Josh
March 21st, 2012 at 10:24 PM
Also, is there any way to get SSO to work for the CMC as well as for BI?
March 21st, 2012 at 4:35 PM
I followed your guide and found it to be great, thanks!
There are some points were the guide is missing a minor step, and the video sure helped make sure I’m still on track.
There are a couple of typos in paths and codes in the guide, if you want, I’ll point them out to you, for the sake of posterity.
March 14th, 2012 at 9:03 AM
Hi Pat,
Great to hear. The service account is bound to the web application server (WAS), Tomcat for instance. So if you cluster the BOBJ services, but still retain one WAS instance, then you won’t need to modify any service account details, just replicate the BOBJ server specifics on the new BOBJ server. If you are building an entirely new BOBJ cluster, separate to existing, then for simplicity sake create a new service account (though I think you can get away with sharing one technically).
Cheers, Josh
March 10th, 2012 at 12:35 AM
I used your post for AD SSO for 3.1 and it worked great for my single server install of BusObj. I now want to move to a clustered environment, that is I want to add another server to the existing BusObj server which is AD SSO. Question, do I use the same service account that is presently being used in my existing AD SSO BusObj server for the new server which will be part of the new cluster, or do I create a new service account for the new server? My concern with using the same service account was around creating additional /different SPNs and what exffect that would have on the existing AD installation of BusObj.
thx patw
February 14th, 2012 at 2:24 PM
That’s what I thought. It is happening in all of my environments, and I have double checked and triple checked the SPN’s. So maybe it is something to do with the domain setup. Thanks
February 14th, 2012 at 2:04 PM
Hi Matt,
That should work ok normally, because you have defined SPNs for both the hostname and the FQDN – maybe something to do with the domain setup?
Kind regards,
Josh
February 14th, 2012 at 6:03 AM
Not sure what changed, but after installing the remaining patches for the other components SSO started working again.
I have one more question however. SSO works great when I go to http://BOBJSERVER/BOE/BI but I get a Windows Authentication popup when I go to http://BOBJSERVER.mydomain.com/BOE/BI and then an http 500 error if I actually log in, or just the normal log in screen in I click cancel. Any way to make this work from both the hostname URL and the FQDN URL? Thanks again
February 10th, 2012 at 8:03 PM
I have had the problem after installing patch 11 with SAP authentication. Problem: the configuration in patch 11 is not the same, we have done more security-configuration in BW-System.
Maybe that is the same with AD-Authentication
February 1st, 2012 at 10:30 AM
Hey Matt, I haven’t I’m sorry – so I’m not sure if there is a bug or not..
February 1st, 2012 at 7:48 AM
Has anyone tried this since Patch 11? I installed Patch 11 on my DEV environment yesterday as well as on the new PROD environment today, and this no longer works. Even after uninstalling and going back to Patch 10. I’ve wasted so much time trying to figure it out.
January 25th, 2012 at 9:42 PM
Somebody out there must understand how this stuff works!!
Do me one favour though – but in big letters to make user the domain name is entered in capitals – save me a lot of grief next time!
January 25th, 2012 at 1:15 PM
I don’t think the instructions in the admin guide have worked for SSO configuration with Vintela since XI R2, so I’m not sure why they haven’t fixed the doco as yet. Don’t worry, some parts of it I don’t even fully understand, not being an AD techie, but the good thing is once you’ve done it several times, you can nail it 99% of the time, and the 1% can be resolved by SAP support.
January 24th, 2012 at 6:12 PM
I’d love to hear some comments about why your instructions work despite being different to those in the admin guide!
I avoided Kerberos for the whole XIR2 release, but don’t have much option any more, I’m trying to get a better understanding of what’s going on rather than just following instructions.
January 18th, 2012 at 11:10 AM
Hi Rahul, thanks for your comment and glad to hear AD SSO is working for you. End-to-end SSO has it’s own challenges and I’d encourage you to look to the SAP Service Marketplace and Support Notes (or even Support Team at SAP) to help resolve this issue.
Cheers, Josh
January 18th, 2012 at 7:13 AM
Great Post, SSO is now working and AD users can now login successfully. Now are are trying to establish end-to-end SSO to SQL server 2005 reporting database from Business Objects and we have issues. When refreshing the reports from the webi client it comes up with error saying that “session cannot be verified” Please help
January 9th, 2012 at 9:14 AM
Thanks Jason- will see if I can get can add that later on. Cheers, Josh
January 8th, 2012 at 1:01 PM
Great post. I would also request that you post instructions for end to end single sign on, i.e to include SSO from BOBJ to SAP BW and how mapping is done between AD users and BW users and how groups are managed for these users in BOBJ
December 4th, 2011 at 9:28 PM
Great demo video – and doc.
The real question is why SAP BOBJ doesn’t provide more content in this “clear” a style…?
THANKS!
November 17th, 2011 at 12:36 PM
Thanks for this – nice counterbalance to Steve F’s whitepaper.
November 14th, 2011 at 9:06 AM
Hi Sean,
Thanks for your comment. That was a domain Admin account, but purely added for the purposes of the demo. It doesn’t need to be added, I just did so I could test while logged in as the Admin user.
Cheers, Josh
November 2nd, 2011 at 5:54 AM
great update. I was following the BI 4.0 admin guide for SSO and as you will find, it is totally messed up. your video saved the day for me. QUick question: the Admnistrator account that you added to the usergroup AD group, is it a local Administrator account on your bobj server or is it a dmain Administrator account ?