gpo user rights assignment best practices

Discover & Secure Sensitive Data with Netwrix Data Classification

19 July, 10am PDT

DATA SECURITY

• Data Access Governance
• Data Governance
• Data Loss Prevention

IDENTITY SECURITY

• Privileged Access Management
• Active Directory Security
• Identity Governance and Administration
• Password Security
• Identity Threat Detection & Response
• Compliance Solutions
• Become a Partner
• Partner Portal
• Technology Partners
• Partner Locator
• Support Portal
• Knowledge Center
• Submit Ticket
• Support Program
• Supported Versions
• Customer Portal
• Customer Training
• Renew License
• Professional Services
• Customer Webinars
• Customer Case Stories

MISCELLANEOUS

• Security Center
• Attack Catalog
• How-to Guides
• eBooks & Guides
• SysAdmin Magazine
• Cyber Chief Magazine
• Customer Case Studies
• Management Team
• Analyst Coverage

Group Policy Best Practices

Group Policy enables organizations to control a wide variety of activities across the IT environment. For example, you can use Group Policy to prevent the use of USB drives, run a certain script when the system starts up or shuts down, deploy software, or force a particular home page to open for every Active Directory user in the network. 

This guide provides both general Group Policy best practices and recommendations for specific settings. It also offers guidance for troubleshooting issues with your Group Policy objects (GPOs).

General Group Policy Best Practices

Establish separate organizational units (ous) for users and computers.

Having a good OU structure makes it easier to apply and troubleshoot Group Policy. In particular, putting Active Directory users and computers in separate OUs makes it easier to apply computer policies to all computers and user policies to all users. 

Note that the root Users and Computers folders in Active Directory are not OUs. If a new user or computer object appears in these folders, move it to the appropriate OU immediately.

Use nested OUs for granular control

To delegate permissions to specific users or groups, put those objects in an appropriate nested OU (sub OU) and link the GPO to it. For instance, within the Users OU, you might create a sub OU for each department and link GPOs to those sub OUs.

Enforce a clear naming policy

Being able to determine what a GPO does simply by looking at the name will make Group Policy administration much easier. For example, you might use the following prefixes:

• U for GPOs related to users, such as U_SoftwareRestrictionPolicy
• C for GPOs related to computer accounts, such as C_DesktopSettings

Add comments to your GPOs

Add a comment to each GPO explaining its purpose and settings. This will make your Group Policy more transparent and easier to maintain.

Understand GPO precedence

Several GPOs can apply to the same Active Directory object at the same time. They are applied in a specific order, and new settings override those set by previously applied GPOs. This order LSDOU, which stands for:

• Local: Group Policy settings applied at the local computer level have the lowest precedence.
• Site: Settings for Active Directory sites are applied next.
• Domain: Next are Group Policy settings that affect all OUs in the domain.
• OU: Last applied are GPO settings at the OU level.

Create smaller GPOs for specific use cases 

Align each GPO with a specific purpose, so it’s easier to manage them and understand inheritance. Here are some examples of tightly focused GPOs:

• Browser Settings
• Security Settings
• Software Installation Settings
• AppLocker Settings
• Network Settings
• Drive Mappings

However, keep in mind that loading many small GPOs can require more time and processing at logon than having a few GPOs that each have more settings.

Set GPOs at the OU level rather than the domain level

Any GPO set at the domain level will be applied to all Active Directory objects in the domain, which could lead to some settings being applied to inappropriate users and computers. The only GPO that should be set at the domain level is the Default Domain Policy. 

Instead, apply GPOs at the OU level. A sub OU inherits the policies applied to its parent OU; you don’t need to link the policy to each sub OU. If you have users or computers that you don’t want to inherit a setting, put them in their own OU.

Avoid blocking policy inheritance and policy enforcement

Blocking policy inheritance and policy enforcement make GPO management and troubleshooting much more difficult. Instead, strive for a well-designed OU structure that makes these settings unnecessary.

Instead of disabling a GPO, delete its link 

Disabling a GPO will keep it from being applied to any OU in the domain, which could cause problems. Therefore, if a GPO is linked to a particular OU where you don’t want it to be applied, delete the link instead of disabling the GPO. Deleting the link will not delete the GPO. 

Avoid using the ‘deny’ permission in Group Policy

Administrators can explicitly deny a user or group the ability to be excluded from a specific GPO. While this functionality can be useful in certain scenarios, it can easily lead to unintended consequences because it will not be clear that a GPO is not being applied to certain objects. In order to find out which users or groups have been blocked; administrators would need to examine each GPO separately.

Implement change management and change auditing for Group Policy

Changes to GPOs can have profound effects on security, productivity, compliance and more. Therefore, all changes should be planned and fully documented. In addition, you should track all changes to Group Policy and get alerted to critical changes. Unfortunately, both these goals are difficult with native tools: The security logs do not provide a record of exactly which settings were changed, and getting alerts requires PowerShell scripting. For a more comprehensive and convenient approach, invest in a third-party solution like  Netwrix Auditor for Active Directory .

To learn more about how to track changes to Group Policy, see the  Group Policy Auditing Quick Reference Guide .

Speed GPO processing by disabling unused computer and user configurations

If you have a GPO that has computer settings but no user settings, you should disable the User configuration for that GPO to speed GPO processing time. 

In addition, be aware of the following additional factors that can cause slow startup and logon times:

• Login scripts downloading large files
• Startup scripts downloading large files
• Mapping home drives that are far away
• Deploying huge printer drivers over Group Policy preferences
• Overuse of Group Policy filtering by Active Directory group membership
• User personal folders applied via GPO
• Use of Windows Management Instrumentation (WMI) filters (see the next section)

Avoid using a lot of WMI filters

WMI contains a huge number of classes with which you can describe almost any user and computer settings. However, using many WMI filters will slow down user logins and lead to a bad user experience. When possible, use security filters instead because they need less resources.

Use loopback processing for specific use cases

Loopback processing limits user settings to the computer that the GPO is applied to. A common use of loopback processing is when you need certain settings applied when users log into only particular terminal servers. You need to create a GPO, enable loopback processing, and apply the GPO to the OU that has the servers in it.

Use Advanced Group Policy Management (AGPM)

AGPM provides GPO editing with versioning and change tracking. It is part of the Microsoft Desktop Optimization Pack (MDOP) for Software Assurance.

Back up your GPOs

Configure daily or weekly backup of policies using Power Shell scripting or a third-party solution so that you can always restore them to a known good state.

GPO Settings Best Practices

The following best practices will help you configure your GPOs to ensure strong security and productivity. 

Do not modify the Default Domain Policy or the Default Domain Controller Policy

The Default Domain Policy affects all users and computers in the domain, so it should be used for account, account lockout, password and Kerberos policy settings only.

Use the Default Domain Controller Policy for the User Rights Assignment Policy and Audit Policy only.

However, it is even better to use separate GPOs even for the policies listed above.

Limit access to the Control Panel 

It’s important to limit access to the Control Panel on Windows machines. You can block all access to the Control Panel, or allow limited access to specific users using the following policies:

• Hide specified Control Panel items
• Prohibit access to Control Panel and PC settings
• Show only specified Control Panel items

Do not allow removable media 

Removable media can be dangerous. If someone plugs an infected drive into your system, it unleash malware into the network. In addition, these drives are a path for data exfiltration.

You can disable the use of removable drives using the “Prevent installation of removable devices” policy. You can also disable the use of DVDs, CDs and even floppy drives if you want, though they present less risk.

Disabling automatic driver updates on your system

Driver updates can cause serious problems for Windows users:  They can cause Windows errors, performance drops, or even the dreaded blue screen of death (BSOD). Regular users can’t switch updates off since it’s an automated feature. 

As an administrator, you can disable automatic driver updates using the “Turn off Windows Update device driver searching” Group Policy. You will need the hardware IDs of the devices, which you can find in Device Manager.

Restrict access to the command prompt 

The command prompt is very useful for system administrators, but enabling users to run commands could harm your network. Therefore, it’s best to disable it for regular users. You can do that using the “Prevent access to the command prompt” policy.

Turn off forced restarts 

If a user doesn’t turn off their computer when they leave work and their machine is forcibly rebooted by Windows Update, they can lose their unsaved files. You can use Group Policy to disable these forced restarts.

Prevent users from installing software 

Keeping users from installing software on their machines helps prevent a host of problems. You can prevent software installation by changing the AppLocker and Software Restriction settings and disabling extensions like “.exe” from running.

Disable NTLM authentication

The NTLM authentication protocol has a lot of vulnerabilities,  including weak cryptography, so it is very vulnerable to attacks. Using Group Policy, you can disable NTLM authentication in your network and only the modern Kerberos protocol. However, first be sure to verify that no applications require NTLM authentication.

Block PowerShell locally

PowerShell is generally not needed by business users, and keeping them from using it can help prevent execution of malicious scripts. Using Group Policy, you can block the use of PowerShell on domain joined computers. 

Admins who need to use PowerShell can be excluded from the policy. Alternatively, you can require them to run PowerShell scripts only on a designated machine for better security.

Disable guest accounts on domain computers 

Guest accounts typically have limited access and functionality compared to regular user accounts, but they still pose important security risks. Disabling them using Group Policy helps prevent malicious users from gaining access to your environment.

Limit membership in the Local Administrators group

Members of the Local Administrators group can install software, delete system files, modify security settings and much more. This elevated access increases the risk of malware infections, accidental data loss and deliberate data exfiltration, and system instability and performance issues. 

Using Group Policy, you can remove unnecessary accounts from the Local Administrators group on all computers.

Rename the local Administrator account

The Local Administrator account is a prime target for attackers because it provides privileged access on the machine. To reduce risk, it is a best practice to rename the Local Administrator account. In addition,  use the account only when absolutely necessary; for routine tasks, use other administrative accounts with limited privileges.

Restrict anonymous access to named pipes and network shares

By default, named pipes and shares can be accessed anonymously, which can enable malicious actors to access sensitive data, such as confidential files, system information and network security settings. Accordingly, it is a best practice to use Group Policy to enforce restrictions on anonymous access to named pipes and shares across the network. 

Enforce current password best practices

Standards bodies like NIST offer guidelines for password policy settings that reduce your risk from password-based attacks and credential reuse. You can use Group Policy to apply these recommendations in your environment. 

Keep in mind that while stringent requirements for factors like password length, complexity and password age theoretically increase security, it doesn’t always work that way in practice. Instead, such policies can lead users to adopt insecure workarounds like writing passwords down to avoid the hassle of account lockouts. 

To get the full benefit of strong password policies, consider adopting a tool like Netwrix Password Secure , which will automatically create, store and enter credentials for users. That way, you can improve security by requiring passwords to be long, include special characters, be changed frequently and so on.

Disable anonymous SID enumeration

When anonymous SID enumeration is enabled, adversaries can gather information about user accounts and groups that is valuable in planning and executing cyberattacks. You can disable anonymous SID enumeration by modifying this registry setting: 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Be sure to back up the registry before making any changes, and exercise caution when editing registry settings. Changes should be performed only by knowledgeable and authorized personnel.

Prevent users from switching off Windows Defender

You should ensure that the built-in antivirus and antimalware protection remains active on all Windows systems. Go to the following path in the Group Policy Editor: 

Computer Configuration > Administrative Templates > Windows Components > Windows Defender Antivirus

Configure the Group Policy setting "Turn off Windows Defender Antivirus" as Disabled .

How Netwrix PolicyPak Can Help

Group Policy is an effective tool for detailed settings management within a Windows environment. However, challenges such as the proliferation of Group Policy Object (GPO), organizational changes due to mergers, acquisitions, divestitures, fluctuating staff levels, and forming new entities have made its management increasingly complex. Netwrix PolicyPak addresses these challenges by reducing GPO sprawl and streamlining the management process by merging multiple GPOs into fewer entities. This consolidation leads to improved login times, enhanced security, increased system reliability, and reduced configuration errors. Netwrix PolicyPak also enables administrators to deploy nearly 100% of Group Policy settings to Microsoft Intune without the added complexity of OMA-URI.

Group Policy Troubleshooting Tips

The following troubleshooting tips will help you investigate issues with Group Policy.

• In Windows 10 and Windows Server 2016, use the gpresult command to display Group Policy information for a remote user and computer, including how long it takes to process the GPO.
• Check the Event Viewer for any Group Policy-related errors or warnings.
• Use the Group Policy Results tool to see which policies are being applied to a specific user or computer, and which policies are not being applied.
• Use the Group Policy Modeling tool to simulate the application of Group Policies for a specific user or computer and identify any issues.
• Check that the affected user or computer is in the correct OU in Active Directory and that the Group Policy is linked to the correct OU.
• Check for any conflicting GPOs that may be overriding the desired settings using the Resultant Set of Policy (RSoP) tool.
• Use the Group Policy Management Console to check whether the user or computer has the necessary permissions to apply the GPO settings.
• Check for any network connectivity issues that may be preventing the user or computer from receiving the Group Policy settings.
• Review whether the Group Policy settings are configured correctly.
• For issues with Group Policy Preferences settings, use the Group Policy Preferences troubleshooting extension.
• If all else fails, consider resetting the Group Policy settings for the affected user or computer by running the "gpupdate /force" command or using the "Reset Group Policy Settings" option in the Group Policy Management Console.

• Programming
• Virtualization
• Productivity

Understanding User Rights Assignment - How to lock down or unlock your user's actions

Final notes

• https://www.experts-exchange.com/articles/3360/Understanding-User-Rights-Assignment-How-to-lock-down-or-unlock-your-user's-actions.html copy
• Active Directory

Comments (1)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.

The Original Tech Community

