they have to change it before use. When they change, the normal password
rules will apply.
Post by Joe KaplanI just thought of a way you might be able to code around this. Try to do
a bind to the directory with the password the user supplied when they
went to reset their password with your tool. If it works, you can
conclude that the password they provided you is their same password and
their account works fine, so they are trying to cheat. :) Fail the self
service reset request.
They can probably still get around that by resetting once and then again
back to the other pwd, but it might help a bit. You could store your own
pwd history in memory to help overcome that, but that increases your risk.
You could also make the self service tool more annoying to use by
requiring more than one question.
You could also force users to change password at next login after the
reset, but that only really helps if they are logging in interactively.
You could also keep track of how frequently people use the tool and
threaten to get them in trouble for using it to frequently. Threats of
policy violations often help. :)
Good luck with whatever you do.
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
Post by JanetteThanks Joe for this. I was afraid this was the way it would be. Now to
let management know how it works, and that if people realise this, they
will always change their password using their secret question and answer.
Regards
Janette
Post by Joe KaplanThis is the normal expected behavior.
SetPassword is intended for administrative resets by the administrator.
Administrative resets need to be able to ignore the min pwd age and
history because they are typically only done in non-standard situations.
SetPassword is often adapted for use in a self-service password reset
capacity, but it was never really intended for that, so the rules that
apply to administrative resets are still enforced there as well.
You cannot change the behavior of SetPassword. However, unless you
somehow had the previous password available, you cannot call
ChangePassword either.
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
Post by JanetteHi,
I am working on a system that requires the implementation of
pwdhistorylength and a minpwdage. Previously the system used
changePassword when the user could remember their password and wanted
to change it, and uses setPassword when they are changing their
password via the help of a secret question and answer. I have just
discovered whilst testing that the setPassword method appears to
ignore the password policy attributes such as pwdhistorylength and
minpwdage. Can anyone explain why this might happen, and if there is
any way of enforcing the password policy regardless of the method that
is called to change the password.
Thanks in advance
Janette