Windows AD SSO not working after upgrade to BI 4.1

[former_member246738]

We have just performed a minor release upgrade from BI 4.0 SP5 Patch 2 to BI 4.1 SP01. While Windows AD SSO was working perfectly before the upgrade it has stopped working now. Is there anything specific that needs to be done for SSO to work for BI 4.1. I did not find any specific instructions in this regard in the upgrade guide.  I came across the parameter name “sso.types.and.order= ” in the following link but not sure what the values for this parameter should be. The link is What to expect in SAP BusinessObjects 4.1 | All Things BOBJ BI Blog .

[dallas_marks]

Take a look at SAP KB 2041379 Explaining the SAP BusinessObjects Business Intelligence 4.1 sso.types.and.order para..., which summarizes the new parameter and contains links to updated documentation. Also, beginning with BI 4.1, you can enable SSO in the Central Management Console (CMC), as described in SAP KB 2190831 How to enable CMC SSO in BI41 SP6.

[Former Member]

To the wretched soul despairingly searching through these here forum posts for the solution to his/her BI 4.0/4.1 AD SSO problem... who has worked through every post, walk-through, hot-tip and tutorial, checked NTLM-auth client settings for every imaginable browser, captured every kerberos packet, tried every SPN/principal combination, generated every kind of keytab file there is, made every possible bilaunchpad/global.properties amendment, every bscLogin.conf setting, every krb5.ini configuration and xml file edit...and restarted tomcat 18 billion times.

setspn -x

Have a nice day

SAP... keeping SAP consultants in a job, since forever really.

[former_member189884]

Just as a note, I have recently worked with someone in which setspn -x showed zero duplicates however ADEXPLORER showed there were in fact duplicates. I used to think setspn -x was also a goto for duplicates, this has proven incorrect.

There was no reason for them not to show as the users were in the same ou, and upon querying each individually was able to see the spns. Not sure of the cause but if your out of ideas WIRESHARK (in this case of a Tomcat startup) is the best bet S_PRINCIPAL_UNKNOWN led to the search.

[Patrick_Perrier]

Perhaps Solution 2 here can help: http://scn.sap.com/community/bi-platform/blog/2013/11/08/warning-patching-your-sap-bi-40-to-sap-bi-4...

2: Your Apache Tomcat server.xml

This one was a bit trickier!  The problem is that manual authentication is still working and Silent SSO is working for some of the users.  The others receive a HTTP error.

Turns out patching from SAP BI 4.0 to SAP BI 4.0 will also install a new version of Apache Tomcat (From Tomcat 6 to Tomcat 7).  The installation folder is a bit different too:

• Old Location: C:\Program Files (x86)\SAP BusinessObjects\Tomcat6\

• New Location: C:\Program Files (x86)\SAP BusinessObjects\tomcat\

Doing so, the content of your server.xml has been lost.  Simply edit the new server.xml and make sure to re-apply the

maxHttpHeaderSize="65536" value in the Connector Port.

[hossain_shahin]

I have a slightly different issue with 4.1 AD SSO Kerberos. I have followed the standard BOE4 AD SSO pdf. all seems Ok. I can login with an AD user that has been mapped via CMC from AD (manual) but when I try to login to BOE/BI from a Windows workstation, just the login page comes up. I know the props are taking because I see the custom Auth AD selection visible. I have hardcoded the SPN password on Tomcat JAVA props. I have used all kinds of SPN permutations same thing.

-Dcom.wedgetail.idm.sso.password=password

-Djcsi.kerberos.debug=true

The odd part is that although I have also activated debug, I see very little output on Tomcat 7 logs.

a/

[former_member189884]

do you see the credentials obtained in the logs? if not perhaps the global.properties and/or bilaunchpad.properties is not configured correctly

[hossain_shahin]

Yea, its strage, the Tomcat 7 (new tomcat version in BOE4.1) just does not seem to log anything after the app server starts. The BILaunchpad.properties file is simple:

authentication.visible=true

authentication.default=secWinAD

... the global props is also pretty straight forward:

sso.enabled=true

siteminder.enabled=false

vintela.enabled=true

idm.realm=ANGEL-LINK.NET

idm.princ=cidboeadmin

idm.allowUnsecured=true

idm.allowNTLM=false

idm.logger.name=simple

idm.logger.props=error-log.properties

I am hardcoding the spn (cidboeadmin) and putting the pwd in tomcat java props as I mentioned to bypass the key tab file as recommended by some blogs for t/s.

... I do know to look for "jcsi.kerberos: ** credentials obtained .. **" in Tomcat logs and not seeing it. This new Tomcat logs are weird. The TGT ticket does get logged during manual AD login tho.

Tomcat java custom props:

-Djava.security.auth.login.config=c:\windows\bscLogin.conf

-Djava.security.krb5.conf=c:\windows\krb5.ini

-Dcom.wedgetail.idm.sso.password=PWdOfSPN

-Djcsi.kerberos.debug=true

[former_member189884]

are you looking at the stout.log or stderr.log? it changed in the recent versions.

[Jonathan_Haun]

What do you get when you run:

setspn -l cidboeadmin

Do this from the windows 2008 r2 server command line.

Also, did you run the command to generate a keytab file using the mapuser parameter? This can change the UPN of the service account an change the way Vintela looks for the service account in AD.

[Former Member]

