The Client required Remote Desktop Sessions to be available to 17 contractors via a hosted server. They also wanted that server to be hosted within their existing Azure/365 portal.
The first thing was to connect their AD to the cloud. AD Connect had already been installed and had done the initial seeding of the accounts for Office 365. But it had not been enabled for password replication and so SSO was not in place. Further, the issue with users not synching properly was only because the user accounts were in the default USERS OU. AD Connect doesn’t like this. Accounts need to be elsewhere.
Domain Joined machines in the cloud
In order to join virtual servers and PCs in the cloud to the client.com domain and use domain creds for logins to these machines, we had to extend the AD to the cloud. There are a number of ways to do this and the easiest and simplest is to use Azure Active Directory Domain Services (AAD DS). This extends the domain to the cloud with no site to site VPN (which can be done within Azure) and no virtual server running in the cloud as a domain controller.
Domain Admins for AAD DS
In the AAD Dashboard, go to Groups and note the AAD DC Administrators
This is a global security group that only exists in the AAD DS world. It contains AD accounts that are allowed to be the equivalent of the Domain Admin role in Azure. You must be in the group to be able to do certain high level functions like joining Azure VMs to the Client.com domain.
AD Connect on the on premise domain controller
AD Connect controls the replication of all configured information from the on-prem DC to AAD DS. It is straightforward to use and will sync any OU’s data except for the default, built-in OU.
Azure Virtual Machines
Azure VMs are mainly managed in the classic portal and not the new one.
Here are the server information readings as configured by Microsoft on the server desktop
The server’s RDS configuration is set via Add Roles… as seen below
Configurable information for the Session Based RDS Deployment is listed here: