Configuring profiles : Configuring LDAP profiles : Preparing your LDAP schema for FortiMail LDAP profiles : Using other schema styles
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 42: LDAP directory requirements for each FortiMail LDAP profile query
Object type
Attribute
Value
Query result
User Query Options
User object classes such as inetOrgPerson, inetLocalMailRecipient, 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.)
userPassword
Any.
Query verifies user identity by binding with the user password for any user defined by User Query Options.
User Alias Options
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”.
rfc822MailMember (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”.
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”.
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”.
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.
mailRoutingAddress
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.
Scan Override Options
(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.)
userPassword
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 69: Example compatible LDAP directory and LDAP profile