Federal Desktop Core Configuration : Group Policy

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

The Case of the Unexplained Installation Failure (and an ill-advised registry hack)

Aaron Margosis — Mon, 28 Sep 2009 09:43:00 GMT

Since Mark Russinovich hasn’t trademarked his “Case of the Unexplained…” series, I’m appropriating the title to describe the results of some troubleshooting I did for a customer. The root cause turned out to be a widely-adopted but ill-advised registry hack that many organizations have built into their standard desktop images. If you’re not interested in the troubleshooting steps, skip ahead past the nerd content here and just read the Analysis. [Spoiler: it’s about the Autorun.inf “SYS:DoesNotExist” registry hack.]

The Case

The customer has Kodak scanners that come with CDs containing the required software. When the admin inserted the CD, Autorun didn’t quite work correctly – the Autorun dialog appeared but did not show the Autoplay option to install the software. So the admin opened the folder in Explorer and started autorun.exe to start the installation. Shortly after approving the User Account Control elevation request, the admin saw an error message with a strange title that looked like the installer was performing an incorrect OS version check:

App install error message

The Troubleshooting

I figured that the author of the installation program had assumed that since Windows XP was so perfect that Microsoft would never need to release another version of Windows, there was no reason to check for newer versions. I applied the WinXP compatibility mode (which among other things lies to the program about what the OS version actually is) and tried again. It failed in exactly the same way. What’s more, the installation worked perfectly well on freshly installed copies of Windows Vista that didn’t have the organization’s policies applied to it. Ah – so it’s not a Vista issue, there’s something in the policies!

I started Process Monitor, and ran the installation program again to the point of the error message and then stopped the Procmon trace. I dragged the Procmon crosshairs toolbar icon over the error message to apply a filter to show only events involving the window owner’s process (setup.exe).

Because of the “0” in the title in the error message, I thought the problem might be due to the program searching for something and not finding it, so I right-clicked on items in the Result column and excluded events with result codes I figured wouldn’t be interesting: SUCCESS, FAST IO DISALLOWED, FILE LOCKED WITH ONLY READERS, REPARSE, BUFFER OVERFLOW, and END OF FILE. (I usually exclude results that I want to filter out rather than include results that might be interesting because it’s easy to miss some when setting “include” rules.)

When I looked at the remaining entries, one thing that quickly stood out was the name “DoesNotExist” appearing in path names near the end of the results. I used Procmon’s highlighting feature to make them stand out in the context of surrounding events.

Because the surrounding context didn’t give me an idea of what had happened immediately prior to these failed searches, I took advantage of Procmon’s non-destructive filtering and removed the filter rule that excluded SUCCESS results. As you can see in the screenshot, there had been a bunch of file accesses to D:\setup.ini and then a few to D:\autorun.inf before the attempted registry access to HKLM\Software\DoesNotExist\Info.

I opened the event properties for the first RegOpenKey event and looked at the call stack to get an idea of how and why setup.exe was trying to open that key. Line 12 of the stack showed that the randomly-named component of the setup program was calling into GetPrivateProfileStringA, which led (in line 7) to an attempt to open a registry key.

GetPrivateProfileString is one of the APIs that Windows programmers can use to read from files that are formatted like the old .ini files from 16-bit Windows. And as its documentation points out, those accesses can be redirected to the registry with an IniFileMapping. I located the IniFileMapping that redirected autorun.inf to “DoesNotExist”, deleted it, rebooted, and the installation then worked correctly.

IniFileMapping entry redirecting Autorun.inf to a non-existent registry key

The Analysis

What is IniFileMapping?

IniFileMapping has been part of Windows since NT 3.1. When programs use the ini-file APIs to access files, an IniFileMapping entry can redirect the access to the machine or user registry (HKLM or HKCU). IniFileMapping was designed to help older apps that used .ini files to use the registry instead, to take advantage of the scalability benefits and to enable multiple users to have their own copies of settings instead of sharing a single ini file.

What is Autorun.inf?

When a removable disk, such as a CD or a USB drive, is inserted and Windows detects the new disk, Windows Explorer checks for an Autorun.inf file in the root folder of the drive. The Autorun.inf is a text file formatted as an .ini file (that is, section names in square brackets, name=value pairs within each section). It can include entries which tell Explorer what icon to display for the drive and a default Autoplay action to offer to the user, or in some cases, the program can just begin running. This is the mechanism that allows a program installation to automatically start just by inserting a CD. There are registry settings and group policies that can control whether and how Autorun and Autoplay work. (That link also describes the distinction between Autorun and Autoplay.)

A problem with Autoplay is that by default it has also been applied to writable drives such as thumbdrives. Worms like Conficker were able to propagate through such devices by writing an Autorun.inf and a copy of itself to the drive. The malware could then infect other computers simply by inserting the drive. That was compounded by a bug in the implementation of the settings that were supposed to disable Autoplay. That bug has since been fixed. Furthermore, updated Windows systems now have Autoplay disabled by default for writable drives. Autorun and Autoplay still work for CDs and DVDs, as the threat of worm propagation through that avenue is much smaller and (at this time) does not outweigh the benefits.

Why does this computer have an IniFileMapping for Autorun.inf?

A couple of years ago, a blog post described a clever trick to disable Autoplay for all drives. The trick leveraged the fact that Autorun.inf is formatted as an ini file and that Explorer uses the ini file APIs to read it. By creating an IniFileMapping for Autorun.inf that redirects access to a non-existent registry key, Autoplay entries cannot be read. The author asserted that the only negative effect is that users must browse for the file to execute. As more malware began using writable removable drives as a propagation mechanism, CERT and other security-conscious organizations began recommending this trick, adding the assertion that “This setting appears to disable Autorun behaviors without causing other negative side effects.” Since then, the setting has been mandated as part of the standard image for many organizations.

Why did this application install fail?

It turns out that the Autorun.inf on Kodak’s installation CD contained much more than just Autoplay entries:

[autorun]
open=autorun.exe

[Info]
Dialog=Kodak i610/i620/i640/i660 Scanner
Model=600
ModelDir=kds_i600
ProgramGroup=i610,i620,i640,i660

[Versions]
CD=04040000
FIRMWARE=04000300
ISISDRIVER=2.0.10711.12001
ISISTOOLKIT=57.0.260.2124
KDSMM=01090000
PKG=02010000
SVT=06100000
TWAIN=09250500

[Install]

[SUPPORTEDOSES]
WIN=WINVISTA WINXP WIN2K

[REQUIREDSPS]
WINXP=1
WIN2K=3

Kodak uses the Autorun.inf not only for Autoplay but as a general-purpose ini file containing configuration settings for the installation program. The installation program of course uses standard APIs to read the file, but the IniFileMapping redirects to a non-existent registry location, causing the installer to fail. It needs to be said here that what Kodak is doing is perfectly legitimate. There are no guidelines that say that the Autorun.inf cannot contain other application specific settings.

Could the customer have worked around the problem by copying the CD content to the hard drive and running it from there? No. The IniFileMapping setting applies to any file called Autorun.inf no matter where it is.

The bottom line is that the installation failed because the assurances of no “negative side effects” were not backed with extensive compatibility testing, and denies legitimate usage scenarios.

Recommendation

Customers who want to block Autoplay should use supported mechanisms rather than relatively untested hacks that can end up causing unintended side effects. I’ve seen plenty of cases where a non-standard setting that seems to many to be perfectly safe turns out to have serious repercussions that aren’t discovered for years. (That sort of thing led to the publishing of KB article 885409.)

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