Federal Desktop Core Configuration : Internet Explorer

Viewing and Comparing IE Security Zone Settings - enhanced

Aaron Margosis — Sat, 07 Nov 2009 08:26:00 GMT

I've enhanced the IE security zone comparison utility that I posted here a few weeks ago. The new version shows the effective settings for a selected zone, based on the precedence rules for User and Computer policies and preferences (as described here) and whether only Machine settings are used. Pick an IE security zone (such as Intranet), and the new IEZoneAnalyzer will show what settings are in effect and where those settings come from.

Viewing and Comparing IE Security Zone Settings

Aaron Margosis — Thu, 01 Oct 2009 22:27:00 GMT

The Security tab of the Internet Explorer Properties dialog shows security settings for the Internet, Intranet, Trusted Sites and Restricted Sites zones. However:

It doesn’t show settings for the Local Machine (Computer) zone, nor for Local Machine Zone Lockdown (LMZL).
When machine settings or other policies are in effect, most of the Security Zones UI is disabled.

The attached utility “IE Zone Comparer” was designed to overcome these limitations and provide additional visibility into security zone settings. Pick any two collections of security zone settings, and IE Zone Comparer displays the values of those settings, highlighting any differences between the two collections.

IE Zone Comparer requires .NET 2.0 or higher; it does not require administrative privileges.

How to use it:

Click “Pick Zones…” from the toolbar. The following dialog will appear:

The Effective Settings label indicates whether User settings are used or ignored. Refer to this blog post which discusses precedence order of the various policies and preferences.

For each column, there are two dropdowns. The first dropdown lets you select Templates, Machine Policy, Machine Preferences, User Policy, User Preferences, or FDCC Q1 2009 Policies. If you select Templates, the second dropdown lets you select one of the security zone templates (High, Medium-High, Medium, etc.); if you select Policies or Preferences, the second dropdown lets you select any of the five standard zones or five lockdown zones. (See this post for more information about all those zones.)

Click “OK” on the “Pick items…” dialog, and the selected settings will be rendered in the list view. Items that are present in both columns but with different values will be highlighted in yellow. Items that are present only in one column will be grayed in the other column.

Additional Features

To find a particular item with a partial text search, press Ctrl+F (or the “binoculars” toolbar dropdown). The text search is case-insensitive and searches in all columns from the currently-selected row down. Press F3 to repeat the last search from the current location.

Enter a URL in the text area in the toolbar and click “Map URL to Zone”: IE Zone Comparer will tell you in what security zone IE would render that URL.

The Help/About toolbar button includes some helpful links for more information about IE security zones and URL actions.

Some Example scenarios for the IE Zone Comparer

View effective settings for a particular zone. E.g., something isn’t working correctly on a page that is rendered in the Intranet zone. If user settings are being ignored, select Machine Policies / Intranet and Machine Preferences / Intranet. Policies override preferences; where no policy is set, the machine preferences will apply.
Compare the relative security settings of the Intranet zone vs. the Trusted Sites zone (see screenshot above).
Seeing exactly what changes when you transition from the Locked-Down Local Machine Zone to the regular Local Machine Zone. (Description here.)
Compare Machine Policies for a zone to the policies mandated by FDCC Q1 2009.
View the settings that are applied by a given template, and compare those settings to another template or to an existing zone to see whether it has been modified from that template.
Compare the effective settings of the Locked-Down Local Machine Zone (LMZL) to Local Machine Zone, to see what becomes enabled when the user clicks through the information bar.
Compare user preferences for a zone to the machine preferences for the same zone. (They should be the same; if they are not, then results may change when the “use only machine settings” policy is applied.)

[November 7, 2009: An updated version, IEZoneAnalyzer, has been posted that shows the effective settings for a selected zone and where each of the settings are established.]

FDCC and Internet Explorer 7, Part 3 – Protected Mode

