Re: [ldapext] [Fwd: Re: [OpenDS-users] LDAP Password Modify Extended Operation]

[Kurt Zeilenga <Kurt.Zeilenga@Isode.com>]

On Jul 14, 2008, at 1:48 AM, Howard Chu wrote:

> On the flip side, using an explicitly tagged authzID has the  
> advantage of not making the server try to guess what form of userID  
> has been provided...

If a user (at a UI dialog box) enters:  cn=uid, should that be  
prefixed by dn: or u:.  How is the client to know whether it's a DN or  
a userid?   Likewise, if the user entered uid.domain, how is the  
client to know this is a userid and not some alternative DN format?   
(There are few restrictions on alternative DN formats.)

Just like most clients pass whatever user identity string is inputted  
to simple Bind or SASL/PLAIN bind onto the wire without verification,  
the clients should do the same here.  The server can easily figure  
format its in (based upon local rules).

The u: and dn: prefixes seem to only help the server, they are pain to  
clients.

> As a complete aside, there seems to be a disconnect here - it  
> appears that there ought to be a way to specify which password  
> validation mechanism's password is being changed.

This extension was purposely designed to support only a single  
password per user.

> E.g., it's possible for a user to have a valid directory entry with  
> a local userPassword attribute, as well as a valid password in an  
> external store, e.g. sasldb. (Ugly, but this used to come up  
> frequently.) The local userPassword would be used for Simple Binds,  
> and the sasldb would be used for SASL Binds. Similarly for SASL  
> Binds, not all mechs will necessarily use the same password, so it  
> may be desirable to specify which mech's password to set. (E.g.,  
> SASL/OTP)

-- Kurt
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext