Nah, you can't lock the process down enough to mitigate enough of the risks for my pallette.
The thing is, I think you're talking about allowing an account to logon locally to a workstation but be locked down like a kiosk account. I had that same conversation with some folks a while back. Interesting how it makes the rounds ;)
Anyhow, to add to the previous, if I understand you correctly and this is similar to the previous conversation I had had, you also are talking about giving out the credentials and the authentication information for an account to logon locally to a workstation. That account, would be able to logon over the network and would be a privileged account able to reset accounts that are locked out/forgot their passwords. I'm further guessing this is to alleviate people from borrowing a neighbor's workstation to access that website. Trying to beat the chicken/egg issue by allowing the user to only utilize their workstation even though they've forgotten their password, thereby reducing the amount of password-forgotten related helpdesk calls.
Is that about it?
If so, I suggest having a look at your password policies first and second to have a look at the true cost of what your forgotten passwords really add up to. Although it can be a large part of your helpdesk volume, it typically is not a large part of your helpdesk time. It often is something that comes up in really large organizations, but in smaller orgs, (less than 50,000 users) is not as big of a time drain in my experience. Still, every little bit helps right?
There are some other ways to make this happen. Can you confirm I understand your issue first though?
-ajm
On 6/26/06, Rob MOIR <[EMAIL PROTECTED]> wrote:
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:ActiveDir-
> [EMAIL PROTECTED]] On Behalf Of AWS
> Sent: 25 June 2006 23:35
> To: ActiveDir@mail.activedir.org
> Subject: [ActiveDir] pw reset domain account
>
> There's a proposal at my company for a self service password reset
> website which uses a shared domain account. It's similar to a kiosk
> configuration, but the intent is to publicize the account and password
> so that it can be used from any users' pc when needed.
>
> They have an account-specific OU/GPO configuration which locks down
the
> typical stuff you would expect, but my position is that there are too
> many unknown vectors for such an account to be abused.
>
> Since I don't dabble in the various black hat utils du jour, does
> anyone have any thoughts on how a globally known domain account could
> be hacked upon? Conversely, is there any way such an account could be
> effectively locked down?
Joe and Laura have already given this the gimlet eye, but I'll add that
we were recently considering this here and threw it out due to security
issues. As Laura points out, you have totally lost any hope of control
or accountability on your whole network with these kinds of accounts
loose on it.
You've got a choice - lock it down like crazy (and there is a problem
with that which I'll come to in a moment) or trust your users. Right, I
don't think so either.
The problem with something like this is that your need to lock the
account down is in conflict with giving it enough rights to perform a
privileged task. So you produce all kinds of odd little hacks and tweaks
so that this account has no rights at all apart from when you need it to
have the sort of rights needed to reset a password (While I'm here, how
do you propose stopping people from being able to hack or DOS another
person's account by resetting it for them?).
Anyway, you start locking your chosen account down. You've got to be
lucky enough to have got there first for every possible attack vector
that a hacker can think of exploiting untraceably with this account. The
hacker only needs to be luckier than you once.
--
Robert Moir
Microsoft MVP for Windows Servers & Security
Senior IT Systems Engineer
Luton Sixth Form College
Right vs. Wrong | Good vs. Evil
God vs. the devil | What side you on?
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
