Home 2024

Group Policy – a Practical Overview

Group Policy is a powerful feature in Microsoft’s Active Directory that allows administrators to centrally manage and configure user and computer settings. This overview will address common misconceptions and provide practical insights into its application.

Active Directory Containers vs. Organizational Units (OUs)

Default AD containers like “Users” and “Computers” cannot be targeted by Group Policy. Creating a company OU structure is preferred as it allows for more granular Group Policy application[1]. OUs are the lowest-level AD containers to which you can assign Group Policy settings[4].

For an example:

_ThisCompany (the _ sorts it to the top, no matter the name)

  • Users
    • Employees
      • Executives
      • Office
      • Remote
    • Vendors
    • Service Accounts
    • Disabled User Accounts
  • Computers
    • Servers
      • RDP Servers
      • Disabled Servers
    • Workstations
      • Shared Workstations
      • Disabled Workstations
  • Security Groups
    • User Groups
    • Computer Groups

Applying Group Policy

Domain-Level Application

Group Policy can be applied to the entire domain by linking it at the domain level. With the default scope of Authenticated Users, this applies to all users and computers in the domain. Please note that “Authenticated Users” is a system group that contains all users and all computers in the whole domain.


Adjusting Scope

For more granular control within a GPO, you can use Item-Level Targeting on certain policy preferences, such as mapped drives. This allows specific settings to apply only to certain users or computers within the GPO’s scope. For example, you could create a single Drive Map policy that:

Maps a “Public” drive for all users,
Maps an “Executive” drive only for members of the Executives security group,
Maps an “Office” drive for users in the Office group,
And maps an “RDPDrive” only when users in the RDP Users group log in to servers that are members of the RDP Servers group.

This approach keeps your GPOs cleaner and more efficient by consolidating multiple conditions into a single policy using targeting rules.


OU-Level Application

OUs provide granular control. Policies linked to an OU only apply to objects within that OU, even with a scope of Authenticated Users.

In the above image, the User policies in “Executive Drive Maps” will apply to people in the Executives security group.

When multiple GPOs apply to a user or computer, the order of precedence is:

  1. Local Group Policy
  2. Site-level GPOs
  3. Domain-level GPOs
  4. OU-level GPOs (from parent OU down to child OU)

Lower-level OUs override higher-level ones, unless the higher-level GPO is Enforced.

However, the Lower-level OU policy will still override the higher policy in practice, even though it really shouldn’t. Technically, when a GPO is Enforced, it does two things:

Wins conflicts: If two GPOs configure the same setting, the Enforced GPO wins, even if it’s higher in the hierarchy.

Prevents override: Its settings cannot be overridden by GPOs linked to child OUs.

Practically, that isn’t the case. (Microsoft, eh?)

To get conflicting policies to work, apply both to the same level OU and use Link Order to put the one you want to actually apply to the lowest number (ie, 1). Use the ‘arrows’ to move a policy up or down in link order.


Group Policy Objects (GPOs)

GPOs are virtual collections of policy settings stored in the Group Policy Objects container in Group Policy Management Console (GPMC)[1]. They must be linked to OUs or the domain to take effect.

Computer vs. User Configuration

Group Policy Objects (GPOs) are divided into two main sections:

Computer Configuration – applies to computer accounts.

User Configuration – applies to user accounts.

However, where the GPO is linked and which objects reside in that scope determines what actually gets applied.
Computer Configuration settings only apply to computer objects that reside in the OU (Organizational Unit) where the GPO is linked.

User Configuration settings only apply to user objects in the linked OU.

Important: Placing a security group in an OU does not extend GPO scope to its members. The actual user or computer object must be in the OU.
If a GPO is linked to an OU that contains only computers, the User Configuration section of that GPO will not apply to anything — because there are no user objects in scope.

If you want Computer Configuration settings to apply to specific computers, those computer accounts must reside in the OU where the GPO is linked.

Likewise, for User Configuration settings to apply, the user accounts must be in the linked OU.

Files, Scripts and Policies

This might seem obvious, but it’s worth stating clearly: when using a GPO to copy files from a network share — even something like NETLOGON — you need to reference the UNC path that users would actually use. For example, if you place a file in C:\Windows\SYSVOL_DFSR\domain\scripts\, that local path won’t work in a GPO. Instead, you need to use the network path: \\domain.local\NETLOGON. The same rule applies to any other share. You can’t reference something like D:\Data\Shares\IT\Installers — you need to use the UNC path, such as \\MyDC.domain.local\Installers, so that the client systems can access it over the network.

