File Copy from a Remote Server

[=?Utf-8?B?QWRyaWFuTW9ycmlz?=]

Hello!

I'm trying to copy a file from another computer on the network that I do not
have permission with my current logon details to access.

If I open the folder using the Windows file manager with the path "\\
192.168.2.2\temp" (where temp is a shared directory on server \\192.168.2.2),
windows prompts for a User Name and password of a user who has permission on
that computer to access that directory. If I enter valid details, the folder
is opened and I can copy files from this machine.

How do I do this programmatically in c++ or c#? Standard file open and/or
directory commands do not have the option to enter a valid Username/password
and they just fails with permission denied (understandably).

Regards....Adrian

[Peter Duniho]

On Thu, 31 Jul 2008 12:42:03 -0700, AdrianMorris
<Ad**********@discussions.microsoft.comwrote:

[...]
If I open the folder using the Windows file manager with the path "\\
192.168.2.2\temp" (where temp is a shared directory on server
\\192.168.2.2),
windows prompts for a User Name and password of a user who has
permission on
that computer to access that directory. If I enter valid details, the
folder
is opened and I can copy files from this machine.

How do I do this programmatically in c++ or c#? Standard file open and/or
directory commands do not have the option to enter a valid
Username/password
and they just fails with permission denied (understandably).

I don't know if .NET exposes this directly. Possibly via WMI. One way or
the other though, I know that if you execute a "net use \\<servername>
/user:<username/password:<password>" command, then connections to shares
on the server will use those credentials.

In fact, I often do this from a command-prompt before attaching to
protected shares just because it winds up being faster than waiting for
Windows to figure out it needs to prompt me. :)

Pete

[Larry Smith]

I'm trying to copy a file from another computer on the network that I do

not
have permission with my current logon details to access.

If I open the folder using the Windows file manager with the path "\\
192.168.2.2\temp" (where temp is a shared directory on server
\\192.168.2.2),
windows prompts for a User Name and password of a user who has permission
on
that computer to access that directory. If I enter valid details, the
folder
is opened and I can copy files from this machine.

How do I do this programmatically in c++ or c#? Standard file open and/or
directory commands do not have the option to enter a valid
Username/password
and they just fails with permission denied (understandably).

In C++ you can use the "NetUseAdd()" family of functions or
"WNetAddConnection2()" and cousins. There's probably a wrapper in .NET
somewhere for this, possibly using WMI. Understanding authentication is
really the crux of the issue but that's a deep subject and there are
(potential) trip wires along the way. I can post a primer on basic
authentication if you want however (less than a page). I wrote it for a
colleague a few years back and it will give you an entry-level
understanding. You'll still have to do further research before you can
safely tackle these functions though (and note that just copying a posted
example using these functions or anything higher you might find typically
won't cut it if you want bullet-proof code).

[=?Utf-8?B?QWRyaWFuTW9ycmlz?=]

Hello Larry,

Thanks for these pointers...

If you have any further information, I would really appreciate it!

Regards....Adrian

"Larry Smith" wrote:

I'm trying to copy a file from another computer on the network that I do
not
have permission with my current logon details to access.

If I open the folder using the Windows file manager with the path "\\
192.168.2.2\temp" (where temp is a shared directory on server
\\192.168.2.2),
windows prompts for a User Name and password of a user who has permission
on
that computer to access that directory. If I enter valid details, the
folder
is opened and I can copy files from this machine.

How do I do this programmatically in c++ or c#? Standard file open and/or
directory commands do not have the option to enter a valid
Username/password
and they just fails with permission denied (understandably).

