Configuring user query options
The following procedure is part of the LDAP profile configuration process. For general procedures about how to configure an LDAP profile, see “Configuring LDAP profiles” on page 548.
- Go to Profile > LDAP.
- Click New to create a new profile or double click on an existing profile to edit it.
- Click the arrow to expand User Query Options
- Configure the query to retrieve the distinguished names (DN) of user objects by their email addresses.
Figure 227:User Query Options section
| GUI item | Description | |||
| Schema | If your LDAP directory’s user objects use a common schema style:
• InetOrgPerson • InetLocalMailRecipient • MS Active Directory • Lotus Domino select the schema style. This automatically configures the query string to match that schema style. If your LDAP server uses any other schema style, select User Defined, then manually configure the query string. |
|||
| Base DN | Enter the distinguished name (DN) of the part of the LDAP directory tree within which the FortiMail 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=FortiMailA,dc=example,dc=com, of an LDAP user account with permissions to query the Base DN.
This field may be optional if your LDAP server does not require the FortiMail unit to authenticate when performing queries, and if you have enabled Allow unauthenticated bind. For details, see “Allow unauthenticated bind” on page 567. |
|||
| 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. |
|||
| GUI item | Description | |||
| Scope | Select which 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. |
|||
| LDAP user query | Enter an LDAP query filter that selects a set of user objects from the LDAP directory.
The query string filters the result set, and should be based upon any attributes that are common to all user objects but also exclude non-user objects. For details, see “LDAP user query example” on page 553. This option is preconfigured and read-only if you have selected from Schema any schema style other than User Defined. For details on query syntax, refer to any standard LDAP query filter reference manual. |
|||
LDAP user query example
For 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 FortiMail 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 FortiMail 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 FortiMail 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” on page 557.
Configuring group query options
The following procedure is part of the LDAP profile configuration process. For general procedures about how to configure an LDAP profile, see “Configuring LDAP profiles” on page 548.
- Go to Profile > LDAP.
- Click New to create a new profile or double click on an existing profile to edit it.
- Click the arrow to expand Group Query Options
For more information on determining user group membership by LDAP query, see “Controlling email based on recipient addresses” on page 468 or ““Controlling email based on IP addresses” on page 475.
- Configure the following:
Figure 228:Group Query Options section
| GUI item | Description |
| Use LDAP tree node as group | Enable to use objects within the Base DN of User Query Options as if they were members of a user group object.
For example, your LDAP directory might not contain user group objects. In that sense, groups do not really exist in the LDAP directory. However, you could mimic a group’s presence by enabling this option to treat all users that are child objects of the Base DN in User Query Options as if they were members of such a group. |
| Group membership attribute | Enter the name of the attribute, such as memberOf or gidNumber, whose value is the group number or DN of a group to which the user belongs.
This attribute must be present in user objects. Whether the value must use common name, group number, or DN syntax varies by your LDAP server schema. For example, if your user objects use both inetOrgPerson and posixAccount schema, user objects have the attribute gidNumber, whose value must be an integer that is the group ID number, such as 10000. |
| GUI item | Description | |||
| Use group name with base DN as group DN | Enable to specify the base distinguished name (DN) portion of the group’s full distinguished name (DN) in the LDAP profile. By specifying the group’s base DN and the name of its group name attribute in the LDAP profile, you will only need to supply the group name value when configuring each feature that uses this query.
For example, you might find it more convenient in each recipient-based policy to type only the group name, admins, rather than typing the full DN, cn=admins,ou=Groups,dc=example,dc=com. In this case, you could enable this option, then configure Group base DN (ou=Groups,dc=example,dc=com) and Group name attribute (cn). When performing the query, the FortiMail unit would assemble the full DN by inserting the common name that you configured in the recipient-based policy between the Group name attribute and the Group base DN configured in the LDAP profile. Note: Enabling this option is appropriate only if your LDAP server’s schema specifies that the group membership attribute’s value must use DN syntax. It is not appropriate if this value uses another type of syntax, such as a number or common name. For example, if your user objects use both inetOrgPerson and posixAccount schema, user objects have the attribute gidNumber, whose value must be an integer that is the group ID number, such as 10000. Because a group ID number does not use DN syntax, you would not enable this option. |
|||
| Group base DN | Enter the base DN portion of the group’s full DN, such as ou=Groups,dc=example,dc=com.
This option is available only if Use group name with base DN as group DN is enabled. |
|||
| Group name attribute | Enter the name of the attribute, such as cn, whose value is the group name of a group to which the user belongs.
This option is available only if Use group name with base DN as group DN is enabled. |
|||
| Lookup group owner | Enable to query the group object by its distinguished name (DN) to retrieve the DN of the group owner, which is a user that will receive that group’s quarantine reports. Using that user’s DN, the FortiMail unit will then perform a second query to retrieve that user’s email address, where the quarantine report will be sent.
For more information on sending quarantine reports to the group owner, see “Quarantine Report Setting” on page 394 and “Managing the personal quarantines” on page 182. |
|||
| GUI item | Description | |||
| Group owner attribute | Enter the name of the attribute, such as groupOwner, whose value is the distinguished name of a user object. You can configure the FortiMail unit to allow that user to be responsible for handling the group’s quarantine report.
If Lookup group owner is enabled, this attribute must be present in group objects. |
|||
| Group owner address attribute | Enter the name of the attribute, such as mail, whose value is the group owner’s email address.
If Lookup group owner is enabled, this attribute must be present in user objects.
|
|||
Hi, on these instructions it states “personal black lists and white lists” on page 620.”
Where can i get the book to view page 620??
https://docs.fortinet.com/d/fortimail-5.4.0-administration-guide
That is a PDF version of the FortiMail documentation. 620 is referenced there.
Hello,
What about the confidence degree of Header Analysis (also called Deepheader Analysis)? The default value is 95.0, and statisticaly on dozen of emails, all the values are always within range 95,03- 95,09. What is really checked in headers ? In our organization (government – 5000 users) we have lots of SPAM catched but also lots of false positive catched by this feature…
Unfortunately the defaults are just “broad strokes”. A lot of tweaking is necessary to get things to where you are in your organization’s happy range of false positives vs missed spam.
Hello,
Do we have some addtional info regarding heuristic filter ? It is quite tricky to proceed with fine tuning with this light description. In my case, default settings just catch anything (around 10 emails out of 150’000… Now I have decreased threshold value to 3.0 and increased percentage of rules to 50% and now it catches around 200 emails out of 750’000 … still no false-positive.
Hello,
Is there a way to clear only one entry in the LDAP cache ? Since we have over 10’000 users and that there are multiple routers and FW between the SMTP Gateway and the LDAP servers we do not want to clear the whole cache.