Introduction
IIS introduces a new security feature in Service Pack 2 of Windows Server 2008 and Windows Vista. It's called Application Pool Identities. Application Pool Identities allows you to run Application Pools under an unique account without having to create and manage domain or local accounts. The name of the Application Pool account corresponds to the name of the Application Pool. The image below shows an IIS worker process (w3wp.exe) running as the DefaultAppPool identity.
Application Pool Identity Accounts
Worker processes in IIS 6 and 7 run as NETWORKSERVICE by default. NETWORKSERVICE is a built-in Windows identity. It doesn't require a password and it has only user privileges, i.e. 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.
The problem is however that over time more and more Windows system services started to run as NETWORKSERVICE and services running as NETWORKSERVICE can tamper with other services running 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 unique identities for each of its Application Pools. Click here for more information about Virtual Accounts.
Whenever a new Application Pool is created the IIS management process creates a security identifier (SID) representing the name of the Application Pool itself, i.e. if you create an Application Pool with the name "MyNewAppPool" a security identifier with the name "MyNewAppPool" is created in the Windows Security system. From this point on resources can be secured using this identity. The identity is not a real user account however, i.e. it will not show up as a user in the Windows User Management Console.
You can try this by selecting a file in Windows Explorer and adding the "DefaultAppPool" identity to its Access Control List (ACL).
- Open Windows Explorer
- Select a file or directory.
- Right click the file and select "Properties"
- Select the "Security" tab
- Click the "Edit" and then "Add" button
- Click the "Locations" button and make sure you select your machine.
- Enter "IIS AppPool\DefaultAppPool" in the "Enter the object names to select:" text box.
- Click the "Check Names" button and click "OK".
By doing this the file or directory you selected will now also allow the "DefaultAppPool" identity access.
You can do this via the command-line using the ICACLS tool. The following example gives full access to the DefaultAppPool identity.
ICACLS test.txt /grant "IIS AppPool\DefaultAppPool":F
On Windows 7 and Windows Server 2008 R2 the default is to run Application Pools as this security identifier, i.e. as the Application Pool Identity. To make this happen a new identity type with the name "AppPoolIdentity" was introduced. If the "AppPoolIdentity" identity type is selected (default on Windows 7 and Windows Server 2008 R2) IIS will run worker processes as the Application Pool identity. With every other identity type the security identifier will only be injected into the access token of the process. If the identifier is injected content can still be ACLed for the AppPool identity but the owner of the token is probalby not unique. Here is an article that explains this concept.
Accessing the Network
Using the NETWORKSERVICE account in a domain environment has a great benefit. Worker process running as NETWORKSERVICE access the network as the machine account. Machine accounts are generated when a machine is joined to a domain. They look like this:
<domainname>\<machinename>$,
for example:
mydomain\machine1$
The nice thing about this is that network resources like file shares or SQL Server databases can be ACLed to allow access for this machine account.
What about AppPool identities?
The good news is that Application Pool identities also use the machine account to access network resources. No changes are required.
Compatibility Issues with Application Pool Identities
Guidance Documentation
The biggest compatibilty issue with Application Pool Identities is probably the guidance documents written which explicitely recommend to ACL resources for NETWORKSERVICE, i.e. the default identity of the DefaultAppPool in IIS 6.0 and 7.0. Customers will have to change their scripts to ACL for "IIS AppPool\DefaultAppPool" when running on IIS 7.5 (see example above on how to do this).
User Profile
IIS doesn't load the Windows user profile but certain applications might take advantage of it anyway, to store temporary data in it for example. SQL Express is an example of an application doing this. The user profile has to be created to store temporary data in the profile directory or in the registry hive however. The user profile for the NETWORKSERVICE account was created by the system and it was always available. No user profile is created by the system however when switching to unique Application Pool identities. Only the standard Application Pools (DefaultAppPool and Classic .NET AppPool) have user profiles on disk. No user profile is created if the Administrator creates a new Application Pool.
IIS Application Pools can be configured to load the user profile however by setting the "LoadUserProfile" setting to "true".
Summary
Application Pool Identities are a powerful new isolation feature introduced for Windows Server 2008, Windows Vista, Windows 7 and Windows Server 2008 R2. It will make running IIS applications even more secure and reliable.
Related Content
Comments