• IT Administration Forum
• PowerShell Forum
• Community Forum
• PowerShell Group
• Earning as 4sysops member
• Member Ranks
• Member Leaderboard – This Month
• Member Leaderboard – This Year
• Member Leaderboard – All-time
• Author Leaderboard – 30 Days
• Author Leaderboard – 365 Days
• Cloud Computing
• Write for 4sysops
• Security options in Windows Server 2016: Accounts and UAC

4sysops - The online community for SysAdmins and DevOps

Interactive logon

User account control.

• Recent Posts

• UniGetUI (formerly WingetUI): GUI for winget, Chocolatey, and PowerShell Gallery - Wed, Jul 17 2024
• What is Microsoft Dev Home? - Wed, Jul 3 2024
• New in Microsoft PowerToys: Advanced Paste and additional enhancements - Thu, Jun 13 2024

Security policy settings control various aspects of system protection, as explained in my post User rights assignment in Windows Server 2016 . Settings available in Security Options allow you to configure things related to user accounts, interactive logon, network access, network security, and the UAC feature. Today, I will cover settings related to interactive user behavior and built-in accounts. You should add these to your security baseline group policies and apply them on all computers.

Each setting uses the following format:

Name of the setting —Recommended value or values

Accounts: Administrator account status —Disabled

Note that in case of issues like a broken domain trust, you will need to reboot the system to safe mode, where the account is always enabled, or have another local account with administrator privileges available.

Accounts: Block Microsoft accounts —Users can't add or log on with Microsoft accounts

Users should be able to use only accounts your organization provides. This option will prevent access to Microsoft online accounts.

Accounts: Guest account status —Disabled

Even though the Guest account has no rights by default, it is a best practice to disable it completely and rename it with the Accounts: Rename guest account option.

TIP: Renaming the Guest account to Administrator is a good trick on attackers—they think they are trying to hack the Administrator account, but in reality, they are hacking an account with no permissions. This may slow down an attack.

Accounts: Limit local account use of blank passwords to console logon only —Enabled

There may be some leftover local accounts with no passwords, which is far from secure. Enabling this setting ensures no one can use such accounts for Remote Desktop Protocol (RDP) connections or network access to a share. Physical access to the keyboard (or VMware console) is required to use such accounts.

Settings related to built in accounts

Interactive logon: Do not display last user name —Disabled

Normally, when Windows boots up, it shows the username of the last logged-on user. The username is sensitive information. An attacker could use it to discover your naming convention and then guess other usernames.

Interactive logon: Do not require CTRL+ALT+DEL —Disabled

This well-known key combination prevents exploits that present users with a fake logon screen, capturing entered credentials.

Interactive logon: Number of previous logons to cache (in case domain controller is not available) —2

Cached logons are stored on the local filesystem. If an attacker gains access to the filesystem, he can also find these cached logons. It is not very common that a domain-joined server can't reach domain controllers to authenticate a user.

Interactive logon: Require Domain Controller authentication to unlock workstation —Enabled

Enabling this setting ensures that changes to user accounts apply to users already logged on. For example, disabling a user account means no one can use it any longer to unlock a previously logged-on session. If you are working offline, this setting is not applied.

User Account Control: Admin Approval Mode for the Built-in Administrator account —Enabled

User Account Control: Run all administrators in Admin Approval Mode —Enabled

These two settings control whether UAC is enabled or not. By default, the first option is set to disabled; if you are logged on as Administrator, everything is running with elevated privileges. It is a best practice to enable UAC for the Administrator account also.

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode —Prompt for consent on the secure desktop

User Account Control: Switch to the secure desktop when prompting for elevation —Enabled

User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop —Disabled

Configuring all three settings as above ensures that the system will always switch to the secure desktop (a dimmed screen with a prompt). Malware can spoof a standard elevation prompt—once you enter your elevated credentials, the attacker has them.

Secure desktop prompt

User Account Control: Detect application installations and prompt for elevation —Enabled

Some malware may look like a trusted program. When you permit it, it will try to install the malicious code. Enabling this setting will display another prompt, allowing you to mitigate damage.

User Account Control: Behavior of the elevation prompt for standard users —Automatically deny elevation requests

Subscribe to 4sysops newsletter!

Error message for a standard user

As you can see, many security settings are available in Windows Server 2016. A clean installation leaves many of them not configured for high security. I highly recommend changing them, especially those related to built-in accounts and the UAC feature. By doing so, you are making your server more secure.

IT Administration News

• GPT-4o mini: advancing cost-efficient intelligence
• Apple, Anthropic, and other companies used YouTube videos to train AI – The Verge
• Docker Desktop 4.32: Beta Releases of Compose File Viewer, Terminal Shell Integration, and Volume Backups to Cloud Providers | Docker
• The godmother of AI has a new startup already worth $1 billion – The Verge
• Microsoft CTO Kevin Scott thinks LLM scaling laws will hold despite criticism | Ars Technica

Read All IT Administration News

Join our IT community and read articles without ads!

Do you want to write for 4sysops? We are looking for new authors.

• Windows Server security features and best practices
• User rights assignment in Windows Server 2016
• Security options in Windows Server 2016: Network security

Authenticator backup: Microsoft, Google, Amazon, Authy

Delegated Managed Service Accounts in Windows Server 2025

List groups in Linux

Install Let’s Encrypt certificates on Windows with Certbot and export as PFX

Create and remove group in Linux, add user, switch primary group

Audit and disable NTLMv1

Enable FIDO passkey authentication for IAM users in AWS

Enable Microsoft Entra ID passkey authentication

KeePassXC: A free cross-platform password manager for Windows, macOS and Linux

Configuring external authentication methods in Microsoft 365 with Microsoft Entra ID

Integrate Microsoft Graph activity logs for Microsoft 365 with Azure Monitor

Disable Basic Authentication for SMTP AUTH in Exchange Online

Rotate BitLocker recovery passwords, delete used keys from Active Directory

Delegate permission to unlock Active Directory accounts

Allow end users to execute code on the Windows logon screen with administrator privileges

New mitigations for CVE-2023-24932 (BlackLotus) in the April update, not yet enabled by default

Combining password policies for Active Directory and Entra ID (Azure AD)

Create, use, and manage Windows Passkeys

Improve Windows performance with Microsoft PC Manager

Encrypt and decrypt with Ansible Vault

Leave a reply Click here to cancel the reply

Please enclose code in pre tags: <pre></pre>

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Receive new post notifications

Subscribe to Newsletter

Follow 4sysops.

Please ask IT administration questions in the forums . Any other messages are welcome.

Log in with your credentials

or      Create an account

Forgot your details?

Create account.

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Configuring User Rights Assignment policies via GPO

I'm configuring a GPO to add a local group to a user right policy, however, when configuring through GPO, all existing members of the right are removed on GPO application. You can obviously add all the users to the GPO to make sure these are retained but when the user is only local to the remote server e.g. NT SERVICE\SQLSERVERAGENT, this can't be added to the GPO from the DC which simply doesn't recognise it.

Am I right in assuming it's a case of using GPO when the user right should only contain domain accounts/groups, built-in users/groups but if additional user types need to be added then manual addition should be used instead?

Shame if it's the latter. Could do with being able to configure this via GPP like you can with local users/groups and having the option to retain the existing members which would address this initial observation

Cheers Jamie

• group-policy

In such specific case, please open the group policy's console from the SQL server itselft, you will need to install the RSAT tool. The options are different as it will detect your local user from it, and will allows you to select it when you edit the GPO.

Be adviced the GPO will not apply correctly on server where that local user don't exist.

• I did wonder if this was the way to do it but didn't fancy installing RSAT tools on a server, especially in an environment that has a lot of security tools monitoring changes, just to be able to add the local users. This still doesn't address the unwanted removal of existing users/groups when applying the GPO but guess that's just the way user rights policy configuration works. Definitely something that could do with some improvement in my opinion. –  jshizzle Commented Sep 14, 2021 at 16:39
• 1 @jshizzle I agree the unwanted removal is a headache, but from another perspective it do make sure that no one played with the local group, thus your GPO got the last word. –  yagmoth555 ♦ Commented Sep 14, 2021 at 17:52

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged group-policy ..

• The Overflow Blog
• The framework helping devs build LLM apps
• How to bridge the gap between Web2 skills and Web3 workflows
• Featured on Meta
• Upcoming initiatives on Stack Overflow and across the Stack Exchange network...
• Announcing a change to the data-dump process

Hot Network Questions

• Why are some elves royalty?
• Physical meaning of symmetric and antisymmetric wavefunction
• A story about a personal mode of teleportation, called "jaunting," possibly in Analog or Amazing Stories
• Book series where soldiers or pilots from Earth are teleported to a world where they learn how to use crystal magic technology
• Diminished/Half diminished
• The Zentralblatt asked me to review a worthless paper, what to do?
• What make and model of aircraft is this?
• Is it normal for journal reviewers to reject submissions based on non-scientific reasoning?
• Can perfectly stable orbits exist in GR?
• smartctl lies that NVME has lifespan of ~2800TBW? What is the real lifespan of my NVME?
• Maximizing row and column products in a 4x4 grid
• When Trump ex-rivals, who previously gave Trump terrible comments, now turn to praising him, what benefits could they gain?
• When can widening conversions cause problems?
• Why is this image from pianochord.org for A11 labeled as an inversion, when its lowest pitch note is an A?
• Constructing the interval [0, 1) via inverse powers of 2
• How to stop rewriting?
• Verbs for to punish
• Story about the Chofetz Chaim being sworn in as a witness in a secular court
• How to use chemfig package?
• Flights canceled by travel agency (kiwi) without my approval
• Implementing stoicism in daily life
• How to add personal lines to a language syntax?
• Left crank arm misaligned on climb
• Definition of free group action on a scheme

Group Policy Best Practices

Group Policy is a series of settings in the Windows registry that control security, auditing and other operational behaviors. For example, Group Policy enables you to prevent users from accessing certain files or settings in the system, run specific scripts when the system starts up or shuts down, or force a particular home page to open for every user in the network. Here are Active Directory Group Policy best practices that will help you to secure your systems and optimize Group Policy performance.

Step 1: Do not modify the Default Domain Policy and Default Domain Controller Policy

Use the Default Domain Policy for account, account lockout, password and Kerberos policy settings only; put other settings in other GPOs. The Default Domain Policy applies at the domain level so it affects all users and computers in the domain.

Use the Default Domain Controller Policy for the User Rights Assignment Policy and Audit Policy only; put other settings in separate GPOs.

However, even for the policies listed above, it is better to use separate GPOs.

Step 2: Create a well-designed organizational unit (OU) structure in Active Directory

Having a good OU structure makes it easier to apply and troubleshoot Group Policy. Don’t mix different types of AD objects in the same OUs; instead, separate users and computers into their own OUs and then create sub OUs for each department or business function. Putting users and computers in separate OUs makes it easier to apply computer policies to all computers and user policies to only the users. It is easier to create a GPO and link it in many OUs than to link it to one OU and deal with computers or users that the policy should not affect. However, don’t plan your OU architecture based solely on how you will linking Group Policies to it.

Step 3: Give GPOs descriptive names

Being able to quickly identify what a GPO does just looking at the name will make Group Policy administration much easier. Giving a GPO a generic name like “pc settings” will confuse sysadmins. For example, you might use the following naming patterns:

Policies for user accounts: U_ Policies for computer accounts: C_ Policies for computer and user accounts: CU_

Here are few examples using those naming rules:

U_SoftwareRestrictionPolicy U_SoftwareInstallation C_DesktopSettings CU_AuditSettings

Create each GPO according to its purpose rather than where you’re linking it to. For example, if you want to have a GPO that has server hardening settings in it, put only server hardening settings in it and label it as such.

Step 4: Add comments to your GPOs

In addition to creating good names, you should add comments to each GPO explaining why it was created, its purpose and what settings it contains. This information can be priceless years later.

Step 5: Do not set GPOs at the domain level

Each Group Policy object that is set at the domain level will be applied to all user and computer objects. This could lead to some settings being applied to objects that you don’t want to. Therefore, the only GPO that should be set at the domain level is the Default Domain Policy. It’s better to apply other policies at a more granular level.

Step 6: Apply GPOs at the OU root level

Applying GPOs at the OU level will allow sub OUs to inherit these policies; you don’t need to link the policy to each sub OU. If you have users or computers that you don’t want to inherit a setting, then you can put them in their own OU and apply a policy directly to that OU.

Step 7: Do not use the root Users or Computers folders in Active Directory

Those folders are not OUs so they cannot have GPOs linked to them. The only way to apply policies to those folders is to link them to the domain level, but as stated above, you should avoid doing that. So as soon as a new user or computer object appears in these folders, move it to the appropriate OU immediately.

Step 8: Don’t disable GPOs

If a GPO is linked to an OU and you don’t want it to be applied, delete the link instead of disabling the GPO. Deleting the link from an OU will not delete the GPO; it just removes the link from the OU and its settings are not applied. Disabling the GPO will stop it from being applied entirely on the domain, which could cause problems because if you use this Group Policy in another OU, it will no longer work there.

Step 9: Implement change management for Group Policy

Group Policy can get out of control if you let all your administrators make changes as they feel necessary. But tracking changes to Group Policy can be difficult because security logs cannot give you full picture of exact which setting was changed and how. You can take a look at how you can track changes to Group Policy in the Group Policy Auditing Quick Reference Guide.

The most important GPO changes should be discussed with management and fully documented. In addition, you should set up email alerts for changes to critical GPOs because you need to know about these changes ASAP in order to avoid system downtime. You can do this using PowerShell scripts or, more conveniently, with IT auditing software like Netwrix Auditor for Active Directory.

Step 10: Avoid using blocking policy inheritance and policy enforcement

