Peter Mogensen wrote:
Mike Malsman wrote:
> On 11.Mar.2009, at 9:32 AM, Peter Mogensen wrote:
>> But limiting cn=config access to ldapi:/// ... no luck.
>> Do someone have a working example of this?
> What does your 'access' directive look like?
access to dn.exact="cn=config"
by peername.path="/var/run/slapd/ldapi" auth
by * none
I've used this method before in "normal" databases, to control who can
become rootdn, but it just won't work for cn=config.
Of course, I have to add a "userPassword" attribute to
but it seems to be ignored.
It ought to be rejected/startup should fail; userPassword is not a valid
attribute for any cn=config entries.
I've also tried to create a cn=root,cn=config object, but I have
problem finding a schema which is loaded which allows me to set
The cn=config database is not a normal database: you cannot create arbitrary
entries under cn=config.
If people on this list hadn't said that it was possible, I would
probably have concluded by now that it is simply not possible to limit
rootdn access to cn=config to ldapi:///.
Personally I think peername-based access control is a crock. For TCP sockets,
IP addresses can be easily spoofed. For Unix Domain sockets, different
operating systems have different policies on how/whether Unix permission bits
affect them. The only safe thing to do is assume that any user can access the
socket, because that's almost universally true.
Do it right, use SASL/EXTERNAL and use authz-regexp to map Unix credentials to
And don't mess around with "userPassword" when "rootpw" is what
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/