Internet Explorer’s Explicit Security Zone Mappings


[Updated 15 May 2012 to correct a bug involving precedence of Computer policies over User policies.]

I recently worked with some customers who wanted to enumerate which web sites had been assigned to which Internet Explorer security zones.  I.e., they wanted to know which web sites had been assigned to the Intranet zone, which to Trusted Sites, etc.  In the course of this work I uncovered some surprising complexities about site-to-zone assignment rules that had not yet been documented.  This blog post describes those discoveries.  Later today I will post an updated version of IEZoneAnalyzer that lists the sites that have been configured and whether those settings are in effect or ignored. [Update: it’s been posted.]

[I’m not happy with the way the blog software has reformatted this document; rather than spend the day fighting it I’m attaching the original Word doc to this post.]

Overview

Internet Explorer applies a set of rules to associate web sites (URLs) with security zones, based on criteria such as whether the server has a dot in its name.  In addition, group policies, computer settings and user preferences can be used to map specific URLs to specific zones.  For example, you could explicitly add “https://www.contoso.com” to the Trusted Sites zone.  Such site-to-zone mappings are defined under one or more ZoneMap key hierarchies in the registry.  There are five different locations where ZoneMap key hierarchies can be defined, but only one or two of them will be in effect at any particular point in time.  Exactly which settings under which ZoneMap keys are effective depends on a number of circumstances:

 

·         Whether Site-To-Zone-Assignment lists are configured in Computer Configuration and/or User Configuration group policies;

·         Whether the “Security Zones: Use only machine settings” group policy is configured (a.k.a., Security_HKLM_only);

·         Whether Internet Explorer’s Enhanced Security Configuration (ESC) is enabled (Server only);

and, quite surprisingly:

·         Whether or not the program is a 32-bit process on 64-bit Windows; a.k.a., “Windows On Windows 64” or WOW64.

 

Yes, that’s right – in some circumstances, a 32-bit process and a 64-bit process on the same computer can see the same site mapped to different security zones.

 

Also, my testing indicates that there is a bug that results in all URLs being treated as “Internet” zone when both ESC and a Computer or User Site-To-Zone-Assignment list are enabled.

Explicit Site To Zone Rules

The rules for selecting ZoneMap keys are listed below.  Each table shows some combination of the four circumstances described in the overview; following each table is the key or keys that are in effect in those circumstances.  There are separate settings under each ZoneMap key for “ESC on” and “ESC off”.  If ESC is on, only those settings under the EscDomains and EscRanges subkeys are used; if ESC is off, only the settings under the Domains and Ranges subkeys are used.

 

Note that in the tables below, WOW64 set to “Yes” means a 32-bit process on a 64-bit version of Windows.  WOW64 set to “No” means either a 32-bit process on a 32-bit version of Windows or a 64-bit process on a 64-bit version of Windows.

 

 

WOW64

Security_HKLM_only

Computer Site-To-Zone

User Site-To-Zone

Yes

Cleared

Absent

Absent

 

Combines results from

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

User preferences (in HKCU) take precedence over computer preferences

 

 

WOW64

Security_HKLM_only

Computer Site-To-Zone

User Site-To-Zone

No

Cleared

Absent

Absent

 

Combines results from

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

User preferences (in HKCU) take precedence over computer preferences

 

 

WOW64

Security_HKLM_only

Computer Site-To-Zone

User Site-To-Zone

Yes

Set

Absent

Either

 

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

User site-to-zone assignments are ignored if present

 

 

WOW64

Security_HKLM_only

Computer Site-To-Zone

User Site-To-Zone

No

Set

Absent

Either

 

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

User site-to-zone assignments are ignored if present

 

 

WOW64

Security_HKLM_only

Computer Site-To-Zone

User Site-To-Zone

Either

Either

Present

Absent

 

HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

 

 

WOW64

Security_HKLM_only

Computer Site-To-Zone

User Site-To-Zone

Either

