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.

That strikes me as less secure than the default. Are you sure you want the WWW publishing service to run under a different context, or could you perhaps be needing to run an Application Pool under a different context (for connections to remote servers and so on)? — Chris McKeown, Jan 13 '14 at 23:19
IUSR is the security context used when anonymous visitors browse your website. I would recommend against using it for the WWW service. What problem are you trying to solve by doing so? Maybe we can help you come up with a workaround. — Katherine Villyard, Jan 14 '14 at 01:35
Thanks for the advice. What would you recommend instead of IUSR? As long as the user we set WWW service to is either IUSR or has a password expiration we are fine by our security requirement. — Ben, Jan 14 '14 at 13:13
The least privileged account possible. 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 a local account, to confine the credentials to that particular box. — Katherine Villyard, Jan 14 '14 at 21:40

Katherine Villyard · Answer 1 · 2014-01-16T23:30:45.470

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.

Okay I have tried running the WWW Service and Windows Process Activation Service(they are tied together) under a local account but end up with an error which states - "Error 1297: A privilege that the service requires to function properly does not exist in the service account configuration." Do you what privileges this user must need or why this could be happening? — Ben, Jan 14 '14 at 22:35
I just tested with my personal workstation and a local administrator account. It successfully changed the service, but failed to start because of related services having different credentials. My googling is not turning up a lot aside from saying it's painful to change the default www service account and that's what application pools are for. :( Do you really have to change the account in services? — Katherine Villyard, Jan 14 '14 at 23:12
The other service it's talking about is most likely the process activation service. Look at the properties for process activation service and you should see that it's tied to the WWW Service. Try changing the credentials for that and see what you get. — Ben, Jan 14 '14 at 23:16
OK, I changed that. I also granted the account the same privileges as local system (http://technet.microsoft.com/en-us/library/dd349799(v=ws.10).aspx) because I got the error message "System error 1297 has occurred. A privilege that the service requires to function properly does not exist in the service account configuration." If it helps looks like people other than you have this problem. http://forums.iis.net/t/1192555.aspx?Running+Windows+Process+Activation+Service+as+Domain+Account — Katherine Villyard, Jan 14 '14 at 23:55
For granting the account the same privileges as local system: Did you simply go to Local Security Policy>>Local Policies>>User Rights assignment to take care of that? How did you know which privileges were the same as local system? — Ben, Jan 15 '14 at 14:11
I mistyped because I was going home. Local Service, which is what it is by default. Let me edit my answer. — Katherine Villyard, Jan 15 '14 at 14:17

score 2 · Answer 2 · answered Apr 01 '14 at 21:22

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.

TristanK · Answer 3 · 2014-01-21T00:50:40.147

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.

Can't select IUSR for running a service under

3 Answers3