Securing Domain Controllers To Improve Active Directory Security

Securing Domain Controllers to Improve Active Direct... https://adsecurity.org/?
p=3377
•  (https://adsecurity.org/?feed=rss2)
 Securing Windows Workstations: Developing a Secure Baseline (https://adsecurity.org/?p=3299)
Sneaky Persistence Active Directory Trick #18: Dropping SPNs on Admin Accounts for Later
Kerberoasting (https://adsecurity.org/?p=3466) 
Nov 03 2016
Securing Domain Controllers to Improve Active Directory Security

• By Sean Metcalf (https://adsecurity.org/?author=2) in ActiveDirectorySecurity (https://adsecurity.org
/?cat=565), Microsoft Security (https://adsecurity.org/?cat=11), Technical Reference
(https://adsecurity.org/?cat=2)
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 (https://adsecurity.org
/?page_id=1352) 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}
1 of 42 10/15/23, 16:40
Securing Domain Controllers to Improve Active Direct... https://adsecurity.org/?p=3377
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
(https://support.microsoft.com/en-us/kb/556025). The Active Directory Best Practices Analyzer
(https://technet.microsoft.com/en-us/library/dd391875(v=ws.10).aspx) looks for the default GPOs to ensure
they’re applied correctly (https://technet.microsoft.com/en-us/library/ff646920(v=ws.10).aspx). 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
2 of 42 10/15/23, 16:40
3 of 42 10/15/23, 16:40
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)
4 of 42 10/15/23, 16:40
5 of 42 10/15/23, 16:40
The Default Domain Controllers Policy default settings for Windows Server 2012 R2 are shown in the above
graphics.
Creating Domain & Domain Controller Security Baseline GPOs

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.
• Minimum Password Age: 1
◦ 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.
6 of 42 10/15/23, 16:40
• Minimum Password Length: 14

◦ 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
(https://blogs.technet.microsoft.com/canitpro/2013/05/29/step-by-step-enabling-and-using-fine-
grained-password-policies-in-ad/) 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
• Store passwords using reversible encryption: Disabled
◦ 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.
• Account lockout duration: 1 – 90 minutes
◦ Set to some value to mitigate password guessing attempts
• Account lockout threshold: 5 – 20 invalid logon attempts
◦ Set to configure how many invalid logon attempts are required before locking the account.
• Reset account lockout counter after: 5 – 60 minutes
◦ 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 (https://technet.microsoft.com/en-us/solutionaccelerators
/cc835245.aspx) (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)
7 of 42 10/15/23, 16:40
Microsoft SCM Domain Controller Security Compliance Policy
8 of 42 10/15/23, 16:40
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 (https://blogs.technet.microsoft.com/secguide/2014/04
/07/why-were-not-recommending-fips-mode-anymore/). 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 (http://iase.disa.mil/stigs/os/windows)

• Australian Information Security Manual: http://www.asd.gov.au/infosec/ism/index.htm
(http://www.asd.gov.au/infosec/ism/index.htm)
• CIS Benchmarks: https://benchmarks.cisecurity.org/downloads/browse
/?category=benchmarks.os.window (https://benchmarks.cisecurity.org/downloads/browse
/?category=benchmarks.os.windows)
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
(https://blogs.technet.microsoft.com/secguide/2016/01/22/new-tool-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
9 of 42 10/15/23, 16:40
Workstation Configuration, Windows Server Configuration, User Configuration, etc. In addition to these,
configure additional GPOs with a few new settings for testing.
Patching Domain Controllers

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).
Protecting Domain Controllers

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:
• Kerberos AES encryption support (http://blogs.msdn.com/b/openspecification/archive/2011/05

/31/windows-configurations-for-kerberos-supported-encryption-type.aspx)
◦ Enables possibility of removing RC4 HMAC Kerberos encryption from supported types
(http://blogs.msdn.com/b/openspecification/archive/2011/05/31/windows-configurations-for-
kerberos-supported-encryption-type.aspx). Note that Windows 7 & Windows Server 2008 R2
no longer support Kerberos DES encryption (https://technet.microsoft.com/en-us/library
/dd560670%28v=ws.10%29.aspx).
• Managed Service Accounts (http://blogs.technet.com/b/askds/archive/2009/09/10/managed-service-
accounts-understanding-implementing-best-practices-and-troubleshooting.aspx)
◦ AD controls the service account password.
• Authentication Mechanism Assurance (https://technet.microsoft.com/en-us/library
/dd391847%28v=ws.10%29.aspx).
◦ Users receive additional group membership when authentication with smartcard
Windows Server 2012 Domain Functional Level:
• Group Managed Service Accounts (https://technet.microsoft.com/en-us/library/hh831782.aspx)

◦ AD controls the service account password.
• Compound Authentication & Kerberos FAST (Kerberos Armoring) (https://technet.microsoft.com/en-
us/library/hh831747.aspx)
10 of 42 10/15/23, 16:40
◦ Combines user and device authentication

◦ Protects Kerberos AS & TGT requests.
Windows Server 2012 R2 Domain Functional Level:
• Authentication Policies & Silos (https://technet.microsoft.com/en-us/library/dn486813.aspx)

◦ Protect privileged accounts limiting where they can logon to.
• Protected Users Security Group (https://technet.microsoft.com/en-us/library/dn466518.aspx)
◦ PDC set to Windows 2012 R2 to create the group
◦ Protected Users Host Protection (Win 8.1/2012R2) Prevents:
▪ Authentication by using NTLM, Digest Authentication, or CredSSP.
▪ Cached credentials
▪ DES or RC4 encryption types in Kerberos pre-authentication.
▪ Account delegation.
◦ Protected Users Domain Enforcement Prevents:
▪ NTLM authentication.
▪ DES or RC4 encryption types in Kerberos pre-authentication.
▪ Be delegated with unconstrained or constrained delegation.
▪ Renew the Kerberos TGTs beyond the initial four-hour lifetime.
Windows Server 2016 New Security Features (https://technet.microsoft.com/windows-server-

docs/identity/whats-new-active-directory-domain-services):
• 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) (https://technet.microsoft.com/en-us/windowsserver/bb332157.aspx).
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)
11 of 42 10/15/23, 16:40
• 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
• Devices: Prevent users from installing printer drivers: Enabled
• Shut down the system: Administrators
Domain Controller Recommended Group Policy Settings

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
(https://technet.microsoft.com/en-us/library/jj865672(v=ws.10).aspx) to identify how NTLM authenticaiton is
used in the enterprise.
12 of 42 10/15/23, 16:40
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
13 of 42 10/15/23, 16:40
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.
14 of 42 10/15/23, 16:40
• 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
(https://technet.microsoft.com/en-us/library
/dn408187.aspx#How%20to%20configure%20additional%20LSA%20protection%20of%20credentials).
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.
15 of 42 10/15/23, 16:40
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”.
16 of 42 10/15/23, 16:40
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.
17 of 42 10/15/23, 16:40
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
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.
18 of 42 10/15/23, 16:40
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.
Microsoft network server: Digitally sign communications (if client agrees): Enabled
The default setting is Disabled.
19 of 42 10/15/23, 16:40
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.
20 of 42 10/15/23, 16:40
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
21 of 42 10/15/23, 16:40
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.
22 of 42 10/15/23, 16:40
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
Configuring Domain Controller Auditing (Event Logs)

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.
23 of 42 10/15/23, 16:40
Starting with Windows Vista & Windows Server 2008, Windows auditing is expanded to 57 items.
24 of 42 10/15/23, 16:40
25 of 42 10/15/23, 16:40
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

Auditing Subcategory Event IDs
26 of 42 10/15/23, 16:40
Audit Audit Policy Change 4719: System audit policy was changed.
4908: Special Groups Logon table modified.
Audit Authentication Policy Change 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.
4739: Domain Policy was 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.
4706: A new trust was created to a domain.
4707: A trust to a domain was removed.
Audit Computer Account Management 4741: A computer account was created.
4742: A computer account was changed.
4743: A computer account was deleted.
Audit DPAPI Activity 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.
Audit Kerberos Authentication Service 4768: A Kerberos authentication ticket (TGT) was requested
4771: Kerberos pre-authentication failed
4772: Kerberos authentication ticket request failed
Audit Kerberos Service Ticket Operation 4769: A Kerberos service ticket (TGS) was requested
4770: A Kerberos service ticket was renewed
Audit Logoff 4634: An account was logged off.
27 of 42 10/15/23, 16:40
Audit Logon 4624: An account was successfully logged on.
4625: An account failed to log on.
4648: A logon was attempted using explicit credentials.
Audit Other Account Logon Events 4648: A logon was attempted using explicit credentials
4649: A replay attack was detected.
4800: The workstation was locked.
4801: The workstation was unlocked.
5378: The requested credentials delegation was disallowed

by policy.
Audit Other Object Access Events 4698: A scheduled task was created.
4699: A scheduled task was deleted.
4702: A scheduled task was updated.
Audit Process Creation 4688: A new process has been created.
Audit Security Group Management 4728: A member was added to a security-enabled global
group.
4729: A member was removed from a security-enabled global

group.
4732: A member was added to a security-enabled local

group.
4733: A member was removed from a security-enabled local

group.
4735: A security-enabled local group was changed.
4737: A security-enabled global group was changed.
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.
4764: A group’s type was changed.
28 of 42 10/15/23, 16:40
Audit Security System Extension 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.
4697: A service was installed in the system.
Audit Sensitive Privilege Use 4672: Special privileges assigned to new logon.
4673: A privileged service was called.
4674: An operation was attempted on a privileged object.
Audit Special Logon 4964: Special groups have been assigned to a new logon.
Audit User Account Management 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.
4738: A user account was changed.
4740: A user account was locked out.
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.
4780: The ACL was set on accounts which are members of

administrators groups.
4794: An attempt was made to set the Directory Services

Restore Mode.
Recommended DC Auditing
• Account Logon
◦ Audit Credential Validation: Success & Failure
◦ Audit Kerberos Authentication Service: Success & Failure
◦ Audit Kerberos Service Ticket Operations: Success & Failure
• Account Management
◦ Audit Computer Account Management: Success & Failure
◦ Audit Other Account Management Events: Success & Failure
29 of 42 10/15/23, 16:40
◦ Audit Security Group Management: Success & Failure

◦ Audit User Account Management: Success & Failure
• Detailed Tracking
◦ Audit DPAPI Activity: Success & Failure
◦ Audit Process Creation: Success & Failure
• DS Access
◦ Audit Directory Service Access: Success & Failure
◦ Audit Directory Service Changes: Success & Failure
• Logon and Logoff
◦ Audit Account Lockout: Success
◦ Audit Logoff: Success
◦ Audit Logon: Success & Failure
◦ Audit Special Logon: Success & Failure
• System
◦ 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.
EventID Description Impact
4768 Kerberos auth ticket (TGT) was Track user Kerb auth, with client/workstation
requested name.
4769 User requests a Kerberos service Track user resource access requests &
ticket Kerberoasting
4964 Custom Special Group logon tracking Track admin & “users of interest” logons
4625/4771 Logon failure Interesting logon failures. 4771 with 0x18 =

bad pw
4765/4766 SID History added to an If you aren’t actively migrating accounts

account/attempt failed between domains, this could be malicious
4794 DSRM account password change If this isn’t expected, could be malicious
attempt
4780 ACLs set on admin accounts If this isn’t expected, could be malicious
4739/643 Domain Policy was changed If this isn’t expected, could be malicious
4713/617 Kerberos policy was changed If this isn’t expected, could be malicious
4724/628 Attempt to reset an account’s Monitor for admin & sensitive account pw
password reset
30 of 42 10/15/23, 16:40
4735/639 Security-enabled local group changed Monitor admin/sensitive group membership

changes
4737/641 Security-enabled global group Monitor admin/sensitive group membership

changed changes
4755/659 Security-enabled universal group Monitor admin & sensitive group membership
changed changes
5136 A directory service object was Monitor for GPO changes, admin account
modified modification, specific user attribute
modification, etc.
Domain Controller Events to Monitor (Event Logs)

Here’s a large list of Domain Controller Events to monitor:
• 4610 (https://www.ultimatewindowssecurity.com/securitylog/encyclopedia
/event.aspx?eventid=4610)– An authentication package has been loaded by the Local Security
Authority.
/event.aspx?eventid=4611)– A trusted logon process has been registered with the Local Security
Authority.
/event.aspx?eventid=4616)– The system time was changed.
/event.aspx?eventid=4624)– An account was successfully logged on.
/event.aspx?eventid=4625)– An account failed to log on.
/event.aspx?eventid=4634)– An account was logged off.
/event.aspx?eventid=4648)– A logon was attempted using explicit credentials
/event.aspx?eventid=4649)– A replay attack was detected.
/event.aspx?eventid=4672)– Special privileges assigned to new logon.
/event.aspx?eventid=4673)– A privileged service was called.
/event.aspx?eventid=4674)– An operation was attempted on a privileged object.
/event.aspx?eventid=4688)– A new process has been created.
/event.aspx?eventid=4689)– A process has exited.
/event.aspx?eventid=4692)– Backup of data protection master key was attempted.
31 of 42 10/15/23, 16:40
/event.aspx?eventid=4693)– Recovery of data protection master key was attempted.

