For organizations that use Active Directory (AD), securing domain controllers (DCs) is an essential part of AD security. DCs are critical components of the IT infrastructure. These servers hold sensitive and security-related data, including user account information, authentication credentials, and Group Policy objects (GPOs). Naturally, then, DC security is an important part of both AD security and your organization’s entire cybersecurity strategy.

What makes a server a domain controller?

To create a Windows server a DC, you install the Active Directory Domain Services (AD DS) role on the server. You then promote the server from within Server Manager.

When you promote the server, many of its original settings change. For example, only members of the Administrators group in AD are allowed to log on to the DC locally or via Remote Desktop Protocol (RDP).

Unlike a non-DC Windows server, a DC does not use local users and groups. Rather, the DC uses only AD-based users and groups. However, by default, members of the Domain Admins group in AD are also members of the Administrators group. Therefore, any account that is a member of the Domain Admins group has the right to log on locally and via RDP to any DC in the organization. 

For security reasons, Microsoft recommends against installing the AD DS role and the Remote Desktop Service (RDS), or terminal server, role on the same server.

Who can access domain controllers?

You can grant DC logon rights to users or groups by modifying the default Domain Controllers GPO in AD or by creating and applying a GPO to the Domain Controllers organizational unit (OU). However, you should restrict these rights to only users or groups that require them.

Avoid granting logon rights to standard user accounts. Although situations might exist in which non-administrator users need to log on to a DC, such permissions can increase the risk of unauthorized access and potential security breaches.

All DCs are members of the Domain Controllers OU by default. Therefore, changes to GPOs that link to that OU affect all the DCs in the OU. Granting a standard user account rights to the OU can essentially enable that user to access all DCs in the organization—not a good idea from a security perspective.

Larger organizations often create dedicated roles for users who need to perform maintenance or upgrades to applications that run on DCs. In smaller organizations or branch offices where dedicated roles are unavailable, the temptation to allow non-administrator users access to DCs might be greater. Resist it!

The danger of DC misconfiguration

As the number of DCs increases and IT and security team members change over time, the risk of misconfigurations and security vulnerabilities also increases. In some cases, this configuration creep might go unnoticed or disregarded, leaving DCs vulnerable to security breaches.

Therefore, it’s important to implement appropriate security controls. Limit DC access to those users who require it to perform their duties. Doing so can help to reduce the risk of unauthorized access and potential security breaches and strengthen the security and integrity of your organization’s IT systems and data.

Domain controller security threats

There’s a term for what happens when an attacker gains access to any DC in your organization: game over.

By compromising a DC, attackers can gain access to the sensitive information on that DC. They might also gain access to other systems and data within your organization. Threat actors with DC access can potentially:

Steal sensitive information such as user credentials, enabling them to access other systems and data within the organization and perform lateral movement.

Create new user accounts with administrative privileges, giving them greater control over the organization’s IT systems and data.

Elevate privileges, enabling them to bypass security controls and gain access to sensitive data.

Spread malware or viruses to other systems within the organization.

Disrupt operations by deleting or modifying critical data, shutting down systems, or creating denial-of-service (DoS) attacks.

How to improve domain controller security

To remediate and reduce the potential risk to DC security, perform the following actions:

Verify that Tier 1 objects, such as the Domain Admins group in AD, contain only relevant and necessary user objects.

Determine which GPOs are linked to the Domain Controllers OU in AD.

For each linked GPO:

Open Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment.

Go to the GPO section.

Confirm that only the Administrators group (Domain Admins) has the Allow Log On Through Remote Desktop Services right.

Confirm that only the Administrators group (Domain Admins) has the Allow Log On Locally right.

Continuously assess domain controller security

In addition to the previous steps, be sure to closely monitor your event logs for both failed and successful logons to all your DCs. But don’t stop there.

You can use free community tools such as Purple Knight and Forest Druid to continually assess your AD security posture. And learn more about AD security and best practices such as least privilege and Zero Trust through the other posts in our AD Security 101 series.

Learn more about domain controller security and AD security

AD Security 101: AD Monitoring for Malicious Changes

Why DC Snapshots Are No Substitute for Active Directory Backups

How Attackers Can Use Active Directory Primary Group Membership for Defense Evasion

The post AD Security 101: Domain Controller Security appeared first on Semperis.