If you have a good OU structure, then you can most likely avoid using blocking policy inheritance and policy enforcement. These settings can make GPO troubleshooting and management more difficult. Blocking policy inheritance and policy enforcement are never necessary if the OU structure is designed properly.

Step 11: Use small GPOs to simplify administration

Having small GPOs makes troubleshooting, managing, design and implementation easier. Here are some ways to break out GPOs into smaller policies:

Browser Settings Security Settings Software Installation Settings AppLocker Settings Network Settings Drive Mappings

However, keep in mind that larger GPOs with more settings will require less processing at log on (since systems have to make fewer requests for GPO information); loading many small GPOs can take more time. However, large GPOs can have GPO setting conflicts that you have to troubleshoot, and you’ll have to pay more attention to GPO inheritance.

Step 12: Speed GPO processing by disabling unused computer and user configurations

If you have a GPO that has computer settings but no user settings, you should disable the User configuration for that GPO to improve Group Policy processing performance at systems logon. Here are some other factors that can cause slow startup and logon times:

Login scripts downloading large files Startup scripts downloading large files Mapping home drives that are far away Deploying huge printer drivers over Group Policy preferences Overuse of Group Policy filtering by AD group membership Using excessive Windows Management Instrumentation (WMI) filters (see the next section for more information) User personal folders applied via GPO

Step 13: Avoid using a lot of WMI filters

WMI contains a huge number of classes with which you can describe almost any user and computer settings. However, using many WMI filters will slow down user logins and lead to a bad user experience. Try to use security filters over WMI, when possible, because they need less resources.

Step 14: Use loopback processing for specific use cases

Loopback processing limits user settings to the computer that the GPO is applied to. A common use of loopback processing is on terminal servers: Users are logging into a server and you need specific user settings applied when they log into only those servers. You need to create a GPO, enable loopback processing and apply the GPO to the OU that has the servers in it.

Step 15: Use “gpresult” to troubleshoot GPO issues

The gpresult command displays Group Policy information for a remote user and computer. In addition, it breaks down how long it takes to process the GPO. This command is available only in Windows 10 and Windows Server 2016. The gpresult utility has many settings; you can view them by entering the command “gpresult /?”.

Step 16: Use Advanced Group Policy Management (AGPM)

AGPM provides GPO editing with versioning and change tracking. It is part of the Microsoft Desktop Optimization Pack (MDOP) for Software Assurance and can be downloaded from https://www.microsoft.com/en-us/download/details.aspx?id=54967 .

Step 17: Back up your Group Policies

Configure daily or weekly backup of policies using Power Shell scripting or a third-party solution so that in case of configuration errors, you can always restore your settings.

Step 18: GPO settings best practices

Step 19: limit access to the control panel in windows.

It’s important to limit access to the Control Panel, even if the user is not an administrator on the Windows machine. You can block all access to the Control Panel or allow limited access to specific users using the following policies:

Hide specified Control Panel items Prohibit access to Control Panel and PC settings Show only specified Control Panel items

Step 20: Do not allow removable media drives

Removable media can be dangerous. If someone plugs an infected drive into your system, it unleash malware into the whole network. In an office environment, it’s best to disable removable drives entirely using the “Prevent installation of removable devices” policy. You can also disable DVDs, CDs and even floppy drives if you want, but the primary concern is removable drives.

Step 21: Disabling automatic driver updates on your system

Driver updates can cause serious problems for Windows users: They can cause Windows errors, performance drop or even the dreaded blue screen of death (BSOD). Regular users can’t switch updates off since it’s an automated feature. Windows Group Policy settings can be changed to disable automatic driver updates, using the “Turn off Windows Update device driver searching” policy. However, you must specify the hardware IDs of the devices you want to stop updates on. You can find this information in Device Manager.

Step 22: Make sure access to command prompt is restricted

The command prompt is very useful for system administrators, but in the wrong hands, it can turn into a nightmare because gives users the opportunity to run commands that could harm your network. Therefore, it’s best to disable it for regular users. You can do that using the “Prevent access to the command prompt” policy.

Step 23: Turn off forced restarts on your servers

If your Windows Update is turned on, you probably know that Windows pushes you to reboot the system after updating. But some users don’t turn off their computers when they leave work, so if their desktops are forcibly rebooted by a Windows Update, they can lose their unsaved files. You can use Group Policy settings to permanently disable these forced restarts.

Step 24: Disable software installations by AppLocker and Software Restriction Policy

There are many ways you can block users from installing new software on their system. Doing this reduces maintenance work and helps avoid the cleanup required when something bad is installed. You can prevent software installation by changing the AppLocker and Software Restriction Group Policy settings and disabling certain extensions (such as “.exe”) from running.

Step 25: Disable NTLM in your network infrastructure

NTLM is used for computers that are members of a workgroup and local authentication. In an Active Directory environment, Kerberos authentication has to be used instead of NTLM, because it is stronger authentication protocol that uses mutual authentication rather than the NTLM challenge/response method. NTLM has a lot of known vulnerabilities and uses weaker cryptography, so it is very vulnerable to brute-force attacks. You should disable NTLM authentication in your network using Group Policy to allow only Kerberos authentication, but first ensure that both Microsoft and third-party applications in your network do not require NTLM authentication.

Step 18 is blank but otherwise, great write up! Thanks for taking the time to share!

Step 18 is just the name of the second chapter:)

Excellent write up Ryan. At my last place we used GPO extensively. We followed a lot of these rules. But this is a very comprehensive list to really get a handle on things. Learned a bunch of new things here.

One example: I had never used gpresult. Always used RSOP instead.

Thanks for posting

Very helpful article, it has to be saved as a reference, thank you, great work! Note: point 15, about gpresult, I use it with windows 7 very well, don’t think that it is execlusive to windows 10 or windows server 2016!

Excellent piece. Learned some new things to apply “correctly” to my domains.

Related Topics

12 Group Policy Best Practices: Settings and Tips for Admins

Group policy is a fundamental building block of an enterprise network, allowing administrators to configure settings, behaviors, and privileges for users and computers. To ensure an efficient deployment, there are several best practices that admins should follow.

1. Minimize changes to the default policies: The Default Domain Policy should only set password policy, domain account lockout policy, and domain Kerberos policy. The Default Domain Controllers Policy should only set user rights assignment policy and audit policy.

2. Minimize GPOs at the root domain level: Avoid linking GPOs at the root domain level as they will apply to all users and computers in the domain. Instead, create and link a new GPO above the default policy if needed.

3. Organize your OU structure: Separate users and computers into separate OUs to make it easier to apply computer policies to computers and user policies to users. Consider organizing OUs by department or specific functions.

4. Link GPOs at the OU root level: Link GPOs at the highest level of the OU structure to allow for inheritance and avoid linking the same GPO to multiple OUs.

5. Avoid blocking policy inheritance and policy enforcement: Blocking GPO inheritance at the OU level prevents higher-level policies from being applied, causing confusion and troubleshooting difficulties. Policy enforcement ensures that a later policy does not overwrite the GPO settings and configuration.

