Connect Your Local Machine to AWS Simple AD (Windows): A Complete Guide

Introduction

This guide demonstrates how to establish secure, private access from a laptop to resources in an AWS VPC that are protected by a Simple Active Directory (SAD) and Windows Server. The primary path uses AWS Client VPN with Directory Service authentication. An appendix shows how to achieve the same using Pritunl.

What you’ll build

• A Virtual Private Cloud (VPC) with public and private subnets, an Internet Gateway (IGW), and a NAT Gateway.
• AWS Directory Service – Simple AD (managed LDAP + DNS) in private subnets.
• A Windows EC2 instance in a private subnet reachable only over VPN.
• An AWS Client VPN endpoint integrated with Simple AD for user authentication.
• (Optional) A Pritunl VPN server as a self‑hosted alternative.

Reference Architecture

Prerequisites

• AWS account with permissions for VPC, Amazon EC2, Directory Service, and ACM.
• A workstation with an RDP client and (optionally) the AWS CLI.
• A single AWS Region chosen—keep all resources in that same Region.

Tip: If you already have a VPC and NAT, you can reuse them.

Part A — Network Setup (from scratch)

1. Create a VPC

• CIDR: 10.0.0.0/16.

2. Create subnets

• Public: 10.0.10.0/24 (AZ‑A)
• Private‑A: 10.0.1.0/24 (AZ‑A)
• Private‑B: 10.0.2.0/24 (AZ‑B)

3. Internet Gateway (IGW)

• Create and attach it to the VPC.

4. NAT Gateway

• Allocate an Elastic IP.
• Create the NAT Gateway in the public subnet.

5. Route tables

• Public RT → add 0.0.0.0/0 → IGW; associate the public subnet.
• Private RT → add 0.0.0.0/0 → NAT GW; associate the private subnets.

6. Baseline security groups (SGs)

• sg-windows (for Windows EC2): allow RDP 3389 from the Client VPN CIDR (set later). Allow other internal ports as needed.
• sg-client-vpn-endpoint: allow inbound from VPN clients (AWS maps this) and outbound to the VPC.

Public vs. private subnets are defined by routes: public subnets have a default route to an IGW; private subnets do not.

Part B — Directory Service (Simple AD)

1. Create Simple AD

• Directory name (example): corp.local.
• Choose the VPC and two private subnets in different AZs.
• After creation, record the two Simple AD DNS IPs (e.g., 10.0.1.50, 10.0.2.50). These resolve corp.local and host LDAP.

2. NACL/RT notes

• Default NACLs (allow/allow) are fine for most cases.
• Ensure the private route table has a path to the internet via NAT if Simple AD requires outbound updates.

Part C — Windows EC2 (private subnet)

1 . Launch the instance

• AMI: Windows Server.
• Subnet: 10.0.1.0/24 (Private‑A).
• SG: sg-windows.
• No public IP.
• Optional IAM role: AmazonSSMManagedInstanceCore for Session Manager access.

2. Join to Simple AD

• After VPN and DNS are in place, join the instance to corp.local, or simply rely on Simple AD for VPN user authentication.

With Simple AD, AWS operates the domain controllers. Your Windows instance is a member server, not a DC. In the windows instance, to join the instance to corp.local go to:

Control panel -> Network and Internet -> Network and Sharing Center -> ethernet -> properties -> Internet Protocol Version 4(TCP/IPv4) -> properties -> use the following DNS server addresses.

Here, add the DNS address of Simple AD. 

Part D — Certificates for AWS Client VPN

You need a server certificate in ACM to create the Client VPN endpoint.

Option 1 — Self‑signed (EasyRSA)

Generate locally, then import to ACM (in the same Region as the VPN):

# On Linux/macOS

git clone https://github.com/OpenVPN/easy-rsa.git

cd easy-rsa/easyrsa3

./easyrsa init-pki

./easyrsa build-ca nopass

./easyrsa build-server-full server nopass

# Import to ACM:
#  Certificate body  → pki/issued/server.crt
#  Private key       → pki/private/server.key
#  Certificate chain → pki/ca.crt

For AWS Client VPN, the server certificate does not need a public DNS name; a generic CN like server is sufficient for console selection.

Option 2 — ACM Private CA (recommended for enterprises)

Issue the server certificate from a private CA; it’s already in ACM and easier to manage/rotate.

Part E — Create the AWS Client VPN Endpoint

1. Create endpoint (VPC → Client VPN Endpoints → Create)

• Client IPv4 CIDR: e.g., 10.250.0.0/22 (must not overlap the VPC CIDR).
• Server certificate: pick the ACM cert you imported/issued.
• Authentication: user‑based → Directory Service → select your Simple AD.
• Connection logging: optional (CloudWatch Logs).
• DNS servers: enter your Simple AD DNS IPs (from Part B). This ensures corp.local resolves on clients.
• Security group: attach sg-client-vpn-endpoint (you can refine later).

2. Associate a subnet

• On Associations → Associate subnet → choose any VPC subnet (public is common). This provides a path from the endpoint into the VPC.

3. Add routes

a) On Routes → Add route:

• Destination: your VPC CIDR (e.g., 10.0.0.0/16).
• Target: the associated subnet.

4. Authorization rules

• Allow access to 10.0.0.0/16 for all users or a specific AD group.

The endpoint should reach Available. If it’s stuck in pending-associate, you likely missed the Associate subnet step.

Part F — Client Setup & Testing

1. Download the client configuration from the endpoint (Client configuration tab).
2. Install the AWS VPN Client (or another OpenVPN client) on your laptop.
3. Import the configuration and connect with your AD credentials.

Verify

• ipconfig/ifconfig: you should receive an IP from 10.250.0.0/22.
• nslookup corp.local: should resolve via the Simple AD DNS servers configured on the endpoint.
• RDP to the Windows private IP (e.g., 10.0.1.119).
• (Optional) Join a Windows workstation to the corp.local domain while connected.

Security Groups — Practical Rules

1. Windows EC2

• Inbound: RDP 3389 from the Client VPN CIDR (e.g., 10.250.0.0/22).
• Inbound: other ports (DNS/LDAP/etc.) only if required by your apps.
• Outbound: allow all, or restrict as policy dictates.

2. Client VPN Endpoint 

• Inbound: from VPN clients (AWS handles mapping to this SG).
• Outbound: to the VPC CIDR.

For tighter security, allow only the exact application ports from the Client VPN CIDR to target instances.

Troubleshooting (real‑world)

• RDP times out → Check SGs (3389 from Client VPN CIDR), NACLs (allow/allow), Windows Firewall, and that the instance has no dependency on a public egress path.
• VPN connects, but names don’t resolve → Ensure the endpoint’s DNS servers are the Simple AD DNS IPs. On Windows, run ipconfig /flushdns after reconnecting. On Linux with systemd‑resolved, the local stub (127.0.0.53) may persist until reconnect.
• Certificate not visible when creating the endpoint → Confirm ACM Region matches the endpoint Region and that you imported the full cert + key + chain.
• You haven’t associated a subnet yet.
• Windows can’t reach the internet → Private route table must have 0.0.0.0/0 → NAT GW for updates, activation, etc.

Cost Considerations (ballpark)

• Client VPN: hourly per endpoint + per‑connection pricing.
• Simple AD: hourly pricing (AWS runs two DCs).
• NAT Gateway: hourly + per‑GB processed.
• Windows EC2: instance hours + Elastic Block Storage Costs.

Use Savings Plans/Graviton where possible and shut down test environments when idle.

Optional — Pritunl (Self‑Hosted Alternative)

Choose this if you want more control or to avoid Client VPN costs. 

Configure in the web UI

• Open https://<EC2-Elastic-IP> (allow 443 from your admin IP).
• Run sudo pritunl setup-key on the server and paste the key.
• Create an Organization and a User.
• Create a Server (UDP 1194 or TCP 443). Set DNS Server = Simple AD DNS IPs.
• Add Route: 10.0.0.0/16 with NAT enabled to simplify return traffic.
• Attach the Organization to the Server and Start the server.
• Export the user profile (.ovpn) and connect from your laptop.

EC2 security group for Pritunl

• Inbound: 1194/udp (or your chosen port) from client IP ranges; 443/tcp from admin IPs.
• Outbound: to the VPC CIDR.

For whole‑VPC access, ensure the route covers 10.0.0.0/16 and that target instance SGs allow traffic from the VPN subnet (or from the Pritunl server if NAT is enabled).

Quick Validation Checklist

• Client receives IP from the Client VPN CIDR.
• nslookup corp.local resolves via Simple AD DNS.
• RDP to Windows private IP works while connected; fails when disconnected (desired isolation).
• Authorization rules limit access to intended subnets/ports only.