Home > Archive > ASP > November 2005 > ASP Executable over the network
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
ASP Executable over the network
|
|
| RMurray 2005-11-17, 6:55 pm |
| We have an ASP page that calls an executable to change files from one
type to another. We have been running this page for 2 years without
any difficulties. We are attempting to switch it to a new server and
point the executable to a NAS. Now the program fails to execute
properly. We a able to point it to a local drive and it works fine,
and also running the programming manually pointed to the network drive
works fine but the combination of the asp page calling it and pointing
to the NAS isn't working. We have set the user on the page to have
access to the NAS. Setting up the security Audit to pull from both of
the failed and successful logins. Nothing is showing up in the logs
from these attempts. We've been working on this for a couple days so
any ideas you guys might be able to throw out would be very much
appreciated.
Thanks,
Ryan
| |
| BubbaThree 2005-11-17, 6:55 pm |
| You are probably attempting to run under the ASP.NET service which by default
runs under the local system account which does not have the network privs.
You can change the service account or use impersonation to run under the
end-user account. Add
<identity impersonate="true"/>
<authentication mode="Windows"/>
in the <system.web> to the Web.Config file.
"RMurray" wrote:
> We have an ASP page that calls an executable to change files from one
> type to another. We have been running this page for 2 years without
> any difficulties. We are attempting to switch it to a new server and
> point the executable to a NAS. Now the program fails to execute
> properly. We a able to point it to a local drive and it works fine,
> and also running the programming manually pointed to the network drive
> works fine but the combination of the asp page calling it and pointing
> to the NAS isn't working. We have set the user on the page to have
> access to the NAS. Setting up the security Audit to pull from both of
> the failed and successful logins. Nothing is showing up in the logs
> from these attempts. We've been working on this for a couple days so
> any ideas you guys might be able to throw out would be very much
> appreciated.
>
> Thanks,
> Ryan
>
>
| |
| Turkbear 2005-11-17, 6:55 pm |
| On 17 Nov 2005 12:40:50 -0800, "RMurray" <starcru e@gmail.com> wrote:
>We have an ASP page that calls an executable to change files from one
>type to another. We have been running this page for 2 years without
>any difficulties. We are attempting to switch it to a new server and
>point the executable to a NAS. Now the program fails to execute
>properly. We a able to point it to a local drive and it works fine,
>and also running the programming manually pointed to the network drive
>works fine but the combination of the asp page calling it and pointing
>to the NAS isn't working. We have set the user on the page to have
>access to the NAS. Setting up the security Audit to pull from both of
>the failed and successful logins. Nothing is showing up in the logs
>from these attempts. We've been working on this for a couple days so
>any ideas you guys might be able to throw out would be very much
>appreciated.
>
>Thanks,
>Ryan
If I rememebr correctly,the asp page has no 'user' when it tries to access a file on another server...The Anonymous IIS
user ( I think IUSR_Machinename) is actually doing the access so that user needs access granted..
But, Its been a while since I had to do something like this, so 'grain of salt' time...
| |
| RMurray 2005-11-17, 6:55 pm |
| We set the anonymous user to an account that does have access to the
share (in fact to test our theory we set it to an Administrator for a
short while) but it still is not working. I should point out that we
are currently running Windows 2000 on the web server and 2003 Appliance
Edition on the NAS. So unfortunately it looks like this isn't the
case... I will check the local security policy though and make sure
there isn't anything in there that I'm missing.
|
|
|
|
|