On 6/1/2018 8:44 AM, Scott Birl wrote:
Hello all:
Running the 4.3.28 server.
My LDAP team wants me to monitor their LDAP farm over both 636 *and* 389. Monitoring 636 is working as expected, but 389 is not; at least not 100%. ServerA's 389 has not required the use of STARTTLS, yet, so monitoring it is working well. ServerB's 389 is requiring the use of STARTTLS, and tests are failing red with an output of "unknown error."
(Yes, there are applications outside of Xymon that can connect to 389 using STARTTLS with no problem.)I modified ~xymon/server/etc/protocols.cfg to have the [ldap] section to use "options ssl", but my LDAP team tells me that STARTTLS is not present, and tests are still red.
I ran: strace ~xymon/server/bin/xymonnet --debug --report ServerB and I can see the connection being made, as well as the ldaplogin bind credentials being passed over, but certainly no STARTTLS is being passed.
On the receiving end of the strace, I see: read(3, "\1\r\4\0\4\30confidentiality required", 30) = 30 write(1, "101588 2018-06-01 11:52:08.27042"..., 81101588 2018-06-01 11:52:08.270421 ldap_result returned 97 for ldap_simple_bind()) = 81 followed by the "LDAP output: Unknown error"
The hosts.cfg has this entry for its LDAP tests for ServerA and ServerB. ldap://10.96.160.XX:389/dc=DOMAIN,dc=ORG??sub?(uid=moof8) ldaplogin=cn=USER,ou=roles,dc=DOMAIN,dc=ORG:*********
Is there something that I am missing in order to have Xymon issue a STARTTLS for 389?
If you want a STARTTLS, I think you should be using the ldaps test:
0.0.0.0 serverA.bar.com # ldap://blah blah blah 0.0.0.0 serverB.bar.com # ldaps://blah blah blah
The ldap tests in xymonnet have always been a point of confusion for me, but I recall finding there are two different tests. The first is specified by test:port syntax: 0.0.0.0 foo.bar.com # ldap:399 0.0.0.0 baz.bar.com # ldaps:666 This test uses the lines in protocols.cfg and is pretty brain-dead.
The second test is specified by URL syntax: 0.0.0.0 foo.bar.com # ldap://foo.bar.com:399/blah blah blah 0.0.0.0 baz.bar.com # ldaps://baz.bar.com:666/blah blah blah This test ignores everything in protocols.cfg, but still reports under the ldap column.
The use of ldap/ldaps strings to name both tests caused me all kinds of confusion. I eventually evaded this by creating my own protocol.cfg (and referencing it in the stock file). It contains the the following:
[ldap|ldapPort] port 389
[ldaps|ldapsPort] options ssl port 636
This redefines the stock ldap/ldaps tests, but defines an alias for each of them. When I want the brain-dead test, I use the alias of my own creation. In my hosts.cfg, I have lines like
0.0.0.0 foo.bar.com # ldapPort:389 ldapsPort:667 ldaps://foo.bar.com:667/blah blah blah
Which gives the three columns. I can see the results of the query under the 'ldap' column. I can also see if ldap or ldaps brain-dead connections are working.
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska