Re: Using different encryption on localhost and networked connections

[Michael Ströder <michael@stroeder.com>]

Robert Henjes wrote:
> My proposed solution:
> * All clients, which support client certificate verification, should
> directly connect using TLS to the LDAP server.

You really want to use client authc during TLS negotiation with the client
having a private key and a public key cert? Note that this does only makes
sense if you have end-users interactively operating the LDAP client software.

> * All clients, esp. the management tools, should establish a ssh-tunnel to
> the server and connect through localhost entity.

I would not mess with an extra SSH tunnel if you already have TLS up and running.

> * (optional) specific clients should be able to connect via specific access
> rules (but this is a future topic ;) )

Please don't take it personally but that's a pretty broad statement.

> Questions:
> 1) Turing off the option "ssl tls=1" means, a client can contact the server
> without encryption. If a password is transmitted, it will be rejected, but
> it is still transmitted unsecure. Due you have any recommendations
> according this issue?

If you want to avoid that particular problem you have to use LDAP over SSL on
a separate port (AKA LDAPS). Because then the SSL/TLS connection MUST be fully
established *before* the LDAP connection.

Note that you cannot by any means prevent a client from doing something really
dumb except by client configuration. Maybe a custom web interface for
administration over HTTPS would be more appropriate for your requirements than
a GUI client?

> Possible solution: The server only responds to unencrypted requests on the
> local interface. How can I achieve this?

Start slapd with appropriate parameters for command-line option -h for LDAP on
localhost and LDAPS for remote connections.

> 2) With the above presented solution, I can not change my own password as the desired user (Invalid credentials (49)), only as admin(root). Why?

You have this ACL:

access to attrs=userPassword,shadowLastChange
        by peername.ip=127.0.0.1 write
        by ssf=128 dn="cn=admin,dc=example,dc=com" write
        by ssf=128 anonymous auth
        by ssf=128 self write
        by * none

1. It should have as last clause:
        by * auth
2. Are you sure self should be able to write shadowLastChange? Then you cannot
enforce Unix password policy anymore.

Ciao, Michael.