As a CTO, one of my tasks is to foresee the expansion of our IT infrastructure, which is mostly hosted in Azure. In the past few months I have been working on a whole new Azure environment that streamlines our virtual machines (VMs), offloads most of our workloads to manage services and users the latest and greatest when possible. One of the products I was looking forward to was Azure Active Directory Domain Services (AADDS), which provides two domain controllers for our Azure environment as a managed service. Not only this means we don’t have to worry about deploying domain controller VMs, but also a tighter integration with our Azure Active Directory.
After two weeks of researching on the subject and speaking with Azure support, I decided to take the leap—hoping the leap was based on empirical research more than faith. Boy, was I wrong wronged.
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, and many of the concerns raised have been addressed or mitigated. While some constraints persist, Entra ID Domain Services today 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.
During my research on AADDS, one of the fundamental aspects that I needed clarification on is Kerberos support. Our solution involved VMs running SharePoint [note: no longer the case since 2017], and Kerberos authentication is of paramount important to us. Both the AADDS documentation as well as the Azure support engineers have guaranteed to me that Kerebros is supported. Except that it really isn’t, as I found out the hard way.
Upon configuring SharePoint, we eventually had to create the Service Principal Names (SPNs), which are critical for Kerberos authentication to work. Creating these was not a problem, but when we tried to set up the Kerberos delegation for computer accounts, we got an access denied message. It turns out that we do not have the right to perform certain administrative tasks in an AADDS-based domain, and changing the delegation of computer accounts is one of them. Being this task a critical step of setting up Kerberos, this means that in practice support fort Kerberos in AADDS is insufficient to say the least, but I would go further: To claim that AADDS support Kerberos is disingenuous.
I spoke with Microsoft about this issue, which was escalated as far as the AADDS product team. While support engineers agreed with my rationale, management tried to dodge the bullet at first. One of their arguments is that the product is in preview, as if this would somehow give them the right to tell me that the product supports Kerberos when, in fact it does not. Also, even though AADDS was in preview at that time, they would gladly take our money for it (it is not like AADDS was free during the preview). In the end we were refunded for the costs incurred in this little Azure adventure, and off we went to decommission AADDS and restart our work from scratch, this time deploying two domain controllers as VMs and using AD Connect to sync with our Azure Active Directory.
Earlier this month (October 2016), Microsoft graduated AADDS from preview to general availability (GA). Upon reading the press release, I was quite disturbed to see AADDS being marketed as “scalable” and “supporting Kerberos”, yet I see no evidence that the issues I encountered have been fixed. When I spoke with the escalation team at Microsoft, they told me that these issues are unlikely to be resolved anytime soon, if ever.
Fact is that even if this problem is solved, due to administrative limitations imposed by the AADDS managed service customers might sooner or later bump into another roadblock and have no other option but to decommission their AADDS. This is no simple task since Active Directory (AD) is the backbone of the entire Windows infrastructure. One argument I heard coming from Microsoft is that AADDS is for small businesses, which I find to be ridiculous. First, the requirement for Kerberos has nothing to do with the size of an organisation. Second, which organisation would subscribe to a service that could hinder the capability of growth? For instance, why would a start-up go for AADDS since it has the potential to hurdle the growth of their infrastructure?
My advice to Azure customers is to stay away from AADDS and just deploy AD via VMs on Azure and use AD Connect.
Leave a Reply