Can't select IUSR for running a service under

Question

We have a Windows 2008 R2 box running IIS 7.5 which due to a security requirement we need to set the World Wide Web Publishing Service to run under IUSR. I can give IUSR folder permissions just fine. But when I try to select IUSR for the account to run under for World Wide Web Publishing Service I get a message saying that the user cannot be found. Currently we have the service running under "Local System Account". Any help would be greatly appreciated.

Answer 1

IUSR is the security context used when anonymous visitors browse your website. I would recommend against using it for the WWW service.

Prior to IIS7.5, a service account (IWAM) would be created for you that was a local account in addition to the local IUSR account. The new model is to run with different application pool identities so that one web site can't affect another one on the box if a site is compromised. I'd probably consider an unprivileged local account for the WWW service, to confine the credentials to that particular box.

I tested using a local user for WWW and the Windows Process Activation Service, and kept getting error messages of "this account isn't privileged enough" for the Windows Process Activation Service. So I added the local account to IIS_IUSRS and any other IIS-related group, and went into local security policy and added the privileges in Local Security Policy's User Rights Assignment:

• Replace a process-level token
• Adjust memory quotas for a process
• Generate security audits
• Log on as a batch job

That didn't work, so I added "Create global objects" after finding something in google suggesting that might help. It didn't. But then it was time for me to go home, so I undid it all (even though it was a test environment).

I then tried

• Impersonate a client after authentication

No joy. The services run as Local System, and the link I was working from says,

The Local System account is a powerful account that has full access to the computer and acts as the computer on the network. If a service uses the Local System account to log on to a domain controller, that service has access to the entire domain. Some services are configured by default to use the Local System account, and this should not be changed. The Local System account does not have a user-accessible password.

Sorry, I tried, but I think you're out of luck. You could certainly try giving an account the privileges listed here:

• SE_ASSIGNPRIMARYTOKEN_NAME (disabled)
• SE_AUDIT_NAME (enabled)
• SE_BACKUP_NAME (disabled)
• SE_CHANGE_NOTIFY_NAME (enabled)
• SE_CREATE_GLOBAL_NAME (enabled)
• SE_CREATE_PAGEFILE_NAME (enabled)
• SE_CREATE_PERMANENT_NAME (enabled)
• SE_CREATE_TOKEN_NAME (disabled)
• SE_DEBUG_NAME (enabled)
• SE_IMPERSONATE_NAME (enabled)
• SE_INC_BASE_PRIORITY_NAME (enabled)
• SE_INCREASE_QUOTA_NAME (disabled)
• SE_LOAD_DRIVER_NAME (disabled)
• SE_LOCK_MEMORY_NAME (enabled)
• SE_MANAGE_VOLUME_NAME (disabled)
• SE_PROF_SINGLE_PROCESS_NAME (enabled)
• SE_RESTORE_NAME (disabled)
• SE_SECURITY_NAME (disabled)
• SE_SHUTDOWN_NAME (disabled)
• SE_SYSTEM_ENVIRONMENT_NAME (disabled)
• SE_SYSTEMTIME_NAME (disabled)
• SE_TAKE_OWNERSHIP_NAME (disabled)
• SE_TCB_NAME (enabled)
• SE_UNDOCK_NAME (disabled)

But it might be easier to just get a piece of paper from Microsoft telling you to not do that.

Answer 2

I am also looking at a way to do that. I suspect that the OP has the same requirement as I do. That would be a JITC requirement from the DoD. Here it is:

Check Content: 
1. Go to Start, Administrative Tools, then Services.
2. Right click on service name World Wide Web Publishing Service, Select Properties, then select the Log On tab.
3. The username next to this account is the web service account ID.  If any other user than IUSR is listed, continue to step 4.  If the service account IUSR is used to run the service, this is not a finding.
4. Open a command prompt and enter Net User [service account ID], press Enter.
5. Verify the values for Password last set and Password expires to ensure the password has been changed in the past year, and will be required to change within the coming year.

Fix Text: 
Configure the service account ID, used to run the web-site, to have its password changed at least annually or use the service account IUSR.

Answer 3

So many levels of wrongness here. Really short version: Don't do that!

I strongly suspect that either you're misinterpreting the security requirement, or that it was written without regard for how IIS was designed.

WAS needs to run as Local System. Full stop. It's not accessible remotely, so has a very limited attack surface, i.e. local computer administrators.

One reason it runs as Local System is that it carves up applicationhost.config into distinct portions for each Application Pool, which gets its own isolated copy in Inetpub\Temp\AppPools.

Another is that it launches Application Pool worker processes (W3WPs) with specific identities as configured by the web administrator - i.e. if you say an App Pool has a basic identity of ApplicationPoolIdentity, that's a unique low-privileged account used as the basic process identity when not impersonating someone else.

Yet another is that it's not supported to change the identity of WAS, and it was designed to run as Local System. It's a privileged process.

The WWW Service, which was InetInfo and supported page processing in ages past (i.e. most recently the Windows 2000 timeframe) but isn't any more, might be the target of the recommendation.

But it's not involved in page processing any more (IIS 6+), just in getting HTTP.SYS configured for future use by W3WPs.

So App Pools (specifically, associated Worker Processes) do the actual work, and you can configure their basic identity via the App Pool tab, and the specific account used for anonymous work via the Authentication -> Anonymous settings.

Without seeing the actual written text or understanding its source, something seems malformed somewhere. Or like it was written by someone that knew a bit about standard Win32 services, but not much about IIS.

To secure and isolate an IIS site, and seemingly achieve the intent of the guidance (if not what was written), all you need to do is:

• Use the Application Pool Identity as the anonymous account (or IUSR if your policy requires that, but it reduces security (as it's a common shared account, rather than a unique-per-site account)
• Set permissions on the content so that only IIS AppPool\AppPoolName has Read permission to the content folders

And you're done.