BO 4.0 SSO - External Forest Manual AD Works, SSO Does Not

[ross_anderson2]

Hello everyone, I've been researching this for weeks now without a solution. Basically, we have a multi-forest AD architecture and would like to use SSO on the BI Launchpad for all domains. Manual and SSO AD Authentication is working for the default domain and all child domains, however, ONLY manual AD authentication works on external forests (which have a two-way transitive trust, btw).

This tells me that the general SSO config is correct, plus the KRB5.ini file must be correct because manual authentication is also working to the external forests. I've tried using AD groups in the default domain (with the external forest users) and using AD groups WITHIN the external forest as well - in other words, I've mapped into BOBJ CMC using both methods, neither of which work for SSO (but DO work for manual AD auth). Kinit works for all domains and domain users as well.

I've looked at the following notes and documents as well and haven't found a solution. Has anyone else gotten external forest SSO authentication working in this scenario?  Thanks!!

SAP Articles -

https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/sno/ui_entry/entry.htm?param=69765F6D6F6465...

https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/sno/ui_entry/entry.htm?param=69765F6D6F6465...

https://websmp230.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/sno/ui_entry/entry.htm?param=69765F6D6F6465...

https://websmp230.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/sno/ui_entry/entry.htm?param=69765F6D6F6465...

Threads

http://scn.sap.com/thread/2044457

[Former Member · Accepted solution]

Hi Ross,

I had a similar situation as yourself. The internal Windows AD forest would work perfectly, while the external Windows AD forest wouldn't SSO. Unfortunately, how we resolved this issue isn't a quick fix. We utilized SAP Consultant Support Services to come onsite and build out a custom solution, as we still wanted the solution to be supportable. If supportability isn't a priority for your shop, then you can build out a custom solution to solve this issue. What made this solution even more intriguing is we also had SAP BW authenticated users as well.

In a nutshell, this solution would check the information sent to BusinessObjects, through the HTTP header, and attempt to check each of the Windows AD domains, then SSO the user into the application. The roles would still remain the same, as the Windows AD groups could still be pulled into the application.

Sorry it's not as helpful as you'd expect. However, I at least wanted to provide it, to at least give you another option, if no one else has a solution to this. Let me know if you have any questions/concerns with the above. Thanks,

-Victor

[ross_anderson2 · Accepted solution]

Thanks for the reply Victor. We may have to do some sort of personalized solution but I really don't see why we should have to do that. SSO to the default domain and all child domains is working. Manual auth works for all domains, including external forests, which means it's likely that the KRB5.ini and bscLogin.conf files are correct.

There must be some sort of communication break down between the forests, but even after doing full packet captures and looking through the stdout.log tomcat file, I just can't put my finger on it. Frustrating!

[Former Member · Accepted solution]

Ross,

I 100% understand your frustration. I burnt through many cycles trying to figure out what the deal was. I was literally working 12 - 16 hour shifts just to figure this thing out. What I garnered from the SAP folks is that once it attempts to SSO once, it doesn't continue on.

Meaning, if the user is within the central domain, you'll SSO all day long, without a hiccup. If that user isn't within the central domain (IE: Resides in the external domain), then it won't check the next user store. Thus, folks can manually log in. Just like if you have SAP BW with users within them, configured BI to authenticate those users, folks can manually log into the BI application, SSO just won't work, nor would the BI application attempt to SSO the user in both Windows AD & SAP BW.

Of which, I would strongly suggest not banging your head against that desk any further and discussing a custom solution with your folks. Again, I know this isn't the answer you were looking for, and trust me when I tell you that after spending days/hours on this thing, just to find out a custom solution had to be done, it didn't, knowing that, make me feel any better.

If you have any further questions/concerns over this, please let me know. Thanks,

-Victor

[ross_anderson2 · Accepted solution]

Thanks again for your thoughtful responses Victor. We may just go towards SAP's NW SSO solution or install an EP with Logon Tickets, not sure just yet.

One final note about the External Forest SSO failures though. I notice that during a successful SSO transaction (from the default domain) that all of the logs go into the stdout.log file, and everything looks normal. However, during an external forest sso attempt, the stderr.log file grows by 6k and produces this specific output (below) during every failure. Not sure if there is anything pertinent in here or if it's just a general error, but wondered if this sheds any addt'l light on the subject.

Sep 5, 2013 10:15:34 AM org.apache.catalina.core.StandardWrapperValve invoke

SEVERE: Servlet.service() for servlet equinoxbridgeservlet threw exception

java.lang.RuntimeException: java.lang.IllegalStateException

          at com.businessobjects.http.servlet.internal.BundlePathAwareServiceHandler.serviceHelper(BundlePathAwareServiceHandler.java:254)

          at com.businessobjects.http.servlet.internal.BundlePathAwareServiceHandler.service(BundlePathAwareServiceHandler.java:197)

          at com.businessobjects.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:248)

          at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

          at org.eclipse.equinox.servletbridge.BridgeServlet.service(BridgeServlet.java:220)

          at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)

          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

          at com.businessobjects.pinger.TimeoutManagerFilter.doFilter(TimeoutManagerFilter.java:166)

          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

          at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)

          at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)

          at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)

          at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)

          at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)

          at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)

          at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)

          at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)

          at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)

          at java.lang.Thread.run(Thread.java:662)

