The fourth part of my series into Azure Active Directory examines the options available to synchronise data between your on-premises AD and Azure AD.
In this series, I will take you through the key aspects of Azure Active Directory, and you will discover how using Azure AD you can build identity solutions for the future. The series is about the technology rather than the marketing hype. It’s also something I cover in more depth in my masterclass, which is a deep-dive into the technologies and goes into the real technical detail. For an introduction to this series and some background on myself, see Episode 1: Introductions all round.
Caveat: To the best of my knowledge the information was accurate at the time of writing this blog but changes to Azure AD and the portals are frequently happening, and the precise details may change.
Episode 4: Synchronising Azure AD and on-premises AD
Previously in this series we have seen how we can create users in an Azure AD tenant and how those users can authenticate to applications. We can create users in the Azure AD using the new or classic portals, programmatically through API calls or using PowerShell. The Users created in this way can use all the benefits of Azure AD to reach out and authenticate against 1000s of SaaS apps. However, one of the most compelling reasons to adopt Azure AD is to empower our on-premises users, with accounts in our on-premises AD, to reach out and embrace the world of distributed applications. We could provision our on-premises users with an account in Azure AD, and they could use this account to access the SaaS applications while using their on-premises AD account to access corporate applications. The better solution, however, is to use the same credentials on-premises and in the cloud; to achieve this, we must synchronize user accounts between the two directories.
Luckily for us, Microsoft has equipped us with Azure AD Connect to handle all the magic of synchronization. As with all things in the cloud, the technologies are evolving, and precursors to Azure AD Connect are Windows Azure Active Directory Sync (DirSync) and Azure AD Sync. These two tools are depreciated and reach end-of-life in Q1 2017.
As I’ve already said, cloud technology is still fairly early stage as far as technology goes, and new features are coming on-line all the time. Using the analogy of a child growing up, we’ve already passed the terrible twos and Azure will be seven next February 1, I would hate to speculate what will happen when Azure becomes a teenager! The point is, we need to keep up with the latest and greatest features and to do that we need to use the latest tools. With this in mind, we should be synchronizing with Azure AD Connect. Azure AD Connect now automatically updates itself ensuring that you have the latest and greatest!
The Azure synchronization tools were unidirectional to start and synchronized users from on-premises AD to the Azure AD. As the needs to support password resets and device registration in the cloud emerged the tools were upgraded to support write-back. Cloud-based changes are now written back to the on-premises AD.
Azure AD Connect has now matured to support:
- See below
- AD FS integration
- This option configures federated SSO and triggers the deployment of an AD FS server and a Web Application Proxy. I’ll give more details of hybrid scenarios with AD FS in a later episode of this blog.
- Health Monitoring
- Azure AD Connect along with AD FS and AD directory services can be monitored and reported through Azure Active Directory Connect Health
Azure AD Connect has evolved from Microsoft identity management tools (aka MIIS, ILM, FIM, and MIM). The Azure AD Connect wizard will provide the capabilities to deal with most scenarios. However, if you use your MIM skills to make advanced changes outside of the scope of the Wizard, you may create an unsupportable configuration. See Azure AD Connect sync: Best practices for changing the default configuration for more details.
The default mode of operation is for all users, contacts and groups to be synchronized to the Azure AD. If you use the Express Setting options see Figure 1, you will be up and running quickly, but everything will synchronize including passwords. SQL Server 2012 Express is installed with an approximate limit of 100,000 objects.
To fully control the configuration, the custom settings must be chosen, see Figure 2:
There are many different paths that can be followed depending on the options chosen. In this blog, I just want to cover off the key principles. There is lots of good documentation and help that can be used to configure more advanced scenarios.
Looking at Figure 2 the first three checkboxes are self-explanatory. Four groups are created for administration purposes (Administrators group, Operators group, Browse group, and the Password Reset Group) if you want to define the groups choose the “Specify custom sync groups” option.
Our next challenge is to decide how we want the user to sign-in, see Figure 3 – Step 1.
Figure 3 – Step 1
- Password synchronization, allows the same password to be used on-premises and in the cloud. The on-premises password is stored cryptographically as a non-reversible hash, rather than just replicating this to the Azure AD an additional layer of security is applied, and the hash is hashed again before passing it to Azure AD.
- The hashes stored in Azure AD cannot be used to access any on-premises AD resources.
- Federation with AD FS, enables the user to be authenticated by on-premises AD FS and AD. If you do not have an existing AD FS infrastructure, the Wizard will install AF FS and the Web Application Proxy onto existing 2012 R2 servers.
- Do not configure, results in the user having and Azure AD and a separate on-premises AD password. Alternatively, a 3rd party federation service may be in use.
Figure 3 – Step 2
- Connect with Global Administrator privileges to you Azure AD.
Figure 3 – Step 3
- Connect to and add the directories that you want to sync from your on-premises forest(s).
- The account specified needs to the appropriate privileges for the synchronization options that you choose. As a minimum, it must have read permission in the selected directory(ies). See Azure AD Connect: Accounts and permissions for more details.
- Remember to work with the principle of least privilege, do not just use a domain administrators account for convenience!
Figure 3 – Step 4
- All of the on-premises AD UPN suffixes are enumerated and displayed together with any verified domains.
- You can select the on-premises AD user attribute to be used as the Azure AD sign-in name
- The recommendation is to use the UPN
Here it is worth taking a few moments to discuss on-premises UPNs and the Azure AD username. The recommendation is for users to sign-in to the Azure AD using their on-premises UPN. Maximum compatibility and simplicity for the user is achieved by using the on-premises UPN as the Azure AD username. However, it does mean that the on-premises UPN suffix must be configured in Azure AD as a verified domain.
If you have on-premises suffixes that cannot be added to Azure AD as verified domains, for instance, UPN suffixes of example.com or xtseminars.local, the recommendation is to update the on-premises suffixes to verifiable domain names. If, after analysis, it is decided that it is not possible to change the on-premises UPN suffix then an alternative attribute (Alternative ID) of the user account can be selected as the Azure AD username. It is advised to use the user’s mail attribute, the caveat is that to sign in to Azure AD a user will use their email address, but to log on to on-premises resources, they will use their on-premises UPN or the domain\username format.
Warning: using an alternative attribute may cause compatibility issues with some workloads.
If there is no verified domain that matches the user’s UPN or alternate ID suffix the user will be created in Azure AD as <name>@<tenant name>.onmicrosoft.com.
Figure 3 – Step 5
- Here you can select which domains and OUs to synchronize to the Azure AD
Subsequent steps are shown in Figure 4.
Figure 4 – Step 6
- If you have multiple on-premises directories, it is possible for a user to be represented multiple times across the directories. As an example, the user might have their user account in one directory and be defined as a contact in other directories. So that they are only synchronized once to the Azure AD, the synchronization engine must be able to join these different identities together. In step 6 you define the attribute that uniquely identifies the user and has the same value across all directories. As an example, you could possibly choose the mail attribute.
- The source anchor must contain a value that uniquely identifies the user in the on-premises directory and in the Azure AD. The selected value must never change during the lifetime of the user. An ideal choice would appear to be the However, if the users are moved between on-premises directories, this value will change and should not be used. If this is a likely scenario, you need to choose a different anchor. The anchor value must be immutable (unique and unchanging), it cannot contain the @ character, it is case sensitive, and the selected attribute cannot be changed.
Figure 4 – Step 7
- Allows you to define a group of objects to be synchronized. The use of this feature is only intended for staging deployments.
Figure 4 – Step 8
- This step allows you to set up the more advanced features and I will leave it to you to investigate further.
After the wizard has completed and once the synchronization is running don’t forget to use Azure Active Directory Connect Health to monitor the results. Please watch the video where I look at some of the post installation checks that you can perform and reconfiguration options. That’s it until next time.
For details of all the episodes in this series, look here. To learn and become skilled in implementing identity systems based on Azure AD, on-premises AD and AD FS join me at one of my Masterclasses.