Understanding identities in IIS

Understanding identities in IIS

https://support.microsoft.com/en-my/help/4466942/understanding-identities-in-iis

Introduction

---

This article provides background information about identities in Internet Information Services (IIS).

Table of contents

• Application Pool identities
• Default permissions and user rights in wwwroot
• Understanding configuration isolation
• IUSR – anonymous authentication
• ASP.NET impersonation

More information

---

Application pool identities

To understand application pool identities, you have to understand what an identity is. In simple terms, an identity is a Windows account. Every process that runs in Windows runs under an identity. The applications are run by the worker process by using a Windows identity. The Windows identity that is used is dependent on the application pool identity, which can be any of the following accounts:

• Local System: Completely trusted account that has very high privileges and also has access to network resources.
• Network Service: Restricted or limited service account that is generally used to run standard, least-privileged services. This account has fewer privileges than a Local System account. This account has access to network resources.
• Local Service: Restricted or limited service account that is very similar to Network Service and is intended to run standard, least-privileged services. This account does not have access to network resources.
• ApplicationPoolIdentity: When a new application pool is created, IIS creates a virtual account that has the name of the new application pool and that runs the application pool worker process under this account. This is also a least-privileged account.
• Custom account: In addition to these built-in accounts, you can also use a custom account by specifying the user name and password.

Differences between application pool identities

Scenario 1: Event log access

In this scenario, you have one web application that creates a custom event log (MyWebAppZone) and an event log source (MyWebAppZone.com)
at runtime. Applications that run by using any of the identities can
write to the event log by using existing event sources. However, if they
are running under an identity other than Local System, they cannot
create new event sources because of insufficient registry permissions.

For example, if you run the application under Network Service, you receive the following security exception:

When you run the ProcMon trace
simultaneously, you often find that NT AUTHORITY\NETWORK SERVICE does
not have the required Read and Write access privileges to the following
registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\

This is the location in the registry where all the settings of an event log are stored.

The difference between the 'Local System' account and the 'Network Service' account?

Since there is so much confusion about functionality of standard service accounts, I'll try to give a quick run down.

First the actual accounts:

• LocalService account (preferred)

  A limited service account that is very similar to Network Service and meant to run standard least-privileged services. However, unlike Network Service it has no ability to access the network as the machine accesses the network as an Anonymous user.

  • Name: NT AUTHORITY\LocalService
  • the account has no password (any password information you provide is ignored)
  • HKCU represents the LocalService user account
  • has minimal privileges on the local computer
  • presents anonymous credentials on the network
  • SID: S-1-5-19
  • has its own profile under the HKEY_USERS registry key (HKEY_USERS\S-1-5-19)

• NetworkService account

  Limited service account that is meant to run standard privileged services. This account is far more limited than Local System (or even Administrator) but still has the right to access the network as the machine (see caveat above).

  • NT AUTHORITY\NetworkService
  • the account has no password (any password information you provide is ignored)
  • HKCU represents the NetworkService user account
  • has minimal privileges on the local computer
  • presents the computer's credentials (e.g. MANGO$) to remote servers
  • SID: S-1-5-20
  • has its own profile under the HKEY_USERS registry key (HKEY_USERS\S-1-5-20)
  • If trying to schedule a task using it, enter NETWORK SERVICE into the Select User or Group dialog

• LocalSystem account (dangerous, don't use!)

  Completely trusted account, more so than the administrator account. There is nothing on a single box that this account cannot do, and it has the right to access the network as the machine (this requires Active Directory and granting the machine account permissions to something)

  • Name: .\LocalSystem (can also use LocalSystem or ComputerName\LocalSystem)
  • the account has no password (any password information you provide is ignored)
  • SID: S-1-5-18
  • does not have any profile of its own (HKCU represents the default user)
  • has extensive privileges on the local computer
  • presents the computer's credentials (e.g. MANGO$) to remote servers

Above when talking about accessing the network, this refers solely to SPNEGO (Negotiate), NTLM and Kerberos and not to any other authentication mechanism. For example, processing running as LocalService can still access the internet.

The general issue with running as a standard out of the box account is that if you modify any of the default permissions you're expanding the set of things everything running as that account can do. So if you grant DBO to a database, not only can your service running as Local Service or Network Service access that database but everything else running as those accounts can too. If every developer does this the computer will have a service account that has permissions to do practically anything (more specifically the superset of all of the different additional privileges granted to that account).

It is always preferable from a security perspective to run as your own service account that has precisely the permissions you need to do what your service does and nothing else. However, the cost of this approach is setting up your service account, and managing the password. It's a balancing act that each application needs to manage.

In your specific case, the issue that you are probably seeing is that the the DCOM or COM+ activation is limited to a given set of accounts. In Windows XP SP2, Windows Server 2003, and above the Activation permission was restricted significantly. You should use the Component Services MMC snapin to examine your specific COM object and see the activation permissions. If you're not accessing anything on the network as the machine account you should seriously consider using Local Service (not Local System which is basically the operating system).

---

In Windows Server 2003 you cannot run a scheduled task as

• NT_AUTHORITY\LocalService (aka the Local Service account), or
• NT AUTHORITY\NetworkService (aka the Network Service account).

That capability only was added with Task Scheduler 2.0, which only exists in Windows Vista/Windows Server 2008 and newer.

A service running as NetworkService presents the machine credentials on the network. This means that if your computer was called mango, it would present as the machine account MANGO$:

What is the recommended application pool identity to use for Sitecore?

You can use either, but I recommend ApplicationPoolIdentity whenever possible. TBH, your question really isn't Sitecore-specific, but the below info should help to get you started.

Application Pool Identity vs NETWORK SERVICE

The security of ApplicationPoolIdentity will always be greater than or equal to that of NETWORK SERVICE, given that the same access rights are applied to both.

When using AppPoolIdentity, you have a separate identity (security account) for each app pool. This means that you can control the services and securities for your application pool, specifically, agnostic of any other application pools or services. In other words, if you have multiple services and/or applications then ApplicationPoolIdentity is more secure, otherwise it is pretty much the same, though ApplicationPoolIdentity is more extensible (and a bit easier to read in Windows Event Logs, IMHO).

In contrast, NETWORK SERVICE can be used for any/all of your services, i.e. it can be used by more than one without issue. While this sounds like a nice feature that might save you some time, this actually means that if you use it your securities cannot be controlled on a service-by-service or application-by-application basis. All services and/or applications that use NETWORK SERVICE will have the same permissions, which can be a pretty big security risk.

Food for Thought

Imagine that you use NETWORK SERVICE on your site and you also happen to use NETWORK SERVICE on an IIS-based service that a hacker manages to break into. Imagine that the hack allows the hacker to access the server's file system. Because you used NETWORK SERVICE for the application pool's security account, the hacker now has access to your site's folder and to anything that your site had access too. Now, the hacker can not only gain access to your site's ConnectionStrings and web.config, but also to things in your System folder (since Sitecore requires access to some of the System folders), your databases (since they have your ConnectionStrings), and beyond!

More information

This post from iis.net gives a good description of the different security accounts that you can use and their similarities/differences.