Enterprise Mobility and Security Blog


Azure AD Domain Services is a new solution, currently in public preview, primarily designed to simplify “lift-and-shift” scenarios in Azure IaaS; “lift-and-shift” is a strategy for moving your existing workloads as they are into the cloud, which often requires a domain controller running in the cloud environment.

In a nutshell, Azure AD Domain Services takes the users and passwords available in your Azure Active Directory and “projects” them into a fully managed domain controller in a VNet of your choice. You can then domain-join computers – typically your lift-and-shifted workloads – to that domain. For a more complete overview, please read the Azure AD Domain Services documentation here.

When would I use Azure AD Domain Services with Azure RemoteApp?

Azure RemoteApp (ARA) allows you to create a domain-joined collection; this is done so your remote applications run on domain-joined computers and can access other resources using Windows Authentication.

If you want remote applications connecting back to your on-premises environment, you should not use Azure AD Domain Services – instead you should configure a site to site connection between Azure and on-premises and use that with ARA. ARA will then join its computers to your on-premises domain controller and users will be able to access your on-premises resources.

However, if your entire workload is being lift-and-shifted into Azure and there is no need to connect back to the on-premises domain, Azure AD Domain Services may be the right solution for you. Instead of connecting ARA back to your on-premises you will place it in the same VNet as Azure AD Domain Services and your other resources. Remote applications will be able to authenticate and access resources within that virtual network.


The diagram below shows a deployment of Azure RemoteApp into an AAD-DS managed domain.


Here are a few points to keep in mind:

Note 1: You can sync your user names and passwords from an on-premises Active Directory. However, this should not be confused with setting up a hybrid environment that will connect back to on-premises; AAD-DS is not used to connect to on-premises but instead it creates a new isolated domain in Azure.

Note 2: AAD-DS works both with directory synced identities as well as “cloud only” identities – user accounts created directly in Azure Active Directory. As long as a user account is exposed through AAD, it will be made available in the AAD-DS managed domain.

Note 3: There is no connectivity or trust relationship between the AAD-DS domain and any on-premises domain that may exist. Apps hosted on Azure RemoteApp will only have access to the resources hosted within the Azure AD Domain Services domain and the VNet. This provides isolation from any on-premises environment that may have been left behind.

How to deploy Azure RemoteApp with Azure AD Domain Services

The process is the same as for deploying domain-joined collection with a traditional domain controller. However, we need to pay attention to the Azure configuration:

1. Make sure the Azure subscription you want to use with ARA is associated with the Azure Active Directory (AAD) you want to use as the source of users for your deployment.

  • In the Azure Management Portal choose Settings from the left hand side pane
  • Check the parent directory name associated with your subscription – you want this to be the directory containing future ARA users. The Azure AD Domain Services service will be deployed for this directory as well


  • If you want to use a different AAD with your subscription, follow the instructions here to move the subscription into a different directory:

2. Create an Azure VNet that will be used both with Azure AD Domain Services and ARA.
Read here about considerations for VNets used with ARA – see section “Azure RemoteApp cloud collection with VNet” for the configuration relevant to the Azure AD Domain Services scenario.

3. Follow the instructions here to deploy Azure AD Domain Services in your Azure Active Directory.

  • Make sure to update your VNet with DNS addresses provided by Azure AD Domain Services (Step 4).
  • Pay particular attention to “Step 5: Enable password synchronization”; if not done correctly your users will fail to sign into the domain-joined ARA machines.
  • Please note that Azure AD Domain Services is currently in public preview so things are subject to change before general availability.

4. Create a new Azure RemoteApp domain-joined collection (also known as “hybrid collection”)

  • In Azure Management Portal, click New -> App Services -> RemoteApp -> Create with VNet
  • Choose the same VNet you used with Azure AD Domain Services and make sure to select the domain join option.


  • The collection is created but needs additional input before it can be used. This can be done via QuickStart in the Azure Management Portal. Click on “join local domain” which will bring up the form below.


i. Domain Name: this is the domain name you chose when configuring Azure AD Domain Services. Make sure this is the same value, otherwise we won’t be able to join computers to your domain.

ii. Service Account User Name: when deploying Azure AD Domain Services you created a group called “AAD DC Administrators” in your Azure Active Directory. Members of this group have the necessary privileges to join computers to the domain. Use one of those accounts here.

  • Azure RemoteApp will provision your collection; part of that process will attempt to join computers to your Azure AD Domain Services managed domain. If you see failures related to problems with the domain, here are some tips:i. Verify the domain and VNet information in your collection.

    ii. Create your own VM in the Azure Management Portal; make sure it is added to the same VNet you used with Azure AD Domain Services. Log onto the VM and try to join it to the domain. If this process fails, you are probably using wrong credentials or the network configuration is incorrect.

    iii. If the network configuration is correct and you are certain you are using the correct admin account, double check you followed the instructions under “Step 5: Enable password synchronization”. If your user accounts have not been synced correctly, they won’t work with sign in into Azure AD Domain Services.

5. Assign users to Azure RemoteApp. Keep the following in mind

  • User accounts must be from the same Azure Active Directory that contains the Azure subscription used to deploy ARA.
  • You cannot use Microsoft Accounts (e.g. @outlook.com).
  • User account’s User Principal Name (UPN) as represented in AAD and Azure AD Domain Services must be the same. For example, if the user logs in with joe@contoso.onmicrosoft.com into AAD they must also have the same login for Azure AD Domain Services. Depending on how you set things up those two UPNs may be different:

i. When you create or sync a user into AAD you choose the UPN for the user. For example, you may choose to use one of the public domain names you own – the user’s AAD UPN may look like this: joe@contoso.com

ii. When creating Azure AD Domain Services you choose a domain name; for example, you may choose the default domain name that comes with your AAD: contoso.onmicrosoft.com. The user’s Azure AD Domain Services UPN would be joe@contoso.onmicrosoft.com

iii. In this case the user would not be able to log into Azure RemoteApp because the UPNs are different. Either change the UPN in AAD or change the name of the domain in Azure AD Domain Services.

  • Temporary limitation: Azure RemoteApp domain-joined collections must use “dir synced” users only.

i. Originally when we designed domain-joined collections we assumed they will always use a regular customer-owned Active Directory which is synced into Azure Active Directory.

ii. We added a check to make sure that only users properly sourced from AD (“dir synced”) can be added to the collection. Users who were not synced, but created directly in AAD, would not be able to connect to Azure RemoteApp since they have no access to the domain.

iii. With Azure AD Domain Services all users from AAD (no matter how created) are “projected” into the managed domain, so this check is not necessary.

iv. While we work on removing this limitation, please make sure that you dir sync users into AAD before adding them to your Azure RemoteApp collection. For non-sync’ed users you will see an error message when adding them to the collection.

Note: Questions and comments are welcome. For troubleshooting requests, post a new thread in the Remote Desktop clients forum. Thank you!