Federal Desktop Core Configuration : FDCC

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.]

Source code for New and Updated Local Group Policy utilities

Aaron Margosis — Tue, 15 Sep 2009 20:35:00 GMT

Visual Studio 2008 source and project files for the new ImportRegPol utility and the updated Set_FDCC_LGPO and Apply_LGPO_Delta utilities for managing Local Group Policy Objects.

Note that these are all now Visual Studio 2008 projects.

New and Updated Local Group Policy Utilities

Aaron Margosis — Tue, 15 Sep 2009 20:30:00 GMT

A customer requested an addition to the local group policy toolset posted on the FDCC blog. While working on the new utility, I needed to upgrade the other two. The full set is attached to this post, with documentation. The source code for all of them is attached to a separate post.

The new utility, ImportRegPol, takes a registry policy file (registry.pol) as input. It can import its contents into the local group policy of the local computer (Computer or User configuration), or simply read it and output Notepad-editable text that can be consumed by Apply_LGPO_Delta.

While working on it, I discovered and corrected subtle shortcomings in Set_FDCC_LGPO and Apply_LGPO_Delta. The main shortcoming had to do with when a value or set of registry policy values were to be deleted: if the settings were present when Set_FDCC_LGPO or Apply_LGPO_Delta was run, they would be deleted, but those deletion “commands” were not saved in the policy store. So, if the settings were to be reintroduced, gpupdate from local policy would not remove them. The new implementations insert the deletion “commands” into the policy store so that they can be applied whenever policy refreshes. This required extending the input file syntax for Apply_LGPO_Delta and the log file output for Set_FDCC_LGPO, both of which have been bumped to v2.0.

While I was at it, I upgraded those utilities to Visual Studio 2008 and enabled ASLR and DEP. In addition, the new version of Apply_LGPO_Delta does not perform an OS check, so it is no longer restricted only to Windows XP and Vista, and will run on any supported version of Windows. Set_FDCC_LGPO still runs only on XP (SP2 or higher) or Vista (RTM or higher), because NIST hasn’t defined FDCC settings for any other versions of Windows.

Here is more information on the new ImportRegPol utility:

ImportRegPol

ImportRegPol is a non-interactive tool that imports the settings from a Registry Policy (registry.pol) file into the Computer or User configuration of the local group policy of the current computer. It can also parse a registry.pol file and produce an editable text file that can be consumed by Apply_LGPO_Delta v2.0.

Introduction

Administrators frequently apply policies by copying registry.pol files into the Group Policy folders. This technique is not supported by Microsoft, and has the unfortunate side effect of destroying any previously existing policies. ImportRegPol reads the reference policy file and uses supported application programming interfaces (APIs) to add settings to local policy.

The format of registry policy files is a documented, binary file format, normally produced by Group Policy editors such as GpEdit.msc. However, there aren’t any good viewers or editors for directly manipulating those files. For this reason, the Apply_LGPO_Delta utility uses a custom, Notepad-editable text file format to define specific changes to apply to local group policy. The log file format produced by ImportRegPol is compatible with Apply_LGPO_Delta v2.0. ImportRegPol can be run in a “parse-only” mode to read a registry.pol file and produce an equivalent input for Apply_LGPO_Delta.

The utility requires administrative rights to import policies, but does not require administrator rights for parse-only mode. Note that the in-use registry.pol files in the GroupPolicy folders can be used for input only in parse-only mode.

Command line syntax and usage:

The ImportRegPol command line syntax is described below. All parameters are case-insensitive. The command line must include -m or -u followed by the absolute or relative path to a registry policy file. All other parameters are optional.

ImportRegPol.exe –m|-u path\registry.pol [/parseOnly] [/log LogFile] [/error ErrorLogFile] [/boot]

-m path\registry.pol   [for Computer configuration] or

-u path\registry.pol   [for User configuration]

                        Path\registry.pol specifies the absolute or relative path to the input registry policy file (which does not need to be named “registry.pol”).

/parseOnly             Reads and validates the input file but does not make changes to local group policy. In conjunction with the /log option, can be used to convert a registry policy file to an input file for Apply_LGPO_Delta.

/log LogFile           Writes detailed results to a log file. If this option is not specified, output is not logged nor displayed. The logged results for the registry policy settings can be used as input for Apply_LGPO_Delta.

/error ErrorLogFile   Writes error information to a log file. If this option is not specified, error information is displayed in a message box dialog.

/boot                  Reboots the computer when done.

This utility is not a console app, so you won’t see a console window appear, and if you start it from a CMD prompt, it will run in the background – CMD won’t wait for it to complete. You can check in TaskMgr to see when it completes. If you want CMD to wait for ImportRegPol to complete, run the utility with "start /wait".

FDCC Vista Application Development Requirements

cgreene — Wed, 08 Jul 2009 16:51:00 GMT

Overview

NOTE: This entry only focuses on the Windows Vista version of the FDCC and desktop applications.

Since its infancy, common themes have emerged which have delayed or prevented enterprise customers from deploying the FDCC. By the 80/20 rule, the two most common problems, in order, are:

1. Data and Settings Management

2. Application Installation

Customers have encountered other, smaller issues. But these two will cover 80% of the problems faced by applications when implementing the FDCC.

This entry will discuss the background of these items and how to best develop your application for the FDCC. It is primarily intended for developers, but system administrators can benefit too because some features of Windows will be discussed that can make your life easier.

This entry does not discuss UAC Virtualization. It assumes you are developing applications that will function entirely as a normal user.

Before we dive in, let’s discuss a little background and the purpose of the FDCC.

Why the FDCC?

The spirit of the FDCC is to provide a standard operating system image and settings, a common set of applications, and firewall for a non-privileged user community. This is the best way to secure an enterprise and ensure fundamental system integrity while reducing costs.

Users cannot be allowed unrestricted access to a system. There is no technical or business reason users should have elevated privileges to browse the internet, check email, or create and modify documents. Doing so provides an easy opportunity for malware to steal, destroy, or falsify data.

The foundation of the FDCC is Microsoft Windows Vista with NTFS. This is great news for those who have invested time and effort learning how to develop on the Windows platform. If you have developed on Windows in the private sector/commercial world, then developing on the FDCC will be an easy transition.

The FDCC, and Windows in general, is a system designed for multiple users and to isolate the actions of multiple users. Non-elevated users can only write to their own profile. They are not allowed to:

· Make system-wide changes

· View or modify another user’s profile

· Write or modify directories owned by the operating system containing binaries such as EXE’s or DLL’s

This helps keep any unintentional and/or malicious activity by one user from affecting other users of a system and spreading across the enterprise.

Unfortunately, MCS has worked with many applications that modify the default permissions and leave a machine more vulnerable to attack. Security can be completely undone by one application making a seemingly minor change.

Your job as a developer is to make sure you follow these best practices to maintain this default security.

Know your Users

The target audience for FDCC applications is no longer the workgroup. Gone are the days when you could assume a system administrator could physically visit the machines of your user community and install and configure application. Developers must make every effort to make sure their application can be deployed and configured in an enterprise environment with hundreds, thousands, or myriads of users.

Administrators are users too and first impressions last forever. Often the first experiences administrators have with applications are when they install the software on client machines. This experience can either be a good one or bad. The requirements put forth in this document ensure that administrators have all of the tools they need to do their job.

Data and Settings Management

Windows Vista provides the infrastructure to separate user data, user settings, and computer settings. Applications that use this infrastructure correctly offer the following benefits:

· Applications do not fail when run by non-privileged users

· Administrators or users can easily back up data and settings without needing to backup application or operating system files

· Multiple users can share a single computer, each with his or her own preferences and settings

· System administrators can enable Folder Redirection

· Applications are less likely to prevent Fast User Switching from operating correctly and efficiently

· Administrators can easily migrate user data when users get a new computer

History

Many applications make assumptions that their users would have administrative privileges and thus often try to write to protected areas of the operating system. Most commonly, these protected areas are the Program Files folder or HKLM. More generally, these areas include any resource in which normal users did not have write/modify access. Thus, on Windows XP many applications reported “access denied” error messages. Windows Vista introduced UAC Virtualization, but users often have no idea where the target redirection occurred. What’s more is that UAC Virtualization may be turned off in some organizations. If this occurs, applications commonly report “access denied” error messages just as they would were they running on Windows XP.

Several organizations maintained separate, logical drives for applications and data. Thus, it was common to find all application binaries installed on the C: drive and then a folder would be set up on the D: drive for user-created data. The idea was that the data would be safe on the D: drive if the C: drive ever crashed.

Also commonly found, were applications that installed custom directories on the root of the C: drive that contained application binaries and user-created data. The argument in favor of this practice was that applications and data could easily be migrated to new machines simply by backing up the directory on the old machine, and restoring it on the new on.

All of these scenarios remove flexibility from the system administrators and make network management more difficult. They raise the total cost of ownership for enterprises because:

1. Tools like the User State Migration Tool migrate user-created data, but it takes time and resources to develop and test each of these extensions. Often, several trial-and-error attempts must be made before it’s considered ready for production. Inevitably, something gets missed.

2. Administrators no longer have the flexibility to us folder redirection for user-created data.

3. While having the application isolate data into its own custom directory enabled users to share data, the negative is that this approach is a one-way street. It becomes difficult to separate data so that only certain users had access to it. It also makes using the application inside Terminal Services sessions practically impossible without major re-writing.

The following requirements will ensure that administrators have maximum flexibility and will help reduce their workload and allow them to administer by exception.

User-Created Data

User-created data is anything a user can store or retrieve at a later time. Obvious examples are Word, Excel, or PowerPoint documents. User-create files must be stored in the Documents folder or subfolder. The default Documents folder location for a typical Vista installation is C:\Users\<username>\Documents, but paths should never be hard-coded. Calling the Common Item Dialog will default to the Documents folder. Windows Vista also provides direct access to the Documents folder using the SHGetKnownFolderPath function passing in FOLDERID_Documents. For example:

PWSTR pszDocFolder;
SHGetKnownFolderPath(FOLDERID_Documents, 0, NULL, &pszDocFolder);
CoTaskMemFree(pszDocFolder);

On a typical installation of Windows Vista pszDocFolder would contain the string “C:\Users\<username>\Documents”.

Note: .NET Framework developers should use the System.Environment.GetFolderPath method with the Environment.SpecialFolder.MyDocuments parameter.

The benefits of using the Documents folder as the default location for data storage are:

· All users (including those with restricted account types) have write access to this location

· Users have one familiar place to organize and store all their data

· Data sharing is facilitated between applications because all applications using Common Item Dialog can easily access the Documents folder

· The Documents folder is an abstracted location and can be redirected to the network transparently by an administrator

· The Documents folder is available on the Start menu

Application-Created Data

Application-created data is used by the application to store application state, user preference, and temp files, etc. This type of data is typically hidden from users.

By storing this application-specific data in one of the several valid locations, you make it possible for multiple people to use the same computer without corrupting or improperly modifying each other’s data. The specification provides several valid locations and you are free to choose the location that works best for your needs.

A clear benefit to the developer is that can actually result in fewer lines of code. SHGetKnownFolderPath enables you to determine the correct location in which to store the user’s data and the user-specific application data.

Classifying and storing application data according to the guidelines in this requirement provides these benefits:

· It enables multiple users to share a computer and helps enable Fast User Switching.

· It enables business-related operations such as roaming, off-line storage, and allowing the operating system and its applications to be secured.

· It ensures a consistent and abstracted location for user data, enforces per-user separation of application data.

· It is one of the key factors in enabling remote use of the application.

This section identifies the valid file folders and the valid registry locations that applications must use for this data, and gives guidance on how to choose which of these locations are best used in different circumstances. The choice of valid locations to use is left to the software developer.

Classify application data into the following categories:

· Per user, roaming

· Per user, non-roaming

· Per computer (non-user specific and non-roaming)

NOTE There may be more than one category for the different application data stored by your application.

It is best to use application data file folders rather than the registry for storing application data in excess of 64K. The registry is an acceptable choice for small amounts of data. At installation time, try to store less than a total of 128K across HKEY_CURRENT_USER (HKCU) and HKEY_LOCAL_MACHINE (HKLM).

To comply with this specification, store application data files appropriately as either common or per-user. That is:

· In a subfolder of either the common application folder (identified by FOLDERID_ProgramData), or

· In the user profile folders: application data (FOLDERID_RoamingAppData) or local application data (FOLDERID_LocalAppData).

The subfolder to create to store user data files in is:
[company name]\[product name]\[version].

Using the Registry

Applications may also use the registry to store read/write application and configuration data.

· The HKCU registry hive is appropriate for storing small amounts of data (approximately 64K) and for policy settings that are per user.

· Avoid writing to HKLM during runtime, because limited users have read-only access to the entire HKLM tree by default. In addition, HKLM does not support roaming.

· Larger, file-based data should be placed in an application data folder. For example, Internet Explorer’s Temporary Internet Cache is stored within the file system of the user’s profile and not in the registry.

· At installation time, the application should not store more than a total of 128K across HKCU and HKLM.
Note that HKEY_CLASSES_ROOT is excluded.

