I have an asp.net mvc 3 app installed on IIS6 and I am getting ACL errors (401.3 errors) when trying to access it. It is running as a virtual app under the default web. I have gone through what I believe are the correct security setting on the respective folders.
I have given the Network Service and in IUSER_ users access to the root folder of the default web. I have also given access to the microsoft.net, temp and system32 folders under c:\windows.
I still get the 401.3 error. When I set the app to use both anonymous and windows authentication I get prompted for credentials. Entering the credentials allows me to access the app. This means that there is some file/folder that needs permissions.
So I used FileMon to see what was going on. I hit the site and get the ACL error but I see no ACCESS DENIED errors in FileMon nor so I see any reference to the site itself. It is like I never made a request. (Yes I cleared my cache).
I am tapped out on what to do next. Any suggestions on where to look to determine what resources needs permissions?
Thanks in advance!
In order for MVC to work on IIS6, you need to do some configuration changes in IIS. Specifically, you should tell IIS to handle all request, in order to ensure that the .NET routing engine kicks in.
http://haacked.com/archive/2010/12/21/asp-net-mvc-3-extensionless-urls-on-iis-6.aspx/
This is one of the best tutorials on getting MVC to work with IIS6.
Related
I am trying to deploy an asp.net 4 app to a new microsoft server 2008 R2
I have set up the application as I have done dozens of times before and set the folder permissions appropriately.
I have tried setting the application pool name directly to have write permissions
I have tried setting IUSR, IIS_IUSRS, NETWORK SERVICE and Users.
I have confirmed that windows authentication is disabled and anonymous is enabled as well as forms authentication is enabled. Logging in works fine i can access all pages normally except if i try to write to the folder. Then a password is required box pops up which looks like windows authentication (even though its disabled)
Every post here states and in my past experience says if I set the folder permissions for the defaultidentity application pool it should work, but for some reason this server wont let me do it!
Any help would be most appreciated.
Welp this turns out to be a really weird one. For some reason when SQL reporting services is installed it reserves the folder name "Reports" in any IIS Web application folder regardless of whether your actually using Reporting services. Its not created by default or anything, but if you happen to create folder titled "Reports" dont expect to access anything from it. After many hours of frustration it turns out it's a random reservation which doesn't throw any error just somehow overrides your authentication protocol to use windows authentication for their reserved folder.
Thanks Microsoft!
We have an old ASP.NET application hosted in IIS6/Win2k3. It's a document generation application that uploads the documents to SharePoint 2003. The application uses an application pool under the user sharepointservice, which is the administrator of the SharePoint site. The web application, which has been recently migrated to .net 2.0 from 1.1, uses NTLM authentication to identify our intranet users.
As the IT administrators are on holidays, I, the developer, has been given local admin rights to the Win2k3 box. The issue is, whenever I deploy the website, though the documents are uploaded appropriately to the SharePoint site via the application, the users are not able to download them. The error is
HTTP Error 403 - Forbidden: Access is denied
I know the IT guys use a service account, not their domain user accounts.
I have already tried to modify the permissions in IIS for that website. I even put Everyone and <Domain>\Users to have read access to all of those folders, to no avail. I've scoured the net, there are no definitive answers. Am I missing something else?
I hate answering my own question, but this did it for me:
The application pools for the SharePoint site were modified from the default. So I reset them, including the AppPools for _layouts, _vti_bin, and _wpresources. Their AppPools are now the default, and are the same.
This link gave me the lead.
You are probably being prompted by permissions for the file system. Check the directories where IO is happening and make sure the user sharepointservice is using in the app pool has read/write permissions.
I just had this problem and solved it after following these instructions:
http://support.microsoft.com/kb/2543306
It seems the webapplication took so long that it hadn't created everything correctly when the IIS timed out. So I was receiving strange errors like yours.
My host is having issues getting my MVC3 app to work on their server, so I though I'd check it out myself. Until now I've been too busy developing under the built in server to worry about IIS, but today I tried my first deployment to the host with no joy. Then I tried one to my local IIS, with no joy. Then I tried telling VS to use IIS for debugging, to maybe resolve some local issues, with no joy.
What steps and configuration are required to use local IIS 7.5 to debug an MVC3 application?
EDIT: Going through a browser, after clearing up a permission problem for my Windows user on Temp ASP.NET Files, I now site with a I get a HTTP Error 403 (Forbidden), but the occassional basic auth login dialogue. Here I have tried a Forms auth user, my normal Windows user, and my Windows admin user, all to no avail.
When I try and debug under VS, I get a 500, internal error.
THE PLOT THICKENS: When I enable directory browsing on the site, I get a proper directory listing for the site root url. This suggests the the MVC3 routing is not working, but why not?
If you're getting a directory listing that means there's not a default file set (for IIS6). It usually means the request wasn't routed to IIS to deal with. thing are slightly different with II7 & it's integrated pipeline.
Simon
Setup
There is an IIS 6 application running in a .NET 2.0 App Pool on Server-A. IIS 7 Server-B needs to host that same code-base under a different URL. I created a virtual directory under Server-B's website to the network path of the application on Server-A. I've enabled this virtual directory on Server-B as an application running in its own .NET 2.0 App Pool in Classic Mode. Both app pools run as the same domain account that has access to that folder.
Issue
When accessing the site from Server-A it works fine. Accessing it from Server-B however generates the infamous "Required permissions cannot be acquired." error.
I have been trying to find a solution to this problem for two days. The two most common solutions have been to check the CLR Trust level on the Server-B box or to set the Load User Profile property on the App Pool to "True". Since I have full administrative rights I set the Trust level to Full and set the profile sitting to "True". Strongly naming all the assemblies the application and throwing them in the GAC is not where I want to go.
I'm sure I'm just missing some configuration somewhere. Any ideas? Thanks.
We have had a similar problem once.
In our case the user that was the identity of the app pool have never logged on to the server. Therefore, there was no local user profile, therefore there was a problem when the system tried to use the profile.
As a test try and set the identity of the app pool to the admin account you use to log in with.
Manually verify that user can access that share. Try logging into windows as that user and then accessing that share (or fake it with something like a "runas /User:{Domain\UserName} net use {\server\share}").
Also try loading ShareMonitor wherever the files actually live. It should tell you what user account is trying to access a given share. It might not be the account you think it is. I cannot recall if it was this program or not, but I have used something very similar in the past to figure out a really odd permission problem.
That should determine if it is a file access problem. If it isn't, then all I can say is to make sure you have ASP.NET enabled (on windows server it is a separate option).
Also check out the file permissions on your "Temporary ASP.NET Files" directory. I've had to explicitly add users write access to that before to get things working.
in my case my IIS App Pool had LoadUserProfile=false, so it was not loading the profile of the app pool's Identify (a domain account). This caused this unable to acquire permissions even though my Webroot files/folders (including /bin) had correct permissions. Setting LoadUserProfile=true fixed the issue for my setup.
I would set that application pools identity attribute (in advanced settings) as administrator. That way, you application will work on the server, just like it works on the local setup.
I have been trying to configure a small website on a Windows Server 2008 running IIS 7. Unfortunately, when trying to load the website I keep getting the error: Server Error 401 - Unauthorized: Access is denied due to invalid credentials.
The permissions on the website folder include read, write, and execute for user ASP.NET v4.0. I even clicked "Check names" before adding the user to folder, to make sure that I spelled everything correctly. But the error continues to show. Also, I noticed that everything works okay if I add "Users" to the permissions for the folders containing the website, but I don't see why this should be necessary. I only want to give ASP.NET v4.0 access to the folder.
Some other noteworthy points include that I'm using the ASP.NET v4.0 application pool, that the managed pipeline is integrated, and that load user profile is set to true.
If anyone has any ideas, I'd appreciated the help. I'm stumped!
EDIT: Does it matter that the website is on the d: drive? I just assumed this wasn't important...
I find I always need to give IIS_IUSRS access.
I'd recommend you to use the Process Monitor to detect which user is actually accessing the file.
Here you'll find an explanation about how to achieve that.
Open IIS7 on the server. Highlight the site, and double-click on the Authentication icon in the Security Section. Check that Anonymous Authentication is enabled.
Some troubleshooting links for this particular issue:
http://support.microsoft.com/kb/902160
http://support.microsoft.com/kb/907273