That makes good sense as well. Good idea, Rich!
This might even be something that could be integrated directly into the
web
app itself. If you do the setpwd with the new random value and prompted
the
user to supply a new value, if you could hold the new random pwd in memory
so they would not actually see the random value but it would still be used
as input for the changepwd operation.
Some of the details on this would depend on whether this solution was
intended to sup****t users who were logging on interactively or if it was
for
users who were disconnected and relied on a web-based interface for AD
password changes.
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
--
"Rich Raffenetti" <rich@[EMAIL PROTECTED]
> wrote in message
news:Osq0s1D9IHA.5992@[EMAIL PROTECTED]
>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
|
