MachineLAP-4471
LocationA home address, 2,140 km out
NetworkDomestic Wi-Fi
Corporate networkNever seen it
UserHas not logged in yet
Domain joining
It has never seen your network. Domain-joined anyway.
Domain-joined Windows devices are the ones IT can actually govern. Remote work broke the assumption underneath: that joining a domain meant being on the corporate network. We put the domain within reach of the device instead of the device within reach of the domain.
No office visitThe laptop is joined wherever it was delivered.
No VPNNo concentrator to publish and no subnet to land on.
The controller is never exposedIt stays on the private network, reached through the gateway.
Works before the user logs inThe machine has an identity of its own to present.
The directory stays where it is. The reach is what changes.
What is remote domain joining?
Domain joining
The domain was never the problem. The network in front of it was.
Domain joining registers a Windows device with an Active Directory domain, so the machine has its own identity in the directory and comes under central control. Remote domain joining removes the network dependency without removing the domain: the ZTNA controller brokers the connection between the remote device and your AD, so the device can join and stay governed from anywhere.
- A machine in the directory is a machine you governGroup policy, centrally managed credentials, enforced configuration, revocation from one place. Domain-joined devices are the ones IT can actually act on, which is why leaving a remote fleet outside the domain costs so much more than it appears to.
- The old procedure assumed a network, not a domainJoining traditionally required the device to be on the corporate network, because the join has to find and talk to a domain controller. That was fine when every laptop was issued at a desk. It broke the moment fleets went remote.
- The controller brokers it insteadThe connection between the remote device and your AD is brokered, so the device can join, receive policy and stay governed from anywhere, with no office visit and no VPN concentrator in the path.
- The directory does not moveIt stays exactly where it is: private, unexposed, reached only through the gateway. Nothing about this puts a directory endpoint on a public address.
Reaches the directory
- The remote device, through the gateway
- The controller, as part of authentication
- Group policy, on the normal refresh schedule
- Your administrators, from the internal network
Cannot reach it
- The public internet
- A port scan of your perimeter
- Anything without a brokered session
Three ordinary situations.
No good answer.
In all three the domain is intact and the device is compliant on paper.
The connection between them is what is missing. None of these is an exotic failure. They are the ordinary consequence of a procedure that assumed the machine and the directory were on the same network, at a time when they usually are not.
onboardingThe new hire who never comes inA laptop is drop-shipped to a home address and boots for the first time in a living room 2,000 km from the nearest office. Nothing on it has ever seen the corporate network, and the join has to happen before the user has an account to log in with. The usual answers are couriering the machine to IT, walking someone through it on a call, or leaving the device unmanaged.
credentialsThe password that expires on a TuesdayAn AD password expires while the user is at home. Windows shows the change-password prompt at the login screen and cannot reach a domain controller to complete the change. Cached credentials get them onto the machine; they do not get the password changed. In remote-first organisations this generates more helpdesk tickets than almost anything else.
policy driftGroup policy that quietly stops applyingThe device was joined properly, in the office, before everything went remote. It has not seen a domain controller in eleven months. It is still joined, but it is not governed. Policy drifts, configuration decays, and the fleet inventory says everything is fine because the object still exists in AD.
Reachable, not published_
The domain controller stays dark.
The alternative most organisations reach for is exposing something. Publish the domain controller, open a VPN concentrator, put a directory endpoint on a public IP with a firewall rule in front of it. All of them create an internet-facing target for the most valuable system on the network. A domain controller is the whole estate in one box.
Nothing here is published. The directory sits on the private network with no public listener and no inbound rule; the gateway reaches it from inside. The device reaches the domain because the connection exists, not because the domain has been moved anywhere.
And the traffic does not come to us either. The control plane makes the access decision; the data path runs device to gateway. Domain traffic does not transit InstaSafe infrastructure.
How the split plane worksDomain joining outcomes
The domain reachesfurther.Nothing else does.
Three things change once the join stops depending on which network the machine is sitting on, and one thing pointedly does not.
The join happens wherever the laptop is
Devices join the corporate domain through the controller, with no office visit and no courier.
Policy keeps reaching the fleet
GPO reaches remote devices, so AD and LDAP compliance extends to the whole estate rather than the half of it that comes in.
The directory stays private
AD is reached through the gateway only. Extending its reach never means giving it a public address.
//Bring the laptop you cannot get to//
Describe the machine, the location and the directory.
Thirty minutes with an engineer. Tell us where the device is and which directory it has to join, and we will walk the join through the console with you.
Regulated, air-gapped, or on-premise? See deployment options