Ron Aitchison | 29 Sep 11:46
Favicon

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).
(Continue reading)

Gavin Henry | 30 Sep 11:46
Favicon
Gravatar

Re: Securing cn=config

> 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.

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
> 

--

-- 
Kind Regards,

Gavin Henry.

T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry <at> suretecsystems.com

Open Source. Open Solutions(tm).
(Continue reading)

Ron Aitchison | 30 Sep 21:44
Favicon

Re: Securing cn=config


Gavin Henry wrote:
>> 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.
>
> 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
>>
>
>

--

-- 
Ron Aitchison                      www.zytrax.com
ZYTRAX                             ron <at> zytrax.com
                                   tel: 514-315-4296
                                   Suite 22
(Continue reading)

Ron Aitchison | 30 Sep 21:44
Favicon

Re: Securing cn=config


Gavin Henry wrote:
>> 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.
>
> 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
>>
>
>

--

-- 
Ron Aitchison                      www.zytrax.com
ZYTRAX                             ron <at> zytrax.com
                                   tel: 514-315-4296
(Continue reading)


Gmane