SLAPD.conf Customization

By default slapd looks for an existing slapd.d (dynamic configuration) directory and if it is not found it will load from the static slapd.conf file. Since you are planning on using slapd.conf the default will be fine.

Global Section

Server ID

Each server in an OpenLDAP cluster has a serverID. If it is not specified in slapd.conf it will default to zero. We recommend that even in a single-server configuration, you set systemID to something other than zero. That way, if you decide to add another master server to the cluster for higher availability, you won’t have to reload your first server to activate replication between the masters. The server id block needs to come first in the slapd.conf file and must be an integer between 1 and 4095.

The server ID can also be specified as a 3-digit hexadecimal with a prefix of “0x”. Each Producer server in the replication architecture will require its own unique server identification number. The syntax for producer servers when replication is configured is as follows:

    serverID    1

NOTE: for devops customers (i.e. Chef, Puppet, Ansible, etc): The serverIDs for multiple producer servers may be identified in a single slapd.conf file as follows:

    serverID    1    ldap://<producer 1 server's FQDN>/
    serverID    2    ldap://<producer 2 server's FQDN>/

Caution: This creates an easy single point of failure as serverIDs are required on producers in a replicated environment and changes to the firewall, closing of ports or modifications of hostnames/FQDNs would all cause a serverID configured this way to be ignored, thus breaking replication. Any changes in the server’s URI must be reflected in the slapd.conf file.

Schemas

The schema block comes next in the slapd.conf file. Schemas define objectClasses and attributes for entries being used in the database.

NOTE: The /opt/symas/etc/openldap/schema directory is removed and recreated during the update/upgrade process. If custom schemas are in use, place them the /opt/symas/etc/openldap/custom_schemas directory to avoid accidental deletion.

The syntax is as followings.

    include     /opt/symas/etc/openldap/schema/core.schema 
    include     /opt/symas/etc/openldap/schema/ppolicy.schema 
    include     /opt/symas/etc/openldap/custom_schemas/your_private.schema

PID/ARG Paths

The Process Identification and custom Arguments (specific slapd process start-up requirements) file paths block comes next. These paths must contain the absolute name of the files that will hold the LDAP server’s process ID and LDAP server’s process command line options. These PID file path must match what is configured in the symas-openldap.conf file. The syntax is as follows:

    pidfile      /var/symas/run/slapd.pid
    argsfile     /var/symas/run/slapd.args

TLS Security Settings

The next block in the slapd.conf file is the TLS Security Section. The items configured here are extremely important and must be correct. Otherwise, it may not be possible to connect to the LDAP server, or replication and chaining may not work. See the OpenSSL Certificates section of Securing the Connection for more information on certificate creation and TLS Security Section configuration options. See the Security and Ciphers section of Securing the Connection for more details on available settings. The following contains a recommended example syntax:

    TLSCACertificateFile         /opt/symas/ssl/cacert.pem
    TLSCertificateFile           /opt/symas/etc/openldap/slapdcert.pem
    TLSCertificateKeyFile        /opt/symas/etc/openldap/slapdkey.pem
    TLSCipherSuite HIGH:MEDIUM
    TLSVerifyClient try
    TLSProtocolMin 3.1

If SASL Authentication/Connectivity is in use, this section will also contain any “authz” user information. See the SASL Connectivity section of Securing the Connection for more information. The example syntax below contains the user that “does” replication.

    authz-regexp "email=XXXXX,cn=([^,]*),YYYYYY" "cn=replicator,dc=symas,dc=com"

Threads & Tool-Threads

The threads configuration parameter controls the size of the pool of threads used to process LDAP operations. The default value (16) has been found to be reasonable for most platforms, and most deployment scenarios. In some cases, the server may perform better if it is lowered. In a few cases (such as systems with many (>=4) CPUs), a higher number may be better. High values (even 32) may cause resource exhaustion and/or significant resource contention. One should bench the server under load before and after the change to see if the change had any significant impact. Unless the benching indicates that the change resulted in significant improvement, the change should be undone. The rule of thumb for the threads setting is to multiply the number of processor cores by four. The example syntax follows:

    threads 16

Symas OpenLDAP supports threaded slapadd. This is only useful if running slapadd on a multi-cpu box. Generally, assign 1 thread per CPU. This specifically affects the creation of index databases, so if the number is indices is fewer than CPUs, set the value to the number if indices instead. With MDB backends, ‘tool-threads’ is hard coded to 2 and setting it to anything higher can actually slow things down. The example syntax follows:

    tool-threads 2

