Re: SSL offloading with NTLM auth
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 modehttp maxconn 5 contimeout 4000 clitimeout 5 srvtimeout 5 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 1 option http-pretend-keepalive frontendWebAccess maxconn 5 bind172.17.336.433:666 ssl crt /usr/local/etc/haproxy-certs/mc.dom.com.pem modehttp 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: 0005:WebAccess.clireq[000d:]: RPC_IN_DATA /Rpc/RpcProxy.dll?lips.dom.intl:6001 HTTP/1.1 0005:WebAccess.clihdr[000d:]: Accept: application/rpc 0005:WebAccess.clihdr[000d:]: User-Agent: MSRPC 0005:WebAccess.clihdr[000d:]: Authorization: NTLM TlRMTVNTUAABB4IIogAGAbEdDw== 0005:WebAccess.clihdr[000d:]: Host: mc.dom.com 0005:WebAccess.clihdr[000d:]: Content-Length: 0 0005:OutlookAnywhere.srvrep[000d:000e]: HTTP/1.1 401 Unauthorized 0005:OutlookAnywhere.srvhdr[000d:000e]: Content-Type: text/html 0005:OutlookAnywhere.srvhdr[000d:000e]: Server: Microsoft-IIS/7.5 0005:OutlookAnywhere.srvhdr[000d:000e]: WWW-Authenticate: NTLM
Re: SSL offloading with NTLM auth
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 modehttp maxconn 5 contimeout 4000 clitimeout 5 srvtimeout 5 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 1 option http-pretend-keepalive frontendWebAccess maxconn 5 bind172.17.336.433:666 ssl crt /usr/local/etc/haproxy-certs/mc.dom.com.pem modehttp 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: 0005:WebAccess.clireq[000d:]: RPC_IN_DATA /Rpc/RpcProxy.dll?lips.dom.intl:6001 HTTP/1.1 0005:WebAccess.clihdr[000d:]: Accept: application/rpc 0005:WebAccess.clihdr[000d:]: User-Agent: MSRPC 0005:WebAccess.clihdr[000d:]: Authorization: NTLM TlRMTVNTUAABB4IIogAGAbEdDw== 0005:WebAccess.clihdr[000d:]: Host: mc.dom.com 0005:WebAccess.clihdr[000d:]: Content-Length: 0 0005:OutlookAnywhere.srvrep[000d:000e]: HTTP/1.1 401 Unauthorized 0005:OutlookAnywhere.srvhdr[000d:000e]: Content-Type: text/html 0005:OutlookAnywhere.srvhdr[000d:000e]: Server: Microsoft-IIS/7.5 0005:OutlookAnywhere.srvhdr[000d:000e]: WWW-Authenticate: NTLM TlRMTVNTUAACBgAGADgFgomiDMdfGnUDCJUAAGwAbAA+BgGxHQ9OAEsARAACAAYATgBLAEQAAQAIAEoAVQBOAE8ABAAQAG4AawBkAC4AaQBuAHQAbAADABoAagB1AG4AbwAuAG4AawBkAC4AaQBuAHQAbAAFABAAbgBrAGQALgBpAG4AdABsAAcACADUFzdfwP/NAQA= 0005:OutlookAnywhere.srvhdr[000d:000e]: WWW-Authenticate: Negotiate 0005:OutlookAnywhere.srvhdr[000d:000e]: X-Powered-By: ASP.NET 0005:OutlookAnywhere.srvhdr[000d:000e]: Date: Thu, 31 Jan 2013 14:36:35 GMT 0005: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
Re: SSL offloading with NTLM auth
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 modehttp maxconn 5 contimeout 4000 clitimeout 5 srvtimeout 5 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 1 option http-pretend-keepalive frontendWebAccess maxconn 5 bind172.17.336.433:666 ssl crt /usr/local/etc/haproxy-certs/mc.dom.com.pem modehttp 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: 0005:WebAccess.clireq[000d:]: RPC_IN_DATA /Rpc/RpcProxy.dll?lips.dom.intl:6001 HTTP/1.1 0005:WebAccess.clihdr[000d:]: Accept: application/rpc 0005:WebAccess.clihdr[000d:]: User-Agent: MSRPC 0005:WebAccess.clihdr[000d:]: Authorization: NTLM TlRMTVNTUAABB4IIogAGAbEdDw== 0005:WebAccess.clihdr[000d:]: Host: mc.dom.com 0005:WebAccess.clihdr[000d:]: Content-Length: 0 0005:OutlookAnywhere.srvrep[000d:000e]: HTTP/1.1 401 Unauthorized 0005:OutlookAnywhere.srvhdr[000d:000e]: Content-Type: text/html 0005:OutlookAnywhere.srvhdr[000d:000e]: Server: Microsoft-IIS/7.5 0005:OutlookAnywhere.srvhdr[000d:000e]: WWW-Authenticate: NTLM TlRMTVNTUAACBgAGADgFgomiDMdfGnUDCJUAAGwAbAA+BgGxHQ9OAEsARAACAAYATgBLAEQAAQAIAEoAVQBOAE8ABAAQAG4AawBkAC4AaQBuAHQAbAADABoAagB1AG4AbwAuAG4AawBkAC4AaQBuAHQAbAAFABAAbgBrAGQALgBpAG4AdABsAAcACADUFzdfwP/NAQA= 0005:OutlookAnywhere.srvhdr[000d:000e]: WWW-Authenticate: Negotiate 0005:OutlookAnywhere.srvhdr[000d:000e]: X-Powered-By: ASP.NET