6. Delete a GPO link instead of disabling: If you no longer want a GPO to be applied to an OU, delete the link instead of disabling it. This ensures that the objects in other OUs are not affected by the disabled GPO.

7. Use descriptive GPO names: Use descriptive names to quickly identify the purpose of a GPO, such as “User – Microsoft Office Settings” or “Computer – Security Settings”.

8. Disable unused computer and user configurations: If a GPO only contains computer or user settings, disable the other configuration settings to decrease GPO processing time.

9. Simplify administration with smaller GPOs: Avoid putting all settings and configurations into a single, large GPO. Create smaller, targeted GPOs for specific settings, such as Windows Update, browser settings, network settings, etc.

10. Use WMI filters sparingly: Avoid using too many WMI filters as they can slow down computer startup and user login. Use GPO security filters instead to control which users, groups, or computers the GPO settings should apply to.

11. Backup group policies: Regularly backup GPOs as part of your disaster recovery plans. Use third-party tools or PowerShell scripts to create backups.

12. Avoid using the Users or Computers folders in Active Directory: These folders are not OUs and cannot have GPOs linked to them. Instead, create separate OUs for users and computers and link GPOs to those OU levels.

Following these best practices will help administrators efficiently manage and deploy group policies within their Active Directory environment.

Minimize changes to the default policies

To maintain a streamlined group policy implementation, it is recommended to minimize changes to the default policies. The default policies, namely the Default Domain Policy and Default Domain Controllers Policy, play a crucial role in setting password policies, domain account lockout policies, domain Kerberos policies, user rights assignment policies, and audit policies.

By keeping changes to these default policies to a minimum, administrators can ensure a stable and consistent configuration across their enterprise network. It also helps avoid potential conflicts or unintended consequences that may arise from extensive modifications to these policies.

By adhering to these best practices, administrators can maintain a secure and efficient group policy implementation while minimizing potential issues that can arise from extensive modifications to the default policies.

• Default Domain Policy: Only set password policy, domain account lockout policy, and domain Kerberos policy.
• Default Domain Controllers Policy: Only set user rights assignment policy and audit policy.

Modifying these default policies should be done with caution, as excessive changes can lead to confusion, conflicts, and troubleshooting difficulties. It is recommended to create and link new GPOs above the default policies if additional settings or configurations are required, to keep the default policies focused on their intended purposes.

By following these best practices, administrators can effectively manage and optimize their group policy implementation, ensuring a secure and efficient environment for their enterprise network.

Minimize GPOs at the root domain level

To avoid applying GPOs to all users and computers in the domain, it is best practice to minimize the use of GPOs at the root domain level. Instead, create and link GPOs at higher levels in the OU structure. This approach allows for better organization, management, and control of GPOs.

When GPOs are linked at the root domain level, they will be inherited by all OUs and objects within the domain, increasing the risk of unintended consequences and making troubleshooting more complex. By keeping GPOs at a higher level, you can ensure that they are applied only to the specific OUs or objects where they are needed.

Organizing GPOs at higher levels also improves efficiency and reduces administrative overhead. Here are some benefits:

• Streamlined configuration: Linking GPOs at higher levels allows for the consolidation of similar settings and configurations. Instead of duplicating GPOs across multiple OUs, you can centralize them, making it easier to manage and update policies.
• Consistency and security: Applying GPOs at higher levels ensures that the same policies are enforced consistently throughout the domain. This helps maintain a secure and standardized environment.
• Reduced processing time: When GPOs are linked at higher levels, they are processed only once, reducing the processing time for computers and users. This improves system performance and user experience.

Table 1 : Example of GPOs linked at the root domain level

By following this best practice, you can achieve better GPO management, improved performance, and a more controlled deployment of policies within your Active Directory environment.

Organize your OU structure

An organized OU structure is key to effectively applying group policies to users and computers. Separate OUs can make it easier to apply specific policies based on department or functions. By organizing your OU structure, you can streamline policy management and ensure that the right policies are applied to the right users and computers.

When organizing your OU structure, consider grouping users and computers based on their department or specific functions. This allows you to apply policies that are relevant to a particular group without affecting others. For example, you can create separate OUs for finance, marketing, and IT departments, each with their own set of policies.

Benefits of an organized OU structure:

Overall, an organized OU structure enhances the efficiency and effectiveness of group policy management. It allows you to easily apply policies, troubleshoot issues, and streamline your policy management process. By following this best practice, you can ensure that your group policies are applied accurately and consistently throughout your enterprise network.

Link GPOs at the OU root level

Linking GPOs at the root level of OUs enables easy inheritance and prevents the need for duplicating GPOs in multiple OUs. By linking GPOs at the highest level of the OU structure, you can ensure that all child OUs inherit the settings and configurations defined in the linked GPO.

This approach simplifies administration and reduces the risk of inconsistent policies across different OUs. It allows you to make changes and updates to a single GPO, which will then be applied to all child OUs, ensuring consistency and efficiency.

When linking GPOs at the OU root level, it’s important to consider the order of processing and inheritance. The GPOs should be linked in a logical sequence, taking into account any dependencies or specific requirements for different departments or users.

Inheritance Example

In this example, the GPO – General Settings is linked at the root level, ensuring that all child OUs inherit these general settings. Additionally, the HR and Finance OUs have their specific policies linked to address their respective departmental needs. Any changes made to the GPO – General Settings will automatically apply to all child OUs, simplifying administration and ensuring consistency.

Avoid blocking policy inheritance and policy enforcement

Blocking policy inheritance and failing to enforce policies can lead to confusion and inconsistent settings. It is best practice to avoid blocking policy inheritance and enforce policies when necessary. By following these guidelines, administrators can ensure that their group policy settings are applied consistently across their network.

The default policies should only be modified to configure essential settings such as password policy, domain account lockout policy, and domain Kerberos policy. Other configurations, such as user rights assignment policy and audit policy, should be set in separate policies.

Linking GPOs at the root domain level can lead to unwanted policy application across the entire domain. Instead, create and link new GPOs above the default policies to ensure a focused and targeted application of group policies.

Separating users and computers into separate OUs based on department or specific functions makes it easier to apply policies tailored to their respective needs. This approach streamlines administration and ensures policies are applied to the correct objects.

By implementing these best practices, administrators can optimize their group policy implementation and management, resulting in a more efficient and secure network environment. Following these guidelines will help ensure consistent policy application, minimize confusion, and reduce troubleshooting efforts.

Additional Best Practices and Recommendations

In addition to the previous best practices, there are several other recommendations that can further optimize your group policy implementation.

1. Use descriptive GPO names: When creating GPOs, use clear and descriptive names to quickly identify their purpose. This will make it easier for you and your team to manage and troubleshoot GPOs in the future. For example, you can use names like “User – Microsoft Office Settings” or “Computer – Security Settings”.

