[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Enhancement request to control the LDAP search depth per entry

Michael Ströder wrote:
> >
> > In the context of a public PKI, we think there is one LDAP function
> > missing to make the certificate publication service usable. Indeed, as
> > it stands, assuming that certificates are needed to be available to
> > anybody (for certificate verification reasons for instance), it is
> > possible for any users to make an exhaustive LDAP search on a particular
> > attribute so that all the certificates of the LDAP basis may be
> > downloaded by the users.
> The amount of search results returned can already be limited.
Yes, but since the 'limits' option is defined in the slapd.conf, it
means that this rule applies on the whole LDAP basis. Perhaps it is
useful to authorize exhaustive search on some LDAP subtrees and to deny
it for others. (it depends on the organization of the LDAP tree)

> > As identifiers within the users'certificates
> > are usually email addresses, it is then possible to make a list of
> > current email addresses of the company's employees and uses it for spam.
> >
> > To prevent that problem, the idea is to authorize access to a subset of
> > LDAP entries or attributes only if the LDAP request specifies the full
> > DN. This limitation would be activated on a per entry (or per attribute)
> > basis.
> You mean limit access to an attribute by search scope?
It may be done like this with the server controlling that search
However, I think the best will be to remain independent of the search
scope and to control that the access to one entry/attribute is possible
only if the full DN is specified in the request.
Actually, I think this requires defining in the slapd.access a new field
(something like 'depth') in the 'access to' directive. As such, it will
be possible to adapt the control on an entry/attribute basis.

> Not sure if that really helps solving the spammer problem since one can make
> an exhaustive search for retrieving all DNs and ask for the limited
> attributes afterwards in single search requests. :-/

So this will be necessary to first inhibit this DNs search possibility,
maybe for an LDAP subtree only, and/or for 'anonymous' type of users.

> Also most e-mail clients do not search for the DN and retrieve the attribute
> 'mail' afterwards. So your approach would make your directory unusable with
> most mainstream software out there.

I consider the context of external users accessing the LDAP server, and
I need to limit access to the LDAP server. For internal users
(=authenticated users) using email clients, the possibility to make a
search on the 'mail' attribute should still be authorized.

> Maybe I did get you wrong though...
Thank you for your feedback. I hope the explanations are clearer.
Best regards