As a CTO, one of my tasks is to foresee the expansion of our IT infrastructure, which is mostly hosted in Azure. Over the past few months, I’ve worked on a new Azure environment that streamlines our virtual machines (VMs), offloads most of our workloads to managed services, and uses the latest and greatest where possible. One of the products I looked forward to was Azure Active Directory Domain Services (AADDS). It provides two domain controllers for our Azure environment as a managed service. This means we don’t have to worry about deploying domain controller VMs, and we benefit from tighter integration with Azure Active Directory.
Update
This article was written in 2016 and reflects the limitations and context of Azure AD Domain Services (AADDS) at the time. AADDS has since evolved into Microsoft Entra ID Domain Services. Many of the concerns raised have been addressed or mitigated. While some constraints persist, Entra ID Domain Services now works reliably in modern environments—including hybrid setups where Entra ID is synchronised with an on-premises Active Directory. This allows organisations to meet specific legacy or niche requirements without the limitations previously described.
Research and a Leap of Faith
After two weeks of research and several discussions with Azure support, I decided to take the leap—not blindly, but based on what I thought was sound information. Boy, was I wrong wronged.
One key area I needed clarification on was Kerberos support. At the time, our solution involved VMs running SharePoint [note: no longer the case since 2017], and Kerberos authentication was crucial. Both the AADDS documentation and the Azure support engineers assured me that Kerberos was supported.
Except that it really isn’t, as I found out the hard way.
Where It Breaks
When configuring SharePoint, we created the Service Principal Names (SPNs) required for Kerberos authentication. Creating those was not a problem. But when we tried to set up Kerberos delegation for computer accounts, we hit an access denied error.
It turns out that AADDS blocks certain administrative tasks—and changing delegation settings on computer accounts is one of them. Since this step is essential for Kerberos, support in AADDS is not just limited—it’s broken. To claim otherwise is, frankly, disingenuous.
Escalation and Evasion
I raised the issue with Microsoft. It was escalated all the way to the AADDS product team. While the support engineers agreed with my rationale, management tried to deflect. One argument they gave was that the product was still in preview—as if that excused them from promising Kerberos support when it clearly wasn’t functional.
And AADDS wasn’t free during preview. Microsoft still charged for it. We paid for a product that didn’t work as advertised.
Eventually, we were refunded. We decommissioned AADDS and rebuilt from scratch—this time deploying two domain controllers as VMs and using AD Connect to sync with Azure Active Directory.
From Preview to Production?
Earlier this month (October 2016), Microsoft announced AADDS had reached general availability (GA). In the press release, they described it as “scalable” and “supporting Kerberos”. Yet I’ve seen no evidence that anything has changed.
When I followed up with Microsoft’s escalation team, they admitted the issue was unlikely to be resolved anytime soon—if at all.
The Real Risk
Even if this particular problem is eventually solved, the administrative limitations imposed by the AADDS managed service mean that customers are still likely to bump into other roadblocks. And if that happens, their only option may be to decommission AADDS entirely. That’s no small task. Active Directory (AD) is the backbone of the entire Windows infrastructure.
One argument I heard from Microsoft was that AADDS is intended for small businesses. I find that ridiculous. First, the requirement for Kerberos has nothing to do with the size of an organisation. Second, what business—large or small—would subscribe to a service that might hinder its growth?
For instance, why would a start-up choose AADDS if it could ultimately limit the scalability of their infrastructure?
Final Advice
My advice to Azure customers: stay away from AADDS. Just deploy AD via VMs on Azure and use AD Connect.