Last updated on September 22nd, 2026 at 09:42 am
In the last build I put a domain controller up from nothing. DC01, trevtech.lab, a test user called Bruce Wayne, an IT-Admins group. It worked. A Windows 11 client joined the domain, logged in with a domain account, picked up policy.
And then I sat there thinking: right, now what.
Because a domain that works perfectly and touches nothing outside your own network is a closed loop. It’s a great thing to have built. It’s also about half of what a real environment looks like in 2026. Every job ad in this space says hybrid somewhere in it, and hybrid means one identity that exists on-prem and in a Microsoft cloud tenant, with one password.
So that’s what I built next. This is the write-up.
By the end of it, bwayne signs in to a Microsoft cloud tenant using the password stored in my on-prem AD, and nothing about that password ever gets typed into the cloud.
The wall I hit first, before installing anything
Here’s the bit most write-ups skip.
I picked trevtech.lab as my domain name in the first build. Loads of homelab guides tell you to use .local or .lab — it’s old advice from a pre-cloud era, and it stuck around long after the reason for it stopped applying.
The problem: .lab is non-routable. It doesn’t exist on the public internet. Nobody can prove they own it, because there’s nothing to own. And Microsoft’s whole domain verification process works by asking you to prove ownership via a DNS record.
So Entra will not verify trevtech.lab. Not a setting, not a workaround. It just can’t.
What happens if you plough on and sync anyway is worse than an error, because it looks like it worked. Every user arrives in the cloud as bwayne@yourtenant.onmicrosoft.com. The sync ran. Objects appeared. And you now have a tenant full of identities with the wrong logon names, which you’ll be unpicking later.
The fix is a routable domain you actually own, added to AD as an alternative UPN suffix.
I used lab.trevtech.org — a subdomain of a domain I already had. If you don’t own a domain, one costs about the same as a coffee. It’s the cheapest unlock in this entire build.
# Add the routable suffix to the forest
Get-ADForest | Set-ADForest -UPNSuffixes @{add="lab.trevtech.org"}# Restamp users in the lab OU onto the new suffix
Get-ADUser -Filter * -SearchBase "OU=Users,OU=trevtech,DC=trevtech,DC=lab" |
ForEach-Object {
Set-ADUser $_ -UserPrincipalName ("{0}@lab.trevtech.org" -f $_.SamAccountName)
}Bruce Wayne’s logon name is now bwayne@lab.trevtech.org. Nothing has been installed. The hardest problem in the build is already behind us.
One thing worth saying plainly: this changes users’ UPNs, which is their logon name. In a lab, fine. Anywhere with real people on it, that’s a change-controlled job with comms attached.
A separate tenant, and the subdomain trick
Build a new tenant for this. Do not sync a lab into a tenant you care about. Twenty minutes, no card required.
Now, the question I had going in, and the answer took some digging: my main domain trevtech.org is already verified in my production M365 tenant. Can I still use a subdomain of it in a different tenant?
Yes — and this is a genuinely useful thing to know. Entra treats a root domain and its subdomains as separate DNS namespaces. So trevtech.org stays verified in production, and lab.trevtech.org verifies independently in the lab tenant. Microsoft documents this as the supported way to run related domains across multiple tenants.
What you cannot do is verify the same exact domain in two tenants. That’s the limit people run into.
Add the custom domain in the Entra admin centre, it gives you a TXT record, drop that at your DNS host, hit verify. Usually a few minutes.
Two cautions:
- That TXT record goes on your production DNS zone. It’s additive and won’t touch mail flow or production authentication — but it’s still prod DNS, so be deliberate about it.
- Within a single tenant, subdomains inherit the root’s authentication type. Across separate tenants they’re independent, so the lab stays managed regardless of what production does.
You need the Hybrid Identity Administrator role for the next part. Not Global Admin. Worth knowing the distinction — it’s the kind of thing that comes up in interviews. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference
Why Cloud Sync and not the tool everyone else installs
Nearly every tutorial on this topic tells you to install Entra Connect Sync. The big one, with the wizard and the local SQL database.
Two things changed that.
In April 2026 Microsoft said all customers will eventually move from Connect Sync to Entra Cloud Sync. No final retirement date yet — it goes when Cloud Sync reaches feature parity — but the direction is set, and Microsoft started contacting smaller customers about migrating from July 2026.
There’s also a harder, nearer deadline: Connect Sync installs older than version 2.5.79.0 stop synchronising on 30 September 2026 unless they’re upgraded. That’s a backend security change, and it’s an upgrade cliff rather than a retirement, but it will break environments that ignore it.
Cloud Sync is a lightweight agent on-prem with all the configuration living in the cloud. No SQL, no server role, nothing to patch locally, and multiple agents can run for redundancy.
The honest limitation: Cloud Sync still can’t do device writeback for Hybrid Entra Join, password writeback, pass-through authentication, or Exchange hybrid. If you need any of those, you need Connect Sync today.
This build needs none of them. Users and password hash sync, which Cloud Sync handles completely. So Cloud Sync it is — and that’s what Microsoft recommends for new projects anyway.
Know the name Entra Connect Sync regardless. Most workplaces are still running it, and you’ll meet it.
Installing the agent on DC01
Prerequisites, as a checklist rather than a spec sheet:
| Requirement | Detail |
|---|---|
| Server OS | Windows Server 2016 or later |
| AD schema | Needs msDS-ExternalDirectoryObjectId (Server 2016+) |
| On-prem rights | Domain Admin or Enterprise Admin, once, to create the gMSA |
| Cloud role | Hybrid Identity Administrator |
| Network | Agent reaches a DC on TCP/389 (LDAP) and TCP/3268 (Global Catalog) |
| Windows service | Credential Manager (VaultSvc) must not be disabled |
That last one is the sneaky one. Hardened images and lockdown scripts sometimes disable VaultSvc, and the agent install fails without telling you why.
Installing on the domain controller is supported, and for a lab it’s fine — that’s what I did. In production you’d put it on a separate member server, because a DC is a tier 0 box and you keep the software surface on it as small as possible. Worth knowing the difference between “this works” and “this is what you’d actually do.”
The install itself is short. Run it, sign in with the hybrid identity admin account, the agent registers itself, a gMSA gets created to run the service. Then check the agent shows as healthy in the Entra admin centre before you touch anything else.
Note what didn’t happen: no inbound firewall rules. The agent makes outbound connections only. That’s a big part of why this design is easier to defend than the old one.
Configuring the sync — and the one click that matters
The agent is a pipe. Nothing has moved yet.
The configuration is built in the Entra admin centre, cloud-side. And the single most important decision in this whole build is scoping.
Scope the configuration to a specific OU. Not the whole directory.
Sync everything and you’ll push service accounts, disabled objects, and the built-in Administrator into your cloud tenant. It’ll work, and then you’ll spend an evening cleaning it up. Scope narrow, widen later when you know what you’re doing.
Then enable password hash synchronisation. Worth understanding what this actually does, because “syncing passwords to the cloud” makes people flinch and the flinch is based on a misunderstanding.
AD never stores your password — it stores a hash. Password hash sync takes that hash, hashes it again, and sends that. It’s one-way and it’s on a timer. Microsoft never receives your password, and can’t work backwards to it. You’re not forwarding your keys. You’re forwarding a photo of the lock.
Use provision on demand to test a single user before you enable anything. I ran bwayne through it first. If one user provisions cleanly, the config is right.
Then enable it and watch the first cycle. Cloud Sync runs roughly every two minutes, which is a lot tighter than the 30 minutes people expect from the old tool.
Proving it actually works
An object appearing in a portal proves the plumbing. It doesn’t prove what I claimed at the start.
So: open a browser with no existing session — different machine, or a private window. Sign in as bwayne@lab.trevtech.org using the on-prem password. The one stored in my domain controller, that was never typed into anything cloud-facing.
It works.
Then the proof that actually matters: change the password on-prem, wait a cycle, sign in again with the new one. First sign-in could be coincidence. The second one is the mechanism.
Last thing to look at is the user object in the portal. It’s flagged as synced from on-premises, and you can’t edit it in the cloud. That’s the source of authority, and it’s the concept worth taking away from all of this. AD is still the master. The cloud holds a copy.
That’s hybrid identity. One identity, two places, one password.
The gotchas
The .onmicrosoft.com trap. Sync before fixing the UPN suffix and every user lands with the wrong logon name. Recoverable, but you’ll be restamping users and waiting on sync cycles to catch up.
Scoping too wide. The fastest route to a tenant full of objects you never meant to send. Start with one OU.
VaultSvc disabled. Agent install fails, error doesn’t point at the cause. Check the service before you start.
Expecting an instant sync. It’s a scheduled cycle, not a trigger. Give it a couple of minutes before deciding it’s broken.
Assuming this gets you Hybrid Join. It doesn’t. Device join is a separate mechanism, it needs device writeback, and Cloud Sync doesn’t do that yet.
Is it worth building?
Yes, and it’s a better use of a weekend than another cert module.
Part 1 gave you a domain. On its own that’s a closed loop that proves you can follow instructions. This is the bit that turns it into something you can talk about — because “explain hybrid identity to me” is a real interview question, and there’s a visible gap between someone reciting a definition and someone describing a tenant they built, scoped, broke, and fixed.
The whole thing is an evening. The domain name is the only part that requires a decision you can’t easily undo, and now you know to make it first.
Video for this build is on the channel — link below.
https://www.youtube.com/@TrevTech-IT
— Trev | I broke it. Fixed it.
