LDAP Servers

The FortiNDR system supports remote authentication of administrators using LDAP servers. To use this feature, configure the server entries in the FortiNDR unit for each authentication server in your network.

If you have configured LDAP support and require a user to authenticate using an LDAP server, the FortiNDR unit contacts the LDAP server for authentication. To authenticate with the FortiNDR unit, the user enters a username and password. The FortiNDR unit sends this username and password to the LDAP server. If the LDAP server can authenticate the user, the FortiNDR unit accepts the connection. If the LDAP server cannot authenticate the user, the FortiNDR unit refuses the connection.

The following options are available:

Create New	Select to add a LDAP server.
Edit	Select a LDAP server in the list and click Edit in the toolbar to edit the entry.
Clone	Select a LDAP server in the list and click Clone in the toolbar to clone the entry.
Delete	Select a LDAP server in the list and click Delete in the toolbar to delete the entry.

The following information is displayed:

Profile Name	The LDAP server profile name.
SERVER Name/IP	The server name and IP address of the LDAP server.
Port	The port number for the server.
Ref	The LDAP server's reference ID.

To add an LDAP server:

1. Go to User & Authentication > LDAP Server.
2. Click Create New. The Add New LDAP Server page opens.
3. Configure server settings.

   Profile name	Enter a name for the profile.
   Server name/IP	Enter the fully qualified domain name (FQDN) or IP address of the LDAP server. Port: Enter the port number where the LDAP server listens. The default port number varies by your selection in Use secure connection: port 389 is typically used for non-secure connections, and port 636 is typically used for SSL-secured (LDAPS) connections.
   Fall Back Server name/IP	Optional. Enter the fully qualified domain name (FQDN) or IP address of an alternate LDAP server that the FortiNDR unit can query if the primary LDAP server is unreachable. Port: Enter the port number where the fallback LDAP server listens. The default port number varies by your selection in Use secure connection: port 389 is typically used for non-secure connections, and port 636 is typically used for SSL-secured (LDAPS) connections.
   Use secure connection	Select whether or not to connect to the LDAP servers using an encrypted connection. None: Use a non-secure connection. SSL: Use an SSL-secured (LDAPS) connection. Click Test LDAP Query to test the connection. A pop-up window appears.
   Default Bind Options
   Base DN	Enter the distinguished name (DN) of the part of the LDAP directory tree within which the FortiNDR will search for user objects, such as ou=People, dc=example, dc=com. User objects should be child nodes of this location.
   Bind DN	Enter the bind DN, such as cn=fortiNDR, dc=example, dc=com, of an LDAP user account with permissions to query the Base DN.
   Bind password	Enter the password of the Bind DN. Click Browse to locate the LDAP directory from the location that you specified in Base DN, or, if you have not yet entered a Base DN, beginning from the root of the LDAP directory tree. Browsing the LDAP tree can be useful if you need to locate your Base DN, or need to look up attribute names. For example, if the Base DN is unknown, browsing can help you to locate it. Before using, first configure Server name/IP, Use secure connection, Bind DN, Bind password, and Protocol version, then click Create or OK. These fields provide minimum information required to establish the directory browsing connection.
   User Query Options
   LDAP user query	Click Schema to select a schema style. You can edit the schema as desired or select User Defined and write your own schema.
   Scope	Select the level of depth to query, starting from Base DN. One level: Query only the one level directly below the Base DN in the LDAP directory tree. Subtree: Query recursively all levels below the Base DN in the LDAP directory tree.
   Derefer	Select the method to use, if any, when dereferencing attributes whose values are references. Never: Do not dereference. Always: Always dereference. Search: Dereference only when searching. Find: Dereference only when finding the base search object.
   User Authentication Options	Enable to configure the authentication options. Select one of the followng from the dropdown. Try UPN or mail address as bind DN Try common name with base DN as bind DN Search user and try bind DN.
   Advanced Options
   Timeout (seconds)	Enter the maximum amount of time in seconds that the FortiNDR unit will wait for query responses from the LDAP server.
   Protocol version	Select the LDAP protocol version used by the LDAP server: LDAP Version 2 or LDAP Version 3.
   Allow Unauthenticated Bind	Disable bind authentication.
   Enable Cache	Enable to cache LDAP query results. Caching LDAP queries can introduce a delay between when you update LDAP directory information and when the FortiNDR unit begins using that new information, but also has the benefit of reducing the amount of LDAP network traffic associated with frequent queries for information that does not change frequently. If this option is enabled but queries are not being cached, inspect the value of TTL. Entering a TTL value of 0 effectively disables caching.
   Clear Cache	Select to empty the FortiNDR unit’s LDAP query cache. This can be useful if you have updated the LDAP directory, and want the FortiNDR unit to refresh its LDAP query cache with the new information.
   TTL (minutes)	Enter the amount of time, in minutes, that the FortiNDR unit will cache query results. After the TTL has elapsed, cached results expire, and any subsequent request for that information causes the FortiNDR unit to query the LDAP server, refreshing the cache. The default TTL value is 1440 minutes (one day). The maximum value is 10080 minutes (one week). Entering a value of 0 effectively disables caching. This option is applicable only if Enable cache is enabled.

4. Click OK.

To edit an LDAP server:

1. Go to User & Authentication > LDAPServer.
2. Select a profile and vlick Edit.
3. Configure the LDAP server setting and click Apply current settings. Optionally, you can click Reset settings to return to the default settings.
4. Click OK.

LDAP user query example

