Azure Active Directory Synchronization: Filtering, Part 2

Reading Time: 5 minutes

This post is the fourth in a series about Azure Active Directory Synchronization and will cover Filtering. Originally I've planned to make this one post, but in my opinion it became to large and complex thus again a part 2. Other posts have covered and will cover:

In the previous post I discussed why and how to filter: Domain, Organizational Unit or Attribute based filtering.

When to filter, Inbound or Outbound?

Now we have to decide when to filter: Inbound, Outbound or both. My best practice is to always use Inbound filtering when possible. This way you limit the amount of objects that are imported in the Connector Space and subsequent the Metaverse. As stated earlier, this can also prevent the need for a full-fledged SQL server. The easiest forms are Domain and OU filtering and have my preference, but further fine tuning with Attribute filtering might be required.

To be clear, Domain and OU filtering are always Inbound filtering. The choice for Inbound and Outbound Filtering is determined by the requirements of your deployment. In most cases Inbound filtering has a major preference. It filters out objects at the most earliest stage, just before they are flowing to the Metaverse.

Outbound filtering happens when objects are moved from the Metaverse to the Connector Space of your Azure Active Directory (Azure AD), just before synchronization to Azure AD. This means that a lot of objects could be handled by AADSync are in the Metaverse/Database, costing resources while they are not being used. This is why Outbound filtering should only be used if Inbound filtering is not an option with the objects that need filtering. Obviously you can use Inbound filtering (with a different scope) in combination with Outbound filtering.

As of now I've only implemented Outbound filtering once. The situation required the synchronization from two Active Directory (AD) Forests, with almost identical objects which required to be matched and combined (see a follow up post on this subject). These scenarios (multiple AD forests need to sync objects to Azure AD) are the most likely candidates to use Outbound filtering, as it is possibly you might require matching to occur first before filtering unwanted objects. And matching occurs in the Metaverse, when Inbound filtering already occurred.

Figure 1. The process of Outbound Filtering, when two objects are joined. See text for clarification. Unedited source: https://msdn.microsoft.com/en-us/library/azure/dn800989.aspx

See figure 1 above: One forest was the "real" production forest and the other a hosted Lync resource forest. We used inbound OU filtering (See Inbound Synchronisation Rule, ISR in figure 1) with the production forest, but the hoster created (via a third party sync tool) all similar objects in one single OU which made this kind of filtering from that forest useless. Domain filtering also wasn't an option and attribute filtering also wasn't possible. This meant we probably would get a lot of objects in the Metaverse that shouldn't be synced to Azure AD, hence no ISR in that specific Attribute flow.

We decided to filter outbound (See Outbound Synchronisation Rule, OSR in figure 1) *after* (almost) identical objects where matched and combined in the Metaverse, using an attribute (AttributeA in figure 1) from our production forest. If the production object had the correct attribute value (AttributeA = True in figure 1) it would be synced to Azure AD, whether it was matched with its resource object counterpart or not.

If the resource forest had an object that didn't match with anything from the production forest, it would not get the correct attribute value and would never be synced to Azure AD. This way we assured that no lone object existing only in the resource forest would be synced and only objects from the production forest would be synced to Azure AD whether they are joined or not.

Example of Outbound Filtering

In this example we will configure outbound filtering by customizing an existing rule. We will filter objects that do not have ExtensionAttribute1 with value O365, meaning that (joined) objects that have this attribute with that value will be synced to Azure AD.

Open the Synchronization Rules Editor (in Start Menu).
In the left windows you see Inbound and beneath it Outbound. Select Outbound.
Find and select the rule named "Out to AAD – User Join" and click Edit.
Click on the Scoping Filter and click Add Clause.
In the clause for Attribute choose ExtensionAttribute1, as Operator select EQUAL and in the Value field enter O365. See Figure 2.
Click Save.
If you are confident that the rule is correct and everything else checks out, start a Full Synchronization.

Figure 2. In the clause for Attribute choose ExtensionAttribute1, as Operator select EQUAL and in the Value field enter O365.

Changes to filtering

If filtering has changed after previous synchronization runs and an object no longer falls within the selection this will result in a deletion in Azure AD. This is comparable when you delete an on-premises object which is subsequently deleted within Azure AD, or to be more precise moved to the Deleted Users recycle bin. When the deleted object falls within the filtering selection again, it will appear again as an active object within Azure AD. This is valid for any kind of filtering, Domain, OU, Attribute and Inbound or Outbound.

New or customized Filtering Rules

You can create new rules, but sometimes an existing rule already has (mostly) the correct scope. It is supported to customize existing rules (created during install and initial configuration). Be careful not to have overlapping scopes, as that could result in unexpected results and break normal operations, also depending on the Precedence of the rules.

However, new rules are retained when in-place upgrading AADSync, whereas customized existing rules might be reset to their default configuration after an upgrade. This is why you always have to check all rules before starting your synchronization again, especially Outbound Filtering rules.

Concluding

Filtering objects is essential in order to sync only the objects to Azure AD that are required. It can also limit your required resources. There are several methods that can be used, each with their own pros and cons: Domain, Organizational Unit or Attribute. Each a more specific way to filter objects. The preference is to filter early, meaning Inbound, and to keep filtering simple, meaning a greater focus towards Domain and OU filtering. However, there are situations, especially when more AD forests are involved, that Outbound and Attribute filtering are the only ways to keep you Azure AD lean and mean.

Changes in filtering can result in objects being deleted in Azure AD, so after changing filtering rules always check whether it had the expected result. If not, reverting the rule and start a synchronization again, should return the objects in an active state in Azure AD.

You can create new or customize existing (default) rules, but be sure to check whether they have reverted to their default configuration when upgrading AADSync.

In any case, a sound understanding about how AADSync works is required to know how and where to filter what.