Directory.GetFiles() / DirectoryInfo.GetFiles() on a remote server

[Guest]

Hi,

I've been trying to use Directory.GetFiles() and also
DirectoryInfo.GetFiles() to list files on a remote server using
"\\server_name\dir_name" like paths. It works fine on a test windows app, but
I get an access error message when the code is running on a asp.net app.

First I thought it was just a matter of credentials, so I started to use
windows authentication and impersonate the current user, but I still got the
same message.

Any thoughts? Is it possible to list files on a remote server when code is
running on an asp.net app?


Regards,
Daniel

 

[Steve C. Orr [MCSD, MVP, CSM, ASP Insider]]

Are you sure the user you're impersonating has permission to that server and
file share?
To rule out credential issues once and for all I think you should try
impersonation using your user account since you know for sure that you have
access.

For example, you can add a line similar to this to your web.config file:
<identity impersonate="true" userName="domain\MyUserName">
password="MyPassword"/>

Here's more info on impersonation:
http://msdn.microsoft.com/library/d...-us/cpguide/html/cpconaspnetimpersonation.asp

 

[Guest]

Hi Steve,

Thanks for you help. A really strange thing happened. When I used the
userName and password parameters it worked fine. Then I removed these
parameters and logged in with the same user name and password. Although I
could see that the user was the same, it didn't work.

This is the test code I'm using:

Response.Write(WindowsIdentity.GetCurrent().Name + "<br />");
string[] files = Directory.GetFiles("\\\\ecomponentdc\\Temp");
if(files != null && files.Length > 0)
foreach(string filePath in files)
Response.Write(filePath + "<br />");

And this is the result with and without the web.config parameters:

-> With web.config parameters
E-COMPONENT\daniel.correa
\\ecomponentdc\Temp\New Text Document.txt

-> No web.config parameters
E-COMPONENT\daniel.correa
Access to the path "\\ecomponentdc\Temp" is denied.

As you can see, both times the same user was impersonated, so why didn't it
work the second time? Could there be an IIS configuration, or could it be CAS
related? Any ideas?

Thanks again for your help,
Daniel

Are you sure the user you're impersonating has permission to that server and
file share?
To rule out credential issues once and for all I think you should try
impersonation using your user account since you know for sure that you have
access.

For example, you can add a line similar to this to your web.config file:
<identity impersonate="true" userName="domain\MyUserName">
password="MyPassword"/>

Here's more info on impersonation:
http://msdn.microsoft.com/library/d...-us/cpguide/html/cpconaspnetimpersonation.asp

--
I hope this helps,
Steve C. Orr,
MCSD, MVP, CSM, ASPInsider
http://SteveOrr.net

Hi,

I've been trying to use Directory.GetFiles() and also
DirectoryInfo.GetFiles() to list files on a remote server using
"\\server_name\dir_name" like paths. It works fine on a test windows app,
but
I get an access error message when the code is running on a asp.net app.

First I thought it was just a matter of credentials, so I started to use
windows authentication and impersonate the current user, but I still got
the
same message.

Any thoughts? Is it possible to list files on a remote server when code is
running on an asp.net app?


Regards,
Daniel

 

[BradM]

Steve,

You are trying to authenticate across 3 tiers, client + 2 servers. Standard authentication (NTLM) cannot pass authentication to the second server, only Kerberos can. If you access resources on the same server, NTLM can use the impersonation.

When you code the account details into your page, you were only accessing 2 tiers, ASP server and the "File Server".

For Kerberos, you ASP web server must be setup to "Trust for delegation", your ASP must be able to use Kerberos authentication (not my area).

Firstly, try setup up the ASP server to "Trust for delegation", if you are in an AD environment, this is done on the "general" tab. I have seen instances where the ASP web site must be created post setting the trust. I have not seen any way upto June 2006 of fixing this.