SSO working, but "silent" SSO fails

[Former Member]

I've followed Tim's guide, and set up XI 3.1 SP2 (FP 2.4), and have configured vintela. To date, I have the following working:.</p>

DeskI, Designer: choose Windows AD from the drop down box and click OK to logon correctly..</p>

Query As a Web Service - Enable Windows AD SSO is checked, and I can logon correctly as myself by clicking OK..</p>

InfoViewApp (Tomcat only, will work on IIS7 later) - can manually enter my AD credentials and password and I logon OK.</p>

In CMC, my group is mapped in the AD box, and I can see my account in the users, and has been updated from AD with my name and email address.</p>

</p>

When I look at stdout.log file, I can see the "credentials obtained" when Tomcat starts, and I can see my login attempt.</p>

Acquire TGT using AS Exchange.</p>

principal is proa4@XXX.</p>

And the "Commit Succeeded".</p>

Before this attempt - and any attempt from a client machine where a user enters .</p>

http://server:8080/InfoViewApp, I can see the following "error"..</p>

or http://fqdn:8080/InfoViewApp.</p>;

It does fill in my username on the login screen, and as mentioned I can then type in my AD password and login correctly..</p>

</p>

</p>

16-03-10 13:47:34:234 - [/InfoViewApp].[action] Thread [http-8080-Processor25]; Servlet.service() for servlet action threw exception.</p>

java.lang.IllegalStateException</p>

at org.apache.catalina.connector.ResponseFacade.sendError(ResponseFacade.java:418)</p>

at javax.servlet.http.HttpServletResponseWrapper.sendError(HttpServletResponseWrapper.java:117)</p>

at com.businessobjects.sdk.credential.WrappedServletResponse.sendError(WrappedServletResponse.java:30)</p>

at com.wedgetail.idm.sso.AbstractAuthenticator.setUnauthorizedResponse(AbstractAuthenticator.java:1328)</p>

at com.wedgetail.idm.sso.MechChecker.authenticate(MechChecker.java:144)</p>

at com.wedgetail.idm.sso.AbstractAuthenticator.authenticate(AbstractAuthenticator.java:1060)</p>

at com.wedgetail.idm.sso.AbstractAuthenticator.authenticateServiceTicket(AbstractAuthenticator.java:998)</p>

at com.wedgetail.idm.sso.AbstractAuthenticator.checkAuthentication(AbstractAuthenticator.java:953)</p>

at com.wedgetail.idm.sso.AuthFilter.doFilter(AuthFilter.java:122)</p>

at com.businessobjects.sdk.credential.WrappedResponseAuthFilter.doFilter(WrappedResponseAuthFilter.java:66)</p>

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)</p>

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)</p>

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)</p>

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)</p>

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)</p>

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)</p>

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)</p>

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)</p>

at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)</p>

at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)</p>

at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)</p>

at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)</p>

at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)</p>

at java.lang.Thread.run(Thread.java:595)</p>

Debug is true storeKey false useTicketCache false useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is false principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false</p>

[Krb5LoginModule] </p>

</p>

I'm quite confused here, as other people who reported this issue had problems with the infoviewapp\web-inf\web.xml file - but mine looks correct, when I compare it to Tim's guide. What else should I be looking at to solve this issue?</p>

</p>

BOE is running on Windows Server 2008 x64. Tomcat is running under the Bus Obj service account i created in AD, as is the SIA/CMC and all servers. The account is trusted for delegation for Kerberos, and has the 'Act as part of the O/S' set.</p>

</p>

Edited by: Adrian Procter on Mar 16, 2010 10:14 PM

[Former Member]

Worked with SAP technician. I had the problem of silent single signon not working. Manual AD signon worked. The problem was two service accounts existed in AD with the same servicePrincipalName in each. For example if you have AD accounts of service-vintella and service-vintella2 with each having http/MyBoServer as part of the servicePrincipalName as seen in Microsoft's AD Explorer, then silent SSO will not work. Deleting the account service-vintella from AD fixed the issue for me.

[Former Member]

I am getting the same problem after installing SP2.4 - with exactly the same stack trace. This was working in SP2 with no issues. I have rechecked all of my web.xml files. Did anyone find a resolution to this issue.

AD login works. SSO shows the correct user in the logs and says the keytab is fine. But I get the InfoViewApp IllegalStateExcpetion and that verbatim stack trace.

[Former Member]

Yes, I did get this working with help from SAP.

The tech support (3rd line I think) went through my configuration, and everything was correct, as per Tim's documents. In the end, all we did was change the application pool for the PlatformServices and InfoViewApp folder back to the "Default Pool", apply & restart IIS7. Then, we changed it back to the BOSSO pool that I had made, apply & restart IIS7.

We turned on "Enable Integrated Windows Authentication" in IE8, restarted IE and I was able to login silently using SSO to InfoView. We did nothing to Kerberos/Tomcat setup, and it started working.

The tech support guy said that he had seen this quite a bit with IIS 7 not regsistering the pool correctly, and that the changing the pool and re-applying it got it to reset something.

Hope that helps.

Adrian

Edited by: Adrian Procter on Apr 15, 2010 4:41 PM

[BasicTek]

The app pool issue is something new that started in XI 3.x. It seems that when our product creates an app pool which is default NTLM that the apps must be removed from it and re-added, we have a KB on this.

On the SPN the packet scan and kerbtray would reveal this. It's impossible to see with the server tracing when the HTTP SPN is duped, logs on the server will look ok because the failure only occurs on the client.

I'm going to mark this as answered, thanks for sharing your resolutions

Regards,

Tim

[BasicTek]

proa4@XXX is your manual logon attempt, which succeeded per the log.

SSO cannot be traced fully from the server. In the doc it mentions using a oacket scanner and kerbtray as per the examples. I have written a KB on this (key words in SMP of netmon SSO packet scan) should find. You need to trace SSO on the client workstation once you get the credentials obtained. 3 ticket requests should occur (as request for the user, tgs for the user, and tgs for the http/fqdnurl. Microsoft kerbtray alone will usually verify this but the packet scan will allow us to view the errors if it's failing. If you need help open a case with support - authentication team

Regards,

Tim