Almost every organization uses groups to assign permissions to employees. For example, these groups grant read or write admissions to a folder. The simple structure of groups keeps it clear for administrators whether they assign permissions to folders or printers or any other resource type.
Within the cloud era, groups are still relevant to assign permissions or resources. However, this requires a different approach.
The administration around group memberships still leaves much to be desired. Employees with many working years often collected a large backpack of group memberships. The dynamics of working have also changed over the years. The workspace tends to be more flexible and more project/team-oriented. To place these requirements in existing group structures is very difficult. In many organizations, there has been a sprawl of groups within their Active Directory.
As a result, many Active Directory contain a jungle of groups. I don’t need to explain why this is bad for IT security.
Azure AD Dynamic Groups
Within Azure AD, you can create groups that are populated based on a user account’s properties. These groups are called Dynamic Groups. For example, a group can be made based on the job title. It is, therefore, relatively easy to create a group with all managers of an organization. This group is also automatically updated. When a member no longer meets the requirements, Azure AD will remove the member.
Azure AD can use almost all user account properties to create membership rules.
The beauty of these Azure AD Dynamic Groups is that Fortigates can use them. (Read here how to set up your Fortigate SAML authentication with Azure AD) Access to resources is granted based on these dynamic groups. The employee can only access resources via the SSL-VPN if their account meets the Dynamic Group’s requirements.
In the examples below, I created two different groups. One is for the security team. The other is for the CSN Microsoft licensing specialists.
Describe the purpose of the dynamic group as concretely as possible and add it to the description
In the examples below, I created two different groups. One is for the security team. The other is for the CSN Microsoft licensing specialists.
Within Azure AD, create a new group. Specify that the membership type is: "Dynamic User". Next, add a "Dynamic query".
In the "Rule builder" you can specify what properties are needed to meet the group requirrements. In the example below, his job title should have something to do with "security".
Use the "validation rules" to check if the desired members meet the criteria By choosing a number of test persons you can quickly see if the rule works.
This group was created for the Microsoft licensing specialists of CSN Group.
When creating a Dynamic Group a welcome mail is sent to the members. You can disable this behavior in exchange online:
Set-UnifiedGroup -Identity "voorbeeldgroep@domein.nl" UnifiedGroupWelcomeMessageEnable:$false
The groups have been created. The object ID of the group is needed in the Fortigate configuration later on.
The object id of the group is used in the Fortigate configuration
By opening the group you can check if the desired members are present.
We also use the Dynamic Groups to assign the enterprise app "Fortigate SSL-VPN"
Gives a clear name to the attribute here. This will be needed later in the Fortigate configuration.
In the SAML user configuration of the Fortigate, place the name of the group attribute you just created.
In the group configuration of the Fortigate you create the new groups. In these groups, you specify the condition they must meet. In this case, the "group-name" must match the "Object-id" of the group in Azure AD.
The newly created groups can now be used to allocate resources. In other words. They can be used in the Fortigate security policies.