Aaron Margosis — Tue, 16 Jun 2009 08:27:00 GMT

This is the [long-delayed] third installment in a series discussing various issues regarding the intersection of Microsoft Internet Explorer 7 and the Federal Desktop Core Configuration (FDCC). The FDCC bears close resemblance to Microsoft’s security guidance for Windows XP and Windows Vista, so this series will be of interest to any customers who are locking down Windows and Internet Explorer.

The first post in this series covered IE’s security zones, changes made to “Trusted Sites” in IE7, preferences vs. policies, templates, and the “locked down” zones. The second post discussed the impact of FDCC-mandated policies on typical Internet Explorer users. This post discusses the impact of Protected Mode on Windows Vista.

The two main issues covered here are:

1. While Protected Mode improves security against web-based threats, it can cause some application compatibility problems with line of business web applications.

2. There is a bug in the default configuration for IE7 that can inadvertently enable Protected Mode in the Computer zone, which can break more stuff.

Windows Vista enhanced its security infrastructure with Mandatory Integrity Control, which makes Internet Explorer’s “Protected Mode” possible. To summarize, IE in Protected Mode runs in a process with a constrained security context that prevents the process from modifying most areas of the file system and registry, including those areas that the user is normally allowed to modify, such as the user’s Startup folder. Protected Mode is intended to serve as a defense in depth measure, so that if malware from the internet manages to exploit a browser vulnerability, it will be much harder for the attacker to make changes to the user’s system.

Protected Mode is a per-zone setting. It is enabled by default for the Internet and Restricted Sites zones, disabled for the Trusted Sites and Local Machine (a.k.a., “Computer”) zone. The Intranet zone has Protected Mode enabled by default in IE7, but disabled by default in IE8. I’ll explain that change in a moment.

With Internet Explorer 7, all the tabs within a window frame are managed by a single process. Because Protected Mode is an attribute of the process, everything displayed within a particular IE7 window is either Protected Mode ON or Protected Mode OFF. So if the user navigates from a zone where PM is enabled to one where PM is disabled (or vice versa), IE7 needs to open a new window, and displays this dialog:

This is admittedly not the greatest experience from the user’s perspective. Internet Explorer 8 was re-architected so that individual tabs within a window frame can be managed by separate processes which can be swapped out as needed, so navigating between PM-enabled and PM-disabled is now seamless.

The reason that Protected Mode was enabled for the Intranet zone in IE7 was not for any security benefit. The Intranet zone, after all, is the most permissive of the zones, allowing the use of more browser-based programming techniques than do the other zones. For example, the pop-up blocker is disabled only in the Intranet zone. The reason that IE7 turns on Protected Mode for the Intranet zone is only to avoid having to switch windows when navigating between the Internet and Intranet zones, which the designers assumed would be the most used zones in the enterprise.

As long as the web app you’re using uses only standard HTML, DHTML, AJAX, etc., it usually doesn’t matter whether it is in Protected Mode or not. But if you have mobile code (e.g., ActiveX or Java) that expects to be able to write to the file system or registry, Protected Mode can cause your app not to work as expected. Since custom ActiveX and Java is common with line of business (LOB) web applications, this can lead to a significant number of application compatibility issues.

When this is the case, it is worth considering disabling Protected Mode for the Intranet zone. It is possible to rewrite the custom code to work in Protected Mode, for example by leveraging external broker applications as described in the MSDN article, Understanding and Working in Protected Mode Internet Explorer. However, this can be complex, time-consuming and expensive. Given that IE8 already disables Protected Mode for the Intranet zone, it is far simpler just to disable it for IE7 as well. Upgrading to IE8 is another alternative worth considering.

Also, if the sites that users spend the majority of their time in are in the Intranet and Trusted Sites zones, turning off Protected Mode for the Intranet zone reduces the number of window switches as well.

Having said that, let me make very clear that it is strongly recommended that Protected Mode always remain enabled in the Internet and Restricted Sites zones. If you have external sites that are business-critical and that fail with Protected Mode (e.g., due to use of Java), they should be added to the Trusted Sites zone.

Here is how to disable Protected Mode in the Intranet zone through Group Policy:

Policy location: Computer Configuration \ Administrative Templates \ Windows Components \ Internet Explorer \ Internet Control Panel \ Security Page \ Intranet Zone

Setting: Turn on Protected Mode

State: Enabled: Disable (see the screenshot, below)

Bug in Default Settings for Protected Mode for the Local Machine Zone

There are numerous places where IE security zones can be configured: for each of the five zones, there are machine-wide policies and preferences; per-user policies and preferences; and then corresponding “lockdown” zones for each of those, of which the most important is the Local Machine Zone Lockdown (LMZL). For more information about these topics, see FDCC and Internet Explorer 7, Part 1: Security Zones.

Protected Mode is not intended to be used in the Local Machine (a.k.a., Computer) zone, and it is set to Disabled in all the places where it can be configured – with one exception. Due to an oversight, the default configuration of IE7 enables Protected Mode in the machine preferences for the LMZL. As described in Part 1 of this series, machine preferences normally have no effect – unless the “Security Zones: Use only machine settings” Group Policy setting is enabled, as it is in the FDCC, and in Microsoft’s security guidance for Windows. The Protected Mode setting remains in effect when transitioning from the Locked-Down LMZ to the normal LMZ, since unlike the other zone settings it cannot be changed without switching to another process.

As described in the previous section, Protected Mode can cause app breakage when the app expects to be able to write to the file system or registry. Common examples we’ve seen are failures with “print preview” and similar functionality where the preview content has been written to and then opened from the local hard drive.

When IE8 is installed, the setting is corrected. For IE7, the change has to be applied directly. Here are the specifics:

Key: HKLM \ Software \ Microsoft \ Windows \ CurrentVersion \ Internet Settings \ Lockdown_Zones \ 0

Value name: 2500

Change the value from 0 to 3.

You can also fix the problem through Group Policy:

Policy location: Computer Configuration \ Administrative Templates \ Windows Components \ Internet Explorer \ Internet Control Panel \ Security Page \ Locked-Down Local Machine Zone

Setting: Turn on Protected Mode

State: Enabled: Disable (see the screenshot, below)

FDCC and Internet Explorer 7, Part 2 – Impact on Users

Aaron Margosis — Wed, 12 Nov 2008 18:46:00 GMT

This is the second installment in a series discussing various issues regarding the intersection of Microsoft Internet Explorer 7 and the Federal Desktop Core Configuration (FDCC). The FDCC bears close resemblance to Microsoft’s security guidance for Windows XP and Windows Vista, so this series will be of interest to any customers who are locking down Windows and Internet Explorer.

The first post in this series covered IE’s security zones, changes made to “Trusted Sites” in IE7, preferences vs. policies, templates, and the “locked down” zones. This post will discuss the impact of FDCC-mandated policies on typical Internet Explorer users:

Installing ActiveX

Viewing or changing security zone settings

FIPS – “System cryptography: Use FIPS compliant algorithms…”

Prevent ignoring certificate errors

Java, and Java Permissions

User goodies

Impact of FDCC-mandated policies on typical IE users

Installing ActiveX

The single most impactful and valuable aspect of the FDCC is its mandate that users not have administrative rights on their computers. This single requirement is what provides the greatest security and cost-reduction benefits of the FDCC. Without this part of the mandate, the value of the rest of the required policies is minimal. (Note that the Power Users group on Windows XP is an admin-equivalent group. Users should not be members of this group, nor of Backup Operators.)

It must be emphasized that while FDCC expressly forbids typical users from running with elevated privileges, as of this writing there is no Group Policy setting to enforce it, nor any scanning tools that validate it. Nevertheless, it is part of the FDCC mandate, and agencies are required to follow it.

