[Date Prev][Date Next] [Chronological] [Thread] [Top]

Using different encryption on localhost and networked connections

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)

> If you're willing to concede that will never appear outside of
> your loopback interface, you can synthesize this by checking peer IPs.
> # is allowed, regardless of ssf. world at large needs ssf check
> access to dn.<dnstyle1>=<what1>
>         by peername.ip= <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

For deployment we want to use TLS client certificates, as far as possible, using TLS encryption all the way long.

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 ;) )

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= 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 without encryption
access to dn.subtree="dc=example,dc=com"
        by peername.ip= 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

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,

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.

Dipl.-Inform. Robert Henjes
University of Wuerzburg,
Institute of Computer Science,
Chair of Distributed Systems (Informatik III),
Am Hubland, 97074 Wuerzburg, Germany

Tel: +49 931 31-86652
Fax: +49 931 888-6632