[email protected]
[Top] [All Lists]

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

Subject: Re: [ldapext] [Fwd: Re: [OpenDS-users] LDAP Password Modify Extended Operation]
From: Kurt Zeilenga
Date: Sun, 13 Jul 2008 21:30:25 -0700

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, "[email protected]" 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 <[email protected]>
Reply-To: [email protected]
Organization: Sun Microsystems, Inc.
To: [email protected]
References: <[email protected]> <[email protected]> <[email protected]> <[email protected] > <[email protected]>

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
---------------------------- 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: [email protected]
For additional commands, e-mail: [email protected]

[email protected]----
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

[email protected]----
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

 -- 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
[email protected]

Ldapext mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>