Dear piler users,
I'd like to describe an SSO related odd issue which affects both IE and
Outlook.
The problem is that when IE or Outlook are configured to use SSO, they
randomly
(based on my observation by a 1:10-20 ratio) send the ntlm
authorization data
with http requests not just to /sso.php, rather to any other URIs as
well.
The ngrep output for a problematic http query:
T 1.2.3.4:49229 -> 1.2.3.5:80 [AP]
POST /message.php HTTP/1.1..Accept: */*..Content-Type: app
lication/x-www-form-urlencoded; charset=UTF-8..X-Roundcube
-Request: undefined..X-Requested-With: XMLHttpRequest..Ref
erer: http://SERVER/search.php..Accept-Language:
hu,en-US;q=0.7,en;q=0.3..Accept-Encoding: gzip, deflate..U
ser-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6
.2; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; Microsoft Outl
ook 15.0.4420)..Host: SERVER..Content-Length: 0..
Connection: Keep-Alive..Cache-Control: no-cache..Cookie: s
plitter2=421; PHPSESSID=38jo8vdmvvfotqhivffsocgif3..Author
ization: NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAG
A4AlAAAADw==....
##
T 1.2.3.5:80 -> 1.2.3.4:49229 [AP]
HTTP/1.1 200 OK..Date: Mon, 15 Sep 2014 08:52:50 GMT..Serv
er: Apache/2.4.6 (CentOS) PHP/5.4.16..X-Powered-By: PHP/5.
4.16..Expires: Thu, 19 Nov 1981 08:52:00 GMT..Cache-Contro
l: no-store, no-cache, must-revalidate, post-check=0, pre-
check=0..Pragma: no-cache..Content-Length: 42..Keep-Alive:
timeout=5, max=100..Connection: Keep-Alive..Content-Type:
text/html; charset=UTF-8.....invalid id:
#
T 1.2.3.4:49229 -> 1.2.3.5:80 [A]
The trouble is that when they do so, then they fail to send the POST
parameters
with the http request. It results in "invalid id:" error messages when
/message.php
is affected (clicked on a messsage to view it in the preview pane), or
even
bogus search results, because instead of passing the search query to
/search.php,
it gets an empty parameter list, and hence return all messages.
If you get an "invalid id:" message, then you get the message by
clicking on the
message link again, but I admit it's pretty annoying and may mislead
users.
A valid post query should like like this (notice the absense of the
Authorization:
header, and the presence of the 'id' field):
T 1.2.3.4:49229 -> 1.2.3.5:80 [AP]
POST /message.php HTTP/1.1..Accept: */*..Content-Type: app
lication/x-www-form-urlencoded; charset=UTF-8..X-Roundcube
-Request: undefined..X-Requested-With: XMLHttpRequest..Ref
erer: http://SERVER/search.php..Accept-Language:
hu,en-US;q=0.7,en;q=0.3..Accept-Encoding: gzip, deflate..U
ser-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6
.2; WOW64; Trident/7.0; .NET4.0E; .NET4.0C; Microsoft Outl
ook 15.0.4420)..Host: SZERVER..Content-Length: 15.
.Connection: Keep-Alive..Cache-Control: no-cache..Cookie:
splitter2=421; PHPSESSID=38jo8vdmvvfotqhivffsocgif3....
#
T 1.2.3.4:49229 -> 1.2.3.5:80 [AP]
id=4992&search=
You are NOT affected if you
- use firefox or chrome
OR
- don't use SSO
I am trying to find some windows experts for help, and I hope someone
will come
up with a clue to solve this annoying issue. Until then unfortunately
IE / Outlook
with SSO is considered buggy.
I'll let you know if a solution / workaround is available.
Best regards,
Janos
