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:
- 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.
- 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.