[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Securing cn=config
I'm using OpenLDAP 2.4.11 on FreeBSD 6.2 RELEASE. I have a one user DIT
(dc=example,dc=com), a cn=monitor DIT (with a rootdn and rootpw) and
cn=config DIT (with rootdn and rootpw). Access to all the DITs uses
simple binds. I configured the system to use TLS/SSL on the standard 636
port. and every works perfectly for all DITs. I can log in either with
ldap(389) or ldaps (636) schemes.
So I decided to lock down the box and prevent any non-TLS access (to
DITs). By simply removing the listen on 389 (slapd -h ldaps:/// -u ldap)
I could accomplish this - but the (perhaps minor) collateral damage was
that access to cn=subschema with an anonymous bind obviously no longer
worked (but obviously did using ldaps scheme). In an attempt to get this
feature back I put back the listen on port 389 (slapd -h "ldap:///
ldaps:///" -u ldap) and added a global ACL of
access to * tls_ssf=128 break
Which works perfectly for the user DIT but obviously since I login to
cn=monitor an cn=config via the rootdn had no effect. I removed the
global ACL and added
security simple_bind=128
And this where is got interesting:
1. Access via ldap on the user DIT and on cn=monitor where both
inhibited and connections (rightly) refused whereas in both cases access
via ldaps was accepted.
2. I could bind anonymously to rootDSE and cn=subschema which I wanted
3. cn=config would accept either a ldap (389) or an ldaps (636)
connection. Apparently by-passing the security simple_bind=128 check.
a. Is this expected?
b. is there a better way to do it?
c. Am I (more than likely) missing something? (on searching the archives
I saw a note from Quannah suggesting that he was using some sort of SASL
service to inhibit access).
Many thanks in advance for any help on this matter.
Regards
--
Ron Aitchison www.zytrax.com
ZYTRAX ron@zytrax.com
tel: 514-315-4296
Suite 22
6201 Chemin Cote St. Luc
Hampstead QC H3X 2H2 Canada
Author: Pro DNS and BIND (Apress) ISBN 1-59059-494-0