Guest Smithers Posted August 20, 2007 Posted August 20, 2007 I'm rewriting a small utility app that, amongst other tasks, copies files from the local machine to servers on the local network. The existing implementation executes a batch file that executes the "net use" command to map a drive to each destination server/share. The program then tests via "if (File.Exists())" to ensure that the mappings were successful. I'd like to find a better way to copy the files out to the servers... and eliminate the batch file and "net use" altogether if possible. Is there an easier way to map drive letters than via batch file and net use? Is there a way to copy files without mapping a drive letter at all? I'm developing this with .NET 3.5 beta 2, C#, and the app is to run on Windows Server 2003. Thanks!
Guest Ignacio Machin \( .NET/ C# MVP \) Posted August 20, 2007 Posted August 20, 2007 Re: Alternatives to Net Use Hi, "Smithers" <A@B.com> wrote in message news:O4SM5O14HHA.4436@TK2MSFTNGP03.phx.gbl... > I'm rewriting a small utility app that, amongst other tasks, copies files > from the local machine to servers on the local network. The existing > implementation executes a batch file that executes the "net use" command > to map a drive to each destination server/share. The program then tests > via "if (File.Exists())" to ensure that the mappings were successful. > > I'd like to find a better way to copy the files out to the servers... and > eliminate the batch file and "net use" altogether if possible. You do not need to have the share mapped to the machine, you can simply use an UNC like "\\servername\share\file"
Guest Larry Smith Posted August 20, 2007 Posted August 20, 2007 Re: Alternatives to Net Use > I'm rewriting a small utility app that, amongst other tasks, copies files > from the local machine to servers on the local network. The existing > implementation executes a batch file that executes the "net use" command > to map a drive to each destination server/share. The program then tests > via "if (File.Exists())" to ensure that the mappings were successful. > > I'd like to find a better way to copy the files out to the servers... and > eliminate the batch file and "net use" altogether if possible. > > Is there an easier way to map drive letters than via batch file and net > use? > > Is there a way to copy files without mapping a drive letter at all? > > I'm developing this with .NET 3.5 beta 2, C#, and the app is to run on > Windows Server 2003. A mapped drive is simply an alias for a UNC (Universal Naming Convention) name. Just use the UNC name instead (which is cleaner anyway). IOW, if drive "Z:" is mapped to \\ServerName\ShareName then the command: copy YourFile Z:\SomeFolder is the same as: copy YourFile \\ServerName\ShareName\SomeFolder
Guest Peter Duniho Posted August 20, 2007 Posted August 20, 2007 Re: Alternatives to Net Use Smithers wrote: > Is there a way to copy files without mapping a drive letter at all? Yes. Just specify the filename with the UNC server name. So, if you have \\server\share mapped to d: and would normally copy to the filename "d:\myfile.dat", instead use the filename "\\server\share\myfile.dat". Pete
Guest Smithers Posted August 20, 2007 Posted August 20, 2007 Re: Alternatives to Net Use What about authentication? IIRC when I wrote version 1 of this utility a few years ago (and similar apps over the years before), I had to go with mapping a drive letter because with [net use] I could specify login credentials ("connect as user"); whereas going with a UNC assumes that the source is authenticated to the destination (or is otherwise trusted). -S "Peter Duniho" <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote in message news:13cjnb1hcc4itb5@corp.supernews.com... > Smithers wrote: >> Is there a way to copy files without mapping a drive letter at all? > > Yes. Just specify the filename with the UNC server name. So, if you have > \\server\share mapped to d: and would normally copy to the filename > "d:\myfile.dat", instead use the filename "\\server\share\myfile.dat". > > Pete
Guest Peter Duniho Posted August 20, 2007 Posted August 20, 2007 Re: Alternatives to Net Use Smithers wrote: > What about authentication? Don't know. That is, not without using "net use". Maybe .NET provides a mechanism, but I'm not aware of it. > IIRC when I wrote version 1 of this utility a few years ago (and similar > apps over the years before), I had to go with mapping a drive letter because > with [net use] I could specify login credentials ("connect as user"); > whereas going with a UNC assumes that the source is authenticated to the > destination (or is otherwise trusted). You can use "net use" without mapping a drive letter to authenticate yourself. Of course, even better is configuring the network so that you don't need authentication. If you have an NT domain set up, this is as simple as setting the access rights for the share to include the logged-in user that will be accessing the share. If you don't, you can achieve the same thing by making sure the server computer has a user with the same name and password as that used on the client computer used to connect. There might be some security setting you have to configure to enable this behavior; I don't recall off the top of my head whether this works by default. Barring any of that, executing a "net use \\server\share /user:<username> /password:<password>" will authenticate you for the share, and then you can use the UNC paths without any trouble. You can do this from a command prompt manually or programmatically. Pete
Guest Smithers Posted August 20, 2007 Posted August 20, 2007 Re: Alternatives to Net Use Great feedback (as usual). Thanks! -S "Peter Duniho" <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote in message news:13cjp6mb8shsi87@corp.supernews.com... > Smithers wrote: >> What about authentication? > > Don't know. That is, not without using "net use". Maybe .NET provides a > mechanism, but I'm not aware of it. > >> IIRC when I wrote version 1 of this utility a few years ago (and similar >> apps over the years before), I had to go with mapping a drive letter >> because with [net use] I could specify login credentials ("connect as >> user"); whereas going with a UNC assumes that the source is authenticated >> to the destination (or is otherwise trusted). > > You can use "net use" without mapping a drive letter to authenticate > yourself. > > Of course, even better is configuring the network so that you don't need > authentication. If you have an NT domain set up, this is as simple as > setting the access rights for the share to include the logged-in user that > will be accessing the share. > > If you don't, you can achieve the same thing by making sure the server > computer has a user with the same name and password as that used on the > client computer used to connect. There might be some security setting you > have to configure to enable this behavior; I don't recall off the top of > my head whether this works by default. > > Barring any of that, executing a "net use \\server\share /user:<username> > /password:<password>" will authenticate you for the share, and then you > can use the UNC paths without any trouble. You can do this from a command > prompt manually or programmatically. > > Pete
Guest Smithers Posted August 20, 2007 Posted August 20, 2007 Re: Alternatives to Net Use Quick followup: Is it possible to issue a "net use" without putting it in a batch file and launching that via Process.Start? The end result I'm after is having the destination server name\share names listed in App.config. Then at runtime I check to see if I can access each share prior to attempting to copy files. IF the share is not accessible, then I'm wanting to issue the net use to attempt to authenticate. Only after that fails would the logic give up. I don't want to have to go with a batch file if possible as I implement the net use portion of this. Thanks! "Peter Duniho" <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote in message news:13cjp6mb8shsi87@corp.supernews.com... > Smithers wrote: >> What about authentication? > > Don't know. That is, not without using "net use". Maybe .NET provides a > mechanism, but I'm not aware of it. > >> IIRC when I wrote version 1 of this utility a few years ago (and similar >> apps over the years before), I had to go with mapping a drive letter >> because with [net use] I could specify login credentials ("connect as >> user"); whereas going with a UNC assumes that the source is authenticated >> to the destination (or is otherwise trusted). > > You can use "net use" without mapping a drive letter to authenticate > yourself. > > Of course, even better is configuring the network so that you don't need > authentication. If you have an NT domain set up, this is as simple as > setting the access rights for the share to include the logged-in user that > will be accessing the share. > > If you don't, you can achieve the same thing by making sure the server > computer has a user with the same name and password as that used on the > client computer used to connect. There might be some security setting you > have to configure to enable this behavior; I don't recall off the top of > my head whether this works by default. > > Barring any of that, executing a "net use \\server\share /user:<username> > /password:<password>" will authenticate you for the share, and then you > can use the UNC paths without any trouble. You can do this from a command > prompt manually or programmatically. > > Pete
Guest Larry Smith Posted August 20, 2007 Posted August 20, 2007 Re: Alternatives to Net Use > Is it possible to issue a "net use" without putting it in a batch file and > launching that via Process.Start? > > The end result I'm after is having the destination server name\share names > listed in App.config. Then at runtime I check to see if I can access each > share prior to attempting to copy files. IF the share is not accessible, > then I'm wanting to issue the net use to attempt to authenticate. Only > after that fails would the logic give up. I don't want to have to go with > a batch file if possible as I implement the net use portion of this. Yes you can launch "net use" but I personally don't recommend it. It's normally better to rely on an API than standalone executables (for proper error detection alone). I'm not sure what .NET offers in this area (for handling shared resources) but the WinAPI definitely provides the functionality you're looking for (see "NetUseAdd()" and cousins or "WNetAddConnection2()"). I'm not sure how you intend on authenticating however since you need to secure your passwords (don't store them in a cleartext format IOW). In any case, if your application needs to be bullet-proof then I strongly recommend you learn about authentication first and in particular, how it works with shared resources. There's more to it than what's been presented in this thread so far (and some little known gotchas). Your best bet IMO is to get a copy of "Programming Windows Security" by Keith Brown. It was published some years ago and may be difficult to get now but it's an excellent source of information (and still highly relevant). Chapter 8 describes your particular situation in extensive detail. The following primer might also help. I wrote it some years back for a colleague who was trying to learn about this issue. It's not the complete picture but it does provides a conceptual understanding. 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 ("sbrown" 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\sbrown" 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\sbrown" trying to logon and it doesn't trust "MachineA" to vouch for "sbrown" (like it does the "CA005" domain controller to vouch for "lsmith"- the "sbrown" 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 therefore rear its ugly head on "MachineA" (telling me that "MachineB" doesn't trust "MachineA" to vouch for "MachineA\sbrown"). To get around this problem you can generally do one of three basic things: 1) Create a matching "sbrown" account on "MachineB" with the same password as the "sbrown" 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\sbrown" 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 "sbrown" user (again, a network logon session is created instead of an "interactive" logon session however) so you can now access anything on that machine that "MachineB\sbrown" is normally allowed to access (even though you're now doing this on 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 :)"
Guest Chris Dunaway Posted August 20, 2007 Posted August 20, 2007 Re: Alternatives to Net Use On Aug 20, 1:45 pm, "Smithers" <A...@B.com> wrote: > What about authentication? > IIRC when I wrote version 1 of this utility a few years ago (and similar > apps over the years before), I had to go with mapping a drive letter because > with [net use] I could specify login credentials ("connect as user"); > whereas going with a UNC assumes that the source is authenticated to the > destination (or is otherwise trusted). > > -S > > "Peter Duniho" <NpOeStPe...@NnOwSlPiAnMk.com> wrote in message > > news:13cjnb1hcc4itb5@corp.supernews.com... > > > Smithers wrote: > >> Is there a way to copy files without mapping a drive letter at all? > > > Yes. Just specify the filename with the UNC server name. So, if you have > > \\server\share mapped to d: and would normally copy to the filename > > "d:\myfile.dat", instead use the filename "\\server\share\myfile.dat". > > > Pete You can impersonate a user using code like this: http://tinyurl.com/2jfc37 Chris
Guest clintonG Posted August 22, 2007 Posted August 22, 2007 Re: Alternatives to Net Use Smithers needs to delve into Microsoft's PowerShell which was developed to do tasks exactly the same as those discussed in this news article. PowerShell uses the .NET Framework to abstract away the complexity and need to write lots of code in the same manner we learned the framework does for us with its thousands of methods of classes. <%= Clinton Gallagher NET csgallagher AT metromilwaukee.com URL http://clintongallagher.metromilwaukee.com/ "Smithers" <A@B.com> wrote in message news:O4SM5O14HHA.4436@TK2MSFTNGP03.phx.gbl... > I'm rewriting a small utility app that, amongst other tasks, copies files > from the local machine to servers on the local network. The existing > implementation executes a batch file that executes the "net use" command > to map a drive to each destination server/share. The program then tests > via "if (File.Exists())" to ensure that the mappings were successful. > > I'd like to find a better way to copy the files out to the servers... and > eliminate the batch file and "net use" altogether if possible. > > Is there an easier way to map drive letters than via batch file and net > use? > > Is there a way to copy files without mapping a drive letter at all? > > I'm developing this with .NET 3.5 beta 2, C#, and the app is to run on > Windows Server 2003. > > Thanks! >
Recommended Posts