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
- Employees
- Computers
- Servers
- RDP Servers
- Disabled Servers
- Workstations
- Shared Workstations
- Disabled Workstations
- Servers
- 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
To target specific users or computers within the domain:
- Remove “Authenticated Users” from the scope.
- Add specific security groups for users or computers, or “Domain Computers” or “Domain Users” to the scope.
For example, adding “Executive” group and “Domain Computers” to the scope would apply the policy to any Executive user on any domain computer they log into. Adding “Office” and “RDP Servers” to the scope would apply the policy to users in the Office security group when they are on servers in the RDP Servers group.
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.
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
GPOs have two main sections:
- Computer Configuration: Applies to computer objects.
- User Configuration: Applies to user objects.
If a GPO is linked to an OU containing only computers, the User Configuration settings won’t apply, and vice versa.
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
- Avoid modifying Default Domain Policy or Default Domain Controllers Policy unless necessary. Create separate GPOs for additional settings[5].
- Password policy can only be affected by the Default Domain Policy.
- Computer reboots or user logoffs may be necessary for new group memberships and certain policies to take effect.
- Some policies require computers to be connected to the domain network to apply, which may affect remote VPN users.
- New folder redirection policies require a user logoff and logon to apply.
- Avoid redirecting the Desktop folder. Redirecting the Desktop can lead to performance issues and a poor user experience, especially for remote users[9].
- 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].
- 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].
- Take advantage of Group Policy Modeling and Group Policy Results to predict and verify policy application[18].
- Be aware of the Group Policy processing order (Local, Site, Domain, OU) and use this knowledge to resolve conflicts between GPOs[16].
- When implementing folder redirection, carefully consider permissions. Ensure users have appropriate access to their redirected folders while maintaining security[15].
- 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].
- 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
To create multiple password policies in Active Directory (AD), you can use Fine-Grained Password Policies (FGPPs). Here’s a step-by-step guide:
Prerequisites:
- Your AD forest functional level must be Windows Server 2008 or higher.
- You must be a member of the Domain Admins group or have equivalent permissions.
Create a Fine-Grained Password Policy (FGPP)
- Open the Active Directory Administrative Center (ADAC) or use the PowerShell cmdlet
dsac.exe
. - Navigate to the System container > Password Settings Container.
- Right-click and select “New” > “Password Settings” (or use the PowerShell cmdlet
New-ADFineGrainedPasswordPolicy
). - Enter a name for the policy (e.g., “Admins Policy”) and set the precedence (a lower number indicates higher priority).
- 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)
- Click “OK” to create the policy.
Assign the FGPP to a Security Group
- Open the ADAC or use the PowerShell cmdlet
dsac.exe
. - Navigate to the Security Groups container.
- Select the security group you want to assign the policy to (e.g., “Server Admins”).
- Right-click and select “Properties” (or use the PowerShell cmdlet
Set-ADGroup
). - In the “Membership” tab, click “Add” and select the FGPP you created (e.g., “Admins Policy”).
- Click “OK” to save the changes.
Verify Policy Application
- Use the PowerShell cmdlet
Get-ADUserResultantPasswordPolicy
to verify which policy applies to a specific user. - 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.