2. Disable unused computer and user configurations: If a GPO contains both computer and user settings, consider disabling the configuration that is not needed. This will reduce GPO processing time and improve overall system performance.

3. Simplify administration with smaller GPOs: Instead of putting all settings and configurations into a single, large GPO, create smaller, targeted GPOs for specific settings. This will make it easier to manage and troubleshoot individual policies, as well as reduce the risk of unintended consequences when making changes.

4. Use WMI filters sparingly: While WMI filters can be useful for targeting GPOs to specific devices or user groups, using too many can slow down computer startup and user login. Consider using GPO security filters instead, which allow you to control which users, groups, or computers the GPO settings should apply to.

5. Backup group policies: Regularly backing up your GPOs is essential for disaster recovery purposes. Consider using third-party tools or PowerShell scripts to automate the backup process and ensure you have a reliable copy of your policies in case of any unexpected issues.

6. Avoid using the Users or Computers folders in Active Directory: The Users and Computers folders in Active Directory are not OUs and cannot have GPOs linked to them. Instead, create separate OUs for users and computers and link GPOs at those OU levels. This will help maintain a clean and organized structure within your Active Directory environment.

By following these additional best practices and recommendations, you can further optimize your group policy implementation and ensure a more efficient and effective management of your enterprise network.

• Recent Posts

• Enhancing Insider Threat Detection with Natural Language Processing: Real-World Applications and Future Trends - July 15, 2024
• CCSP vs. CISSP: Which One Should You Take? - July 14, 2024
• Active Directory Users and Computers (ADUC): Installation - July 13, 2024

Similar Articles:

• Group Policy Objects (GPOs): How They Work
• Risks of Renaming Your Domain in Active Directory
• IDS vs. IPS: What Organizations Need to Know
• VMware ESXi in the Line of Ransomware Fire
• What is Network Segmentation?
• Office 365 Migration: Enterprise Guide and Best Practices
• Understanding Stack Memory: Comprehensive Overview for Novices
• CISM vs. CISSP Certification: Which One is Best for You?
• IT Certifications Guide
• Which Cybersecurity Career Is Right For Me?

What is the CIA Triad?

Securing azure blob storage: set-up guide.

Group Policy Examples: Most Useful GPOs for Security

This is a list of common Active Directory Group Policies (GPOs) that should be implemented in an Active Directory environment for security and administrative convenience. Please note that not all these settings may be right for your environment so consider each carefully. As with any GPO settings, test on a small group of users and computers before rolling out.

1. Enable Audit Logs

Enabling audit logs helps to monitor activity on your network and is a great security tool for identifying threats in your infrastructure.

At a minimum, you should enable Audit System Events. This policy is in Computer Configuration -> Windows Settings –> Security Settings –> Audit Policy.

Change “Audit System Events” to Success, Failure.

See the article Windows Server Audit Policy for auditing best practices.

2. Screen Lockout Time

Enable a lock-out time from inactivity on your domain computers to protect data and privacy. A generally accepted time is 10 – 15 minutes but can be shorter if need be. Teaching your users to lock their computers when they are walking away from their desks is great. But a backup plan is always ideal.

This setting is in Computer Configuration –> Windows Settings –> Security Settings –> Local Policies –> Security Options.

Modify the time for Interactive Logon: Machine inactivity limit.

See the article GPO lock screen for more details.

3. Password Policy

Enforcing a strong password policy is critical for the security of your domain.

These settings are in Computer Configuration –> Windows Settings –> Security Settings –> Account Policies –> Password Policy.

See the article Active Directory password policy for more details.

4. Account Lockout Policy

Enforcing an account lockout policy will help keep your domain computers secure. A malicious actor could attempt to guess passwords for a domain account.

These settings are in Computer Configuration –> Windows Settings –> Security Settings –> Account Policies –> Account Lockout Policy.

See the article Active Directory account lockout policy for more details.

5. Removable Media

Allowing your users to plug in USB drives, external hard drives, or insert CDs, DVDs, should be turned off.  You open the door up to your network being infected with viruses or malware. 

These settings are in User Configuration –> Policies –> Administrative Templates –> System –> Removable Storage Access

You can enable Deny read and execute on specific devices or Enable All Removable Storage classes:  Deny all access” to block all devices.

6. Restrict access to the command prompt and PowerShell

Limit access to the command prompt and PowerShell to prevent commands from being run by regular user accounts.  If a system is compromised, the command prompt or PowerShell could be used to elevate a user account.  Also, PowerShell can be used to run malicious scripts and is often used to spread ransomware. 

To prevent access to the command prompt, enable the setting “Prevent access to the command prompt”.

The setting is in User Configuration –> Administrative Templates –> System.

To disable PowerShell, see the article disable PowerShell GPO .

7. Limit access to Control Panel options

You should limit access to what users can change in Control Panel. Users can change a lot of system settings in the Control Panel such as network settings, adding and removing software, and adding and removing users. All of these activities could open the door to a security breach.

To lock down access to the control panel, you want to enable “Prohibit access to Control Panel and PC Settings”.

This setting is located at User Configuration –> Administrative Templates –> Control Panel

8. Limit who can install software

All software should be tested and approved before being installed on a network. Also, regular user accounts should not be allowed to install software. This is for both security and to alleviate issues the software may cause.

This setting is in Computer Configuration –> Administrative Templates –> Windows Components –> Windows Installer.

Click on “Prohibit User Installs” and enable the policy.

9. Guest Account Settings

Guest accounts grant access to a computer without using a password. This is a security concern as well as a data access concern. It’s best to disable guest access.

This setting is in Computer Configuration –> Windows Settings –> Security Settings –> Local Policies -> Security Options

Click on “Accounts: Guest Account Status” and select disabled.

10. Prevent Storing LAN Manager Hash

LAN Manager stores account passwords in hashes in the local SAM database. The hash is weak and very susceptible to hacking. This should be turned off.

The setting is in Computer Configuration –> Windows Settings –> Security Settings –> Local Policies –> Security Options.

Set “Network Security: Do not store LAN Manager hash value on next password change” policy to Enabled.

11. Limit Local Account use of a blank password to console only

Blank passwords are a high-security threat. In the case that an admin inadvertently creates a local account with no password before it is added to the domain, you can block the ability for that account to be used via RDP, Telnet, and FTP.

Set “Accounts: Limit local account use of blank password to console logon only” to Enabled.

12. Turn off forced restarts

If you are using Windows Update, disable automatic restarts when users are logged on. This will prevent a lot of angry emails and phone calls.

This setting is in Computer Configuration –> Administrative Templates –> Windows Components –> Windows Updates.

Enable the policy “No auto-restart with logged on users for scheduled automatic updates installations”.

13. Monitor Changes to GPO Settings

Tracking changes to your Group Policy Object settings is very helpful when you have multiple admins making changes.

This setting is in Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Advanced Audit Policy Configuration –> Audit Policies/DS Access.

Select Audit Directory Service Changes and click Success.

