[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 psychotrahe
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: Matthias Eble (psychotrahe)
Date: 2007-06-19 17:48

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

Today i have read about a user expecting ldaps to connect to 636 in a
forum.

But using the direct connection seems to be deprecated according to
http://www.openldap.org/lists/openldap-software/200409/msg00617.html

So startTLS should be the right way to make it. I couldn't find out if
ldap_start_tls_s() eventually makes a secure connect after the query on the
default port. IMO it should do so.







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

Comment By: John Rouillard (rouilj)
Date: 2007-06-19 17:38

Message:
Logged In: YES 
user_id=707416
Originator: YES

I checked the code I used to compile the check_ldaps binary. It matches
the startls stuff that
hweiss detailed. I agree with psychotrahe that check_ldaps should use port
636
and not 389 with startTLS. At the very least it has to be documented.

I can verify the startTLS error:

  /usr/lib/nagios/plugins/check_ldaps -H localhost -b dc=... -3 -w 1 -c 10

  Could not init startTLS at port 389!

when running against a non-TLS enabled server. I am starting to think
that
my port 389 test that worked was using startTLS. So my assertion:

> 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.

should have read:

 ...
 worked against the ldap port *with* ssl,
 but I expected it to use ldaps protocol and not ldap with startTLS.


-- rouilj


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

Comment By: Matthias Eble (psychotrahe)
Date: 2007-06-19 17:25

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

Hi Holger,

you are right. I din't know about the startTLS functionality.

IMO check_ldaps lets people expect a to be connecting to a secure port.
startTLS seems to be intended to be used on a non secure port. It should
imo therefore  rather be an option to check_ldap instead of default
behaviour for check_ldaps.
I also couldn't find a hint that clarifies what check_ldaps was intended
to do.

However since we don't want to break backward compatibility, we should as
you said add some lines to --help. 





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

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