I’m enabling SSO with Windows AD on my new BO Server R3.3 (Windows Server 2008) .
Windows AD authentication is working perfectly. SSO only works for some users (?!) For those, it’s not working IE7 displays a frame in the center of the window and display “Internet Explorer cannot display the webpage” .
I’ve look all the documentation. Check all the milestones several times but nothing helps…
Is anyone have an idea, clue or direction where I can look for?
Also check if the IE browser settings are correct:
Enable Integrated Windows Authentication*
Add the InfoView Link to Local Intranet site.
Uncheck the IE option - Show Friendly HTTP Error Message…so that it will give you complete error message. IE > Tools > Internet Options > Advanced > Browsing section.
If you are using Vintela SSO, then you can also enable logging and check what is getting logged when user with IE7 browser tries to login.
Did you analyze the pattern ?
Is it user specific or machine specific or occurs at random ?
May be this would lead us to understand the problem better.
Users that can use the single sign on are users from the group adm… (administrators) and accounts for external consultants.
What we think is the problem is around settings in IE or some configuration in Tomcat. The strange thing is that we don’t have any of this problem. Might be a little change somewhere in the test server install but I was not there yet.
another strange thing that may be lead one of you to an idea. My profile doesn’t work but I log into Windows account with my administrator account. Then, this worked. But, when I logged off and logged on into Windows with my normal account (not administrator) , SSO is working but I’m logged in InfoView as my administrator account … Strange!
Seems that we find the origin of the problem. The ticket generated by Kerberos is limited to a 5000 Octets size. For some users, those that belongs to a lot of groups, this ticket is too big.
Solution we’ll test will be to increase the size limit on the server to something bigger…
We have change the size of the Kerberos ticket but still the same. Some users can single sign on and some have a frame not displayed in IE.
In firefox, the behaviour is the same: some users can log on automatically and some are rejected. But with this software there’s no error displayed but only we have the web page for the login/password.
The logs of Tomcat are not relevant because the message is quite generic:
28-02-11 16:52:46:195 - {ERROR} [/InfoViewApp].[action] Thread [http-80-Processor19]; 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)
Other thing : We have 2 test environments , one is Windows Server 2008 and the other 2008 R2 . 2008 R2 is the one not working and 2008 . IT seems that the configs for the web.xml files of Tomcat are the same.
Tried but did not helped. The log remain the same. Is there something special to install for the log4j? I am not a specialist of this. Can you explain me simply how it works?
In other hand, I’m trying to use kerbtray.exe to check the Kerberos ticket. Next step, would be to scan packets on the client computer.
My feeling is that TOmcat is ok but error is coming from the Kerberos ticket (may be too big?)
This problem is only faced for users with a lot of groups in WinAD. ie users from IT . Users that may need single sign on are not users from IT.
I guess the problem is that for those users Kerberos ticket size is too big and can’t be read by Tomcat or InfoView. So, in order to solve this, it involves either changing the WinAD organization (=> impossible) either changing some conf somewhere in Tomcat… But I didn’t find it
Considering the small number of users impacted by this problem, I don’t think spending more time is useful.
Counting all your efforts in this…I couldnot resist myself posting this.
If you are very sure, that issue is because of
Then, you should be increasing “maxHttpHeaderSize” in server.xml file as suggested by edyl in the first shot.
Basically, Kerberos ticket stores all the groups which the user is memeber of. And this Kerberos ticket is passed through HTTP Header. The very same thing I found here - http://solution.ibi.com:8080/32362530.html
So I would suggest you to increase the size to largest - maxHttpHeaderSize=“65536” and check result.
Another good point I found on this link - This number should
always be increased/decreased in incriments of 4096.
After a lot of investigation, I found the solution.
Actually, for those users that belongs to a huge number of Win AD groups, the HTTP request generated by InfoView, in order to SSO, was too big.
So, because this is too large, our firewall intreprets it as a malformed htttp request. So the request was dropped for those users.
the problem was coming from the Smartdefence module of Checkpoint
We were having the same issue and it also was only for users in a large number of AD groups.
Your post got us heading in the correct direction. Rather than the cause being the firewall it was “Riverbed” technology which also dropped the http requests.
FYI Of all users who could SSO the largest number of AD groups was 77. Of all the users who couldn’t log on, the lowest number of AD groups was 102.
(BOB member since 2007-09-27)
(BOB member since 2007-12-26)
