É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