Hi Matt, The issue with LDAP, is that it is not a banner protocol. So either you check the TCP port is well bound on the server for a simple L4 check, for L7, you don't have the choice, you must send a message and check the server's result.
Baptiste On Tue, Mar 31, 2015 at 9:53 AM, Matt . <yamakasi....@gmail.com> wrote: > I'm also testing some ldap checks but I see lots of logging and log > partitions filling up like crazy. > > I wonder if it's really doable to check the ldap status in in a gracefull way. > > 2015-03-31 9:45 GMT+02:00 Neil - HAProxy List > <maillist-hapr...@iamafreeman.com>: >> Hello >> >> I was thinking of updating the ldap-check but I think I've a better idea. >> Macros (well ish). >> >> send-binary 300c0201 # LDAP bind request "<ROOT>" simple >> send-binary 01 # message ID >> send-binary 6007 # protocol Op >> send-binary 0201 # bind request >> send-binary 03 # LDAP v3 >> send-binary 04008000 # name, simple authentication >> expect binary 0a0100 # bind response + result code: success >> send-binary 30050201034200 # unbind request >> >> could be in a file named macros/ldap-simple-bind >> >> then the option >> tcp-check-macro ldap-simple-bind >> >> would use it, I know this is close to includes. >> >> similarly macros/smtp-helo-quit >> connect port 25 >> expect rstring ^220 >> send QUIT\r\n >> expect rstring ^221 >> >> >> or from >> http://blog.haproxy.com/2014/06/06/binary-health-check-with-haproxy-1-5-php-fpmfastcgi-probe-example/ >> # FCGI_BEGIN_REQUEST >> send-binary 01 # version >> send-binary 01 # FCGI_BEGIN_REQUEST >> send-binary 0001 # request id >> send-binary 0008 # content length >> send-binary 00 # padding length >> send-binary 00 # >> send-binary 0001 # FCGI responder >> send-binary 0000 # flags >> send-binary 0000 # >> send-binary 0000 # >> # FCGI_PARAMS >> send-binary 01 # version >> send-binary 04 # FCGI_PARAMS >> send-binary 0001 # request id >> send-binary 0045 # content length >> send-binary 03 # padding length: padding for content % 8 = 0 >> send-binary 00 # >> send-binary 0e03524551554553545f4d4554484f44474554 # REQUEST_METHOD = GET >> send-binary 0b055343524950545f4e414d452f70696e67 # SCRIPT_NAME = /ping >> send-binary 0f055343524950545f46494c454e414d452f70696e67 # SCRIPT_FILENAME >> = /ping >> send-binary 040455534552524F4F54 # USER = ROOT >> send-binary 000000 # padding >> # FCGI_PARAMS >> send-binary 01 # version >> send-binary 04 # FCGI_PARAMS >> send-binary 0001 # request id >> send-binary 0000 # content length >> send-binary 00 # padding length: padding for content % 8 = 0 >> send-binary 00 # >> >> expect binary 706f6e67 # pong >> >> (though for items like >> send-binary 0e03524551554553545f4d4554484f44474554 # REQUEST_METHOD = GET >> I'd prefer a >> send-as-binary "REQUEST_METHOD = GET" >> ) >> >> these and many others could be shipped with haproxy. >> >> this seems to make sense to me as they are small contained logical items >> >> Neil >> >> >> On 30 March 2015 at 23:02, Baptiste <bed...@gmail.com> wrote: >>> >>> you should believe it :) >>> >>> On Mon, Mar 30, 2015 at 11:34 PM, Neil - HAProxy List >>> <maillist-hapr...@iamafreeman.com> wrote: >>> > Hello >>> > >>> > Thanks so much. That worked well, I now get >>> > L7OK/0 in 0ms >>> > not sure I believe the 0ms but maybe I should >>> > >>> > Thanks again, >>> > >>> > Neil >>> > >>> > On 30 March 2015 at 22:14, Baptiste <bed...@gmail.com> wrote: >>> >> >>> >> On Mon, Mar 30, 2015 at 10:33 PM, Neil - HAProxy List >>> >> <maillist-hapr...@iamafreeman.com> wrote: >>> >> > Hello >>> >> > >>> >> > I'm trying to use ldap-check with active directory and the response >>> >> > active >>> >> > directory gives is not one ldap-check is happy to accept >>> >> > >>> >> > when I give a 389 directory backend ldap server all is well, when I >>> >> > use >>> >> > AD I >>> >> > get 'Not LDAPv3 protocol' >>> >> > >>> >> > I've done a little poking about and found that >>> >> > if ((msglen > 2) || >>> >> > (memcmp(check->bi->data + 2 + msglen, >>> >> > "\x02\x01\x01\x61", 4) != 0)) { >>> >> > set_server_check_status(check, >>> >> > HCHK_STATUS_L7RSP, "Not LDAPv3 protocol"); >>> >> > is where I'm getting stopped as msglen is 4 >>> >> > >>> >> > Here is tcpdump of 389 directory response (the one that works) 2 >>> >> > packets >>> >> > 21:29:34.195699 IP 389.ldap > HAPROXY.57109: Flags [.], ack 15, win >>> >> > 905, >>> >> > options [nop,nop,TS val 856711882 ecr 20393440], length 0 >>> >> > 0x0000: 0050 5688 7042 0064 403b 2700 0800 4500 >>> >> > .PV.pB.d@;'...E. >>> >> > 0x0010: 0034 9d07 4000 3f06 3523 ac1b e955 ac18 >>> >> > .4..@.?.5#...U.. >>> >> > 0x0020: 2810 0185 df15 5cab ffcd 63ba 77d3 8010 >>> >> > (.....\...c.w... >>> >> > 0x0030: 0389 2c07 0000 0101 080a 3310 62ca 0137 >>> >> > ..,.......3.b..7 >>> >> > 0x0040: 2de0 -. >>> >> > 21:29:34.195958 IP 389.ldap > HAPROXY.57109: Flags [P.], seq 1:15, >>> >> > ack >>> >> > 15, >>> >> > win 905, options [nop,nop,TS val 856711882 ecr 20393440], length 14 >>> >> > 0x0000: 0050 5688 7042 0064 403b 2700 0800 4500 >>> >> > .PV.pB.d@;'...E. >>> >> > 0x0010: 0042 9d08 4000 3f06 3514 ac1b e955 ac18 >>> >> > .B..@.?.5....U.. >>> >> > 0x0020: 2810 0185 df15 5cab ffcd 63ba 77d3 8018 >>> >> > (.....\...c.w... >>> >> > 0x0030: 0389 e878 0000 0101 080a 3310 62ca 0137 >>> >> > ...x......3.b..7 >>> >> > 0x0040: 2de0 300c 0201 0161 070a 0100 0400 0400 >>> >> > -.0....a........ >>> >> > >>> >> > Here is tcpdump of active directory (broken) 1 packet >>> >> > >>> >> > 21:25:24.519883 IP ADSERVER.ldap > HAPROXY.57789: Flags [P.], seq >>> >> > 1:23, >>> >> > ack >>> >> > 15, win 260, options [nop,nop,TS val 1870785 ecr 20331021], length 22 >>> >> > 0x0000: 0050 5688 7042 0050 5688 7780 0800 4500 >>> >> > .PV.pB.PV.w...E. >>> >> > 0x0010: 004a 1d7d 4000 8006 34e3 ac18 280d ac18 >>> >> > .J.}@...4...(... >>> >> > 0x0020: 2810 0185 e1bd 5a3f 2ae7 3ced 7b5b 8018 >>> >> > (.....Z?*.<.{[.. >>> >> > 0x0030: 0104 1d7a 0000 0101 080a 001c 8bc1 0136 >>> >> > ...z...........6 >>> >> > 0x0040: 3a0d 3084 0000 0010 0201 0161 8400 0000 >>> >> > :.0........a.... >>> >> > 0x0050: 070a 0100 0400 0400 >>> >> > >>> >> > this was discussed but not finished before see >>> >> > http://www.serverphorums.com/read.php?10,394453 >>> >> > >>> >> > I can see the string \02\01\01\61 is there but not in the correct >>> >> > place >>> >> > >>> >> > Anyone have any ideas about fixing this so that both (and possibly >>> >> > other) >>> >> > ldap implementations work? >>> >> > >>> >> > Thanks, >>> >> > >>> >> > Neil >>> >> >>> >> >>> >> Hi Neil >>> >> >>> >> Yes you can switch to the tcp-check checking method. >>> >> I works with binary protocols as well. >>> >> Here is what I use for the AD in my lab: >>> >> >>> >> option tcp-check >>> >> tcp-check connect port 389 >>> >> tcp-check send-binary 300c0201 # LDAP bind request "<ROOT>" simple >>> >> tcp-check send-binary 01 # message ID >>> >> tcp-check send-binary 6007 # protocol Op >>> >> tcp-check send-binary 0201 # bind request >>> >> tcp-check send-binary 03 # LDAP v3 >>> >> tcp-check send-binary 04008000 # name, simple authentication >>> >> tcp-check expect binary 0a0100 # bind response + result code: success >>> >> tcp-check send-binary 30050201034200 # unbind request >>> >> >>> >> >>> >> You could add the same sequence for LDAPs on port 636: >>> >> tcp-check connect port 636 ssl >>> >> tcp-check send-binary 300c0201 # LDAP bind request "<ROOT>" simple >>> >> tcp-check send-binary 01 # message ID >>> >> tcp-check send-binary 6007 # protocol Op >>> >> tcp-check send-binary 0201 # bind request >>> >> tcp-check send-binary 03 # LDAP v3 >>> >> tcp-check send-binary 04008000 # name, simple authentication >>> >> tcp-check expect binary 0a0100 # bind response + result code: success >>> >> tcp-check send-binary 30050201034200 # unbind request >>> >> >>> >> >>> >> Note for myself: put this tip on the blog.. >>> >> >>> >> Baptiste >>> > >>> >
