Nested AD filters for group memberships
Authorizations should be assigned quickly, but correctly. Assigning authorizations using nested AD filters is best automated, most likely using a PowerShell script. Quick and easy, right?
It may seem simple at first, but as soon as the required AD filters become more complex, are nested or need to be customized, this can quickly become a problem. Suddenly, the colleague who created the script back then is no longer there. Or it was so long ago that he is simply no longer sure how exactly it actually works. Not to mention that the script becomes slower and slower the more users and groups it has to process. The AD LDS also responds slowly to complex LDAP queries with deeply nested AD filters on a Windows server, especially if the attribute values are empty.
Now IT is facing a problem because the automation of AD group authorizations with complex nested filters is too slow. It can only be adapted to the new rules with a great deal of effort.
Here you will find DynamicGroup as an alternative to PowerShell for creating nested AD filters.
Index
Practical scenarios: Nested AD filters for granular authorizations
The conditions on the basis of which an authorization is granted are often complex and must fulfil various criteria. The reason for this is simple: a variety of factors influence which rights a user has. The department, country and status are frequently used values, but the title or another group membership can also be decisive.
For example, we have received cases that look like this in anonymized form:
– A user should be in department “Sales” or “HR“, but not have the title “Head of department“.
– A computer should have a name that contains “-A” or “-B” and ends with “007“. It should also not be located in a specific OU.
– A user should be active, employed in “Germany“, “Austria” or “Switzerland“, and in the “IT” or “Development” department.
In addition to these fixed rules, there can also be exceptions, which only adds to the complexity of the solution.
Now, of course, we don’t just have one such condition, but dozens – each with its own special cases. If we want to solve all this in PowerShell, we need a good structure and perhaps even outsourced modules. But even with the best intentions, such a script will always be difficult to maintain and slow in large AD structures.
What are “nested AD filters”?
A filter is described as nested if it is made up of many different conditions that are linked to each other. If we visualize such a filter graphically, a tree structure with several levels is created. Complex attribute-based authorizations are based on nested AD filters.
Via the “Active Directory Users and Computers” console, as well as via PowerShell, we can only map such filters using LDAP. LDAP offers the full range of possibilities, but is difficult to maintain with very complex filters and therefore prone to errors.
Nested AD filters with DynamicGroup
DynamicGroup, on the other hand, offers the option of editing the filter as LDAP as well as in a graphical user interface as a tree structure. We can also convert between the formats, for example import an existing LDAP filter and display it as a tree structure before customizing it.
DynamicGroup simplifies the management and maintenance of group memberships with nested AD filters thanks to a simple configuration, without losing compatibility with familiar LDAP.
In contrast to PowerShell, colleagues who are not so familiar with scripting can also take over.
In addition, special cases for the defined rules can be easily configured in DynamicGroup using the include and exclude lists.
This leaves the question of performance: here, too, our tests show that PowerShell is decidedly slower than DynamicGroup. The more complex the conditions are, the clearer the speed gain of DynamicGroup becomes. Our application is up to 25x faster than PowerShell.
How does DynamicGroup help?
How would we implement a scenario like the one in our examples in DynamicGroup?
We start by analyzing the filter in detail and breaking it down into the individual sub-conditions and links.
So let’s take a closer look at the first example:
A user should be in department “Sales” or “HR”, but not have the title “Head of department”.
This results in the following sub-conditions, which are linked with “And”:
- User should be filtered
- Filtered by department; there are again two sub-conditions linked with “Or”
- Filtered by title
The first sub-condition is a special case that is set in DynamicGroup using a checkbox. This further simplifies the resulting tree structure and results in the following picture:
We can see that the resulting LDAP filter already contains complicated parentheses and links, although this search query is still relatively simple.
Thanks to DynamicGroup, we no longer have to worry about this, and we can create and test the filter quickly and easily. Thanks to the “Preview” function, we can check a new or modified filter for a correct result list before saving it.
Summary
Nested AD filters are often necessary to implement fully automated attribute-based authorizations (ABAC). DynamicGroup greatly simplifies the administration and maintenance of these filters, speeds up implementation and improves automation.
About FirstAttribute
FirstAttribute is an independent cloud services and software company focused on Identity & Access Management (IAM) for AD and M365/Entra ID. You can learn more about our team at Company.
DynamicGroup has been a popular tool for AD administrators for many years to manage group memberships in AD in a coordinated and secure way. The application is used worldwide by companies in a wide range of industries. Continuous updates ensure that the application remains up to the growing demands in IT and does exactly what it promises.
DynamicSync is an automation software for cloud groups. As a pure cloud service (SaaS), DynamicSync specializes in dynamic and automatic group synchronization in Entra ID.