[Xymon] Cannot issue STARTTLS for ldap:389 -- xymon server 4.3.28

[John Thurston]

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