How and why to setup Entra Domain Services

Who could say no to a cute and cuddly (and new) things like the pups above. That is probably what Microsoft are saying when discussing Entra DS, but, it's not at all bad once you work out some of the Azure gumf. After all who doesn't want a little slice of on-prem Active Directory (AD) back again?

But why...?

There are some situations where you simply can't do without good old fashioned AD, in these cases you probably already have it running (somewhere). If this is you, despite Microsoft's branding, Entra DS might not be for you. If you have AD and need it "in the cloud" just setup another Domain Controller in your favourite cloud providers' environment slap in a VPN and away you go. What happens when you don't have an existing domain? Maybe the domain burned down or was decommissioned as part of that cyber audit that said out of date software needed to go? Then something, well, needed it. These are those times when Entra DS really saves your ass.

At the time of writing there are also some use cases where technically supported options are just a lot clunkier or more fragile than slapping in a quick (famous last words) managed service. Looking at you Azure File Share, Azure Virtual Desktop and Synology NAS.

No I don't need you to all write in about how I was being mean to your favourite product or that other options are available. We know there are. But some times they have other implications, like cost, or quirks that don't make them as attractive for the situation you are in.

Which leaves...the how?

Whereas in some articles I may look in exacting detail how you do X, Y, or Z the Microsoft articles and Azure wizards are actually quite complete in this area so I'll just point out a few gotchas that I see people commonly miss. And what you might do as next steps.

The I wish I had read the help article more closely list (FAQs):

These first few are not Entra DS specific but enough people stumble that it is worth the e-ink.

For the love of God stop making AD domains (managed or otherwise) the same as your website address. i.e. BigCompanyBrand.co.uk Consider that DNS is still a thing and that at some point you might want to be able to get to the website from within the domain without fudging it. You have many choices but something like <company initials>.domain i.e. BCB.BigCompanyBrand.co.uk works well. Don't forget just like with normal AD you want it to be something easy enough to type if you need it but not obnoxiously long or complicated like a random string of letters. Sometimes shortening or abbreviating the company name is also a good way of doing it.

Equally bad is AD.BigCompanyBrand.co.uk, what happens when two ADs meet? It is easy to type but everyone uses it.

Ditch the .local. Modern infrastructure needs modern security and some of that might well mean interacting with public Certification Authorities. You will struggle to get certificates issued for .local domains.

Think about where you are deploying the domain controllers in Azure. They are still Tier Zero, and as such get certain security considerations baked in by default but they also still have to communicate efficiently with the rest of your infrastructure. If you are deploying Entra DS to manage VDI in a region geographically close to your users then use the same region for the managed instances.

Don't be surprised when you deploy to an existing vNET that stuff stops for a minute (or more). One of the provisioning steps adds a Network Security Group to the vNET. If your favourite only RDS server is in that vNET your users will make you aware.

Check the requirements. If you are deploying to make, for instance, a line of business app work remember that old protocols are turned off by default. Whilst I don't recommend it, you may need to switch on deprecated protocols if it meets your requirements.