Re: secure ldap remotely (TLS handshake error)

[Tony Earnshaw <tonni@hetnet.nl>]

Éliás Tamás skrev, on 17-09-2007 15:08:

> Udv / Greetings!

Udv!

> I have revised the prevoious list postings, but unfortunately I'm in
> deeper trouble with openldap as before.
>
> On a debian etch machine, I'm running a simple slapd instance with
> HDB. I have to connect to this from the internet. Still this time it
> was working only locally and quite fine. So I've started to look afte
> r if I can manage security somehow.

Don't know Debian, don't know HDB, but it shouldn't matter in this case.

> I have read about the differences between LDAPS, STARTTLS and so. The
> facts I've collected:
>
> - by using the TLSCertificateFile and other options I can use my own
> selfigned cert.

You don't need a client cert to connect either via ldaps or 
ldap/starttls [1].

> - ldaps is a non standard method and works only locally originated
> connections.

Not so. It is standard in as much as almost all clients everywhere 
implement it and it's not likely to go away for a *very* long time. It 
is frowned upon by IETF, but that is another matter.

The client (whichever), or you as sysadmin, must have a way of importing 
the server's CA cert into a repository somewhere on the client machine. 
Alternatively, the client must have a mechanism for importing the cert 
offered to it, that you as admin sanctify. That last applies only to non 
OpenLDAP clients. The first applies to OpenLDAP clients, such as 
ldapsearch and friends.

ldaps in *not* only for locally originated connections, it will work 
across any network.

> - ldap and starttls command can be managed to work non locally. now
> the questions. So if I connect from a remote machine to the standard
> port, how to tell the ldap client to start tls?

That depends on the client, the mechanism involved is defined by the 
LDAP rfcs (don't now which). OpenLDAP tools mostly use '-Z[ZZ]' 
somewhere in the command string. OpenLDAP servers use another method, 
depending on the context.

> - Also, I've looked for other ways. there are security ssf options, that must work. By using any form
> the security ssf options, other softwares or even the ldapsearch
> function can not connect, tough slapd is running.

ssf functions for encrypted data are mostly automatic.

> So I want to achieve the following:
> - access the ldap remotely on a secure manner, I do not care if it is
>  TLS or some ldap managed stuff.

TLS and ldaps are pretty secure; no man in the middle or anywhere else 
is likely to decode the traffic.

 I do not want to use sasl,

SASL *plus* TLS/ldaps is even more secure and will earn you brownie 
points as far as ssf goes. Personally, I use SASL digest-md5 plus TLS 
for OpenLDAP services wherever possible. You should *want* to use SASL 
wherever possible, also for non-OpenLDAP related services, such as smtp 
and IMAP.

But if you care about security over *local* connections, ldapi over Unix 
sockets is the way to go, if possible with SASL external - which, again, 
gives buckets of ssf brownie points.

> I have my
>  accounts defined in the ldap directory, I do not need some kinda
>  outsider auth mechanism.

[1] Then you don't need client certificates.

> IS THIS possible?

Is what possible?

> I've already have the client cert, the tls options set in the config,
> and ldap is listening on ldap://host, and no "security ssf" options
> defined. I want to secure all transfers (passwords already MD5 or SHA)

Password encryption is immaterial if you're doing ldaps or STARTTLS. I 
have all my passwords in cleartext, in LDAP, since I use MD5 SASL 
authentication for all services I can. BUT. Your basic Unix security has 
to be top-notch if you do that kind of thing.

> If TLS does not work, what to do now? Thank you for the answer.

TLS works ;)

> sw info: latest stable openldap compiled from source, with latest
> openssl.

Same here (what do *you* mean by "latest"? Could be latest Red Hat 4, in 
which case it's useless).

--Tonni

--
Tony Earnshaw
Email: tonni at hetnet dot nl