Mapping AD Groups to Roles

FortiSIEM provides the ability to map Microsoft Active Directory (AD) Groups to Roles. A user mapped to more than one Role has permissions for all roles following the Least Restrictive Role principle described below.

Follow these steps to map an AD Group to a Role:

Step 1: Setup or Edit an Authentication Profile

1. Log in to the FortiSIEM system.
2. Follow the instructions in Adding External Authentication Settings to setup a new profile or edit an existing profile. Currently, only LDAPS and LDAPTLS are supported for mapping AD Groups. The new or edited entry appears in the list of authenticated organizations.

Step 2: Create a Role to be Mapped to the AD Group

Follow the instructions in Adding a New Role to add a role that is to be mapped to an AD Group.

Step 3: Assign an AD Group

1. Click ADMIN > Settings > Role > AD Group Role.
2. Click New to create a new AD Group mapping or select a row and click Edit to edit an existing mapping.
3. Provide the following information in the Add AD Group Role popup:
   • Organization - Set to System (all organizations can use the information), Super/Local (only Super/Local can use the information).
   • AD Group DN - The AD Group domain name. Currently, the server must be either LDAPS or LDAPTLS.
   • Mapped Role - Scroll down the list for the role you want to map to. You can find descriptions of the predefined roles in Role Settings.
   • Comment - Enter an optional comment describing the mapping.

Step 4: Test Your Mappings

Test your mappings by logging out of the FortiSIEM session then logging back in as the LDAPS/LDAPTLS user.

You can use either the CN or the SamAccountName as the Username in FortiSIEM.

The following example account illustrates the options:

PS C:\Users\Administrator> Get-ADUser -Identity jdoe

DistinguishedName : CN=J Doe,OU=department1,DC=fortisiem,DC=lab

Enabled : True

GivenName : J

Name : J Doe

ObjectClass : user

ObjectGUID : 2386c3e6-d2c0-47b8-85d0-334585e959f

SamAccountName : jdoe

SID : S-1-5-21-87403157-1919951427-186658781-1620

Surname : Doe

UserPrincipalName : jdoe@fortisiem.lab

• Using the CN as the Username, for example:

  User: J Doe

  Password: ********

  Domain: local

• Using the SamAccountName as the Username, for example:

  User: fortisiem\jdoe

  Password: ********

  Domain: local

Principle of Least Restrictive Role

If a user belongs to two FortiSIEM Roles, then the user will have the rights of BOTH Roles.

• Case 1 - A node is explicitly defined in both role definitions. Then a user belonging to BOTH roles have the union of all permissions for that node. Explicit definitions mean that the node appears in the bottom Restrictions area when you view the Role in Settings > Role > Role Management. Some examples:

  One Role has READ permission on the RESOURCES tab, while the other Role has WRITE and EXECUTE permissions on RESOURCES tab. Then, a user belonging to BOTH roles has READ, WRITE, EXECUTE on RESOURCES tab.

  One Role has READ permission on the RESOURCES tab, while the RESOURCES tab is hidden in the other Role. Then, a user belonging to BOTH roles has READ permission on the RESOURCES tab.

• Case 2 - A node is not explicitly defined in one Role but explicitly defined in the other role. Then the user belonging to BOTH roles have the explicit permission defined in the second role. For example, a Full Admin role has nothing explicitly defined, because it has full permission on ALL nodes. If the user belongs to both Full Admin role and another role that can only READ the CMDB tab, then the user has only READ permission on the CMDB tab.
• Case 3 - A node is not explicitly defined in two Roles. Then the user belonging to BOTH roles has full permission on that node.