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

To target specific users or computers within the domain:

  1. Remove “Authenticated Users” from the scope.
  2. 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:

  1. Computer Configuration: Applies to computer objects.
  2. 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

  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.
  3. Computer reboots or user logoffs may be necessary for new group memberships and certain policies to take effect.
  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

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:

  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.

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.

DC AD and Group Policy

In the last post, I covered setting up a new domain controller and some things to help keep your domain healthy, well organized and your IT provider happy.

In this followup, I will keep going. Now that we have a Domain Controller, a Domain and DNS, we should look at Group Policy.

Group Policy Walk-Thru

One of the reasons that we chose to create OUs instead of Containers in the last post/video is that group policy can be applied to OUs, but not Containers.

In going over Group Policy, I’d like to start with User folders. In a corporate environment, losing a file can be a very bad thing. For the most part, servers are backed up, but workstations are not. So, how to protect the files of users? Server Shared folders are one option, but I’ll cover a couple others in this post – Folder Redirection and Home Folders. These let your users have more control over their files, as other users can not normally access either one.

It is a good idea to make a dedicated drive for Data files, separate from the OS drive.

For Home folders, create a folder on the Data drive named something like “HomeFolders.”

Open properties of the folder, security, advanced and disable inheritance.

Remove the Users permissions – give Authenticated users “This Folder Only” permissions to:
List folder / read data
Read attributes
Read extended attributes
Create folders / append data
and
Read permissions

The user “Creator Owner” should have “Subfolders and Files onlyfull control.


On the Sharing tab, use advanced and share the folder as “Home$” to make it a hidden share. Give Everyone read and Authenticated Users full control of the share.

In Active Directory Users and Computers, on the Profile tab, in the Home Folder section, choose a drive letter and put a path with a folder name that matches the user’s logon name.

Clicking Apply creates the folder. If you have a lot of users and don’t want to edit every user to add the home folder, you can use powershell – but you will need to use powershell to give them permissions to the folder as well.
Below is a powershell script to create the folders for existing users, give the users permissions and set the home folder for all users in active directory.

Import-Module ActiveDirectory

#Script for updating folder permissions to give the user full access to their home folder
# as long as its named the same as their username - so, jdoe will have full access to the jdoe folder.
# - with This "Folder, Subfolders and Files" level.
#
# --- change the domain name
 $domain = "kearan"
 $hdpath = "E:\KearanCo\HomeFolders"

# --- Make Home Directories
 $users=get-aduser -filter *
  Foreach($user in $users){
  $usern=$user.samaccountname
  $nhd = $hdpath + "\" + $($usern)
  New-Item -ItemType Directory -Path $nhd
  }

# ---- change the Folder Path
 $folders = Get-ChildItem -Path $hdpath | Where-Object -FilterScript {
     $_.PSIsContainer -eq $true
 }

# --- Set the folder permissions
 foreach ($folder in $folders) 
 {
     $path = $folder.fullname
     $ACL = Get-Acl -Path $path
     $user = $folder.name
     $AccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule("$domain\$user","FullControl",”ContainerInherit, ObjectInherit”,"None",”Allow”)
     $AccessRule1 = New-Object System.Security.AccessControl.FileSystemAccessRule("$domain\Domain Admins","FullControl",”ContainerInherit, ObjectInherit”,"None",”Allow”)
     $Account = New-Object -TypeName System.Security.Principal.NTAccount -ArgumentList "$domain\$user"
     $acl.SetOwner($Account)
     $acl.SetAccessRule($AccessRule)
     $acl.SetAccessRule($AccessRule1)
     $acl | Set-Acl $path
 }

# --- Set users Home Directory in AD ---
# --- change "FileServer" to the actual file server name 
# --- and Home$ to the actual share name. And H to your share letter.
 $users=get-aduser -filter * 
  Foreach($user in $users){
  $usern=$user.samaccountname 
  $HomeDir="\\FileServer\Home$\$($usern)" -f $usern
  Set-ADUser $user -HomeDirectory $HomeDir -HomeDrive H:
  }

You can use each section of the above script as a stand-alone script in order to do one at a time. Use the below code to change an existing home drive to a new server.

# Change Home Directory
$users=get-aduser -filter {homedirectory -like '*Old_Server*'} 
 Foreach($user in $users){
 $usern=$user.samaccountname 
 $HomeDir="\\NewServer\Home\$($usern)" -f $usern
 Set-ADUser $user -HomeDirectory $HomeDir -HomeDrive H:
 }

For Folder Redirection, create an AD group for all those you want to have redirected folders. Unless you are comfortable having all the users in an OU having the folder redirection, of course. To have more control over what accounts get the folder redirection, use the AD group method.

Create a folder, like the Home Folder above, with the same permissions. Now, go into Group Policy Management and create a new Group Policy.

Edit the group policy and go to User Configuration –> Policies –> Windows Settings –> Folder Redirection

Choose the items to redirect (See the video) and set the scope of the policy to Domain Computers (or whichever computer group you want, such as RDS Servers) and the Group you want to apply it to, ie “Folder Redirection Group.” Apply the policy to the domain, or the target OU.

See the video for more on Group Policy and Troubleshooting.

The GPupdate code from the Video:

gpupdate

gpresult /H e:\kearanit\%username%_GPResult.htm

BONUS:
– Video only available through the blog – how to enable the AD Recycle Bin – restore accidentally deleted user accounts!

The 7 FSMO Roles

5 FSMO roles? Oh, no. There are Hidden FSMO roles that they don’t tell you about!  They don’t want you to know about these until you run into a problem! There are really 7 FSMO Roles to know about.

Have you even been unable to demote a domain controller?  It tells you that it can’t determine the fSMORoleOwner – even though a netdom query FSMO returns all 5 roles?

You may also get: “The Directory service is missing mandatory configuration information, and is unable to determine the ownership of floating single-master operation roles”

Well, there are two hidden roles: CN=Infrastructure,DC=ForestDnsZones  and CN=Infrastructure,DC=DomainDnsZones

So, the next time you are transferring FSMO roles, you need to move these two as well – before you Decom the old Role Holder!

Run adsi edit as admin.

This image has an empty alt attribute; its file name is fmso_0.png
Connect to

Right click on ADSI Edit, select Connect to the naming context 

This image has an empty alt attribute; its file name is fmso_1.png
DC=DomainDNSZones,DC=Kearan,DC=local

Click and expand the new “Default naming context” – click on the connection point, move to the right column and click Infrastructure:

This image has an empty alt attribute; its file name is fsmo_2.png
CN=Infrastructure

Right click and select properties or double click to edit.

Scroll to fSMORoleOwner

This image has an empty alt attribute; its file name is fsmo_3.png
fSMORoleOwner line

You may see something like : CN=NTDS Settings\0ADEL:aae73bb2-d552-4b61-a6e0-7ce4e09dcc47,CN=oldservername\0ADEL:234e4831-f988-4c2a-a1ca-db0f8b2643d8

This is an already decommed DC that never got the fSMO role moved.

Double click to edit.  Change the CN to match your normal FSMO role holder.  You can copy the fSMORoleOwner from the original “Default naming context” section – which is DC=yourdomain,DC=tld”

Repeat for naming context “DC=ForestDnsZones,DC=yourdomain,DC=tld”

This image has an empty alt attribute; its file name is fsmo_4.png
DC=ForestDnsZones,DC=Kearan,DC=local

The fSMORoleOwner in each of the three “Infrastructure” sections should match.