How Do I Connect Local AD with Existing Azure AD for Azure Virtual Desktop?

Documentation for creating Azure AD Connect Cloud Sync to an Azure tenant with existing Azure Active Directory (AAD) users

Use Cases:

• You use Office 365 or Microsoft 365 and have current email / Sharepoint / One-Drive / AAD users in the Microsoft platform and/or 
• You currently synchronize a traditional Active Directory forest (ADDS) to AAD via AADC/AADC-CS

Acronyms used in guide: 

• AAD - Azure Active Directory (Microsoft cloud hosted as a service) 
• AD - Active Directory (An instance of an Microsoft Active Directory Domain Services install on a physical server, VM in azure, etc) 
• AADC - Azure Active Directory Connect (One of Microsoft's systems you can use for facilitating AD hybrid identity)  
• AADC-CS - Azure Active Directory Connect Cloud Sync (One of Microsoft's systems you can use for facilitating AD hybrid identity) 
• AVD - Azure Virtual Desktop (Microsoft's platform for delivering Windows shared/personal virtual desktops/applications via Azure)

Below there is an example simple case to illustrate this. If you have a more complex environment with AD federation, multiple public domains, split DNS or other scenarios please reach out to MyCloudIT senior support for advice. Important Note: This guide does not cover if you have an existing active directory environment on-premises, in azure or other via another method, there is a separate guide for that scenario. 

When you deploy AVD via the MyCloudIT portal we automatically install and configure AADC-CS. We also add your public domain (named custom domain names in AAD). This domain must be publicly registered and added to AAD prior to deployment.  

The new AD instance (on the domain controller we create on a VM called MSDC) will then be the master truth for all users and will replicate to AAD.  

You can check if you already have users in Azure Active directory by going to https://aad.portal.azure.com and logging in and clicking users. 

If you want to use these same users for AVD then the domain you supply AAD Custom (public) Domain for AVD question in the portal deployment wizard need to be the same as these exist users. 

Post deployment you would then add these as new users to AD via the "Active Directory" screen in the MyCloudIT portal making sure the UPN matches the ones that already exist. This will create a 'soft match' and the users will be considered "synchronized" and the same object. 

Example Case 

You have 3 existing users that have Office 365 Business Premium licenses and use exchange online email and one drive. The users User Principal Names (UPN) are as follows. 

• daniel.williams@myCompany.com 
• wei.wang@myCompany.com 
• jess.smith@myCompany.com 

You wish to deploy your first AVD system to this same Azure tenant and subscription. You would first check that myCompany.com is verified and primary in https://aad.portal.azure.com under "Custom domain names". 

Next you would Deploy AVD for the MyCloudIT portal making sure that AAD Custom (public) Domain for AVD question is answered as "myCompany.com". Wait for the deployment to complete and finish all post deployment steps.  

Next via the "Active Directory" screen in the MyCloudIT portal or via "Active Directory Users and Computers" add the three users. take extra care to make sure the domain specified for each users UPN is myCompany.com. 

A good way to check if synchronization is happening is to change an attribute such as "Office" for an AD user and then make sure that field is then changed in AAD. Note: Synchronization is not constant, it is performed at scheduled intervals so you may need to wait.

Appendix 

Appendix A: AD as the source of Truth 

This should be reviewed carefully as data loss is possible and cannot be reversed. This is by design from Microsoft.  

As AD is the source of truth (as opposed to AAD) fields such as "Last Name", "First Name", "Office" and "Street Address" the values specified in AD will overwrite any in AAD/Office365. Any attributes filled out in Azure.  

If an attribute for a user is populated in AAD/Office365 then ADDC-CS is activated and that same attribute is un-filled in AD then both will become empty. Example: AAD user daniel.williams@myCompany.com has the "last name" attribute set as "Williams". You create a new AD user daniel.williams@myCompany.com and leave the "Last name" field blank. Once the first synchronization has completed this user will no longer have a last name in either AD or AAD/Office365. 

Note that the AD attribute "Full name" does not map to AAD. The "Display Name" attribute in AD maps to "Name" in AAD. 

Appendix B: Password Changes 

If users already exist in AAD and then you add the same user as per above to make then "soft match" then the password set on the AD account will replace the users AAD/Office365 password.  

Once users are already synchronizing if you change or reset a password in AD the new password will also be applied to the AAD account.  

Warning: Once users are already synchronizing if you change or reset a password in AAD/Office365 the user will have 'mismatching' passwords. There are various ways to manage this challenge but that is outside of the scope of this document.  

We advise that administrators only reset passwords via AD or the MyCloudIT portal. Users can change their passwords via their RDS or WVD sessions. A useful method is to put a "change password" shortcut on the desktop. 

If you require two way synchronization of passwords then you will need to configure "password writeback" but this requires an AAD Premium plan or Microsoft 365 Business Premium. The list price for AAD P1 is US$6 per user per month. At the time of writing AADC-CS does not support password writeback.  

Appendix C: Email Considerations 

We recommend for most customers one of two scenarios: 

1. If you use exchange online (often called Office 365 email) then the users usernames in AD should be the same as their "Primary email address and username" in Office 365. If they have other email alias and shared mailboxes this is fine but no need to specify them in AD. In this Scenario the AD attribute "E-mail" should be also the same as their username.  
2. If you do not use exchange online then the "E-mail" attribute in AD can be the users third party email address, Example: example@gmail.com. 

These basic recommendations come from the fact that the way various AD attributes such as 'mail' and 'proxyAddresses' are synchronized can have unintended results.  

For Further reading see: https://learn.microsoft.com/en-us/troubleshoot/azure/active-directory/proxyaddresses-attribute-populate

Appendix D: AADC - Cloud Sync 

The MyCloudIT portal uses AADC-CS to synchronize user objects. Compared to traditional AADC, it is more lightweight, syncs more often and managed on the Azure plane. It is the better option for standard deployments. However it does not support all of the features. Some things that AADC supports that AADC-CS does not are: 

• Writeback for passwords, devices, or groups 
• Pass-Through Authentication 
• Exchange hybrid writeback 
• Device objects (hybrid AAD computer join or windows hello) 
• Integration with ADFS 
• Advanced SSO scenarios 

For further information see: https://docs.microsoft.com/en-us/azure/active-directory/cloud-sync/what-is-cloud-sync 

If you require AADC we can assist with advice on replacing AADC-CS with it, just reach out.