Field Notes: Azure AD Connect – Group Filtering Gotchas

Active Directory, Identity 3 Minutes

This is a continuation of a series on Azure AD Connect. In the previous blog post, we looked at filtering options that can be used to control which objects are synchronized from on-premises directories to Azure AD – domain, OU and group filtering. I would like take a closer look at group filtering here, and discuss some gotchas that I briefly touched on in previous posts of this series. If you have not seen the previous blog post on object filtering using Azure AD Connect, I suggest you start here. Other related (previous) posts are provided in the summary section below.

Security Group Filtering

The filtering on groups feature allows you to synchronize only a small subset of objects for a pilot. Group-based filtering can be configured the first time Azure AD Connect is installed by using the custom installation option. Details are available in this document, which also highlights the following important points:

  • It is only supported to configure this feature by using the installation wizard
  • When you disable group-based filtering, it cannot be enabled again
  • When using OU-based filtering in conjunction with group-based filtering, the OU where the group and its members are located must be included (selected for synchronization)
  • Nested group membership is not resolved – objects to synchronize must be direct members of the group used for filtering

Let’s go through some cases to demonstrate:

(1) nested groups, and

(2) what happens when the group used for filtering is moved to a different OU.


The case of the nested group

In the previous post on filtering, we only had two user objects in the security group that we use for filtering – First Rockstar and Third Rockstar.

The name of the group is IDRS Sync in this example

I have just added a group named Nested Group to the sync group in order to demonstrate the requirement for direct membership. Members of the IDRS Sync group are now:

  • First Rockstar (user)
  • Third Rockstar (user)
  • Nested Group (security group)

Nested Group is a security group containing one member – Fourth Rockstar as shown above.

With this in place, a quick look at the Troubleshooting Task that I introduced here reveals that the object (Fourth Rockstar):

  • is found in the AD Connector Space
  • is found in the Metaverse
  • is not found in the Azure AD Connector space – no export

Fourth Rockstar is in the OU selected for synchronization. The account is also filtered out because it is not a direct member of the sync group.

In the Synchronization Service Manager, we can see that only the group was exported, but not the account that was added to the group itself. This confirms what the troubleshooting task picked up.


To get Fourth Rockstar synchronized, we would have to add the account as a direct member of the IDRS Sync group.


The case of the changed distinguished name

Let us now cover a scenario where the group used for filtering is moved to an OU that is not selected for synchronization. In this example, I moved the IDRS Sync group from the Sync OU to the VIP OU.

The distinguished name changed from CN=IDRS Sync,OU=Sync,DC=idrockstar,DC=co,DC=za to CN=IDRS Sync,OU=VIP,DC=idrockstar,DC=co,DC=za

If you look at the Synchronization Service Manager, you will notice that the group is removed from the on-premises directory connector and the metaverse. (The VIP OU is not selected for synchronization.)

It may appear that First Rockstar was not removed at first. It is still available in Azure AD at this stage. Remember that this was the only account that was in the OU selected for synchronization AND in the IDRS Sync group (previous blog post).

A synchronization cycle later, the object is deleted.

A quick refresh now shows that the account (First Rockstar) was deleted as a result of moving the IDRS Sync group to an OU that is not in scope of synchronization. This may not be a desired outcome!

Notice the error that clearly states what the problem is when we look at the filter users and devices page in Azure AD Connect. The distinguished name of the group has changed.

For my tenant, I am going with the synchronize all users and devices option to make life easy and align with the recommendation against use of this feature for production deployments.

Summary

I just went through two of the scenarios covering challenges that could be faced when using group filtering. Please note that this feature is currently only intended to support a pilot deployment and should not be used in production.

References

Related posts

Till next time…

Author

Published

One thought on “Field Notes: Azure AD Connect – Group Filtering Gotchas”

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