That was indeed to trick: use the ldaps test against 389.

(surprised I didnt think of that beforehand!)

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.

Yes, I see what you're saying, and though the strace shows xymonnet reading in protocols.cfg, I didnt think it was ignoring it. Our :389 starts off in the clear, but then needs to be wrapped in starttls. I never did get a clear explanation on how this differs from their :636; I just know they want routine test results from both :389 and :636.

I did try just brain-dead "ldap" without any search parameters, but that too failed once the connection wasnt over TLS.

One thing I havent tried is an LDAPS test using :389 as the port: ldaps://10.96.160.XX:389/dc=DOMAIN,dc=ORG??sub?(uid=moof8) ldaplogin=cn=USER,ou=roles,dc=DOMAIN,dc=ORG:********* I'll give that a shot on one of the servers.

Thanks.