Archive for the ‘Group Policy’ Category

There are many reasons to create a custom ADM/ADMX template: managing settings for software that doesn’t include GPO support, a modification to an OS setting that isn’t part of the standard templates, disable or enable a specific component (e.g. IPv6) or to extend the features of existing policy settings (e.g. redirect user shell folders).

All of these have one thing in common: they complete their function by modifying registry keys, the core function of the custom ADM or ADMX template. This commonality results in the following typical high level process for creating or modifying custom ADM/ADMX files:

  1. Research the registry keys that control the required settings.
  2. Learn and understand the template file format.
  3. Create and test the custom template file.
  4. Repeat step 3 until everything works right (usually the longest step in the process).
  5. Deploy the templates to configure GPOs after training administrators about the differences between managed and unmanaged settings.
  6. Respond to questions and issues when the mechanism malfunctions, the specific requirements change or people forget the operation process for using the custom template.

There’s not much we can do about step 1 since we need to determine how to configure the required settings but past that step, this is a fairly long and sometimes painful road to implement the required change. As a result, many administrators choose to use scripts or .REG files to simplify the process and avoid having to dig into the ADM/ADMX file format.

With the introduction of group policy preferences with Windows 2008, we now have the registry extension that can accomplish the same task and much much more. The base functionality allows us to deploy registry keys as well as custom templates or scripts but this mechanism includes the following additional benefits:

  • The ability to import keys from the local computer’s registry – once you configure the required settings on your admin computer, you can import them directly into the GPO.
  • The ability to organize and manage keys by collection.
  • The ability to manage all of the key types: strings, DWORD, QWORD, multi-string value, expandable-string value and binary values.
  • The ability to update, replace or delete existing strings – the update action will only update the value data whereas the replace action will delete the existing key/value and create a new one with the desired value data.

In addition to the registry extension specific benefits, we also get the following benefits that are global to all preferences:

  • The ability to run user settings using the system security context
  • The ability to remove the item when the setting is no longer applied – this is an important option that allows the preference to behave similar to a managed policy setting (note that this will not re-instate an original value, just remove the setting).
  • The ability to create a true preference and apply the setting only once allowing the user to change it.
  • ..and most importantly, the ability to configure conditional expressions for each registry key or collection to further define its target. This capability, known as item-level targeting (or ILT) is a very granular and powerful engine that provides an administrator the tools to direct each setting to the computers or users who need it based on over 25 categories of properties including hardware levels, OS, networking configuration, group membership and any registry/file/LDAP/WMI query.

Given these benefits, the registry extension becomes the ‘Swiss army knife’ of custom registry modifications to Windows systems and user environments.

So while there is still a need for ADMX templates from Microsoft to manage the OS and there’s a strong need for templates from other software vendors, when those templates are not available, I reach for the registry extension and avoid any authoring of custom ADM/ADMX templates.

So are custom ADM/ADMX template a thing of the past?  please share in the comments section. I’m interested in how many folks out there are still creating custom template files.

 

Local group membership is used to manage access for a variety of reasons. Applications leverage local groups for access to system resources. Protective systems and support staff also require specific privileges that are granted using local groups.  The need to manage membership of these groups becomes an important goal in order to meet business objectives in the areas of security, manageability and availability.

The most typical need that comes up is the need to manage membership of the local Administrators group. This high privilege group that in many cases includes the ‘Domain Users’ group is now a potential security problem and needs to be restricted to protect the system. Often the desired membership is limited to the user who ‘owns’ the system along with support personnel and locked down otherwise to reduce the ability of malicious individuals and code to compromise the system.

My example and discussion will focus on the need to control the local Administrators group but most of the points will apply to other scenarios as well.

Group policy offers several approaches to meeting this goal and of course, they each work well in different scenarios. Let’s dig into the options and when they should be used or avoided.

Restricted Groups

The first mechanism I’m going to cover has been around in Group Policy for many years but is still frequently misunderstood.

The restricted groups configuration node can be found under Computer Configuration\Policies\Windows Settings\Security Settings\Restricted Groups. The component is configured by adding a group (you can either browse or type in a group name) and then configuring the members of the group or the groups this group is a member of.

This mechanism has one very important nuance (important enough to keep someone from getting fired!). If the group membership is controlled (using the top part of the configuration dialog), the existing group membership will be replaced by the configuration. This means that potentially important existing security principals are removed, that maintaining exceptions for specific machines is complex and that using multiple GPOs to configure this mechanism in a cumulative manner isn’t possible.