Item-Level Targeting

For more granular control within a GPO, Item-Level Targeting can be used on certain policy items, such as mapped drives. This allows for specific settings to apply only to certain users or computers within the scope of the GPO. You could make one Drive Map policy and map the “Public” drive to all users, map “Executive” drive only to the Executives security group, map “Office” drive to only the users in the Office security group and map “RDPDrive” to users in the RDP Users security group when they log in to servers in the RDP Servers security group, for example.


Best Practices and Considerations

  1. Avoid modifying Default Domain Policy or Default Domain Controllers Policy unless necessary. Create separate GPOs for additional settings[5].
  2. Password policy can only be affected by the Default Domain Policy. (with weird exceptions noted below)
  3. Computer reboots or user logoffs may be necessary for new group memberships and certain policies to take effect. There is a trick that can apply policies without a computer reboot (users are not as lucky). Send the command “klist purge” before “gpupdate /force“
  4. Some policies require computers to be connected to the domain network to apply, which may affect remote VPN users.
  5. New folder redirection policies require a user logoff and logon to apply.
  6. Avoid redirecting the Desktop folder. Redirecting the Desktop can lead to performance issues and a poor user experience, especially for remote users[9].
  7. Always test Group Policy settings before deploying to production. Use a test environment that closely resembles your production environment, including domain controllers, domain members, operating systems, and network configuration[11].
  8. Utilize a testing organizational unit (OU) to evaluate GPOs before deployment. This allows you to verify the effects of new policies without impacting the production environment[14][17].
  9. Take advantage of Group Policy Modeling and Group Policy Results to predict and verify policy application[18].
  10. Be aware of the Group Policy processing order (Local, Site, Domain, OU) and use this knowledge to resolve conflicts between GPOs[16].
  11. When implementing folder redirection, carefully consider permissions. Ensure users have appropriate access to their redirected folders while maintaining security[15].
  12. Use item-level targeting for more granular control over policy application, but be aware that the GPO itself will still appear as applied even if individual items don’t take effect due to targeting[10].
  13. Regularly review and clean up unused or outdated GPOs to maintain an efficient and manageable Group Policy environment[13].

By understanding these concepts and best practices, administrators can effectively use Group Policy to manage and secure their Active Directory environment while avoiding common pitfalls.

Citations:
[1] https://www.techtarget.com/searchwindowsserver/definition/Group-Policy
[2] https://activedirectorypro.com/group-policy-guide/
[3] https://www.ninjaone.com/blog/what-is-group-policy-in-active-directory/
[4] https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-overview
[5] https://blog.quest.com/what-is-group-policy-and-how-do-gpos-work/
[6] https://blog.netwrix.com/group-policy-management
[7] https://www.windows-active-directory.com/benefits-of-group-policy-in-active-directory.html
[8] https://www.varonis.com/blog/group-policy-objects
[9] https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/folder-redirection-using-group-policy
[10] https://activedirectorypro.com/group-policy-guide/
[11] https://www.oreilly.com/library/view/microsoft-windows-group/0735622175/ch04s04.html
[12] https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/deploy-folder-redirection
[13] https://www.globalknowledge.com/us-en/resources/resource-library/articles/in-the-trenches-eight-tips-n-tricks-for-microsoft-windows-group-policy/
[14] https://learn.microsoft.com/en-us/previous-versions/windows/microsoft-desktop-optimization-pack/agpm/use-a-test-environment
[15] https://www.amorales.org/2019/03/folder-redirection-permissions-and-gpo.html
[16] https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn581922(v=ws.11)
[17] https://learn.microsoft.com/en-us/microsoft-desktop-optimization-pack/agpm/test-a-gpo-in-a-separate-organizational-unit-agpm40
[18] https://community.spiceworks.com/t/what-if-with-group-policy-before-rolling-out/804250
[19] https://www.reddit.com/r/sysadmin/comments/chr1wo/gpo_testing_and_deployment_rings/


BONUS:

Create Multiple AD Password Policies

