Active Directory

Contents

Group Policy

Group Policy provides a central way of managing user and computer configuration. You can use Group Policy to configure everything from password and auditing policies to software deployment, desktop background settings, and mappings between file extensions and default applications.

INSIDE OUT

Not the only configuration management option

It’s fair to say that Group Policy is really starting to show its age. On the server side, Microsoft is pushing Desired State Configuration as the primary method of managing server configuration. On the client side, you often get a better result using tools such as Configuration Manager for on-premises deployments and Intune for clients that aren’t domain joined.

GPO management

After you get beyond editing GPOs to configure settings, you need to start thinking about issues such as GPO maintenance. For example, if an important document is lost, you need to know how to recover it from backup. Do you know what to do if someone accidentally deletes a GPO that has hundreds of settings configured over a long period of time?

The main tool you’ll use for managing GPOs is the Group Policy Management Console (GPMC), shown in Figure 4-23. You can use this console to back up, restore, import, copy, and migrate. You can also use this console to delegate GPO management tasks.

Figure 4.23

Figure 4-23 Group Policy Management Console

In larger environments, there is more than one person in the IT department. In very large organizations, one person’s entire job responsibility might be creating and editing GPOs. Delegation enables you to grant permission to perform specific tasks to a specific user or group of users. You can delegate some or all of the following Group Policy management tasks:

  • GPO creation

  • GPO modification

  • GPO linking to specific sites, organizational units (OUs), or domains

  • Permission to perform Group Policy Modeling analysis at the OU or domain level

  • Permission to view Group Policy Results information at the OU or domain level

  • Windows Management Instrumentation (WMI) filter creation

Users in the Domain Admins and Enterprise Admins groups can perform all Group Policy management tasks. Users who are members of the Group Policy Creator Owners domain group can create GPOs. They also have the right to edit and delete any GPOs that they’ve created. You can delegate permissions to GPOs directly using the GPMC.

There are also a substantial number of cmdlets available in the PowerShell Group Policy module, including the following:

  • Get-GPO Enables you to view GPOs

  • Backup-GPO Enables you to back up GPOs

  • Import-GPO Enables you to import a backed-up GPO into a specified GPO

  • New-GPO Enables you to create a new GPO

  • Copy-GPO Enables you to copy a GPO

  • Rename-GPO Enables you to change a GPO’s name

  • Restore-GPO Enables you to restore a backed-up GPO to its original location

  • Remove-GPO Enables you to remove a GPO

Creating GPOs

Creating a GPO is simply creating a new Group Policy Object. Newly created GPOs have no settings applied. Follow these steps to create a new GPO:

  1. Open the Group Policy Management Console.

  2. Under Forest\Domains\Domain Name, right-click Group Policy Objects and select New.

  3. Provide a name for the new GPO and select OK.

If you want to delegate the ability for users to create GPOs, you can add them to the Group Policy Creator Owners group. You can also explicitly permit them to create GPOs using the GPMC. To do this, perform the following steps:

  1. Open the GPMC from the Tools menu of Server Manager.

  2. Expand the domain in which you want to delegate the ability to create GPOs, select Group Policy Objects, and select the Delegation tab.

  3. Select Add and select the group or user that you want to give the ability to create GPOs in that domain.

Editing GPOs

To edit a GPO, users must be either a member of the Domain Admins or Enterprise Admins group. Users can edit a GPO if they

  • Created it

  • Have been given Read/Write permissions on the GPO through the GPMC

To grant a user permission to edit a GPO, perform the following steps:

  1. Select the GPO in the GPMC.

  2. Select the Delegation tab.

  3. Select Add, specify the user or group that should have permission to edit the GPO, and then specify the permissions that you want to give this user or group. You can choose from one of the following permissions:

    • Read

    • Edit Settings

    • Edit Settings, Delete, Modify Security

Linking GPOs

Linking a GPO to an object such as a domain or OU involves navigating to the location in the Group Policy Management Console, right-clicking on that location, and selecting Link Existing GPO. You then select which of the existing GPOs you want to link to the domain or OU. You can also create and link a GPO using this method.

To enable a user to link a GPO to a specific object, you need to edit the permission on that object. You can perform this task in the GPMC. For example, to grant a user or group permission to link a GPO to an OU, select the OU in the GPMC, select the Delegation tab, select Add, and then select the user or group to which you want to grant this permission.

Backup GPOs

Backing up a GPO enables you to create a copy of a GPO as it exists at a specific point in time. A user must have read permission on a GPO to back it up. When you back up a GPO, the backup version of the GPO is incremented. It’s good practice to back up GPOs prior to editing them so that if something goes wrong, you can revert to the unmodified GPO.

You should back up GPOs before you or other people modify them. If a problem occurs, it’s quicker to restore a backup than it is to reconfigure the modified GPO with the existing settings.

To back up a GPO, perform the following steps:

  1. Open the GPMC.

  2. Right-click the GPO that you want to back up and select Back Up. In the Back Up Group Policy Object dialog, enter the location of the backup and a description for the backup, and then select Back Up.

You can restore a GPO using the Restore-GPO cmdlet. Restoring a GPO overwrites the current version of the GPO if one exists or re-creates the GPO if the GPO has been deleted. To restore a GPO, follow these steps:

  1. Right-click the Group Policy Objects node in the GPMC and select Manage Backups.

  2. In the Manage Backups dialog, select the GPO you want to restore and select Restore.

  3. If multiple backups of the same GPO exist, you can select which version of a GPO to restore.

Import and copy GPOs

Importing a GPO enables you to take the settings in a backed-up GPO and import them into an existing GPO. To import a GPO, perform the following steps:

  1. Right-click an existing GPO in the GPMC and select Import Settings.

  2. In the Import Settings Wizard, you are given the option of backing up the destination GPO’s settings. This enables you to roll back the import.

  3. Specify the folder that hosts the backed-up GPO.

  4. On the Source GPO page of the Import Settings Wizard, select the source GPO. You can view the settings that have been configured in the source GPO prior to importing it. Complete the wizard to finish importing the settings.

Remember that when you import settings from a backed-up GPO, the settings in the backed-up GPO overwrite the settings in the destination GPO.

Copying a GPO creates a new GPO and copies all configuration settings from the original to the new. You can copy GPOs from one domain to another. You can also use a migration table when copying a GPO to map security principals referenced in the source domain to security principals referenced in the destination domain.

To copy a GPO, perform the following steps:

  1. Right-click the GPO that you want to copy and select Copy.

  2. Right-click the location that you want to copy the GPO to and select Paste.

  3. In the Copy GPO dialog, choose between using the default permissions and preserving the existing permissions assigned to the GPO.

Fixing GPO Problems

Windows Server includes command-line utilities that allow you to repair a GPO after you perform a domain rename or re-create default GPOs. If you need to re-create the default GPOs for a domain, use the DCGPOFix command. If you perform a domain rename, you can use the GPFixup command to repair name dependencies in GPOs and Group Policy links.

Migrate Group Policy Objects

When moving GPOs between domains or forests, you need to ensure that any domain-specific information is accounted for, so locations and security principals in the source domain aren’t used in the destination domain. You can account for these locations and security principals using migration tables. You use migration tables when copying or importing GPOs.

Migration tables enable you to alter references when moving a GPO from one domain to another, or from one forest to another. An example is when you are using GPOs for software deployment and need to replace the address of a shared folder that hosts a software installation file so that it’s relevant to the target domain. You can open the Migration Table Editor (MTE) by right-clicking Domains in the GPMC and selecting Open Migration Table Editor.

When you use the MTE, you can choose to populate from a GPO that’s in the current domain or to populate the MTE from a backed-up GPO. When you perform this action, the MTE will be populated with settings that reference local objects. If there are no results, then no local locations are referenced in the GPO that you’re going to migrate.

INSIDE OUT

Restoring GPO doesn’t restore links

Note that restoring a GPO does not restore the GPO’s links, such as links to specific OUs. You can, however, determine where the GPO was linked prior to restoring the GPO by viewing information about the backed-up GPO.

Policy processing

Group policy is processed in the following order, with subsequent policies overriding previously applied policies where conflicts exist:

  • Local Settings configured at the local level apply first. If multiple local policies apply, settings in machine policies apply first, settings in admin and nonadmin local policies override them, and settings in per-user policies override any configured at the machine and admin/nonadmin levels.

  • Site Policies based on location apply next. Any settings configured at the site level override settings configured at the local level. You can link multiple GPOs at the site level. When you do this, policies with a lower numerical link order override policies with a higher numerical link order.

  • Domain Settings applied at the domain level override settings applied at the site and local levels. You can link multiple GPOs at the domain level. The Default Domain Policy is linked at this level.

  • Organizational unit (OU) Settings applied at the organizational unit level override settings applied at the domain, site, and local levels. When an account is a member of a child OU, policies applied at the child OU level override policies applied at the parent OU level. You can apply multiple GPOs at the OU level. Policies with a lower numerical link order override policies with a higher numerical link order.

For example, if one policy configures a setting at the AD site level and another policy configures the same setting at the OU level, the policy that configures the setting at the OU level is applied.

The exception to this is when you configure one of the following settings:

  • Block Inheritance The Block Inheritance option allows you to block upstream policies from applying. You can configure this option at the Domain or OU level. It blocks all upstream settings except those configured through a policy that has the No Override setting.

  • No Override You use the No Override setting to stop the Block setting. Use this on policies that you need to have enforced.

Every setting that is configured in a Group Policy item will be examined during the Group Policy processing. Configuring settings you don’t need increases Group Policy processing times, which can increase startup and logon times.

Resultant Set of Policy tool

The Resultant Set of Policy tool allows you to generate a model of Group Policy application, allowing you to figure out which policies apply to particular objects within the domain. Resultant Set of Policy allows you to figure out why the Group Policy application isn’t behaving in the way that you expect and allows you to resolve Group Policy conflicts.

There are two ways you can calculate the Resultant Set of Policy. The first is to use Group Policy Modeling. The second is to use Group Policy Results. The difference between these is as follows:

  • Group Policy Modeling Allows you to view the impact of altering site membership, security group membership, filtering, slow links, loopback processing, and the movement of accounts to new OUs on the application of policy.

  • Group Policy Results Allows you to troubleshoot the application of policy by telling you which settings apply to a specific user or computer account.

By default, members of the Domain Admins and Enterprise Admins groups can generate Group Policy Modeling or Group Policy Results information. You can delegate permissions so users can perform these tasks at the OU or domain level.

INSIDE OUT

Policy in multidomain forests

Policies linked at the site level in multidomain forests are stored in the root domain. This can cause challenges with Group Policy application in scenarios in which a site-linked policy applies but where no DC with a root domain membership is present in the local site.

Filtering

GPO filtering allows you to determine whether a linked GPO applies based on group membership or the results of a WMI query. By default, a linked GPO will have the security filter set so it applies to Authenticated Users and no WMI filter set, as shown in Figure 4-24. If a GPO is only supposed to apply to a specific group of users or computers in the domain, site, or OU, specify the security group and remove the Authenticated Users group.

Figure 4.24

Figure 4-24 GPO filtering

For example, you could write a WMI query that performs a check so that a GPO only applies if the computer has more than 4 GB of RAM. If the computer has more than 4 GB of RAM, the policy applies normally. If the computer has less than 4 GB of RAM, the GPO does not apply. WMI filters must be assessed, which can slow down Group Policy processing. Many of the scenarios in which WMI filtering might have been appropriate 20 years ago can be better accomplished using PowerShell scripts.

INSIDE OUT

Site-linked GPOs

If Group Policy processing takes too long because of site-linked GPOs, the simplest solution is not to link polices at the site level; instead, you apply the links at the domain level and use Group Policy filtering through a WMI query to ensure location-specific GPOs are applied. An alternative is to place domain controllers that have root domain membership at each site, although this is likely to be more expensive than the policy filtering option.

