Welcome to TechNet Blogs Sign in | Join | Help

FDCC Blog Alert: Issue with Vista SP1

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. 

Posted by Mandy Tidwell | 0 Comments
Filed under: , ,

FDCC and Internet Explorer 7, Part 1: Security Zones

This multi-part series will discuss various issues regarding Microsoft Internet Explorer 7, particularly with regard to its use on Federal Desktop Core Configuration (FDCC) compliant systems.  The FDCC is based on Microsoft’s security guidance for Windows XP and Windows Vista, so this series will likely be of interest to audiences beyond those impacted by FDCC.  Topics that will be covered include:

·         Primer on IE security zones and how they are controlled and used, including the "Locked Down" zones.

·         Impact of FDCC-mandated settings on typical IE users.

·         Recommendations regarding "Protected Mode" on Windows Vista.

·         Discussion of a bug that impacts the Local Machine zone (a.k.a., the "Computer" zone) on FDCC-compliant Vista computers.

·         Introduction of a new tool, IEZoneCompare, to visually identify and compare effective IE security zone policies and preferences.

Internet Explorer Security Zones

In this article:

Zones and Policies

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

RegEditIEZones

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

LogonOptions

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:

LockedDownZonesInGpEdit

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

Set_FDCC_LPGO v1.04 (Q3 2008) - Source code

The source code and Visual Studio project files for the Set_FDCC_LGPO Q3 2008 update are included as an attachment to this post.

To build the project, you need Visual Studio 2005 and the Windows SDK. The current NIST FDCC policy files are included in the attachment; to build with updated policy files, the attachment includes a PowerShell script to collect files from a locally-extracted copy of the NIST GPO files.  That script needed to be modified from the previous version, as the folder structure for the NIST GPOs has since been renamed, and earlier assumptions by the script no longer hold.  Details are described in the .ps1 script and the new .cmd batch file that are included.  Since the files have already been collected (in the "res" folder), you won't need to perform those steps to build the project anyway.

Source code is provided "AS-IS" without warranty, and is not supported by Microsoft customer support.

Set_FDCC_LGPO: Updated for 2008 Q3

Set_FDCC_LGPO is a utility that we originally released in December that applies the Group Policy Objects provided by NIST on their web site to the Local Group Policy on the Windows XP or Windows Vista computer you run the tool on.

NIST recently released FDCC Major Version 1.0 (Q3 2008), and so this utility has also been updated to incorporate the new GPOs.  The updated utility is provided as an attachment to this blog post.

