I am trying to set up SSO for the web interface for our MicroStrategy implementation. We have a desktop app that is using SSO successfully. But when we try to access MicroStrategy through the browser, we get the HTTP 400 error.

So far, I have found all the "fixes" about setting the LimitRequestFieldSize and LimitRequetLine in the httpd.conf file, I've tried setting the maxHttpdHeaderSize in server.xml and I've changed registry settings MaxFieldLength and MaxRequestBytes under HKLM\System\CCS\services\HTTP\paramters as well as the MaxTokenSize under HKLM\System\CCS\Control\Lsa\Kerberos\Parameters.

I have verified that the kerberos ticket is less than 4k, so the size of the ticket shouldn't be an issue.

Nothing seems to prevent me from getting this error.

Is there anyone who might have some ideas as to where I can go from here to figure out where the problem lies? Any thoughts ideas or suggestions would be welcome as I have pretty much exhausted everything I've found in Google, Red Hat, MicroStrategy and pretty much every other resource I could think of.

If anyone has any ideas or needs to see any snippets of config files, I can post those.

Thanks in advance!!

I would be interested to see what is in the actual http header. Have you tried using something like tamper data or another add-on to be able to view your HTTP headers as they are sent back to the server. Sounds like it may be a scripting problem generating too big of a request but thats just a guess.

Thanks...I'll see if I can run a Fiddler trace and get that info. I'm abstaining from that environment during business hours for the most part as users are accessing it, but I'll run a trace and share what I find.

Thanks!!!

Ok...so hopefully I did this correctly. (I'm rather new to Fiddler and all this tracing stuff). According to Fiddler, it looks like the header information is as follows:

GET /MicroStrategy/servlet/mstrWeb HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; InfoPath.2; MS-RTC LM 8)
Accept-Encoding: gzip, deflate
Host: microstrategy.qa.domain.com
Connection: Keep-Alive
Authorization: Negotiate YII<snip>
Cookie: JSESSIONID=A2F6F33121C1163336DF9988F7D7402B

The part I snipped out was the rest of the Authorization string after the YII. I wasn't sure it was wise to post the actual string on a public forum. However, since the string was somewhat lengthy, I copied/pasted it into Word to get an exact character count.

The string, including the YII, according to Word is 10,232 characters.

Update....

Our current AD domain was migrated from an old domain. We noticed that one result of this was that many of our users and groups in AD still had a SID history from the previous domain.

We created a test user and added it to groups that did not have any SID history and we were able to add the user in to over 100 groups without any Bad Request errors.

The next step will be to verify that old SIDs are no longer needed and remove the SID history from all users and groups.

Unfortunately, I was not able to capture the header size on the test system (didn't have the tools). Perhaps I'll see if I can get Fiddler installed and check the header size against the 10k size from my production system.

Looks like the SID history was the culprit. After removing SID history from my user and associated groups, I am able to use SSO for internal web pages.

Thanks for all your help!! Much appreciated.