Solution: Asp.Net and Smb shares - without impersonation

[Granger Godbold]

I've found a solution to this that I think I like, but I thought it wise to put
it out for all to see so people could punch holes in it as they wished. (Is
there a better way?)

I want a page in an Asp.Net site to be able to open/access a file that's on an
Smb share (ie. "Windows Share", "NetBios Share", etc.). I cannot use the
"ASPNET" username; that's a bad route to take anyhow (got to mess with the
"automatic" password settings and other worms in the can you'll be opening).

At first glance, everyone seems to suggest using the "identity" tag in
web.config to do impersonation. However, it's a huge PITA; there's more to it
than what's described in KB #317012 or at the following
http://msdn.microsoft.com/library/en-us/secmod/html/secmod15.asp
For example, your new user won't have permission to access
System.Diagnostics.Process.GetCurrentProcess().Handle
among other various "gotchas". Impersonation is overkill.



The solution?
Use System.Diagnostics.Process and run "net use" from the Asp.Net application
to authenticate to your network share. The authentication will last just like it
does when you call it from the command line (for the user you execute it as).

I believe this method to be the least invasive on existing code. For me, I have
a File.Exists check first. If that fails, then I try to open the file
(File.OpenText is what I tested with, but File.Open should be the same). If the
exception is

[System.IO.IOException] Logon failure: unknown user name or bad password.

then I do the "net use" call to authenticate and try again. If it's not that
exception, then the file will actually not exist, and you get this error:

[System.IO.FileNotFoundException] Could not find file "<filename>"

and I then let the exception propagate to my error-handling stuff.

 

[Ken Cox [Microsoft MVP]]

Don't you have to give the ASPNET account broad permissions to execute "net
use"? It seems like that's a pretty big security hole.

I'd still prefer to use impersonation to authenticate to the network share.

 

[Paul Glavich [MVP - ASP.NET]]

You could also try defining an application pool (I am assuming IIS6) and
define a specific identity to use/application account that has access to the
requested resource (as well as the same privileges as ASPNET user so that it
can run .Net apps). Alternatively (although I would also view this as
overkill) is you can define a COM+ component (ie. inherit from
ServicedComponent) and install the component that needs to access the remote
resource into COM+. You could then define a specific identity/user account
under which it would run, and again you would give/assign that user the
required access.

Just some other options.

--
- Paul Glavich
Microsoft MVP - ASP.NET

Don't you have to give the ASPNET account broad permissions to execute "net
use"? It seems like that's a pretty big security hole.

I'd still prefer to use impersonation to authenticate to the network share.

I've found a solution to this that I think I like, but I thought it wise
to put it out for all to see so people could punch holes in it as they
wished. (Is there a better way?)

I want a page in an Asp.Net site to be able to open/access a file that's
on an Smb share (ie. "Windows Share", "NetBios Share", etc.). I cannot use
the "ASPNET" username; that's a bad route to take anyhow (got to mess with
the "automatic" password settings and other worms in the can you'll be
opening).

At first glance, everyone seems to suggest using the "identity" tag in
web.config to do impersonation. However, it's a huge PITA; there's more to
it than what's described in KB #317012 or at the following
http://msdn.microsoft.com/library/en-us/secmod/html/secmod15.asp
For example, your new user won't have permission to access
System.Diagnostics.Process.GetCurrentProcess().Handle
among other various "gotchas". Impersonation is overkill.



The solution?
Use System.Diagnostics.Process and run "net use" from the Asp.Net
application to authenticate to your network share. The authentication will
last just like it does when you call it from the command line (for the
user you execute it as).

I believe this method to be the least invasive on existing code. For me, I
have a File.Exists check first. If that fails, then I try to open the file
(File.OpenText is what I tested with, but File.Open should be the same).
If the exception is

[System.IO.IOException] Logon failure: unknown user name or bad password.

then I do the "net use" call to authenticate and try again. If it's not
that exception, then the file will actually not exist, and you get this
error:

[System.IO.FileNotFoundException] Could not find file "<filename>"

and I then let the exception propagate to my error-handling stuff.

 

[Granger Godbold]

No. You don't. I didn't have to change anything on the ASPNET account for it to
work correctly.

Don't you have to give the ASPNET account broad permissions to execute
"net use"? It seems like that's a pretty big security hole.

I'd still prefer to use impersonation to authenticate to the network share.

I've found a solution to this that I think I like, but I thought it
wise to put it out for all to see so people could punch holes in it as
they wished. (Is there a better way?)

I want a page in an Asp.Net site to be able to open/access a file
that's on an Smb share (ie. "Windows Share", "NetBios Share", etc.). I
cannot use the "ASPNET" username; that's a bad route to take anyhow
(got to mess with the "automatic" password settings and other worms in
the can you'll be opening).

At first glance, everyone seems to suggest using the "identity" tag in
web.config to do impersonation. However, it's a huge PITA; there's
more to it than what's described in KB #317012 or at the following
http://msdn.microsoft.com/library/en-us/secmod/html/secmod15.asp
For example, your new user won't have permission to access
System.Diagnostics.Process.GetCurrentProcess().Handle
among other various "gotchas". Impersonation is overkill.



The solution?
Use System.Diagnostics.Process and run "net use" from the Asp.Net
application to authenticate to your network share. The authentication
will last just like it does when you call it from the command line
(for the user you execute it as).

I believe this method to be the least invasive on existing code. For
me, I have a File.Exists check first. If that fails, then I try to
open the file (File.OpenText is what I tested with, but File.Open
should be the same). If the exception is

[System.IO.IOException] Logon failure: unknown user name or bad password.

then I do the "net use" call to authenticate and try again. If it's
not that exception, then the file will actually not exist, and you get
this error:

[System.IO.FileNotFoundException] Could not find file "<filename>"

and I then let the exception propagate to my error-handling stuff.