Caused by: java.lang.IllegalStateException

          at org.apache.catalina.connector.ResponseFacade.sendError(ResponseFacade.java:421)

          at javax.servlet.http.HttpServletResponseWrapper.sendError(HttpServletResponseWrapper.java:118)

          at javax.servlet.http.HttpServletResponseWrapper.sendError(HttpServletResponseWrapper.java:118)

          at com.businessobjects.sdk.credential.WrappedServletResponse.sendError(WrappedServletResponse.java:30)

          at com.wedgetail.idm.sso.AbstractAuthenticator.writeAuthenticationChallenge(AbstractAuthenticator.java:1936)

          at com.wedgetail.idm.sso.MechChecker.authenticate(MechChecker.java:147)

          at com.wedgetail.idm.sso.AbstractAuthenticator.authenticate(AbstractAuthenticator.java:1444)

          at com.wedgetail.idm.sso.AbstractAuthenticator.checkAuthenticationOnly(AbstractAuthenticator.java:1330)

          at com.wedgetail.idm.sso.AbstractAuthenticator.checkAuthentication(AbstractAuthenticator.java:1139)

          at com.wedgetail.idm.sso.AuthFilter.doFilter(AuthFilter.java:148)

          at com.businessobjects.sdk.credential.WrappedResponseAuthFilter.doFilter(WrappedResponseAuthFilter.java:66)

          at com.businessobjects.http.servlet.internal.FilterRegistration.doFilter(FilterRegistration.java:72)

          at com.businessobjects.http.servlet.internal.filter.FilterChainImpl.doFilter(FilterChainImpl.java:43)

          at com.crystaldecisions.webapp.util.filter.ResponseEncodingFilter.doFilter(ResponseEncodingFilter.java:24)

          at com.businessobjects.http.servlet.internal.FilterRegistration.doFilter(FilterRegistration.java:72)

          at com.businessobjects.http.servlet.internal.filter.FilterChainImpl.doFilter(FilterChainImpl.java:43)

          at com.businessobjects.webutil.boetrustguard.BOETrustValidateFilter.doFilter(BOETrustValidateFilter.java:45)

          at com.businessobjects.http.servlet.internal.FilterRegistration.doFilter(FilterRegistration.java:72)

          at com.businessobjects.http.servlet.internal.filter.FilterChainImpl.doFilter(FilterChainImpl.java:43)

          at com.businessobjects.webutil.internal.filters.BrowserRenderingModeFilter.doFilter(BrowserRenderingModeFilter.java:39)

          at com.businessobjects.http.servlet.internal.FilterRegistration.doFilter(FilterRegistration.java:72)

          at com.businessobjects.http.servlet.internal.filter.FilterChainImpl.doFilter(FilterChainImpl.java:43)

          at com.businessobjects.webutil.boetrustguard.BOETrustPrepareFilter.doFilter(BOETrustPrepareFilter.java:32)

          at com.businessobjects.http.servlet.internal.FilterRegistration.doFilter(FilterRegistration.java:72)

          at com.businessobjects.http.servlet.internal.filter.FilterChainImpl.doFilter(FilterChainImpl.java:43)

          at com.businessobjects.swd.shared.tracelog.TraceLogScopeFilter.doFilter(TraceLogScopeFilter.java:38)

          at com.businessobjects.http.servlet.internal.FilterRegistration.doFilter(FilterRegistration.java:72)

          at com.businessobjects.http.servlet.internal.filter.FilterChainImpl.doFilter(FilterChainImpl.java:43)

          at com.businessobjects.sdk.actionfilter.WorkflowFilter.doFilter(WorkflowFilter.java:45)

          at com.businessobjects.http.servlet.internal.FilterRegistration.doFilter(FilterRegistration.java:72)

          at com.businessobjects.http.servlet.internal.filter.FilterChainImpl.doFilter(FilterChainImpl.java:43)

          at com.businessobjects.swd.appcontext.RequestInitFilter.doFilter(RequestInitFilter.java:26)

          at com.businessobjects.http.servlet.internal.FilterRegistration.doFilter(FilterRegistration.java:72)

          at com.businessobjects.http.servlet.internal.filter.FilterChainImpl.doFilter(FilterChainImpl.java:43)

          at com.businessobjects.http.servlet.internal.BundlePathAwareServiceHandler.serviceHelper(BundlePathAwareServiceHandler.java:235)

          ... 20 more

[Former Member · Accepted solution]

Hi Ross,

Nothing of particular stands out in these logs files. However, based upon which version of Tomcat you're using (6.0 vs 7.0), it depends on the actual meaning of the error: java.lang.IllegalStateException. Of which, here are two URL's that I found that can explain it a bit better:

http://docs.oracle.com/cd/E17802_01/products/products/servlet/2.5/docs/servlet-2_5-mr2/javax/servlet...