As a result, controlling group membership directly is rare and typically only used in environments where complete control is required and no further modification to the group’s membership is needed or anticipated.

The lower half of the configuration dialog, or the indirect configuration method, are much more useful in my experience. The behavior of this component is cumulative so any configuration changes are added to existing group membership.

Leveraging restricted groups to manage the Administrators group will therefore involve the following steps:

  • Create an AD group to contain privileged accounts that will be added to the local Administrators group
  • Create a GPO for local group management
  • Add the AD group created to the restricted groups interface
  • Add the local administrators group to the AD group configuration within restricted groups using the bottom, or ‘Member of’, section
  • Refresh the policy

Using this approach, a single GPO can contain multiple restricted groups entries and would manage local group membership for a collection of systems. This allows a decent level of basic local group management but it does leave a taste that something easier to use, more powerful and more flexible should be available these days. This is where group policy preferences come in…..

Local Users and Groups Extension

The introduction of group policy preferences (GPPs) with Windows Server 2008/Vista brought a whole new mechanism to manage local groups (and users). GPPs provide an extension to manage local users and groups that provides a lot of control and flexibility. Let ‘s take a look at what is possible:

First, the extension exists under both the user and computer configuration nodes under Preferences\Control Panel Settings\Local Users and Groups with some benefits to the user section that will be discussed below. Note that when using the user configuration section, the extension can be configured to be limited by the permissions of the user by selecting ‘Run in logged-on user’s security context’ on the Common tab.

Once the extension is selected and a new group is added, the administrator can use the interface to rename the group, remove existing users and groups from the membership list and add or remove specific security principals to/from the group’s membership.

In addition to these operations, the extension takes advantage of common (and powerful) GPP features like ‘Apply once’, item-level targeting and policy actions such as update/replace/create/delete  (which allows removal of a group or user account).

Another great features is available when using the user configuration version of the extension which can automatically manage membership for the ‘current user’ through the GPO making it easy to add the local user only to a local group.

In my opinion, all local user and group membership administration should be performed using GPPs and the Local Users and Groups extension. The improved interface, granular control and benefit of GPP mechanisms makes this the ideal choice for the task.

For more information about GPPs and what they require, check out my previous blog post: https://rdpfiles.com/2009/11/13/group-policy-preferences-aka-gpps-2/.

Security GPOs provide a number of ‘hidden’ settings that all start with the ‘MSS’ prefix. These settings are referenced in the NIST FDCC guidelines for group policy as well as many other locations. The settings would all normally be found under Computer Configuration\Windows Settings\Security Settings\Local Policy\Security Options. However, the settings are not readily visible or available within a GPO.

