I'm setting up an SSO for Active Directory users through a website that runs on an Apache (Apache2 on SLES 11.1), and when testing with Firefox it all works fine. But when I try to open the website in Internet Explorer 8 (Windows 7), all I get is
"Bad Request
Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.
Authorization: Negotiate [ultra long string]"
My vhost.cfg looks like this:
<VirtualHost hostname:443>
LimitRequestFieldSize 32760
LimitRequestLine 32760
LogLevel debug
<Directory "/data/pwtool/sec-data/adbauth">
AuthName "Please login with your AD-credentials (Windows Account)"
AuthType Kerberos
KrbMethodNegotiate on
KrbAuthRealms REALM.TLD
KrbServiceName HTTP/hostname
Krb5Keytab /data/pwtool/conf/http_hostname.krb5.keytab
KrbMethodK5Passwd on
KrbLocalUserMapping on
Order allow,deny
Allow from all
</Directory>
<Directory "/data/pwtool/sec-data/adbauth">
Require valid-user
</Directory>
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/apache2/ssl.crt/hostname-server.crt
SSLCertificateKeyFile /etc/apache2/ssl.key/hostname-server.key
</VirtualHost>
I also made sure that the cookies are deleted and tried several smaller values for LimitRequestFieldSize and LimitRequestLine.
Another thing that seems weird to me is that even with LogLevel debug I won't get any logs about this. The log's last line is
ssl_engine_kernel.c(1879): OpenSSL: Write: SSL negotiation finished successfully
Does anyone have an idea about that?
My gut says you've got a very large security token, possibly because the user is a member of a large number of groups. The AD Kerberos implementation is going to provide Apache with a Privilege Attribute Certificate (PAC) by default. This structure can be large if the user is a member of a significant number of groups. You can use the
tokensz.exe
tool to see the user's token size.If this is the problem you can modify the UserAccountControl attribute of the user's account to prevent the PAC from being sent.
You may be able to get away with modifying your
/etc/krb5.conf
file to reference the KDC askdc = tcp/kdc.name.here
. This problem can occur if the PAC causes the token to be too large for a UDP datagram, but forcing the communication to the KDC with TCP is a possible workaround, too.Changing that value on 1,000 users isn't difficult for your AD admins if it solves your problem.
I found another solution, though I'm not sure if it really works. Apache Docs states that for big packages I'll have to set LimitRequestFieldSize and/or LimitRequestLine .
The thing is that if you want to set the value of LimitRequestLine to anything higher than 8KB then you'll have to modify the source and recompile Apache, as 8KB is the fixed maxSize (http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestline).
I don't know for sure if this method works, because I reinstalled apache from our own repository on a second server later. It seems that this was a different package version as the problem didn't occur there.
I had this error happening on a Drupal 7 site in Safari on Mac and found that closing the browser windows and clearing the cache of the browser, quitting the browser, opening it back up and reloading the page worked to discontinue the error which has only happened this one time.
In case anyone hits this problem with mod_proxy_ajp, take a look at: From which Apache version onward is LimitRequestFieldSize no longer hardcoded to 8k max?