/event.aspx?eventid=4695)– Unprotection of auditable protected data was attempted.
/event.aspx?eventid=4697)– A service was installed in the system.
/event.aspx?eventid=4698)– A scheduled task was created.
/event.aspx?eventid=4699)– A scheduled task was deleted.
/event.aspx?eventid=4702)– A scheduled task was updated.
/event.aspx?eventid=4706)– A new trust was created to a domain.
/event.aspx?eventid=4707)– A trust to a domain was removed.
/event.aspx?eventid=4713)– Kerberos policy was changed.
/event.aspx?eventid=4716)– Trusted domain information was modified.
/event.aspx?eventid=4717)– System security access was granted to an account.
/event.aspx?eventid=4718)– System security access was removed from an account.
/event.aspx?eventid=4719)– System audit policy was changed.
/event.aspx?eventid=4720)– A user account was created.
/event.aspx?eventid=4722)– A user account was enabled.
/event.aspx?eventid=4723)– An attempt was made to change an account’s password.
/event.aspx?eventid=4724)– An attempt was made to reset an account’s password.
/event.aspx?eventid=4725)– A user account was disabled.
/event.aspx?eventid=4726)– A user account was deleted.
/event.aspx?eventid=4727)– A security-enabled global group was created.
/event.aspx?eventid=4728)– A member was added to a security-enabled global group.
/event.aspx?eventid=4729)– A member was removed from a security-enabled global group.
/event.aspx?eventid=4730)– A security-enabled global group was deleted.
/event.aspx?eventid=4731)– A security-enabled local group was created.
/event.aspx?eventid=4732)– A member was added to a security-enabled local group.
/event.aspx?eventid=4733)– A member was removed from a security-enabled local group.
32 of 42 10/15/23, 16:40
/event.aspx?eventid=4734)– A security-enabled local group was deleted.
/event.aspx?eventid=4735)– A security-enabled local group was changed.
/event.aspx?eventid=4737)– A security-enabled global group was changed.
/event.aspx?eventid=4738)– A user account was changed.
/event.aspx?eventid=4739)– Domain Policy was changed.
/event.aspx?eventid=4740)– A user account was locked out.
/event.aspx?eventid=4741)– A computer account was created.
/event.aspx?eventid=4742)– A computer account was changed.
/event.aspx?eventid=4743)– A computer account was deleted.
/event.aspx?eventid=4754)– A security-enabled universal group was created.
/event.aspx?eventid=4755)– A security-enabled universal group was changed.
/event.aspx?eventid=4756)– A member was added to a security-enabled universal group.
/event.aspx?eventid=4757)– A member was removed from a security-enabled universal group.
/event.aspx?eventid=4758)– A security-enabled universal group was deleted.
/event.aspx?eventid=4759)– A security-disabled universal group was created.
/event.aspx?eventid=4760)– A security-disabled universal group was changed.
/event.aspx?eventid=4764)– A group’s type was changed.
/event.aspx?eventid=4765)– SID History was added to an account.
/event.aspx?eventid=4766)– An attempt to add SID History to an account failed.
/event.aspx?eventid=4767)– A user account was unlocked.
/event.aspx?eventid=4768)– A Kerberos authentication ticket (TGT) was requested
/event.aspx?eventid=4769)– A Kerberos service ticket was requested
/event.aspx?eventid=4770)– A Kerberos service ticket was renewed
/event.aspx?eventid=4771)– Kerberos pre-authentication failed
/event.aspx?eventid=4772)– Kerberos authentication ticket request failed
33 of 42 10/15/23, 16:40
/event.aspx?eventid=4774)– An account was mapped for logon.

/event.aspx?eventid=4775)– An account could not be mapped for logon.
/event.aspx?eventid=4776)– The domain controller attempted to validate the credentials for an
account
/event.aspx?eventid=4777)– The domain controller failed to validate the credentials for an account
/event.aspx?eventid=4780)– The ACL was set on accounts which are members of administrators
groups.
/event.aspx?eventid=4782)– The password hash for an account was accessed.
/event.aspx?eventid=4793)– The Password Policy Checking API was called.
/event.aspx?eventid=4794)– An attempt was made to set the Directory Services Restore Mode.
/event.aspx?eventid=4800)– The workstation was locked.
/event.aspx?eventid=4801)– The workstation was unlocked.
/event.aspx?eventid=4816)– RPC detected an integrity violation while decrypting an incoming
message.
/event.aspx?eventid=4817)– Auditing settings on an object were changed.
/event.aspx?eventid=4865)– A trusted forest information entry was added.
/event.aspx?eventid=4866)– A trusted forest information entry was removed.
/event.aspx?eventid=4867)– A trusted forest information entry was modified.
/event.aspx?eventid=4904)– An attempt was made to register a security event source.
/event.aspx?eventid=4905)– An attempt was made to unregister a security event source.
/event.aspx?eventid=4907)– Auditing settings on object were changed.
/event.aspx?eventid=4908)– Special Groups Logon table modified.
/event.aspx?eventid=4944)– The following policy was active when the Windows Firewall started.
/event.aspx?eventid=4964)– Special groups have been assigned to a new logon.
/event.aspx?eventid=5024)– The Windows Firewall Service has started successfully.
/event.aspx?eventid=5025)– The Windows Firewall Service has been stopped.
/event.aspx?eventid=5030)– The Windows Firewall Service failed to start.
34 of 42 10/15/23, 16:40
/event.aspx?eventid=5031)– The Windows Firewall Service blocked an application from accepting

