I would make your setPassword option give them a new (random) password (not
accept a password) and optionally, as Joe suggested, preexpire it so that
they have to change it before use. When they change, the normal password
rules will apply.
"Joe Kaplan" <joseph.e.kaplan@[EMAIL PROTECTED]
> wrote in message
news:Oa2pp958IHA.356@[EMAIL PROTECTED]
> I 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
> --
> "Janette" <jtowell@[EMAIL PROTECTED]
> wrote in message
> news:%23WroTa58IHA.3368@[EMAIL PROTECTED]
>> Thanks 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
>>
>> "Joe Kaplan" <joseph.e.kaplan@[EMAIL PROTECTED]
> wrote in
message
>> news:O3lt$Zx8IHA.2496@[EMAIL PROTECTED]
>>> This 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
>>> --
>>> "Janette" <jtowell@[EMAIL PROTECTED]
> wrote in message
>>> news:%23apTKds8IHA.5556@[EMAIL PROTECTED]
>>>> Hi,
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
Rich Raffenetti
|
