Could you please remove this "pretent keepalive" option from your configuration and give it a try? HAProxy may close the connection because of it. And yes, a tcpdump between haproxy and the CAS server may help as well.
cheers On Fri, Feb 1, 2013 at 7:11 AM, Roland <r...@bayreuth.tk> wrote: > Hi Baptiste, > > thanks a lot! > > If I connect the same computer with the same account and unchanged settings > (except the URL of webaccess) directly to the CAS it works without any > problems. Connection is established immediately. > > I also verified with Microsoft Remote Connectivity Analyzer. It stops with > an error: > > ===== > Attempting to ping RPC proxy mc.nkd.com. > RPC Proxy can't be pinged. > > Additional Details > An HTTP 401 Unauthorized response was received from the remote > Unknown server. This is usually the result of an incorrect username or > password. If you are attempting to log onto an Office 365 service, ensure > you are using your full User Principal Name (UPN). > ===== > > All tests before (HTTP authentication methods, IIS configuration, SSL > credentials a.s.o.) are running fine. > > I'm absoultely clueless. > I think I'll try to narrow down the problem with tcpdump- maybe the > connection is forcably closed on some side. > > Cheers, > Roland > > > > > On Thu, 31 Jan 2013, Baptiste wrote: > >> 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 >>> >> >> >
