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

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




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.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@opends.dev.java.net
For additional commands, e-mail: users-help@opends.dev.java.net


--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@opends.dev.java.net For additional commands, e-mail: users-help@opends.dev.java.net





--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@opends.dev.java.net For additional commands, e-mail: users-help@opends.dev.java.net



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

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