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

RE: [ldapext] draft-behera-ldap-password-policy - bind behavior when pwd must be changed



G'Day!

Purhaps i've misunderstood something, but I have a little trouble agreeing
with the arguments that have been made in this discussion.

I do agree that in the current state of the draft, the 'change after reset'
feature does not accomidate for LDAP Server's being used for authentication
into other systems.
However, failing bind operations is certainly not the solution.

Imagine all the LDAP server's which use the bind operation to authenticate
user's for the purpose of accessing the directory information.

Lets say a new user joins an organization and their password is
automatically set to their Date Of Birth by the administrator.
At the moment, the user would be able to bind to the directory and be
severly restricted in what they can do, until they change their password.
If the bind operation returned a failure, how do you propose that the user
is ever going to be able to change their password?

As far as I can tell, there are two ways that the password is ever going to
be changed.
1. By the user,
2. By someone else.

If we fail binds, the user can never be able to change the password
themselves since they would not be able to authenticate themselves to the
directory.
It would be entirely possible for someone else to change the password,
however this would be pointless. In the Adacel View500 implementation of
this draft, we have made the assumption that if a A's password is modified
by B, and B has sufficient access rights to modify A's password, then B is
an administrator.
This being the case, if B modified A's password for her, then the directory
would automatically reset the pwdReset value to TRUE.


On a different note, the description of pwdReset states the following:
"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."

I think this should be reworded to get rid of the 'first authentication'
part.
There is nothing in the draft that restricts a user from binding a million
times before changing their passwrod.

Regards,
Andrew Sciberras
Software Engineer
Adacel Technologies




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