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..
Attachment:
signature.asc
Description: Message signed with OpenPGP