I want to force clients to use TLS except on the IPv4 loopback interface. As suggested by Aaron I have the following ACL as the very first one # first, make sure TLS or localhost access to * by tls_ssf=1 none break by peername.ip="127.0.0.1" none break by * none followed by my "real" ACLs.
Everything is working as expected but I've just noticed that I can bind to the server with my rootdn in cleartext. Is this expected? Is there a way to prevent this?
Regards, Thierry.
Thierry Lacoste writes:
I want to force clients to use TLS except on the IPv4 loopback interface. As suggested by Aaron I have the following ACL as the very first one # first, make sure TLS or localhost access to * by tls_ssf=1 none break by peername.ip="127.0.0.1" none break by * none followed by my "real" ACLs.
Note that this returns "invalid credentials" to users who send their password unproteced. They may assume they typed the password wrong and send it unprotected again:-( If you use the 'security' directive instead, they will get the more informative 'confidentiality required' result code.
However that may stop you from using localhost without TLS too. Haven't checked. But you can listen for ldapi:// instead.
On some hosts you then won't even need a rootpw: ldapwhoami -YEXTERNAL -H ldapi:// makes the server pick up the client process' uid and gid. Avoid ldapi:// on OpenLDAP 2.3.34 and earlier, it has security holes on some hosts.
Everything is working as expected but I've just noticed that I can bind to the server with my rootdn in cleartext. Is this expected? Is there a way to prevent this?
I guess it's an unexpected consequence of how rootdn is implemented. Access controls are applied to entries, and rootpw is not in an entry.
So an alternative way would be to create an entry with the rootdn as the DN and rootpw as userPassword, and in slapd.conf keep rootdn but remove rootpw.
Hallvard B Furuseth wrote:
Thierry Lacoste writes:
I want to force clients to use TLS except on the IPv4 loopback interface. As suggested by Aaron I have the following ACL as the very first one # first, make sure TLS or localhost access to * by tls_ssf=1 none break by peername.ip="127.0.0.1" none break by * none followed by my "real" ACLs.
Note that this returns "invalid credentials" to users who send their password unproteced. They may assume they typed the password wrong and send it unprotected again:-( If you use the 'security' directive instead, they will get the more informative 'confidentiality required' result code.
However that may stop you from using localhost without TLS too. Haven't checked. But you can listen for ldapi:// instead.
On some hosts you then won't even need a rootpw: ldapwhoami -YEXTERNAL -H ldapi:// makes the server pick up the client process' uid and gid. Avoid ldapi:// on OpenLDAP 2.3.34 and earlier, it has security holes on some hosts.
Everything is working as expected but I've just noticed that I can bind to the server with my rootdn in cleartext. Is this expected? Is there a way to prevent this?
Yes it is expected.
I guess it's an unexpected consequence of how rootdn is implemented. Access controls are applied to entries, and rootpw is not in an entry.
No. The rootdn always ignores ACLs.
Thierry Lacoste lacoste@miage.univ-paris12.fr writes:
I want to force clients to use TLS except on the IPv4 loopback interface. As suggested by Aaron I have the following ACL as the very first one # first, make sure TLS or localhost access to * by tls_ssf=1 none break by peername.ip="127.0.0.1" none break by * none followed by my "real" ACLs.
Everything is working as expected but I've just noticed that I can bind to the server with my rootdn in cleartext. Is this expected? Is there a way to prevent this?
Yes, rootdn has no restrictions. To prevent this behaviour, don't create a rootpw, but create a general administration user with an appropriate policy.
-Dieter
openldap-software@openldap.org
-
Dieter Kluenter -
Hallvard B Furuseth -
Howard Chu -
Thierry Lacoste