Small Office VPN: Keep It Off the Domain Controller

Three conditions decide whether the office's only Windows server should also terminate the VPN: how much internet-facing software you are willing to run on the directory, whether you can authenticate remote users without that role, and what happens to your management access when the host reboots. If any of the three has a bad answer, separate the roles. The office being small changes the budget, not the risk.

A domain controller is trusted by every machine in the domain; a VPN gateway is reachable by anyone on the internet. That asymmetry is the whole argument.

Two Jobs With Two Different Exposure Profiles

The gateway accepts connections from outside, so its listener, its TLS stack and its authentication surface are all reachable from untrusted networks. The directory holds an authority other machines trust, which is why Microsoft's hardening guidance treats the domain-controller role and its hosting environment as especially sensitive. Every service added to that host inherits the directory's trust position while adding its own attack surface. Convenience of installation is not a trust boundary.

Separating the roles does not remove the dependencies. Remote users still need authentication, routes, DNS and access rules, and a gateway that skips them is not more secure, only less useful.

Authentication Without the Directory Role

A gateway can validate credentials through a supported external integration without hosting the directory itself. Whatever that integration is, give it an account whose rights match the purpose: reading the attributes needed to authenticate, nothing more. Admitting VPN users never requires making their ordinary accounts domain administrators, and it never requires the gateway to hold a copy of the directory.

Then scope the network paths the remote client actually needs. Access to one internal file service, plus the name resolution and identity services that workflow depends on, is a defined set of paths. It is not a reason to allow every domain-controller port or every administrative interface from the VPN pool.

One Host Is Still One Failure Domain

Two guests on one hypervisor separate their operating-system configuration and do not separate their fate. The hypervisor's administrators, virtual switching, storage and backups remain part of the design, and a host reboot removes both services at once. Calling that high availability because the diagram shows two VMs is a common and expensive mistake. If the only route back in runs through the VPN on that host, a failure takes away the connection needed to repair it.

So plan an independent management path that does not depend on the tunnel, and write down what stays available during maintenance. Schedule gateway updates and directory maintenance separately, noting which users or applications each interruption touches.

A maintenance window that requires the VPN to be up in order to fix the VPN is not a maintenance window.

Move It Without Locking Yourself Out

If the roles already share one installation, avoid a hurried remote migration. Inventory what the gateway owns today: addresses, forwarding rules, NAT, DNS settings, authentication configuration and any published services. Prepare both the replacement and a way back before you move the listener or alter a default route. Then test an ordinary remote user's real work through the new boundary, and confirm that unnecessary administrative access still fails.

The goal is not a prettier diagram. It is the ability to repair or rebuild the VPN without touching the box that anchors directory trust for the whole office. Those are different objectives, and only one of them needs a second server.

Record the decision either way, including the conditions that would reopen it. A small office grows, and the answer that fitted one server may not fit the next.