Sorry for reopening / reasking the following issue.
I tried to scan through all posts, but this answer seemed to be the closest one to my problem. (We're using OpenLDAP 2.4 on Debian Lenny)
Link: http://www.openldap.org/lists/openldap-software/200409/msg00535.html
If you're willing to concede that 127.0.0.0/8 will never appear outside of your loopback interface, you can synthesize this by checking peer IPs.
# 127.0.0.1 is allowed, regardless of ssf. world at large needs ssf check access to dn.<dnstyle1>=<what1> by peername.ip=127.0.0.1 <access1> by * none break # We're not coming via loopback; ssf must be checked. access to dn.<dnstyle1>=<what1> by ssf=128 <access2> by * none
Situation: For deployment we want to use TLS client certificates, as far as possible, using TLS encryption all the way long.
Problem: Various LDAP client software and services do not support (TLS) client certificate verification.
My proposed solution: * All clients, which support client certificate verification, should directly connect using TLS to the LDAP server. * All clients, esp. the management tools, should establish a ssh-tunnel to the server and connect through localhost entity. * (optional) specific clients should be able to connect via specific access rules (but this is a future topic ;) )
Implementation: This is not clear to me, how the previous posts are related to my problem, and how to configure the OpenLDAP server. I tried several scenarios with varying results, but no one was perfect yet.
Here a snippet of my current slapd.conf: --------------- # the "ssl tls=1" is not necessary due to the special # access rule in the remainder of this configuration
TLSCACertificateFile /etc/ssl/CA/cacert.pem TLSCertificateKeyFile /etc/ssl/private/privkey.pem TLSCertificateFile /etc/ssl/certs/pubkey.pem TLSVerifyClient demand # for highest security
# The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below 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
# Security considerations (TESTING!!!!) # http://www.openldap.org/lists/openldap-software/200409/msg00535.html # access from 127.0.0.1 without encryption access to dn.subtree="dc=example,dc=com" by peername.ip=127.0.0.1 write by * none break # worldwide access requires tls encryption access to dn.subtree="dc=example,dc=com" by ssf=128 write by * none
# Ensure read access to the base for things like # supportedSASLMechanisms. Without this you may # have problems with SASL not knowing what # mechanisms are available and the like. # Note that this is covered by the 'access to *' # ACL below too but if you change that as people # are wont to do you'll still need this if you # want SASL (and possible other things) to work # happily. access to dn.base="" by * read
# The admin dn has full write access, everyone else # can read everything. access to * by dn="cn=admin,dc=example,dc=com" write by * read ---------------
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? Possible solution: The server only responds to unencrypted requests on the local interface. How can I achieve this? 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? 3) What would be the appropriate way to achieve my goal? * Locking the dc=example,dc=com base from all unencrypted access from "worldwide" hosts. (admin should still have full access, but encryption has to be enforced) * Allowing access to the complete ldap tree without encryption from localhost
Thank you very much, any help or further link is appreciated. I spent almost one week now reading and completing the stuff, but sometimes it works, but a "whole" is left, otherwise only parts of the ldap server are accessible as desired.
Best regards, Robert
P.S.: Though "googling" for several days now, I'm interested in any Link to a good website discussing the access rules besides the openldap documentation and presenting various use cases.