The VPN tunnel was solid. We had split-tunnel traffic, per-user group policies, and MFA layered on Azure AD sign-ins. Nothing fancy, just a Meraki firewall and a bunch of cloud-native users on laptops.
Then someone asked for Wi-Fi to authenticate via RADIUS.
Not Wi-Fi on laptops, Wi-Fi for the office printers and a couple of older VOIP phones. Devices that didn’t speak SAML, didn’t join Azure AD, and couldn’t use certificates without a management headache. Just a plain old SSID with LDAP-backed RADIUS.
That’s when the obvious hole showed up: we didn’t have an LDAP source. Azure AD, by itself, doesn’t expose LDAP or Kerberos. And we had no on-prem domain controller.
At first, we thought Meraki might support SAML auth directly. It doesn’t, not for VPN or Wi-Fi. It does support RADIUS, but that assumes your RADIUS server has an actual directory to talk to.
We weren’t going to roll out on-prem AD just to get LDAP. That would mean a domain controller, backups, patches, and joining devices, all the things we’d intentionally avoided by going full Azure AD in the first place.
What we needed was LDAP, not Active Directory in the traditional sense. Just something that could respond to a bind request and validate passwords that already existed in Azure AD. That pointed us to Azure AD Domain Services. So, what is Azure’s AD DS?
What is Azure AD Domain Services?
Azure AD Domain Services (Azure AD DS) is Microsoft’s way of giving you the parts of Active Directory that legacy systems still expect without forcing you to build or maintain domain controllers.
When you enable it, Microsoft stands up two managed domain controllers inside your chosen Azure virtual network. You can’t RDP into them, patch them, or change their schema. They just exist, quietly providing LDAP, Kerberos, and NTLM.
That’s the entire draw: a read-only, managed domain that syncs from your Azure AD tenant. When a user resets their password in Azure AD, that hash syncs down to Azure AD DS so older systems can authenticate it.
It’s not the same thing as Azure AD. Azure AD DS exposes the traditional domain protocols that cloud-only Azure AD never had. You can bind to it with LDAP, join Windows VMs to the domain, and even apply Group Policy Objects.
But there are limits worth knowing early. You can’t extend the schema. You can’t create or edit users directly with ADUC, the objects are synchronized one-way from Azure AD. Forest and domain trusts are unsupported, so it stands alone. Replication is handled entirely by Microsoft and runs on their schedule, not yours.
If you’re thinking of it as “Active Directory in the cloud,” that’s close enough for function but wrong in control. It’s closer to “a read-only mirror of Azure AD that speaks old protocols.”
For teams like ours, that was perfect. We didn’t want the overhead of managing AD. We just needed LDAP to exist long enough for the Meraki RADIUS server to point at something that could actually answer.
Why a cloud-native org might still need it
If you start in the cloud, Active Directory sounds like something you escaped from. You’ve got Azure AD for identity, Entra ID for MFA, and Intune for device management, everything’s tidy until you run into gear that doesn’t understand any of it.
That’s where the problem hides. Legacy protocols didn’t retire when we moved to the cloud. Printers, VPN clients, even network appliances like Meraki still expect LDAP or Kerberos to confirm a user exists. Azure AD doesn’t provide either. It speaks modern OAuth and SAML, great for browsers, useless for RADIUS.
In our case, the Meraki firewall was doing its job. It could handle RADIUS authentication, but it needed a directory to check against. We pointed it at Azure AD and got nothing. Meraki expected LDAP; Azure AD offered tokens. Different worlds.
Azure AD Domain Services bridged that gap neatly. Once it was running, we could bind the Meraki RADIUS server directly to the managed domain using LDAP over SSL. No extra domain controllers. No sync tools. Just credentials that matched the same users already living in Azure AD.
The benefit wasn’t only the VPN fix. Azure AD DS opened up old SMB file shares, on-prem accounting apps, and one ancient label printer server that refused to die. Anything that needed to see “DOMAIN\username” finally had somewhere to look.
We didn’t bring Active Directory back from the dead, we just gave the ghosts of LDAP and NTLM a place to live that didn’t need babysitting.
Setup decisions and things that stalled us
When we decided to spin up Azure AD Domain Services, the wizard made it look easy, pick a resource group, choose a network, and wait. The waiting part wasn’t optional.
Azure AD DS takes a while to build. About forty-five minutes after deployment, the domain name resolved, but LDAP wasn’t answering yet. Microsoft handles replication behind the scenes, so all you can do is watch the portal and drink coffee. The service eventually wakes up, but it’s a quiet kind of delay that catches people off guard.
We tied it into an existing virtual network where our jump host lived. That vNet had subnets for servers and management tools, but no DNS server configured. Azure AD DS creates its own DNS, and here’s the catch: every VM that needs to talk to it must use its private IPs as DNS. Ours were 10.x.x.4 and 10.x.x.5, automatically assigned inside the vNet. Forgetting that step means your domain join will hang forever at “locating domain controller.”
The next tripwire was password hashes. Azure AD doesn’t store NTLM hashes unless you enable that sync for Domain Services. When you first turn on AD DS, users need to reset their passwords before they can authenticate through LDAP or Kerberos. The portal explains this in one small note, which most people skim. We learned the hard way, nobody could log in until they changed passwords.
Once DNS was right and passwords synced, domain join worked like it used to. From the jump box:
Add-Computer -DomainName "corp.example.com" -Credential (Get-Credential) -Restart
No special parameters, no magic. The VM rebooted, grabbed a GPO, and joined the managed domain.
One last surprise: Azure AD DS doesn’t live on public IPs. Everything that touches it, servers, RADIUS, management VMs, must exist inside or be peered to the same vNet. That meant moving our RADIUS instance closer, network-wise, to keep LDAP traffic private and fast.
It wasn’t hard work, but it reminded us how much “simple” depends on wiring things the right way first.
What’s different about managing it
Once the domain started answering pings and LDAP binds, the real question was: how do you manage something you don’t control?
Azure AD Domain Services feels familiar at first. You can open Active Directory Users and Computers (ADUC), Group Policy Management Console (GPMC), and even AD Sites and Services from a domain-joined VM. But the difference shows up fast, it’s all read-only from Azure AD’s point of view.
You can’t make new users or edit synced ones inside ADUC. The data comes one way: Azure AD → Azure AD DS. Any changes flow down automatically, not up. The right place to create a new account is still the Entra (Azure AD) portal. The managed domain just receives a copy when synchronization runs.
Group Policy still works, but it’s scoped to the AADDC Computers and AADDC Users containers. There’s no organizational unit hierarchy beyond what Microsoft provides. You can create your own OUs under those if you need custom policies, but it’s best to keep it minimal. GPO replication is slower than you’d expect, usually a few minutes rather than seconds. Enough to wonder if it applied, not long enough to panic.
DNS management is handled inside the Azure portal. The domain creates an internal zone matching your AD DS domain name. You can add or modify records, but Microsoft owns the root of that zone. If you need conditional forwarders or split-brain setups, you handle that in your own DNS server, not theirs.
From a backup and uptime standpoint, it’s completely hands-off. Microsoft maintains two domain controllers behind the service, replicating automatically across zones in the selected region. There’s no RDP access, no snapshots, and no patch windows to plan. You give up visibility in exchange for reliability, and for most small or hybrid environments, that’s a fair deal.
The adjustment was mostly mental. After years of scripting our own domain controllers, it felt odd to trust a directory we couldn’t touch. But the logs told the truth: LDAP binds were succeeding, Kerberos tickets were valid, and RADIUS requests from the Meraki box were authenticating just fine.
Sometimes the best kind of admin work is the one that doesn’t need you anymore.
Why this didn’t mean ‘going back on-prem’
After Azure AD DS was running and the RADIUS server finally answered a test request, someone joked that we’d rebuilt Active Directory in the cloud. It wasn’t wrong, but it missed the point.
We didn’t resurrect on-prem AD. We just rented the only pieces we still needed: LDAP and Kerberos. No domain controllers to patch, no replication errors, no SYSVOL eating itself on a Friday. Microsoft runs the plumbing, we just point systems at it.
That small distinction mattered. The Meraki VPN clients could now use the same usernames and passwords that Azure AD handled for everything else. The accounting share mounted without a service account buried in a batch file. Legacy systems got to stay alive while we planned their replacements.
For a company that started cloud-first, Azure AD Domain Services wasn’t a step backward, it was a bridge. It gave the network just enough “old” behavior to keep RADIUS and LDAP-bound devices working, without dragging a full domain back into maintenance.
There’s still a line between the new world and the old one, but now it’s clean. The VPN connects. The logs stay quiet. And nobody’s asked for a physical domain controller since.