You've probably seen recommendations from multiple sources, security experts, security seminars, perhaps an internal audit or three, to restrict Remote Desktop access to domain controllers. They're right - your domain controllers are a critical component of your infrastructure, so securing access to them is very important. Even if you're running Core, you may have RDP enabled, so this may still apply to you. The standard methods of allowing or denying RDP access (User rights assignment, etc.) lack flexibility, potentially allowing authorized accounts to connect from unauthorized computers, exposing those accounts to credential theft. Please note that there are many ways of accessing domain controllers remotely - this article only addresses RDP, but the same fundamental concept may be applied to other network access methods.

Fundamentally, securing RDP access to DCs is about ensuring the right computers and individuals have access to them via Remote Desktop while others do not.

This process configures your domain controllers to only accept RDP connection requests from computers in specific AD groups by leveraging IPSec for authentication, Windows Firewall with Advanced Security (WFAS) for enforcement, and Group Policy for deployment. Please note that users still need to have permissions to log in to RDP – this process only allows access to the RDP port (TCP 3389) from specific computers, denying access to any that aren't a member of the permitted group.

This process will work for any version of Windows Server 2008 and newer, but this lab uses all Windows 10 Enterprise & Windows Server 2016 Datacenter, which you can download and try for yourself for 180 days.

Lab layout:

Step 1. is ensuring you've identified the users that need access to the domain controllers via RDP.

But do they really need RDP? Users do not need to use RDP to log in to domain controllers if:

They need to run AD administrative tools

RSAT tools can be installed on nearly any workstation or jump box, and access the domain controllers remotely over RPC

>Active Directory Users & Computers (ADUC)

>Active Directory Sites & Services (ADSS)

>Active Directory Administrative Center (ADAC)

>Group Policy Management Console (GPMC)

>Etc.

They need to run Tool X on the domain controllers - many Tool Xs support native remoting:

Event Viewer

Computer Management

Shutdown or reboot the computer

>Shutdown /r /f /t 1 /m dc1.foo.com.internal

Registry Editor

Etc.

They need to run PowerShell scripts or commands against AD or the DCs themselves

ADWS (Active Directory Web Services) allows for remoted cmdlets and execution via the -server, -computername etc. parameters from other computers across the network

>Get-aduser -filter {samaccountname -eq "administrator"} -server foo.com.internal

>ADWS uses TCP 9389 over the network by default

WinRM (Windows Remote Management) allows for remote sessions via enter-pssession, invoke-command etc.

>Enter-pssession -computername dc1.foo.com.internal

>Invoke-command -computername dc1.foo.com.internal -scriptblock { <insert command here> }

>WinRM uses TCP 5985 over the network by default

If your environment includes force multipliers like the System Center ecosystem of products (SCCM, SCOM etc.) then the pool of available remote options increases greatly. That's a topic for a different discussion.

There are some cases where local access to the domain controller is desired or required:

Disaster recovery

DSRM

Hung server

Upgrade the OS

Reconfigure the bios

Troubleshoot hardware

Tool Y that can't be executed remotely and (for some reason) is installed on the domain controllers

>I'd suggest moving Tool Y to a member server as soon as possible, unless Tool Y absolutely requires running on a domain controller

A good way to approach the issue is to only grant your Domain Admins - those that are tasked with making AD chug along on a daily basis - access to the computers that have access to domain controllers via RDP. This means several things:

Your Domain Admins need hardware/virtualization chops as well as AD skillz

>They also need to be aware they hold these responsibilities

Need to have a well defined escalation path and process so everyone knows that if a domain controllers starts lighting up in your monitoring tools, everyone knows the team to whom to escalate

>This escalation path can include other teams for specific functionality, leveraging remote tools that do not require RDP access but fit in to their teams' responsibilities

Need to have the appropriate tooling to ensure all teams can do their part, including the Domain Admins

>This dovetails nicely with the idea of privilege separation/tiered access

After identifying the users that should be granted access, we then need to identify the computers that need to access your domain controllers. These are the computers that the users you identified previously will use to access domain controllers via RDP. Good candidates are well-secured jump hosts, bastion hosts, etc., access to which is limited to the users identified in step 1. If you've implemented the concept of Privileged Admin Workstations, they can be candidates as well, and this is the concept I used for this blog. The keys to determining if a class of machines would suffice are:

Well-secured Closely monitored Limited accessibility

Finally, once you've identified your pool of users & computers, and have created/identified AD groups appropriately, configure IPSec-based authorization for firewall rules between the computers identified in previously and your domain controllers via Group Policy.

Before we begin our configuration process, note that both the regular workstation (w10ws01.internal.lab) and the Privileged Admin Workstation (w10paw01.internal.lab) can connect to the domain controller for internal.lab on RDP (TCP 3389)

Step 2. Configure an IPSec rule in a GPO that applies to the machines that need to RDP to the domain controllers (PAW etc.)

a. Use a new GPO explicitly for Firewall/IPSec purposes, if possible. Mine is named "PAW Firewall Policy"

i. Gives you easy ability to rejigger or remove IPSec at the client level

b. Open the new GPO and expand out Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security

i. Ensure local firewall rules are not applied for all profiles

1. Right click on Windows Firewall with Advanced Security and select Properties

2. On the Domain Profile tab, select the Customize box under Settings

3. Set "Apply local firewall rules" and "Apply local connection security rules" to "No"

4. Repeat for the other profiles

5. Click OK

ii. Expand out Windows Firewall with Advanced Security and click Connection Security Rules

iii. Right click in the window on the right side and select New Rule

iv. In the New Connection Security Rule Wizard, choose Custom and hit Next

v. Endpoint 1 is local

1. Leave as any

vi. Endpoint 2 is remote

1. Specify the IP addresses of your domain controllers

a. This can be done with individual addresses, or a range. The "Predefined set of computers" choice doesn't have enough flexibility to include just your domain controllers.

2. Hit Next when you've added your domain controllers

vii. Select "Require authentication for inbound and outbound…"

1. This ensures your IPSec connections are mutually authenticated

2. Hit Next

viii. For the Authentication Method, choose "Computer"

1. "Computer and user" sounds good, but there are issues with attempting to validate these network access requests with both a user group as well as a computer group. I’ll explain in a bit more detail in the firewall rule section below.

2. Hit Next

ix. On the Protocols and Ports page, configure the following

1. Protocol: TCP

2. Endpoint 1 (remember, this is the machine to which this GPO applies:) All ports

3. Endpoint 2 (this is the remote side of the connection:) Select "Specific Ports and configure 3389

4. Click Next

x. Click Next to leave all profiles checked

vi. Give the rule a meaningful name - I chose "PAW to DC RDP Kerberos". Also include a description to help any engineers that follow in your footsteps to understand what the rule is doing

Step 3. Configure an IPSec rule in the GPO that applies Windows Firewall rules to domain controllers.

You do use GPO to ensure your domain controllers have a consistent firewall rule set, right? ;)

a. Use a new GPO explicitly for firewall & IPSec purposes, rather than reusing the Default Domain Controllers GPO

i. Gives you easy ability to rejigger/remove IPSec at the domain controller level

ii. My GPO is named “Domain Controllers Firewall Policy.” I'm so creative, I know.

b. Configure this rule the same as the one configured for the PAW GPO, with a few important differences:

i. On the Endpoints page, leave "Any IP Address" selected for both Endpoint 1 and Endpoint 2

1. This means any attempt to contact your domain controllers on TCP 3389 will have to be authenticated via IPSec

ii. On the Protocols and Ports page, set Endpoint 1 to "Specific Ports" and "3389" and leave Endpoint 2 as "All Ports"

Step 4. Open the GPO that applies your Windows Firewall configuration to your domain controllers and create an inbound firewall rule on it that allows RDP to a domain controller only if it is secured via IPSec and if the computer making the connection is in an appropriate AD group

a. Open the appropriate DC GPO, “Domain Controllers Firewall Policy” in my example

b. Verify local firewall rules are not applied same as in step 2bi.

c. Create an inbound permit firewall rule for local port TCP 3389 on the domain controller GPO noted in step 3a. above

d. Choose Custom, then hit Next twice

e. On the Protocols and Ports page, set the following

1. Protocol type: TCP

2. Local port: Specific Ports

3. 3389

4. Remote port: All Ports

5. Hit Next on Scope

f. On the Action page, select "Allow the connection if it is secure"

1. Choose the first option "Allow the connection if it is authenticated and integrity protected"

g. RDP is already encrypted, so "Require the connections to be encrypted" is superfluous. MOAR security isn't necessarily bad, but it may adversely affect performance of the connections

h. Click Next on Users

i. *NOTE* If this firewall rule is configured with both a Users group as well as a Computers group, Windows Firewall will allow the connection if either is true. This means an approved user that logs in from an unapproved workstation will still be allowed access to TCP 3389 on the domain controller, as long as IPSec authentication occurs and an appropriate Security Association (SA) is established. Because we’re exclusively using a computer group, we skip this step.

j. On the Computers page, grant permission to the relevant AD group of computers that will be accessing the domain controllers

k. Click Next on Profile to keep it applied to all network profiles

l. Give the firewall rule an appropriate name and description

m. Note that the icon on the far left is a little closed lock instead of a checkmark - this indicates the rule requires connection security (IPSec)

n. Remove or disable all other RDP access rules

o. GPUpdate on all computers to which the above GPOs apply, or wait for the natural GP update cycle to complete - 90 minutes +- 30, so between 1 and 2 hours, and 5 minutes for the domain controllers.

On both the PAW and the DC, you can open WFAS, expand Monitoring and select Connection Security Rules to ensure the relevant connection security rule is active. To see if IPSec sessions are being established, expand Security Associations and click on the Main Mode box. Please note that you'll only see active associations after you've attempted to connect to the DC on TCP 3389.

After group policy successfully applies, only computers that are in the groups identified in step 4j and that can successfully establish an IPSec security association with the domain controllers will be able to access DCs via RDP. Even telnetting to TCP 3389 will fail if both of these conditions have not been met. This also means that many of your monitoring systems may be lighting up, if they were monitoring your DCs for RDP availability - hope you notified your monitoring teams!

There are other variations on this theme. Let me know how it goes for you!