|
Posted by Roger Abell [MVP] on August 31, 2008, 9:49 am
If you were Registered and logged in, you could reply and use other advanced thread options
> Likewise we make users local admins, having found limited-user working to
> cause too many problems. We maintain the local Administrator password with
> a
> small program run from the logon-script. This arrangement has the
> advantage
> that if an installer forgets to set a password, the standardised one will
> be
> set at next logon.
>
> The key thing is to make sure users don't get added to the Domain Admins
> group. I've seen sites that are like this, and it leaves the whole network
> open to attack from any one compromised computer.
>
>> > How does your organizations manage the local administrator account on
>> > workstations? Typically the end-users do run with "administrative"
>> > privileges, but a local admin account is needed to access a machine
>> > offline. So how is this account typically named (i.e. renamed) and
>> > password secured (i.e., complex and only a few people know it)? Then
>> > you have the problem of having to change this password on every
>> > workstation if a member of the IT staff leaves. Just looking for
>> > quick thoughts here, no long treatise on the topic is necessary!
>
I could argue that your entire client infrastructure is open to high risk,
not just of attack/compromise but perhaps more significantly for violation
of information privacy. Consider, any account (you say they are admins)
can get the local admin password from the program used to set that pwd.
It might take a little effort, but I would bet that you cannot prevent that.
So, any accont can obtain a password valid for admin access on any of
the client systems. That basically means that anything stored on any of
those systems is or can be made available. As for network stored data
it would only by a keylogger away.
Roger
PS We have found that users can function without problem as non-admin.
| 
XML site map