Azure Active Directory Domain Services On -premises workstation Join

Copper Contributor


Just a quick one, I know this might not be something new but was wondering if anyone can help.



Company A is a start up company who wants a cloud only infrastructure with Office 365 and Azure. They don't want to build on-premises servers except for workstations to be used by the employees. They have 3rd party apps but does not really require AD authentication. So, here are the questions:


1.  If we use AAD DS, can they join workstations on-premises without even building a domain controller locally?

2. If yes, do they need a site to site VPN for this?

3. As for integration with office 365, can they have a single identity using AAD DS?  what about dirsync, is it still required?  Hybrid is not an option to them.  

4. As for the AAD DS, is this already available in ARM?  


I have checked the following articles but it seems I still need more input based on specific scenarios.  Any help is greatly appreciated.


Thank you   


9 Replies
AAD DS is not really for on-premises machines, it's for cloud-hosted servers.
Local machines will scan the network for a domain controller, and if one is not found then they will use local resources. So given AAD DS is not on the same network as you the machines won't find the service. At best you would need ExpressRoute so that you can have a Layer 2 connection to AAD DS, but this is a lot of work.
Realistically if you don't need AD locally, then just have the users authenticate using their AAD (not DS) credentials to the machines. This would be the same identity as used in O365, and therefore in Windows 10 would give a SSO experience to those services.

That's not really a use case for AAD DS. It's intended to be more of an "extention" of on-premises AD, and not a standalone directory service. Think of it as "managed" AD, where the bulk of administrative effort is taken care by MS, but you are also limited in some operations (for example, no domain admin priviledges, even GPOs and OUs are very limited). Basically, it's only recommended for scenarios such as these:


Microsoft itself does not recommend using AAD DS for workstations, the alternative proposed being Azure AD join. If you ask me, neither is particularly good alternative, but as long as you are fine with the restrictions, they can certainly work in some scenarios.


Here's a detailed session on AAD DS from Ignite NZ:



I'm not sure I agree with the suggestion that standalone AAD is "not really a use case for AAD DS".

AAD domain join is supported in Windows 10 for example:


I would think that the use-case would define the suitability of AAD but according to the article below for new small to medium size businesses, AAD appears to be functional entirely on its own.

I quote:

"one needs to understand that Azure AD (which Azure AD Join lets you easily join to) is not really a complete enterprise directory service in every sense of the word. What I mean is that a traditional directory service like AD DS that uses Lightweight Directory Access Protocol (LDAP) for authentication also includes other bits and pieces such as network policies, security policies, and so on. Azure AD, on the other hand, basically (in its current rev at least) only provides identity management capabilities (using REST instead of LDAP), which means that Azure AD is mainly intended for running apps in Software as a Service (SaaS) clouds. On the other hand, Azure AD and Azure AD Join are continuing to evolve under Microsoft's cloud-first, mobile-first strategy championed by CEO Satya Nadella, so large traditional enterprises should keep an eye on it while smaller companies jump on the train and enjoy the ride."






best response confirmed by DerrickFl (Copper Contributor)

Hello Gian,


Microsoft is trying to help customers simplify their cloud networks by building more services in the cloud. Before AAD DS, many customers used to build AD DS VMs on Azure in order to provide LDAP/Kerberos, etc., authentication for specific requirements. So, MS has simplified this by implementing AAD DS, meaning you get two IP DNS sources that are, in effect, AD DS VMs unmanaged by you. This is desgined devices that are on your Azure virtual network. This being said, for on-premises devices to authenticate to AAD DS, you must have a point-to-point VPN tunnel and point the local devices to your AAD DS DNS ips. But you should have a reliable network connection. As for AAD Connect (formerly DirSync), thats required for local AD DS synchronization to your AAD. Given that you prefer not having any local server resources, this would not apply in your case. Hope this helps.

Hi Loryan, Vasil and Sid,


Thank you so much for your replies and inputs and I really appreciate it. I have been reading also just wanted to validate my understanding on Azure AD DS. Based on what you guys mentioned, it seems like company A needs to have a local AD domain controller on premises and extend it to Azure depending on the requirement and In order to have full enterprise directory capabilities such as GPO's etc just like traditional directory service on Windows Server. So I think the way to go here is to build S2S VPN connectivity to Azure from Onpremises and build Azure ADDS VMs and have the workstations join to the domain. If connecting to Office 365, then a Dirsync server running AAD connect should also be built in Azure as an IaaS VM and have it synchronize to Azure AD. 


@Josh Villagomez


Hello Josh, Thank you for providing your input on the matter.  Hopefully in the future, MS would offer a full standalone enterprise directory service in Azure just like the traditional LDAP directory service in Windows Server without even building servers onpremises. In that way, we are able to address customers that are cloud-only organizations especially those that do not have plans on refreshing server hardware. Azure ADDS is also a good offering given especially for customers that are running Azure workloads already. 


Again, Thank you guys for your responses.


Hi everyone,


I'm very familiar with MS Active Directory having supported it since WIndows Server 2003 but, now working for a small software business that is entertaining a full Cloud infrastructure but does not already run Active Directory in any shape or form, I started investigating what is described here by Microsoft as effectively, "Active Directory as a Service"


Microsoft state in the above link

"Use Azure Active Directory Domain Services to join Azure virtual machines to a domain, without having to deploy domain controllers. Sign in to the virtual machines using their corporate Azure Active Directory credentials and seamlessly access resources. Use Group Policy to more securely administer domain-joined virtual machines – a familiar way to apply and enforce security baselines on all of your Azure virtual machines."



Another quote :

"Take advantage of Azure Active Directory Domain Services features like domain join, LDAP, NT LAN Manager (NTLM) and Kerberos authentication, which are widely used in enterprises. Migrate legacy directory-aware applications running on-premises to Azure, without having to worry about identity requirements. Easily deploy line-of-business applications on Linux and Windows Server virtual machines on Azure. You don’t have to deploy domain controllers as Azure virtual machines or use a VPN connection back to your identity infrastructure."



So, if AAD DS, is in not a Cloud based Active Directory that facilitates some traditional Domain management such as Group Policy (albeit via an Azure VM running Active Directory Adminstration Tools and joined to the AAD Domain) and other "on premise" AD functionality, including Windows 10 workstation AAD domain join  without the need for building, deploying and maintaining Domain Controllers, what is it exactly? 












Oh and @Gian - I apologise if I have rather hijacked this thread - I think you and I have similar if not identical ambitions for Azure AD and I hope my observations are relevant to your original post.


Hi Sid,


No problem. Glad you have good observations too and yes I think we have identical ambitions for Azure Active Directory. Thank you for adding this up.



There is now more clear guidance from Microsoft on this subject as here,


Hope this helps.