Sigh... security is never black and white, is it? :-) 

Question:

Environment: IIS6.0 Windows 2003 R2, Windows 2003 level domain. Everything
standard.

1) The Microsoft security guide for IIS6.0 says that the IUSR account needs Log on Locally rights.
2) The Microsoft group policy Enterprise security template for Member Servers removes this right. When the policy is applied, anonymous access is broken.
3) The Member Server template is a baseline for all servers. You are supposed to ADD a Web Server template on top for web servers.
4) The Security Policy guide specifies that if you apply the more restrictive Limited Functionality template to Member Servers, then you need to move the web server out of that OU so the policy is not applied. By inference you don't do this for the standard Enterprise policy template.
5) Question: do the policy templates contradict the security guide?
6) Question: I read somewhere that if you enable Basic authentication, you no longer need the Log on Locally right for anon. Is that correct?
7) Question: I have enabled Advanced Digest authentication with the UseDigestSSP property set in the metabase. This works fine. I read something about this disabling subauthentication, and I recognise that subauthentication is something to do with the way IIS handles the IUSR account. Could it be that with Advanced Digest enabled, the IUSR account no longer works unless it has Log on Locally rights?

Thanks very much,

Answer:

Yup, the security guide and policy template appear to contradict, but it is perfectly alright because security is relative, not absolute. This subtle point is often overlooked. If security was absolute, then any monkey can apply rules to achieve security... but then what would you and I be doing? :-)

  • The IIS Security Guide simply says what is needed by IIS
  • The Group Policy Template can say anything else because its scope is different
  • The templates and guides just give you requirements and information. You have to assemble and decide which is more pertinent and important for your situation and reconcile the differences

Put it another way (extreme example for illustration):

  • Security and Functionality are at odds
  • You want the most secure and functional web server
  • You may read somewhere that the most secure server is one that is not powered
  • You may read somewhere else that the most functional server is one that is powered on
  • Yes, the two statements contradict, but is either wrong? Nope. You just have to figure out the right balance given the information and your requirements.

Enablement of authentication protocols does not have direct correlation with required user privileges. Likewise, enablement of SubAuthentication does not have direct correlation with required user privileges. The LogonMethod used to obtain the user token has direct correlation with the "Log on Locally" user privilege.

See these links for more information:

Yes, that's a lot of information. What do you really need to know between Anonymous, Basic, Advanced Digest, "Log on locally" privilege, and SubAuthentication?

Anonymous and SubAuthentication:

  • Anonymous Authentication's "let IIS control anonymous user's password" feature requires SubAuthentication
  • SubAuthentication requires LocalSystem as the process identity
  • If IIS runs with process identity of LocalSystem, it can obtain a user's token, without knowing the password, by using SubAuthentication
  • On IIS5, IIS runs as LocalSystem and can use SubAuthentication to offer the default feature of "let IIS control anonymous user's password" for the configured anonymous user. This is strictly a "usability" feature so that you do not have to remember to synchronize anonymous user password so Anonymous Authentication should not fail to logon (of course, other failures can still happen with Anonymous Authentication...)
  • On IIS6, IIS runs as Network Service and does NOT offer the "let IIS control anonymous user's password" feature by default (it is not even in the UI) since it would require SubAuthentication and LocalSystem. This a security feature for IIS6, and you have to remember to synchronize anonymous user credentials now. OS upgrade preserves the configuration; otherwise, you have to do extra work to tweak and configure the "let IIS control anonymous user's password" feature

Anonymous, Basic, and "Log on Locally":

  • Anonymous and Basic Authentication obtain user tokens compliant with LogonMethod
  • On IIS5, LogonMethod is INTERACTIVE and thus requires its users to have "Log on locally" privilege
  • On IIS6, LogonMethod is NEWORK_CLEARTEXT and thus does NOT require its users to have "Log on locally" privilege. But of course you can configure LogonMethod to be INTERACTIVE and require "Log on locally" privilege

Anonymous and Advanced Digest

  • Anonymous Authentication's "let IIS control anonymous user's password" feature requires SubAuthentication
  • SubAuthentication requires LocalSystem as the process identity
  • Advanced Digest does not require SubAuthentication
  • Standard Digest requires SubAuthentication

Conclusion

All of these boil down to security improvements in IIS6 vs IIS5:

  • By changing default LogonMethod to NETWORK_CLEARTEXT, anonymous and basic authentication users do not need "Log on locally" privilege
  • By removing SubAuthentication, IIS worker process can run as the less privileged "Network Service" instead of privileged LocalSystem

These changes allow Anonymous, Basic, and Advanced Digest Authentication protocols to function while requiring fewer privileges of the user and process, but there are caveats - you now have to synchronize anonymous user credentials (see this blog entry for a common failure pattern), and legacy applications that require INTERACTIVE may fail.

As always, the choice is up to you as to which is preferable. :-)

//David