Subject: [ldapext] Read Entry control not applicable to Bind Operations

From: Michael Ströder <[email-masked]>
Date: Fri, 20 Apr 2012 18:47:52 +0200

HI!

I wonder why RFC 4527 limits the use of the Read Entry control to update
operations (Add, Delete, Modify, ModifyDN).

E.g. the pre-read control could be also useful to read the last login time and
number of failed authc attempts and display it to the user *after* a
successful bind. This is a bit tricky since the appropriate ACLs would have to
be applied when reading the attribute values although the user is not already
bound. But this could be internally handled by the server similar to proxy authz.

Ciao, Michael.

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 20 Apr 2012 18:10:29 -0700

> operations (Add, Delete, Modify, ModifyDN).

Because to solve the problem I had at the time, I only needed pre- and post-read entry on update capabilities.

> successful bind.

There's lots of issues here which make this not so simple.

* There is a bad assumption that there is a one and only entry associated with the user.
* There is a bad assumption that the information desired is held in that entry.
* The request and response controls are not protected by the SASL layers established, if any, during the Bind.
* Proper semantics in multi-step SASL bind gets messy.

Lastly, it kind of overlaps with the purposes of the draft password policy control... which arguely should be capable of return a wide range of authentication and service authorization information to the client.

So, even if I was now writing the read-entry spec, I would have strongly opposed including non-update coverage, especially bind coverage, in the spec.

If someone really wants this, they can write a separate spec, reuse all the syntaxes (just define a "feature" for the extension to this control extension).

-- Kurt