CRS2008 V1 Vintela SSO - ALMOST There!

[Former Member]

What little hair I had left after implementing AD with Tomcat 5.5 is now gone as I try to get Vintela SSO to work.

I'm at the point that Tomcat's STD.OUT indicates "credentials obtained." I can SSO with the Windows Fat Client tools (e.g. BVM). But, when attempting to connect to InfoView, I'm still presented with logon prompts and the following appears in Tomcat logs:

[/InfoViewApp].[action] Thread [http-8080-Processor25]; Servlet.service() for servlet action threw exception

java.lang.IllegalStateException

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

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

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 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)

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

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

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

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

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

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

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

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

at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)

at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)

at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)

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

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

KERBTRAY is showing two tickets... the two krbtgt, but NOT the http.

Even the propeller on my head won't spin fast enough to figure all this weird Java stuff out... I'm a Microsoft guy!

Any ideas? THANK YOU!!!

- George -

[Former Member]

Turns out that the web server is adding a full-domain to the machine-name-only URL (according to Wireshark capture). Creating an SPN that includes the full domain resolves this issue.

- George -

[Former Member]

Hi George,

Sorry for your hair...

Regarding your sso issue, are you able to connect manually to infoview as it's the first step before doing sso.

Check the following points:

- You have 3 SPNs as

HTTP/Tomcat_server.DOMAIN

HTTP/Tomcat_server

HTTP/IP_of_Tomcat_server

- In AD, for the service account, in delegation tab, you have set the option "Trust this computer for delegation to any service (Kerberos only)".

- Are you using DES or RC4 encryption? (I recommend RC4)

- Try to run the kinit command to check that your krb5.ini file is configured properly

I hope this will help you

Regards,

Philippe

[Former Member]

Philippe,

Thanks for the reply.

I think SPNs are OK:

C:\Users\HansenSup>setspn -l HansenCR

Registered ServicePrincipalNames for CN=HansenCR,OU=ServiceAccounts,OU=Departmen

ts,DC=BOISE,DC=LOCAL:

http/10.215.1.138

http/ch-hansen

BOSSO/HansenCR.boise.local

BOBJCentralIMS/CH-HANSEN.BOISE.LOCAL

(there's no fully-qualified one... should there be a ch-hansen.boise.local--that's now how users will be accessing InfoView, though... they'll just be using ch-hansen:8080/InfoViewApp)?

Can connect manually to InfoView with AD credentials.

Can also SSO to client tools (e.g. Launch BVM, leave ID/PW blank and click OK, logs in fine).

And, KINIT appears to work OK:

D:\Program Files\Business Objects\javasdk\bin>kinit BOSSO/HansenCR.boise.local

Password for BOSSO/HansenCR.boise.local-at-BOISE.LOCAL:**********

New ticket is stored in cache file C:\Users\HansenSup\krb5cc_HansenSup

(had to change the at sign in the domain or this moderately-dumb message board thought it was an e-mail address).

??????

- George -