Using Application Data Folders

Once you have decided how to classify your data, you can use SHGetKnownFolderPath to retrieve the corresponding folder locations.

The KNOWNFOLDERID values described here provide a consistent, unified way to access the physical paths to the desired folder locations, independent of the operating system. The preferred API is SHGetKnownFolderPath. To access the path for application data, applications should call SHGetKnownFolderPath with the appropriate KNOWNFOLDERID and then append [company name]\[product name]\[version] to the returned path. Specifically:

PWSTR pszAppData;
SHGetKnownFolderPath(
FOLDERID_RoamingAppData, 0, NULL, & pszAppData);
CoTaskMemFree(pszAppData);

On a typical installation of Windows Vista pszAppData would contain the string “C:\Users\<username>\AppData\Roaming”.

Note: .NET Framework developers should use the System.Environment.GetFolderPath method with the Environment.SpecialFolder.ApplicationData parameter.

When storing application data in the user profile, applications must use the following hierarchy under the Application Data file structure:

FOLDERID_RoamingAppData\
[Company or Organization Name]\
    [Product Name]\
      [Version]\
        [File or Folder]

Data Type	KNOWNFOLDERID	Folder Location
Per user, roaming	FOLDERID_RoamingAppData	[user profile]\AppData\Roaming
Per user, non-roaming	FOLDERID_LocalAppData	[user profile]\AppData\Local
Per computer (non-user specific and non-roaming)	FOLDERID_ProgramData	C:\ProgramData

To comply with this specification, applications must classify and store data appropriately as either common or per-user. That is, either FOLDER_ProgramData or one of the user profiles: FOLDERID_RoamingAppData or FOLDERID_LocalAppData.

FOLDERID_RoamingAppData

This folder will be enabled for roaming with the user profile. Use this folder to store all user-specific application preferences. For example, if a user can specify a custom dictionary to be used in the application, you would store it here. That way, if a user roams from computer to computer, the dictionary will roam with him or her. This also allows other users to have their own custom dictionaries.

FOLDERID_LocalAppData

This folder is for application data that does not roam. As it is still part of the User profile, this is still per-user information. Application data that is computer-dependent, such as user-specified monitor resolution, must be stored here.

This data must not roam because different computers are likely to have different monitors. In addition, large blocks of data that can easily be recreated and temporary files must be placed here to minimize download time that is incurred when roaming.

EXAMPLE Internet Explorer keeps its cache of downloaded .html/.gif pages here so that they don’t roam with the user. However, the smaller cookie and history lists are stored in FOLDERID_RoamingAppData so that they do roam.

FOLDERID_ProgramData

This folder should be used for application data that is not user specific. Note that a limited user will only have read privilege for files in this folder, except for the files that user created. If users need to have write access to the common files, then during installation the application must create a sub-folder of FOLDERID_ProgramData with “Modify” privilege for appropriate user groups.

EXAMPLE An application may store a spell-check dictionary, a database of clip art or a log file in the FOLDERID_ProgramData folder. This information will not roam and is available to anyone using the computer.

Additional Considerations

· Files may be shared in the application data (FOLDERID_LocalAppData, FOLDERID_LocalAppDataLow or FOLDERID_RoamingAppData) folders. Multiple computers may use them simultaneously with different instances of the application. The data may also be used by multiple applications, for example, applications in a productivity suite.
Applications should get a write exclusive on the file only when absolutely necessary. For example, applications using CreateFile should only specify GENERIC_WRITE when a write is required, but they should always set FILE_SHARE_READ.

· Paths returned by SHGetFolderPath are valid Win32 file system names that may contain spaces and may be in the universal naming convention (UNC) format.

· PathAppend() and PathCombine() APIs can be used to concatenate the relative path information onto the paths returned by SHGetFolderPath. For example:
PathAppend(szAppData, "Company\Product\File.txt")

· By default, all users can write to the Users\Public\Documents location (FOLDERID_PublicDocuments).

Application Installation

The best way to package applications is using the Windows Installer format. Windows Installer is the native application installation engine in Windows Vista. It provides the following benefits:

· Applications can be inventoried using Windows Installer

· System administrators can selectively change how and which features will be installed

· Applications have the ability to self-heal

· It enables applications to separate per-user and per-machine installation tasks

· Applications can provide silent or unattended capabilities often with little effort on the developers part

· It enables system administrators to easily choose how the app is deployed (Group Policy Installation or Configuration Manager installation)