incoming connections on the network.
/event.aspx?eventid=5033)– The Windows Firewall Driver has started successfully.
/event.aspx?eventid=5034)– The Windows Firewall Driver has been stopped.
/event.aspx?eventid=5035)– The Windows Firewall Driver failed to start.
/event.aspx?eventid=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.
/event.aspx?eventid=5148)– The Windows Filtering Platform has detected a DoS attack and entered
a defensive mode; packets associated with this attack will be discarded.
/event.aspx?eventid=5149)– The DoS attack has subsided and normal processing is being resumed.
/event.aspx?eventid=5150)– The Windows Filtering Platform blocked a packet.
/event.aspx?eventid=5151)– A more restrictive Windows Filtering Platform filter has blocked a
packet.
/event.aspx?eventid=5152)– The Windows Filtering Platform blocked a packet.
/event.aspx?eventid=5153)– A more restrictive Windows Filtering Platform filter has blocked a
packet.
/event.aspx?eventid=5154)– The Windows Filtering Platform has permitted an application or service
to listen on a port for incoming connections.
/event.aspx?eventid=5155)– The Windows Filtering Platform has blocked an application or service
from listening on a port for incoming connections.
/event.aspx?eventid=5168)– SPN check for SMB/SMB2 failed.
/event.aspx?eventid=5378)– The requested credentials delegation was disallowed by policy.
/event.aspx?eventid=6144)– Security policy in the group policy objects has been applied
successfully.
Expanded information on these events is available for download (DC-Events.xlsx (https://adsecurity.org/wp-

content/uploads/2016/11/DC-Events.xlsx) or DC-Events.csv (https://adsecurity.org/wp-content/uploads
/2016/11/DC-Events.csv)). The xlsx file includes hyperlinks.
Information in the csv/xlsx files includes:
• EventID
• Activity Logged
• Audit Category
• Auditing Subcategory
35 of 42 10/15/23, 16:40
• OS Support
• 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 (https://technet.microsoft.com/en-us/windows-server-docs/identity

/ad-ds/plan/security-best-practices/audit-policy-recommendations)
Key Domain Controller Security Items

