[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [ldapext] draft-behera-ldap-password-policy - bind behavior w hen pwd must be changed
Hi,
This is an excellent discussion but I would like to add one thought
regarding the pwdReset attribute.
In most organisations I have worked with, there is a security requirement
that has always proven difficult to implement:
"A user should be suspended if they do not change their password
within N days of an administrative reset."
I have normally got round this by defining an attribute similar to pwdReset
but placing a date in the attribute rather than simply making it Boolean.
But this requires some knowledge of whether or not the user has subsequently
changed their password.
I agree with Andrew's interpretation of Administrator as this must not be
intended to mean "directory manager".
Mark
-----Original Message-----
From: Andrew Sciberras [mailto:andrews@adacel.com.au]
Sent: Tuesday, November 18, 2003 4:26 PM
To: 'Michael Ströder'
Cc: Ldapext (E-mail)
Subject: RE: [ldapext] draft-behera-ldap-password-policy - bind behavior
when pwd must be changed
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