Re: [ldapext] Re: Password policy state attributes

["Jim Sermersheim" <jimse@novell.com>]

>>> John McMeeking <jmcmeek@us.ibm.com> 12/03 7:40 AM >>>
>
>Several scenarios have been described which I think need to be clearly
>distinguished:

Yes, thank's John.

>1.  Multiple userPassword (or attribute) values.  For example, an entry has
>userPassword values "secret" and "anothersecret".  I would prefer that
>password policy attributes apply to the entire set of userPassword values.

I would prefer that password policy is limited to be applied to only single-value password attributes.

>I have a hard time with the notion that "secret" is valid and
>"anothersecret" has been reset, or the notion of a single password being
>locked.  Trying to express that state would require tying the policy
>attributes to individual values and likely that the user know passwords to
>get the values or that the values be returned in clear text to make use of
>the results.  Try searching for all entries with expired passwords or
>figuring out from the results which of the user's passwords were expired.

I agree.

>2.  Multiple password attributes used by the server for authentication of a
>single entry, as opposed to 3, below. I think this would require something
>like simple bind using userPassword, DIGEST-MD5 using authPassword, ...
>This seems like a bit of a stretch, but that may be just my limited
>perspective.  If this is a valid scenario, then I would prefer the approach
>Mark Smith favored:
>   pwdExpirationWarned;pwd-userPassword

Ok. This still allows #3, which is the actual use case that prompted the recent discussion of multiple passwords

>If (2) is considered valid, should the passwordPolicyResponse control be
>changed to indicate which password attribute the warning or error applied
>to?

Yes.

>3.  Multiple password attributes, where applications perform
>authentication.  For example, web app retrieves the webPassword attribute
>and compares it to the user entered string.  I don't see password policy
>applying here.  The server is not performing the authentication function
>(no bind request), making the data no different than telephone numbers from
>a directory server perspective.

Ah, but the application is using the Compare operation. The request is that when password policy is applied to some attribute (that the server itself may never use for authN), that the password policy be applied to the Compare operation. This allows many applications to be written without all having to duplicate password policy checking/enforcement.

>To summarize:
>- The policy attributes like pwdExpirationWarned should apply to all
>password values (possibly multiple values of a single attribute) for an
>entry.  

I disagree here. Why not allow this to be per password attribute (ignoring the problem of multi-value attrs)?

>I do not favor trying to support policy attributes for each
>individual value of a single attribute.

Right--that's ugly.

>-  I don't think multiple password attributes are likely to be used within
>a single entry and used to support bind requests.  I could be persuaded
>otherwise, in which case I would like to see something like:
>   pwdExpirationWarned;pwd-userPassword

I wouldn't want to ignore the possibility

>John  McMeeking

Jim
<snip>

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