Jonathan Knight wrote:
> It's hard to tell without seeing your whole configuration. Auth (by
> simple bind) uses ACLs. In detail, it needs auth access to
> userPassword. The ACL you show above should indeed prevent auth;
> however, everybody would see the userPassword of everybody under that
> tree (=r).
Here's the config file I'm currently playing with.
access to * by * none
If I've understood the manual correctly then this should stop all access
to the entire DIT.
I start slapd with:
/usr/local/ldap-proxy/libexec/slapd -d 128
@(#) $OpenLDAP: slapd 2.4.11 (Dec 18 2008 18:18:07) $
Backend ACL: access to *
by * none
Backend ACL: access to *
by * none
config_back_db_open: line 0: warning: cannot assess the validity of the
ACL scope within backend naming context
I then run this command on the client:
ldapwhoami -x -h romeo.kis.keele.ac.uk -D
Enter LDAP Password:
As you can see the BIND succeeds and the DN is returned. If I get the
password wrong, I get the invalid credentials error rather than the DN.
There is no debug output on the slapd server. Any attempt at an
ldapsearch will fail on the search and I get some ACL debug output, but
the initial bind always succeeds.
So how do I use an ACL to stop a bind?
You see, you did not illustrate an important part of your configuration
in your first message. slapd.access(5) states:
Operations require different privileges on different portions of
entries. The following summary applies to primary database backends
such as the BDB and HDB backends. Requirements for other backends may
(and often do) differ.
The bind operation, when credentials are stored in the directory,
requires auth (=x) privileges on the attribute the credentials are
stored in (usually userPassword).
Access control to search entries is checked by the frontend, so it is
fully honored by all backends; for all other operations and for the
discovery phase of the search operation, full ACL semantics is only
supported by the primary backends, i.e. back-bdb(5), and back-hdb(5).
Some other backend, like back-sql(5), may fully support them; others
may only support a portion of the described semantics, or even differ
in some aspects. The relevant details are described in the backend-
specific man pages.
And slapd-ldap(5) states:
The ldap backend does not honor all ACL semantics as described in
slapd.access(5). In general, access checking is delegated to the
remote server(s). Only read (=r) access to the entry pseudo-attribute
and to the other attribute values of the entries returned by the
search operation is honored, which is performed by the frontend.
A similar statement appears in slapd-relay(5):
The relay backend does not honor any of the access control semantics
described in slapd.access(5); all access control is delegated to the
relayed database(s). Only read (=r) access to the entry pseudo-
attribute and to the other attribute values of the entries returned by
the search operation is honored, which is performed by the frontend.
So yes, as clearly documented, there is no way to use ACLs to enforce
bind policies unless you're using back-bdb, back-hdb or back-sql.
An alternative consists in using the rewrite engine of slapo-rwm(5) to
intercept binds and do filtering for you. Something along the lines of
the example in slapo-rwm(3) that defines and uses a map called
"attr2dn". Beware that this is not trivial and may result in
significant overhead, as it will likely need to perform internal
requests for each bind operation.
Ing. Pierangelo Masarati
OpenLDAP Core Team
via Dossi, 8 - 27100 Pavia - ITALIA
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497