IIS, Security Templates, and Anonymous Authentication

아티클
07/01/2006

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

Comments

Anonymous
July 02, 2006
Security may not be black and white, but thank you David, for explaining the above points in a black-and-white manner! That was very clear!!
Anonymous
July 03, 2006
Phylyp - Thanks.

It amazes me that despite having all information and interactions documented, nothing pulls it all into comparative context so that it makes useful sense.

Unfortunately, this sort of synthesis is precisely where traditional documentation efforts fail, and it is one of the reasons why I blog... because I got tired of trying to get documentation writers to publish this sort of information on my behalf and WITHOUT their "technical edits" of my writing). And with a blog, I completely bypass that red-tape and directly publish the synthesized facts.

//David
Anonymous
August 23, 2006
The comment has been removed
Anonymous
August 23, 2006
The comment has been removed

다음을 통해 공유