FortiAnalyzer
FortiAnalyzer can receive logs and Windows host events directly from endpoints connected to EMS, and you can use FortiAnalyzer to analyze the logs and run reports.
iyotov
Staff
Staff
Article Id 197813

Description

 

This article describes an example of configuring remote directory groups as remote administrators in FortiManager and FortiAnalyzer using LDAP.

The goal is to give admin rights to users that are members of certain AD security group.

This example uses Microsoft Active Directory since it is one of the most popular directory solutions.
With other LDAP servers, the implementation would be similar, but depending on their specifics, different attributes and/or filters may be required.


Solution

 

Active Directory side:
  • There is a primary domain controller at 10.0.0.1 and a secondary one at 10.0.0.2.
  • The test domain is called 'triton.lab'.
  • The users will be using their logon name (sAMAccountName attribute) on the FortiManager/FortiAnalyzer logon prompt.

  • OU 'RemoteAdmins' contains the security groups 'fmgAdmins' and 'fmgAdminsRO', and service user 'firewalls'.

  • User 'firewalls' is set with domain admin privileges and never expiring password, and will be used as LDAP bind user, in order to authenticate FortiManager/FortiAnalyzer to AD.
  • Users 'test1' and 'test2' are members of the security group 'fmgAdmins' and will be assigned unlimited access to FortiManager.
  • Users 'user1' and 'user2' are members of the security group 'fmgAdminsRO', which will be restricted to read-only access.
iyotov_0-1659714191827.png

 

 

FortiManager/FortiAnalyzer
 
There are two configuration variants available on FortiManager/FortiAnalyzer side.
The resulting admin authorization is generally the same, but the LDAP group search is different:
- Variant 1 searches for the User DN in the 'member' attribute of the specified Group.
- Variant 2 searches for the specified Group DN in the User's 'memberOf' attribute.
 
While in Active Directory the user-group reference is always matching on both sides, this may not be the case with some more open directory solutions.
For example, if in the directory users have no attribute containing the groups that are members of, but only the groups have attribute defining the member users, then Variant 2 below may require a directory specific filter string or may not work at all.
 
Variant 1 (available from version 6.0 onward):
 
In GUI go under System Settings - > Admin - > Remote Authentication Servers
Create one server object (AD1) for the 'fmgAdmins' group.
 
iyotov_4-1659716690853.png

And second server object (AD2) for the 'fmgAdminsRO' group.

 

iyotov_3-1659716634287.png
 
Verify that the 'member' attribute is present in the 'attributes' field (it is by default).
The 'filter' in this scenario should be (&(objectcategory=group)(member=*))
 
When the two LDAP server objects are ready, use in two wildcard admin users with different locally assigned permissions.
Go to System Settings - > Admin - > Administrators
Create one server object with server AD1 and assign the access profile Super_user for  the 'fmgAdmins' group.
 
iyotov_1-1659615826997.png
 
Create second server object with server AD2 and assign the access profile Read_User for the 'fmgAdminsRO' group.
Different ADOM and policy restrictions can be added the same way.
 
iyotov_5-1659717227258.png

 

To configure the same via CLI, use:


# config system admin ldap
   edit "AD1"
    set server "10.0.0.1"
    set secondary-server "10.0.0.2"
    set port 389
    set cnid "sAMAccountName"
    set dn "DC=triton,DC=lab"
    set type regular
    set username "CN=firewalls,OU=RemoteAdmins,DC=triton,DC=lab"
    set password ADpaSSword!2#
    set group CN=fmgAdmins,OU=RemoteAdmins,DC=triton,DC=lab
    set filter (&(objectcategory=group)(member=*))
   next
 end
# config system admin user
    edit "RemoteAdmins"
        set profileid "Super_User"
            set adom "all_adoms"
            set policy-package "all_policy_packages"
        set user_type ldap
        set ldap-server "AD1"
        set wildcard enable
     next
  end
 