For Internet Explorer users, the most noticeable result of running as non-admin is that they can no longer install ActiveX controls. Non-admin users do not even get prompted when a site they have browsed to wants to install an ActiveX.

The deployment model for ActiveX has traditionally been on-demand, and performed by Internet Explorer itself. When a user browses to a web page that uses an ActiveX control, the page can specify the location from which the control can be downloaded and the minimum version required. Internet Explorer checks whether the required or a newer version is installed; if not (and if the user has the necessary rights), the user will be prompted to install or upgrade the control. The installation is performed by Internet Explorer, which runs in the security context of the logged-on user. Installing ActiveX typically involves copying files into system-wide locations (%windir%\Downloaded Program Files), and registering settings in system-wide registry locations (HKEY_CLASSES_ROOT, which usually maps to HKEY_LOCAL_MACHINE\Software\Classes). Non-admin users have never been allowed to do this, and so Internet Explorer long ago added a check for necessary rights so that non-admin users wouldn’t get prompted for an install they couldn’t perform.

For organizations that have used ActiveX for web-based line of business (LOB) web applications, this creates some challenges. The ActiveX controls cannot be deployed in the traditional manner. There are several ways to manage these challenges:

· On Windows Vista, the ActiveX Installer Service can be configured via Group Policy to allow non-admin users to install ActiveX controls from designated sites.

· ActiveX controls can be repackaged to be deployed through Active Directory Group Policy, SMS or another enterprise management system.

· Internet Explorer 8 (now at Beta 2) allows an ActiveX control to be marked so that it can be installed per-user rather than per-machine, and not require admin rights to install.

· Retire the ActiveX and reimplement the required functionality using AJAX, .NET ClickOnce or another technology that doesn’t require client admin rights.

More information about the ActiveX Installer Service (a.k.a., “AxIS”) can be found here:

· The ActiveX Installer Service in Windows Vista (TechNet Magazine)

· Implementing and Administering the ActiveX Installer Service

· ActiveX Installer Service Discussion and Video (circa Windows Vista RC1)

· KB 951585 (describes a hotfix that may be needed for some environments)

Technical information about Internet Explorer 8 can be found here:

· Internet Explorer 8 Beta 1 Whitepapers (including Non-Admin ActiveX Controls)

Viewing or changing security zone settings

Another important aspect of FDCC (or of any locked down configuration, for that matter) is that end users make many fewer trust or security decisions. These decisions are made instead by trained security professionals – or at least by designated system administrators who hopefully have more than just a tenuous grip on IT security concepts and issues.

Included in this set of decisions is how much trust to place in various web sites. On unrestricted computers, users can choose which sites to treat as “Trusted site” or “Restricted sites”, and determine what sites should be treated as part of the “Local intranet”. Users are also able to change individual security settings for each of these zones, or apply a different template to a zone (e.g., set “Trusted sites” to the Low security template as it had been prior to IE7 – not a good idea!)

With FDCC, all these decisions are removed from end users. The primary policy which enforces this is “Security zones: Use only machine settings”: User Policies and Preferences for security zones are ignored in favor of Machine Policies and Preferences, and the same settings apply to all users of the computer. The IE security zone settings that FDCC requires are implemented as Machine Policies. Since users are not allowed to change any system-wide configuration settings, this setting blocks users from adding or removing sites from the Trusted sites, Restricted sites and Local Intranet zones, from changing the security level of or individual security settings within any of the zones. Consequently, another effect of this setting is that most of the standard UI for viewing or changing IE security zone settings is disabled:

One drawback is that users (and admins) cannot use this dialog to see what the effective security settings are for a given zone. “IE Zone Compare” is a new tool that makes that information visible. It will be posted on this blog later in the “FDCC and Internet Explorer 7” series.

