Directory
Currently, this page mainly discusses generic slapd configuration pieces for slapd.conf that apply to both the master and the replica. The last directives section on this page is specific to replicas.
schemacheck on
This directive means that all changes will be forced to follow the defined schemas loaded via include statements in the conf file.
allow bind_v2
This directive tells slapd to allow LDAP v2 binds
TLSCertificateFile /etc/ldap/HOSTNAME.cert
TLSCertificateKeyFile /etc/ldap/HOSTNAME.key
TLSCACertificateFile /etc/ldap/comodo-full.pem
This portion sets up the SSL cert and key used for TLS. It also specifies the CA certificate file to use for verifying certs.
include /usr/local/etc/openldap/slapd.acl
Include this file in slapd.conf. We seperate our ACL's into their own file for easier management.
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
These directives say where to write out SLAPD's PID, and arguments that SLAPD was started with.
loglevel 256
Put syslog logging at level 256. We have found this gives a useful amount of information about the directory's activity.
threads 8
This tells slapd to use 8 threads. The default is 16. Note that increasing or decreasing the number of threads used can drastically effect performance, and more threads does NOT necessarily mean better performance. In most cases, increasing the number of threads reduces performance significantly, unless one has many real CPUs. We found 8 threads to be optimal for our setup, but it can be different under other operating systems and depending on the total number of CPUs available.
idletimeout 30
This directive tells slapd to close connections that have been idle for 30 seconds or more.
sasl-realm stanford.edu
sasl-host HOSTNAME.stanford.edu
sasl-authz-policy both
sasl-regexp uid=service/(.*),cn=stanford.edu,cn=gssapi,cn=auth ldap:///cn=Service,cn=Applications,dc=stanford,dc=edu??sub?krb5PrincipalName=service/$1@stanford.edu
sasl-regexp uid=webauth/(.*),cn=stanford.edu,cn=gssapi,cn=auth ldap:///cn=Webauth,cn=Applications,d c=stanford,dc=edu??sub?krb5PrincipalName=webauth/$1@stanford.edu
sasl-regexp uid=(.*),cn=stanford.edu,cn=gssapi,cn=auth ldap:///uid=$1,cn=Accounts,dc=stanford,dc=ed u??sub?suSeasStatus=active
The above directives define how our SASL configuration will work. The first line sets our SASL realm to stanford.edu, which is what our K5 realm is. The second line simply configures this host.
The third line (sasl-authz-policy) allows proxy authorization if it is configured. We do not configure it, so this line is essentially meaningless at this time.
The sasl-regexp lines are particularly critical. They are what rewrite incoming connections who have SASL formatted DN's to the DN's that are in the directory DB. It is important to remember that they are processed in order, so you want to write them from most specific to most general.
lastmod on
This directive keeps "modifyTimeStamp" updated for entries. It is useful to have this data at hand sometimes.
database bdb
shm_key 5
suffix "dc=stanford,dc=edu"
rootdn "cn=Manager,dc=stanford,dc=edu"
directory /db
These directives configure the database environment. They say we will use the BDB backend to slapd, and that we will use a shared memory segment to store the BDB environment. The database will have a root suffix of dc=stanford,dc=ed The rootDN, which has world write access, is cn=Manager,dc=stanford,dc=edu The directory to store index files is /db
I have found the shm_key directive to only be useful on Solaris. It is not needed on Linux for databases that fit into available memory.
limits group="cn=ldapadmin,cn=applications,dc=stanford,dc=edu" time=unlimited size=unlimited
This directive states that the ldapadmin group has the capability to make unlimited searches in the database.
checkpoint 1024 5
This directive checkpoints the database every 1024 bytes (1 MB) of written information or the passage of 5 minutes of time. Checkpointing your data often is a good thing to do, as it minimizes slapd shutdown time, and minimizes the potential to lose data in unexpected situations (like a power loss).
cachesize 20000
This directive tells slapd to store the 20,000 most accessed entries in memory. Having a properly configured cachesize can drastically affect performance. See the OpenLDAP FAQ for more information.
idlcachesize 20000
This directive tells slapd to store the 20,000 most used IDL's frequented when accessing entries in memory. Having a properly configured IDL cachesize can drastically affect performance. Each IDL holds the search results from a given query, so the IDL cache will end up holding the most frequently requested search results.
index default eq
index cn eq,sub
index sn eq,sub,approx
index uidNumber
The above directives configure the types of indexing to be performed on the listed attributes. The very first directive says that the default type of indexing to use, if none is specified, is eq. So, for the uidNumber entry, it will be indexed eq.
Type types of possible indexing are:
pres, eq, approx, sub, none
"pres" indexing allows you to use filters that ask if the attribute is present in an entry (cn=*).
"eq" indexing allows you to use filters to ask if an attribute has an exact value ("gn=quanah").
"approx" indexing allows you to use filters to ask if an attribute value "sounds like" something. This is tied to the --enable-phonetic compile option in OpenLDAP. ("sn~=book") could return book, hook, nook.
"sub" indexing allows you to use filters that do substring searches on an attribute's values. A filter of ("cn=*mount*") will return all values of cn containing the letters "mount".
Some information about why indexing is important is available at OpenLDAP's FAQ-O-Matic
reverse-lookup on
This directive turns on reverse lookups. This means that if a system connects to OpenLDAP as "joe.stanford.edu", OpenLDAP will validate that the IP address supplied matches the IP address returned when doing a lookup on "joe.stanford.edu".
database monitor
Enable the monitor backend to slapd.
updatedn cn=replicator,cn=service,cn=applications,dc=stanford,dc=edu
updateref ldaps://ldap-master.stanford.edu
These two directives are specific to replicas. They say that the DN allowed to update the replica is "cn=replicator" and that the connection will be an SSL connection from "ldap-master.stanford.edu"