java.lang.IllegalStateException - if the response was already committed

https://tomcat.apache.org/tomcat-7.0-doc/servletapi/javax/servlet/ServletRegistration.html

java.lang.IllegalStateException - if the associated ServletContext has already been initialised

In other words, when attempting to utilize your external forest, that functionality has already been called and you're unable to utilize it. Based upon the information I have, I would imagine it's because the SSO functionality has attempted to call the central domain. Once it realized it couldn't do that, it attempted to go to the external domain, thus stating the error above.

Basically, it's unable to make both calls as it needs to utilize the same servlets in order to perform this action. Since it's already being used, it can't use it again. Essentially, I think it's tripping itself up, thinking it needs to initialize it, in order to allow the SSO to work, but it doesn't realize it's already initialized. I know that seems far fetched, but it's my best guess at it.

Please let me know if there is anything else I can help you out with. Thanks in advance,

-Victor

[jmsrpp]

I've seen this before ... the best way to determine the root cause of the failure is to use Wireshark to capture the Kerberos traffic from the browser and the Tomcat server.  It is unlikely that the CMS is getting invoked at this point in the process.

It sounds like the ticket is reaching a limit in the delegation properties or that there is something missing from your krb5.ini allowing Tomcat to determine the source of the ticket.

The last time I encountered this the solution was to add an account from the default domain to the user's PC in the external forest.  This could probably be pushed to all of the computers as a policy from AD.

Bottom line ... the problem is with delegation of the kerberos principle, which is why you don't see the problem with manual logon.  Wireshark is the most complete way to identify the root cause, but if you want to test with the solution I mention above you might find you're encountering the same problem.

[ross_anderson2]

Thanks again guys

Victor - your theory does make sense, but I can't understand why it's doing that. It's designed to do external forest auth, obviously.

James - I think my KRB5.ini must be correct since the manual ext forest auth is working correctly. I'm not completely sure what you mean though by "add an account from the default domain to the user's PC". Are you saying to put the BO AD acct from the default domain into the Administrator's group on the external forest PC?

I've been trying to do more wireshark captures and again, can't quite put my finger on the problem. You are both probably correct in saying that it's likely an issue with communicating back to the external domain via the KRB5.ini file. I'll continue to do a few more wiresharks to and from the Tomcat server.

One other question - does anyone use the [capaths] section in the krb5.ini file? Some documentation says to use it, some does not. I have tried it both ways without success, so I assume it is not necessary for external forest sso.

*EDIT - after several wireshark pcaps, I see that doing manual auth from the external domain results in some kerberos (88) packets from the Tomcat server to the external forest DC, however, doing an SSO attempt from the same external PC does not generate ANY kerberos (88) packets at the Tomcat server; so, the long and short of it is that the CMS is never even sending a kerberos request to the external DC during an SSO attempt.

*EDIT 2 - attached wireshark output from Tomcat server of SSO login attempt from external forest PC/user; no Kerberos packets, only 401 unauthorized when hitting the logonservice.do module; one thing i do notice is that there is mention of NTLMSSP_NEGOTIATE - could this be indicating that the attempt is not Kerberos, but rather NTLM?  I know only Kerberos is accepted by the CMC WinAD plug-in, so don't know if that maybe helps to narrow down the problem.

[jmsrpp]

By adding a user from your default domain to a user's PC in the external domain, I mean accessing computer management (or whatever it is called these days!) and adding a user from the default domain to one of the local groups.  For example, you could add a domain administrator to the local admin group on the user's machine.  This is at the OS level and not from within BI.

I suspect it is the delegation of the Kerberos ticket which is failing, not the communication to the domain controller itself.  If so, the CMS is not even in the equation yet because the failure is occurring either on the user's PC or on Tomcat.

I have not used the [capaths] section myself.

*just saw your Wireshark JPEG.  What we need to look at is the full packet to evaluate what is going on with the AD logon request.  You're right ... this should be of protocol KRB or LDAP and should not involve NTLM.  In order to do SSO in this scenario we must have the appropriately marked Kerberos ticket.  Can you possibly attach the Wireshark capture itself?  You can feel free to email it to me directly as well.

[former_member189884]

what are you using as the idm.princ parameter? also what spn is entered in the CMC winad plugin?

[ross_anderson2]

Thanks for the reply Josh

idm.princ=bobjadm     <- AD service account

SPN (in CMC) => BOBJCentralMS/bobjadm.domain.com     <- As indicated in the "Configuring Active Directory Manual Authentication and SSO for BI4" doc

SPNs

BOBJCentralMS/bobjadm.domain.com

HTTP/sapbo1

HTTP/sapbo1.domain.com

BOBJCentralMS/Domain.com

I just don't get how manual AD auth works but not SSO - I'm leaning towards an issue with the DCs, Trust or GC configuration but I can't put my finger on it.

[ross_anderson2]

Anyone out there doing SSO to an External Forest from the BI Launchpad (/BOE/BI)?

Everything else is working normally. I've tried putting the external forest users into a "Domain Local" security group in the default domain as well as putting them into an AD security group in the external forest domain as well .. neither method works.