If you search for instructions on enabling the settings, you will find the following instructions:

  1. Download and install the Windows 7 Security Compliance Management Toolkit. (http://www.microsoft.com/downloads/details.aspx?FamilyID=5534bee1-3cad-4bf0-b92b-a8e545573a3e&displaylang=en)
  2. Log on to the computer as an administrator.
  3. On the desktop, click the Start button, click All Programs, and click Microsoft Security Compliance Manager and then Local GPO.
  4. On the desktop, click the Start button, click All Programs, and click LocalGPO
  5. Right-click the LocalGPO command-line file, and then click Run as administrator to open a command prompt with full administrative privileges.
  6. At the command prompt, type cscript LocalGPO.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.

These instructions will do the trick but they always frustrate me because the installation of the Security Compliance Management Toolkit is quite large and includes the installation of SQL Express. It seems that a simple task like viewing important GPO settings doesn’t need this full package to be installed on each GPO management console.

Well, it turns out that it doesn’t. With a little manipulation, you can install only the required pieces. Just follow this procedure:

  1. Download the toolkit and start the installation but don’t click any buttons when the wizard starts.
  2. Navigate to the root of your C drive and look for the temporary directory created by the installation. The directory name will be a long hex string.
  3. Open the directory and extract the contents of the data.cab file using any decompression tool.
  4. Find the extracted file GPOMSI and rename it to LocalGPO.MSI.
  5. Run LocalGPO.MSI and complete the installation.
  6. Cancel the original installation of the toolkit.
  7. Continue with step 4 in the instructions above.

Nice, quick and simple and you can keep the LocalGPO.Msi file for installation on other systems.

Group Policy Preferences aka GPPs

Posted: November 13, 2009 in Group Policy

The biggest change to group policies since Windows 2000 comes to Windows courtesy of a Microsoft purchase of a company called Desktop Standard. Among several excellent enhancements to group policies comes Group Policy Preferences (GPPs). GPPs allow group policy objects to control a whole new set of Windows settings using Active Directory based GPOs. Along with dozens of new policy settings, GPPs introduce several new concepts to GPOs, namely multiple setting actions, item level targeting and one time application of settings. Each of these individually would make this new mechanism worth a look, but the combination is one of the most powerful tools available to Windows system administrators, and it’s all included in Windows at no additional cost.

Requirements

Before we dig into what GPPs can control and how they control it, let’s go over the requirements for using GPPs. The popular misconception is that GPPs require a significant investment in upgrading the domain, DCs or the entire network to Windows 2008/R2 and Vista/Windows 7. The truth is that the requirements are significantly lower than that. There are two sets of requirements related to using GPPs, the requirements to edit a GPO and to apply a GPO:

  • Editing a GPO with GPPs requires a system running Windows Server 2008, Windows Server 2008 R2, Windows Vista SP1+ or Windows 7. Therefore, introducing a single machine running any of these operating systems to a network would allow GPOs using GPPs to be created.
  • Applying a GPO with GPPs is supported on the  above mentioned operating systems (Windows Server 2008, Windows Server 2008 R2, Windows Vista SP1+ and Windows 7) but also on Windows XP SP 2+ and Windows 2003 SP2+. In order to use GPPs on Windows XP SP2, Windows 2003 and Vista RTM, the new Client Side Extensions (CSEs) for GPPs must be downloaded and installed. The updated CSEs are included in Windows XP SP3 and Vista SP1.

You’ll notice that there are no requirements for your domain controllers and or other server operating systems!!!

Significant Features

GPPs introduce several unique new features that expand and enhance the usage of group policies and can be used for all GPPs:

  • Item level targeting

This feature, available on the Common tab, allows the construction of a multipart conditional statement that must be met before the setting is applied. Since the condition only applies to one setting, a single GPO can have settings that are applied to different users and computers. The condition parameters include items such as:

  • Computer Name
  • CPU Speed
  • Disk Space
  • Domain
  • Environment Variable
  • IP Address Range
  • Operating System
  • Organizational Unit
  • RAM
  • Site
  • and User

Also available are conditions that query specific registry keys, files, LDAP objects and WMI properties.

  • Apply once

Another feature that can be found on the Common tab and therefore used for the large majority of GPPs, is represented by a checkbox labeled ‘Apply once and do not reapply’. Using this setting allows the administrator to implement a default setting but allow users to modify the setting. This ‘soft’ application of GPO settings is a powerful tool for system administrators.

  • Modification actions

Found on the default and left-most tab of most GPPs is the Action pulldown. This setting provides granular control for the type of action used when applying the setting and contains the following options:

  • Create – This action will create a new object as specified. If an object exists, no action will be taken.
  • Replace – If the specific object exists, it will be removed and a new one created with the specified settings. If the object doesn’t exist, it will be created. This setting is similar to traditional GPOs and force a configuration regardless of existing settings.
  • Update – If the specific object exists, it will be updated with any specified settings. Other settings will not be distributed. If the object doesn’t exist, it will be created.
  • Delete – This action will search for the specific object and delete it.

GPP Extensions

Of the approximately 20 new setting areas (or extensions) introduced with GPP, the majority provide a new, easier method of configuring settings that historically required complex scripts, third party utilities or were not possible at all.

The following extensions can be used to replace tasks traditionally completed with scripts or batch files:

  • Drive maps
  • Printers
  • Environment
  • Files
  • Registry
  • Shortcuts
  • Local Users and Groups

Whereas the following extensions present functionality that is new to GPOs:

  • Start Menu
  • Folder Options
  • Power Options
  • Data Sources
  • Network Shares

The features, functions and elements described here are just examples of the new options available with GPPs. A review of the preferences sections within the GPO will quickly allow any administrator to find settings that address their own issues and optimize systems management in their organization.

hopefully this introduction helps readers understand GPPs a little better and leads some to leverage these very capable tools. If you have found a cool use for GPPs, please comment and share.