Re: Read Entry control not applicable to Bind Operations

Kurt Zeilenga <[email protected]> Fri, 20 Apr 2012 18:10:29 -0700
Newsgroups gmane.ietf.ldapext
Message-ID <[email protected]>
On Apr 20, 2012, at 9:47 AM, Michael Ströder wrote:

> HI!
> 
> I wonder why RFC 4527 limits the use of the Read Entry control to update
> 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.

> 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.

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