14. Block Microsoft Store

Users can get carried away with launching apps from Microsoft Store. This creates an admin nightmare.

To block Microsoft Store, Enable the setting “Turn off the store application”.

This setting is in Computer Configuration –> Administrative Templates -> Windows Components –> Store

There are some apps that still require updating via Microsoft Store, you can allow this by going to Computer Configuration –> Administrative Templates –> Windows Components –> Store.

Select the policy “Turn off automatic download and install of updates” and select disable.

15. Disable Anonymous SID/Name Translation

If this option is enabled, it is possible using the SID to get the name of the built-in Administrator account even if the admin account has been changed to a different name.

Change the policy “Network access: Allow anonymous SID/Name translation” to Disabled.

16. Limit access to the Registry

Altering the registry settings is always a major concern for admins. You can lock down the registry so that users can’t alter it.

This setting is in User Configuration –> Administrative Templates –> System.

Select the policy “Prevent access to registry editing tools” and set it to Enabled.

Then under Disable regedit from running silently, change to Yes.

17. Remove Anonymous Users from Everyone Permissions

This should be disabled by default. I would double-check. If this is enabled, anonymous users can access any resources that everyone permissions have access to.

This setting is in Computer Configuration –> Windows Settings –> Security Settings –> Local Policies –> Security Options

“Network access: Let everyone permissions apply to anonymous users” should be set to Disabled.

18. Turn on auditing for NTLM to make sure you are not using it.

NTLM is a legacy authentication protocol and has several vulnerabilities, it was replaced with Kerberos in Windows 2000. Before you disable it, make sure you don’t have any legacy clients still using these authentication methods.

Audit NTLM Usage

Select policy “Network Security: Restrict NTLM: Audit NTLM authentication in this domain” and enable all.

You can view the Event Viewer under Applications and Services Log – Microsoft – Windows – NTLM to see if NTLM is being used. Look for NTLM in the Authentication Package value. The Package name will show you what version of NTLM is being used.

After making sure your domain is not using NTLM, you can disable it.

Disable NTLM (Make sure you audit your network first)

Select policy “Network Security: Restrict NTLM: NTLM authentication in this domain” and select Deny All.

19. Disable LLMNR

Link local Multicast Name Resolution (LLMNR) is a protocol used to resolve IP Addresses to host names. Basically, it performs domain name lookups without a DNS server. It works by sending a broadcast out on the network looking for an address and any devices on the network can respond. This can easily be used by an attacker to respond to these broadcasts and connect to machines. In a business network, your devices should be using a DNS server you control or approve.

You can disable LLMNR with this policy setting.

Computer Configuration -> Administrative Templates -> Network -> DNS ClientEnable Turn Off Multicast Name Resolution policy by changing its value to Enabled

20. Control the Local Administrators Group

If you do not limit access to the local administrator’s group then how do you know which accounts are full administrator rights? Over time staff will create and add existing accounts into the local administrator’s group on workstations and laptops. This will give the account full rights to the computer allowing them to install software, and drivers, make system changes, and so on. This is bad security practice and no user should be doing their day to day work with full administrator rights.

You can use group policy to control which users are members of this group and prevent other staff from making changes.

Refer to the remove local admin rights guide for step-by-step instructions.

21. Windows Firewall

I recommend you centrally manage the Windows firewall using group policy. This is similar to the local administrator rights issue, if you are not centrally managing it the rules can get out of control. If a user gets a firewall prompt to allow or deny something that could easily click allow all the time. Any requests to unblock something should come through the IT/Security team.

See the article Windows firewall best practices for more details.

22. Enable User Account Control (UAC)

With UAC, applications run in the security context of a regular user (non-administrator account) and it prompts for permissions when the application needs administrator-level access.

This is another layer of security to help protect users, computers, and your network. This is another setting that users or other staff can disable. Use group policy to centrally force UAC to be enabled and prevent it from being disabled.

The UAC policies are located in the following:

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options.

23. Applocker or Software Restriction Policies

Applocker is a feature that allows you to control which applications and files can run. This can help prevent unapproved software and files from running. For example, if a user downloads software from the internet and it is not approved in the Applocker policy the software will be blocked.

This can also help prevent ransomware and other malicious viruses from installing and spreading on your network. Applocker is only available on Windows enterprise addition. If you are running Windows pro then look into software restriction policies.

The software restriction policies are located in the following.

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Software restiriction policies

I hope you enjoyed this article. What GPOs do you use to improve security?

Leave a Comment Cancel reply

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Add workstations to domain

• 1 contributor
• Windows Server

Describes the best practices, location, values, policy management and security considerations for the Add workstations to domain security policy setting.

This policy setting determines which users can add a device to a specific domain. For it to take effect, it must be assigned so that it applies to at least one domain controller. A user who is assigned this user right can add up to 10 workstations to the domain. Adding a machine account to the domain allows the device to participate in Active Directory-based networking.

Constant: SeMachineAccountPrivilege

Possible values

• User-defined list of accounts
• Not Defined

Best practices

• Configure this setting so that only authorized members of the IT team are allowed to add devices to the domain.

Computer Configuration\Windows Settings\Security Settings\User Rights Assignment\

Default values

By default, this setting allows access for Authenticated Users on domain controllers, and it isn't defined on stand-alone servers.

The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.

Policy management

Users can also join a computer to a domain if they've the Create Computer Objects permission for an organizational unit (OU) or for the Computers container in the directory. Users who are assigned this permission can add an unlimited number of devices to the domain regardless of whether they've the Add workstations to domain user right.

Furthermore, machine accounts that are created through the Add workstations to domain user right have Domain Administrators as the owner of the machine account. Machine accounts that are created through permissions on the computer’s container use the creator as the owner of the machine account. If a user has permissions on the container and also has the Add workstation to domain user right, the device is added based on the computer container permissions rather than the user right.

A restart of the device isn't required for this policy setting to be effective.

Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.

Group Policy

Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:

• Local policy settings
• Site policy settings
• Domain policy settings
• OU policy settings

When a local setting is greyed out, it indicates that a GPO currently controls that setting.

Security considerations

This policy has the following security considerations:

Vulnerability

The Add workstations to domain user right presents a moderate vulnerability. Users with this right could add a device to the domain that is configured in a way that violates organizational security policies. For example, if your organization doesn't want its users to have administrative privileges on their devices, users could install Windows on their computers and then add the computers to the domain. The user would know the password for the local administrator account, could sign in with that account, and then add a personal domain account to the local Administrators group.

Countermeasure

Configure this setting so that only authorized members of the IT team are allowed to add computers to the domain.

Potential impact

For organizations that have never allowed users to set up their own computers and add them to the domain, this countermeasure has no impact. For those organizations that have allowed some or all users to configure their own devices, this countermeasure forces the organization to establish a formal process for these procedures going forward. It doesn't affect existing computers unless they're removed from and then added to the domain.

Related topics

• User Rights Assignment    

Additional resources