Skip to Content
author's profile photo Former Member
0
Former Member
Oct 26, 2011 at 06:52 AM

SSO Silent Mode fails: BO XI 3.1 SP4 + Tomcat

34 Views

Hi,

We are trying to troubleshoting failure of Silent SSO Mode after deploying Vintella on BO XI 3.1 SP4 (Tomcat as App server) following Tim Ziemba guide (TN-1483762) . I have carefully reading previous post on same topic (mark as anwered). SSO working, but "silent" SSO fails

My situation is practically the same:

(1) Silent SSO (this is, logon into InfoView withou having to type manually AD credentials) fails. 

25-10-11 17:03:36:903 - {ERROR} [/InfoViewApp].[action] Thread [http-80-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)

(2) Manual AD logon in InfoView works properly

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 
      [Krb5LoginModule] user entered username: gonzaal @ F4E.ORG 

     Acquire TGT using AS Exchange 
     Principal is gonzaal @ F4E.ORG 
     EncryptionKey: keyType=23 keyBytes (hex dump)=0000: BA 55 0B 99 A1 4A A1 8F   48 68 F5 0D F7 86 54 FD  .U...J..Hh....T. 
    
     Commit Succeeded

(3) Following previous posts recommendations we have engaged a kerbtray & packet scanning in the client machine (TN-1370926) with the following results

1554   16:17:48 25/10/2011   239.8711155      10.201.71.24   10.201.0.5   KerberosV5   KerberosV5:AS Request Cname: gonzaal Realm: F4E Sname: krbtgt/F4E    {UDP:333, IPv4:16} 
    1555   16:17:48 25/10/2011   239.8711155      10.201.0.5   10.201.71.24   KerberosV5   KerberosV5:AS Response Ticket[Realm: F4E.ORG, Sname: krbtgt/F4E.ORG]    {UDP:333, IPv4:16} 
    1556   16:17:48 25/10/2011   239.8711155      10.201.71.24   10.201.0.5   KerberosV5   KerberosV5:TGS Request Realm: F4E.ORG Sname: HTTP/es-w08-bobapp1.f4e.org    {UDP:334, IPv4:16} 
    1557   16:17:48 25/10/2011   239.8711155      10.201.0.5   10.201.71.24   KerberosV5   KerberosV5:KRB_ERROR  - KRB_ERR_RESPONSE_TOO_BIG (52)   {UDP:334, IPv4:16} 
    1561   16:17:48 25/10/2011   239.8711155      10.201.71.24   10.201.0.5   KerberosV5   KerberosV5:TGS Request Realm: F4E.ORG Sname: HTTP/es-w08-bobapp1.f4e.org    {TCP:335, IPv4:16} 
    1564   16:17:48 25/10/2011   239.8867405      10.201.0.5   10.201.71.24   KerberosV5   KerberosV5:TGS Response Cname: gonzaal    {TCP:335, IPv4:16}

In the aforementioned thread it was mentioned that "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". In agreement with packet scanning I'm not sure if this is really ocurring.

Any idea?