Fortigate policies based on Azure Dynamic Groups

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 "" 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.

Fortigate and Azure AD: Safe remote access

Within CSN Group, like the rest of the world, we work mostly from home this year. Our employees, therefore, need access to the resources within our data center from home. And that in a way that does not compromise data security. Consequently, we combine two of the best security products available: Fortigate firewalls and Azure Active Directory (Azure AD). Are you wondering how these products work together? I will explain it below.

Possibly it is redundant, but the security products separately do the following:

A Fortigate is a so-called next-gen firewall. This firewall offers broad protection against countless cyber threats. If properly configured, this firewall will fend off attacks such as ransomware. Also, it provides solutions for connectivity issues. For example, we connect sites to data centers based on SD-WAN technologies. The Fortigates offer the ability to give home workers secure access to network resources. It is a versatile device that will speak to the imagination of most people.

Azure Active Directory (Azure AD)
Azure AD is Microsoft’s Identity Manager. It is sometimes confused with the traditional Windows Active Directory. However, these are independent products. The products do have some similarities. For example, both can distribute authorizations and handle authentication requests. Azure AD also provides a central location for account administration and can address cloud applications’ above issues. For example, log in to Office 365 is handled by Azure AD, and the accounts within Azure AD can be linked to all SaaS applications so that you have one account that you can log in to anywhere. It eliminates the numerous separate accounts you have to remember for each online service.

How does CSN deploy these tools for secure home working?
Our employees who work from home through corona can securely access the necessary resources within the data center through the Fortigate SSL-VPN client. It creates a secure tunnel through the Internet from the endpoint to the Fortigate firewall. To keep things simple for employees, they use the same account as Office365. It includes using the same Multi-Factor Authentication (MFA). In our case, this is a push message that authorizes the login attempt with the push of a button. The diagram below shows the connection and authentication schematically:

What do our employees need to do to set up the connection? Watch it in the video below?

Technical interpretation
Now that we have covered the purpose, we can look at the technical interpretation. SAML handles the authentication. We are dealing with three stakeholders in this configuration:

  1. User: the employee who works from home and wants access to the content.
  2. Identity Provider: the party that contains the identities of the employees, or Azure AD.
  3. Service Provider: the party that provides access to the content, or Fortigate firewall.

Want to read more about the configuration? You’ll find all the details in this guide.

The configuration starts with creating an enterprise application within Azure AD. Enter the Fully Qualified Domain Name (FQDN) or the IP address of the Fortinet.

After the enterprise application is configured you can assign it to users. This authorizes employees to use the application. This can also be done on the basis of groups.

The employee can then easily find the connection by logging into Office365. Here you can find the shortcut.

If you followed the Fortigate-ssl-vpn-tutorial guide, the User and Identity Provider is now configured. Now only the Service Provider remains to be done. In this case, that is the Fortigate firewall. After the certificate is imported into the Fortigate, the SAML configuration can start.

Don’t forget to assign the SSL-VPN portal. SAML authentication is possible for web-access and tunnel-access.

As a final step, we need to provide the firewall with a security policy. In our case, we want to give the SSL-VPN users access to a specific application server with a fileshare and a database.

See the video below for the end user experience to setup an ssl-vpn connection

Read more about the specific security tools here: