Preparing your LDAP schema for FortiMail LDAP profiles

FortiMail units can be configured to consult an LDAP server for many things that you might otherwise normally have to configure on the FortiMail 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 FortiMail 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
• your LDAP server 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 FortiMail 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, select from Schema which OpenLDAP schema your user objects follow: either InetOrgPerson or InetLocalMailRecipient. Also enter the Base DN, Base DN, and Bind password to authenticate queries by the FortiMail unit and to specify which part of the directory tree to search.
   • In User Authentication Options, enable the query with the option to Search user and try bind DN.

Figure 236:Example LDAP profile configuration for user email address and authentication queries to an OpenLDAP-style directory

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

Using other schema styles

If your LDAP server’s schema is not one of the predefined common schema styles, or if you want to enable queries that require information that does not currently exist in your directory, you may need to adapt either or both your LDAP server and LDAP profile query configuration.

Before modifying your LDAP directory, verify that changes will be compatible with other applications using the directory. You may prefer to modify the LDAP profile query and/or add new attributes than to modify existing structures that are used by other applications, in order to reduce the likelihood of disruption to other applications. For instructions on modifying schema or setting attribute values, consult the documentation for your specific LDAP server.

The primary goal when modifying your LDAP directory is to provide, in some way that can be retrieved by LDAP profile queries, the information required by FortiMail features which can use LDAP profiles. Depending on the LDAP profile queries that you enable, you may need to add to your LDAP directory:

• user objects
• user group objects
• email alias objects

Keep in mind that for some schema styles, such as that of Microsoft ActiveDirectory, user group objects may also play a double role as both user group objects and email alias objects. For the purpose of FortiMail LDAP queries, email alias objects can be any object that can be used to expand email aliases into deliverable email addresses, which are sometimes called distribution lists.

For each of those object types, you may also need to add required attributes in a syntax compatible with the FortiMail features that uses those attributes.

At a minimum, your LDAP directory must have user objects that each contain an email address attribute, and the value of that email address attribute must use full email address syntax (for example, mail: user@example.com). This attribute is required by User Query Options, a query which is required in every LDAP profile.

Many other aspects of LDAP profiles are flexible enough to query for the required information in more than one way. It may be sufficient to modify the query strings and other fields in the LDAP profile to match your individual LDAP directory.

For example, the purpose of the User Query Options is to find the distinguished name (DN) of user objects by their email addresses, represented by the FortiMail variable $m. Often user objects can be distinguished by the fact that they are the only records that contain the attribute-value pair objectClass: User. If the class of user name objects in your LDAP directory is not objectClass: User but instead objectClass: inetOrgPerson, you could either modify:

• the LDAP profile’s user query to request user objects as they are denoted on your particular server, using objectClass=inetOrgPerson; for example, you might modify the user query from:

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

to be:

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

• the LDAP server’s schema to match the queries’ expected structure, where user objects are defined by objectClass=User

Alternatively, perhaps there are too many user objects, and you prefer to instead retrieve only those user objects belonging to a specific group number. In this case, you might modify the query string from:

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

to be:

(&(objectClass=User)(gidNumber=102)(mail=$m))

You can use any attribute-value pairs to filter the query result set, as long as they are unique and common to all objects in your intended result set.

For example, most directories do not contain an antivirus processing switch attribute for each user. However, FortiMail units can perform antivirus processing, which can be switched off or on depending on the results from an LDAP query. The FortiMail unit expects the query to return a value that may use Boolean syntax (TRUE or FALSE) that reflects whether or not, respectively, to perform antivirus processing. In this case, you would add to user objects in your LDAP directory an antivirus attribute whose value is a Boolean value.

The following table indicates expected object types, attribute names, and value syntax, as well as query results, for each LDAP profile query. Attributes listed should be present, but their names may vary by schema. Attributes that do not have a default name require that you configure them in both your LDAP profile and your LDAP directory’s schema. Table 54:LDAP directory requirements for each FortiMail LDAP profile query

Object type	Attribute	Value	Query result
User Query Options
User object classes such as inetOrgPerson, inetLocalMailR ecipient, User, dominoPerson.	mail	A user’s email address.	Query compares the email address to the value of this attribute to find the matching user, and retrieve that user’s distinguished name (DN), which is the basis for most other LDAP profile queries.
Group Query Options
(Objects from User Query Options.)	gidNumber or memberOf	Varies by schema. Typically is either a group number or the distinguished name (DN) of the group.	Query retrieves the group name for any user defined by User Query Options.
(Objects from User Query Options.)	mail	A user’s email address.	Query uses the DN retrieved from groupOwner to retrieve the email address of the user specified by that DN.
User group object classes such as group or groupOfNames.	groupOwner	A user object’s DN.	Query retrieves the DN of a user object from the group defined in gidNumber or memberOf.
User Authentication Options
(Objects from User Query Options.)	userPasswo rd	Any.	Query verifies user identity by binding with the user password for any user defined by User Query Options.
User Alias Options

Table 54:LDAP directory requirements for each FortiMail LDAP profile query

Email alias object classes such as nisMailAlias, or user objects from User Query Options, depending on whether your schema resolves email aliases directly or indirectly, respectively. For details, see “Base DN” on page 558.	rfc822Mail Member (for alias objects) or mail (for user objects)	Either the user name portion of an email address (e.g. user; for alias objects), or the entire email address (e.g. user@example .com; for user objects).	Query expands an alias to one or more user email addresses. If the alias is resolved directly, this query retrieves the email addresses from the alias object itself. If the alias is resolved indirectly, this query first queries the alias object for member attributes, then uses the DN of each member in a second query to retrieve the email addresses of those user objects. For details, see “Base DN” on page 558.
User group object classes such as group or groupOfNames. User groups are not inherently associated with email aliases, but for some schemas, such as Microsoft ActiveDirectory, group objects play the role of email alias objects, and are used to indirectly resolve email aliases. For details, see “Base DN” on page 558.	member	A user object’s DN, or the DN of another alias object.	Query retrieves the DN of a user object that is a member of the group. This attribute is required only if aliases resolve to user email addresses indirectly. For details, see “Base DN” on page 558.
Mail Routing Options
(Objects from User Query Options.)	mailHost	A fully qualified domain name (FQDN) or IP address.	Query retrieves the fully qualified domain name (FQDN) or IP address of the mail server — sometimes also called the mail host — that stores email for any user defined by User Query Options.
	mailRoutin gAddress	A user’s email address for a user account whose email is physically stored on mailHost.	Query retrieves the email address for a real account physically stored on mailHost for any user defined by User Query Options.
AS/AV On/Off Options

Table 54:LDAP directory requirements for each FortiMail LDAP profile query

(Objects from User Query Options.)	No default attribute name.	Varies by schema. May be: •      TRUE, YES, 1, ENABLE or ENABLED (on) •      FALSE, NO, 0, DISABLE, or DISABLED, or any other value not associated with “on” (off)	Query retrieves whether or not to perform antivirus processing for any user defined by User Query Options.
	No default attribute name.	Varies by schema. May be: •      TRUE, YES, 1, ENABLE or ENABLED (on) •      FALSE, NO, 0, DISABLE, or DISABLED, or any other value not associated with “on” (off)	Query retrieves whether or not to perform antispam processing for any user defined by User Query Options.
Address Mapping Options
(Objects from User Query Options.)	No default attribute name.	A user’s internal email address.	Query retrieves the user’s internal email address
	No default attribute name.	A user’s external email address.	Query retrieves the user’s external email address.
Enable webmail password change
(Objects from User Query Options.)	userPasswo rd	Any.	Query, upon successful bind using the existing password, changes the password for any user defined by User Query Options.

Each LDAP profile query filter string may indicate expected value syntax by the FortiMail variables used in the query filter string.

• $m: the query filter expects the attribute’s value to be a full email address
• $u: the query filter expects the attribute’s value to be a user name
• $b: the query filter expects the attribute’s value to be a bind DN

The following example illustrates a matching LDAP directory and LDAP profile. Labels indicate the part of the LDAP profile that is configured to match the directory schema.

Figure 237:Example compatible LDAP directory and LDAP profile

Figure 238:Example LDAP profile (part 1)

Figure 239:Example LDAP profile (part 2)