Secure Active Directory Access Over The Internet.

It works as Kerberos. From the operating system’s point of view the domain controller is simply reachable at its usual address on a routable path, so the normal Kerberos exchange happens: the client locates the KDC through DNS SRV records, requests a ticket-granting ticket, and presents service tickets as usual. The overlay is transport. It does not proxy or terminate the authentication, which is precisely why you do not have to re-architect anything above it.

Same answer: they are ordinary traffic on a reachable path. DNS matters most — the client must resolve your internal domain and its SRV records rather than a public resolver, so DNS is part of the design conversation in every deployment. Time skew is the other classic Kerberos failure, so domain-joined machines need to keep syncing against your domain time source, not a random public NTP pool.

Replication between domain controllers is unchanged. What changes is that the path between them is the encrypted fabric instead of a site-to-site VPN. AD Sites and Services still needs to reflect reality: your site link costs and subnet-to-site mappings should describe the topology you actually have, so clients pick a sensible domain controller and replication schedules stay appropriate. Getting that mapping wrong is the most common cause of odd behaviour, and it is on the readiness-review checklist for that reason.

The same thing that happens today with a site-to-site VPN. If the branch has no local domain controller, remote directory resources become unreachable and users fall back to cached credentials for local logon. If the branch has its own domain controller or an RODC, local authentication continues normally and replication catches up when the link returns. This is a property of your branch design rather than of the overlay, and it is worth deciding deliberately rather than discovering during an outage.

Yes, and for a plant or warehouse that cannot tolerate an internet-dependent logon, you should. An RODC at the branch gives you local authentication and a smaller blast radius if the site is physically compromised, while the fabric carries replication and management traffic back to head office. The two approaches are complementary, not alternatives.

Yes, because the control plane is self-hosted. In an environment with no internet egress, the control plane and the nodes operate within your own network boundary and there is no vendor-cloud dependency for day-to-day operation. This is the configuration plants, labs, and public-sector estates usually need, and it is the reason self-hosting is the default rather than an enterprise upsell.

You do. The control plane runs on your infrastructure, so key material lives inside your estate rather than with a vendor. There is no arrangement in which Computer Port needs to hold your keys in order for the platform to function.

Administrative audit trails, session logs, and configuration change history are written on your infrastructure and stay there, which is the part auditors usually care about most. That supports CERT-In, ISO, and DPDP evidence requests, but no product turns compliance into a checkbox — your retention periods, incident-reporting process, and who reviews the logs are still organisational decisions. We will tell you what the platform produces and you map it to your obligations.

The design is peer-to-peer with NAT traversal, so the common case is a direct path between the two nodes rather than a round trip through a central gateway. That is the main performance argument against a VPN concentrator, where every branch conversation is dragged through head office. Where a particular NAT combination prevents a direct path, connectivity is maintained rather than dropped — that trade-off is worth understanding for your specific topology, and it is part of the overlay design step.

Those are overlay networks, and if an overlay is all you need they are reasonable tools. ControlIT is an overlay plus the directory work that makes on-prem Active Directory function across it, plus identity with SSO and enforced MFA, plus endpoint operations — on one self-hosted control plane with Indian engineering support behind it. If your question is purely "how do I get a WireGuard-class mesh up", this is more product than you need. If your question is "how does my domain keep working for people who are not in the building", it is the right shape.

Somewhere to run the control plane, outbound internet access from the endpoints, an AD administrator available for a few hours, and a decision on which sites go first. No inbound firewall rules, no schema changes, no new forest or domain, and no trust relationships.