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

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

Kurt Zeilenga wrote: 
On Jul 13, 2008, at 8:43 PM, Howard Chu wrote:

Looks like we need some clarification of RFC3062... 


The userIdentity string is either an RFC 4514 LDAP string
representation of a DN, or some other string representation of a DN
(LDAP generally allows alternative string representations), or some
string representation of some other authentication identity form (such
as a SASLprep user name used in PLAIN, CRAM-MD5, DIGEST-MD5).

The intent is for the field to carry the same user identity (authcid)
string that the user would normally use for password authentication.
For instance, "kurt@example.com" or "uid=kurt,dc=example,dc=com".

Note that authzid is for representing authorization identities, not
authentication identities.  Hence, it was not my intent that the user
provide an authzid.  However, it would be reasonable for
implementations to accept these IN ADDITION to user's authentication
identity strings.

That seems like a friendly thing to do, but it's blurring the distinction between authcID and authzID, to the point of meaninglessness.

In linguistic terms, the authzID is a Subject (the entity that is acting), and in this op the userID/authcID is an Object (the entity that is being acted on). Semantically they're very different. This blurring seems like A Bad Thing to me.

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

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


-------- Original Message -------
Subject: Re: [OpenDS-users] LDAP Password Modify Extended Operation
Date: Mon, 14 Jul 2008 02:37:30 +0200
From: Anton Bobrov<Anton.Bobrov@Sun.COM>
Reply-To: users@opends.dev.java.net
Organization: Sun Microsystems, Inc.
To: users@opends.dev.java.net
References:<487A7E3E.6030207@stroeder.com>
<487A83B3.4010608@sun.com>  <487A85F2.3020802@stroeder.com>  <487A92DB.3040606@sun.com
<487A97E8.4010008@symas.com> 

yeah, i think it is confusing and should be clarified.
to me [since the same thing used elsewhere] it is what
Kurt did imply, you sure could ask him to comment on
that but as long as its not clarified in the RFC its
somewhat a hanger really. i leave it to Kurt and Ludo
[Ludo, are you reading this ?].

Howard Chu wrote:
Anton Bobrov wrote: 
Michael, its mentioned a bit earlier in that RFC, see
"1. Background and Intent of Use" section there which
specifically talks about that and has a reference to
RFC2829 where related to your question see section 9.
"Authorization Identity".

Oddly enough, RFC3062 could have plainly said that the userIdentity
was
an RFC2829 Authorization Identity, but it doesn't. It says it may (or
may not) be an LDAPDN, and LDAPDNs clearly do not begin with a "dn:"
prefix. Maybe this should be clarified in an IETF forum.

Michael Ströder wrote:
Michael Dugan wrote:
Michael Ströder wrote: 
I'm testing LDAP Password Modify Extended Operation (RFC 3062)
with
OpenDS 1.0. I just sent the new password in the request, bound as
"cn=Directory Manager". Are there any restrictions?

I get the following error:

---------------------------- snip ----------------------------
Protocol error:
The password modify extended request cannot be processed
because it
contained an invalid authorization ID that did not start with
either
"dn:" or "u:". The provided authorization ID string was "cn=Fred
Feuerstein,ou=People,dc=opends,dc=stroeder,dc=local"
---------------------------- snip ----------------------------

Frankly I don't understand what it says. To me it sounds rather
an
error message related to "Who Ami I? ext. op.".

Since "cn=Fred
Feuerstein,ou=People,dc=opends,dc=stroeder,dc=local"
> 
looks like a DN, you
probably need to prefix it with "dn:". For example,

   "dn:cn=Fred Feuerstein,ou=People,dc=opends,dc=stroeder,dc=local"

if not it assumes it is not a DN and tries to use an identity
mapper
to process the request.

Could you please point me to the part of RFC 3062 which talks about
adding a "dn:" prefix?

I only found:

------------------------------------------------------------------
    PasswdModifyRequestValue ::= SEQUENCE {
      userIdentity    [0]  OCTET STRING OPTIONAL
      oldPasswd       [1]  OCTET STRING OPTIONAL
      newPasswd       [2]  OCTET STRING OPTIONAL }
[..]
    The userIdentity field, if present, SHALL contain an octet
string
    representation of the user associated with the request.  This
string
    may or may not be an LDAPDN [RFC2253].  If no userIdentity
field is
    present, the request acts up upon the password of the user
currently
    associated with the LDAP session.
------------------------------------------------------------------

My understanding is that the server has to detect whether it's a
valid
DN or not and act accordingly.

Ciao, Michael. 

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext