Open a UNC path with different credentials

[KGLovatt]

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.)

[Gilles LAURENT [MVP]]

"KGLovatt" wrote:

> Hi All,

Hello,

You can try to mount a secure channel with the remote computer using your
admin credentials. After that, all the resources on this remote computer will
be available. For example :

' mount a secure channel with admin credentials (user, pass)
Set oNet=CreateObject("WScript.Network")
oNet.MapNetworkDrive "", "\\" & PC_Name & "\ipc$", False, "user", "pass"
...
' launch explorer here whith your own code
...
' dismount the previously mounted secure channel
oNet.RemoveNetworkDrive "\\" & PC_Name & "\ipc$", True, False

Hope this helps.

--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr

[Al Dunbar]

"KGLovatt" <kglo...@yahoo.co.uk> wrote in message
news:b1dc48c6-b1a9-4c7b...@x38g2000yqj.googlegroups.com...

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

[Gilles LAURENT [MVP]]

"Al Dunbar" wrote:

[...]

> Astute readers here will already know, of course, that the password is
> "$upp0rtM3"... ;-)

ROTFL

[Stefan Kanthak]

"Gilles LAURENT [MVP]" <gl...@free.fr> wrote:

> "KGLovatt" wrote:
>
>> Hi All,
>
> Hello,
>
>> 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.

Use a simple batch, dont fiddle around with the WSH:

NET.EXE USE \\%REMOTE%\IPC$ $upp0rtM3 /USER:SupportUser /PERSISTENT:NO
START /WAIT \\%REMOTE%\C$
NET.EXE USE \\%REMOTE%\IPC$ /DELETE

[...]

> You can try to mount a secure channel with the remote computer using your
> admin credentials. After that, all the resources on this remote computer will
> be available. For example :
>
> ' mount a secure channel with admin credentials (user, pass)
> Set oNet=CreateObject("WScript.Network")
> oNet.MapNetworkDrive "", "\\" & PC_Name & "\ipc$", False, "user", "pass"
> ...
> ' launch explorer here whith your own code
> ...
> ' dismount the previously mounted secure channel
> oNet.RemoveNetworkDrive "\\" & PC_Name & "\ipc$", True, False
>
> Hope this helps.

Stefan

[KGLovatt]

Got it working now, thanks for all your help guys.

but I have to agree with Al - it would be much better to put us all in
a group, and give that group local admins on each PC.
That will be my next venture :-)

I'm building a nice little .HTA application now - will post it here
when I'm all done

Thanks
KGL