Tweaking 389 Directory Server

The 389 Directory Server is one of the most important parts of your Kolab deployment, as it is the sole authoritative source of all user, group, role, resource, shared folder and mail routing information and configuration.

Controlling Indexes and Indexing

Indexes are created for individual attributes, and may consist of one or more of the following three types:

  1. Presence

    A presence index for attributes services queries with a filter such as “(cn=*)”.

  2. Equality

    An equality index for an attribute services queries with a filter such as “(mail=john.doe@example.org)”.

  3. Substring

    A substring index for an attribute services queries with a filter such as “(mail=*joh*)”.

Presence and substring indexes may be used with, for example, auto- completion, while equality indexes may be used in, for example, LDAP lookup tables for Postfix.

Listing the current indexes for a database could be done using a script such as:

Adding new attribute indexes for a database, and executing the task to create the index, could be done with a script such as:

Configuring Virtual List View Control

Virtual List View features in the LDAP server aid in listing pre-indexed and pre-sorted LDAP entries in a paginated fashion, and is a required configuration item for deployments with over 1.000 entries in their LDAP hierarchies [1], when also using an address book, auto-completion and/or the Web Administration Panel.

On the side of the LDAP server, Virtual List Views consist of two separate configuration items:

  1. The search, with a base dn, scope and filter.

  2. The index that includes the Server-Side Sorting parameters.

For an LDAP client to successfully use Virtual List View controls, it is crucially important that:

  1. The search base dn and scope match the configuration of the VLV search, and

  2. Any attributes searched in addition to the configured VLV search filter are appropriately indexed.

By default, the configuration of primarily the Kolab web client uses the following configuration parameters for browsing the LDAP address book:

For Individual Contact Entries

  • Search Base DN: ou=People,$root_dn

    where $root_dn is the relevant root suffix, such as dc=example,dc=org.

  • Search Scope: sub

  • Search Filter: (objectClass=inetOrgPerson)

Note

The search parameters for address book entries are deliberately not limited to only include other Kolab user entries.

The configuration for the LDAP address book also lists the order of attributes to use when sorting the entries:

  1. displayname,

  2. sn,

  3. givenname,

  4. cn

This configures the LDAP server to first attempt sorting by displayname attribute value, then sn, then givenname, etc.

When two entries hold the same value for an attribute used with sorting, the next attribute configured for sorting is used, if any.

When configuring the sorting attributes, only use combinations of meaningful attributes, and preferrably as few as possible at a time.

When, for example, you want one list to be sorted by user’s names, and another list sorted by phone number, do not combine the two different lists in to one sorting configuration. Instead, use multiple values for the vlvSort attribute.

For Groups

  • Search Base DN: ou=Groups,$root_dn

    where $root_dn is the relevant root suffix, such as dc=example,dc=org.

  • Search Scope: sub

  • Search Filter: (|(objectClass=groupOfUniqueNames)(objectClass=groupOfUrls))

Note

For groups too, the search parameters for address book entries are deliberately not limited to only include other Kolab user entries.

The configuration for the LDAP address book also lists the order of attributes to use when sorting the entries:

  1. cn

Creating the VLV and SSS configuration objects in an LDAP server may be achieved using the following example scripts, in order:

  1. Creating the VLV Search configuration in LDAP:

    https://git.kolab.org/kolab-scripts/plain/populate-ldap/10a-add-vlv-searches.sh

  2. Creating the VLV Indexes with Sorting configuration in LDAP:

    https://git.kolab.org/kolab-scripts/plain/populate-ldap/10b-add-vlv-indexes.sh

  3. Subsquently, the index tasks should be executed:

    https://git.kolab.org/kolab-scripts/plain/populate-ldap/10c-run-vlv-index-tasks.sh

Configuring Server-side Sorting Control

Server-side Sorting control is a pre-requisite for Virtual List View control.

If you are using Virtual List View (see Configuring Virtual List View Control), you are also already using Server-Side Sorting.

Increasing the Maximum Number of File Descriptors

A 389 Directory Server is configured to open at most 1024 so-called file descriptors, which include database pointers, logs, replicas, statistics and (client) network sockets.

Increase the default number of maximum open file descriptors from 1024.

To change the number to 8192:

  1. Edit /etc/sysconfig/dirsrv, adding a line:

    ulimit -n 8192
    

    Note

    Note that your operating system may have other security limitations, and may have a system-wide limitation on the number of files as well. See sysctl fs.file-max for your current limit.

  2. Stop the directory server:

    # service dirsrv stop
  3. Edit /etc/dirsrv/slapd-*/dse.ldif and replace the following line:

    nsslapd-maxdescriptors: 1024
    

    with:

    nsslapd-maxdescriptors: 8192
    
  4. Start the directory server back up:

    # service dirsrv start

Disabling the 7-bit Password Enforcement

By default, 389 Directory Server has enabled a plugin to only allow passwords to consist of 7-bit characters.

Older systems and software applications do not support the use of 8-bit characters (i.e., non-ASCII) in passwords, and to prevent compatibility issues, this plugin is enabled by default.

To allow 8-bit characters, disable the 7-bit check plugin:

# ldapmodify -x -h localhost -D "cn=Directory Manager" -W
Enter LDAP Password:
dn: cn=7-bit check,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: off

modifying entry "cn=7-bit check,cn=plugins,cn=config"

A restart of the directory service is required for this change the become active:

# service dirsrv restart

Disabling the Access Logs

Access logs are accounts of new connections, searches and other such information about who accesses what, where from, and when.

In larger environments, this log can grow very large, very quickly, and while disk space consumption is the lesser concern, the related disk I/O may be more relevant.

Larger environments could choose to put /var/log/dirsrv/ on a separate disk (separate from /var/lib/dirsrv/), possibly even in-memory tmpfs, or disable the access logs altogether.

To disable the access logs, run the following command:

# ldapmodify -x -h localhost -D "cn=Directory Manager" -W
Enter LDAP Password:
dn: cn=config
changetype: modify
replace: nsslapd-accesslog-logging-enabled
nsslapd-accesslog-logging-enabled: off

modifying entry "cn=config"

The directory server does not need to be restarted for this setting to take effect.

Enabling the Audit Logs

Audit trails are important, especially when the access logs have been disabled.

Audit logs include diffs of LDAP entries being modified, along with a timestamp and the credentials used. As such, despite explicitly lacking the source of the modification, provided a set of differentiated bind credentials per service allowed to modify LDAP entries this can still be a complete audit trail.

To enable the audit logs, run the following command:

# ldapmodify -x -h localhost -D "cn=Directory Manager" -W
Enter LDAP Password:
dn: cn=config
changetype: modify
replace: nsslapd-auditlog-logging-enabled
nsslapd-auditlog-logging-enabled: on

modifying entry "cn=config"

The directory server does not need to be restarted for this setting to take effect.

Footnotes