Hi, 401 is absolutely normal in NTLM. There are 2 or 3 request/response before the user is really authenticated when using NTLM. When HAProxy load-balances NTLM based services, the only log line you'll see will be 401 errors. Even if the connection works properly. This is due to the "tunnel" mode, which seems to be properly configured in your conf, as far as I can see. In tunnel mode, haproxy analyzes the first request, logs the first response, (hence the 401) and creates a tunnel between the client and the server. From now, on this connection, HAProxy will only transmit payload, even if that's HTTP, nothing will be analyzed anymore. The tunnel mode is mandatory for NTLM, because if you change TCP source port during the connection, it brakes the authentication.
Could you confirm your outlook session works? I mean that your client is well connected to your exchange server? I can confirm HAProxy works properly with Exchange 2010 and with 2013 as well. Cheers On Thu, Jan 31, 2013 at 4:13 PM, Roland <r...@bayreuth.tk> wrote: > Hi! > > I'm using haproxy 1.5dev17 and try to balance traffic destined for MS > Exchange 2010 CAS servers. > OWA and ActiveSync are working without any problems- but Outlook Anywhere > (RPC over HTTP with NTLM auth) produces an error 401 even with Microsofts > Remote Connectivity Analyzer. > > HAProxy runs in SSL offload mode. The cert is an officialy signed one. > My haproxy.conf is (partially): > ... > defaults > mode http > maxconn 50000 > contimeout 4000 > clitimeout 50000 > srvtimeout 50000 > balance roundrobin > log global > option tcplog > option redispatch > option contstats > option dontlognull > timeout connect 5s > timeout http-keep-alive 5s > timeout http-request 15s > timeout queue 30s > timeout client 300s > timeout server 300s > default-server inter 3s rise 2 fall 3 > backlog 10000 > option http-pretend-keepalive > > frontend WebAccess > maxconn 50000 > bind 172.17.336.433:666 ssl crt > /usr/local/etc/haproxy-certs/mc.dom.com.pem > mode http > option httplog > log global > no option httpclose > acl ACLRPC path_beg -i /rpc/rpcproxy.dll > use_backend OutlookAnywhere if ACLRPC > ... > > backend OutlookAnywhere > stick-table type ip size 10240k expire 60m > stick on src > cookie SRV insert nocache > balance roundrobin > option redispatch > server juno 172.17.336.433:80 cookie oasrv1 weight 1 check > ... > > The one active CAS server used for testing purposes (juno) is configured for > SSL offloading for RPC. All other Exchange directories in IIS are set to not > require SSL on this system. > > When running HAProxy in debug mode an Outlook Anywhere session looks like: > 00000005:WebAccess.clireq[000d:ffff]: RPC_IN_DATA > /Rpc/RpcProxy.dll?lips.dom.intl:6001 HTTP/1.1 > 00000005:WebAccess.clihdr[000d:ffff]: Accept: application/rpc > 00000005:WebAccess.clihdr[000d:ffff]: User-Agent: MSRPC > 00000005:WebAccess.clihdr[000d:ffff]: Authorization: NTLM > TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw== > 00000005:WebAccess.clihdr[000d:ffff]: Host: mc.dom.com > 00000005:WebAccess.clihdr[000d:ffff]: Content-Length: 0 > 00000005:OutlookAnywhere.srvrep[000d:000e]: HTTP/1.1 401 Unauthorized > 00000005:OutlookAnywhere.srvhdr[000d:000e]: Content-Type: text/html > 00000005:OutlookAnywhere.srvhdr[000d:000e]: Server: Microsoft-IIS/7.5 > 00000005:OutlookAnywhere.srvhdr[000d:000e]: WWW-Authenticate: NTLM > TlRMTVNTUAACAAAABgAGADgAAAAFgomiDMdfGnUDCJUAAAAAAAAAAGwAbAA+AAAABgGxHQAAAA9OAEsARAACAAYATgBLAEQAAQAIAEoAVQBOAE8ABAAQAG4AawBkAC4AaQBuAHQAbAADABoAagB1AG4AbwAuAG4AawBkAC4AaQBuAHQAbAAFABAAbgBrAGQALgBpAG4AdABsAAcACADUFzdfwP/NAQAAAAA= > 00000005:OutlookAnywhere.srvhdr[000d:000e]: WWW-Authenticate: Negotiate > 00000005:OutlookAnywhere.srvhdr[000d:000e]: X-Powered-By: ASP.NET > 00000005:OutlookAnywhere.srvhdr[000d:000e]: Date: Thu, 31 Jan 2013 14:36:35 > GMT > 00000005:OutlookAnywhere.srvhdr[000d:000e]: Content-Length: 58 > > I suspect NTLM to be the culprit. > Even after searching through all possible ressources I cannot find a > solution for this problem. As you can see in the config above I already > tried to implement some kind of keep-alive- with no success at all. > > If I bypass HAProxy or change HAProxy config to "mode tcp" everything is > fine. > > Have anyone had this kind of problem already? Or maybe some similar? > > Best regards, > Roland >
