FDCC and Internet Explorer 7, Part 1: Security Zones
This multi-part series will discuss various issues regarding Microsoft Internet Explorer 7, particularly with regard to its use on Federal Desktop Core Configuration (FDCC) compliant systems. The FDCC is based on Microsoft’s security guidance for Windows XP and Windows Vista, so this series will likely be of interest to audiences beyond those impacted by FDCC. Topics that will be covered include:
· Primer on IE security zones and how they are controlled and used, including the "Locked Down" zones.
· Impact of FDCC-mandated settings on typical IE users.
· Recommendations regarding "Protected Mode" on Windows Vista.
· Discussion of a bug that impacts the Local Machine zone (a.k.a., the "Computer" zone) on FDCC-compliant Vista computers.
· Introduction of a new tool, IEZoneCompare, to visually identify and compare effective IE security zone policies and preferences.
Internet Explorer Security Zones
In this article:
Zones and Policies
Local Intranet Zone vs. Trusted Sites Zone
The "Locked Down" Security Zones
Zones and Policies
There are many capabilities that can be leveraged by a web browser beyond rendering static HTML. These capabilities can include the ability to run script, to invoke installed mobile code (such as Java or ActiveX), and to manipulate the clipboard. Permission to use some of these capabilities should be granted only to trustworthy content. The concept behind IE security zones is that the source of the content to be rendered by the browser – in other words, where the content came from – can be used to help determine the trustworthiness of that content. Zones that are defined by Internet Explorer include:
· Local Machine (a.k.a., "Computer" or "My Computer") zone is for content that is already found on the local computer (but not in the Temporary Internet Files cache). In the past this had been considered the most trusted content; this was changed by the "Local Machine Zone Lockdown" feature first introduced in Windows XP SP2, and which is described in more detail below.
· Local Intranet zone is for content found on the organization’s intranet.
· Internet zone is for content found on the Internet – this is considered an untrustworthy source for content.
· Trusted Sites are for external sites that are explicitly determined by the user or by the administrator to be more trustworthy than other content on the internet.
· Restricted Sites are for sites that are explicitly determined by the user or by the administrator to be less trustworthy than other content on the internet.
Registry settings determine which capabilities are permitted for each zone. There are dozens of these settings, which are documented in KB 182569. For example, the value "1201" maps to the permissions for "Initialize and script ActiveX controls not marked as safe." These zone settings can be defined in multiple places, with a hierarchy determining which settings are actually in effect:
· Machine Policies (HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones)
· Machine Preferences (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones)
· User Policies (HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones)
· User Preferences (HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones)
Under each of these "Zones" keys are subkeys for each of the security zones:
· 0: Local Machine
· 1: Local Intranet
· 2: Trusted Sites
· 3: Internet
· 4: Restricted Sites
The default precedence order for settings for a particular zone is:
· Machine Policies
· User Policies
· User Preferences
· Machine Preferences
Policies always take precedence over Preferences, so if a registry value exists for a capability in a Policies key, it will override a corresponding setting in a Preferences key for that zone. In a default Windows install, no Policies keys are populated, so only Preferences are in effect. FDCC mandates a bunch of Policies settings, particularly for the Internet zone. Note that all the User Policies keys (starting in HKCU\Software\Policies and HKCU\Software\Microsoft\Windows\CurrentVersion\Policies) are read-only to non-admin users – even though they are in HKCU. Policies are hard to enforce if you let users overwrite them.
Also note that the correct way to populate the Policies is through Group Policy interfaces, not by pushing data directly into those registry keys. The Group Policy interfaces (whether programmatic or interactive tools) ensure that the Group Policy stores (registry.pol files) contain the authoritative settings, and that the GP hierarchy (domain vs. OU vs. local policies) is respected. If you apply settings directly into the registry, they will likely get overwritten or deleted upon the next Group Policy refresh.
By default, User Preferences take precedence over Machine Preferences. By default, Machine Preferences come into play only when a corresponding value does not exist in the User Preferences. However, there is a group policy, "Security Zones: Use only machine settings", which FDCC mandates. With this policy in effect, User Policies and Preferences are ignored – only the Machine Policies and Preferences are used. This helps ensure that non-admin users do not override administrative security choices.
Note that the Security tab of the Internet Properties dialog shows User Preferences only. And when Policies are in effect, most or all of the Security tab UI is disabled, with a label at the bottom explaining, "Some settings are managed by your system administrator".
"Templates" define a collection of settings that can be applied to a zone as a comprehensive group. These collections appear in the IE Security tab as security levels "High", "Medium-high", "Medium", "Medium-low", and "Low". When you set a particular zone to one of these levels, it copies the settings for that template to the User Preferences for that zone. The Template settings are defined in the registry in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\TemplatePolicies.
Local Intranet Zone vs. Trusted Sites Zone
Originally, the "Trusted Sites" zone was treated as the most trustworthy of all the zones. It was configured to use the "Low" security level template, while "Local intranet" was set to "Medium-low". Starting with Internet Explorer 7, however, security on "Trusted Sites" was tightened up, and it now defaults to the "Medium" security level template. So now, "Local Intranet" has more relaxed permissions than "Trusted Sites" . It is recommended to use the "Intranet" zone for internal sites, and "Trusted Sites" for trusted external sites.
For organizations that had added their dotted-name intranet sites to the "Trusted Sites" zone and are using default permissions for that zone, one very notable impact is that browsing IIS web sites that use Windows authentication now prompts for credentials rather than just using the Windows logon of the user to flow through. This is because the "Logon options" security setting for "Medium-low" and above sends credentials automatically only in the Intranet zone (see screenshot).
When Trusted Sites was based on the "Low" template, the Logon option defaulted to "Automatic logon with current user name and password." But generally you do not want Internet Explorer to try to log on automatically with the user’s current username and password to an external site, even a "trusted" one.
By default, URLs in which the server name contains dots are assumed to be in the Internet zone, even if they are on your organization’s intranet; e.g., http://hrweb.contoso.com. One way to define the fully-qualified domain names (FQDNs) that should be considered intranet is through the "Site to Zone Assignment List" in Group Policy (Computer Configuration \ Administrative Templates \ Windows Components \ Internet Explorer \ Internet Control Panel \ Security Page). For more information on zone detection algorithms, see this page: http://msdn.microsoft.com/en-us/library/bb250483(VS.85).aspx.
The "Locked Down" Security Zones
Those who have dug into Group Policy for Internet Explorer and/or the details of FDCC configuration have probably noticed that in addition to the standard zones ("Internet", "Intranet", etc.), there are corresponding "Locked-Down" zones, with their own collections of settings:
The Policies and Preferences for these zones live in "Lockdown_Zones" keys near the corresponding machine and User Policies and Preferences:
· Machine Policies: HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Lockdown_Zones
· Machine Preferences: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Lockdown_Zones
· User Policies: HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Lockdown_Zones
· User Preferences: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Lockdown_Zones
The "Locked-Down Local Machine Zone" is very different from the other "Locked-Down" zones.
The Lockdown_Zones settings for the Local Machine zone (zone 0) are used by a feature first introduced in Windows XP Service Pack 2 called "Local Machine Zone Lockdown" (LMZL). By default, when a page is opened in the Local Machine zone, it runs with the more restrictive policies/preferences in the Lockdown_Zones\0 registry keys, rather than the usual Zones\0 settings. By default, the LMZL settings disable ActiveX and script. If the content in the page tries to use ActiveX or script, the information bar prompts the user whether to allow them to run. If the user allows the blocked content, Internet Explorer then uses the less-restrictive, normal Local Machine zone policies/preferences from that point forward for the lifetime of that browser tab (for IE7+) or browser window (IE6).
You can find more information about LMZL on the following pages:
The Lockdown_Zones settings for the other zones (Intranet, Internet, etc.) are used to support a feature called "Network Protocol Lockdown" (NPL). This can be used to force content received over less-commonly used URL schemes to be provided restricted permissions. http: and https: are the most common URL schemes. Less common schemes include ftp:, file:, mailto:, shell:, and application-defined pluggable protocols. NPL restrictions are off by default, but administrators may choose to enable lockdown zones for specific applications and URL schemes to help reduce attack surface.
More information about NPL can be found here: