"KGLovatt" <kglovatt@xxxxxx> wrote in message
news:b1dc48c6-b1a9-4c7b-9995-1ff5e3719e5d@xxxxxx
> Hi All,
> This is the scenario;
> We regularly need to open the C drive on remote PCs, maybe move or
> delete files, then close the C drive again, and we do this by using
> the C$ share so that it doesn't disrupt the user.
>
> We currently use Start/Run \\computername\c$ which works fine, but we
> have to enter our username and password everytime. All of us in
> support use the same name/password to access C$ shares, (SupportUser)
> which is a local admin on every machine on the domain.
>
> Does anyone know how to modify the following so it will automatically
> pass the username (SuportUser) and the password ($upp0rtM3) so that we
> don't have to enter it every time?
>
>
> sub ConnectButton_OnClick
>
> 'NB This will open an Explorer window pointing at the remote C
> Drive
> 'You will have to enter the username/password for C$ access :
>
> strHostName = "\\" & PC_Name & "\c$"
> Set objShell = CreateObject("WScript.Shell")
> strCommand = "explorer " & strHostName
> Set objExecObject = objShell.Exec(strCommand)
>
> (I know we could add all of the support users to the local admins on
> every domain PC, and then it wouldn't ask for the username/password,
> but we're reluctant to do that, our manager wants us to use a password
> that is only known to us ... and is happy to have it scripted because
> the scripts are stored on our secure shared folder which joe public
> can't get to.) My suggestion would be to create a security group in the domain with a name
"workstation admins", add that group to the local administrators group on
all workstations, and then add domain user accounts to the domain group as
needed (ideally these will not be the individual;s normal accounts, but
domain-based workstation admin accounts setup for the purpose).
The reason I say this is that having a bunch of people all using (and
knowing the password to) a local admin account on all workstations is
problematic. If, for example, one of your people were to go postal, imagine
what it would take to ensure that that person's admin access to all the
workstations was effectively removed? You would need to change the local
password on how many machines? And disseminate it to how many non-rogue
individuals to allow them back in?
Using a global group as I suggest would allow you to disable the rogue
user's admin access to all workstations just by removing his/her account
from the domain group. This would also have exactly zero impact on all of
the non-rogue users, as their own accounts would be unaffected.
The rogue user could also change the password in your environment and lock
everyone out but him/herself.
And don't laugh at the idea of the rogue user - questions are regularly
posted here or in "microsoft.public.windows.server.security" about how to
lock these guys out...
With a shared password, you also lose accountability. Supposing something
improper was done on a workstation. In your environment, if the security log
indicated the account that was used, knowing that it was "SuportUser" would
not tell you which individual was responsible. The other problem with a
shared password is this: with care a single individual can likely keep their
own personal password secure; as soon as more than one person knows it, it
is no longer a secret. The mere act of communicating that password to new
staff (or to everyone when the password has been changed) will practically
guarantee that it will come to be known to some who are not authorized to
know it.
If your manager wants you to be using a password known only to you, the one
you logon to the domain with is much more likely to meet the requirement
than the shared password, as there is absolutely no way to find out who else
might know it.
Astute readers here will already know, of course, that the password is
"$upp0rtM3"... ;-)
/Al