Description
This article describes how to configure and troubleshoot LDAP authorization with custom attributes for ADOM and access-profile override on FortiManager/FortiAnalyzer.
The example below 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.
Another LDAP scenario with different logic and only group match is described at:
https://community.fortinet.com/t5/FortiAnalyzer/Technical-Note-Configuring-Active-Directory-groups-a...
Scope
FortiManager/FortiAnalyzer version 6.2.2 and newer.
Solution
To use ADOM and access profile overrides, specific directory attributes must be defined for the users.
In Active Directory, edit the respective user/s and go to Attribute Editor (View - > 'Advanced Features' may need to be enabled first under Active Directory Users and Computers).
Select two unused string type attributes from the list.
In this example, the multi-valued string 'extensionName' will be used for ADOM override, since it allows multiple ADOMs to be assigned to the user.
The access profile attribute should be a single-value string, for example 'profilePath'
The values assigned to these attributes should match exactly (incl. upper/lower case) ADOM and admin profile names existing on FortiManager/FortiAnalyzer
Once the attributes are configured on directory side, configure the attribute names on FortiManager/FortiAnalyzer, under the LDAP server object.
To configure the same in CLI (the syntax may vary slightly across the different firmware versions):
# config system admin ldap
edit "AD1"
set server "10.0.0.1"
set secondary-server "10.0.0.11"
set cnid "sAMAccountName"
set dn "DC=triton,DC=lab"
set type regular
set username "CN=firewalls,OU=RemoteAdmins,DC=triton,DC=lab"
set password P@55_w()Rd
set memberof-attr "memberOf"
set profile-attr "profilePath"
set adom-attr "extensionName"
set filter (objectclass=*)
next
end
Configure a 'wildcard' admin user with default 'Admin Profile' and ADOM settings set, for example to 'No_Permission_User' and some empty ADOM.
Make sure that 'ext-auth-adom-override' and 'ext-auth-accprofile-override' are enabled.
To configure the same in CLI (the syntax may vary slightly across the different firmware versions):
# config system admin user
edit "LDAP_Users"
set profileid "No_Permission_User"
set adom-access specify
set adom "empty_adom"
set policy-package "all_policy_packages"
set user_type ldap
set ldap-server "AD1"
set wildcard enable
set ext-auth-accprofile-override enable
set ext-auth-adom-override enable
next
end
With the above configured, when 'user1' logs into FortiManager/FortiAnalyzer with their logon name (sAMAccountName in this case), the respective users should be granted restricted access to modify only the UTM profiles in ADOM1, ADOM2, ADOM3.
Another directory user can be given different permissions by only modifying the respective directory attributes, without further FortiManager/FortiAnalyzer configuration changes.
Troubleshooting:
There are three main problem scenarios:
• Connectivity issues
• Misconfiguration on LDAP server side
• Misconfiguration in the FortiManager/FortiAnalyzer settings
The following CLI commands can be used to troubleshoot LDAP issues on FortiManager/FortiAnalyzer:
# diag debug application fnbam 255 <- Up to version 6.4.2.
# diag debug application auth 255 <- From version 6.4.3
# diag sniffer packet any “host <server_ip> and port <ldap_port>” 3 0 a
There is also packet capture available in GUI - > System Settings - > Network
The default ports are 389 for LDAP, or 636 for LDAPS/STARTTLS, but those can be customized, so if the server is not replying, confirm on which port it is listening for LDAP queries.
Then make sure that TCP/<ldap_port> is allowed on the intermediate network devices and in the server firewall.
In LDAP the communication is in plain text, including the bind credentials and user passwords.
In such case, one can see both the underlying TCP connection, as well as the LDAP related binds, search requests and the respective server responses.
This is useful, in order to confirm if FortiManager/FortiAnalyzer is using correct bind credentials, if the search requests are generated correctly, and if the LDAP server returns the expected attribute values.
In LDAPS the transmission is encrypted and the LDAP related payload is not readable, but the capture can be still useful to rule out connectivity or SSL/TLS related issues.
Once confirmed that FortiManager/FortiAnalyzer can communicate with the LDAP/S server, the above mentioned CLI debug can be used to verify if the attribute values are parsed correctly, and what ADOMs and profiles are assigned to the user.
The examples below explain how to read the debug outputs from both versions of the debug command (Select the images to enlarge)
Output from 'diag debug application fnbam 255', version <= 6.4.2
Output from 'diag debug application auth 255', version >= 6.4.3
If one needs to open a support ticket for LDAP authentication or authorization issues, collect this debug output and attach it, together with the relevant system config from CLI or a full backup file.
In case of connectivity issues, a packet capture would be also required.