If user objects in your directory have two distinguishing characteristics, their objectClass and mail attributes, the query filter might be:

(& (objectClass=inetOrgPerson) (mail=$m))

where $m is the FortiNDR variable for a user's email address.

If the email address ($m) as it appears in the message header is different from the user’s email address as it appears in the LDAP directory, such as when you have enabled recipient tagging, a query for the user by the email address ($m) may fail. In this case, you can modify the query filter to subtract prepended or appended text from the user name portion of the email address before performing the LDAP query. For example, to subtract -spam from the end of the user name portion of the recipient email address, you could use the query filter:

(& (objectClass=inetOrgPerson) (mail=$m$

{-spam}))

where ${-spam} is the FortiNDR variable for the tag to remove before performing the query. Similarly, to subtract spam- from the beginning of the user name portion of the recipient email address, you could use the query filter:

(& (objectClass=inetOrgPerson) (mail=$m$

{^spam-}))

where ${^spam-} is the FortiNDR variable for the tag to remove before performing the query.

For some schemas, such as Microsoft ActiveDirectory-style schemas, this query will retrieve both the user’s primary email address and the user’s alias email addresses. If your schema style is different, you may want to also configure User Alias Options to resolve aliases. For details, see Configuring user alias options.

Alias member query example

If user objects in your directory have two distinguishing characteristics, their objectClass and mailattributes, the query filter might be:

(& (objectClass=alias) (mail=$m))

where $m is the FortiNDR variable for a user's email address.

If the email address ($m) as it appears in the message header is different from the alias email address as it appears in the LDAP directory, such as when you have enabled recipient tagging, a query for the alias by the email address ($m) may fail. In this case, you can modify the query filter to subtract prepended or appended text from the user name portion of the email address before performing the LDAP query. For example, to subtract -spam from the end of the user name portion of the recipient email address, you could use the query filter:

(& (objectClass=alias) (mail=$m${-spam}))

where ${-spam} is the FortiNDR variable for the tag to remove before performing the query. Similarly, to subtract spam- from the beginning of the user name portion of the recipient email address, you could use the query filter:

(& (objectClass=alias) (mail=$m${^spam-}))

where ${^spam-} is the FortiNDR variable for the tag to remove before performing the query.

Whether you should configure this query filter to retrieve user or alias objects depends on whether your schema resolves email addresses directly or indirectly (using references).

If alias objects in your schema provide direct resolution, configure this query string to retrieve alias objects. Depending on your schema style, you can do this either using the user name portion of the alias email address ($u), or the entire email address ($m). For example, for the email aliases finance@example.com and admin@example.com, if your LDAP directory contains alias objects distinguished by cn: finance and cn: admin, respectively, this query string could be cn=$u.

If alias objects in your schema provide indirect resolution, configure this query string to retrieve user objects by their distinguished name, such as distinguishedName=$b or dn=$b. Also enable User group expansion In advance, then configure Group member query to retrieve email address alias objects, and configure Group Member Attribute to be the name of the alias object attribute, such as member, whose value is the distinguished name of a user object.

Preparing your LDAP schema for FortiNDR LDAP profiles

FortiNDR units can be configured to consult an LDAP server for many things that you might otherwise normally have to configure on the FortiNDR unit itself, such as user authentication, group membership, mail routing, and other features. Especially if you have a large amount of users and groups already defined on an LDAP directory, you may find it more convenient to query those existing definitions than to recreate the definition of those same users locally on the FortiNDR unit. To accomplish this, you would configure an LDAP profile, then select that LDAP profile in other areas of the configuration that should use its LDAP queries.

LDAP profiles require compatible LDAP server directory schema and contents. Your LDAP server configuration may already be compatible. However, if your LDAP server configuration does not contain required information in a schema acceptable to LDAP profile queries, you may be required to modify either or both your LDAP profile and LDAP directory schema.

Verify your LDAP server’s configuration for each query type that you enable and configure. For example, if you enable mail routing queries, verify connectivity and that each user object in the LDAP directory includes the attributes and values required by mail routing. Failure to verify enabled queries can result in unexpected mail processing behavior.

Using common schema styles

Your LDAP server schema may require no modification if your LDAP server:

• Already contains all information required by the LDAP profile queries you want to enable

• Uses a common schema style, and a matching predefined LDAP query configuration exists for that schema style

If both of those conditions are true, your LDAP profile configuration may also be very minimal. Some queries in LDAP profiles contain schema options that automatically configure the query to match common schema styles such as IBM Lotus Domino, Microsoft ActiveDirectory (AD), and OpenLDAP. If you will only enable those queries that have schema options, it may be sufficient to select your schema style for each query.

For example, your LDAP server might use an OpenLDAP-style schema, where two types of user object classes exist, but both already have mail and userPassword attributes. Your FortiNDR unit is in gateway mode, and you want to use LDAP queries to use users’ email addresses to query for authentication.

In this scenario, it may be sufficient to:

1. In the LDAP profile, enter the domain name or IP address of the LDAP server.
2. Configure the LDAP profile queries:

   • In User Query Options, from Schema which OpenLDAP schema your user objects follow: either InetOrgPerson or InetLocalMailRecipient. Also enter the Base DN, Bind DN, and Bind password to authenticate queries by the FortiNDR unit and to specify which part of the directory tree to search.

   • In User Authentication Options, enable Search user and try bind DN.

   • Configure mail domains and policies to use the LDAP profile to authenticate users and perform recipient verification.