OAM Windows Native Authentication Fails with Some Users

So you have OAM configured with Windows Native Authentication and it appears to be working well most of the time. However, some users receive the dreaded “HTTP 400 Bad Request” screen on the /oam/CredCollectServlet/WNA url:

Refreshing the page works. In fact, WNA works flawlessly 99% of the time, but for some users, especially senior users, it doesn’t. This is clearly unacceptable.

You scratch your head and check OAM’s logs and find nothing. You check the browser headers, up the log level, you check everything and still find nothing. The user is clearly getting logged into OAM, because when you refresh it works, but something is happening that is generating a 400 error and you can’t figure out what.

Check the problematic users’ groups in AD. Are those users members of an abnormally large number of groups? If so, you may have found the issue.

Chances are you are using an OHS or Apache reverse proxy. What is happening is that the encrypted SPNEGO token for the users with too many groups is too large for OHS to handle. OHS is truncating the token in the header and thus generating a 400 Bad Request error when moving from OAM to OHS after authentication. 

The fix is simple: You need to increase the limit of the size of the HTTP header allowed by OHS. How do we do that? With the LimitRequestFieldSize directive in the OHS config.

By default, the limit is 8190 bytes. SPNEGO authentication headers can be up to 12392 bytes in size. Simply add the following line in your server config or virtual host context in your OHS http.conf or appropriate conf files:

LimitRequestFieldSize 12392

Restart OHS. And you will never see a 400 Bad Request error via Windows Native Authentication ever again. 

 

Questions, comments or concerns? Feel free to reach out to us below or at IDMWORKS