Modules

There are two kinds of optional modules: backends and overlays. Backends implement databases. Backends are dynamically loaded by slapd when it starts up.

Overlays provide hooks to functions that extend base OpenLDAP capabilities. Password Policy is implemented by an overlay module (ppolicy), for example.

Essentially, overlays can:

• Customize the behavior of existing backends without changing the backend code and without requiring one to write a new custom backend with complete functionality, or
• Add function that can be applied to different backend types

The modulepath specifies a list of directories to search for loadable modules. The default directory for Symas OpenLDAP is /opt/symas/lib64/openldap, which is where the standard OpenLDAP install will place its modules. The syntax is as follows:

    modulepath     /opt/symas/lib64/openldap

The modules to be loaded are listed using the moduleload configuration. Filenames may be absolute path names or a simple filenames Non-absolute names are searched for in the directories specified by the modulepath option. While the order of modules is normally irrelevant. back-meta is built on top of back-ldap so it is required that back_ldap.la be loaded before back_meta.la.

The syntax follows:

    moduleload     back_mdb.la
    moduleload     back_monitor.la
    moduleload     ppolicy.la
    moduleload     syncprov.la
    moduleload     accesslog.la
    moduleload     pw-sha2

Included Modules:

Overlay configurations take advantage of loaded modules.

Access Control Lists (ACLs)

Broadly, an ACL associates

• What is being operated on?
• Who is requesting the operation?
• What type of operation is requested?
• See slapd.access man page (https://kb.symas.com/v2.4.45.4/man5/slapd.access/) for details

“Access to by ”

What:

    dn[.dnstyle]=<dnpattern>
    filter=<ldapfilter>
    attrs=<attrlist> [val[/matchingRule][.attrstyle]=<attrval>]
    = all entries
    <dnstyle> = (base|one|sub|children|regex)
    <attrlist>=(<attr>|[(!|@)]<objectClass>)[,<attrlist>]
    <attrstyle>=(base|one|sub|children|regex)

Who:

• • • everyone
• anonymous = unauthenticated clients
• users = all authenticated clients
• self = users whose DN matches the target entry
• dn = explicit DN
• dnattr = an DN-valued attribute in the entry
• group = the list of members in a group entry
• peername = the socket address of the client
• sockname = the socket address of the server listener
• domain = the DNS name of the client
• sockurl = the URL of the server listener
• set = ACL sets
• ssf = overall security strength factor
• transport_ssf = transport level SSF
• tls_ssf = tls-specific SSF
• sasl_ssf = SASL-specific SSF

SSF - Security Strength Factor

The server uses Security Strength Factors (SSF) to indicate the relative strength of protection. A SSF of zero (0) indicates no protections are in place. A SSF of one (1) indicates integrity protection are in place. A SSF greater than one (>1) roughly correlates to the effective encryption key length. For example:

    DES = 56
    3DES = 112
    AES = 128, 192, or 256

A number of administrative controls rely on SSFs associated with TLS and SASL protection in place on an LDAP session. Security controls disallow operations when appropriate protections are not in place. For example:

    security ssf=1 update_ssf=112

This requires integrity protection for all operations and encryption protection, 3DES equivalent, for update operations (e.g. add, delete, modify, etc.).

Privilege Access Level:

• none = no access
• auth = authentication
• compare = Compare operations
• search = search filter evaluation
• read = search results
• write = modifications
• manage = all access including administrative access

Each level includes the preceding ones

Privilege Rights:

• m, w, a, z, r, s, c, x, d, 0 - can be used to assign individual rights instead of levels m for manage, w for write, a for add, z for delete, r for read, s for search, c for compare, x for authentication, d for disclose, and 0 (zero) for no access.
• Use (+ | - | =) modifiers to add, remove, or replace rights.

NOTE: +0 is standalone and cannot be combined with any other access privileges.

Evaluation

ACLs are evaluated in the order in which they appear in the configuration

• Most specific rules must appear before general rules
• Evaluation usually stops at the first match

Additional controls may be specified to alter the evaluation sequence Evaluation controls

• Stop = stops evaluation at the current rule
• Continue = keep examining other clauses within the same rule
• Break = keep examining other rules

Example for slapd.conf:

    access to dn.subtree="dc=example,dc=com"
      by * =cs break
    access to dn.subtree="ou=people,dc=example,dc=com"
      by * +r

• Gives Compare and Search access to all entries in the tree to all users
• Adds Read access for all entries in the “ou=people” subtree

Example for slapd.d

    olcAccess: to dn.subtree="dc=example,dc=com" by * =cs break
    olcAccess: to dn.subtree="ou=people,dc=example,dc=com" by * +r

Service-Type ACLs

Access rules for replication or service-type accounts. Since the rule is very specific and in the case of the replication user, will be evaluated often, this rule should be near the top of the ACL.

Common Directory Structure/Entries

    ou=admin,dc=example,dc=com
      + cn=replicator
      + cn=updater
    ou=groups,dc=example,dc=com
      + cn=read_all
        member: cn=replicator,ou=admin,dc=example,dc=com
      + cn=write_all
        member: cn=updater,ou=admin,dc=example,dc=com

Replication/Service Account ACL

    access to *

Examples (slapd.conf vs. slapd.d):

SLAPD.CONF (default)

    access to dn="" by * read
    access to *
    by self write
    by users read
    by anonymous auth
    by sockurl="^ldapi:///$" write

SLAPD.D (default)

    olcAccess: {0}to dn.base="" by * read
    olcAccess: {1}to * by self write by users read by anonymous 
    auth by sockurl.exact="^ldapi:///$" write

• Allow all to read rootDSE
• Entries can write to self
• Authenticated users may read
• Unauthenticated users may use attributes for authentication
• Unix domain sockets may write

SLAPD.conf

    Access to attrs=userPassword
        by self write
        by anonymous auth
        by dn="cn=admin,dc=example,dc=com" write
        by * none
    Access to dn.base=""
        by dn="cn=admin,dc=example,dc=com" read
    Access to *
        by dn="cn=admin,dc=example,dc=com" write
    Access to dn.subtree="dc=qa,dc=example,dc=com"
        by dn="cn=admin,dc=qa,dc=example,dc=com" read by * break
    Access to dn.children="dc=qa,dc=example,dc=com"
        by self write
        by dn="cn=admin,dc=qa,dc=example,dc=com" write 
        by dn.children="dc=qa,dc=example,dc=com" read 

SLAPD.D

    olcAccess: {0}to * by
    dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth 
    manage by * break
    olcAccess: {1}to attrs=userPassword by self write by anonymous 
    auth by dn="cn=admin,dc=example,dc=com" write by * none 
    olcAccess: {2}to dn.base="" by dn="cn=admin,dc=example,dc=com"
    read
    olcAccess: {3}to * by dn="cn=admin,dc=example,dc=com" write
    olcAccess: {4}to dn.subtree="dc=qa,dc=example,dc=com" by
    dn="cn=admin,dc=qa,dc=example,dc=com" read by * break 
    olcAccess: {5}to dn.children="dc=qa,dc=example,dc=com" by 
    self write by dn="cn=admin,dc=qa,dc=example,dc=com" 
    write by dn.children="dc=qa,dc=example,dc=com" read

• Every authenticated user can change their own password
• The user cn=admin,dc=example,dc=com can read the base DN
• The user cn= admin,dc=example,dc=com can modify everything everywhere
• The user cn=admin,dc=qa,dc=example,dc=com can read the subtree dc=qa DN
• All dc=qa members can modify themselves
• The user cn=admin,dc=qa,dc=example,dc=com can modify all subtree dc=qa content
• All dc=qa members can read the subtree dc=qa content

ACL Creation Suggestion:

Print a copy of the DIT from Apache Directory Studio Use multiple colored pens to identify who you want to have what kind of access to what portion of the DIT Note any areas that overlap as additional ACLs will be required to clearly define those areas.

Limits

The next block specifies connection time and entry return limits. Use the sizelimit option to specify the maximum number of entries to return from a search operation. The default size limit is 500. Use unlimited to specify no limits. The syntax is as follows:

    sizelimit {<integer>|unlimited}

A second format allows a fine grain setting of the size limits. Extra args can be added on the same line.

    sizelimit size[.{soft|hard|unchecked}]=<integer> [...]

Use the timelimit option to specify the maximum number of seconds (in real time) slapd will spend answering a search request. The default time limit is 3600. Use unlimited to specify no limits. The syntax is as follows:

    timelimit {<integer>|unlimited}

A second format allows a fine grain setting of the time limits. Extra args can be added on the same line.

    timelimit time[.{soft|hard}]=<integer> [...]

For the more granular limits setting, specify time and size limits based on the operation’s initiator or base DN. The argument can be any of

    anonymous | users | [<dnspec>=]<pattern> | group[/oc[/at]]=<pattern>