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?
/Peter
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 cn=config.ldif, 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 a problem finding a schema which is loaded which allows me to set userPassword.
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 LDAP credentials.
And don't mess around with "userPassword" when "rootpw" is what you need.