Technically, Active Directory only allows one password policy to apply via Group Policy — typically set in the Default Domain Policy at the domain level. While GPO features like inheritance blocking, OU levels, and loopback processing are useful for other settings, they do not allow multiple password policies via GPOs. (Technically)

To apply different password policies to different users or groups, use Fine-Grained Password Policies (FGPPs), which are managed through the Password Settings Container in Active Directory.

Here’s a step-by-step guide to creating FGPPs:

Prerequisites:

  1. Your AD forest functional level must be Windows Server 2008 or higher.
  2. You must be a member of the Domain Admins group or have equivalent permissions.

Create a Fine-Grained Password Policy (FGPP)

  1. Open the Active Directory Administrative Center (ADAC) or use the PowerShell cmdlet dsac.exe.
  2. Navigate to the System container > Password Settings Container.
  3. Right-click and select “New” > “Password Settings” (or use the PowerShell cmdlet New-ADFineGrainedPasswordPolicy).
  4. Enter a name for the policy (e.g., “Admins Policy”) and set the precedence (a lower number indicates higher priority).
  5. Configure the password settings you want to apply, such as:
    • Minimum password length
    • Password history (number of old passwords stored)
    • Maximum password age
    • Minimum password age
    • Lockout threshold and duration
    • Complexity requirements (e.g., uppercase, lowercase, digits, special characters)
  6. Click “OK” to create the policy.

Assign the FGPP to a Security Group

  1. Open the ADAC or use the PowerShell cmdlet dsac.exe.
  2. Navigate to the Security Groups container.
  3. Select the security group you want to assign the policy to (e.g., “Server Admins”).
  4. Right-click and select “Properties” (or use the PowerShell cmdlet Set-ADGroup).
  5. In the “Membership” tab, click “Add” and select the FGPP you created (e.g., “Admins Policy”).
  6. Click “OK” to save the changes.

Verify Policy Application

  1. Use the PowerShell cmdlet Get-ADUserResultantPasswordPolicy to verify which policy applies to a specific user.
  2. Run the command with the user’s name or distinguished name (e.g., Get-ADUserResultantPasswordPolicy -Identity s.wolf).

Additional Tips:

  • You can create multiple FGPPs and assign them to different security groups or OUs.
  • FGPPs override the default domain password policy.
  • Use the “Directly Applies To” setting to specify which users or groups the policy applies to.
  • You can also use Group Policy Objects (GPOs) to apply password policies, but FGPPs provide more granular control.

Remember to test your password policies and verify their application to ensure they meet your organization’s security requirements.

RDP RDWeb Oopsie

I encountered an odd behavior from a recent Gateway RDWeb. I have Remote App and Full Desktop published to RDWeb, but when I went to download the FullDesktop.rdp – it got the same settings as the remote app.

I’ve checked the registry entries and they are correct. Even copied the contents of RDPFileContents entry to notepad and saved as .rdp and it worked great – so its valid…

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\MyCollection\Applications\MyAppName

and

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\MyCollection\RemoteDesktops\MyCollection

The contents have been changed to modify some settings and add the domain name in username section – but again, valid and works. Also changed the Name of each and it shows up in RDWeb properly.

I don’t know HOW RDWeb is pulling the wrong entry for the Desktop, since it SHOULD be pulling it from the Registry.

The ONLY thing I can think of is that my Collection Name and the Remote App name are the same… (above MyCollection and MyAppName are the same) but why would that be a problem?

Apparently, it is. My Collection is “MyAppName” and the published Remote App is “MyAppName” – and Windows Remote Desktop can’t decide which is which in RDWeb – despite the right settings in the registry.

Trusted Domain users to RDP session

Can users from a Trusted Domain authenticate on a Remote Desktop connection in a different, trusting domain? Can it be done? Yes.

So, after some painful back and forth, it can be done, but its not totally secure, and it can be quite the hassle.

  1. Requires Two-Way domain trust, which is not as secure as a one-way, limited trust,
  2. The RDP broker must be able to talk to the Trusted DC and the Trusted DC must be able to talk to the Trusting RDP broker as well as the Trusting DC
  3. Domain Local group on the Trusting domain that has a group from the Trusted domain as a member.
  4. NPS on the Gateway must be set to allow the Trusted domain user group. (May not be required on environments without a gateway)

