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. 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.
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:///.
/Peter
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.
Howard Chu wrote:
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.
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 guessed so.
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.
Yes - but limiting access (say cn=config, if it was possible) is an explicit statement by the sys-adm (me) that I want configuration access to be governed by OS permissions on _this_ installation. That's no different from the old slapd.conf
The only safe thing to do is assume that any user can access the socket, because that's almost universally true.
But there was no assumption that any user could write to slapd.conf. Wasn't the assumption that the sysadm had to control configuration access external to the database?
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.
won't setting a rootpw allow anyone being able to guess it to connect on any socket (TCP/UNIX) that slapd is listening on an bind as cn=config?
/Peter
Peter Mogensen wrote:
Howard Chu wrote:
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.
won't setting a rootpw allow anyone being able to guess it to connect on any socket (TCP/UNIX) that slapd is listening on an bind as cn=config?
Then just use SASL/EXTERNAL and don't use any passwords at all.
Howard Chu wrote:
Peter Mogensen wrote:
Howard Chu wrote:
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.
won't setting a rootpw allow anyone being able to guess it to connect on any socket (TCP/UNIX) that slapd is listening on an bind as cn=config?
Then just use SASL/EXTERNAL and don't use any passwords at all.
Ok. It seems this does what I want:
authz-regexp "gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=config" database config rootdn "cn=config" #rootpw none
$ ldapwhoami -YEXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:cn=config
Only question now is if this is enough to prevent people from binding as cn=config on ldap://<public-IP>/, where the server is also listening.
/Peter
Peter Mogensen wrote:
Howard Chu wrote:
Peter Mogensen wrote:
Howard Chu wrote:
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.
won't setting a rootpw allow anyone being able to guess it to connect on any socket (TCP/UNIX) that slapd is listening on an bind as cn=config?
Then just use SASL/EXTERNAL and don't use any passwords at all.
Ok. It seems this does what I want:
authz-regexp "gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=config" database config rootdn "cn=config"
The config database defaults to "cn=config" for its rootdn so there is no need to specify it here.
#rootpw none
$ ldapwhoami -YEXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:cn=config
Only question now is if this is enough to prevent people from binding as cn=config on ldap://<public-IP>/, where the server is also listening.
Without any other authz-regexps in place, the only other possibility is to use a client cert that slapd trusts, whose subject DN is "cn=config". Aside from that, no, there is no other way anyone can bind to this identity.
Howard Chu wrote:
$ ldapwhoami -YEXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:cn=config
Only question now is if this is enough to prevent people from binding as cn=config on ldap://<public-IP>/, where the server is also listening.
Without any other authz-regexps in place, the only other possibility is to use a client cert that slapd trusts, whose subject DN is "cn=config". Aside from that, no, there is no other way anyone can bind to this identity.
Alright... So I guess that would be the way to do it if I wanted cn=config syncrepl-icated from another server.
/Peter
Peter Mogensen wrote:
Only question now is if this is enough to prevent people from binding as cn=config on ldap://<public-IP>/, where the server is also listening.
Omit rootpw in config database and no one will be able to bind as cn=config.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati wrote:
Peter Mogensen wrote:
Only question now is if this is enough to prevent people from binding as cn=config on ldap://<public-IP>/, where the server is also listening.
Omit rootpw in config database and no one will be able to bind as cn=config.
Yes... that one was obvious. But that was not what I wanted. What I wanted was to "simulate" the old slapd.conf situation where only root (or who ever the OS gave permissions) could configure slapd.
So I wanted to prevent binds to cn=config from anywhere but ldapi:///
In an ordinary database I can do that with ACL's and create an object for the rootdn to which I limit auth priviledges.
But the cn=config database is obviously not normal.
Using SASL/EXTERNAL and authz-regexp seems to do the trick (as I described).
/Peter
PS: Only now I'm struggling to make cn=config binds possible remotely with TLS client ceritifcates. GNUTLS seems to complain: "TLS: can't accept: A TLS packet with unexpected length was received.." But that's another story.
openldap-software@openldap.org
-
Howard Chu -
Peter Mogensen -
Pierangelo Masarati