IE 11 / Outlook 2013 furcsa single sign-on / ntlm auth-tal kapcsolatos anomaliak

2 gepunk van, az egyiken (KLIENS) (64-bites) IE 11 ill. Outlook 2013 fut. A masik gep (SZERVER) egy centos 7, amin egy apache 2.4 website sso-val enged belepni (auth_ntlm_winbind_module es winbindd segitsegevel) a kovetkezo modon: a kliensek (IE 11 es Outlook 2013) a SZERVERen levo /sso.php cimen landolnak, ahol az apache ugy van konfiguralva, hogy csak a /sso.php-ra erkezo keresekhez igenyel authentikaciot. Amikor a kliens meglatogatta /sso.php-t, akkor kap egy session-t, amibe bekerulnek kulonfele adatai, es mehet a site tovabbi oldalaira, ahol a SZERVER mar a session valtozokat figyeli, es az sso adatok nem erdesek tobbe. Eddig koser a dolog.

A .htaccess file igy nez ki:

DirectoryIndex index.php

RewriteEngine On
<par rewrite rule>

<IfModule auth_ntlm_winbind_module>
<FilesMatch "sso\.php$">
AuthName "NTLM authentication"
NTLMAuth on
NTLMAuthHelper "/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp"
NTLMBasicAuthoritative on
AuthType NTLM
require valid-user
</FilesMatch>
</IfModule>

Viszont azt tapasztalom az IE11 ill. Outlook 2013 eseten, hogy random esetekben, amikor a /xxxxxxxx.php uri-t hivja meg, akkor az alabbit kapom (ngrep kimenet):

T 1.2.3.4:49229 -> 1.2.3.5:80 [AP]
POST /xxxxxxx.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://SZERVER/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: 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]
......

Na most a problema csak annyi, hogy az apache nem mondta az Outlook 2013-nak, hogy az /xxxxxxxx.php lekerdezesekor is authorizalni kellene. De nem is ez okozza a gondot, hanem az, hogy amikor az Outlook 2013 elkuldi az NTLM parbeszedhez szukseges dumat, akkor nem hajlando elkuldeni egyuttal POST adatokat is kuldeni (amire pedig jquery-bol szepen kertem).

A http://SZERVER szerepel az IE Internet Options -> Security -> Local sites listaban az sso vegett.

Normal esetben a kliens ilyesmi http kerest kuld:

T 1.2.3.4:49229 -> 1.2.3.5:80 [AP]
POST /xxxxxxx.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://SZERVER/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=

amire rendben meg is erkezik a korrekt valasz. Teljesen veletlenszeru, hogy mikor kuld autorizacios adatokat, es mikor nem. Kb. 1:10-20 az arany, azonban a felhasznalokat nagyon meg tudja zavarni, hogy kattint es hibat kap (mivel nincsenek POST adatok), majd ugyanoda kattint ujra, es kap valaszt (mert elmennek a POST adatok). Meg annyi, hogy mas bongeszokkel (Chrome, Firefox) hibatlanul mukodik a dolog.

A kerdes az, hogy merre induljak el?

update: eddig ez a cim tunik a legrelevansabbnak: http://stackoverflow.com/questions/4796305/why-does-internet-explorer-n…

Talan megvan a megoldas: You cannot post data to a non-NTLM-authenticated Web site. Egy registry hack + IE options turkalas kell hozza.