Using RemoteApp with Azure AD Domain Services

Microsoft recently announced that Azure RemoteApp can be used with Azure AD Domain Services (still in preview) for domain authentication, without running domain controllers as virtual machines in Azure. I’ll explain what this means in this post.

Azure RemoteApp

Many services that customers want to migrate or run in the cloud still depend on thick client applications. For example, a business might want to go all in on the cloud, deploy Office 365, and still need to run Office Pro Plus. This business could use Remote Desktop Services (RDS) in Azure to deploy Office Pro Plus and publish the applications to the users. Or in another example, an organization might use Azure Site Recovery (ASR) as a disaster recovery (DR) solution. In the event of a fire, they might need to failover. The services and data are safe in Azure, but they’re useless without end-user access. RDS comes in handy because it can provide near instant access to Mac, iOS, Android, and Windows devices.
On the downside, RDS requires:

• A lot of infrastructure, such as a connection broker, load balanced SSL gateways, and more, for high availability or large numbers of users
• Software assurance for your RDS CALs to be used with a cloud service. Just how many people purchased that add-on or even have RDS CALs sitting there in case of a disaster?

RemoteApp is licensed per-user (based on the service being deployed and the number of users assigned to the deployment). You don’t need RDS CALs or software assurance, and RDS takes care of all of the RDS infrastructure. All RDS asks you for is:

• A sysprepped template that can be used by Azure to deploy the session hosts for you
• Azure AD is populated with user accounts that will be assigned to the RemoteApp collection

In just about every scenario that I’ve been involved with, customers have opted for a RemoteApp deployment that uses Active Directory in conjunction with Azure AD:

1. Users sign into RemoteApp via Azure AD to get access to published applications.
2. When a user signs into their first application, that user is signed into Active Directory via a domain controller running as an Azure virtual machine. Group Policy configures the user experience.
3. The RemoteApp session hosts are also members of the domain (via the domain controllers) and are controlled by Group Policy.

And here is the catch: You need to run domain controllers (ideally, at least two) as virtual machines in Azure for the above configuration. Although they are probably lightweight machines, adding cost is bad – especially when the customer asks why they have to use two Active Directories (Azure AD and Domain Controllers).

Azure AD Domain Services

Microsoft realized that many customers are looking to deploy services, new or old, into Azure that rely on Domain Services, such as Group Policy, LDAP, and so on. These are things that Azure AD just cannot do. So Microsoft launched a preview of Azure AD Domain Services that provides many of the services that legacy AD offers. The goal here is to let us have a domain in Azure without deploying DCs in Azure (note I said, “in Azure”).
When you deploy Azure AD Domain Services you will:

1. Verify the FQDN of your on-premises domain
2. Enable Domain Services in your Azure AD domain
3. Connect Azure AD Domain Services to a VNet – it will consume 2 IP addresses to use as DNS servers on your VNet
4. Optionally use Azure AD Connect to syncrhonize user accounts from your on-premises DCs into Azure AD

Azure AD Domain Services with RemoteApp

Before you read any further, remember that Azure AD Domain Services is in preview. There are going to be issues, so be prepared for them. In this solution you will:

• Continue to run domain controllers on premises. This is where you continue to do the majority of your user administration.
• Synchronize on-premises AD with Azure AD.
• Use Azure AD to authenticate users with Remote App (as before).
• Have Azure AD Domain Services authenticate the RemoteApp session hosts on a common VNet.
• Use Azure AD Domain Services to authenticate users when they sign into the RemoteApp session hosts.

Authenticating RemoteApp users with Azure AD Domain Services [Image credit: Microsoft]

There are a few notes from Microsoft:

1. Azure AD Domain Services is a different domain to your on-premises domain. They share a domain name, and user accounts are synchronized between them, but this is not a hybrid environment where your domain is stretched to Azure using virtual domain controllers, and AD Sites & Services.
   1. You can use both “hybrid” or synchronized users and “cloud only” users in Azure AD DS. But you can only use synchronized users with RemoteApp at this time.
2. There is no trust between Azure AD DS and the on-premises domain. This means a user that signs into RemoteApp cannot use a client to access on-premises resources via a site-to-site network connection.

There are lots more notes from Microsoft for this preview scenario. For example:

• RemoteApp will be configured to use Azure AD DS as the authenticating domain.
• Azure AD DS should be connected to the same virtual network as the RemoteApp app collection.
• Ensure that the Azure AD DS IP addresses are configured as the DNS servers of the virtual network.

This is definitely an interesting design option for those that are considering a deployment in Azure that will have no backwards integration into the on-premises network, such as a complete migration or a DR scenario. It will reduce labour requirements and reduce costs, and those are good things.