For our client we are using a setup with Oracle OAM 11.1.2.3 behind a 11g OHS server. The client uses Single Sign On based on Kerberos using a Windows 2008 AD/KDC server.
On the test environment, using test accounts, things are working fine. On the prod environment, though, some users are were not able to log in.
The following error was seen in the managed server log:
<Error> <oracle.oam.engine.authn> <BEA-000000> <org.ietf.jgss.GSSException, major code: 11, minor code: 0
major string: General failure, unspecified at GSSAPI level
minor string: Length of input stream read does not match size of the inner context token
org.ietf.jgss.GSSException, major code: 11, minor code: 0
major string: General failure, unspecified at GSSAPI level
minor string: Length of input stream read does not match size of the inner context token
at com.ibm.security.jgss.mech.spnego.SPNEGOContext.acceptSecContext(SPNEGOContext.java:1)
at com.ibm.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:268)
at com.ibm.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:178)
at oracle.security.am.engine.authn.internal.executor.SPNEGOLoginModule$1.run(SPNEGOLoginModule.java:158)
…
So, we had to figure out what the difference was between the users.
We saw differences between the (spnego) token size, which led to differences between sizes in the headers that were sent from the client to the webtier and, in the end, to the oam server.
There are limits on the OHS that limit the header size. These can be set by the LimitRequestFieldSize in the httpd.conf. But, this would result in a 400 Bad Request Error which was NOT the case. To rule this out, we set this value to 1024 which indeed caused a 400 error. In this case, though, the request did not reach the oam managed server and the error was not seen.
We did see the header entering the oam managed server using extended format logging on the access logs of the MANAGED server. So NOT the access log of the webtier! Using this logging, we could see that the ‘breaking point’ of the error was at exactly 4000 bytes. Sounds like a configurable value, right?
In fact, from OAM 11.1.2.3, there is a new limit on the header size on the OAM Managed server itself!
You can see the limit using wlst from $ORACLE_HOME/common/bin/wlst.sh
Connect to the admin server, and run:
displayTrustedInputConfig()
You can see that the default is set to 4000 (bytes, that is).
Use, the following commands to set the values you want:
configTrustedInputs(name="DEFAULT_HEADER",maxSize="12000")
configTrustedInputs(name="DEFAULT_PARAMETER",maxSize="12000")
configTrustedInputs(name="DEFAULT",maxSize="12000")
And restart the oam managed servers
Now, in this example I use 12000. But, you might want to take into consideration that a SPNEGO ticket has a max size of 12392 bytes. That is only the ticket! So, to rule out the oam managed server as a potential bottleneck, you might want to set this limit to 15000 or so, using some slack for overhead.