(Two related settings are “Do not allow users to add/delete sites” and “Do not allow users to change policies”. However, the “Use only machine settings” policy combined with users not having admin rights ends up having the same effect, but more completely and effectively.)

FIPS – “System cryptography: Use FIPS compliant algorithms…”

FDCC mandates that only FIPS compliant algorithms be used for all cryptographic operations. It’s actually more than FDCC – the law has required this of Federal agencies for many years. The main impact this policy has for Internet Explorer users is that HTTPS sites must use the TLS 1.0 protocol (sometimes known as SSL 3.1). SSL 3.0 and earlier are not FIPS compliant. Internet Explorer (and other Schannel clients) cannot negotiate a connection with sites that use SSL 3.0 or earlier. The symptom of this failure is the same that you’d get if the site were down completely: IE6 says “The page cannot be displayed” (“The page you are looking for is currently unavailable…”); IE7 displays “Internet Explorer cannot display the webpage” (“Most likely causes: You are not connected to the Internet…”).

Using TLS 1.0 requires the cooperation of the browser and the web server. On the browser side, make sure that the “Use TLS 1.0” option is checked on the Advanced tab of the Internet Options dialog. Note that on IE6 this is not checked by default (it is on by default in IE7). Unfortunately, there is no Group Policy to control this setting.

See the following Knowledge Base articles for more information about the effects of the FIPS setting:

· KB 811833: The effects of enabling the "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" security setting in Windows XP and in later versions of Windows

· KB 811834: PRB: Cannot visit SSL sites after you enable FIPS compliant cryptography

Prevent ignoring certificate errors

Draft versions of the FDCC GPOs required that “Prevent ignoring certificate errors” be enabled. Because of the huge amount of usability impact, this requirement was removed from FDCC Major Version 1.0, which was released on June 20, 2008. In other words, this setting is no longer required by FDCC. Get the latest SCAP content from fdcc.nist.gov to make sure that your compliance scans don’t flag this setting as missing or misconfigured.

When you browse an HTTPS site, Internet Explorer verifies the server’s digital certificate: it has to match the name of the site you’ve requested, it has to come from a trusted certificate authority, and its validity period must be current. If any of these verifications fail, the user is warned that something is amiss, as shown in this screenshot below. Ordinarily, the user is given the option to ignore the certificate error and to browse to the site anyway:

Continuing to the site is not recommended, because you don’t have assurance that the site is who they claim to be. Anybody can create a self-signed server authentication certificate that claims to be bankofamerica.com – but only the real Bank of America should be able to get a bankofamerica.com server authentication certificate from a trusted certificate authority.

When the “Prevent ignoring certificate errors” policy is enabled, the decision to continue to a potentially bad site is taken out of the user’s hands – the option to “Continue to this website” is removed, and the user cannot browse to the page:

This policy setting is security goodness, but FDCC removed the requirement to enable it because it turns out that within the government there are a lot of internal sites and network appliances that have self-signed certificates. There are also issues with certificate names: if the server name in the certificate says “sharepoint.internal.agency.gov”, then you can’t browse to https://sharepoint – you have to use the fully-qualified domain name. Similarly, if the name in the certificate is just “sharepoint”, then there is no way to get there if you have to use the FQDN to resolve it.

Note that “Prevent ignoring certificate errors” is a completely separate issue from the FIPS issue.

Java, and Java Permissions

The “Java Permissions / Disable Java” setting that had been applied to all security zones in draft versions of the FDCC caused some unintended problems, as we described here. FDCC Major Version 1.0 changes the setting to “High safety” for the Intranet and Trusted Sites zones, so non-Microsoft Java should be able to run in those zones.

Sun Java can have problems running in Internet Explorer Protected Mode on Windows Vista. Recommendations about Protected Mode will be the topic of the next post in this series.

User goodies

FDCC disables auto-complete in forms and will not save passwords typed into forms or authentication dialogs.

