Filtering directory identities from Hypersync

When dealing with hierarchical directory structures such as AD and ADLDS, it is a common requirement to filter objects from synchronization with downstream systems.

Traditional container filtering

With identity management systems such as MIM and AAD Connect, the most common approach to fulfilling this requirement has traditionally been to filter based on OU or container, thereby defining subtree scopes which are excluded from processing.

Alternative approaches are also adopted, such as filtering based on group membership or at the synchronization rule layer.  However, with MIM at least, there were generally considerable performance reasons which drove high adoption of the container/OU filtering approach.  This was because LDAP filtering applied on import to the staging area used for synchronization is often at orders of magnitude faster than staging all objects in a partition and then filtering by a rule expression(s).

For LDAP directories, HyperSync also supports both approaches, but without the performance penalties.  Similar to MIM's AD management agent, this at the Directory Provider level by specifying a collection of Containers to Include/Exclude for each referenced directory partition:

As with MIM, however, there are several downsides to the above approach.  When container filtering is implemented, objects filtered in this way

• cannot be accessed by for reporting within Identity Panel; and
• cannot be assigned to managed group membership.

Scoping Rules are another means by which implementers of HyperSync can exclude objects from being processed, but in order to use them they have to be associated with every sync rule.  For more globally applied filters this is not always practical and certainly not manageable for large rule sets.

Silo Filter Rules

Silo filter rules are used for identifying classes of identity filter out of HyperSync graph entirely.  This gives implementers of HyperSync a new, more effective way of applying global filtering, without the performance overhead that might be expected from an approach applied at the synchronization stage rather than the import stage.  Importantly, also without the administrative overhead of applying Scoping Rules to every attribute flow or stateful sync rule.

When migrating from MIM to Hypersync, consider the common scenario where an AD OU "MIMExclude" has been created specifically for excluding objects such as users and groups from the scope of MIM entirely.  This might be to temporarily bypass sync rule edge cases, or to deliberately exclude special user objects such as a AD group-managed service account (gMSA) from synchronization.

Of course, this can be achieved through the provider filtering approach described above, but that would mean creating a "blind spot" for HyperSync similar to the way it would have been for MIM.  Instead, a Silo Filter rule such as the one below can be used, whereby objects can still be excluded from synchronization, but are available for inclusion in both reporting and group membership management: