On 20 Nov 2017, at 08:07, Clément OUDOT clem.oudot@gmail.com wrote:
option ldap-check option ssl-hello-chk
I’ve now had a chance to test both of these. Together and separate. Still no dice :( :(.
Dec 5 22:32:17 ldap50 slapd[786]: conn=1018 fd=23 ACCEPT from IP=<LOADBALANCER>:55807 (IP=<LDAP_SERVER>:636) Dec 5 22:32:17 ldap50 slapd[786]: conn=1018 fd=23 closed (TLS negotiation failure)
So the LB will never put the LDAP server online… Not sure why it gets TLS negotiation failure - I can search (on LDAPS) directly to the host from my workstation..
The SSL cert have both the CN with the FQDN of the host and a DNS value of the load balancer FQDN.
The haproxy config that OpenStack creates:
----- s n i p ----- # Configuration for lbaas-admin-auth-ldap global daemon user nobody group nogroup log /dev/log local0 log /dev/log local1 notice stats socket /var/lib/neutron/lbaas/v2/03090662-bac2-495f-8809-0d1e25b0bf21/haproxy_stats.sock mode 0666 level user
defaults log global retries 3 option redispatch timeout connect 5000 timeout client 50000 timeout server 50000
frontend 64d7db20-b245-4646-b94e-1e2e523c01d0 option tcplog bind <LOADBALANCER>:636 mode tcp default_backend 360d0c51-eb59-40b8-8c9a-fc3a3ff02822
backend 360d0c51-eb59-40b8-8c9a-fc3a3ff02822 mode tcp balance leastconn option ssl-hello-chk option ldap-check timeout check 5 server 96c97080-54be-406e-81e5-3bc50e1becdb LDAP_SERVER:636 weight 1 check inter 30s fall 5 ----- s n i p -----
HAProxy will, with these two options (ssl-hello-chk and ldap-check), say that there’s no servers available:
----- s n i p ----- Dec 5 22:39:17 OS_SRV haproxy[8864]: Server d6ed5563-3d54-4853-aafe-3c4fe7e6f409/92bcf829-36b4-417f-b50c-e93c83e29427 is DOWN, reason: Layer7 invalid response, info: "Not LDAPv3 protocol", check duration: 2ms. 2 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. Dec 5 22:39:17 OS_SRV haproxy[8864]: Server d6ed5563-3d54-4853-aafe-3c4fe7e6f409/92bcf829-36b4-417f-b50c-e93c83e29427 is DOWN, reason: Layer7 invalid response, info: "Not LDAPv3 protocol", check duration: 2ms. 2 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. Dec 5 22:39:23 OS_SRV haproxy[8864]: Server d6ed5563-3d54-4853-aafe-3c4fe7e6f409/60a60f15-0486-4305-a746-c9040bdafde2 is DOWN, reason: Layer7 invalid response, info: "Not LDAPv3 protocol", check duration: 2ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. Dec 5 22:39:23 OS_SRV haproxy[8864]: Server d6ed5563-3d54-4853-aafe-3c4fe7e6f409/60a60f15-0486-4305-a746-c9040bdafde2 is DOWN, reason: Layer7 invalid response, info: "Not LDAPv3 protocol", check duration: 2ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. Dec 5 22:39:29 OS_SRV haproxy[8864]: Server d6ed5563-3d54-4853-aafe-3c4fe7e6f409/c63c9f47-6f87-4f67-8c41-ab8d78e51761 is DOWN, reason: Layer7 invalid response, info: "Not LDAPv3 protocol", check duration: 2ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. Dec 5 22:39:29 OS_SRV haproxy[8864]: Server d6ed5563-3d54-4853-aafe-3c4fe7e6f409/c63c9f47-6f87-4f67-8c41-ab8d78e51761 is DOWN, reason: Layer7 invalid response, info: "Not LDAPv3 protocol", check duration: 2ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. Dec 5 22:39:29 OS_SRV haproxy[8864]: backend d6ed5563-3d54-4853-aafe-3c4fe7e6f409 has no server available! Dec 5 22:40:09 OS_SRV haproxy[8610]: 10.0.5.254:4049 [05/Dec/2017:22:40:09.436] 64d7db20-b245-4646-b94e-1e2e523c01d0 360d0c51-eb59-40b8-8c9a-fc3a3ff02822/<NOSRV> -1/-1/0 0 SC 0/0/0/0/0 0/0 ----- s n i p -----
Reading up on the options, these seems to be only for checking for online servers, not for “normal” communication. Since I can talk LDAPS with the servers both directly and via the load balancer (in both cases, as long as I don’t do KerberosV auth), this doesn’t seem to be the correct solution for me… ?
If I try to talk LDAPS + KRB5 auth directly to the server:
----- s n i p ----- ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context ----- s n i p -----
which is correct because of how Kerberos checks hosts, principals and host keys etc, but if I talk to the load balancer:
----- s n i p ----- ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) ----- s n i p -----
Now, this usually works “after a few hours” if I just leave it alone. This particular server is proving to be very obstinate..