Azure Active Directory Synchronization: An Introduction, Part 2

Reading Time: 5 minutes

This post is the second in a series about Azure Active Directory Synchronization, covering part 2 of an introduction. Previous and follow up posts have covered and will cover:

• Introduction, Part 1
• Filtering, Part 1
• Filtering, Part 2
• Object Matching
• Alternate Logon ID

As most organizations will not require FIM, I will focus my attention mostly on AADSync. Although DirSync is (unless features from AADSync are required) the first choice, it's deprecated, but more importantly: most concepts are still unchanged.

In order to be able to understand subjects like Filtering, Object Matching etc. discussed in follow up posts, it is necessary to get a grasp of the terminology and concepts used within AADSync. I'll try to keep the terminology as concise as possible, as this post is targeted at those who want a quick introduction. For a more detailed explanation you can read the Technical Concepts and Understanding the Default Configuration.

Connectors and Connector Space

Connectors (or Management Agents in DirSync) are the items that connect with Active Directory (AD), whether it is an on-premises Active Directory or Azure Active Directory (AAD) used by services like Office 365. They regulate the import or export of objects or changes on objects from the specific environment they are connected to. They can only be connected to one environment at a time; DirSync could only have two connectors; one to your on-premises AD and one to AAD. AADSync can have multiple connectors to multiple AD Forests, but only one connector to an AAD.

The information obtained by a connector is stored in the Connector Space, a cached set of the data imported by the specific Connector. It is possible to filter what objects are imported, more on this later.

Attribute flow and Metaverse

Objects and their attributes from all connectors will be transported to the Metaverse and from the Metaverse they will be synchronized with AAD; This process is called the attribute flow. The Metaverse is a combination of all objects and attributes from all connectors; depending on the configuration, objects from all connectors are unique or can be joined to form one object (more on this in another post).

Updating and Provisioning

Any object within the Metaverse that has attributes (relevant to AAD) with values that have changed, will be updated with the next export to AAD. If an object previously did not exist in AAD, it will be created by AADSync i.e. provisioned. If an object is deleted in AD, it will be deleted in AAD (to be found in Deleted Users for 30 days).

When Exchange Online or other features like Password Write-Back are used, AADSync is then allowed to change attributes in your on-premises AD. The service account running the service then requires additional Write/Change permissions in AD.

Synchonization Editor & Rules

For a closer look of the inner workings, starting the Synchronization Rules Editor is a good way. In DirSync you had to find and start miisclient.exe. Luckily with AADSync, it's now a predefined shortcut in your Start Menu.

After starting the Synchronization Rules Editor, you will find a whole bunch of separate rules. These are essentially the backbone of AADSync and regulate what and how objects and their attributes are imported, matched, transformed and exported.

The preconfigured rules are determined by the installer on the AADSync configuration options selected and the status of the Active Directory Schema of any on-premises AD Forest during installation. For instance; if you have Exchange on-premises and enabled the Hybrid Exchange option during install, you will have a different set of rules, because different sets of information need to be handled in specific ways. If required, you can add or customize rules. See a follow up post regarding this.

Inbound & Outbound rules

You have inbound and outbound rules. Inbound rules are applied when importing information from a specific source, i.e. your on-premises Active Directory into the Metaverse. Outbound rules are applied when exporting information from the Metaverse to a specific source, mainly Azure Active Directory. This will be explained in more detail in an upcoming Filtering post.

Each rule has specific configuration sections that dictate when and how an object is treated by the rule. These sections are Description, Scoping, Join and Transformation. Each rule also has a Precedence value, which influences the order in which rules are handled.

Description

The Description is more than a Name and Description, it is also the page that determines which source connector is used, the Object type (user, contact or group), Precedence and Link Type. Linking will be discussed below.

The precedence of rules regulates which rule is implemented before other rules. Rules with a lower precedence number will win over similar rules with a higher precedence number.

Scoping

With Scoping you can define specific requirements for objects that will be handled by this rule. If the filter returns true, then the object will be handled by this rule and actions in Join and/or Transformations are performed.

For instance: a filter can check the attribute MailNickname with Operator ISNOTNULL, which requires the object to be at least mail enabled. You can determine the Attribute, the Operator (logical AND/OR/EQUAL etc.) and a Value if required.

Join

These are the rules that determine how objects from the connector space are related to the objects in the Metaverse. If the rules match for an object, than both objects are joined in the Metaverse. If no Join rules match, then the Link Type (in Description) action will be administered for instance Provision (i.e. create object). More on this in the upcoming Object Matching post.

Transformation

At the Transformation section, you can alter the value of specific attributes after filtering and joining. You can let the value from the source object persist, determine a constant value independent of the source value or you can use Expressions (in Visual Basic for Applications) for complex actions.

Concluding

An understanding of synchronization concepts are required in order to successfully customize the available configuration options such as filtering, discussed in later posts. It is also very helpful in designing you synchronization requirements and troubleshooting any issues. A more detailed explanation can be found in the Technical Concepts and Understanding the Default Configuration pages.