· A properly formatted MSI package is transactional. It either completely installs or completely fails. It never leaves the system in an unknown state.

· It automatically supports UAC

· There is already a large ecosystem of applications packaged in the Windows Installer format. Thus, the learning curve is minimal or non-existent for most system administrators.

See the following links for more information on Windows Installer:

· Overview of the Windows Installer Technology

· Developer Story Windows Installer

History

Once upon a time, it was common to find organizations with administrators running around the office from machine to machine, installing and configuring applications. Many lines of business (LOB) applications were limited to a finite set of known users and so it was understandable to train a few people how to administer them. They were built with enough functionality to meet the needs of the end user, but the burden of installing and configuring the applications was largely left to the administrators by following a long series of manual steps on each user’s desktop. The unfortunate reality is that creating a solid installation package was mostly an afterthought for many application developers.

The worst offenders had no installation package or the installation package was nothing more than a scripted xcopy. Administrators were instructed to create a directory, copy EXE’s and DLL’s, create registry keys and shortcuts before the application could be used. Any missed step or instruction not followed perfectly lead to a partially functioning application or, worse, a non-functioning application. Repeatability of the application installation was low and configuration management became more difficult. But even if an administrator got an application installed properly, there were often other difficulties running the apps.

Many applications stored user-created data and application data in the same directory as the application directory. If these applications were installed to Program Files, normal users were denied write and modify access. Thus, even if users weren’t responsible for installing and/or configuring their applications, they were still often granted elevated privileges because some applications simply would not run otherwise. But because users had full control over their PC’s, it created an unmanaged situation and administrators often had no idea how each machine was configured. Worst of all, users can easily download – without even realizing it—malware. This is an invitation to hackers and has historically been the cause of several security breaches in enterprise networks.

Many applications are also commonly installed to non-standard locations on the root of the hard drive, such as C:\AccountingApp. This was thought to solve the problem of giving users administrative privileges because users were able to read/write/modify. Plus some developers argued that it made migration from one machine to the next easier because a single directory could be copied from the source machine to the target machine. But it presented other problems.

Any user with write/modify access to the application folder would be able to replace the application binaries. But remember – Windows and the FDCC are designed to isolate multiple users and their actions. Thus, allowing users write/modify permissions to binaries shared by multiple users could allow someone with malicious intent to view or modify another user’s profile or make system-wide changes. More details and consequences of which can be found in the Changing access control on folders vs. files post.

In addition to being a security vulnerability, this approach also made it more difficult when users were upgraded to a new machine and data had to be migrated. Many development teams reasoned that application data is all stored in one place so it’s easy for an administrator to a folder from one machine to the next. True, but only if the administrator has to do it one time. And it completely ignores the security aspect. But security aside for the moment: what happens when there are hundreds or even thousands of machines and/or users? Administrators must rely on tools to help them migrate data like this.

Tools like the User State Migration Tool automatically migrate data for several hundreds of applications. And it is extensible so that administrators can migrate LOB apps. But it takes a lot of resources to configure USMT correctly. So what happens when there are hundreds or even thousands of applications?

Installation Directory

Applications must always target the Program Files folder by default. Applications that install to a subdirectory of this folder inherit the restricted permissions from the parent by default. Normal users are given read and execute permissions to application binaries. But they are not allowed write or modify permissions.

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)

Set_FDCC_LGPO.exe v1.06, Visual C++ project sources

Aaron Margosis — Wed, 15 Apr 2009 19:29:00 GMT

Visual Studio 2005 project files and source code for Set_FDCC_LGPO.exe v1.06 is attached to this blog post.

[Removed, as a newer version is available -- bookmark the landing page for the most up-to-date-links.]

Set_FDCC_LGPO updated: v1.06

Aaron Margosis — Wed, 15 Apr 2009 19:08:00 GMT

Set_FDCC_LGPO has been updated to reflect the updated GPO content on NIST's download page. The FDCC settings have not changed. The updates contain only corrections to the downloads to more closely adhere to the FDCC settings.

The updated Set_FDCC_LGPO is attached to this blog post. (This time I also remembered to include the readme.htm in the zip file.) The updated Visual C++ project sources are here.

To recap: Set_FDCC_LGPO is a non-interactive tool that applies the Q1 2009 FDCC desktop policy settings from NIST to local group policy and optionally to the security settings of the computer as well.

[Attachment removed, as a newer version is available -- bookmark the landing page for the most up-to-date-links.]

Apply_LGPO_Delta v1.01, source code

