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

[Scott Birl]

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.