default domain controller policy user rights assignment

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
User rights assignment in Windows Server 2016

4sysops - The online community for SysAdmins and DevOps

Built-in local security principals and groups

Center for internet security, local policies/user rights assignment.

Recent Posts

Verify digital file signature with SigCheck - Mon, Mar 4 2024
Migrate Microsoft Entra Connect (Azure AD Connect) to a new server - Thu, Dec 7 2023
AccessChk: View effective permissions on files and folders - Thu, Apr 13 2023

Security policy settings are sets of rules that control various aspects of protection. They include account policies, local policies, user rights assignment, the Windows firewall, software restrictions, and so on. There are several ways to configure security policy settings. The most common are:

Group policy objects (GPO) – Used in Active Directory domains to configure and regularly reapply security settings to multiple computers.
Local security policy (secpol.msc) – Used to configure a single (local) computer. Note that this is a one-time action. If another administrator changes these settings, you will need to manually change them back to the required state.

As most organizations use an Active Directory domain, it is preferred to apply security settings via group policies. You should have at least three security baselines created and linked in your domain, based on the following machine types:

Domain Controllers (DC)
Member Servers (MS)
User Workstations

Configuring user rights assignment via Goup Policy

If you have multiple versions of operating systems (OS) running on these machines, you should create separate baselines for each OS version, as some settings might not be available. This also enables stricter configuration for older systems, as they are usually less secure.

It is a best practice to configure security policies using only built-in local security principals and groups, and add needed members to these entities. This gives you much better visibility and flexibility, as GPO provides more options to manage local group members, than to manage security policy members. For example, it's not possible to add a group whose name is generated using system variables (e.g., LAB\LocalAdmins_%COMPUTERNAME%) to a security policy; however, the group can be added to the Administrators group itself.

Security policies do not support generated group names

Administrators – Members of this group have full, unrestricted access to the computer. Even if you remove some privileges from the Administrators group, a skilled administrator can still bypass those settings and gain control of the system. Only add highly trusted people to this group.
Authenticated Users – A special security principal that applies to any session that was authenticated using some account, such as a local or domain account.
Local account and member of Administrators group – A pseudogroup available since Windows Server 2012 R2. It applies to any local account in the Administrators group and is used to mitigate pass-the-hash attacks (lateral movement).
Remote Desktop Users – Members of this group can access the computer via Remote Desktop services (RDP).
Guests – By default, this group has no permissions. I don't think there is any need to use the Guest account and group today.

The Center for Internet Security (CIS) is a well-known non-profit organization that focuses on cybersecurity. To improve your knowledge of cybersecurity, you can access their free materials:

CIS Controls – A set of 20 basic and advanced cybersecurity actions (controls). Using these, you can stop the most common attacks.
CIS Benchmarks – Guidelines with specific configuration steps and detailed explanations. CIS Benchmarks are available for various products such as Windows Server, SQL Server, Apple iOS, and many more.

Both can be downloaded in exchange for your email address. There's no need to worry—there will be no further email, unless you choose to receive them.

Many companies and institutions create their security baselines based on CIS. I recommend you read CIS Controls. It really helped me to understand the importance of various security actions and settings.

CIS Benchmarks example

User rights assignments are settings applied to the local device. They allow users to perform various system tasks, such as local logon, remote logon, accessing the server from network, shutting down the server, and so on. In this section, I will explain the most important settings and how they should be configured.

For each setting, the following format is used:

Name of the setting: Recommended value, or values

Access Credential Manager as a trusted caller: No one (empty value)

Access to the Credential Manager is granted during Winlogon only to the user who is logging on. Saved user credentials might be compromised if someone else has this privilege.

Access this computer from the network: Administrators, Authenticated Users

Required for users to connect to the computer and its resources, such as an SMB share, shared printers, COM+, etc. If you remove this user right on the DC, no one will be able to log on to the domain.

Note : On DCs, you should also add the “ENTERPRISE DOMAIN CONTROLLERS“ group.

Allow log on locally: Administrators

The default configuration includes the Users group, which allows a standard user to log on to the server console. Limit this privilege only to administrators.

Allow log on through Remote Desktop Services: Administrators, Remote Desktop Users

It's common practice that some applications are used via RDP sessions by standard users. This privilege is also frequently required for remote assistance offered by an organization's helpdesk. If a server is running Remote Desktop Services with the Connection Broker role, the Authenticated Users group must also be added to this privilege.

Note: On the DC, it is recommended to allow only administrators to connect via RDP.

Back up files and directories: Administrators

This is a sensitive privilege that allows a user to bypass NTFS permissions (only via an NTFS API interface, such as NTBACKUP). A malicious user could backup and restore data on a different computer, thereby gaining access to it.

Deny access to this computer from the network/Deny log on through Terminal Services: Local account and member of Administrators group, Guests

The default value is only Guests. You should add the second group to prevent pass-the-hash attacks, so if a local elevated user is compromised, it cannot be used to elevate privileges on any other network resource, or access it via RDP.

Force shutdown from a remote system/Shut down the system: Administrators

Only administrators should be able to shut down any server, to prevent denial-of-service (DoS) attacks.

Manage auditing and security log: Administrators

This is a sensitive privilege, as anyone with these rights can erase important evidence of unauthorized activity.

Note: If you are running MS Exchange, the “Exchange Servers” group must be added to DCs.

Restore files and directories: Administrators

Attackers with this privilege can overwrite data, or even executable files used by legitimate administrators, with versions that include malicious code.

Take ownership of files or other objects: Administrators

User having this privilege can take control (ownership) of any object, such as a file or folder, and expose sensitive data.

Deny log on as a batch job/Deny log on as a service/Deny log on locally: Guests

To increase security, you should include the Guests group in these three settings.

Debug programs/Profile single process/Profile system performance: Administrators

This setting allows a user to attach a debugger to a system or process, thereby accessing critical, sensitive data. It can be used by attackers to collect information about running critical processes, or which users are logged on.

Change the system time: Administrators, Local Service

Changes in system time might lead to DoS issues, such as unavailability to authenticate to the domain. The Local Service role is required for the Windows Time service, VMware Tools service, and others to synchronize system time with the DC or ESXi host.

Create a token object: No one (empty value)

Users with the ability to create or modify access tokens can elevate any currently logged on account, including their own.

Impersonate a client after authentication: Administrators, Local Service, Network Service, Service

An attacker with this privilege can create a service, trick a client into connecting to that service, and then impersonate that account.

Note: For servers running Internet Information Services (IIS), the "IIS_IUSRS" account must also be added.

Load and unload device drivers: Administrators

Malicious code can be installed that pretends to be a device driver. Administrators should only install drivers with a valid signature.

I hope this article helped you to understand why it is important to define a security baseline for your systems. Many of the settings are already configured properly following server deployment; however, if they are not controlled by a GPO, they can be manipulated by malicious users. Be careful to whom you grant administrator permissions.

Read the latest IT news and community updates

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
Security options in Windows Server 2016: Accounts and UAC
Security options in Windows Server 2016: Network security

Privacy settings in Microsoft Edge: disable tab grouping, follow creators, similar sites, and shopping recommendations

Convert certificate format with OpenSSL

Verify digital file signature with SigCheck

Sudo for Windows vs. Runas and Sudo for Linux

Install WireGuard VPN on OPNsense Firewall

Windows auto-login without password

The Dev Home app helps to set up a development machine

Install Dev Drive in Windows 11

Displayed network information after starting Security Onion's web interface

Analyzing Windows Event Logs with Security Onion

Connecting to Azure from within the VM using a system-assigned managed identity

An example of using PowerShell to manage system and user-assigned managed identities in Azure

Connect an Azure Function or Web App to a Key Vault to retrieve secrets with PowerShell

Group Policy settings for blocking SMB authentication using NTLM

Windows Server 2025: New security features for file services (SMB, NTLM)

The Security Baseline provides group policies for deactivating SMBv1

Disable SMBv1 and enable SMBv1 auditing

Windows Copilot pops up in its own widget.

Disable Copilot and block ChatGPT in Windows and Edge with Group Policy and Defender

The variables in firehol-defaults.conf control the behavior of Firehol

Configuring iptables with Firehol

Browser certificate inspection tool after importing the CA

Install and use the step-ca certificate authority client

Step-ca: Running your own Certificate Authority with ACME support

The newer versions of Windows contain a client for SSH and SCP

Copying files between Windows and Linux with SCP and PowerShell

Windows Server 2025 Hyper-V: GPU partitioning, deduplication for VHDs, AD-less live migration

EventSentry 5.1: New network security monitoring and compliance features

SystoLOCK in review: Logging in to Active Directory with multi-factor authentication without passwords

Created a domain account to use as a service account and then tried to run powershell cmdlets against the active RDS management server.

Gave that account local admin access on the broker servers and then was able to get further.

Got the error “Access is denied” when trying to run the invoke-RDUserLogoff(with correct hostserver and unifiedsessionID values) to log off a session using that account.

Need to know what permissions should be granted to the account to provide ability to run this command and where like on the broker or the session host.

I can’t run the RD cmdlets on the RD broker to remove a user session without local administrator privileges on the broker and session host.

I need to know what user permissions are necessary to run these cmdlets as giving local admin is not desired.

Sir we are having user1 in server1. We want to collect logs of server1 from server2 using credentials of user1. Surprisingly even after entering the credentials of user1 in event viewer it is taking loggedin credentials of the user logged into server2.

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.

Best practice for Default Domain Policy and Default Domain Controllers Policy

I’m sometimes asked what the best practice is surrounding the Default Domain Policy and Default Domain Controllers Policy. Microsoft has some good guidance on this topic, but it’s not always clearly and consistently stated. Here’s a quick Q&A that might help.

Q. Is it ok to make changes to the DDP and DDCP GPOs, or should I leave them alone and create new policies?

A. The best practice recommendation from Microsoft is as follows:

· To accommodate APIs from previous versions of the operating system that make changes directly to default GPOs, changes to the following security policy settings must be made directly in the Default Domain Policy GPO or in the Default Domain Controllers Policy GPO:
o Password Policy
o Domain Account Lockout Policy
o Domain Kerberos Policy
o User Rights Assignment Policy
o Audit Policy

Source: Best Practice Guide for Securing Active Directory Installations ( https://technet.microsoft.com/en-us/library/cc773164(v=ws.10).aspx)

So, that’s it! If you want to apply other settings at the domain root level or to the Domain Controllers OU then you should create new GPOs and link them to the appropriate scope of management. The ordering of the GPOs shouldn’t really matter as you should have no overlapping settings. As a general rule of thumb, however, I would recommend assigning any new GPOs a higher precedence in case someone starts using the default GPOs for settings that are not on the “approved” list above. That way the new GPOs will win in any conflict.

Another reason to limit the settings in the default GPOs is to allow them to be re-created with minimal re-work in scenarios where they have gone missing or are corrupt and you don’t have a good backup. The method by which you can re-create the GPOs is using a tool called DCGPOFIX.EXE ( https://technet.microsoft.com/en-us/library/hh875588.aspx ). Bear in mind that this tool is a last resort following a major issue or disaster and you should really ensure you have good GPO backups, as per this article:

If you are in a disaster recovery scenario and you do not have any backed up versions of the Default Domain Policy or the Default Domain Controller Policy, you may consider using the Dcgpofix tool. If you use the Dcgpofix tool, Microsoft recommends that as soon as you run it, you review the security settings in these GPOs and manually adjust the security settings to suit your requirements. A fix is not scheduled to be released because Microsoft recommends you use GPMC to back up and restore all GPOs in your environment. The Dcgpofix tool is a disaster-recovery tool that will restore your environment to a functional state only. It is best not to use it as a replacement for a backup strategy using GPMC. It is best to use the Dcgpofix tool only when a GPO back up for the Default Domain Policy and Default Domain Controller Policy does not exist.

Source: https://support.microsoft.com/en-us/kb/833783

Q. We have disabled our DDP and DDCP GPOs and replaced them with new GPOs. Is that OK?

A. No, that’s not ok. The GPOs have a fixed GUID and can be targeted directly using these by the “legacy APIs” mentioned above.

31b2f340-016d-11d2-945f-00c04fb984f9: Default Domain Policy

6ac1786c-016f-11d2-945f-00c04fb984f9: Default Domain Controllers Policy

One well known application that directly modifies the Default Domain Controllers Policy is Microsoft Exchange. The installer adds the Exchange Servers group to the “Manage Auditing and Security Log” User Right (also referred to as SACL right). So, if you disable or unlink the GPO this right (and potentially others like it) it will go missing and will cause problems for Exchange.

Q. Is it OK to rename the DDP and DDCP GPOs?

A. If you feel you must do this I don’t believe it will have any impact, other than it might confuse people when they look for them. I’ve seen some customers rename the GPOs to align them with their in-house naming convention. As mentioned above, these GPOs are targeted using their well-known GUIDs, which is why the rename shouldn’t cause an issue.

You can find the renamed GPOs quite easily using the Group Policy cmdlets, e.g.

# Find the Default Domain Policy

Get-GPO -Guid 31b2f340-016d-11d2-945f-00c04fb984f9

# Find the Default Domain Controllers Policy

Get-GPO -Guid 6ac1786c-016f-11d2-945f-00c04fb984f9

Use the default GPOs for the approved specific purposes only. If you have other settings you need for the same scope of management, create new GPOs and link them with higher precedence than the default GPOs. Under no circumstances should you disable or unlink the GPOs. If you rename the default GPOs there should be no impact, but your mileage may vary.

2 thoughts on “ Best practice for Default Domain Policy and Default Domain Controllers Policy ”

Superb article

Thanks for this post, interesting. I’d never seen this best practice before.

Also the link to the Guide for Securing AD installations does not work, but I found the article via a search. https://technet.microsoft.com/en-us/library/cc773164%28v=ws.10%29.aspx

https://technet.microsoft.com/en-us/library/dd378987%28v=ws.10%29.aspx this link (Updating the default domain policy GPO and the default domain controlles policy GPO) muddies the waters a bit as it recommends using the default domain policy for Audit Policy, User Rights, Security Options and Event Log Policies. Though it does also say that User Rights and Audit must be made to the default GPO..

Privacy Overview

Securing Windows Workstations: Developing a Secure Baseline

Sneaky Persistence Active Directory Trick #18: Dropping SPNs on Admin Accounts for Later Kerberoasting

Nov 03 2016

Securing Domain Controllers to Improve Active Directory Security

By Sean Metcalf in ActiveDirectorySecurity , Microsoft Security , Technical Reference

Active Directory security effectively begins with ensuring Domain Controllers (DCs) are configured securely. At BlackHat USA this past Summer, I spoke about AD for the security professional and provided tips on how to best secure Active Directory. This post focuses on Domain Controller security with some cross-over into Active Directory security. The blog is called ADSecurity after all… 😉

This post covers some of the best methods to secure Active Directory by securing Domain Controllers in the following sections:

Default Domain & Domain Controller Policies

Creating Domain & Domain Controller Security Baseline GPOs

Patching domain controllers, protecting domain controllers, domain controller recommended group policy settings, configuring domain controller auditing (event logs).

Domain Controller Events to Monitor (Event Logs)

Key Domain Controller Security Items

As with any major change to infrastructure, please test before deploying changes.

Default Domain & Domain Controller Group Policies (GPOs)

When an Active Directory domain is first created, there are two GPOs created by default:

Default Domain Policy – GUID: {31B2F340-016D-11D2-945F-00C04FB984F9}
Default Domain Controllers Policy – GUID: {6AC1786C-016F-11D2-945F-00C04FB984F9}

Note that these GPO GUIDs are the same for every Active Directory domain instance. This is to ensure that Windows can quickly find these GPOs and if they’re deleted, they need to be restored/ recreated . The Active Directory Best Practices Analyzer looks for the default GPOs to ensure they’re applied correctly . GPO GUIDs are different than AD object GUIDs since some GPO GUIDs need to be the same across AD instances.

The Default Domain Policy should only contain the following settings:

Password Policy
Account Lockout Policy
Kerberos Policy

The Default Domain Policy default settings for Windows Server 2012 R2 are shown in the above graphic.

The Default Domain Controllers Policy should only contain the following settings:

User Rights Assignment
Security Options (some)

default-domain-controllers-policy-gpo-01

The Default Domain Controllers Policy default settings for Windows Server 2012 R2 are shown in the above graphics.

It is very tempting to put customized settings into the default GPOs. Please resist this urge since it’s better to layer additional security in new GPOs (and easier for change management). Note that the domain password policy is effectively the GPO with the highest link order linked to the domain, so it’s possible to create a new GPO with custom password policy settings, link to the domain, and move the link order to 1 (as shown in the following graphics).

With that said, many organizations simply customize the password policy in the Default Domain Policy GPO which is fine (and was required back in the Windows 2000 and 2003 Server days). Just don’t add new settings to this GPO; keep it clean.

The default password policy settings in the Default Domain Policy GPO leave a lot to be desired. I recommend tightening these up to make them more secure. If there are accounts that require less restrictive requirements, use Fine-Grained Password Policy to provide more lax password settings for exceptions.

Enforce Password History: 24 (the default is fine)
Maximum Password Age: 60 – 180 depending on organizational requirements and minimum password length.
Set this to be 1 or higher so users can’t simply keep cycling their new password until they roll through the password history to get back to their favorite password.
Fun fact: the only acceptable values set via the Group Policy Management Console (GPMC) are the numbers 0 through 14. Manually setting the associated Group Policy settings files in SYSVOL is an unsupported way to set a higher value. The better idea is to set it to 14 here, then use a Fine Grained Password Policy to apply to a group and ensure the users you want this setting to apply to are in this group.
Password must meet complexity requirements: Enabled
If this is set to enabled, any user that changes their password while this setting is enabled has their password stored in the AD database (NTDS.dit file) in a way that can be reversed (as opposed to only hashed) which means the user’s password can be extracted.
Set to some value to mitigate password guessing attempts
Set to configure how many invalid logon attempts are required before locking the account.
Set to configure how long until the account is automatically unlock without requiring help desk assistance.

The first step is to create two new GPOs (these are examples, call them whatever you like):

Baseline Domain Security Policy
Baseline Domain Controller Security Policy

The Baseline Domain Security Policy should contain settings that apply to the entire domain. The best way to create a secure Domain Policy and a secure Domain Controller Policy is to download the Microsoft Security Compliance Manager (currently at version 4.0) and select “Security Compliance” option under the operating system version for which you want to create the security baseline GPOs. Review the options, change as needed, and export as a GPO Backup (folder). Create a new empty GPO in the domain and “Import Settings” from the SCM GPO backup so the new GPO has the same settings as the SCM export. Then apply this GPO to your Domain Controllers . This will improve your DC security baseline if you have minimal security settings already configured, especially if you have no existing workstation GPO.

Most of the settings included are identified and described in the “Protecting Domain Controllers” & “Recommended Group Policy Settings” sections further down in this post.

Microsoft SCM Domain Security Compliance Policy (review settings and test before deploying)

microsoft-scm-win2012r2-domainsecuritycompliance-policy

Microsoft SCM Domain Controller Security Compliance Policy

microsoft-scm-win2012r2-domaincontroller-securitycompliance-policy

If one of the templates includes FIPS compliant encryption, validate whether or not you need it set since Microsoft doesn’t recommend this as of 2014 . If you are unsure if you need it, don’t enable it. FIPS compatible encryption can actually cause problems. Some government systems require it, but please test extensively with applications first.

As part of developing your Security Baseline, there are several large organizations that have spent time and money determining what’s “secure”:

DoD STIG: http://iase.disa.mil/stigs/os/windows
Australian Information Security Manual: http://www.asd.gov.au/infosec/ism/index.htm
CIS Benchmarks: https://benchmarks.cisecurity.org/downloads/browse/?category=benchmarks.os.window

If you already have a GPO configuring workstation security, you can compare what you have to the SCM generated “Security Compliance” GPO using Microsoft’s Policy Analyzer .

There are two different schools of thought for Group Policies, one is to use as few GPOs as possible filing up each one with as many like settings as possible and the other is to use separate GPOs for each purpose. I tend to fall in the middle. Use separate GPOs for major configuration settings: Windows Workstation Configuration, Windows Server Configuration, User Configuration, etc. In addition to these, configure additional GPOs with a few new settings for testing.

Important servers need to be patched as soon as possible when critical security patches are released. The concern centers around “what if I apply a patch and it breaks something?” which is a valid one. Mitigating concerns around breaking operations and ensuring security patches are applied promptly is a delicate balance, certainly more art than science.

Apply patches to a subset of Domain Controllers first to let them “bake” for a period of time, then apply to another set, and then install the patch on all of them. One popular approach is to apply the patch(es) to even numbered DCs at first, and then deploy to odd numbered DCs.
Apply critical security patches first. Any security patch labelled “critical” and applies to DCs needs to be installed as soon as possible. This includes any kind of Remote Code Execution (RCE), AD privilege escalation, and similar.
Ensure that any service installed on a DC is properly patched as well. Domain Controllers frequently host DNS, so a vulnerable DNS service running on a DC could be exploited to compromise the Active Directory domain.
Ensure that servers should be fully patched before promoting to be a DC (issues like MS14-068 make this critical).

Domain Controller security, and in many ways Active Directory security, is based on the Windows version installed on the Domain Controllers. This is why it’s important to run the current Windows version on Domain Controllers – newer versions of Windows server have better security baked in and improved Active Directory security features.

Some of the Active Directory Domain Functional Level security features are listed here by Windows version:

Windows Server 2008 R2 Domain Functional Level:

Enables possibility of removing RC4 HMAC Kerberos encryption from supported types . Note that Windows 7 & Windows Server 2008 R2 no longer support Kerberos DES encryption .
AD controls the service account password.
Users receive additional group membership when authentication with smartcard

Windows Server 2012 Domain Functional Level:

Combines user and device authentication
Protects Kerberos AS & TGT requests.

Windows Server 2012 R2 Domain Functional Level:

Protect privileged accounts limiting where they can logon to.
PDC set to Windows 2012 R2 to create the group
Authentication by using NTLM, Digest Authentication, or CredSSP.
Cached credentials
DES or RC4 encryption types in Kerberos pre-authentication.
Account delegation.
NTLM authentication.
Be delegated with unconstrained or constrained delegation.
Renew the Kerberos TGTs beyond the initial four-hour lifetime.

Windows Server 2016 New Security Features :

Privileged Access Management – support for a separate bastion (admin) forest
Microsoft Passport

Only approved software should be installed on Domain Controllers from trusted sources. This includes installing the Windows OS from a trusted source.

Domain Controllers should have the Windows firewall enabled and configured to prevent internet access. Most of the time, Domain Controllers do not have a good reason for direct internet access.

Ideally, there should be no software or agents installed on Domain Controllers since each additional program installed potentially provides another attack pathway. Every agent or service installed provides that application owner the potential ability to run code on a Domain Controller. If the patch infrastructure manages all workstations, servers, and Domain Controllers, it only takes the compromise of a single patch infrastructure admin to compromise the Active Directory environment. This is why Domain Controllers and administrative workstations/servers require their own management infrastructure separate from the rest of the enterprise since shared system management can provide a path to domain compromise. Domain Controllers and admin workstations/servers should have their own patching infrastructure like Windows Server Update Services (WSUS) .

The best way to protect Active Directory is to limit domain level administrative privileges. This includes limiting access to Domain Controllers, specifically logon and administrative rights. The following User Rights Assignments should be configured to enforce least privilege for Domain Controllers via Group Policy:

Logon as a batch job: Not Defined
Deny log on as a batch job: Guests
Allow log on locally: Administrators
Allow log on through Remote Desktop Services: Administrators
Access this computer from the network: Administrators, Authenticated Users, Enterprise Domain Controllers
Backup file and directories: Administrators (Backup Operators if a backup agent is required)
Restore file and directories: Administrators (Backup Operators if a backup agent is required)
Add workstations to domain: Administrators
Bypass traverse checking: Not Defined
Deny access to this computer from the network: Guests, NT AUTHORITY\Local Account
Devices: Prevent users from installing printer drivers: Enabled
Log on as a service: [only specific accounts that require this right should be listed here]
Domain controller: Allow server operators to schedule tasks: Disabled
Deny log on through Remote Desktop Services: Guests, NT AUTHORITY\Local Account
Shut down the system: Administrators

This section outlines recommended security settings for Domain Controllers, many of which are described and set in the Microsoft security baseline in SCM. Please fully test these settings before applying.

Enable NTLM Auditing

Restrict NTLM: Audit Incoming NTLM Traffic: Enable auditing for all accounts

This policy setting allows you to audit incoming NTLM traffic. This policy is supported on at least Windows 7 or Windows Server 2008 R2. Note: Audit events are recorded on this computer in the “Operational” Log located under the Applications and Services Log/Microsoft/Windows/NTLM.

Restrict NTLM: Audit NTLM authentication in this domain: Enable all

This policy setting allows you to audit NTLM authentication in a domain from this domain controller. This policy is supported on at least Windows Server 2008 R2. Note: Audit events are recorded on this computer in the “Operational” Log located under the Applications and Services Log/Microsoft/Windows/NTLM.

LAN Manager authentication level: Send NTLMv2 response only. Refuse LM & NTLM By default, this configuration is set to “Send NTLMv2 response only” . In the Microsoft Security Compliance Manager, Microsoft recommends this configuration be set to “Send NTLMv2 response only. Refuse LM & NTLM.” This recommendation stands; however, many environments are still using NTLMv1 authentication, so it may be necessary to enable NTLM authentication auditing to identify how NTLM authenticaiton is used in the enterprise.

LAN Manager (LM) is a family of early Microsoft client/server software that allows users to link personal computers together on a single network. Network capabilities include transparent file and print sharing, user security features, and network administration tools. In Active Directory domains, the Kerberos protocol is the default authentication protocol. However, if the Kerberos protocol is not negotiated for some reason, Active Directory will use LM, NTLM, or NTLMv2. LAN Manager authentication includes the LM, NTLM, and NTLM version 2 (NTLMv2) variants, and is the protocol that is used to authenticate all Windows clients when they perform the following operations: Join a domain Authenticate between Active Directory forests Authenticate to down-level domains Authenticate to computers that do not run Windows 2000, Windows Server 2003, or Windows XP) Authenticate to computers that are not in the domain The possible values for the Network security: LAN Manager authentication level setting are: Send LM & NTLM responses Send LM & NTLM — use NTLMv2 session security if negotiated Send NTLM responses only Send NTLMv2 responses only Send NTLMv2 responses only\refuse LM Send NTLMv2 responses only\refuse LM & NTLM Not Defined The Network security: LAN Manager authentication level setting determines which challenge/response authentication protocol is used for network logons. This choice affects the authentication protocol level that clients use, the session security level that the computers negotiate, and the authentication level that servers accept as follows: Send LM & NTLM responses. Clients use LM and NTLM authentication and never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication. Send LM & NTLM – use NTLMv2 session security if negotiated. Clients use LM and NTLM authentication and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. Send NTLM response only. Clients use NTLM authentication only and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. Send NTLMv2 response only. Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. Send NTLMv2 response only\refuse LM. Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers refuse LM (accept only NTLM and NTLMv2 authentication). Send NTLMv2 response only\refuse LM & NTLM. Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers refuse LM and NTLM (accept only NTLMv2 authentication). These settings correspond to the levels discussed in other Microsoft documents as follows: Level 0 – Send LM and NTLM response; never use NTLMv2 session security. Clients use LM and NTLM authentication, and never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication. Level 1 – Use NTLMv2 session security if negotiated. Clients use LM and NTLM authentication, and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. Level 2 – Send NTLM response only. Clients use only NTLM authentication, and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. Level 3 – Send NTLMv2 response only. Clients use NTLMv2 authentication, and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. Level 4 – Domain controllers refuse LM responses. Clients use NTLM authentication, and use NTLMv2 session security if the server supports it. Domain controllers refuse LM authentication, that is, they accept NTLM and NTLMv2. Level 5 – Domain controllers refuse LM and NTLM responses (accept only NTLMv2). Clients use NTLMv2 authentication, use and NTLMv2 session security if the server supports it. Domain controllers refuse NTLM and LM authentication (they accept only NTLMv2).

Lsass.exe audit mode: Enabled Enable “Lsass.exe audit mode” to identify what programs may be blocked when enabling LSA Protection . Review the following events to identify potential issues before enabling LSA Protection:

Event 3065: This event records that a code integrity check determined that a process (usually lsass.exe) attempted to load a particular driver that did not meet the security requirements for Shared Sections. However, due to the system policy that is set, the image was allowed to load.
Event 3066: This event records that a code integrity check determined that a process (usually lsass.exe) attempted to load a particular driver that did not meet the Microsoft signing level requirements. However, due to the system policy that is set, the image was allowed to load.

You can configure this setting to enable the auditing of Lsass.exe so that you can evaluate feasibility of enabling LSA protection. You can use the audit mode to identify LSA plug-ins and drivers that will fail to load in LSA Protection mode. While in the audit mode, the system will generate event logs, identifying all of the plug-ins and drivers that will fail to load under LSA if LSA Protection is enabled. The messages are logged without blocking the plug-ins or drivers. If you enable this setting, Lsass.exe audit mode is enabled and event are generated in the event log. If you disable or do not configure this setting, Lsass.exe audit mode is disabled and event are not generated in the event log.

Enable LSA Protection: Enabled Prior to enabling this setting on Domain Controllers, enable “Lsass.exe audit mode” to identify what programs may be blocked.

Use this setting to configure additional protection for the Local Security Authority (LSA) process to prevent code injection that could compromise credentials. On x86-based or x64-based devices that use Secure Boot and UEFI, a UEFI variable is set in the UEFI firmware when LSA protection is enabled by using the registry key. When the setting is stored in the firmware, the UEFI variable cannot be deleted or changed in the registry key. The UEFI variable must be reset. x86-based or x64-based devices that do not support UEFI or Secure Boot are disabled, cannot store the configuration for LSA protection in the firmware, and rely solely on the presence of the registry key. In this scenario, it is possible to disable LSA protection by using remote access to the device. If you enable this setting, LSA protection is enabled. If you disable or do not configure this setting, LSA protection is not enabled.

Domain member: Require strong (Windows 2000 or later) session key: Enabled The default is “Disabled”.

Session keys that are used to establish secure channel communications between domain controllers and member computers are much stronger in Windows 2000 than they were in previous Microsoft operating systems. Whenever possible, you should take advantage of these stronger session keys to help protect secure channel communications from attacks that attempt to hijack network sessions and eavesdropping. (Eavesdropping is a form of hacking in which network data is read or altered in transit. The data can be modified to hide or change the sender, or be redirected.) When this policy setting is enabled, a secure channel can only be established with domain controllers that are capable of encrypting secure channel data with a strong (128-bit) session key. To enable this policy setting, all domain controllers in the domain must be able to encrypt secure channel data with a strong key, which means all domain controllers must be running Microsoft Windows 2000 or later. If communication to non-Windows 2000–based domains is required, Microsoft recommends that you disable this policy setting.

Network security: Minimum session security for NTLM SSP based (include secure RPC) servers: Require NTLMv2 session security, Require 128-bit encryption

The default setting is “No Minimum”. In the Microsoft Security Compliance Manager, Microsoft recommends this configuration is set to “Require NTLMv2 session security, Require 128-bit encryption” to improve NTLM security.

This policy setting determines which behaviors are allowed for applications using the NTLM Security Support Provider (SSP). The SSP Interface (SSPI) is used by applications that need authentication services. The setting does not modify how the authentication sequence works but instead require certain behaviors in applications that use the SSPI. The possible values for the Network security: Minimum session security for NTLM SSP based (including secure RPC) servers setting are: Require message confidentiality. This option is only available in Windows XP and Windows Server 2003, the connection will fail if encryption is not negotiated. Encryption converts data into a form that is not readable until decrypted. Require message integrity. This option is only available in Windows XP and Windows Server 2003, the connection will fail if message integrity is not negotiated. The integrity of a message can be assessed through message signing. Message signing proves that the message has not been tampered with; it attaches a cryptographic signature that identifies the sender and is a numeric representation of the contents of the message. Require 128-bit encryption. The connection will fail if strong encryption (128-bit) is not negotiated. Require NTLMv2 session security. The connection will fail if the NTLMv2 protocol is not negotiated. Not Defined.

Network security: Minimum session security for NTLM SSP based (include secure RPC) clients: Require NTLMv2 session security, Require 128-bit encryption

Microsoft network server: Digitally sign communications (if client agrees): Enabled The default setting is Disabled.

Session hijacking uses tools that allow attackers who have access to the same network as the client or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned SMB packets and then modify the traffic and forward it so that the server might perform undesirable actions. Alternatively, the attacker could pose as the server or client after legitimate authentication and gain unauthorized access to data. SMB is the resource sharing protocol that is supported by many Windows operating systems. It is the basis of NetBIOS and many other protocols. SMB signatures authenticate both users and the servers that host the data. If either side fails the authentication process, data transmission will not take place. This policy setting determines if the server side SMB service is able to sign SMB packets if it is requested to do so by a client that attempts to establish a connection. If no signing request comes from the client, a connection will be allowed without a signature if the Microsoft network server: Digitally sign communications (always) setting is not enabled. Note Enable this policy setting on SMB clients on your network to make them fully effective for packet signing with all clients and servers in your environment.

Microsoft network server: Digitally sign communication (always): Enabled Microsoft network client: Digitally sign communication (always): Enabled

Both of these settings are configured as “Disabled” by default.

Session hijacking uses tools that allow attackers who have access to the same network as the client or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned SMB packets and then modify the traffic and forward it so that the server might perform undesirable actions. Alternatively, the attacker could pose as the server or client after legitimate authentication and gain unauthorized access to data. SMB is the resource sharing protocol that is supported by many Windows operating systems. It is the basis of NetBIOS and many other protocols. SMB signatures authenticate both users and the servers that host the data. If either side fails the authentication process, data transmission will not take place. This policy setting determines whether packet signing is required by the SMB client component. If you enable this policy setting, the Microsoft network client computer cannot communicate with a Microsoft network server unless that server agrees to sign SMB packets. In mixed environments with legacy client computers, set this option to Disabled because these computers will not be able to authenticate or gain access to domain controllers. However, you can use this policy setting in Windows 2000 or later environments. Note When Windows Vista–based computers have this policy setting enabled and they connect to file or print shares on remote servers, it is important that the setting is synchronized with its companion setting, Microsoft network server: Digitally sign communications (always), on those servers. For more information about these settings, see the “Microsoft network client and server: Digitally sign communications (four related settings)” section in Chapter 5 of the Threats and Countermeasures guide.

Network access: Do not allow anonymous enumeration of SAM accounts and shares: Enabled The default setting is “Disabled”.

An unauthorized user could anonymously list account names and shared resources and use the information to attempt to guess passwords or perform social engineering attacks. This policy setting controls the ability of anonymous users to enumerate SAM accounts as well as shares. If you enable this policy setting, anonymous users will not be able to enumerate domain account user names and network share names on the workstations in your environment. The Network access: Do not allow anonymous enumeration of SAM accounts and shares setting is configured to Enabled for the two environments that are discussed in this guide.

WDigest Authentication (disabling may require KB2871997): Disabled WDigest Authentication is disabled by default on Windows Server 2012 R2 and newer, so this setting enforces this setting.

WDigest leaves user’s plaintext-equivalent passwords in Lsass.exe memory, which leaves the password vulnerable to Pass-the-Hash and other credential theft attacks. When WDigest authentication is enabled, Lsass.exe retains a copy of the user’s plaintext password in memory, where it can be at risk of theft. Microsoft recommends disabling WDigest authentication unless it is needed. If this setting is not configured, WDigest authentication is disabled in Windows 8.1 and in Windows Server 2012 R2; it is enabled by default in earlier versions of Windows and Windows Server. Update KB2871997 must first be installed to disable WDigest authentication using this setting in Windows 7, Windows 8, Windows Server 2008 R2 and Windows Server 2012. Enabled: Enables WDigest authentication. Disabled (recommended): Disables WDigest authentication. For this setting to work on Windows 7, Windows 8, Windows Server 2008 R2 or Windows Server 2012, KB2871997 must first be installed. For more information, see http://support.microsoft.com/kb/2871997 and http://blogs.technet.com/b/srd/archive/2014/06/05/an-overview-of-kb2871997.aspx .

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential REG_DWORD:0

Securing Domain Controllers is only one part of Active Directory security. Another is being able to detect anomalous activity which starts with logging.

Prior to Windows Server 2008, Windows auditing was limited to 9 items.

Starting with Windows Vista & Windows Server 2008, Windows auditing is expanded to 57 items.

Note that “Audit: Force audit policy subcategory settings” should be set to “Enabled” to enforce them when normal audit settings are often configured.

Use AuditPol to validate auditing settings: auditpol.exe /get /category:*

Auditing Subcategories to Events

Recommended dc auditing.

Audit Credential Validation: Success & Failure
Audit Kerberos Authentication Service: Success & Failure
Audit Kerberos Service Ticket Operations: Success & Failure
Audit Computer Account Management: Success & Failure
Audit Other Account Management Events: Success & Failure
Audit Security Group Management: Success & Failure
Audit User Account Management: Success & Failure
Audit DPAPI Activity: Success & Failure
Audit Process Creation: Success & Failure
Audit Directory Service Access: Success & Failure
Audit Directory Service Changes: Success & Failure
Audit Account Lockout: Success
Audit Logoff: Success
Audit Logon: Success & Failure
Audit Special Logon: Success & Failure
Audit IPsec Driver: Success & Failure
Audit Security State Change: Success & Failure
Audit Security System Extension: S&F Audit System Integrity : S&F

Baseline Domain Controller Events to Log

This list should be the basis for event IDs logged on Domain Controllers as well as what type of information these provide.

Here’s a large list of Domain Controller Events to monitor:

4610 – An authentication package has been loaded by the Local Security Authority.
4611 – A trusted logon process has been registered with the Local Security Authority.
4616 – The system time was changed.
4624 – An account was successfully logged on.
4625 – An account failed to log on.
4634 – An account was logged off.
4648 – A logon was attempted using explicit credentials
4649 – A replay attack was detected.
4672 – Special privileges assigned to new logon.
4673 – A privileged service was called.
4674 – An operation was attempted on a privileged object.
4688 – A new process has been created.
4689 – A process has exited.
4692 – Backup of data protection master key was attempted.
4693 – Recovery of data protection master key was attempted.
4695 – Unprotection of auditable protected data was attempted.
4697 – A service was installed in the system.
4698 – A scheduled task was created.
4699 – A scheduled task was deleted.
4702 – A scheduled task was updated.
4706 – A new trust was created to a domain.
4707 – A trust to a domain was removed.
4713 – Kerberos policy was changed.
4716 – Trusted domain information was modified.
4717 – System security access was granted to an account.
4718 – System security access was removed from an account.
4719 – System audit policy was changed.
4720 – A user account was created.
4722 – A user account was enabled.
4723 – An attempt was made to change an account’s password.
4724 – An attempt was made to reset an account’s password.
4725 – A user account was disabled.
4726 – A user account was deleted.
4727 – A security-enabled global group was created.
4728 – A member was added to a security-enabled global group.
4729 – A member was removed from a security-enabled global group.
4730 – A security-enabled global group was deleted.
4731 – A security-enabled local group was created.
4732 – A member was added to a security-enabled local group.
4733 – A member was removed from a security-enabled local group.
4734 – A security-enabled local group was deleted.
4735 – A security-enabled local group was changed.
4737 – A security-enabled global group was changed.
4738 – A user account was changed.
4739 – Domain Policy was changed.
4740 – A user account was locked out.
4741 – A computer account was created.
4742 – A computer account was changed.
4743 – A computer account was deleted.
4754 – A security-enabled universal group was created.
4755 – A security-enabled universal group was changed.
4756 – A member was added to a security-enabled universal group.
4757 – A member was removed from a security-enabled universal group.
4758 – A security-enabled universal group was deleted.
4759 – A security-disabled universal group was created.
4760 – A security-disabled universal group was changed.
4764 – A group’s type was changed.
4765 – SID History was added to an account.
4766 – An attempt to add SID History to an account failed.
4767 – A user account was unlocked.
4768 – A Kerberos authentication ticket (TGT) was requested
4769 – A Kerberos service ticket was requested
4770 – A Kerberos service ticket was renewed
4771 – Kerberos pre-authentication failed
4772 – Kerberos authentication ticket request failed
4774 – An account was mapped for logon.
4775 – An account could not be mapped for logon.
4776 – The domain controller attempted to validate the credentials for an account
4777 – The domain controller failed to validate the credentials for an account
4780 – The ACL was set on accounts which are members of administrators groups.
4782 – The password hash for an account was accessed.
4793 – The Password Policy Checking API was called.
4794 – An attempt was made to set the Directory Services Restore Mode.
4800 – The workstation was locked.
4801 – The workstation was unlocked.
4816 – RPC detected an integrity violation while decrypting an incoming message.
4817 – Auditing settings on an object were changed.
4865 – A trusted forest information entry was added.
4866 – A trusted forest information entry was removed.
4867 – A trusted forest information entry was modified.
4904 – An attempt was made to register a security event source.
4905 – An attempt was made to unregister a security event source.
4907 – Auditing settings on object were changed.
4908 – Special Groups Logon table modified.
4944 – The following policy was active when the Windows Firewall started.
4964 – Special groups have been assigned to a new logon.
5024 – The Windows Firewall Service has started successfully.
5025 – The Windows Firewall Service has been stopped.
5030 – The Windows Firewall Service failed to start.
5031 – The Windows Firewall Service blocked an application from accepting incoming connections on the network.
5033 – The Windows Firewall Driver has started successfully.
5034 – The Windows Firewall Driver has been stopped.
5035 – The Windows Firewall Driver failed to start.
5038 – Code integrity determined that the image hash of a file is not valid. The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.
5148 – The Windows Filtering Platform has detected a DoS attack and entered a defensive mode; packets associated with this attack will be discarded.
5149 – The DoS attack has subsided and normal processing is being resumed.
5150 – The Windows Filtering Platform blocked a packet.
5151 – A more restrictive Windows Filtering Platform filter has blocked a packet.
5152 – The Windows Filtering Platform blocked a packet.
5153 – A more restrictive Windows Filtering Platform filter has blocked a packet.
5154 – The Windows Filtering Platform has permitted an application or service to listen on a port for incoming connections.
5155 – The Windows Filtering Platform has blocked an application or service from listening on a port for incoming connections.
5168 – SPN check for SMB/SMB2 failed.
5378 – The requested credentials delegation was disallowed by policy.
6144 – Security policy in the group policy objects has been applied successfully.

Expanded information on these events is available for download ( DC-Events.xlsx or DC-Events.csv ). The xlsx file includes hyperlinks. Information in the csv/xlsx files includes:

Activity Logged
Audit Category
Auditing Subcategory
Event Volume

Note that many of these are high volume, so evaluate by priority prior to ingesting in your SIEM of choice.

Microsoft provides guidance for Auditing

Member servers should be fully patched before promoting to be a DC (issues like MS14-068 make this critical).
You may be tempted to move Domain Controllers out of the default Domain Controllers OU, but don’t do it. Domain Controllers in other OUs may receive different custom delegation and GPO settings.
Create a new GPO for Domain Controller security (and link to the Domain Controllers OU).
Run the Active Directory Best PRactices Analyzer every year to ensure Doamin and Domain Controller configuration is consistent. There are a number of best practice checks performed when run that identify potential issues .
All patching and updating of DCs should be done separately from workstations and servers – meaning different updating architecture. Many organizations use WSUS to patch DCs and SCCM to patch everything else.
Ensure that out-of-band (OOB) management passwords (DSRM password) are changed regularly & securely stored.
Configure sub-category auditing and set to to be enforced via GPO (“Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings”). This way you have the security events you need to track changes and AD activity. Run “auditpol.exe /get /category:*” on the server to confirm proper auditing is enabled.
Limit DC agents to the most critical, preferably none since every agent that’s added to a DC provides another pathway to AD compromise. If an agent is necessary, whoever manages that product should be treated as a Domain Admin.
If you have virtual DCs (and who doesn’t?), treat the virtual admins as a Domain Admin.
Configure the PDC to automatically synchronize time via GPO (https://blogs.technet.microsoft.com/nepapfe/2013/03/01/its-simple-time-configuration-in-active-directory/).
Minimal groups (& users) with DC admin/logon rights.
Change the default domain Administrator account at least 1x/year, preferably 2x.
Change the KRBTGT account password at least 1x/year, preferably 2x. Each time, the password should be changed once, wait for replication (or the next day), and then change again (https://blogs.microsoft.com/microsoftsecure/2015/02/11/krbtgt-account-password-reset-scripts-now-available-for-customers/).
Configure AppLocker on DCs to only allow authorized applications to run. There shouldn’t be much that runs on a DC, so this should be relatively easy.
Set all admin accounts to “sensitive & cannot be delegated”.
Minimize the groups (& users) with DC admin/logon rights.
Reduce/remove accounts & groups in Domain Admins, especially service accounts.
Leverage admin workstations & admin tiering to protect admin accounts (https://technet.microsoft.com/en-us/windows-server-docs/security/securing-privileged-access/securing-privileged-access-reference-material)
Only run software & services to support AD.
Validate scheduled tasks & scripts.
Add admin accounts to “Protected Users” group (requires Windows Server 2012 R2 Domain Controllers, 2012R2 DFL for domain protection).
Default domain Administrator & KRBTGT password should be changed every year & when an AD admin leaves.
Remove trusts that are no longer necessary & enable SID filtering as appropriate.
All domain authentication should be set (when possible) to: “Send NTLMv2 response only\refuse LM & NTLM.”
Block internet access for DCs, servers, & all administration systems.
Monitor scheduled tasks on sensitive systems (DCs, etc).

References:

Microsoft Security Documents: https://technet.microsoft.com/en-us/security/dn785092
Best Practices for Securing Active Directory: https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory
Securing Active Directory: An Overview of Best Practices (Word doc download) https://www.microsoft.com/en-us/download/details.aspx?id=38815
From the “Best Practices for Securing Active Directory” document, Securing Domain Controllers: https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-ds/plan/security-best-practices/securing-domain-controllers-against-attack
Microsoft Virtual Academy: Defending Active Directory Against Cyberattacks https://mva.microsoft.com/en-US/training-courses/defending-active-directory-against-cyberattacks-16327?l=Gj8k5XsSC_2004300474
Recommended Auditing: https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations
The US government spends a lot of time putting together a secure baseline for different Operating Systems. I look at the security settings they recommend as a starting point and will sometimes lower the security they recommend (depending on the customer requirements) https://www.stigviewer.com/stig/windows_server_2012_2012_r2_domain_controller/
There’s also a STIG for Active Directory (2008 only for StigViewer.com): https://www.stigviewer.com/stig/active_directory_domain/
31B2F340-016D-11D2-945F-00C04FB984F9 , 6AC1786C-016F-11D2-945F-00C04FB984F9 , Active Directory Best Practices analyzer , Active Directory Security , Active Directory security best practices , Audit: Force audit policy subcategory settings , Configuring Domain Controller Auditing , Default Domain Controllers Policy , Default Domain Policy GPO , Domain Controller security , domain password policy , Enable LSA Protection , Enable NTLM Auditing , Event Logs , Fine-Grained Password Policy , GPMC , Group Policy Management Console , HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential , KB2871997 , Key Domain Controller Security Items , LAN Manager authentication level , LSA Protection , Lsass.exe audit mode , Microsoft domain controller auditing , Microsoft SCM Domain Controller Security Compliance Policy , Microsoft SCM Domain Security Compliance Policy , Microsoft Security Compliance Manager , Minimum password age , Patching Domain Controllers , Protecting Domain Controllers , Recommended Group Policy Settings , Require 128-bit encryption , Require NTLMv2 session security , Require strong (Windows 2000 or later) session key , SCM , secure Active Directory , Securing Active Directory , Security Compliance , Send NTLMv2 response only. Refuse LM & NTLM , SYSVOL , User Rights Assignments , WDigest Authentication , Windows Server 2012 R2 , Windows Server 2016

Sean Metcalf

I improve security for enterprises around the world working for TrimarcSecurity.com Read the About page (top left) for information about me. :) https://adsecurity.org/?page_id=8

Skip to comment form

Oliver on November 4, 2016 at 8:36 am

Excellent article, I will definitely be referencing this for quite some time.

I have had some trouble negotiating DC communications through a corporate firewall that I do not control, but this was due to blocked ports related to replication. Are you aware of any changes in required ports if enforcing NTLMv2? What confuses me is the reference to secure RPC, which I cannot find info on elsewhere.

Actually after rereading post-coffee I think you answered this already, saying it does not modify the way the authentication sequence works, but I just want to be sure. This could have actually been a terribly stupid question, sorry.

Sean Metcalf on November 4, 2016 at 8:42 am Author

Thanks! Configuring Active Directory communications through a firewall is challenging since most of RPC occurs on random high-level ports. This is what I use as a reference: https://technet.microsoft.com/en-us/library/dd772723(v=ws.10) .aspx

Oliver on November 4, 2016 at 8:48 am

I got a kick about the job posting in the comments of that article. Makes me feel a little less stupid. The comment about dsfr sysvol on port 5722, now that I’m going to have to look into! I think the firewall I was having issues with was configured for Windows Server 2012, but we’re still on 2008 R2 and that could be contributing.

vRico on November 9, 2016 at 7:13 am

Every Domain Admin should read this article. Content rich and meticulously referenced. White paper quality articles continue to be published from this site.

Comments have been disabled.

Trimarc Active Directory Security Services

User Rights Assignments

Although in this section they are called user rights, these authority assignments are more commonly called privileges.

Privileges are computer level actions that you can assign to users or groups. For the sake of maintainability you should only assign privileges to groups not to individual users. Each computer has its own user rights assignments. In particular this means you should be cognizant of rights assignments on member servers which may easily differ from the rights assignments you find on your domain controllers. To centrally control user rights assignments on computers throughout your domain use group policy.

Logon rights
Admin equivalent rights
Tracking user rights with the security log
User rights in-depth
Access this computer from the network
Act as part of the operating system
Add workstations to domain
Adjust memory quotas for a process
Allow log on locally
Allow logon through Terminal Services
Back up files and directories
Bypass traverse checking
Change the system time
Create a pagefile
Create a token object
Create global objects
Create permanent shared objects
Debug programs
Deny access to this computer from the network
Deny logon as a batch job
Deny logon as a service
Deny logon locally
Deny logon through Terminal Services
Enable computer and user accounts to be trusted for delegation
Force shutdown from a remote system
Generate security audits
Impersonate a client after authentication
Increase scheduling priority
Load and unload device drivers
Lock pages in memory
Log on as a batch job
Log on as a service
Manage auditing and security log
Modify firmware environment values
Perform volume maintenance tasks
Profile single process
Profile system performance
Remove computer from docking station
Replace a process level token
Restore files and directories
Shut down the system
Synchronize directory service data
Take ownership of files and other objects

Child articles:

Logon Rights
Admin Equivalent Rights
Tracking User Rights with the Security Log
User Rights In-Depth

default domain controller policy user rights assignment

15 Group Policy Best Practices

This is the most thorough guide to group policy best practices on the web.

In this guide, I’ll share my recommended group policy settings and GPO management tips. These best practices will simplify GPO management, improve security, and GPO performance.

Warning: Group Policy is not a one size fits all. Every Active Directory environment is different and there is no cookie-cutter solution for group policy. It is best to plan and test any changes to group policy before rolling it out to all systems. One small change could lead to major issues and impact critical business services.

GPO Best Practices and Recommended Settings

I recommend reading the full list below as some best practices may not make sense unless you read them all.

1. Do Not Modify the Default Domain Policy

This GPO should only be used for account policy settings, password policy, account lockout policy, and Kerberos policy. Any other settings should be put into a separate GPO. The Default Domain Policy is set at the domain level so all users and computers get this policy. The Default Domain Policy is linked to the root of the domain.

When you put multiple GPO settings into the default domain policy it becomes very difficult to troubleshoot and control GPO settings. It can also impact performance if the GPO has too many settings and every user and computer has to process them. It is best to use small GPOs (see tip #12) than to stuff everything into one big GPO.

2. Do Not Modify the Default Domain Controller Policy

This GPO should only contain the User Rights Assignment Policy and Audit Policy. Any other settings to the Domain Controllers should be set in a separate GPO.

The Default Domain Controller policy is linked to the Domain Controller OU.

3. Good Organizational Unit (OU) Design Will Make Your Job 10x Easier

A good OU design makes it easier to apply and troubleshoot group policy. It is best to create an OU for computers and a separate OU for users. Then create sub-OUs on how you want to manage your objects. I typically organize objects by department and functionality.

Example OU design:

Putting users and computers in separate OUs makes it easier to apply computer policies to all the computers and user policies to only the users.

Related: 21 Effective Active Directory Management Tips

4. Do Not Set GPOs at the Domain Level

The only GPO that should be set at the domain level is the Default Domain Policy. Anything set at the domain level will get applied to all user and computer objects. This could lead to all kinds of settings getting applied to objects that you don’t want. It’s better to apply the policies at a more granular level.

5. Apply GPOs to The Root OU

Applying GPOs at the root of an OU will allow the sub-OUs to inherit these policies. This way you don’t need to link a policy to each individual OU.

If you want to exclude OUs or a group of users you have a few options.

Use GPO Security Filtering – Best option.
Use Item-level targeting
Apply a GPO to the group that disables the policy.

Exclude Users using GPO Security Filtering.

Let’s look at an example. I have GPO that disables saving passwords in the Chrome browser , the GPO is linked to all users.

What if I have users in various departments that I don’t want this policy applied to? The solution is to use GPO security filtering.

I create a security group, add users to the group, and then deny this group from applying the group policy. Now all users will get the GP except the users in the security group.

6. Avoid Using Blocking Policy Inheritance and Policy Enforcement

If you have a good OU structure then you can most likely avoid the use of blocking policy inheritance and using policy enforcement. I find it much easier to manage and troubleshoot group policies knowing neither of these is set in the domain.

7. Don’t Disable GPOs

If a GPO is linked to an OU and you don’t want it to be, delete it instead of disabling it. Deleting the link from an OU will not delete the GPO, it just removes the link from the OU. Disabling the GPO will stop it from being processed entirely on the domain, and this could cause problems.

8. Use Descriptive GPO Names

Being able to quickly identify what a GPO is for based on the name will make group policy administration much easier. Giving the GPOs a generic name like “laptop settings” is too generic and will confuse people. It will also invite other admins to just dump any and all settings into a single GPO. Before are some descriptive GPO names:

User – Browser Settings
User – Office 365 Settings
User – Block PowerShell
Computer – Screen Lock On
Computer – install Adobe

Just by looking at the above GPO names, you have a pretty good idea of what they are used for.

9. Speed Up GPO Processing by Disabling Unused Computer and User Configurations

For example, I have a GPO called browser settings, it only has computer settings configured and no user settings so, I have disabled the User configuration for this GPO. This will speed up group policy processing.

To disable the computer or user configuration of a GPO:

Browse to Group Policy Objects
Right Click a GPO and select GPO Status
Select one of the options.

10. Use Loopback Processing for Specific Use Cases

Loopback processing, in a nutshell, takes user settings and limits those settings to a computer the GPO is applied to. It is very useful but can also cause issues if used incorrectly. A common use of loopback processing is on terminal servers and Citrix servers. Users are logging into a server and you need specific user settings applied when they log into only those servers. You would need to create a GPO, enable loopback processing and apply it to the OU that has the servers in it.

11. Group Policy Change Management

Group policy can get way out of control if you let all your administrators make changes as they feel necessary.

Change management can be dreadful and it can really slow projects down.

I’m not saying all group policy changes should go through a formal change management process but they should be discussed with management and documented.

One little GPO change could send a flood of calls to the helpdesk. It happens, so it’s best to discuss and document changes to GPOs.

12. Use Small GPOs to Simplify Administration

It can be easy to fall into the trap of stuffing everything into one GPO.

I’m guilty of this too and it becomes a giant headache to manage.

There really is no reason to do this, many small GPOs do not affect performance. Small GPOs make troubleshooting, managing, designing, and implementing 10x easier.

Here are some ways to split up GPOs into smaller policies:

Browser Settings
Security Settings
Power Settings
Microsoft Office Settings
Network Settings
Drive Mappings
Firewall rules
and so on…..

13. Best Practices for Group Policy Performance

Here are some settings 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 WMI filters
Lots and lots of GPOs linked to a user or computer over a slow link.

14. Group Policy Troubleshooting Tips

Know how to use the RSop and gpresult commands to verify and troubleshoot group policy. When troubleshooting you need a way to verify that GPOs are getting applied and check exactly what policies are applied. These two commands are a huge lifesaver. I’ve written a complete how-to article for each command so be sure to check them out.

15. Backup GPOs

If you are not backing up Active Directory or doing system state backup then you need to start backing up your GPOs. You may need to recover a deleted GPO or restore the settings from existing GPOs. See my complete guide on how to backup and restore group policy objects .

To learn more about group policy check out my ultimate guide to group policy management .

I hope you found this article helpful if you have any group policy questions leave a comment below.

56 thoughts on “15 Group Policy Best Practices”

Any limit of object in OU for applying GPO with WMI?

Is there a way to have a GPO only apply while a device is on battery power but not when it is plugged in. i.e. We have patrol vehicles that while the laptop is in the vehicle and plugged into power we cannot have the screen lock. However, once that machine is off power and on battery only then apply a screen lock after x minutes.

You could try a WMI filter for batteryStatus = 1.

https://learn.microsoft.com/en-us/windows/win32/cimwin32prov/win32-battery

Thanks! very helpfull

thank you from baku

Would like to know what may be the cause of my DC administrator account not able to have elevated privileges? for context, I have set that users can not open cmd but when I tried using “run as” administrator, I am getting a message that says “C:\Windows\system32\cmd.exe The requested operation requires elevation” Also my users are getting removed from a security group that I created. eg: test user is a member of test_user_security group.

Thanks in advance!

Seems like the policy you set is restricting cmd. Remove the policy to test if that is the issue.

Is there a template for complete block except for one program (remote app) and Explorer (not IE Explorer) to browse users private folder?

Amazing guide, some things I already knew, but didn’t know the why. I still have a question, if an option has in Computers and Users, what is the best place to put?

if an option has in Computers and Users, what is the best place to put it?

Sorry, I don’t understand the question.

For example in:

Computer Configuration | Policies | Administrative Templates | Windows Componentes | AutoPlay Policies

User Configuration | Policies | Administrative Templates | Windows Componentes | AutoPlay Policies

You have the same options. I think putting for computers is better because it would apply to any user, but I’m not sure if it’s a best practice.

Thanks again.

It just depends if you want the policy to apply to all users that sign on to a computer, or specific users.

For example, if you have a shared computer and need specific users to have a desktop shortcut you would use a user configuration. If you used a computer configuration all the users would get the shortcut. If all users need the policy then use computer configuration.

excellent stuff Robert, please keep up the good work. and thank you for sharing your thoughts.

Thanks Elias

I have both my Win 10 citrix and win7 (soon to be win10) workstations on loopback/replace. I always get so much pushback from the network engineers about this.

What is the best practice for applying a group policy which contains both User and Computer settings?

Would you apply the policy to both the OU containing the users and the OU containing the computers or would you split the settings into 2 different policies (despite both policies being for the same cause).

I recommend you seperate users and computers into their own OU. If that is not an option I would create two GPOs, 1 for the user settings and 1 for the computer settings.

I already have separate OUs for Users and Computers. My question was what would you recommend is the best method if you have a GPO which contains settings for both Users and Computers.

Would you split the Computer and User settings into 2 different GPOs (i.e. even if they are all for Internet settings) or would you apply the same GPO to both the Users and Computers OUs and therefore have a GPO with Computer settings on a User OU and a GPO with User settings on an OU for just computers?

Yes, split it into two GPOs, 1 with just user settings and 1 with just the computer settings. Then you can disable the section that is not used.

Best explanation for loopback processing I’ve ever seen. Always slightly confused about what it does. Not anymore 🙂

Glad it helped

Robert, I deal with GPO management on a daily basis, in a very large environment. I agree with everything you’ve said. Here are a few things that have helped me tremendously, If you don’t want a GPO to apply to specific users or computers or groups for that matter, you can edit that GPO, go properties security and add the user, computer or group and select “DENY” apply group policy. Make sure you take advantage of adding comments to your GPO’s. Some GPO’s are doing alot and commenting them out will help you remember what they do and if there are any special nuance’s you need to take into consideration.

George great tip. This is a great way to apply GPOs to very specific groups. I need to write a how-to on this, thanks for mentioning this.

I find the practice of using Deny to be horrible! As soon as there is more than one administrator, or a change of admin employees (new person taking over), that kind of structure becomes rather confusing. If you need to use Deny, then you’ve designed the OU structure wrong…

I agree that if it is not documented or communicated it can be a nightmare. But it can also be extremely useful for targeting specific users and computers and to deny it from all users. For example, I have a blanket firewall GPO that all users get for the basic FW settings. I have some users that need FTP on, I create a new security group and only apply this GPO to these users and deny it to all other users. I want to keep all the users in their department OU so moving to another OU is not a good option for this. Targeting a GPO to a security group is great but try not to let it get out of control.

Could you please share the Steps & Process ?

Great document, thank you

Are GPO better or worse when trying to create and AD structure? Please Explain

Good OU structure is important to implementing GPOs. It helps with properly targeting the right users and computers, troubleshooting and to ensure the policy gets applied. For examples, if you want to prevent certain users from creating a pst file in outlook the GPO needs to be applied to an OU with those users. If you apply the GPO to an incorrect OU it will either not get applied or get applied to the wrong group of users.

Thank you this is awesome really!

Thanks Brian

I happen to come across your site searching for gpresults and bookmarked it.

Quickly browsing through the various posts you’ve made, I like the summarized points!

Complete newbie. I’m looking into tackling group policy and also like the rsop testing article.

My question is whether to disable or delete the group policy – in some reading I came across a while back, it mentioned to disable a group policy as a precaution (for a period of time). Just in case, something does go wrong.

Thank you for sharing your knowledge

Not sure I understand your question.

I would not recommend disabling or deleting the default GPOs or services on domain controllers.

Thanks A lot for this post

Thank you very much for spending so much time in putting this together. What suggestions do you have if the following rules have been broken and they need to be repaired? 1. Do Not Modify the Default Domain Policy 2. Do Not Modify the Default Domain Controller Policy

I very seldom work with GPOs, have inherited a rat’s nest and I’m not sure where to start the unravelling process. On top of it all, there are built-in groups with members who don’t belong there i.e., specific Users are members of Administrators, Domain Admins and Enterprise Admins. I’d like to fix the problem without causing any major disruptions to developers (yes, developers are domain admins because that’s the way they wanted it to be). Would I be better off using third-party software to unravel and straighten out a mess?

Thank you very much, John

Nice tips, doing some already, but got some new also

Thanks Maani

very supporting

great tips, i am installing AD, DHCP and DNS for a new organisation and this will definitely help in my planning and configuration. please also share tips on DNS and DHCP if possible.

I’ll be working on a best practice guide for DHCP and DNS soon. Stay tuned.

Could you elaborate a little more on why we need multiple gpos linked to an ou? Or are all the reasons there are?

I suggest grouping similar policies into their own GPO as opposed to stuffing them into one big GPO. This will make troubleshooting, managing and applying policies much easier. I’ll give an example of turning the screensaver timeout on all the computers. If I put this policy into say the default domain policy it would get applied to all computers. Now if someone requests this policy be turned off on some specific computers there is no easy way to do that. If the screensaver policy was it’s own GPO then it becomes easy to filter it out for specific users and computers. It also makes it easier to report and see what policies you have when they are broken out. Does that make sense?

really awesome

Thanks Senthil. I hope you was able to put some of these tips to use.

i’ve improved a lot my AD administration reading this article!

Thank you Robert!

Greetings from México!

Greetings! Each year I seem to pick up a few good tips, I’m happy to share them.

This is Brilliant !

Thanks Sujeeth

Looks great. Thanks for this!

Thanks Thomas

Super Excellent!!!! Thank youuuuuu!!

You’re welcome, Alex.

Awesome guide! Thanks Mug!

Thanks sofian!

Additional considerations

To perform this procedure, you must be a member of the Account Operators group, Domain Admins group, or the Enterprise Admins group in Active Directory Domain Services (AD DS), or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
To perform this procedure, you must first install Group Policy Management as a feature in Server Manager.
You can also perform the task in this procedure by using the Active Directory module for Windows PowerShell. To open the Active Directory module, click Start , click Administrative Tools , and then click Active Directory Module for Windows PowerShell . For more information, see Assign User Rights to a Group in AD DS ( https://go.microsoft.com/fwlink/?LinkId=138383 ). For more information about Windows PowerShell, see Windows PowerShell ( https://go.microsoft.com/fwlink/?LinkID=102372 ).

Additional references

Managing Groups

Understanding User Accounts
Create a New User Account
Reset a User Password
Copy a User Account
Move a User Account
Set Logon Hours
Disable or Enable a User Account
Map a Certificate to a User Account
Change a User's Primary Group
Delete a User Account
Understanding Group Accounts
Create a New Group
Add a Member to a Group
Convert a Group to Another Type
Change Group Scope
Delete a Group
Find Groups in Which a User is a Member
Understanding Computer Accounts
Create a New Computer Account
Add a Computer Account to a Group
Delete a Computer Account
Manage a Remote Computer
Move a Computer Account
Reset a Computer Account
Disable or Enable a Computer Account
Understanding Domains
Manage a Different Domain
Manage the Domain Using a Different Domain Controller
Understanding Organizational Units
Create a New Organizational Unit
Delete an Organizational Unit
Move an Organizational Unit
Delegate Control of an Organizational Unit
Troubleshooting Active Directory Users and Computers
Resources for Active Directory Users and Computers
<Object> Properties - Object tab
User Properties - Profile Tab
User Properties - Account Tab
Computer Properties - Delegation tab
Read-only Domain Controller Properties - Password Replication Policy Tab
Advanced Password Replication Policy Dialog Box - Policy Usage Tab
Advanced Password Replication Policy Dialog Box - Resultant Policy Tab
Prepopulating Passwords
New Object - Organizational Unit Dialog Box
Change <Domain> or <Forest> Dialog Box
Change Domain Controllers Dialog Box
Raise Domain Functional Level Dialog Box
Tasks to Delegate
Active Directory Object Type
Permissions

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.

I need to restore AD Default Domain Controllers Policy to default but cannot log in

Okay, long story.

I only have two domain controllers, I know, bad choice, but that's just what I did.

Microsoft just released the RD Web Client, so I wanted to install it. I created a new VM and joined it to my domain. Once I installed the Remote Desktop Web Client, it worked, except I couldn't use the Connection Broker because its service was starting and stopping. I found that it had something to do with the policies in Computer config > Windows Settings > Local security options > User rights assignment.

I went into that section and found the policy that the site listed to change that was about Generating Security Audits and one about Logging on as a Service to both allow Local Service and Network Service. That did not fix it for me.

This is where I went insane, please do not mind me, I regret everything I did.

I thought, maybe I should try others in that policy list, so I tried the one about creating a Token Object.

It froze, took a while, and then said could not change policy. But even so, it still showed the changes I made. So I preceeded to change them back. Once again, it gave the error, but still changed. Then I noticed that it gave an error saying that the domain controller could not be contacted. The other couldn't either. The GPO Management then closed.

In my VMWare list, I then noticed that my primary domain controller had shut down. I looked at it, and it booted back up, and then it said Applying Security Policy and Default Domain Controllers Policy, and then it said Please wait for Local Session Manager, then shut down again.

It is now in a boot loop.

I found something here " http://www.sysadminlab.net/windows/restore-default-domain-policy-and-default-domain-controller-gpo-settings-to-default ", but I can't do it on Startup Repair options because it does not support Windows PE.

I tried Safe Mode, Safe mode with networking, and Safe mode with Command Prompt. Nothing.

I tried Last Known Good Configuration, nothing.

I also tried Directory Services Repair, but it can't complete the command because "it is not a domain controller". If I try to log in to a domain account instead in Directory Services Repair, it says the log on server could not be contacted.

I have tried everything I could think of, and I CANNOT afford to lose my AD Domain.

Also, if you come up with a solution, please take into account that I have an Exchange 2010 server hosted on that DC too, and can't afford to lose that either.

Also, the domain controller that won't boot is running Windows Server 2008 R2.

Furthermore, the RD domain controller DOES boot and log in, I'm not sure what's different. But do you think it's worth it to do the reset of policies on it?

active-directory
windows-server-2008-r2

Under what circumstances may I add “urgent” or other similar phrases to my question, in order to obtain faster answers? – ceejayoz Jul 26, 2018 at 1:17
So you cannot log into your domain controller using the default domain administrator credentials? Have you by any chance created any other domain administrator accounts whose credentials might be cached on that server? Are you also saying that even though this server is a domain controller, Domain Services Restore Mode is not working because it thinks that it is no longer a DC? – Sam Erde Jul 26, 2018 at 5:04
I cannot log into ANY account, because it shuts down before logon. The only time I can log into an account is when I boot in DSRM but it states, yes, that it isn't a domain controller, even though it obviously knows that it is because when logging in it specifically states that it is logging into my domain (INTERNAL). Yes, I do have two other accounts in the Admins group, but once again, same issue, because if I state any admin account to log in in DSRM, it says the server can't be contacted, and on the regular bootup, it just shuts down before logon. – CCLL1246 Jul 26, 2018 at 13:38

4 Answers 4

Something you can try is power off the damaged domain controller, mount the damaged domain controller disk on the functional domain controller, and copy the contents of the policy folder that you changed from the functional DC disk. Then reattached the disk to the damaged DC and start it.

C:\Windows\SYSVOL\sysvol\[domain]\Policies\{Guid of the policy that you changed}\

The offending file is probably the \MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

I believe the line you are looking for should look like:

SeCreateTokenPrivilege =

If the computer is crashing before applying the policy that you changed, it may not work.

OP would have to recover the file from the backup, I believe both DCs are toast. – Semicolon Jul 26, 2018 at 15:41
The permanent GUID of the DDCP is {6AC1786C-016F-11D2-945F-00C04FB984F9} – Semicolon Jul 26, 2018 at 15:43
2 I actually just booted into the recovery mode and deleted the {6AC1786C-016F-11D2-945F-00C04FB984F9} policy folder in SYSVOL. The server now boots up. Thanks for the policy name, Semicolon. – CCLL1246 Jul 26, 2018 at 19:14

Alright guys, I fixed it. I had to boot into recovery mode (WINPE), and I went into CMD, and removed the policy faulty policy {6AC1786C-016F-11D2-945F-00C04FB984F9} as Semicolon stated, and the server booted back up. Thanks very much.

Nice work! Just curious about something... in the main description you said Win PE not supported on your servers, and in the solution you said you booted to Win PE. Thx. – joshgoldeneagle Jul 27, 2018 at 0:50
What I said, is that Windows PE is not supported by dcgpofix. But manually deleting files off of the hard drive is supported. – CCLL1246 Jul 27, 2018 at 16:43

I'm guessing you missed this tidbit in the Windows Documentation for the Create a token object user right - (which you read before you adjusted the GPO that you didn't understand)

[Create a token object] is used internally by the operating system. Unless it is necessary, do not assign this user right to a user, group, or process other than Local System.

Honestly, given your apparent level of experience, you need to get out your credit card, call Microsoft and open a case to see if they can help you resolve this.

You may be able to edit the DDCP group policy file manually if you use something like a live distro to boot into and access the drive. I've never tried anything like that on a Domain Controller before, so YMMV.

Or instead of editing the file manually, you can obtain a previous copy of the GPO from your backup, and using a live CD linux distro to replace the current DDCP gpo with the older DDCP gpo file - may want to do that on both domain controllers, though.

Failing that, you may have to bite the bullet restore the DC from a backup.

Maybe if you are lucky there is a VMWare snapshot you can restore from. In the future you should consider taking a VMWare snapshot every time you are making any significant changes on a server. Of course you need to remember to remove the snapshot once it is confirmed the changes are successful, as VMWare snapshots cannot be kept long term unfortunately.

Otherwise hopefully you can restore from your backup software. Please tell us someone is doing regular scheduled backups in your environment.

1 The short version of this comment is, "do not take snapshots of domain controllers!" – Sam Erde Jul 26, 2018 at 5:00
Okay, yes, I have backups, from a software called Vembo, but I only like to use them when ABSOLUTELY nescessary, as when I restored from them once, the Exchange mail server could not send OR receive, and some policies had to be completely started over. – CCLL1246 Jul 26, 2018 at 13:40

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged active-directory windows-server-2008-r2 ..

The Overflow Blog
Why the creator of Node.js® created a new JavaScript runtime
Is AI making your code worse?
Featured on Meta
Changing how community leadership works on Stack Exchange: a proposal and...
Shifting the data dump schedule: A proposal

Hot Network Questions

Can one be cruel to nonsentient things?
What does Rashi mean with "our Rabbis expounded what they expounded"?
Could uploading a paper on arXiv before publishing it in a journal lead to being "scooped", or does it actually prevent that?
Why can an applied force exceed static friction *without slipping* when both objects are free?
Why can't I check-in online for international flights?
Will the coating on deck screws interact poorly with untreated lumber?
Next cyclic suffix
How do ETFs process dividends?
Cooling fan direction
Characters on ray class groups
How to make my icosphere inflate in a heart shape?
Why define coefficient of determination as 1 - RSS/TSS?
Old movie similar to Clash of Titans (1981) but with Romans
Imperative Call Using Await In LWC
How can I help my players resume mid-battle with the same energy?
How to compensate for overcount?
How could I make literacy universal in a medieval society?
9-hour 40-mn layover in Haneda Airport
Can I Clear The Grid?
Is there a literary term for a word which looks completely 'flat' when spelled out in lowercase?
How to get a single rainbow coloured legend for a group of rainbow coloured curves all having same line style?
Seeking a Polynomial Time Algorithm for Balanced Weight Assignment to Nodes in a Tree
Why do (or don't) languages forbid unreachable code?
FAR 121.577 and first class drinks

Master of the ServerVerse

Exchange and the default domain controllers gpo.

I recently ran across an issue with an Exchange 2010 server that was configured for a hybrid Office 365 setup. The on-premises Exchange 2010 server had the majority of mailboxes migrated to Office 365 and was serving primarily as an onsite SMTP relay and CAS server. The service desk at my client had started to receive complaints that scan-to-email and other relays were not working. In addition, they were not able to provision new employee MS Outlook profiles using Autodiscover and existing users were receiving prompts in Outlook regarding connectivity.

The client was not aware of any specific changes to the environment. They did edit a GPO, but stated it was only a minor change that would not have this effect.

Reviewing the status of the Exchange server, there were numerous errors regarding MSExchange ADAccess, MSExchange Mailbox Replication, and other critical Exchange services. The Exchange Management Console would not enumerate successfully, citing a Kerberos authentication error. The event viewer also showed the following helpful errors:

error code 0x80040a02 (DSC_E_NO_SUITABLE_CDC)

A quick online search led me to this helpful article , which suggested checking group policies for the Mange auditing and security log user rights assignment, affecting the domain controllers. According to Microsoft , the AD Prep operation of the Exchange 2010 setup takes care of this:

On each domain controller in a domain in which you will install Exchange 2010, the Exchange Servers USG has permissions on the Domain Controller Security Policy\Local Policies\User Rights Assignment\Manage Auditing and Security Log policy.

The Default Domain Controllers Policy is supposed to be pushing this setting out, granting permissions on the domain controllers to the Exchange server(s). However, this was not happening as indicated by checking the SACL right value in following event:

Application | MSExchange ADAccess | 2080 | Topology

Here’s an example showing the lack of required permissions ( SACL right = 0 )

Here’s an example showing the correct required permissions ( SACL right = 1 )

The Default Domain Controllers Policy setting was configured correctly, however running GP Results against the domain controllers showed that the Default Domain Policy setting had taken preference over the Default Domain Controllers Policy setting.

This was confirmed by viewing the Group Policy Inheritance on the Domain Controllers OU using the GPMC, as shown below.

The Domain Controllers OU had inheritance set to blocked , however the Default Domain policy was set to enforced , which took precedence over other policies. Removing the enforced setting, running GP Update on the domain controllers, and restarting the Exchange services (or server) cleared up the issue right away!

How to reset user rights in the default domain group policy in Windows Server 2003

3 contributors

This article describes how to reset user rights in the default domain Group Policy object (GPO) in Windows Server 2003.

Applies to: Windows Server 2003 Original KB number: 324800

The default domain GPO contains many default user-rights settings. Sometimes, if you change the default settings, unexpected restrictions may be put on user rights. If the changes are unexpected or if the changes were not recorded so that you do not know which changes were made, you may have to reset the user-rights settings to their default values.

Reset User Rights for the Default Domain GPO

To restore user rights to use the default settings for the default domain GPO, follow the procedures that are described in this section in the order that they are presented.

Make sure that you use caution when you perform the following procedures. If you configure the GPO template incorrectly, you may cause your domain controllers to be inoperable.

Edit the Gpttmpl.inf File

To edit the Gpttmpl.inf file, follow these steps.

Back up the Gpttmpl.inf file before you perform this procedure.

Start Windows Explorer and open the following folder, where Sysvol_path is the path of the Sysvol folder:

Sysvol_path \Sysvol\ DomainName \Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\Microsoft\Windows NT\SecEdit

The default path of the Sysvol folder is %SystemRoot%\Sysvol.

Right-click Gpttmpl.inf , and then click Open .

To completely reset the user rights to the default settings, replace the existing information in the Gpttmpl.inf file with the following default user-rights information. To do so, paste the following text in the appropriate section of your current Gpttmpl.inf file:

On the File menu, click Save , and then click Exit .

The permissions settings that result from this procedure are the same as the permissions that are compatible with pre-Microsoft Windows 2000 users and permissions that are compatible only with Windows 2000 users.

Edit the Gpt.ini File

The Gpt.ini file controls the GPO template version numbers. You must edit the Gpt.ini file to increase the GPO template version number. To do so:

Start Windows Explorer and open the following folder, where Sysvol_path is the path of the Sysvol folder: Sysvol_path \Sysvol\Domain\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}

Right-click Gpt.ini , and then click Open .

Increase the version number to a number that is sufficient to guarantee that typical replication does not outdate the new version number before the policy is reset. Increment the number either by adding the number "0" to the end of the version number or the number "1" to the beginning of the version number.

Use GPUpdate to Refresh the Group Policy

Apply the new GPO by using the GPUpdate tool to manually reapply all policy settings. To do so:

Click Start , and then click Run .

In the Open box, type cmd, and then click OK .

At the command prompt, type the following line, and then press ENTER: GPUpdate /Force

Type exit and then press ENTER to quit the command prompt.

To look for errors in policy processing, review the event log.

Use Event Viewer to verify that the GPO was successfully applied. To do so:

Click Start , point to Administrative Tools , and then click Event Viewer .
Click Application .

Look for Event ID 1704 to verify that the GPO was successfully applied.

Was this page helpful?

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

The Default Domain Controllers Policy

Numerous user rights assignment settings are predefined in the Default Domain Controllers Policy. Figure 4.19 illustrates the predefined user rights assignment settings for the Windows Server 2003 Default Domain Controllers Policy.

Figure 4.19 Default Domain Controllers Policy: User Rights Assignment

As Figure 4.19 illustrates, several options are predefined in the Default Domain Controllers Policy. The main functions provided by this predefined policy control users' abilities to accomplish administrative and nonadministrative tasks in an Active Directory environment. One of the more common settings provided by the User Rights Assignment portion of the Default Domain Controllers Policy is the capability to Add workstations to domain, granting the right to join systems to the current domain environment. Other policies control the capabilities to log on locally, log on through Terminal Services, and back up files and folders on the system, just to name a few. In the next section, we will discuss best practice and review some common settings used in Active Directory Group Policy.

Developing & Deploying...

Continue reading here: Identifying Active Directory Sites and Subnets

Was this article helpful?

Default Domain Policy - Designing Infrastructure Windows Server 2003
Domain Controller Sizing and Specification
Active Directory Integrated versus Primary Zones
Root Hints and Forwarders
NTLM and Kerberos - Designing Infrastructure Windows Server 2003
Network Topology Definitions

IMAGES

Securing Domain Controllers to Improve Active Directory Security
User rights assignment in Windows Server 2016
Configuring domain controllers for Exchange auditing
active directory
Additional autologin settings
Change User Rights Assignment Security Policy Settings in Windows 10

VIDEO

29- Default Domain Policy & Default DC Policy
3. Creating Additional Domain Controller
28- Domain Group Policy
How to install/utilize Active Directory Domain Services
Types of Group Policy Object and how to link two GPO in Windows Server 2012 R2 in Hindi- PART 7
Project

COMMENTS

Resetting Default Domain Controllers Policy
Our Default Domain Controllers Policy GPO has numerous 'broken' assignments. For example: Act as part of the operating system. ... But when I get back to User Rights Assignment, the vast majority of the broken SIDs are still in place. Additionally, the "log on as a service" section contains a variety of domain accounts (ie: domain\backupuser ...
What are the defaults for the "user rights assignment" in an AD
If you're asking for User Rights Assignment on a single computer, look for Local Security Policy. If you're asking for User Rights Assignment as a group policy, well, it shows up just fine in my console. Are you using RSAT (Remote Server Administration Tools)? I'm using the RSAT available for Windows 10. Older versions of RSAT (or the version ...
User Rights Assignment
User rights are managed in Group Policy under the User Rights Assignment item. Each user right has a constant name and a Group Policy name associated with it. The constant names are used when referring to the user right in log events. You can configure the user rights assignment settings in the following location within the Group Policy ...
Configure security policy settings
Select Local Policies to edit an Audit Policy, a User Rights Assignment, or Security Options. When you find the policy setting in the details pane, double-click the security policy that you want to modify. ... The following procedure describes how to configure a security policy setting for only a domain controller (from the domain controller).
Change User Rights Assignment Security Policy Settings in Windows 10
1 Press the Win + R keys to open Run, type secpol.msc into Run, and click/tap on OK to open Local Security Policy. 2 Expand open Local Policies in the left pane of Local Security Policy, and click/tap on User Rights Assignment. (see screenshot below step 3) 3 In the right pane of User Rights Assignment, double click/tap on the policy (ex: "Shut down the system") you want to add users and/or ...
User rights assignment in Windows Server 2016
They include account policies, local policies, user rights assignment, the Windows firewall, software restrictions, and so on. There are several ways to configure security policy settings. The most common are: Group policy objects (GPO) - Used in Active Directory domains to configure and regularly reapply security settings to multiple computers.
Default Domain Vs Default Domain Controller Policy
spiceuser-4hodz (spiceuser-4hodz) November 14, 2023, 1:58pm 1. As per best practices, Default Domain Controller Policy is for the User Rights Assignment Policy and Audit Policy only. The same settings of DDCP are also available in DDP. Also the policies of DDP are applicable for DC as well.
Best practice for Default Domain Policy and Default Domain Controllers
A. The best practice recommendation from Microsoft is as follows: · To accommodate APIs from previous versions of the operating system that make changes directly to default GPOs, changes to the following security policy settings must be made directly in the Default Domain Policy GPO or in the Default Domain Controllers Policy GPO: · Default ...
Restricting User Rights Assigning in Default Domain Controller Policy
I am currently reviewing my work's default domain controller policy GPO against the MS Security Compliance Manager, and one of the things I have found is that there are many things that have user rights assignments that do not appear in the compliance baseline. Many of this things look to be machine accounts such as: DOMAIN\IWAM_[Server-Name]
What Group Policy settings MUST be set within the Default Domain Policy
Changes in settings to domain security policy should always be made to the Default Domain Policy GPO. Changes in settings to domain controller security policy for User Rights Assignment and Audit Policy must be made to the default GPO, rather than to a newly created GPO. Default Domain Policy: Password Policy, Account Lockout Policy, Kerberos ...
Windows Group Policy: Deploying Group Policy
Accessing the Default Domain Policy GPO in GPMC. In the Group Policy Management Editor, under Computer Configuration, expand Policies\Windows Settings\Security Settings\Local Policies as shown in Figure 2-4. You can then work with Audit Policy, User Rights Assignment, and Security Options as necessary. Figure 2-4.
Securing Domain Controllers to Improve Active Directory Security
The Default Domain Policy default settings for Windows Server 2012 R2 are shown in the above graphic. The Default Domain Controllers Policy should only contain the following settings: User Rights Assignment; Security Options (some) The Default Domain Controllers Policy default settings for Windows Server 2012 R2 are shown in the above graphics.
User Rights Assignment
User rights permissions control access to computer and domain resources, and they can override permissions that have been set on specific objects. User rights are managed in Group Policy under the User Rights Assignment item. Each user right has a constant name and a Group Policy name associated with it. The constant names are used when ...
User Rights Assignments
Each computer has its own user rights assignments. In particular this means you should be cognizant of rights assignments on member servers which may easily differ from the rights assignments you find on your domain controllers. To centrally control user rights assignments on computers throughout your domain use group policy. Logon rights
Allow log on locally
For domain controllers, assign the Allow log on locally user right only to the Administrators group. For other server roles, you may choose to add Backup Operators in addition to Administrators. For end-user computers, you should also assign this right to the Users group. Alternatively, you can assign groups such as Account Operators, Server ...
15 Group Policy Best Practices
This GPO should only contain the User Rights Assignment Policy and Audit Policy. Any other settings to the Domain Controllers should be set in a separate GPO. The Default Domain Controller policy is linked to the Domain Controller OU. 3. Good Organizational Unit (OU) Design Will Make Your Job 10x Easier
Default Domain Policy applies User Rights Assignments that are not in
No OUs. User Rights Assignments on this domain were implemented via a combination of the Default Domain Policy and a security template deployed on each system. I need to ditch the security template and apply the settings via GPO. Here in lies the problem. At first an RSOP and a GPRESULT would display a blank source for the User Rights ...
Assign User Rights to a Group in AD DS
To assign user rights to a group in Active Directory Domain Services To open Group Policy Management, click Start , click Run , type gpmc.msc , and then click OK . In the console tree, right-click Default Domain Controllers Policy , and then click Edit .
I need to restore AD Default Domain Controllers Policy to default but
I found that it had something to do with the policies in Computer config > Windows Settings > Local security options > User rights assignment. ... and then it said Applying Security Policy and Default Domain Controllers Policy, and then it said Please wait for Local Session Manager, then shut down again. It is now in a boot loop.
default domain and dc policy
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.
Exchange and the Default Domain Controllers GPO
On each domain controller in a domain in which you will install Exchange 2010, the Exchange Servers USG has permissions on the Domain Controller Security Policy\Local Policies\User Rights Assignment\Manage Auditing and Security Log policy. The Default Domain Controllers Policy is supposed to be pushing this setting out, granting permissions on ...
Reset user rights in the default domain GPO
Right-click Gpttmpl.inf, and then click Open. To completely reset the user rights to the default settings, replace the existing information in the Gpttmpl.inf file with the following default user-rights information. To do so, paste the following text in the appropriate section of your current Gpttmpl.inf file: On the File menu, click Save, and ...
The Default Domain Controllers Policy
Figure 4.19 Default Domain Controllers Policy: User Rights Assignment As Figure 4.19 illustrates, several options are predefined in the Default Domain Controllers Policy. The main functions provided by this predefined policy control users' abilities to accomplish administrative and nonadministrative tasks in an Active Directory environment.