Technical Tip: LDAP - Configuring Active Directory groups as remote administrators in FortiManager and FortiAnalyzer

[iyotov]

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.

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.

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

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.

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.

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 the 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 the 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 servers 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'.

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.

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 different from 'sAMAccountName' (ex. CN, UPN, UID, etc..), 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:

https://community.fortinet.com/t5/FortiAnalyzer/LDAP-Authorization-Using-LDAP-Attributes-for-ADOM-an... 

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