Lots of overloaded terms here, and a change between IIS 7 and 7.5.
App Pool Identity vs App Pool Account
Let's start with the Application Pool identity (lowercase-i-identity, what I call the App Pool Account to avoid ambiguity):
The way I tell it, the Application Pool Account is the account used to boot an App Pool, and the identity that the App Pool assumes when it's not impersonating anyone else.
So whatever identity you give the App Pool, it's going to need to be able to read the files in the content folder: particularly {but not limited to} any web.config files (which form part of the IIS configuration, and control what the App Pool is going to be doing).
If it can't access a folder, it'll assume there might be an important (game-changing) web.config file in there, and display an error. So the App Pool Account needs Read access to all content folders.
ApplicationPoolIdentity
Why differentiate the App Pool Account (the identity of the app pool) from the App Pool Identity? Because the special-capitals-used ApplicationPoolIdentity is a new account type - a managed service account - introduced and made default in IIS 7.5 / Windows 2008 R2, and available from Windows 2008 SP2 as well (but not the default).
See Application Pool Identities on IIS.Net
When you create a website under 2008 R2 or later using the GUI:
- an App Pool will be created to host that website, and
- the account type will be ApplicationPoolIdentity, instead of Network Service (the 2008 default), Local Service or Local System
- a virtual identity, IIS AppPools\AppPoolName will be made available for use as a security principal on the local machine
With 2008 RTM, the default App Pool account was Network Service plus a unique app pool identity/uniquifier; the new R2/SP2 AppPoolIdentity account type is a Network-Service-like account (i.e. is the computer when connecting off-box), but prevents impersonation of another App Pool within the same box.
Back to the original question:
App pool account defines who your app runs as when it's not impersonating anyone else
Authentication method describes how you're going to authenticate the clients (in order to impersonate them)
The Anonymous user account defines who you're going to run as when impersonating a user for a request which isn't authenticated - IUSR is such a user.
Incidentally, with IIS 7.5+, you can set the Anonymous user account to be the Application Pool Identity (properties of the Anonymous authentication method), which might make it more straightforward to isolate and secure the content for a given website.
Set permissions using IIS AppPool\YourSiteName for the name format (see this post).
I also had this issue occur when I switched my IIS application pool account from NetworkService to a domain user account. I could not access the site externally (401 - Unauthorized), but on the server itself I could access the site.
The issue seems to be linked with Kerberos authentication. IIS 7 attempts to use Kerberos first and can't authenticate properly - (must require more configuration). If you disable Kerberos, you might find that you can actually access the website from an external machine:
You can perform a quick test to check if your issue relates to Kerberos authentication by:
- In Internet explorer open Tools > Internet Options > Advanced > Security > Enable Windows Integrated Authentication - UNCHECK this option. This forces IE to authenticate with your site (or any site) using NTLM only. If you can successfully authenticate, then your issue is that Kerberos isn't fully configured.
This issue occurred for me several times when i migrated sites from IIS6 (defaults to NTLM) to 7 (defaults to Kerberos). I did not want to configure Kerberos, so instead i forced my IIS web server to use only NTLM with the following command:
cscript "F:\inetpub\AdminScripts\adsutil.vbs" set w3svc/NTAuthenticationProviders "NTLM"
The default value is "Negotiate,NTLM". To check your existing value, use:
cscript "F:\inetpub\AdminScripts\adsutil.vbs" get w3svc/NTAuthenticationProviders
If anyone has a deeper understanding of why Kerberos authentication fails please let me know. Also, if anyone knows how to force NTLM authentication only for specific application pools rather than the entire IIS web server please also let me know.
Best Answer
It depends on what you are using the application for and how its authentication works. If the application requires the user's credentials to actually do anything, giving everyone (that being everyone in your domain, excluding guests) access may not be a bad idea at all.
If you do want to restrict access to specific people, the best practice is to create a group and give them the required access (probably read/execute). You could also ensure the group is denied access to configuration files, for instance, and create a "support" group for that application as well that has more access.
In the end, whatever credentials are being used (anonymous auth really just impersonates some specific account you provide for that purpose) need to have read and possibly execute and traverse permissions in the filesystem to access the website.
From your comment above, if you do need to know which specific domain users are accessing it, definitely keep anonymous auth disabled, but if you don't need to limit access to a subset of domain users, there is no harm in granting access to the domain everyone.