Aaron Margosis — Thu, 19 Mar 2009 08:27:00 GMT

Visual Studio 2005 project and source code files for Apply_LGPO_Delta v1.01 is attached to this blog post.

[Attachment removed, as a newer version is available -- bookmark the landing page for the most up-to-date-links.]

Apply_LGPO_Delta updated, v1.01

Aaron Margosis — Thu, 19 Mar 2009 08:13:00 GMT

Apply_LGPO_Delta is a utility for automating the management of local group policy -- administrative templates and security templates. First posted here, it has been updated with the same fix that was applied to Set_FDCC_LGPO to prevent the 0x80070020 sharing-violation error from occurring.

Documentation is in the download. The sample starter files have been updated, including the addition of a security template you can use to revert the file system permissions changes that FDCC mandates on XP.

Updated source code is here.

[Attachment removed, as a newer version is available -- bookmark the landing page for the most up-to-date-links.]

Set_FDCC_LGPO.exe v1.05, source code

Aaron Margosis — Sat, 24 Jan 2009 06:20:00 GMT

Visual Studio 2005 project files and source code for Set_FDCC_LGPO.exe v1.05 is attached to this blog post.

(This blog doesn't support multiple file attachments per post...)

[Attachment removed, as a newer version is available -- bookmark the landing page for the most up-to-date-links.]

Set_FDCC_LGPO updated: v1.05

Aaron Margosis — Sat, 24 Jan 2009 06:07:00 GMT

[2009-04-15: Attachment removed. Bookmark this page for the latest versions of these utilities.]

The utility for applying FDCC configuration settings en masse to a computer has been updated:

The 0x80070020 sharing-violation error code that occasionally occurred appears to be due to contention over the registry.pol files between Set_FDCC_LGPO (which is writing to them) and winlogon.exe, which is reading from them to apply their contents to local policy. Upon a sharing-violation error, Set_FDCC_LGPO no longer reports an error right away, but retries the operation every half second for up to 10 seconds. This should dramatically reduce if not eliminate these errors.
The output log (use the /log command line option) now formats output in the same format that is consumed by Apply_LGPO_Delta, which will make it much easier to create input files to automate those variances.

The GPOs it applies are still those of the FDCC Major Version 1.0 (Q3 2008).

The updated source code is here. The original documentation still applies.

FDCC Blog Alert: Issue with Vista SP1

Mandy Tidwell — Fri, 26 Sep 2008 17:24:00 GMT

Author: Shelly Bird

Credit: Syed Ismail, Ben Christenbury

Applies to: Vista SP1 alone.

Setting:

Microsoft Network Client: Digitally Sign communications (always) is set to Enabled in FDCC.

History:

The server side settings are always ON (w2k3 SP2):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

EnableSecuritySignature [REG_DWORD] = 0x1

RequireSecuritySignature [REG_DWORD] = 0x1

Client-side settings (Vista SP1) for FDCC:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters

EnableSecuritySignature [REG_DWORD] = 0x1

RequireSecuritySignature [REG_DWORD] = 0x1

Issue:

Under this condition, GPO processing for the computer account fails, both at startup and every time gpupdate.exe is run. There will be a 1058 error in Event Viewer:

3/19/2008 4:55:10 PM 1 0 1058 Microsoft-Windows-GroupPolicy NT AUTHORITY\SYSTEM SDC-211.ITL.local

The processing of Group Policy failed. Windows attempted to read the file \\ITL.local\SysVol\ITL.local\Policies\{1B71C87D-FAB7-4FE1-BEAF-07F846DE3E1D}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:

a) Name Resolution/Network Connectivity to the current domain controller.

b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).

c) The Distributed File System (DFS) client has been disabled.

Detail: The account is not authorized to log in from this station

Result: The Group Policy Engine is unable to get the GPO version from the DC.

As soon as RequireSecuritySignature is set to 0 (Disabled) on the client and the client is rebooted, GPO processing works fine.

Note that this issue does not happen in Vista Runtime (pre-SP1). Previously, if the server and client were coordinated to be Enabled for this setting, no issues arose, except possibly with non-Microsoft SMB signing systems.

Resolution: There is a QFE that can be requested from Microsoft Premier and which we have tested and confirmed eliminates this issue. We highly recommend obtaining this QFE for any Vista SP1 implementations which are launched with the FDCC settings. We hope it will shortly be available either as a public update or in the next Service Pack.

For more information, please see the following KB article:

http://support.microsoft.com/kb/950876/en-us