• 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 (https://technet.microsoft.com/en-us/library
/dd391912(v=ws.10).aspx).
• 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
36 of 42 10/15/23, 16:40
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 (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 (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 (https://www.microsoft.com/en-
us/download/details.aspx?id=38815)
• From the “Best Practices for Securing Active Directory” document, Securing Domain Controllers:
/securing-domain-controllers-against-attack (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 (https://mva.microsoft.com/en-US/training-courses/defending-
active-directory-against-cyberattacks-16327?l=Gj8k5XsSC_2004300474)
• Recommended Auditing:
/audit-policy-recommendations (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/
(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/ (https://www.stigviewer.com
/stig/active_directory_domain/)
(Visited 199,491 times, 17 visits today)
•  31B2F340-016D-11D2-945F-00C04FB984F9 (https://adsecurity.org/?tag=31b2f340-016d-
11d2-945f-00c04fb984f9), 6AC1786C-016F-11D2-945F-00C04FB984F9 (https://adsecurity.org
/?tag=6ac1786c-016f-11d2-945f-00c04fb984f9), Active Directory Best Practices analyzer
37 of 42 10/15/23, 16:40
(https://adsecurity.org/?tag=active-directory-best-practices-analyzer), Active Directory Security

(https://adsecurity.org/?tag=active-directory-security), Active Directory security best practices
(https://adsecurity.org/?tag=active-directory-security-best-practices), Audit: Force audit policy
subcategory settings (https://adsecurity.org/?tag=audit-force-audit-policy-subcategory-settings),
Configuring Domain Controller Auditing (https://adsecurity.org/?tag=configuring-domain-
controller-auditing), Default Domain Controllers Policy (https://adsecurity.org/?tag=default-
domain-controllers-policy), Default Domain Policy GPO (https://adsecurity.org/?tag=default-
domain-policy-gpo), Domain Controller security (https://adsecurity.org/?tag=domain-controller-
security), domain password policy (https://adsecurity.org/?tag=domain-password-policy), Enable
LSA Protection (https://adsecurity.org/?tag=enable-lsa-protection), Enable NTLM Auditing
(https://adsecurity.org/?tag=enable-ntlm-auditing), Event Logs (https://adsecurity.org
/?tag=event-logs), Fine-Grained Password Policy (https://adsecurity.org/?tag=fine-grained-
password-policy), GPMC (https://adsecurity.org/?tag=gpmc), Group Policy Management
Console (https://adsecurity.org/?tag=group-policy-management-console), HKLM\SYSTEM
\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential
(https://adsecurity.org
/?tag=hklmsystemcurrentcontrolsetcontrolsecurityproviderswdigestuselogoncredential),
KB2871997 (https://adsecurity.org/?tag=kb2871997), Key Domain Controller Security Items
(https://adsecurity.org/?tag=key-domain-controller-security-items), LAN Manager authentication
level (https://adsecurity.org/?tag=lan-manager-authentication-level), LSA Protection
(https://adsecurity.org/?tag=lsa-protection), Lsass.exe audit mode (https://adsecurity.org
/?tag=lsass-exe-audit-mode), Microsoft domain controller auditing (https://adsecurity.org
/?tag=microsoft-domain-controller-auditing), Microsoft SCM Domain Controller Security
Compliance Policy (https://adsecurity.org/?tag=microsoft-scm-domain-controller-security-
compliance-policy), Microsoft SCM Domain Security Compliance Policy (https://adsecurity.org
/?tag=microsoft-scm-domain-security-compliance-policy), Microsoft Security Compliance
Manager (https://adsecurity.org/?tag=microsoft-security-compliance-manager), Minimum
password age (https://adsecurity.org/?tag=minimum-password-age), Patching Domain
Controllers (https://adsecurity.org/?tag=patching-domain-controllers), Protecting Domain
Controllers (https://adsecurity.org/?tag=protecting-domain-controllers), Recommended Group
Policy Settings (https://adsecurity.org/?tag=recommended-group-policy-settings), Require 128-
bit encryption (https://adsecurity.org/?tag=require-128-bit-encryption), Require NTLMv2 session
security (https://adsecurity.org/?tag=require-ntlmv2-session-security), Require strong (Windows
2000 or later) session key (https://adsecurity.org/?tag=require-strong-windows-2000-or-later-
session-key), SCM (https://adsecurity.org/?tag=scm), secure Active Directory
(https://adsecurity.org/?tag=secure-active-directory), Securing Active Directory
(https://adsecurity.org/?tag=securing-active-directory), Security Compliance
(https://adsecurity.org/?tag=security-compliance), Send NTLMv2 response only. Refuse LM &
NTLM (https://adsecurity.org/?tag=send-ntlmv2-response-only-refuse-lm-ntlm), SYSVOL
(https://adsecurity.org/?tag=sysvol), User Rights Assignments (https://adsecurity.org/?tag=user-
rights-assignments), WDigest Authentication (https://adsecurity.org/?tag=wdigest-
authentication), Windows Server 2012 R2 (https://adsecurity.org/?tag=windows-server-2012-r2),
Windows Server 2016 (https://adsecurity.org/?tag=windows-server-2016)
•
38 of 42 10/15/23, 16:40
(https://adsecurity.org/?author=2)
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
•  (mailto:sean@adsecurity.org)
 4 comments
Skip to comment form 
1.
◦ Oliver on November 4, 2016
◦ ◦ # (https://adsecurity.org/?p=3377#comment-11390)
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.
1.
▪ Sean Metcalf (https://ADSecurity.org) on November 4, 2016
▪ Author
▪ # (https://adsecurity.org/?p=3377#comment-11391)
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)
(https://technet.microsoft.com/en-us/library/dd772723(v=ws.10)).aspx
1.
▪ Oliver on November 4, 2016
▪ ▪ # (https://adsecurity.org/?p=3377#comment-11392)
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.
39 of 42 10/15/23, 16:40
Thanks!
2.
◦ vRico on November 9, 2016
◦ ◦ # (https://adsecurity.org/?p=3377#comment-11445)
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.
Recent Posts
• Attacking Active Directory Group Managed Service Accounts (GMSAs) (https://adsecurity.org
/?p=4367)
• From Azure AD to Active Directory (via Azure) – An Unanticipated Attack Path (https://adsecurity.org
/?p=4277)
• What is Azure Active Directory? (https://adsecurity.org/?p=4211)
• Slides Posted for Black Hat USA 2019 Talk: Attacking & Defending the Microsoft Cloud
(https://adsecurity.org/?p=4179)
• AD Reading: Windows Server 2019 Active Directory Features (https://adsecurity.org/?p=4187)
Trimarc Active Directory Security Services

Have concerns about your Active Directory environment? Trimarc helps enterprises improve their security
posture.
Find out how... (http://trimarcsecurity.com/security-services) TrimarcSecurity.com
Popular Posts
• Attack Methods for Gaining Domain Admin Rights in… (https://adsecurity.org/?p=2362)
• PowerShell Encoding & Decoding (Base64) (https://adsecurity.org/?p=478)
• Kerberos & KRBTGT: Active Directory’s… (https://adsecurity.org/?p=483)
• Finding Passwords in SYSVOL & Exploiting Group… (https://adsecurity.org/?p=2288)
• Securing Domain Controllers to Improve Active… (https://adsecurity.org/?p=3377)
• Securing Windows Workstations: Developing a Secure Baseline (https://adsecurity.org/?p=3299)
• Mimikatz DCSync Usage, Exploitation, and Detection (https://adsecurity.org/?p=1729)
• Detecting Kerberoasting Activity (https://adsecurity.org/?p=3458)
• Scanning for Active Directory Privileges &… (https://adsecurity.org/?p=3658)
• The Most Common Active Directory Security Issues and… (https://adsecurity.org/?p=1684)
Categories
• ActiveDirectorySecurity (https://adsecurity.org/?cat=565)
• Apple Security (https://adsecurity.org/?cat=55)
• Cloud Security (https://adsecurity.org/?cat=431)
• Continuing Education (https://adsecurity.org/?cat=17)
• Entertainment (https://adsecurity.org/?cat=396)
• Exploit (https://adsecurity.org/?cat=347)
40 of 42 10/15/23, 16:40
• Hacking (https://adsecurity.org/?cat=1039)
• Hardware Security (https://adsecurity.org/?cat=168)
• Hypervisor Security (https://adsecurity.org/?cat=172)
• Linux/Unix Security (https://adsecurity.org/?cat=126)
• Malware (https://adsecurity.org/?cat=343)
• Microsoft Security (https://adsecurity.org/?cat=11)
• Mitigation (https://adsecurity.org/?cat=819)
• Network/System Security (https://adsecurity.org/?cat=48)
• PowerShell (https://adsecurity.org/?cat=7)
• RealWorld (https://adsecurity.org/?cat=698)
• Security (https://adsecurity.org/?cat=21)
• Security Conference Presentation/Video (https://adsecurity.org/?cat=234)
• Security Recommendation (https://adsecurity.org/?cat=1045)
• Technical Article (https://adsecurity.org/?cat=24)
• Technical Reading (https://adsecurity.org/?cat=4)
• Technical Reference (https://adsecurity.org/?cat=2)
• TheCloud (https://adsecurity.org/?cat=156)
• Vulnerability (https://adsecurity.org/?cat=930)
Tags
ActiveDirectory (https://adsecurity.org
/?tag=activedirectory) Active Directory (https://adsecurity.org/?tag=active-directory)
ActiveDirectorySecurity
ActiveDirectoryAttack (https://adsecurity.org/?tag=activedirectoryattack)
(https://adsecurity.org/?tag=activedirectorysecurity) Active Directory Security

(https://adsecurity.org/?tag=active-directory-security) ADReading (https://adsecurity.org
/?tag=adreading) ADSecurity (https://adsecurity.org/?tag=adsecurity) AD Security (https://adsecurity.org
/?tag=ad-security) DCSync (https://adsecurity.org/?tag=dcsync) DEFCON (https://adsecurity.org/?tag=defcon)
DomainController (https://adsecurity.org/?tag=domaincontroller) EMET5
(https://adsecurity.org/?tag=emet5) GoldenTicket (https://adsecurity.org/?tag=goldenticket) HyperV
(https://adsecurity.org/?tag=hyperv) Invoke-Mimikatz (https://adsecurity.org/?tag=invoke-mimikatz) KB3011780
(https://adsecurity.org/?tag=kb3011780) KDC (https://adsecurity.org/?tag=kdc) Kerberos
(https://adsecurity.org/?tag=kerberos) KerberosHacking (https://adsecurity.org

/?tag=kerberoshacking) KRBTGT (https://adsecurity.org/?tag=krbtgt) LAPS (https://adsecurity.org/?tag=laps)
LSASS (https://adsecurity.org/?tag=lsass) MCM (https://adsecurity.org/?tag=mcm)
MicrosoftEMET (https://adsecurity.org/?tag=microsoftemet) MicrosoftWindows (https://adsecurity.org
/?tag=microsoftwindows) mimikatz (https://adsecurity.org/?tag=mimikatz)

MS14068 (https://adsecurity.org/?tag=ms14068) PassTheHash (https://adsecurity.org/?tag=passthehash)
PowerShell (https://adsecurity.org/?tag=powershell)
PowerShellCode (https://adsecurity.org/?tag=powershellcode) PowerShellHacking
(https://adsecurity.org/?tag=powershellhacking) PowerShellv5 (https://adsecurity.org/?tag=powershellv5) PowerSploit
(https://adsecurity.org/?tag=powersploit) Presentation (https://adsecurity.org/?tag=presentation) Security
(https://adsecurity.org/?tag=security) SIDHistory (https://adsecurity.org/?tag=sidhistory) SilverTicket (https://adsecurity.org
41 of 42 10/15/23, 16:40
/?tag=silverticket) SneakyADPersistence (https://adsecurity.org/?tag=sneakyadpersistence) SPN (https://adsecurity.org

/?tag=spn) TGS (https://adsecurity.org/?tag=tgs) TGT (https://adsecurity.org/?tag=tgt) Windows10
(https://adsecurity.org/?tag=windows10) WindowsServer2008R2 (https://adsecurity.org/?tag=windowsserver2008r2)
WindowsServer2012 (https://adsecurity.org/?tag=windowsserver2012) WindowsServer2012R2
(https://adsecurity.org/?tag=windowsserver2012r2)
Copyright
Content Disclaimer: This blog and its contents are provided "AS IS" with no warranties, and they confer no
rights. Script samples are provided for informational purposes only and no guarantee is provided as to
functionality or suitability. The views shared on this blog reflect those of the authors and do not represent
the views of any companies mentioned. Content Ownership: All content posted here is intellectual work and
under the current law, the poster owns the copyright of the article. Terms of Use Copyright © 2011 - 2020.
Content Disclaimer: This blog and its contents are provided "AS IS" with no warranties, and they confer no
rights. Script samples are provided for informational purposes only and no guarantee is provided as to
functionality or suitability. The views shared on this blog reflect those of the authors and do not represent the
views of any companies mentioned.
Made with  by Graphene Themes (https://www.graphene-theme.com/).
42 of 42 10/15/23, 16:40

Securing Domain Controllers To Improve Active Directory Security - Active Directory Security

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Securing Domain Controllers To Improve Active Directory Security - Active Directory Security

Uploaded by

Copyright:

Available Formats

Securing Domain Controllers to Improve Active Direct... https://adsecurity.org/?

 Securing Windows Workstations: Developing a Secure Baseline (https://adsecurity.org/?p=3299)

• Default Domain & Domain Controller Policies

Default Domain & Domain Controller Group Policies (GPOs)

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

• User Rights Assignment

Creating Domain & Domain Controller Security Baseline GPOs

• Enforce Password History: 24 (the default is fine)

• Minimum Password Length: 14

• Baseline Domain Security Policy

Microsoft SCM Domain Security Compliance Policy

Microsoft SCM Domain Controller Security Compliance Policy

• DoD STIG: http://iase.disa.mil/stigs/os/windows (http://iase.disa.mil/stigs/os/windows)

Patching Domain Controllers

Protecting Domain Controllers

Windows Server 2008 R2 Domain Functional Level:

• Kerberos AES encryption support (http://blogs.msdn.com/b/openspecification/archive/2011/05

Windows Server 2012 Domain Functional Level:

• Group Managed Service Accounts (https://technet.microsoft.com/en-us/library/hh831782.aspx)

◦ Combines user and device authentication

Windows Server 2012 R2 Domain Functional Level:

• Authentication Policies & Silos (https://technet.microsoft.com/en-us/library/dn486813.aspx)

Windows Server 2016 New Security Features (https://technet.microsoft.com/windows-server-

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

• Logon as a batch job: Not Defined

Domain Controller Recommended Group Policy Settings

Enable NTLM Auditing

This policy setting allows you to audit incoming NTLM traffic.

This policy setting allows you to audit NTLM authentication in

LAN Manager (LM) is a family of early Microsoft client/server

LAN Manager authentication includes the LM, NTLM, and

The possible values for the Network security: LAN Manager

The Network security: LAN Manager authentication level

These settings correspond to the levels discussed in other

• Level 5 – Domain controllers refuse LM and NTLM responses (accept only

Lsass.exe audit mode: Enabled

You can configure this setting to enable the auditing of

If you enable this setting, Lsass.exe audit mode is enabled

Enable LSA Protection: Enabled

Use this setting to configure additional protection for the Local

On x86-based or x64-based devices that use Secure Boot and

Session keys that are used to establish secure channel

When this policy setting is enabled, a secure channel can only

The default setting is “No Minimum”.

This policy setting determines which behaviors are allowed for

The possible values for the Network security: Minimum

The default setting is “No Minimum”.

This policy setting determines which behaviors are allowed for

The possible values for the Network security: Minimum

Session hijacking uses tools that allow attackers who have

This policy setting determines if the server side SMB service

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

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

Session hijacking uses tools that allow attackers who have

This policy setting determines whether packet signing is

The default setting is “Disabled”.

An unauthorized user could anonymously list account names

This policy setting controls the ability of anonymous users to

WDigest Authentication (disabling may require KB2871997): Disabled

WDigest leaves user’s plaintext-equivalent passwords in

When WDigest authentication is enabled, Lsass.exe retains a

Configuring Domain Controller Auditing (Event Logs)