ADSI, password change, password history

[Blake]

Using ADSI, the oUser.ChangePassword enforces the password history.

The oUser.SetPassword does NOT enforce password history

(we are running the setpassword as a user who has permission to set
passwords).

Is there any way to force the setpassword method to respect password
history?

Thanks
Blake

 

[Andrew Mitchell]

Using ADSI, the oUser.ChangePassword enforces the password history.

The oUser.SetPassword does NOT enforce password history

(we are running the setpassword as a user who has permission to set
passwords).

Is there any way to force the setpassword method to respect password
history?

I don't think so.
Using ChangePassword is equivalent to the user changing their password
themself, and all rules are applied.
SetPassword is the same as the administrator selecting Reset Password from
within ADUC, which does not check password history.

Andy.

 

[Al Dunbar [MS-MVP]]

I don't think so.
Using ChangePassword is equivalent to the user changing their password
themself, and all rules are applied.
SetPassword is the same as the administrator selecting Reset Password from
within ADUC, which does not check password history.

Further to this... If the concern is that someone might purposefully re-use
the password assigned by the administrators, and that this would be a
security vulnerability, the best solution is to implement procedures to
prevent this happening. These could include such things as:

- have your account operators run a random password generator script. If
they always use the day of the week and a digit, that is something the user
might remember and go back to. It also becomes easy for others to guess what
it might be.

- have the user come in to the helpdesk, login with the assigned password
(perhaps even have the helpdesk person do this so the user never even knows
what the assigne password was), and change their password before leaving.
Then don't give them a copy of the assigned password for them to take away
with them.

Even if the use inadvertently comes up with a password that happens to be
the same, coincidentally, as a previously helpdesk-set one, I do not see
that as a security issue. Who else would know that they have done so?

/Al

 

[Blake]

That's what I figured.

Thanks

I don't think so.
Using ChangePassword is equivalent to the user changing their password
themself, and all rules are applied.
SetPassword is the same as the administrator selecting Reset Password from
within ADUC, which does not check password history.

Andy.

 

[Blake]

It is a 'self help' process we are developing for our users who forget their
password. We are trying to enforce history regardless of whether they use
setpassword or changepassword.

But thanks anyway.

 

[Al Dunbar [MS-MVP]]

It is a 'self help' process we are developing for our users who forget their
password. We are trying to enforce history regardless of whether they use
setpassword or changepassword.

But your users should never be allowed to use setpassword themselves - that
is a function specifically designed for account admins. It is unsafe because
there is no verification that the password entered was entered correctly and
as the user thought he had typed it.


/Al

 

[Blake]

It is a 'self help' mechanism that our executives have required. You put in
some personal information to "verify" you are who you are and then the
mechanism uses setpassword to give you a new password.

 

[Al Dunbar [MS-MVP]]

It is a 'self help' mechanism that our executives have required. You put in
some personal information to "verify" you are who you are and then the
mechanism uses setpassword to give you a new password.

Eeek! And do these executives think that such an adhoc system is
automatically and of necessity more secure in some way than using the
standard password changing facilities built in to Windows? Sounds a bit like
a boss I once had that simply assumed if you could attach a password to
anything, that made it automatically 100% safe and secure.

Under whose account does this 'self-help' mechanism run - under the account
of the person wanting to change his password? If so, and if the account is
actually being used by a different person, what mechanism prevents them from
setting the password in the normal way if they do no know the user's
personal information? if it is the account of a "friend" who is letting a
person use his account to set his own forgotten one, is that not a violation
of standard security policy?

Where is the personal information stored, and how does it get there? If all
accounts have access to the mechanism, would they not also have access to
whatever the personal information was stored in? Even if they could no
decode the information directly, could they not take a complete copy of the
application and run it on a home computer to guess the boss's personal info,
thereby taking control of his account later on?

What about the IT staff in charge of the application? Could they find out
the personal information without it showing up in a security audit trail?


/Al