FDCC disables 3^rd party browser extensions. This disables toolbars like MSN’s and Google’s, and integration with Acrobat Reader and instant messaging programs. Hopefully it will also block a lot of the malware and spyware that is implemented as browser helper objects, toolbars, etc.

FDCC and Internet Explorer 7, Part 1: Security Zones

Aaron Margosis — Fri, 19 Sep 2008 07:00:00 GMT

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

Templates

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

"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:

· http://technet2.microsoft.com/WindowsVista/en/library/44a2d577-3ee5-4b44-9af7-aaebcfcf41341033.mspx

· http://technet2.microsoft.com/windowsserver/en/library/aebcfc94-25d5-4f41-93cc-7fb6e031de401033.mspx

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:

· http://technet2.microsoft.com/windowsserver/en/library/44a1af75-935b-4cc2-97cd-da3b7e8bfc891033.mspx

Internet Explorer security setting, "Java Permissions: Disable Java"

Aaron Margosis — Fri, 01 Feb 2008 04:28:00 GMT

[Authors: Aaron Margosis and Shelly Bird]

We recently noted in testing some problems with the Disable Java setting.

We had stated in a recent FDCC LiveMeeting that the "Java Permissions/Disable Java" IE security zone settings only apply to the Microsoft Java Virtual Machine (MSJVM). Our testing at larger enterprises did seem to confirm this: numerous Java applications, running with various versions of Sun JRE, were running without errors, with this setting turned on.

However, deeper examination of application compatibility issues with some Line of Business applications at other customers sites have shown that under certain circumstances, customers will see non-Microsoft Java runtime engines affected by this setting. These failures do not appear to be common, and do seem to be limited to just a few applications; however, everyone should be aware of exactly how and when this setting could have impact.

To give some background on this, FDCC applies an "Enabled: Disable Java" setting on every single Internet Explorer Security Zone, including Intranet and Trusted Sites. For example, it is set at this location in policy:

Computer Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page\Internet Zone\Java Permissions

In Group Policy Editor, when you navigate to these settings, you see the choices listed below:

The various "Java Permissions" settings were designed primarily to control the behavior of the Microsoft JVM. To our knowledge, only the Microsoft implementation of Java ever adjusted its behavior based on the "safety" level or the more granular Custom permissions assigned to the security zone in which an applet was running. This is why many of us believed that the "Java Permissions" setting only ever impacted MSJVM. Most likely, the reason that "Disable Java" was configured across the board in the FDCC was specifically to prevent further use of the MSJVM, which is no longer supported and is not included in any shipping Microsoft products.

However, the "Disable Java" option is actually enforced by Internet Explorer, not the MSJVM, by blocking the use of the <APPLET> element in HTML. The <APPLET> element is one of several available ways to run Java code within a web page. There are other HTML elements that can be used instead, and that are not affected by the "Java Permissions" setting. This explains why many Java apps have continued to work with "Disable Java" enabled.

The symptom of a failure will be the following error message in the Internet Explorer Information Bar:

Your security settings do not allow websites to use ActiveX controls installed on your computer. This page may not display correctly. Click here for options…

Switching the "Java Permissions" setting to anything other than "Enabled: Disable Java" allows the page to load. In these situations, we suggest switching the "Java Permissions" settings in the Local Intranet and Trusted Sites zones from "Disable Java" to "High Safety". This will allow the full use of non-Microsoft Java implementations in IE for those zones, while restricting any lingering MSJVM use as much as possible. Report this change as a necessary variance to NIST. (This link describes the effects of the various "Java permissions" settings on the MSJVM: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/ierk/Ch07_e.mspx. Note that customers are strongly encouraged to identify and eliminate any remaining dependencies on the MSJVM.)

If you have control over the HTML that is used to invoke the Java applet, another option is to change the HTML not to use the <APPLET> element. Documentation on these other techniques is available here: http://java.sun.com/docs/books/tutorial/deployment/applet/deployindex.html