|
Home > Archive > IIS Server Security > June 2005 > ASP.NET app permissions
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.NET app permissions
|
|
| curious_Lee 2005-06-07, 7:54 am |
| We've got an ASP.NET 1.1 app that runs fine on LOCALHOST of an XP Pro SP2 box
but won't run on a Windows 2003 server when deployed via XCOPY. It wants to
authenticate against the domain via the challenge popup(which it shouldn't)
and then gives an error about the customErrors being turned off (which they
are). If accessed on the server, it doesn't ask for authentication, but gives
an error
[HttpException (0x80004005): Server cannot access application directory
'D:\www-docs\DASAPPS\imm'. The directory does not exist or is not accessible
because of security settings.]
System.Web.HttpRuntime.EnsureAccessToApplicationDirectory() +72
System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +263
[HttpException (0x80004005): ASP.NET Initialization Error]
System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +982
System.Web.HttpRuntime. ProcessRequestInternal(HttpWorkerRequest
wr) +128
What are the permissions that need to be on an ASP.NET app? I've heard of a
few of them, but do you have a list of accounts (ASPNET, Network Service,
etc.) that must have access to that folder and what level of permissions?
Thank you.
| |
| Jeff Cochran 2005-06-07, 8:48 pm |
| On Tue, 7 Jun 2005 05:19:13 -0700, "curious_Lee"
<curiousLee@discussions.microsoft.com> wrote:
>We've got an ASP.NET 1.1 app that runs fine on LOCALHOST of an XP Pro SP2 box
>but won't run on a Windows 2003 server when deployed via XCOPY. It wants to
>authenticate against the domain via the challenge popup(which it shouldn't)
>and then gives an error about the customErrors being turned off (which they
>are). If accessed on the server, it doesn't ask for authentication, but gives
>an error
>
>[HttpException (0x80004005): Server cannot access application directory
>'D:\www-docs\DASAPPS\imm'. The directory does not exist or is not accessible
>because of security settings.]
> System.Web.HttpRuntime.EnsureAccessToApplicationDirectory() +72
> System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +263
>
>[HttpException (0x80004005): ASP.NET Initialization Error]
> System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +982
> System.Web.HttpRuntime. ProcessRequestInternal(HttpWorkerRequest
wr) +128
>
>What are the permissions that need to be on an ASP.NET app? I've heard of a
>few of them, but do you have a list of accounts (ASPNET, Network Service,
>etc.) that must have access to that folder and what level of permissions?
>Thank you.
Server 2003 uses NETWORK SERVICE. It needs at least READ, but
depending ont he app may need MODIFY on the folder or file.
Check your XCOPY command line also, by default it *should* inherit the
file settings of the folder, not retain permissions from another
system.
Jeff
| |
| curious_Lee 2005-06-08, 7:48 am |
| Thanks, Jeff. Good point. I've added the Network Service, and now receive
this error,
Exception Details: System.Web.HttpException: Access denied to
'D:\www-docs\web.config'. Failed to start monitoring file changes.
The path given above isn't that of the application; this path is to a higher
level folder. The actual path is D:\www-docs\dasapps\imm. We don't have the
ASPNET or the Network Service accounts on the higher level folders. Do they
need to be? And why would it be looking for the Web.config file at the
highest level folder? Thanks.
"Jeff Cochran" wrote:
> On Tue, 7 Jun 2005 05:19:13 -0700, "curious_Lee"
> <curiousLee@discussions.microsoft.com> wrote:
>
>
> Server 2003 uses NETWORK SERVICE. It needs at least READ, but
> depending ont he app may need MODIFY on the folder or file.
>
> Check your XCOPY command line also, by default it *should* inherit the
> file settings of the folder, not retain permissions from another
> system.
>
> Jeff
>
| |
| Tiago Halm 2005-06-10, 5:56 pm |
| Steps to take:
- make sure you set a VDir (Virtual Directory) at the folder root of your
web application.
When w3wp.exe loads a page, it traverses the "IIS file system" upwards until
it finds a VDir. When it finds one, it checks for an AppDomain whose root
directory correspondes to that VDir. If it does not find an AppDomain, it
creates it. The physical directory where the VDir is set is the one where
you need to set the appropriate ACL's.
- look into your web.config and the settings it has
- look into your global.asax (if there's one) and check how its set up and
from where you inherit from
- Make sure to add Read access not to NETWORK_SERVICE itself, but to
IIS_WPG, given this is the (group) account that is standardized to hold the
accounts with which your AppPools can run with. All needed User Rights are
already set to that (group) account.
Tiago Halm
"curious_Lee" <curiousLee@discussions.microsoft.com> wrote in message
news:6B7E9801-216E-454E-B875-1BACD4E7F63B@microsoft.com...
> Thanks, Jeff. Good point. I've added the Network Service, and now receive
> this error,
>
> Exception Details: System.Web.HttpException: Access denied to
> 'D:\www-docs\web.config'. Failed to start monitoring file changes.
>
> The path given above isn't that of the application; this path is to a
higher
> level folder. The actual path is D:\www-docs\dasapps\imm. We don't have
the
> ASPNET or the Network Service accounts on the higher level folders. Do
they[vbcol=seagreen]
> need to be? And why would it be looking for the Web.config file at the
> highest level folder? Thanks.
>
> "Jeff Cochran" wrote:
>
SP2 box[vbcol=seagreen]
wants to[vbcol=seagreen]
shouldn't)[vbcol=seagreen]
they[vbcol=seagreen]
gives[vbcol=seagreen]
accessible[vbcol=seagreen]
+128[vbcol=seagreen]
of a[vbcol=seagreen]
Service,[vbcol=seagreen]
permissions?[vbcol=seagreen]
| |
| www.VoiceInformation.com 2005-06-13, 5:52 pm |
| "Failed to start monitoring file changes" - Watch out for fix described
in http://support.microsoft.com/defaul...b;en-us;Q317955
I was trying to install a Web Mail C# VS.Net project onto one of our
Windows 2000 development machines. Through a painful trial and error
process, I found a series of operations that fixed a problem similar to
yours.
I am going to include the whole chain here so that you can see it in
reference to the other issues.
1) It all started when I built a VS.Net project that ran successfully
on my local machine. When I loaded it onto the Windows 2000 server, and
I went to my site www.TekGuard.com (without specifying \Default.aspx).
The default page was set up correctly in IIS. Then when I specified
\Default.aspx, I would get "Failed to start monitoring file changes".
Problem #1) The browser returned "This Page Cannot Be Displayed", and
IIS logs showed a 403 Error the root directory (ex: www.TekGuard.com),
even though I had set up Default.aspx in IIS under the virtual web
"Documents" | "Enable Default Documents".
I was also getting "Failed to start monitoring file changes" when I
would actually get into the app and run the code within the site.
I tried to fix it using the instructions from
http://support.microsoft.com/defaul...b;en-us;Q317955 (I did
not need to touch any of the subdirectories - the permissions were
inherited automatically). That fixed the "Failed to start monitoring
file changes", but did not fix the fact that I could not access the
default homepage using the root address (i.e., without specifying
\Default.aspx)
Fix #1) "All Tasks" | "Permissions Wizard" | "Select new security
settings from a template" | "Public Web Site". Now I could access the
default homepage using the root address www.TekGuard.com without
specifying \Default.aspx.
2) This then broke my ability to admin the site when on the IIS
machine. I would get "You are not authorized to view this page"
whenever I tried to invoke the admin tools that use SharePoint.
Problem #2) "All Tasks" | "Check Server Extensions 2002" "You are not
authorized to view this page"
Fix #2a) Go to Properties | Directory Security | Edit (Authentication
Methods), Check "Integrated Windows Authentication" is checked
Fix #2b) In a separate instance, but on a related note, after
installing Windows 2003 SP1, I found I could not admin the sites from
the IIS Server machine, and would get the "You are not authorized to
view this page". In this case, I could successfully admin the site from
a remote computer using FrontPage.
I made the fix from
http://support.microsoft.com/defaul...kb;en-us;896861
1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControl
Set\Control\Lsa
2. Right-click Lsa, point to New, and then click DWORD Value.
3. Type DisableLoopbackCheck, and then press ENTER.
4. Right-click DisableLoopbackCheck, and then click Modify.
5. In the Value data box, type 1, and then click OK.
This allowed me to admin the site both from the local IIS machine and
remotely.
#3) When I went to edit portions of the site using FrontPage, FrontPage
said I did not have permission to save the file changes.
Problem #3) FrontPage authoring permissions denied access.
Fix #3) I went back onto the IIS machine, and for the site ran "All
Tasks" | "Check Server Extensions 2002" Detect and Repair.
Now everything seems to be operating normally!
---------------------------------------------------------------------------------------------
Toll Free Automated Attendant Follow-Me Integrated Messaging:
www.VoiceInformation.com
---------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------
Free Mail Server, Anti-Spam Server & PlugIn, Free Source, Unlimited
Users/Domain: www.TekGuard.com
---------------------------------------------------------------------------------------------
|
|
|
|
|