# config system admin ldap
    edit "AD2"
    set server "10.0.0.1"
    set secondary-server "10.0.0.2"
    set port 389
    set cnid "sAMAccountName"
    set dn "DC=triton,DC=lab"
    set type regular
    set username "CN=firewalls,OU=RemoteAdmins,DC=triton,DC=lab"
    set password ADpaSSword!2#
    set group CN=fmgAdminsRO,OU=RemoteAdmins,DC=triton,DC=lab
    set filter (&(objectcategory=group)(member=*))
   next
 end
# config system admin user
    edit "RemoteAdmins"
        set profileid "Read_User"
            set adom "FortiAnalyzer"
            set policy-package "all_policy_packages"
        set user_type ldap
        set ldap-server "AD2"
        set wildcard enable
     next
   end

Note: If same AD group is set in both AD1 and AD2 or if the same server is used in multiple wildcard admins, the system will always match only the first object as in the CLI configuration order.

For the correct setup with same server used in multiple wildcard admins, see Variant 2 below.

 

Variant 2 (available from version 6.2 onward)

 

Another option to configure multiple admin objects, without separate server for each of them, is by using 'set ext-auth-group-match'

 

In the LDAP server object (System Settings - > Admin - > Remote Authentication Servers)

- leave the 'group' field blank.

- in 'memberof-attr' type the name of the attribute, defining the group membership within the users' attributes.
Since this is an Active Directory example, that attribute name is 'memberOf'.

 

iyotov_1-1659626926244.png

 

In this scenario, the group is configured in the wildcard admin, which allows the creation of multiple wildcard admin objects, matching different directory groups, but all under single LDAP server object.

Next, go to System Settings - > Admin - > Administrators and create the two wildcard administrators, required for assigning different permissions.

 

iyotov_3-1659627870718.png

 

iyotov_4-1659628531793.png

 

To configure the same via CLI, use:

 
# config system admin ldap
   edit "AD2"
    set server "10.0.2.1"
    set secondary-server "10.0.2.2"
    set port 389
    set cnid "sAMAccountName"
    set dn "DC=triton,DC=lab"
    set type regular
    set username "CN=firewalls,OU=RemoteAdmins,DC=triton,DC=lab"
    set password ADpaSSword!2#
    set memberof-attr "memberOf"

    unset group
    set filter (objectclass=*)
   next
 end

# config system admin user
    edit "RemoteSuperAdmins"
        set profileid "Super_User"
        set user_type ldap
        set ldap-server "AD2"
        set wildcard enable
        set ext-auth-group-match "fmgAdmins"

    next
    edit
"RemoteReadAdmins"
        set profileid "Read_User"
                           set adom "root"
            set adom-access specify
            set policy-package "all_policy_packages"
        set user_type ldap
        set ldap-server "AD2"
        set wildcard enable
        set ext-auth-group-match "fmgAdminsRO"

     next
  end
NOTE: The example in 'Variant 2' uses short group names. Which is possible in this case, because the 'cnid' of the LDAP server object is configured as 'sAMAccountName'.
If the attribute name used as 'cnid' in the server object is not defined for the groups, then the full DN of the group must be configured, in order to match the group correctly.
If unsure, always use the full DN format.
 
Extended version of 'Variant 2', using also ADOM and profile override attributes is available at:
 
In both variants, the users members of the configured groups can now login to FortiManager with their AD credentials.
- 'test1' and 'test2' will receive permissions based on the local access profile 'Super_User'
- 'user1' and 'user2' will receive permissions based on the local access profile 'Read_User'
- all other directory users will be denied access.

 

 

NOTE: In both scenarios described above, if no group is defined, but 'Match all users on remote server' (wildcard) is enabled, all directory users will be allowed to login.

 

Troubleshooting

The following diagnostic commands can be used for live debugging while reproducing the logon issue:

# diag debug application fnbam 255  <- Up to version 6.4.2

# diag debug application auth 255   -> From version 6.4.3

 

The output is similar in both cases and is fairly easy understand.
If one needs to open a support ticket for LDAP authentication or authorization issues, collect this debug output and attach it, together with the system config from CLI or a full backup file.

Contributors