[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] draft-behera-ldap-password-policy - bind behavior when pwd must be changed
Hello,
Perhaps I'm missing something, but this discussion doesn't make
much sense to me.
As Andrew pointed out several times: in order to change the
password user _must_ first bind to the LDAP server. If an LDAP
authentication client doesn't support password policy controls
that's another matter and I don't see what can the LDAP server do
about it. That is, unless we first change semantics of the
password change operation and introduce the "password must be
changed first" return code. Right?
Cheers,
Dejan
On Wed, Nov 19, 2003 at 08:25:41AM +1100, Andrew Sciberras wrote:
>
> Hi,
>
> >
> >I fully agree with John's analysis.
> >
>
> Thats cool, although I think my differing opinion comes from a certain level
> of ambiguity within the draft.
>
> The decription of pwdMustChange is :
> "This attribute specifies with a value of "TRUE" that users must change
> their passwords when they first bind to the directory after a password is
> set or reset by the administrator."
>
> And pwdReset is:
> "This attribute holds a flag to indicate (when TRUE) that the password has
> been reset and therefore must be changed by the user on first
> authentication"
>
> The problems are:
> * Administrator is never defined
> * The draft never states when the pwdReset value should be set to TRUE
> * The draft doesn't account for the scenario of a reset password (ie.
> pwdReset == TRUE) being changed by an Administrator again.
>
>
> The assumptions i've taken from the draft, into my implemntation, is:
> * An administrator is anyone with the power to change the user's password,
> who isn't the user.
> * If a password, which is being governed by a pwdMustChange policy, is
> changed by my definition of an administrator then the pwdReset value will be
> set to TRUE.
> * If an administrator change dthe password again, the pwdReset value will
> still be TRUE.
>
>
> My implementation was based on my assumptions. And im my implementation, the
> only way your going to get rid of that pwdReset value of TRUE is for the
> user to change the password themselves, which requires a bind operation.
>
> The only way that I can see your proposed solution working is if you and
> other implementations have made different assumptions as to what an
> administrator is.
> If this is the case, then I think we should aim to remove this level of
> ambiguity from the draft.
>
> Catch,
> Andrew Sciberras.
>
> >Ciao, Michael.
>
>
>
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext