On 03/06/2012 05:36 AM, [email protected] wrote:
> Hi,
>
> I was happy to get your conversation about the LDAPS issues (although your 
> mail went to the spam folder :-)
>
> I do not want to interfere your problem finding, but would like to ask 
> another question around this subject, and having found the experts I want to 
> keep that chance...
>
> I have the following question: we have about 100 LDAP applications running to 
> our Novell LDAP interface. Some work on port 636, some on 389. Now I want to 
> set the parameter "require TLS for simple bind with password". My 
> understanding was that TLS (or StartTLS) is an additional feature which can 
> be used (but must not be used) and that therefore the running applications 
> should not be affected. I had to learn that this is not true. Can you help me 
> to identify the requirements to understand which applications would be 
> affected by this change?

Juergen,

It sounds like you don't full understand TLS and the difference between
TLS and SSL. I hope this brief explanation can help you out. I hope I'm
not making a fool out of myself my telling you something you already know.

TLS is similar to SSL, except that it happens on the non-encrypted port
address, so for LDAP, that would be on port 389, instead of the LDAP+SSL
port of 636. For TLS the client connects to the "standard" unencrypted
port and issues the StartTLS command, which tells the server to start
encrypting traffic, still on port 389. The goal of TLS was to reduce
port use, so that services that typically use encryption on a second
port (port 636 for LDAP) can go back to needing to use only one port
(port 389 for LDAP).

Unfortunately, not every application supports TLS. Just as some
applications were slow to implement SSL, many have been slow to
implement TLS, too. Your best bet is to configure your LDAP server to
use port 636 for LDAP+SSL, and port 389 for TLS and unencrypted traffic.
If you want to make encryption mandatory regardless of port used, you
need to specify a security strength factor (SSF) in your slapd.conf. You
can specify an SSF for your entire directory, or just for specific
attributes (password, etc.) by specifying it in an ACL for that class.

As far as determining which applications will be affected by this
change, that's something you'll have do on your own, either by reading
the documentation for your applications to see if they support SSL or
TLS or both, and doing some testing. There's too many different
applications that use LDAP for us to know all of them. If your turn on
SSL or TLS on your LDAP server and running applications break, it could
be that they support SSL or TLS, but were never setup properly to use
encryption

 If they support SSL, you need to tell them to connect to port 636 or
use LDAPS as the protocol. Many LDAP clients are smart enough to use
port 636 if you tell them to use SSL, or automatically use SSL if you
set the port to 636 in their coniguration. If they support TLS, you
usually need to tell them to use TLS, or else they'll just connect to
port 389 without encryption. In addition, you need to provide them with
the CA certificate for the CA that signed your LDAP servers SSL
certificate, so they can verify that it's valid. If your LDAP cert(s)
were signed by as well-known CA  like Verisign, this may already be done
as part of your operating systems default setup.

I hope that long-winded explanation was helpful!

Prentice

Reply via email to