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: Apache Directory Studio, as well as JXplorer do not support (TLS) client certificate verification, what is agreed not to be a topic of openldap. But anyway...

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