bug in ldaptest.c 🔗 link

So it appears that there's a bug in part of the ldap testing code.

---
bbnet/ldaptest.c (lines 85-86)
                 dbgprintf("Forcing port %d for ldaps with STARTTLS\n", LDAP_PORT );
                 ludp->lud_port = LDAP_PORT;
---

Even if you're attempting an ldaps test with a specified port, the test is still only performing a 
389 port test. I changed LDAP_PORT to LDAPS_PORT and recompiled, then tried an ldaps test again, 
however now it just doesn't appear to connect.

---
2010-08-27 16:06:45 Opening file /home/xymon/server/etc/bb-hosts
2010-08-27 16:06:45 Adding hostname 'x.x.x.x' to resolver queue
2010-08-27 16:06:45 Processing 1 DNS lookups with ARES
2010-08-27 16:06:45 Got DNS result for host x.x.x.x : 10.x.x.x
2010-08-27 16:06:45 Finished ARES queue after loop 2
2010-08-27 16:06:45 Concurrency evaluation: rlim_cur=1024, FD_SETSIZE=0, absmax=1024, initial=1014
2010-08-27 16:06:45 About to do 0 TCP tests running 256 in parallel, abs.max 1014
2010-08-27 16:06:45 TCP tests completed normally
2010-08-27 16:06:45 Forcing port 636 for ldaps with STARTTLS
2010-08-27 16:06:45 Initiating LDAP session for host x.x.x.x port 636
2010-08-27 16:06:45 Attempting to select LDAPv3
2010-08-27 16:06:45 Trying to enable TLS for session
2010-08-27 16:06:55 ldap_start_tls failed
URL        : ldaps://x.x.x.x/ou=people,dc=x,dc=x,dc=x?dn?sub?uid=healthcheck
Time spent : 0.00
LDAP output:
Can't contact LDAP server
---

The server I'm running the test against is Sun Directory 6.2, so should this test work, or should I 
give up and just use an external script for my ldaps testing?

Matthew,

STARTTLS uses the normal ldap port rather than the ssl port. The initial
handshake is done in clear text then the connection is 'upgraded' to ssl
using the STARTTLS command within the original TCP connection.

I'm not sure how you tell Xymon to not use STARTTLS and instead use the
SSL port. From a quick look at the surrounding code it doesn't look very
obvious to me.

Actually, looking at the documentation I see:
	...LDAP server that use the older non-standard method of
tunnelling LDAP through SSL on port 636 will not work.

So it looks like the best you could do is check that the port is open
and listening.

Brian

-----Original Message-----
From: Epp, Matthew Mr CTR USA USA [mailto:user-c07bdcff406c@xymon.invalid] 
Sent: Tuesday, 31 August 2010 3:25 AM
To: xymon at xymon.com
Subject: [xymon] bug in ldaptest.c

So it appears that there's a bug in part of the ldap testing code.

---
bbnet/ldaptest.c (lines 85-86)
                 dbgprintf("Forcing port %d for ldaps with STARTTLS\n",
LDAP_PORT );
                 ludp->lud_port = LDAP_PORT;
---

Even if you're attempting an ldaps test with a specified port, the test
is still only performing a
389 port test. I changed LDAP_PORT to LDAPS_PORT and recompiled, then
tried an ldaps test again, however now it just doesn't appear to
connect.

---
2010-08-27 16:06:45 Opening file /home/xymon/server/etc/bb-hosts
2010-08-27 16:06:45 Adding hostname 'x.x.x.x' to resolver queue
2010-08-27 16:06:45 Processing 1 DNS lookups with ARES
2010-08-27 16:06:45 Got DNS result for host x.x.x.x : 10.x.x.x
2010-08-27 16:06:45 Finished ARES queue after loop 2
2010-08-27 16:06:45 Concurrency evaluation: rlim_cur=1024, FD_SETSIZE=0,
absmax=1024, initial=1014
2010-08-27 16:06:45 About to do 0 TCP tests running 256 in parallel,
abs.max 1014
2010-08-27 16:06:45 TCP tests completed normally
2010-08-27 16:06:45 Forcing port 636 for ldaps with STARTTLS
2010-08-27 16:06:45 Initiating LDAP session for host x.x.x.x port 636
2010-08-27 16:06:45 Attempting to select LDAPv3
2010-08-27 16:06:45 Trying to enable TLS for session
2010-08-27 16:06:55 ldap_start_tls failed
URL        :
ldaps://x.x.x.x/ou=people,dc=x,dc=x,dc=x?dn?sub?uid=healthcheck
Time spent : 0.00
LDAP output:
Can't contact LDAP server
---

The server I'm running the test against is Sun Directory 6.2, so should
this test work, or should I give up and just use an external script for
my ldaps testing?


**********************************************************************

This message is intended for the addressee named and may contain
privileged information or confidential information or both. If you
are not the intended recipient please delete it and notify the sender.
**********************************************************************

On Tuesday, 31 August 2010 07:18:01 Scott, Brian wrote:

[...]

ldaps isn't a standardised (RFC) LDAP feature, whereas STARTTLS is. I assume 
this could be a reason why Henrik initially didn't implement ldaps support, 
instead using ldaps:// to indicate STARTTLS.

We can consider implementing real ldaps support, but then we would need a 
different way to request STARTTLS support in ldap:// URLs in bb-hosts.

I will try and look at this, but to make sure it doesn't get lost, please log 
an feture request SF tracker (there is a link on 
http://sourceforge.net/projects/xymon/support).

Regards,
Buchan

In <user-ab481b8898d2@xymon.invalid> Buchan Milne <user-9b139aff4dec@xymon.invalid> writes:

The major problem with this is that Xymon uses the OpenLDAP library
to talk to the LDAP server (the LDAP protocol itself is a bit too
complex for Xymon to do on its own). And OpenLDAP only supports the
RFC-way of doing SSL.


Regards,
Henrik

On Thursday, 23 September 2010 14:18:51 Henrik "Størner" wrote:

<user-9b139aff4dec@xymon.invalid> writes:

This isn't true. Almost all LDAP client software (pam_ldap, nss_ldap, samba, freeradius, ldapsearch etc., apache mod_ldap, etc., to name a few) using OpenLDAP libldap (at least with OpenSSL, I'm not too familiar with OpenLDAP+gnutls) supports original Netscape-style ldaps (which is usually on port 636).

I can look at fixing this, but we need to decide if we are going to change to interpreting ldaps really as ldaps://, and how to distinguish ldap:// with STARTTLS.

Regards,
Buchan

In <user-e04c2c27b8a9@xymon.invalid> Buchan Milne <user-9b139aff4dec@xymon.invalid> writes:

,=20
freeradius, ldapsearch etc., apache mod_ldap, etc., to name a few) using=20
OpenLDAP libldap (at least with OpenSSL, I'm not too familiar with=20
OpenLDAP+gnutls) supports original Netscape-style ldaps (which is usually o=
n=20
port 636).

Okay, I haven't looked at OpenLDAP since I implemented the LDAP tests
(quite some time ago). The SSL support then wasn't documented at all,
so I had to go by some sample code included with the library. If that
has changed and we can support port-636-ldaps somehow then sure - let's
do it. We probably need to invent a different tag in bb-hosts for it,
but that's a minor problem.


Regards,
Henrik

On Sep 27, 2010, at 3:58 PM, Henrik Størner wrote:

I think when most people see “ldaps”, they think port 636. Before this thread came along, I thought that's what the test was doing.

What about a new tag (rename) for the port-389-with-TLS option instead? Just my two cents.

-- 
Rob McBroom
<http://www.skurfer.com/>;

For the Windows client, MrBig, has anyone fooled around with the rules
for parsing the log files? We have a "MIMEsweeper log" that just cannot
figure out syntax to suppress false alerts.

There is a DNS lookup error that we do not regard as fatal so have tried
variations in the mrbig.cfg file of the following entries -

ignore source MIMEsweeper log		# ignore the log file
ignore source "MIMEsweeper log"
ignore message DNS			# ignore any event with DNS in
body

Bouncing the MrBig service after each change although per documentation
this should not be necessary.  Version 0.20. 

The "ignore message" looks to be pretty broad in scope; does not appear
to support filtering on a single log file so in the above (if it was
working as we would expect...) a DNS message in another log file would
also be trapped out.

We went with MrBig as it sounded like BBWin was withering away. No
support forum for MrBig (yet?). Hoping it is something obvious I am
missing that someone can deliver sufficient blunt trauma before I start
wading through the source code.

Citerar "Deiss, Mark" <user-5cd8675c2346@xymon.invalid>:

Is this a Windows event log? Check in Event Viewer what the name is and filtering on the log name should work fine.

Last I heard, the good folks at Qbranch (the company behind Mr Big) were going to carry on maintenance after I left. Tobias Nygren is the new maintainer; see contact info on the web page.

Ulric

It's a Windows event log. I thought maybe there was an issue with the
name having a space but quoting it has no bearing (for the "ignore
source" entries). I have drilled into the particular events and have
added "ignore message" with different single words that are in the
alerts. The final alert in Xymon/BB does not have the event body - just
a header line with date stamps followed by a line with a bracketed
number that something is occurring in the MIMEsweeper log.

I will see about contacting Mr. Nygren.

Office: XXX-XXX-XXXX
user-5cd8675c2346@xymon.invalid
ACS, A Xerox Company 
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure, or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.

-----Original Message-----
From: user-de31148ebe0c@xymon.invalid [mailto:user-de31148ebe0c@xymon.invalid] 
Sent: Tuesday, September 28, 2010 9:19 AM
To: xymon at xymon.com
Subject: Re: [xymon] Question on MrBig log parsing

Citerar "Deiss, Mark" <user-5cd8675c2346@xymon.invalid>:

Is this a Windows event log? Check in Event Viewer what the name is and 
filtering on the log name should work fine.

Last I heard, the good folks at Qbranch (the company behind Mr Big) 
were going to carry on maintenance after I left. Tobias Nygren is the 
new maintainer; see contact info on the web page.

Ulric

On Monday, 27 September 2010 20:58:19 Henrik "Størner" wrote:

<user-9b139aff4dec@xymon.invalid> writes:

Most people will expect "ldaps" to mean LDAP over SSL.. IMHO, we should either 
create a new tag for LDAP with STARTTLS, or use a bind extension in the 
existing ldap tag (IOW, keep it a quasi-valid LDAP URI).

AFAIK, there is no standard bind extension for starttls, but we could use 
something like:

ldap://hostname/????starttls

(or:
ldap://ldap.mydomain.com/dc=mydomain,dc=com?uid?sub?"(uid=testuser)"?starttls
)

Regards,
Buchan

On Sep 28, 2010, at 6:32 PM, Buchan Milne wrote:

Isn't that what I said? :) Of course, it carries a lot more weight coming from you.

That sounds fine for testing with a URI, but what about a “naked” tag? Currently, it's enough to just say “ldap” or “ldaps” to have the test run with defaults. Should we have one like “ldapt” or something? Or should we just require the long form with a URI to trigger this test?

-- 
Rob McBroom
<http://www.skurfer.com/>;

On Wednesday, 29 September 2010 13:21:10 Rob McBroom wrote:

ldap://ldap.mydomain.com/dc=mydomain,dc=com?uid?sub?"(uid=testuser)"?star
ttls )

Sure, if all you want to do is test that the port is open. What would you want 
to occur for an 'ldap' tag regarding STARTTLS?

Should we have one like “ldapt” or something?

What would it do? Check if port 389 is open (just like 'ldap')? Anything else?

ldap://hostname/????starttls
?
or ldap:///????starttls
?

Regards,
Buchan

On Sep 29, 2010, at 11:19 AM, Buchan Milne wrote:

Ah, OK. I thought the “ldaps” test this thread referred to was just “ldaps” and nothing else. Apparently, “ldap” and “ldaps” are both testing port 389 currently (and nothing more). Adding some details, like “ldaps://server/blah” will do STARTTLS on 389, right?

Although, now that I think about it, that can't be true. I'm using your excellent “ol” test but I left the “ldaps” tag in place so I could get warnings about the SSL certs. If “ldaps” is only checking that the port is open, how can it know anything about the cert? Clearly, there's more going on. If it's hitting port 636 to get the cert, then I wouldn't change anything. If it's doing STARTTLS on 389, then I'm saying “ldapt” (or whatever) should take over that function and “ldaps” should use 636.

-- 
Rob McBroom
<http://www.skurfer.com/>;

Don't try to tell me something is important to you if the whole of your “support” entails getting Congress to force *others* to spend time and money on it.

On Sep 29, 2010, at 11:48 AM, Rob McBroom wrote:

I'm using your excellent “ol” test

I mean “openldap”. I forgot that I had shortened it to make the column narrower.

-- 
Rob McBroom
<http://www.skurfer.com/>;