[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: forcing encryption for external server access while allowing unencrypted localhost 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)
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
--
Dipl.-Inform. Robert Henjes
University of Wuerzburg,
Institute of Computer Science,
Chair of Distributed Systems (Informatik III),
Am Hubland, 97074 Wuerzburg, Germany
henjes@informatik.uni-wuerzburg.de
Tel: +49 931 31-86652
Fax: +49 931 888-6632