This update also incorporates improved logging of its SecEdit.exe results.  The updated source code and project files for this release have also been posted.  (For the time being, it's still a Visual Studio 2005 project.)

See the earlier post for documentation.

Q&A From "Using BitLocker with FDCC and FIPS" webcast

Q&A content from the "Using BitLocker with FDCC and FIPS" webcast from May 27, 2008.  The recording of the webcast may be viewed on-demand here


Question: You may have mentioned this earlier but should FIPS be setup before or after FDCC?

Answer: FIPS should be enabled and applied to the end system before BitLocker Drive Encryption is enabled. If the FIPS compliance setting is enabled after the drive has been encrypted, you must turn off BitLocker (decrypt the drive) and then re-enable BitLocker.


Question: What would be the deployment strategy for telecommuters?

Answer: I recommend reading the Windows BitLocker Design and Deployment guides (http://www.microsoft.com/downloads/details.aspx?familyid=41ba0cf0-57d6-4c38-9743-b7f4ddbe25cd&displaylang=en&tm). Some factors to consider:

·         How many systems will need to be activated ( > 15 systems, recommend WMI scripts)

·         Are the systems domain attached

·         Initializing the TPM chip and enabling BitLocker requires administrative right.


Question: Does bitlocker work on solid state hard drives?

Answer: Yes, as long as the drive is an NTFS formatted and is Vista compatible.


Question: Any references/examples of govt agencies that have tested or used Bitlocker?

Answer: Not at this time, but I will inquire further.

 

 

Posted by Aaron Margosis | 0 Comments
Filed under:

Apply_LGPO_Delta 1.0 - source code

The source code and Visual Studio project files for the Apply_LGPO_Delta utility are included at an attachment to this post.

To build the project, you need Visual Studio 2005 or 2008 and the Windows SDK.

Source code is provided "AS-IS" without warranty, and is not supported by Microsoft customer support.

Apply_LGPO_Delta 1.0: utility to apply custom changes to Local Policy

Apply_LGPO_Delta v1.0 is a non-interactive tool that is designed to help make automated changes to Local Group Policy.  It can make changes to registry-based policy as well as apply security templates.  The primary intended scenario is to apply custom changes to FDCC policies after having applied those policies to Local Group Policy using a tool such as Set_FDCC_LGPO.

The utility requires administrative rights, and runs only on Windows XP Service Pack 2 or higher, or Windows Vista (RTM or higher).  If the utility is run without admin rights or on an unsupported platform, an error message is displayed in a message box dialog.

More information is available in the documentation (Apply_LGPO_Delta.htm) included in the zip file attached to this blog post.  The zip file also includes the utility, a set of starter input files representing common requested changes, and a batch file demonstrating command line syntax and conditional execution following Set_FDCC_LGPO.

Source code in the form of a Visual Studio 2005 VC++ project is available here.

 

Webcast for upcoming Local GPO tool

Updated, 28 April 2008

We're preparing a new utility for public release and will be demonstrating it in a webcast on Thursday, May 8, 2008 Tuesday, April 29, 2008, 2:30pm Eastern time.

The utility is called Apply_LGPO_Delta, and makes it possible to automate custom changes to local group policy.  It is intended to be used in conjunction with Set_FDCC_LGPO:  After you run Set_FDCC_LGPO to apply all the NIST GPO settings to local group policy, you can run Apply_LGPO_Delta to make specific changes to those settings.

Updated 28 April 2008, 11:51pm EDT:

Click here to register for the webcast.

(The webcast was postponed from its original date because of technical problems with the event registration site.  The issues have now been fixed.  Sorry for the inconvenience.)

Set_FDCC_LGPO: Updated for 2008 Q1

Set_FDCC_LGPO is a utility that we released in December that applies the Group Policy Objects provided by NIST on their web site to the Local Group Policy on the Windows XP or Windows Vista computer you run the tool on.

As NIST has recently updated those GPOs, this utility has also been updated to incorporate the new GPOs.  The updated utility is provided as an attachment to this blog post.

The source code is unchanged, except for:

  • The version numbers, copyrights, etc., have been updated (it's now version 1.02).
  • The registry.pol and GptTmpl.inf files have been updated from the newer NIST download.

See the earlier post for documentation.

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

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

Java Permissions properties dialog

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

Update: Importing FDCC Group Policy Objects Script Error Resolved

Author:  Joel Yoker, Principal Consultant

 

A reader recently sent in a question about the GPO Import script and a syntax error they received at line 356.  We were able to reproduce the error and it appears to be a "cut and paste" error between the blog post and Notepad.  It appears that that carriage returns are added between each line when you cut the text from the blog post in Internet Explorer and paste it directly into Notepad.

 

Here are the lines that are causing the syntax error:

 

WScript.Echo   "USAGE: cscript.exe //nologo " &  WScript.ScriptName & " [/OPTIONS]" & _

 

VbCrLf & _

 

Etc...

 

If you take out the extra lines added during the “cut and paste”, the script runs fine and the "& _" sections of the statement work without the syntax error.  Essentially, this block of code needs to look like this:

 

WScript.Echo   "USAGE: cscript.exe //nologo " &  WScript.ScriptName & " [/OPTIONS]" & _

VbCrLf & _

VbCrLf & "Script to import FDCC Group Policy Objects (GPO)" & _

VbCrLf & "into a given Active Directory domain. (Note: Requires" & _

Etc...

Posted by Mandy Tidwell | 0 Comments
Filed under:

Script a Custom Power Management Policy

Author: Paul Fox, Senior Consultant

Scenario: A customer wants a custom power plan for their laptop images. This is a frequent request to meet new Green initiatives in Federal and State governments.

Here are the steps to incorporate a scripted power configuration. The resulting install.cmd can be embedded into a task sequence of Microsoft Deployment Toolkit.

Note: Powercfg.exe is included in Vista, Windows XP SP2 and Windows Server 2003 operating systems.

1. Configure a power plan through the Control Panel -> Power Options UI

clip_image002[4]

2. Determine the GUID of your new power plan

C:\>Powercfg –l

Existing Power Schemes (* Active)

-----------------------------------

Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e (Balanced) *

Power Scheme GUID: 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c (High performance)

Power Scheme GUID: a1841308-3541-4fab-bc81-f71556f20b4a (Power saver)

3. Export the power plan

C:\ >powercfg -export <plan>.pow <guid_power_plan>

3. Import the <plan.pow> as an Application into MDT server

4. Create an Install.cmd batch file in notepad and call it as a command line parameter when importing into MDT’s Applications, contents as follows:

Note: In this script powercfg.exe will generate the GUID for the imported power plan. You can also assign a GUID to the power plan by passing it with the import command.

powercfg -import filename [GUID]

filename

Specifies a fully qualified path to a file generated by using the powercfg -export option.

GUID

(optional) Represents the settings loaded into a power scheme. If not supplied, Powercfg will generate and use a new GUID

Modify the import and set active portions with:

Set MYGUID=A6319DFD-EEF4-4644-9D74-9724744F1971

Powercfg.exe –import C:\scheme.pow %MYGUID%

Powercfg.exe –setactive %MYGUID%

If you generate your own GUID it is recommended to us a GUID generating utility (e.g. GUIDGEN included in developer tools)

:: Run Power Management Policy

:: Copy files locally, execute then delete

echo

C:

cd \users\public\downloads

mkdir powermgmt

cd powermgmt

copy "\\<MDT_Server>\distribution$\Applications\Laptop Power Management\*.*" \users\public\downloads\powermgmt

:: Import power plan

c:\windows\system32\powercfg -import C:\users\public\downloads\powermgmt\<plan>.pow

:: Get the GUID of the power plan

c:\windows\system32\powercfg -l > plans.txt

findstr /C "<plan_displayname>" plans.txt > import_plan.txt

:: Set power plan to active

for /F "tokens=4 delims= " %%i in (import_plan.txt) do c:\windows\system32\powercfg -setactive %%i

:: Delete

cd ..

rd /Q /S powermgmt

5. Open Control Panel -> Power Options UI and you will see you custom plan as “active.”

clip_image004[4]

More information about Powercfg.exe can be found at http://technet2.microsoft.com/WindowsVista/en/library/1d58b934-f56a-4796-b2df-7be2eb9c03bc1033.mspx?mfr=true

Posted by Mandy Tidwell | 1 Comments
Filed under:

Why don’t all of the FDCC settings appear in the Group Policy Editor?

Author: Mandy Tidwell, Senior Consultant 

 

As many of you may have noticed, the FDCC Group Policy settings spreadsheet and FDCC Group Policy Objects (GPOs) downloaded from NIST (http://csrc.nist.gov/fdcc) contain settings that are not exposed by default in the Group Policy Editor interface.  These settings are easily identified in that they all begin with MSS.

Ex. MSS: (AutoAdminLogon) Enable Automatic Logon (Not Recommended)

These additional group policy settings were developed by the Microsoft Solutions for Security group and are documented in the appropriate Windows XP and Windows Vista Security Guides.

The Windows XP and Windows Vista Security Guides are available using the following links:

Windows Vista

http://technet.microsoft.com/en-us/bb629420.aspx

 

Windows XP

http://www.microsoft.com/technet/security/prodtech/windowsxp/secwinxp/default.mspx

Exposing these additional settings prefaced with MSS can be accomplished by downloading the appropriate Windows Vista or Windows XP Security Guide and using the following steps:

Windows Vista

To modify the SCE to display MSS settings

1.       Ensure that you have met the following prerequisites:

·         The computer is joined to the domain using Active Directory where you created the GPOs.

·         The Windows Vista Security Guide GPOAccelerator Tool directory is installed.

o   Note You can also simply copy the GPOAccelerator Tool directory from a computer on which you have installed the directory to another computer that you want to use to run the script. The GPOAccelerator Tool folder and subfolders for it must be present on the local computer for the script to run as described in this procedure.

2.       Log on to the computer as an administrator.

3.       On the desktop, click the Windows Vista Start button, click All Programs, and click Windows Vista Security Guide.

4.       Open the GPOAccelerator Tool\Security Group Policy Objects folder.

5.       Right-click the Command-line Here.cmd file, and then click Run as administrator to open a command prompt with full administrative privileges.

6.       At the command prompt, type cscript GPOAccelerator.wsf /ConfigSCE and then press ENTER.

7.       In the Click Yes to continue, or No to exit the script message box, click Yes.

8.       In The Security Configuration Editor is updated message box, click OK.

 

To reset the SCE tool to the default settings in Windows Vista

1.       Log on to the computer as an administrator.

2.       On the desktop, click the Windows Vista Start button, click All Programs, and click Windows Vista Security Guide.

3.       Open the GPOAccelerator Tool\Security Group Policy Objects folder.

4.       Right-click the Command-line Here.cmd file, and then click Run as administrator to open a command prompt with full administrative privileges.

Note If prompted for logon credentials, type your user name and password, and then press ENTER.

5.       At the command prompt, type cscript GPOAccelerator.wsf /ResetSCE and then press ENTER.

6.       In the Click Yes to continue, or No to exit the script message box, click Yes.

Note Completing this procedure reverts the Security Configuration Editor on your computer to the default settings in Windows Vista. Any settings added to the default Security Configuration Editor will be removed. This will only affect the ability to view the settings with the Security Configuration Editor. Configured Group Policy settings remain in place.

7.       In The Security Configuration Editor is updated message box, click OK.

 

Windows XP

To manually update Sceregvl.inf

1.       Use a text editor such as Notepad to open the Values-sceregvl.txt file from the SCE Update folder of the download for this guide.

2.       Open another window in the text editor and then open the %systemroot%\inf\sceregvl.inf file.

3.       Navigate to the bottom of the “[Register Registry Values]” section in the sceregvl.inf file. Copy and paste the text from the Values-sceregvl.txt file, without any page breaks, into this section of the sceregvl.inf file.

4.       Close the Values-sceregvl.txt file and open the Strings-sceregvl.txt file from the SCE Update folder of the download.

5.       Navigate to the bottom of the “[Strings]” section in the sceregvl.inf file. Copy and paste the text from the Strings-sceregvl.txt file, without any page breaks, into this section of the sceregvl.inf file.

6.       Save the sceregvl.inf file and close the text editor.

7.       Open a command prompt and execute the command regsvr32 scecli.dll to re-register the DLL file.

To automatically update sceregvl.inf

1.       The Values-sceregvl.txt, Strings-sceregvl.txt, and Update_SCE_with_MSS_Regkeys.vbs files that are located in the SCE Update folder of the download for this guide must all be in the same location for the script to function.

2.       Execute the Update_SCE_with_MSS_Regkeys.vbs script on the computer you wish to update.

3.       Follow the onscreen prompts.

To reverse the changes made by the Update_SCE_with_MSS_Regkeys.vbs script

1.       Execute the Rollback_SCE_for_MSS_Regkeys.vbs script on the computer you wish to update.

2.       Follow the onscreen prompts.

 After extending the Security Configuration Editor interface using the above steps, you should now be able to see the MSS settings under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options using Group Policy Editor:  all the new entries will start with “MSS:”. 

Final Important Note

Note that although all of the FDCC Group Policy objects should be imported on a machine running the Group Policy Management Console on either a Windows 2000 or a Windows Server 2003 server, the Windows Vista and Internet Explorer 7 Group Policy Objects must only be viewed and edited from a machine running either Windows Vista or Windows Server 2008.  For more information about this requirement, please see the following web site:

http://technet2.microsoft.com/WindowsVista/en/library/02633470-396c-4e34-971a-0c5b090dc4fd1033.mspx?mfr=true