Normally when setting up IIS 7, I'm used to allowing permissions to user IIS APPPOOL\{application pool name} on the root folder of my web application(s). I also give permissions to IUSR (or the IIS_IUSRS user group. (Note, in Windows Server 2008, I found that IUSR isn't in that group by default, so I added it).
In Windows Server 2008, I cannot find user IIS APPPOOL\{application pool name} under Security under the Windows Folder Properties. I'm using Windows Authentication in ASP.NET. I'm receiving a 401.1 on the page in Internet Explorer 8 after getting the authentication prompt. Mozilla Firefox also gave me a Windows authentication prompt, and got me into the site fine. Same with Google Chrome.
How can I solve this one?
HTTP Error 401.1 - Unauthorized You do not have permission to view this directory or page using the credentials that you supplied.
Specific page information:
Module: WindowsAuthenticationModule
Notification: AuthenticateRequest
Handler: PageHandlerFactory-ISAPI-4.0_32bit
Error Code: 0x8009030e
Requested URL: http://.....aspx
Physical Path: C:\.........aspx
Logon Method: Not yet determined
Logon User: Not yet determined
This is most likely because IE will use your authenticated credentials rather than the anonymous user account. If your authenticated user doesn't have access then it will fail. One solution is to add your authenticated user to the site's root folder. With IE your credentials that you're using on the network will pass through to the site, but with the other browsers it will ask for a fresh set of credentials.
Your link in the 3rd comment sounds like a good lead. Did you try turning off Negotiate and seeing what happens? Changing the trusted and intranet zones in the 4th link is a good idea too.
btw, In Windows Server 2008 the IIS_IUSRS is taken care of virtually on the fly, so adding IUSRS doesn't hurt anything, but it's not needed either.
This short description was caused me to understand and clarify the subject for me.
Application Pool Identity Accounts
Worker processes in IIS 6.0 and in IIS 7 run as Network Service by default. Network Service is a built-in Windows identity. It doesn't require a password and has only user privileges; that is, it is relatively low-privileged. Running as a low-privileged account is a good security practice because then a software bug can't be used by a malicious user to take over the whole system.
However, a problem arose over time as more and more Windows system services started to run as Network Service. This is because services running as Network Service can tamper with other services that run under the same identity. Because IIS worker processes run third-party code by default (Classic ASP, ASP.NET, PHP code), it was time to isolate IIS worker processes from other Windows system services and run IIS worker processes under unique identities. The Windows operating system provides a feature called "virtual accounts" that allows IIS to create a unique identity for each of its application pools. Click here for more information about Virtual Accounts.
Configuring IIS Application Pool Identities
If you are running IIS 7.5 on Windows Server 2008 R2, or a later version of IIS, you don't have to do anything to use the new identity. For every application pool you create, the Identity property of the new application pool is set to ApplicationPoolIdentity by default. The IIS Admin Process (WAS) will create a virtual account with the name of the new application pool and run the application pool's worker processes under this account by default.
To use this virtual account when running IIS 7.0 on Windows Server 2008, you have to change the Identity property of an application pool that you create to ApplicationPoolIdentity. Here is how:
To do the same step by using the command-line, you can call the 'appcmd' command-line tool the following way:
%windir%\system32\inetsrv\appcmd.exe set AppPool <your AppPool> -processModel.identityType:ApplicationPoolIdentity
The full document can be read at: Application Pool Identities
I had the same issue in Server 2012 -- for whatever reason it was not creating the virtual accounts (or they were not available for use). -- I believe it's related to the AppHostSvc
or the NetMan
service not running. -- Ultimately, I took a shotgun approach to fixing it (not recommended, try to do as little as possible for a production environment, but this PowerShell might get you out of a pinch in your dev. environment):
#Requires -Version 4
#Requires -RunAsAdministrator
#######################################
$DebugPreference = "SilentlyContinue";
$VerbosePreference = "SilentlyContinue";
$WarningPreference = "Continue";
$ErrorActionPreference = "Stop";
Set-PSDebug -Strict;
Set-StrictMode -Version 3;
#######################################
Get-WindowsOptionalFeature -Online `
| where { $_.FeatureName -ilike "*IIS*" -and $_.State -eq "Disabled" } `
| % { Enable-WindowsOptionalFeature -Online -FeatureName $_.FeatureName -All };
iisreset
Get-Service | ? { $_.ServiceName -eq "W3SVC" } | Start-Service;
Get-Service | ? { $_.ServiceName -eq "W3SVC" } | Set-Service -StartupType Automatic;
Get-Service | ? { $_.ServiceName -eq "WMSvc" } | Start-Service;
Get-Service | ? { $_.ServiceName -eq "WMSVC" } | Set-Service -StartupType Automatic;
Get-Service | ? { $_.ServiceName -eq "AppHostSvc" } | Start-Service;
Get-Service | ? { $_.ServiceName -eq "AppHostSvc" } | Set-Service -StartupType Automatic;
Get-Service | ? { $_.ServiceName -eq "Netman" } | Start-Service;
Get-Service | ? { $_.ServiceName -eq "Netman" } | Set-Service -StartupType Automatic;
iisreset
User contributions licensed under CC BY-SA 3.0