In C++ you can use the "NetUseAdd()" family of functions or
"WNetAddConnection2()" and cousins. There's probably a wrapper in .NET
somewhere for this, possibly using WMI. Understanding authentication is
really the crux of the issue but that's a deep subject and there are
(potential) trip wires along the way. I can post a primer on basic
authentication if you want however (less than a page). I wrote it for a
colleague a few years back and it will give you an entry-level
understanding. You'll still have to do further research before you can
safely tackle these functions though (and note that just copying a posted
example using these functions or anything higher you might find typically
won't cut it if you want bullet-proof code).

[Larry Smith]

Hello Larry,

>
Thanks for these pointers...

If you have any further information, I would really appreciate it!

Ok. The primer I referred to is below. Note that solid info on this stuff
and the SMB protocol under Windows (which is the subject of your post) is
hard to come by IMO. One very good source however is "Programming Windows
Security" by Keith Brown. It's getting old now but still very relevant.
There's a chapter on this very subject in fact. Good luck.

"Here's the (simplified) story (believe it or not). In Windows or any other
OS that implements the
SMB (Server Message Block) protocol (which drives the following scenario),
whenever any
logon session on machine A tries to access a shared resource on any machine
B for the first time
(trying to access a file or folder usually), the file server on machine B
will first try to
authenticate the incoming user so it knows who they are and can therefore
determine what
local resources (file, folders, etc.) they're allowed to access. Note that
the file server runs as a
Windows service and is normally available on all Windows machines (you can
just think of this
as the program that provides access to shared resources on each machine -
"authentication" is
really just the process of logging onto this server for all intents and
purposes). By default the
"user" will be the user associated with the calling thread on machine A and
that normally just
refers to the user who's currently logged onto machine A (though the story
actually runs deeper).
So, for instance, if I log onto "MachineA" as "CA005\lsmith" (my domain
account in the CA005
domain) and I then try to access any file or folder on
"\\MachineB\SomeShare" using Explorer
for instance, the file server on "MachineB" will first try to authenicate
"CA005\lsmith" to
determine that it's really me (otherwise just anyone could come along and
access "MachineB" so
where's the security?). Since I'm a member of a trusted domain ("MachineB"
trusts the CA005
domain controller to vouch for all users in that domain), "MachineB" will
then send my
credentials ("CA005\lsmith") to the CA005 domain controller (where my domain
account is
stored) and the domain controller will then authenticate me accordingly
(verifying that I am in
fact who I claim to be - note that my password is never actually sent across
the wire for security
reasons but how it all works is another story). Once authenticated
(remember, "MachineB" trusts
the CA005 domain controller to do this and authentication is all about
trust), a network logon
session is then created on "MachineB" for "CA005\lsmith" and for all intents
and purposes I'm
now logged onto "MachineB" as if I walked up to it and logged on (even
though I'm still sitting
in front of "MachineA" - note that it's not quite the same as logging onto
"MachineB" directly
since a "network" logon session now exists opposed to an "interactive" logon
session but again,
this is the simple story). Now I can access anything on "MachineB" that
"CA005\lsmith" is
allowed to access and I can do it while still sitting in front of "MachineA"
(so I can now access
all files and folders under "\\MachineB\SomeShare" that "CA005\lsmith" is
allowed to access).
Now, lets' say I log off "MachineA" and logon again using a local account
instead ("swhite" for
instance which is no longer a domain account found on the domain controller
but a local account
created on "MachineA" itself). I'm therefore logged onto "MachineA" as
"MachineA\swhite"
instead of "CA005\lsmith" (all programs I run will then assume this
identity). If I now try to
access "\\MachineB\SomeShare" again, the file server on "MachineB" can no
longer authenticate
me because it now sees someone called "MachineA\swhite" trying to logon and
it doesn't trust
"MachineA" to vouch for "swhite" (like it does the "CA005" domain controller
to vouch for
"lsmith"- the "swhite" account exists on some machine called "MachineA"
which "MachineB"
may have never even heard of and doesn't trust regardless - this is the way
things work in a
Windows domain). "MachineB" will therefore fail to authenticate me and our
old nemesis
"Access Denied" will rear its ugly head on "MachineA" (telling me that
"MachineB" doesn't trust
"MachineA" to vouch for "MachineA\swhite"). To get around this problem you
can generally do
one of three basic things:

1) Create a matching "swhite" account on "MachineB" with the same password
as the "swhite"
account on "MachineA". "MachineB" will then try to authenticate me using the
local account
database (on "MachineB") and so long as the passwords on "MachineA" and
"MachineB" are
kept synchronized, I'll be successfully authenticated (this is how the
Windows file server deals
with accounts whose authorities it doesn't recognize or trust - as long as a
matching account
name and password exist on the local machine, the file server treats the
incoming user as that
particular local user and can log them on) . A network logon session will
then be created as
described earlier but now you'll be running as "MachineB\swhite" instead of
"CA005\lsmith"
(see earlier discussion). You're now effectively logged onto "MachineB" as
if you walked up to it
and logged on as the local "swhite" user (again, a network logon session is
created instead of an
"interactive" logon session however). You can therefore access anything on
that machine that
"MachineB\swhite" is normally allowed to access (even though you're now
doing this on
"MachineA").

2) Activate the "Guest" account on MachineB (disabled by default) and log on
as a "Guest". Let
me know if you want details but it's neither practical nor a secure
alternative.

3) Access "MachineB" using a "NULL Session" but again, it's neither
practical nor secure.

For local accounts, option 1 is therefore your only practical alternative at
a customer site. Also
note that depending on the nature of the application, you can prompt the
user for the credentials
necessary to access MachineB (on the fly) or retrieve them from some secure
source.
"MachineA" can then programatically access "Machine B" using any credentials
it wants (i.e.,
they need not be the credentials of the calling thread which is merely the
default behaviour).
Programming this isn't difficult BTW (once you understand how authentication
works) but let
me know if you want further details (as if this wasn't enough :)"

[=?Utf-8?B?QWRyaWFuTW9ycmlz?=]

Hello Larry,

Many thanks for your help.

I used the "LogonUser" followed by the "ImpersonateLoggedOnUser" functions
and all is working well.

It did involve setting up a local user account on the machine running the
program that matches the Username/Password of a suitable user on the remote
machine as well.

I initially banged my head trying to logon to to remote machine....
unsuccessful.... The solution is to Logon locally and that username and
password is then automatically used when the remote access is made, and all
is well.

Kind Regards....Adrian

"Larry Smith" wrote:

Hello Larry,

Thanks for these pointers...

If you have any further information, I would really appreciate it!

Ok. The primer I referred to is below. Note that solid info on this stuff
and the SMB protocol under Windows (which is the subject of your post) is
hard to come by IMO. One very good source however is "Programming Windows
Security" by Keith Brown. It's getting old now but still very relevant.
There's a chapter on this very subject in fact. Good luck.

"Here's the (simplified) story (believe it or not). In Windows or any other
OS that implements the
SMB (Server Message Block) protocol (which drives the following scenario),
whenever any
logon session on machine A tries to access a shared resource on any machine
B for the first time
(trying to access a file or folder usually), the file server on machine B
will first try to
authenticate the incoming user so it knows who they are and can therefore
determine what
local resources (file, folders, etc.) they're allowed to access. Note that
the file server runs as a
Windows service and is normally available on all Windows machines (you can
just think of this
as the program that provides access to shared resources on each machine -
"authentication" is
really just the process of logging onto this server for all intents and
purposes). By default the
"user" will be the user associated with the calling thread on machine A and
that normally just
refers to the user who's currently logged onto machine A (though the story
actually runs deeper).
So, for instance, if I log onto "MachineA" as "CA005\lsmith" (my domain
account in the CA005
domain) and I then try to access any file or folder on
"\\MachineB\SomeShare" using Explorer
for instance, the file server on "MachineB" will first try to authenicate
"CA005\lsmith" to
determine that it's really me (otherwise just anyone could come along and
access "MachineB" so
where's the security?). Since I'm a member of a trusted domain ("MachineB"
trusts the CA005
domain controller to vouch for all users in that domain), "MachineB" will
then send my
credentials ("CA005\lsmith") to the CA005 domain controller (where my domain
account is
stored) and the domain controller will then authenticate me accordingly
(verifying that I am in
fact who I claim to be - note that my password is never actually sent across
the wire for security
reasons but how it all works is another story). Once authenticated
(remember, "MachineB" trusts
the CA005 domain controller to do this and authentication is all about
trust), a network logon
session is then created on "MachineB" for "CA005\lsmith" and for all intents
and purposes I'm
now logged onto "MachineB" as if I walked up to it and logged on (even
though I'm still sitting
in front of "MachineA" - note that it's not quite the same as logging onto
"MachineB" directly
since a "network" logon session now exists opposed to an "interactive" logon
session but again,
this is the simple story). Now I can access anything on "MachineB" that
"CA005\lsmith" is
allowed to access and I can do it while still sitting in front of "MachineA"
(so I can now access
all files and folders under "\\MachineB\SomeShare" that "CA005\lsmith" is
allowed to access).
Now, lets' say I log off "MachineA" and logon again using a local account
instead ("swhite" for
instance which is no longer a domain account found on the domain controller
but a local account
created on "MachineA" itself). I'm therefore logged onto "MachineA" as
"MachineA\swhite"
instead of "CA005\lsmith" (all programs I run will then assume this
identity). If I now try to
access "\\MachineB\SomeShare" again, the file server on "MachineB" can no
longer authenticate
me because it now sees someone called "MachineA\swhite" trying to logon and
it doesn't trust
"MachineA" to vouch for "swhite" (like it does the "CA005" domain controller
to vouch for
"lsmith"- the "swhite" account exists on some machine called "MachineA"
which "MachineB"
may have never even heard of and doesn't trust regardless - this is the way
things work in a
Windows domain). "MachineB" will therefore fail to authenticate me and our
old nemesis
"Access Denied" will rear its ugly head on "MachineA" (telling me that
"MachineB" doesn't trust
"MachineA" to vouch for "MachineA\swhite"). To get around this problem you
can generally do
one of three basic things:

1) Create a matching "swhite" account on "MachineB" with the same password
as the "swhite"
account on "MachineA". "MachineB" will then try to authenticate me using the
local account
database (on "MachineB") and so long as the passwords on "MachineA" and
"MachineB" are
kept synchronized, I'll be successfully authenticated (this is how the
Windows file server deals
with accounts whose authorities it doesn't recognize or trust - as long as a
matching account
name and password exist on the local machine, the file server treats the
incoming user as that
particular local user and can log them on) . A network logon session will
then be created as
described earlier but now you'll be running as "MachineB\swhite" instead of
"CA005\lsmith"
(see earlier discussion). You're now effectively logged onto "MachineB" as
if you walked up to it
and logged on as the local "swhite" user (again, a network logon session is
created instead of an
"interactive" logon session however). You can therefore access anything on
that machine that
"MachineB\swhite" is normally allowed to access (even though you're now
doing this on
"MachineA").

2) Activate the "Guest" account on MachineB (disabled by default) and log on
as a "Guest". Let
me know if you want details but it's neither practical nor a secure
alternative.

3) Access "MachineB" using a "NULL Session" but again, it's neither
practical nor secure.

For local accounts, option 1 is therefore your only practical alternative at
a customer site. Also
note that depending on the nature of the application, you can prompt the
user for the credentials
necessary to access MachineB (on the fly) or retrieve them from some secure
source.
"MachineA" can then programatically access "Machine B" using any credentials
it wants (i.e.,
they need not be the credentials of the calling thread which is merely the
default behaviour).
Programming this isn't difficult BTW (once you understand how authentication
works) but let
me know if you want further details (as if this wasn't enough :)"