Cleared

Present

Present

 

Combines results from

HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

Computer policies (in HKLM) take precedence over User policies

 

 

WOW64

Security_HKLM_only

Computer Site-To-Zone

User Site-To-Zone

Either

Set

Present

Either

 

HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

User site-to-zone assignments are ignored if present

 

 

WOW64

Security_HKLM_only

Computer Site-To-Zone

User Site-To-Zone

Either

Cleared

Absent

Present

 

HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

 

What About “ZoneMapKey”?

 

IT administrators trying to apply site-to-zone settings by directly manipulating registry values often discover two “ZoneMapKey” registry keys that appear to be more interesting than they actually are: specifically, HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey and HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey.  Values under these keys look like the site-to-zone assignments applied through group policy, and in fact they are.  However, these keys are not used directly by Internet Explorer, and if you directly set values there, they will have no effect.  The ZoneMapKey entries are just a temporary writing place for the Group Policy engine, which writes entries there as specified by Group Policy, and then parses them into corresponding ZoneMap subkey settings that are used by Internet Explorer.

 

Explicit security zone mapping rules 1.1.docx

Comments (7)

  1. Anonymous says:

    My testing in a Windows Server 2008 terminal server with IE7 contradicts your otherwise excellent article on one point.

    a) I find that a setting for a site in

    HKLMSOFTWAREPoliciesMicrosoftWindowsCurrentVersionInternet SettingsZoneMap

    takes precedence over any setting affecting the same site under

    HKCUSOFTWAREPoliciesMicrosoftWindowsCurrentVersionInternet SettingsZoneMap

    not the other way round as stated in the article.

    E.g. if foo.com is set as "trusted" in the HKLM policy, there is no way to override that zone assignment for foo.com or any sub domains of foo.com under HKCU.

    b) IP-address zone assignment also deserves a mention: Interestingly, making a zone assignment for an IP address in the machine site-to-zone policy precludes making a site-to-zone assignment *for any other* IP address under HKCU.

    However, a workaround (which I can not find documented anywhere) for this limitation is to create a key for the IP address you wish to assign to a zone directly under ZoneMapDomains (instead of the documented entries under "Ranges", that is:

    HKCUSOFTWAREPoliciesMicrosoftWindowsCurrentVersionInternet SettingsZoneMapDomainsx.y.z.w

    [Aaron Margosis]  On (a) you are probably correct – in general HKLM policies do take precedence over HKCU policies.  I think I may have copy/pasted lines from non-policy stuff earlier in the document (where HKCU overrides HKLM) and failed to re-order
    them when typing in the "Policies" part of the key path.

    Your (b) finding is interesting – I’ll have to test that.

    15-May-2012: Finally had some time to look at (a) and confirmed what you found.  Computer policies do take precedence over User policies, as expected.  The bug was in my write-up here AND in IEZoneAnalyzer v3.5.0.3.  Both have been fixed.  Still need
    to investigate (b) above.

     

  2. Ron D says:

    Great info Aaron. We are continually "adjusting" how to do our site-to-zone. I might add: one other major factor is if users are pointing to autopac files in IE: sites are assigned to Intranet Zone if the autopac rules states "return direct".

  3. Anonymous says:

    I received some questions and comments about Internet Explorer's Explicit Security Zone Mappings

  4. Anonymous says:

    Pingback from IEZoneAnalyzer v3.5 with Zone Map Viewer – Windows Virtualization Team Blog – TechNetKlub

  5. Anonymous says:

    Pingback from Correction posted for IE Explicit Security Zone Mappings and IEZoneAnalyzer's Zone Map Viewer – Microsoft U.S. Partner Team – Partner Community – Microsoft Dynamics Community

  6. Anonymous says:

    IEZoneAnalyzer is a utility for viewing and comparing Internet Explorer security zone settings –

  7. Anonymous says:

    Part of the new functionality of EMET allows you to block or allow plugins in IE based on the zone that