Filtering Options with Azure AD Connect

A recurring question in our M365 projects is „How can I prevent that my whole AD is synchronised to the Azure Active Directory?“
My answer is always: „You have multiple options and will be in full control at every moment!“

I’ve discussed the topic so often that I now have decided to write a blog post about this (by Microsoft well described) topic. Maybe I can just send the link to this post next time 😉

What can we filter?

Before we discuss the different filter approaches and conditions we have to define at which level and which information can be filtered:

Azure AD app and attribute filtering: „By enabling Azure AD app and attribute filtering, the set of synchronized attributes can be tailored. This option adds two more configuration pages to the wizard. For more information, see Azure AD app and attribute filtering.“

In my experience this optional feature is especially used in early phases of cloud adoption and/or regulated environments with the goal to limit the per user information in AAD to minimum needed. With the increasing adoption (and raising trust) of Office 365, this option gradually fades into the background. The used set of attributes is defined globally for all user, groups, contacts and devices in all connected Domains.

Object filtering: In contrast to attribute filtering, this is about which objects are synchronized to AAD and will be the main subject of this blogpost.

How can we filter objects?

For object filtering this options are available:

Sync filtering based on groups: „The filtering on groups feature allows you to sync only a small subset of objects for a pilot.“

This option was in almost every project I did the choice for the first phases because it offers an easy solution for starting a pilot.

Domain and OU filtering: „By default all domains and OUs are synchronized. If there are some domains or OUs you do not want to synchronize to Azure AD, you can unselect these domains and OUs.“

If you are maintaining a well organized AD you can just select the OUs for the needed users and groups and some default OUs (see link). If you’re not in that situation you can unselect some domains and OUs.

Attribute based filtering: „Attribute-based filtering is the most flexible way to filter objects. You can use the power of declarative provisioning to control almost every aspect of when an object is synchronized to Azure AD.“

With this option you are able to define a granular ruleset under which conditions an object is filtered. You can decide to use a white- or blacklisting approach per object type (user, group,…) and per connector (AD1, AD2,…)

Which option should I use?

Every option has it right to exist and will help in a specific situation. But I will try to provide some „rules of thumb“:

• Your best option is to use the OU filter. It will increase the sync performance and is easy to implement and maintain.
• Use the group filter for pilots, but don’t miss the right time to get rid of it. Use the group filter combined with the OU filter to prepare your exit. Removing the group filter will be much easier for you if you’re using the OU filter too.
• Use the Attribute filter only if you have a good reason. An example would be that you’re unable to separate the objects in different OUs.
• Only use attribute whitelist filters if you have advanced identity management tools like MIM in your environment.

Let’s take a detailed look at the attribute based filtering

While microsoft mainly differentiates between inbound and outbound filtering in the documentation, in my experience it is rather the question of whether a whitelisting or blacklisting approach is pursued.

In contrast to the other filtering methods, attribute-based filtering is not configured via the Azure AD Connect Wizard but via the Synchronization Rules Editor. This allows us a very high level of flexibility in filtering, but requires us to deal with the rather complex rule set of the AADC to some extent.
If you look at the best practices for using the Rules Editor, you can see that you can greatly reduce this need by not adapting existing rules, but always adding additional rules.

With regard to attribute-based filtering, the following points are particularly interesting:

• There is already a (relatively unknown) blacklisting option included in the default rule set – the adminDescription field. (here is a description). If you think a blacklisting approach is right and you can use the adminDescription field, this is the simplest and best approach.
• If you tailor your own solution with Custom Sync Rules the filtering is controlled by setting the value of the metaverse attribute cloudFiltered.

Blacklisting

The main advantages of blacklisting is that you only have to care about the blacklisted objects and the needed Custom Sync Rules are very simple. It is done by adding Custom Sync Rules setting the value of cloudFiltered to TRUE.
Since the Sync Engine evaluates an unfilled cloudFiltered attribute like FALSE, all objects to which no Custom Sync Rule applies are not filtered.

Here is a simple Blacklisting Custom Sync Rule. You can add multiple of this rules to get a logical OR.

Whitelisting

Whitelisting allows you to pick only the needed accounts by building Custom Sync Rules. Implementing a whitelist means technically to blacklist all objects and leverage the precedence to whitelist (cloudFiltered -> FALSE) some of them later. This means you need at least 2 Custom Sync Rules (per Object Type):

• a ‚catch-all-rule‘ that marks all users as filtered (cloudFiltered -> TRUE)
• one or more Whitelisting Rules with less precedence than the catch-all-rule marking some users as unfiltered (cloudFiltered -> FALSE)

Adding Custom Sync Rules

For both filtering approaches you need to modify the ruleset. So it’s a good idea to become familiar how to do this in a controlled and reproducable way. Here are some noteable facts about Sync Rules:

• Sync rules are defined
  • per Connector (AD1, AD2, AAD,..)
  • per Connected System Object Type (User, Contact, Group, …)
  • per Metaverse Object Type (device, group, person, publicFolder)
• Each Sync Rule has a precedence. The ruleset is applied in descending order of the precedence. Managed Sync Rules will always have a precendece >100. Custom Sync Rules will have a precedence <100.
• You can control in which order your Custom Sync Rules are applied by choosing the right precedence for each rule.
• After a modification of the Sync Ruleset a full (initial) sync is needed because the deltasync is only processing changes in the directories. This can take some time regarding your directory size. (see: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-performance-factors )
  If you have a bigger environment you definitively should have a test environment because it can take some time to apply changes.
• While creation a new Sync Rule should stay disabled. Build your rules disabled, schedule a time for the initial sync and disable the rules at this time.
• To identifiy the objects unique the AADC is using GUIDs for
  • every Connector
  • every Sync Rule
• Sync Rules can be exported as PowerShell Scripts in the Sync Rule Editor

My preferred method for integrating new sync rules is to:

1. implement the new rule(s) in my test environment with the Sync Rule Editor
2. test the ruleset
3. export the new rule(s) to PowerShell Scripts
4. prepare the rule(s) for the import in the next stage
5. import the rule(s) per PowerShell at the target

This approach is fairly straight forward and only point 4 requires some discipline in implementation. To allow us to import the rule on another system we have to make the following adjustments to the exported PowerShell scripts:

• Define the variables
  • $connector <- FQDN of your Domain as String
  • $precedence <- desired precedence value <100 (optional)
• Exchange the value (a GUID) at the parameter Identifier with the function ([guid]::NewGuid())
• Exchange the value (a Number) at the parameter Precedence with the variable $precedence (optional)
• Exchange the value (a GUID) at the parameter Connector with the function (Get-ADSyncConnector -Name $connector | Select -Expand Identifier)
• Delete the last 2 lines with the Get-ADSyncRule command

Object Filter and Exchange

If you use Exchange Online or Exchange Hybrid, your users will certainly have some expectations regarding the completeness of the address book. There are some conflicts and pitfalls to consider when using filtering, including:

• usually a number of groups have email addresses -> you can create a whitelisting sync rule scoped to groups with mail ISNOTNULL
• resources such as rooms or shared mailboxes are mapped as user objects in AD and must be considered in Exchange Hybrid -> you can create a whitelisting sync rule scoped to user objects on the basis of values of msExchRecipientTypeDetails (ask your exchange admin)

Conclusion

As I said in the introduction, there are some filtering options and the tools are flexible enough to meet a wide range of requirements. But before setting up – and regularly afterwards – it is very useful to check what is required for convenient service use and which objects / attributes really have filtering requirements. A careless filter can quickly cause unexpected effects.