[Nagiosplug-devel] [ nagiosplug-Bugs-1466426 ] 1.4.2 check_ldaps doesn't default to port 636

[SourceForge.net]

Bugs item #1466426, was opened at 2006-04-07 18:18
Message generated for change (Comment added) made by hweiss
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&group_id=29880

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General plugin execution
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Rouillard (rouilj)
Assigned to: Matthias Eble (psychotrahe)
Summary: 1.4.2 check_ldaps doesn't default to port 636

Initial Comment:
check_ldaps in the 1.4.2 release doesn't automatically
try to conect to port 636. It uses port 389 like
check_ldap does.

-- rouilj


----------------------------------------------------------------------

>Comment By: Holger Weiss (hweiss)
Date: 2007-06-19 16:29

Message:
Logged In: YES 
user_id=759506
Originator: NO

rouilj:

| I saw one host work, but that system (incorrectly) runs both ldap
| and ldaps so it worked against the ldap port without ssl.

Are you *sure* this wasn't an SSL connection (initiated using STARTTLS)? 
>From a quick look at the code, if you call "check_ldaps" without specifying
the LDAPS port, the plugin will try STARTTLS and bail out with a CRITICAL
error if that fails (see check_ldap.c:139-181 from the 1.4.9 release).

psychotrahe:

AFAICS, if argv[0] is "check_ldaps", the plugin currently defaults to
trying STARTTLS, unless "--port=636" was specified, in which case it tries
LDAPS (that is, "SSL on connect").  The change you suggested would make the
plugin behave the other way round, so I guess this would then confuse the
STARTTLS users instead of the LDAPS users :-)  More importantly, it would
break existing configurations which don't specify the --port explicitely.

IMO, this is yet another example that such magic (guessing connection
protocols from ports or the other way round) is almost always a bad idea. 
However, for backwards compatibility, we should probably keep the existing
magic by default.  But maybe we should add options to explicitely request
"SSL on connect" or STARTTLS regardless of the port.  And in any case, we
should properly document the behaviour in the --help output.

----------------------------------------------------------------------

Comment By: Matthias Eble (psychotrahe)
Date: 2007-06-19 15:29

Message:
Logged In: YES 
user_id=1694341
Originator: NO

will fix this tonight.. 
there should be a warning if you connect to the ldaps port and don't get a
ldaps session.
So changing the port to 636 if argv[0] is "check_ldaps" will fix this,
too.

----------------------------------------------------------------------

Comment By: John Rouillard (rouilj)
Date: 2006-04-07 18:56

Message:
Logged In: YES 
user_id=707416

Sorry this is a valid bug. I saw one host work, but that
system (incorrectly) runs both ldap and ldaps so it
worked against the ldap port without ssl.

So that may be another bug, it should fail if it doesn't
get an encrypted session.

-- rouilj


----------------------------------------------------------------------

Comment By: John Rouillard (rouilj)
Date: 2006-04-07 18:51

Message:
Logged In: YES 
user_id=707416

Never mind. User error.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1466426&group_id=29880