Automated permissions based on properties
In many organizations, permissions are assigned based on the properties of the individual user. Whether it is the user’s department, location, status, or a custom value, DynamicGroup can automate permissions based on properties.
Index
Set conditions for group memberships with DynamicGroup
There are many ways to configure whether users should belong to a dynamic group or not. The most used configuration is the “Member Query” and especially the “Query Condition” option, which we will use in this article.
Via the “QueryCondition” (red) you can create complex filters over one or more AD attributes. These can be combined and nested with “AND” and “OR”.
In our example we have a filter with three conditions. The first condition (department equal “HR”) is mandatory and must be met in combination with the second or third condition
As you can see, the query condition is also automatically converted to a valid LDAP filter (blue). This conversion works in both directions. So if you already have an LDAP filter that matches your conditions, you can simply insert it here and continue using it.
In addition, it is always important to store the correct “Search Root” (green). Only users within this OU can become members of the dynamic group. You can read about this topic in detail in our article on site permissions.
However, easy creation and application of filters is not the only advantage of DynamicGroup. Besides, the dynamic groups are automatically updated for you. So, if any properties of a user account change, it will be automatically added to or removed from dynamic groups.
Automated authorizations – use cases
User inactive/disabled
A common use case is that user accounts that are inactive need to have permissions revoked. In this example, you see a query condition that ensures that all users in this dynamic group are active accounts.
The LDAP filter “(!userAccountControl:1.2.840.113556.1.4.803:=2)” is the crucial part here.
The dynamic groups update automatically. It means for users whose accounts are disabled, the permissions are automatically revoked.
It is also possible to explicitly add inactive users to a dynamic group. The following use case goes into more detail.
Authorization management in parental leave
Users who go on parental leave, or longer vacations, often need separate permissions. Here we can automate the permissions with DynamicGroup.
You can simply create a dynamic group in which all users who are on parental leave are.
In our example, the “parental leave” property is mapped via several attributes, including the inactive status of the user account. The additional value “employeeStatus” ensures that we are really only dealing with inactive users due to parental leave, since user accounts could of course also be inactive for other reasons.
Internal and external employees
Another use case for the “QueryCondition” is the separate handling of internal and external user accounts. We want to automate permissions based on a status. In our example, the user type is stored in the AD attribute “employeeType” and only users of type “internal” are included in this dynamic group.
This makes it easy to assign separate permissions for internal and external users.
Conclusion
By using DynamicGroup and the “Member Query” it contains, a wide range of use cases can be covered. Initial authorization assignment and group allocation work with automation easier. But you also have significantly less maintenance work and a higher security level.
Download 30 days trial and more information