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:matthew.epp at us.army.mil] 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?
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com
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:
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:matthew.epp at us.army.mil] Sent: Tuesday, 31 August 2010 3:25 AM To: xymon at xymon.com Subject: [xymon] bug in ldaptest.c
[...]
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?
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 <201008311724.25873.bgmilne at staff.telkomsa.net> Buchan Milne <bgmilne at staff.telkomsa.net> writes:
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.
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:
In <201008311724.25873.bgmilne at staff.telkomsa.net> Buchan Milne <bgmilne at staff.telkomsa.net> writes:
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.
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.
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 <201009271934.40635.bgmilne at staff.telkomsa.net> Buchan Milne <bgmilne at staff.telkomsa.net> writes:
On Thursday, 23 September 2010 14:18:51 Henrik "St=C3=B8rner" wrote:
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.
This isn't true. Almost all LDAP client software (pam_ldap, nss_ldap, samba= ,=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:
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.
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" <Mark.Deiss at acs-inc.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.
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: 240-686-2666 mark.deiss at acs-inc.com 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: ulric at siag.nu [mailto:ulric at siag.nu] Sent: Tuesday, September 28, 2010 9:19 AM To: xymon at xymon.com Subject: Re: [xymon] Question on MrBig log parsing
Citerar "Deiss, Mark" <Mark.Deiss at acs-inc.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.
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
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com
On Monday, 27 September 2010 20:58:19 Henrik "Størner" wrote:
In <201009271934.40635.bgmilne at staff.telkomsa.net> Buchan Milne <bgmilne at staff.telkomsa.net> writes:
On Thursday, 23 September 2010 14:18:51 Henrik "St=C3=B8rner" wrote:
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.
This isn't true. Almost all LDAP client software (pam_ldap, nss_ldap, samba= ,=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.
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:
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).
Isn't that what I said? :) Of course, it carries a lot more weight coming from you.
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 )
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:
On Sep 28, 2010, at 6:32 PM, Buchan Milne wrote:
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).
Isn't that what I said? :) Of course, it carries a lot more weight coming from you.
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)"?star ttls )
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.
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?
Or should we just require the long form with a URI to trigger this test?
ldap://hostname/????starttls ? or ldap:///????starttls ?
Regards, Buchan
On Sep 29, 2010, at 11:19 AM, Buchan Milne wrote:
On Wednesday, 29 September 2010 13:21:10 Rob McBroom wrote:
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.
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?
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/>
participants (7)
-
bgmilne＠staff.telkomsa.net
-
brian.scott4＠det.nsw.edu.au
-
henrik＠hswn.dk
-
mailinglist0＠skurfer.com
-
Mark.Deiss＠acs-inc.com
-
matthew.epp＠us.army.mil
-
ulric＠siag.nu