[Date Prev][Date Next]
Re: secure ldap remotely (TLS handshake error)
Éliás Tamás skrev, on 17-09-2007 15:08:
Udv / Greetings!
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
You don't need a client cert to connect either via ldaps or
- ldaps is a non standard method and works only locally originated
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
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.
 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
Same here (what do *you* mean by "latest"? Could be latest Red Hat 4, in
which case it's useless).
Email: tonni at hetnet dot nl