In older version of directory synchronization tools we normally used the miisclient.exe to perform different complex tasks, like configuring an alternate login ID or implementing attribute based filtering. With Azure AD Connect this has changed and all associated and deprecated features of older tools have been removed from the UI of miisclient.exe. In order to accomplish these tasks in Azure AD Connect, we now use synchronization rules via the Synchronization Rules Editor.
But first of all, what are synchronization rules? Azure AD Connect synchronization rules are a modular definition of logic and are used to define almost everything, including precedence, object deletion, and other rules that were previously disjointed. A synchronization rule in Azure AD Connect is bound to a single connector, either to the AD connector or to the Azure AD connector, but never to both connectors at the same time. Each rule has a certain precedence and precedence defines the specific order in which rules are applied. For instance, a synchronization rule with precedence 100 will be applied first and one with 101 immediately afterwards.
When we create a new Azure AD synchronization rule, we have to logically define the entire flow. The first important step is to define a scope for the synchronization rule. For instance, we can define here that this rule should be applied only to users that have a certain value for the “Department” attribute and belong to a certain security group. This is the simple explanation, because scopes can be fairly complex. We can define several different groups of criteria and have inside each group several conditions. In this scenario please note that conditions inside a group will be evaluated with a logical AND, while between groups a logical OR will be applied.
So what happens with objects for which synchronization rules are applied? Simple, depending on the rules, Azure AD connect will establish a relationship between the connector space object and the metaverse object. If we configure our rule with a “provision” relationship, this will mean that if the object doesn’t exist in the metaverse database it will be created.
But when to use inbound rules and when tu use outbound rules? Good question. And there is no answer that will find a 100% consensus among Azure AD Connect specialists. Generally, it is wise to use inbound rules for filtering, especially in environments with several Active Directory Forests, and to use outbound rules when we want to define a custom attribute flow. Like for example when we need to configure an alternate login ID. The reason is, when you have several AD forests you might want to handle duplicates by filtering in the connector space. Also, in larger environments, this will mean that synchronization performance will be better.
Finally, we could use following graphic to summarize everything I mentioned about Azure AD Connect synchronization rules:
These are some basic concept about synchronization rules in Azure AD Connect. Of course, this is a very vast topic on which we could write an entire book. And maybe I will….some day. Till then, I fully count on your feedback and you personal experience with Azure AD Connect synchronization rules. So if there is anything you would like to share, please just take few minutes to write down a comment to this post.
How useful was this post?
Click on a star to rate it!
Average rating / 5. Vote count:
Latest posts by Dan Patrascu-Baba (see all)
- Configuration and environments in ASP.NET Core - 25/11/2019
- GraphQL in the .NET ecosystem - 19/11/2019
- A common use case of delegating handlers in ASP.NET API - 12/11/2019