I can confirm that Tomcat 7 directs all the startup Vintela/Kerberos output to stderr.log. the only vintela/Kerberos-related information that goes to stdout.log is the debug output created by a user logging on to the BI 4.1 system (a Kerberos ticket retrieval).

I can also confirm what josh said regarding sso.enabled and vintela.enabled parameters in global.properties. I have windows AD SSO working in BI 4.1 without specifying any sso.types.and.order parameters.

[Jonathan_Haun]

All,

Other than the notes in the BILaunchad.properties and OpenDoc.properties files, I was not able to find any additional documentation. What I do know is that with 4.1 SP0, AD SSO would not work without setting this parameter to sso.types.and.order=vintela. If I upgrade 4.0 to 4.1 SP1 directly, I get mixed results. Sometimes it works with the default order, other times I need the parameter. I have conducted about 15+ 4.0 to 4.1 upgrades to date. My advise is to try SSO with the parameter defined. If it does not work, define the parameter.

Thanks,

Jonathan Haun

[former_member246738]

Hi,

The SSO seems to be working fine now. It was a problem with the keytab file. For some reason this seems to have gotten corrupted. I got a new keytab file generated by our AD administrator and everything started working. Additionally, I found that the SSO worked even without the parameter set explicitly. Thanks everyone for your inputs..

[Jonathan_Haun]

A quick followup. Starting with 4.1 SP2, the various .properties files properly explain how this all works. The sso.types.and.order=vintela is the new method for enabling and configuring SSO types. It also allows you to define the order in which the system attempts to authenticate the users. The legacy settings in global.properties are listed below. You can continue to use them or switch over to the new "sso.types.and.order=" option. The new option can be configured in BIlaunchpad.properties and OpenDocument.properties. Starting with 4.1 SP2 I have had no issues using either method. Just remember that the new option overrides the legacy options.

# LEGACY SSO SETTING - Ignored when an application's sso.types.and.order is set

# Set to true to enable other single sign on.

# Scope: application

sso.enabled=false

# --- OTHER LEGACY SSO SETTINGS

# LEGACY SSO SETTING - Ignored when an application's sso.types.and.order is set

# Set to false to disable Siteminder single sign on.

# Scope: application

siteminder.enabled=false

# LEGACY SSO SETTING - Ignored when an application's sso.types.and.order is set

# Set to true to use SAP SSO as the primary SSO mechanism

# Scope: application

sso.sap.primary=false

# LEGACY SSO SETTING - Ignored when an application's sso.types.and.order is set

# Set to true to enable Vintela single sign on.

# Scope: global

vintela.enabled=false

New Setting

# Set sso.types.and.order to define a comma delimited list of SSO types to be enabled and the ordering

# An empty list indicates that the legacy ordering is to be used

# If the list is specified, the legacy options will be ignored

# Valid options: vintela, trustedIIS, trustedHeader, trustedParameter, trustedCookie, trustedSession, trustedUserPrincipal, trustedVintela, trustedX509, sapSSO, siteminder

# If none are desired specify: none

sso.types.and.order=

[ACE-SAP]

Hi

I've just installed a new BO 4.1 and did get into troubles with SSO.
I can confirm you need to set parameter sso.types.and.order

I needed to setup SSO with Windows AD for BI Launchpad so I had to insert that line:

sso.types.and.order=vintela

in the BIlaunchpad.properties

I did get this information from that blog:

http://bobj.sapbiblog.com/2013/06/18/what-to-expect-in-sap-businessobjects-4-1/

No SAP documentation talks about that parameter.

The only information you can get is in the default global.properties file...

So now it is not only RTFM but also Read The F. Config Files

Regards

\tomcat\webapps\BOE\WEB-INF\config\default\global.properties

# ========== SSO Related Default Global Core Web Properties ==========

# Vintela single sign on properties

# Scope: global.

# Applicable if supported by app and included in its sso.types.and.order.

[alexdc12]

This solved my problem of Not being able to use BICS connections with SSO!

Thanks!

[former_member189884]

The sso.types.and.order parameter shouldn't need to be used if you have set the sso.enabled to true as well as the vintela.enabled to true.

-josh

[Former Member]

I agree with Jawahar. Seems like the likely root cause. Hopefully, you documented the customizations you made to enable SSO.

For what it's worth, it's always best to make such customizations in the <INSTALL_DIR>/warfiles/webapps/BOE/ directory rather than the <INSTALL_DIR>/Tomcat6/webapps/BOE/ drectory.

By customizing the files in <INSTALL_DIR>/warfiles/webapps/BOE/, you preserve them if the web applications are ever re-deployed (such as during a Patch installation).

[former_member246738]

We are not using Tomcat. We are using SAP Netweaver AS Java 7.3. I have checked this possibility of global.properties file getting overwritten but it doesn't seem to be the case. The global.properties is intact in both the locations i.e ..J00\j2ee\cluster\apps\sap.com\BOEWEBAPPJAVA\servlet_jsp\BOE\root\WEB-INF\config\custom & in ....SAP BusinessObjects Enterprise XI 4.0\warfiles\webapps\BOE\WEB-INF\config\custom.

[former_member184468]

Check your properties files.  If you did not make your modifications in ...SAP BusinessObjects Enterprise XI 4.0\warfiles\webapps\BOE\WEB-INF\config\custom and instead did those directly in your tomcat deployed folders, those configurations would have been deleted as the war file will be redeployed. 

[Former Member]

Your custom settings might have over written by upgrade. Please check GLobal.Properties files