Field Notes: Azure Active Directory Connect – Domain, OU and Group Filtering

Active Directory, Identity 3 Minutes

This is a continuation of a series on Azure AD Connect. The recently published blog post covers a quick introduction to the troubleshooting task available in Azure AD Connect. This post goes through options that are available in Azure AD Connect to apply filtering on objects that should be synchronized. I provide links to all other related posts in the summary section below.

Filtering in the Azure AD Connect installer

The Azure AD Connect sync: Configure filtering document goes through a lot of detail on how you can control which objects appear in Azure AD based on filtering options that are configured. The scope of this post is just the following options, which are available in the Azure AD Connect installer:

  • Domain-based filtering
  • Organizational unit (OU)-based filtering, and
  • Group-based filtering

Domain and OU based filtering

I am combining the domain and OU filtering options as they are covered in one screen of the installation wizard. Using the installation wizard is the preferred way to change both domain-based and OU-based filtering. To get to this screen, we need to follow the custom installation path of the installation wizard. I cover this option here, and I’ll just skip to the place where we have the ability to customize synchronization options. This option is available under additional tasks once custom installation is selected.

This additional task requires credentials of a global administrator account in the Azure AD tenant to proceed. Provide a valid set and click next to move on.

The next screen shows the directories that are already configured. I only have one forest – idrockstar.co.za.

We are now at the first filtering option – domain and OU. To simplify demonstration, I synchronize everything in the child domain (east.idrockstar.co.za) and only the Sync OU in the root domain (idrockstar.co.za).

Let’s explore the second filtering option.


Group based filtering

Moving along brings us the second part – filter users and devices. Here, we specify a group containing objects that we wish to synchronize.

Note that this is currently only intended for pilot deployment scenarios. Nested groups are not supported and will be ignored.

Provide either the name or the distinguished name of the group and resolve to validate, then click next to proceed. This will be followed by selecting optional features and finalizing the configuration.


Testing the effect of filtering

For demonstration and testing, I created three accounts as follows:

  • First Rockstar – in the synchronized OU and a member of the sync group
  • Second Rockstar – in the synchronized OU and not a member of the sync group
  • Third Rockstar – not in the synchronized OU and a member of the sync group

Synchronization Service Manager

Let’s take a quick look at the synchronization manager to see what happens. Only one of the three objects we just created is exported.

Clicking the adds link under export statistics takes us to the object. The properties button exposes details. In this case, we see the object that matches both the OU and group membership synchronization requirements – First Rockstar.

I’ll cover the synchronization service in detail in a future blog post.

Azure Active Directory

To confirm, I also logon to the Azure AD tenant, select users and search for rockstar. The search only returns the only account that was synhronized, which met the criteria.


Summary

I just covered the two synchronization filtering options available in the Azure AD Connect installer – domain/OU and group-based filtering. I’ll take a closer look at the synchronization service in the follow up blog post soon.

References

Related posts

Published

2 thoughts on “Field Notes: Azure Active Directory Connect – Domain, OU and Group Filtering”

  1. Pingback: Field Notes: Azure Active Directory – Group Filtering Gotchas – Secure Infrastructure Blog
  2. Pingback: Field Notes: Azure Active Directory – Attribute-based Filtering – Secure Infrastructure Blog

Leave a Reply