Re: ADSI, password change, password history
From: Al Dunbar [MS-MVP] (alan-no-drub-spam_at_hotmail.com)
Date: 04/12/04
- Next message: Steven L Umbach: "Re: another EFS recovery question"
- Previous message: Dusty Harper {MS}: "Re: tweekui"
- In reply to: Blake: "Re: ADSI, password change, password history"
- Next in thread: Blake: "Re: ADSI, password change, password history"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 12 Apr 2004 13:38:07 -0600
"Blake" <blake_duffey@NOSPAM.hotmail.com> wrote in message
news:uWAH9nLIEHA.3820@tk2msftngp13.phx.gbl...
> 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
> "Al Dunbar [MS-MVP]" <alan-no-drub-spam@hotmail.com> wrote in message
> news:OfGd4LxHEHA.3820@tk2msftngp13.phx.gbl...
> >
> > "Blake" <blake_duffey@NOSPAM.hotmail.com> wrote in message
> > news:usvDFFmHEHA.2164@TK2MSFTNGP12.phx.gbl...
> > > 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
> >
> >
> > > But thanks anyway.
> > > "Al Dunbar [MS-MVP]" <alan-no-drub-spam@hotmail.com> wrote in message
> > > news:OfY0PNlHEHA.3276@TK2MSFTNGP09.phx.gbl...
> > > >
> > > > "Andrew Mitchell" <amitchell@removecasey.vic.gov.au> wrote in
message
> > > > news:Xns94C7D6659F51casey01@207.46.248.16...
> > > > > "Blake" <blake_duffey@NOSPAM.hotmail.com> said
> > > > >
> > > > > > 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.
> > > >
> > > > 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
> > > >
> > > >
> > >
> > >
> >
> >
>
>
- Next message: Steven L Umbach: "Re: another EFS recovery question"
- Previous message: Dusty Harper {MS}: "Re: tweekui"
- In reply to: Blake: "Re: ADSI, password change, password history"
- Next in thread: Blake: "Re: ADSI, password change, password history"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