Loopback processing

Each GPO has two distinct sections: Computer Configuration and User Configuration. The resultant policies for a user are based on the cumulative user configuration settings in GPOs that apply to the user’s accounts at the site, domain, and OU settings. The resultant computer policies are applied based on the cumulative computer configuration settings in GPOs that apply to the computer’s account at the site, domain, and OU level.

In some situations, you’ll want only the GPOs that apply to the computer account to apply. You might want to do this with conference room computers, for which you want people to be able to sign on with domain accounts but to have a very controlled configuration. When you enable loopback processing, user settings are determined based on the settings in the User Configuration settings area of GPOs that apply to the computer account.

There are two types of loopback processing that you can configure by setting the Group Policy loopback processing mode policy. This policy is located under the Computer Configuration\Administrative Templates\System\Group Policy node and can be configured with the following settings:

  • Replace When you configure Replace, only the GPOs that apply to the computer account will apply. Settings in the User Configuration area of the GPOs that apply to the computer account will apply.

  • Merge The settings in the User Configuration area of GPOs that apply to the user account will still apply but will be overridden by settings in the User Configuration area of GPOs that apply to the computer account.

Slow-link processing enables you to configure Group Policy application to be performed differently, depending on the speed of the connection from the client to the domain controller. It enables you to block activities such as software deployment when the connection between Active Directory and the client is detected as falling below a particular threshold. You configure slow-link detection by configuring the Group Policy slow-link detection policy located under Computer Configuration\Administrative Templates\System\Group Policy. When a slow link is detected, Registry settings from administrative templates, security policies, EFS recovery policy, and firewall policies are applied. Policies related to application deployment, scripts, folder redirection, and disk quotas will not be applied.

Group Policy caching

Group Policy caching reduces the amount of time taken to process Group Policy during computer startup and user sign-on. Rather than retrieve the Group Policies that apply to the computer from a domain controller when a computer starts up or a user signs on, the client will use a cached copy of the last Group Policies downloaded from the domain controller. After this initial application of the cached policies during startup and user sign-on, policies will be retrieved and applied normally from a domain controller. You enable Group Policy caching by configuring the Configure Group Policy Caching policy. This policy is located under Computer Configuration\Policies\Administrative Templates\System\Group Policy.

Force Remote Group Policy update

Remote Group Policy update allows you to force a remote computer to perform a Group Policy update without having to sign on to the computer and run the GPUpdate command or the Invoke-GPUpdate PowerShell cmdlet. Remote Group Policy requires that the following firewall rules be enabled on clients:

  • Remote Scheduled Tasks Management (RPC)

  • Remote Scheduled Tasks Management (RPC-EPMAP)

  • Windows Management Instrumentation (WMI-In)

You can run a remote Group Policy update from the Group Policy Management Console by right-clicking on a container or OU. An update will run on all computers within the container or OU, as well as on any computer accounts stored within child OUs. You can also use the Invoke-GPUpdate PowerShell cmdlet to trigger a remote Group Policy update. The advantage of the PowerShell cmdlet is that you can target a specific computer rather than all computer accounts in an OU.

Group Policy preferences

Group Policy preferences work around the idea of eliminating (or at least substantially reducing) the need for traditional start-up and log-in scripts. Log-in scripts have a way of becoming convoluted over time. Group Policy preferences allow simplification of common log-in and start-up script tasks, such as drive mappings and setting environment variables.

By reducing or eliminating some of the complexity of log-in scripts, you can use Group Policy preferences to reduce configuration errors. You can use Group Policy preferences to configure the following settings:

  • Applications

  • Drive mappings

  • Environment variables

  • File updates

  • Folders

  • Ini files

  • Registry settings

  • Shortcuts

  • Data sources

  • Devices

  • Folder options

  • Internet settings

  • Local users and groups

  • Network options

  • Network shares

  • Power options

  • Printer settings

  • Regional options

  • Scheduled tasks

  • Start Menu settings

