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
And this where is got interesting:
- 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.
How did you bind?
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
Gavin Henry wrote:
And this where is got interesting:
- 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.
How did you bind?
binds cn=monitor (rootdn), user DIT (normal user) and cn=config (rootdn) were simple authenticated binds. bind to roodsecn=subschema was anonymous
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
Gavin Henry wrote:
And this where is got interesting:
- 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.
How did you bind?
binds cn=monitor (rootdn), user DIT (normal user) and cn=config (rootdn) were simple authenticated binds. bind to rootDSE and cn=subschema were anonymous
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
openldap-software@openldap.org