Assuming you can set up a Two-Way domain trust – maybe even set up as Select – so, not covering that here. On the Trusting domain (the one with the RDP server), you will need to set up a Domain Local security group:

That has the Trusted domain’s group as a member:

On the broker/gateway, in NPS, right click on the NPS (local) and if Register server in Active Directory is bold, click it to register in active directory.

In the Network Policies, RDG_CAP_AllUsers, Conditions, User Groups, you need to add the Trusted domain’s user group and the domain local group (just in case).

In the collection(s), you can add the Domain Local group, or groups, to the User Groups assigned to that collection:

Now, users in the group from the Trusted domain, who are in the Domain Local group, can authenticate to an RDP session in the Trusting domain, as long as the firewall or VPN, etc allows the RDP connection broker to reach the Trusted DC and vice versa.

To sum up:

  • Two-Way Domain Trust: Establish a two-way domain trust between the trusting and trusted domains. This facilitates communication between the RDP broker/gateway and the trusted domain’s domain controller.
  • Communication Channels: Ensure that communication channels are open bidirectionally between the RDP broker/gateway and the Trusted DC, as well as between the Trusted DC and the Trusting RDP broker and DC. Verify there are no network restrictions impeding this communication.
  • Domain Local Group Creation: Create a Domain Local group on the Trusting domain, adding a group from the Trusted domain as a member. This allows users from the Trusted domain to be granted access permissions within the Trusting domain.
  • NPS Configuration: In the Network Policy Server (NPS) on the RDP broker/gateway:
    • Register the server in Active Directory.
    • Configure the RDG_CAP_AllUsers network policy:
      • In Conditions, under User Groups, add the Trusted domain’s user group and the Domain Local group.
      • In collections, assign the Domain Local group(s) to the User Groups associated with the collection.
  • Active Directory Registration: Ensure the RDP broker/gateway is properly registered in Active Directory, which is vital for its integration with NPS.
  • Firewall/VPN Configuration: Confirm that firewall or VPN settings allow the RDP connection broker to communicate with the Trusted DC and vice versa. This ensures seamless authentication for Trusted domain users accessing RDP sessions in the Trusting domain.

By meticulously following these steps, users from the Trusted domain who are members of the Domain Local group can successfully authenticate to RDP sessions in the Trusting domain. However, it’s crucial to monitor and maintain the setup’s security to mitigate potential risks.

Helpful Group Policy Query

So, have you ever been tasked with moving file shares or printer shares to a new server? How enjoyable is it combing through Group Policy to find where the old server name is used? Yeah, its not.

Powershell to the Rescue! The below script will look for any text within all the group policies and let you know which ones the text is found in. A server name is the most obvious thing to look for, but it could be a user name or a share name, etc.

# Get the string to search for
$searchString = Read-Host -Prompt "Enter the string to search for in GPOs"

# Set the domain to search for GPOs
$DomainName = $env:USERDNSDOMAIN

# Check if Group Policy module is available, import if not
if (-not (Get-Module -Name GroupPolicy -ListAvailable)) {
    Import-Module GroupPolicy -ErrorAction Stop
}

# Find all GPOs in the current domain
Write-Host "Finding all the GPOs in $DomainName"

try {
    $allGposInDomain = Get-GPO -All -Domain $DomainName -ErrorAction Stop
} catch {
    Write-Host "Error: Failed to retrieve GPOs. $_" -ForegroundColor Red
    exit
}

$matchedGPOs = @()

# Search through each GPO's XML for the specified string
Write-Host "Starting search..."
foreach ($gpo in $allGposInDomain) {
    try {
        $report = Get-GPOReport -Guid $gpo.Id -ReportType Xml -ErrorAction Stop
    } catch {
        Write-Host "Error: Failed to retrieve report for $($gpo.DisplayName). $_" -ForegroundColor Yellow
        continue
    }
    
    if ($report -match $searchString) {
        Write-Host "Match found in: $($gpo.DisplayName)" -ForegroundColor Green
        $matchedGPOs += $gpo.DisplayName
    } else {
        Write-Host "No match in: $($gpo.DisplayName)"
    }
}

# Display results
Write-Host "`nResults:`n**************" -ForegroundColor Yellow
foreach ($match in $matchedGPOs) {
    Write-Host "Match found in: $($match)" -ForegroundColor Green
}