Some of these items can also be configured using a traditional Group Policy. In the event that an item is configured in the same GPO using both policy and preferences, the traditional setting takes precedence. The difference between a Group Policy preference and a normal Group Policy setting is that users can change a Group Policy preference if they have the appropriate permissions. For example, users can unmap a mapped network drive. The drive would remain unmapped until the user logged in again, at which point it would be remapped. Generally, if you want to enforce a setting, use a standard Group Policy. If you want to apply the setting and allow users to change it, use a Group Policy preference. The closest you can come to enforcing a Group Policy preference is to disable the Apply Once And Do Not Reapply setting in the policy item’s configuration. This way, the preference is applied each time Group Policy refreshes.

You can target Group Policy preferences so that different preferences can apply to the same item types within a single GPO. You can use the following items to restrict how a Group Policy preference applies:

  • The computer has a battery.

  • The computer has a specific name.

  • The computer has a specific CPU speed.

  • Apply by or after a specific date.

  • The computer has a certain amount of disk space.

  • The computer is a member of a domain.

  • The computer has a particular environment variable set.

  • A certain file is present on the computer.

  • The computer is within a particular IP address range.

  • The computer uses specific language settings.

  • The computer meets the requirements of an LDAP query.

  • The computer has a MAC address within a specific range.

  • The computer meets the requirements of a WMI query.

  • The computer uses a specific type of network connection.

  • The computer is running a specific operating system.

  • The computer is a member of a specific OU.

  • The computer has PCMCIA.

  • The computer is portable.

  • The computer uses a specific processing mode.

  • The computer has a certain amount of RAM.

  • The computer has a certain registry entry.

  • User or computer is a member of a specific security group.

  • The computer is in a specific Active Directory site.

  • The computer has a Remote Desktop Setting.

  • That a specific time range is present.

  • The user has a specific name.

Administrative templates

Group Policy Administrative Templates allow you to extend Group Policy beyond the settings available in GPOs. Common software packages, such as Microsoft Office, often include Administrative Templates that you can import to manage software-specific settings. In early versions of Windows Server, Administrative Templates were available as files in ADM format. Since the release of Windows Server 2008, Administrative Templates are available in a standards-based XML file format called ADMX.

To be able to use an Administrative Template, you can import it directly into a GPO using the Add/Remove Templates option when you right-click the Administrative Templates node. A second option is to copy the Administrative Template files to the Central Store, located in the c:\Windows\Sysvol\sysvol\<domainname>\Policies\PolicyDefinitions folder on any domain controller. You might need to create this folder if it does not already exist. After the folder is present, the template is then replicated to all domain controllers, and you can access the newly imported Administrative Templates through the Administrative Templates node of a GPO.

Reverting settings configured by Group Policy

Removing or unlinking a GPO does not always revert the affected settings on client machines. The outcome depends on the type of policy, how it was applied, and the nature of the setting. Consider the following when trying to revert settings applied using Group Policy:

  • Group Policy Preferences write their values directly into the standard registry or system configuration areas, not the special policy areas. This process is sometimes termed “tattooing.” When the GPO or preference is removed, the setting remains at its last-applied value and is not reverted or reset to the previous or default state. The original value is overwritten and lost, so the system retains the “tattooed” configuration until it’s changed by another means.

  • Some policy settings do not revert to their previous or default state when the GPO is set to “Not Configured” or removed. Instead, the system keeps the last value set by the policy. This is especially common with certain registry-based settings.

  • Changes to service startup types, file/folder permissions, or other system configurations that are not managed exclusively through policy areas may persist after a GPO is removed.

INSIDE OUT

Like that before I got here

In scenarios where group policies have been used with systems that have been in production for some time, settings might have been configured long ago by policies that have since been removed. You might need to use Desired State Configuration or manual tools to change settings back to defaults that were altered by a no longer applied Group Policy Object.

Save to your account

This chapter is from the book