Chapter 15. LDAP Security

LDAP Security Overview
OpenLDAP SASL Configuration
OpenLDAP SASL - TLS Configuration
OpenLDAP TLS Configuration
OpenLDAP TLS/SSL Mixed Access Configuration

LDAP Security Overview

LDAP and especially OpenLDAP has a number of security features which at first (second and third) glance may be a tad daunting. Figure 15-1 provides a perspective of the problem before diving into detail. It shows the various access methods and interfaces to an LDAP system and then describes some security issues and what methods are available to manage the risks involved. The purpose of this exercise is to determine either a set of security policies or implementation priorities.

Figure 15-1 Security Perspective

All numbers in the descriptions below refer to Figure 15-1.

Remote Communications (1): Remote communication security may or may not be an issue. If you provide unlimited (anonymous) access to non-sensitive LDAP data then the security issue is moot. Caution: In these circumstances you potentially become vulnerable to DoS/DDoS attacks through malicious LDAP query loads - so even this apparently trivial environment may need careful consideration.

If all LDAP communications can be guaranteed to occur within a trusted network then you may elect to operate with simple cleartext passwords without additional security. However, even in these cases it may be a simple matter, depending on the trusted network topology, to sniff traffic and either inspect sensitive data (1-2) or obtain passwords (1-1) sent in the clear.

When communication occurs across an untrusted network then snooping, sniffing, man-in-the-middle and other possibilities provide endless hours of fun for wannabee attackers. Also bear in mind that the use of On-Line Configuration (OLC) (a.k.a cn=config) and monitoring (cn=monitor) will make it attractive to use remote LDAP browsers for administering and managing LDAP servers. This traffic is, by its very nature, highly sensitive.

Assuming that some level of security is required the first question to be addressed is - do I need to protect only passwords (1-1) or do I need to protect data (1-2) and passwords (1-1)? Depending on the answer to that question will determine the next step.
Passwords (1-1): Securing passwords during communications should not be confused with securing them within configuration files or DITs. Even if you have secured all passwords within the configuration file or the DIT using a hash-method, such as {SSHA}, when a password is sent from a client to the server for authentication it is sent in the clear, hashed at the server and compared with the stored contents. Without any further action it can therefore be snooped (or sniffed depending on your predilection for these terms). Note: When an entry containing, say, a userPassword attribute stored using, say, {CRYPT} is requested by a client it is not sent in cleartext but in its hashed (stored) form. However, when access to that same entry is required for authentication the client sends the password in cleartext and clearly(!) if the login is successful the snooper can reasonably assume the cleartext password was correct.

When hashed passwords are sent in a snoopable data stream they can become vulnerable to a dictionary attack - the attacker has the hashed form and runs a list of passwords (a dictionary) through the hashing algorithm until a match is found. Using salt (one or more octets - depending on the implementation - are added to the password before hashing and removed before comparison) significantly improves the security of hashed passwords and unless there are good reasons for not doing so the salted form of any hashing algorithm should always be used. ACLs should be used to limit access to passwords other than specifically authorized users. For example assuming a userPassword attribute the following ACL will only allow the attribute to be sent to the owner of the entry or a specific (admin) group of users:
```
# OLC (cn=config) form
olcAccess: to attrs=userpassword
 by self       write
 by anonymous  auth
 by group.exact="cn=admin,ou=groups,dc=example,dc=com" write
 by *          none

# slapd.conf format
access to attrs=userpassword
 by self       write
 by anonymous  auth
 by group.exact="cn=admin,ou=groups,dc=example,dc=com" write
 by *          none
```
If only passwords require to be safeguarded then the solution is to use SASL with an ALGORITHM such as CRAM-MD5 which performs a secure handshake (using a shared secret) and during which dialog the password never appears in cleartext ( SASL configuration examples). The alternative is to use TLS/SSL (with or without SASL) or Kerberos 5. In this case simple password mechanisms can be used since the whole communication stream is encrypted and therefore snoop-proof.

Finally overlay ppolicy provides features to control aging, complexity and mandatory resets as well as other characteristics of the passwords being used.
Data (1-2): If the data originating from an LDAP server needs to kept snoop-proof then the only solution is to encrypt the entire data stream using TLS/SSL (with SASL, without SASL) or Kerberos (SASL). The down-side to this approach is that encryption is a CPU intensive process and if resource usage or performance is a major consideration then the choice of bulk encryption methods available within the TLS/SSL suite becomes very important (configure TLS/SSL and configure TLS/SSL via SASL). It is possible to mix and match communication. If, for example, it is deemed adequate to use simple cleartext passwords (or even run anonymously) for normal remote LDAP access but additional protection is required when running certain classes of users (configuration samples for mixed TLS/SSL and SASL access).

While the discussion so far has concentrated on merely gaining access to data - what about changes and modifications to that data? OpenLDAP provides two capabilities to generate audit information. The overlay auditlog (more info use 'man slapo-auditlog') and overlay accesslog both provide features to log changes to the underlying DIT and accesslog even provides capabilities to record binds and read/search access as well as save previous contents of entries or attributes.
Local Access (2): Local access is defined to be any event that occurs within the LDAP server or server cluster (or through secured remote access such as provided by ssh) and includes most obviously config files/directories (2-1) and locally issued commands (2-2).
Config Files (2-1): There are two components to be considered here:
1. Ownership and permissions: By default modern LDAP systems run with low privilege user/group accounts (normally ldap:ldap). OpenLDAP loads with root permissions (to allocate privileged ports) before dropping down quickly to its normal (low) operational privileges: when using OLC (cn=config) OpenLDAP demands a minimum of 0750 permissions under its operational user account (normally ldap:ldap) but does not set appropriate permissions unlike with the old slapd.conf which would be automatically set to 0600.
2. Passwords: Passwords that appear in the slapd.d directories (for OLC , cn=config use) and config file (slapd.conf) such as olcRootPw/rootpw are especially sensitive. Consideration should be given to removing both olcRootDn/rootdn and olcRootPw/rootpw completely once a DIT has been established and all passwords should, as a matter of policy, be stored as hashed values to prevent trivial disclosure.
Commands (2-2): Historically LDAP was administered using a local, mostly command line, interface. It was also reasonable to assume that local (in-server) traffic was not snooped making simple (cleartext) password protection to most administrative services an adequate security measure. However, as noted above, the increasing emphasis on run-time configuration (OLC) (a.k.a cn=config) and monitoring (cn=monitor) may mean that remote LDAP Browsers become the norm for LDAP system administration. In this case access to these services will transmit highly sensitive data which should be protected using data security techniques such as TLS/SSL.

Finally, since OLC stores everything in a DIT (cn=config) it may be worth considering the use of the powerful features of overlay accesslog as tool to generate audit logging of changes to this DIT.
DIT (3): DIT security is defined with the LDAP Security model and is implemented exclusively through the use of olcAccess/access to. Permissions should be as tight as possible and and ACLs tested after every change with slapacl.
Replication (1-3): Even if normal client access to an LDAP system has a low security requirement the same may not be true for replication of that same DIT. During a replication cycle at some point or another all the data in a DIT (user and operational attributes) will be exposed on the communication network. Of necessity some of this information is very sensitive. Replication communications connections merit separate consideration. You can provide mixed TLS/SSL and other secure (or even insecure) connections in a single server (configuration samples for mixed TLS/SSL and SASL access).

OpenLDAP SASL Configuration

One day real soon now ™ we'll finish this section

OpenLDAP SASL TLS/SSL Configuration

The OpenLDAP Administration manual notes that when using TLS with SASL EXTERNAL both client and servers require a valid X.509 certificate. Assuming this statement to be true it unnecessarily complicates configuration while adding little to security in the majority of cases (there are notable exceptions to this such as replication). It is not discussed further at this time.

OpenLDAP TLS/SSL Configuration

Overview

TLS (Transport Level Security) is simply the name for the IETF standardized version of Netscape's Secure Sockets Layer (SSL). There are almost no differences between SSL(v3) and TLS(v1) and the two terms are used synonymously within this documentation. TLS/SSL has been supported by OpenLDAP since version 2.1.

TLS/SSL communication typically requires an X.509 certificate (more commonly known as an SSL certificate) which may be purchased from a commercial Certificate Authority (CA) or they can be self-signed certificates. This documentation has a paint-by-numbers guide to creating self-signed certificates and includes additional notes about using commercial certificates where appropriate.

The TLS/SSL session starts by negotiating a cipher suite which comprises a key exchange cipher, a bulk cipher and a MAC (Message Authentication Code - a hash) algorithm. The bulk cipher (which is always a symmetric cipher using a computed session key) and MAC are used when transferring data and are significantly less CPU intensive than the key exchange cipher (an asymmetric cipher, for example RSA or DSA/DSS) which is limited to sending the pre-master key (from which session keys are derived) at the beginning of the exchange.

The term authentication when used within a TLS context refers only to server authentication (using the X.509 certificate) and should not be confused with LDAP authentication which is used to control access to DITs. When used with TLS/SSL LDAP authentication using simple bind procedures becomes risk free because the passwords, while still sent in cleartext, are enveloped in the enciphered data stream - the net effect being that no data can be snooped (or sniffed) while traversing untrusted and insecure networks.

The following configurations do not provide an exhaustive description of all the LDAP TLS features. Instead they make assumptions that will, generally, cover the most common usage and are, hopefully, relatively simple to implement even with a modest knowledge of TLS/SSL and X.509 certificates. However if the user requirement covers unique circumstances then a greater depth of knowledge may be required - this survival guide provides gruesome details on the TLS/SSL protocol, X.509 certificate formats and the generation of self-signed certificates for use in a variety of circumstances that may prove useful.

The process of initiating a TLS session may occur in one of two ways:

Automatically: If the LDAP URL used by a client takes the form of ldaps://hostname/ then the TLS dialog is automatically initiated (both peers expect TLS/SSL protocol elements) on the default ldaps port of 636. The default ldaps port can be changed to an alternate by using the URL form ldaps://hostname:port/ and the server must be configured to listen on the alternative port (using -h parameter to slapd). To make it more confusing the alternate ldaps port could even be 389 (the normal ldap scheme port) to avoid , say, firewall configuration issues in which case the TLS dialog will still be automatic by virtue of the use of the ldaps scheme URL.
By Definition: LDAP will also support TLS/SSL on a standard LDAP port using a URL scheme of ldap://hostname (uses the default port of 389 though this may be changed). In this case client must be explicitly programmed (or prompted) to use a StartTLS sequence (a message requesting an extended operation with the OID of the StartTLS control 1.3.6.1.4.1.1466.20037). For example, when using syncrepl with TLS and a URL of ldap://hostname/ the parameter starttls=yes or starttls=critical MUST be defined (whereas it need not be defined when using a URL format of ldaps://hostname/).

While OpenLDAP, in keeping with its normal philosophy, allows multiple options and variations all the following TLS configurations share the same characteristics and use a subset of the available options, partly to reduce complexity and partly to focus on the most common usage. System policy requirement:

TLS Client configurations must always use the ldaps scheme when invoking secure connection. This simplifies client configuration and forces users to acknowledge that they are accessing a secure server in much the same way that https does when accessing secure web sites.
TLS Servers must have X.509 certificates, TLS Clients are assumed to NEVER have X.509 certificates, that is, the default value of olcTlsVerifyClient/TLSVerifyClient never is always assumed. While there are circumstances, for example, a syncrepl slave (or multi-master) configuration where mutual authentication may be desirable it assumed not to be a common requirement. Once a fully debugged TLS server configuration is operational it is - relatively - simple to add mutual TLS authentication since the user will be thoroughly conversant with the basic security mechanisms. To start with such a configuration is simply asking for errors, frustration and headless chicken imitations as the user ploughes through an apparently never-ending mountain of new information. Best add complexity one step at a time.
Self-signed certificates are used throughout (and their generation documented within the procedures). This is done for two reasons: First self-signed certificates are invaluable during testing since they cost nothing and provide additional insight into the use and functionality of X.509: Second there is little advantage to be obtained in using commercial certificates with LDAP at this time. This is unlike the case with web servers where user browsers (clients) come equipped with multiple commercial CA (root) certificates and the yellow (SSL certificate) or green (EV certificate) address bar, confirming site authenticity, provides a level of user comfort and hence commercial advantage. We can find no current distribution of an LDAP client with commercial CA (root) certificates pre-installed. Steps must be taken to install CA (root) certificates in LDAP client systems and the work involved is as great for a commercial certificate as for a self-signed certificate - only the certificate cost is different. Nevertheless many users will opt to install commercial X.509 certificates and we document any differences throughout.
Only RSA (Rivest, Shamir and Adleman) asymmetric algorithms are used for authentication and key exchange. In general the processes are significantly simpler. While DSA (Digital Signature Architecture) may be required in some cases (for example, Government) it is, currently, less widely used than RSA. DSA will be covered in the notes section at the end of each configuration.

The first configuration presented assumes that the LDAP server will only accept TLS connections using the ldaps scheme. All other attempts to access the server will be rejected. Two further configurations are shown where the server supports a mixture of TLS (ldaps) and non-TLS LDAP traffic

Configuring a Secure OpenLDAP (TLS Only) Server (and Clients)

TLS Server Configuration

The LDAP server is required only to accept TLS secured client connections with LDAP authentication. A single user DIT is supported including a replication service - that is the server will use the syncprov overlay and access is required to a cn=monitor and cn=config service. Self-signed certificates are used throughout (with appropriate notes on using commercial certificates).

Generate a LDAP server and CA certificate: This step will generate a self-signed certificate - if a commercial X.509 (SSL) certificate is being used this process is not required and may be skipped in its entirety. A trivial one-command method is used to generate a single X.509 certificate that may be used to both validate the server and act as a CA (root) certificate for the client. This method is documented in detail with all dialogues. The command sequence is:
```
# optionally create new directories
mkdir /certs
mkdir /certs/keys
cd /certs
# create server/CA cert and private key without passphrase
# valid for 10 years using current RSA recommendations for key size
# RSA is used as the key-exchange protocol
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 
  -keyout keys/ldapskey.pem -out ldapscert.pem

# leaves the cert in 
# cert may used as a server or CA cert)
/certs/ldapscert.pem 
# leaves the private key in 
/certs/keys/ldapskey.pem

# set permissions
chown -R ldap:ldap /certs/*
chmod 0400 keys/ldapskey.pem
```
Notes:
1. For a full explanation of the openssl command parameters
2. Key files normally have a passphrase (password) to protect the sensitive nature of the data. When used with a server such a passphrase is never used (inhibited by the -nodes argument)
3. Depending on certificate requirements other self-signed methods are described.

Add TLS directives to OLC (cn=config): The TLS directives required are added to the global section (lines beginning # are for explanatory purposes only and may be removed):

# cn=config base (global section)

dn: cn=config
changetype: modify
# Security - TLS section
add: olcTLSCertificateFile
olcTLSCertificateFile: /certs/ldapscert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /certs/keys/ldapskey.pem
-
add: olcTLSCipherSuite
olcTLSCipherSuite: TLSv1+RSA:!NULL
-
# the following directive is the default but 
# is explicitly included for visibility reasons
add: olcTLSVerifyClient
olcTLSVerifyClient: never

Alternative configuration for slapd.conf users: The TLS directives required are added to the global section:
```
# slapd.conf
# global section
...
# Security - TLS section
TLSCertificateFile /certs/ldapscert.pem
TLSCertificateKeyFile /certs/keys/ldapskey.pem
TLSCipherSuite TLSv1+RSA:!NULL
# the following directive is the default but 
# is explicitly included for visibility reasons
TLSVerifyClient never
...
# user DIT
database bdb
suffix "d=example,dc=com"
...
# replica provider
overlay syncprov

# cn=config DIT
database config
rootdn="cn=admin,cn=config"
rootpw ....

# cn=monitor DIT
database monitor
rootdn="cn=admin,cn=monitor"
rootpw ....
```
Notes:
1. For more information about TLSCipherSuite. The parameters used exclude all NULL (no encryption) suites. TLSv1 covers SSLv3. The EXPORT cipher suites are allowed - permitting any international connection. If performance or load is a significant issue then it would be better to use an explicit list of cipher suites that have acceptable performance or load characteristics rather than leave it to arbitrary TLS/SSL negotiation.
2. DSA Configuration: To be supplied.
Lock down server: (cn=config - see notes at end of section) The requirement is that only TLS connections will be supported by this server. The strategy adopted is to drop the listens for normal LDAP URL traffic (port 389) leaving only LDAPS URL listens and to introduce a couple of basic rules to force secured simple binding and prevent anonymous binding. This policy has the collateral effect of disabling anonymous LDAP URL binds to the rootDSE and some other interesting stuff. In a highly secure server this is probably desirable. The Access to directive can be used to accomplish similar goals but since ACLs are by-passed when binding to rootdn (when using cn=config and cn=monitor) it is only of limited use. This method is used and described with mixed configurations. Finally the LDAP server is started with listens only on the default LDAPS URL port of 636 (see notes below). First, the additional slapd.conf configuration (adds disallow, require directives and security directives):
```
# slapd.conf
# global section
...
# Security - TLS section
TLSCertificateFile /certs/ldapscert.pem
TLSCertificateKeyFile /certs/keys/ldapskey.pem
TLSCipherSuite TLSv1+RSA:!NULL
# the following directive is the default but 
# is explicitly included for visibility reasons
TLSVerifyClient never

# security - other directives
# prevents anonymous access to
# any connection
disallow bind_anon
# forces a bind operation before DIT access
require bind
# Use of reads on ldaps only port forces use
# of TLS/SSL but not a minimum value
# this directive forces a minimum value
security simple_bind=128

# DIT
database bdb
suffix "d=example,dc=com"
...
# replica provider
overlay syncprov

# cn=config DIT
database config
rootdn="cn=admin,cn=config"
rootpw ....

# cn=monitor DIT
database monitor
rootdn="cn=admin,cn=monitor"
rootpw ....
```
Notes:
1. cn=config: To be supplied.
2. LDAPS URL only listens: Control of the listening ports is accomplished by the use of the -h argument to slapd on startup. The default value if not defined (normal) equates to -h ldap:///. In this configuration to permit only ldaps operation we require a slapd startup command of:
```
slapd -h ldaps:/// -u ldap -g ldap
```
  To make this automatic the startup script needs to be edited in linux (/etc/rc.d/init.c/slapd) or in the case of BSD /etc/rc.conf should include this line slapd_flags="ldaps:///".
  
  If there is a concern over the configuration of firewalls then LDAPS may be configured to use port 389 (it is the URL scheme of LDAPS that indicates TLS not the port) in which case the required start up command becomes:
```
slapd -h ldaps://:389/ -u ldap -g ldap
# ldaps URLs must take the form
ldaps://ldap.server.name:389
```
3. disallow, require and security directives: Use of listens only on the LDAPS port(s) forces all connections to use TLS/SSL. Nothing else will be accepted by this server configuration. To force LDAP authentication the require bind directive is used and anonymous binds are prevented using disallow bind_anon. Thus all connections must bind to have any DIT access and they cannot bind anonymously. Only using security simple_bind=128 will not provide the protection required since it simply says: if a simple bind is executed it must use TLS/SSL. It does not insist that there should be a bind. The sole purpose of the security simple_bind=128 in this configuration is to define a minimum SSF value. If this is not required then the directive could be omitted.
4. rootDSE access: The policy has the side effect of disabling anonymous access to the rootDSE which as noted may be desirable in a secure server.
5. ACL directives: There are no additional security based ACLs used in this configuration - all the security is provided by server-wide directives and the LDAPS-only listens. ACL use would be limited to required access controls based on the user's account access policy.
Client Configuration: The requirement is that only TLS connections will be supported by the LDAP server - consequentially all client access must use LDAPS scheme URLs and perform server X.509 certificate validation which requires access to the CA (root) certificate. Clients in our context are assumed to be ldap utilities and tools and an LDAP Server running a replica service using syncrepl. While it may be obvious that ldap tools and utilities are clients and will therefore derive their parameters from ldap.conf what may be less obvious is that the LDAP server running the replica service is a TLS Client and also obtains its CA (root) certificate verification information from ldap.conf. Ldap.conf configuration:
```
# copy the certificate generated in step 1 above 
# to a suitable location on the client system
# assumed: /certs/ldapscert.pem

# ldap.conf add
TLS_CACERT /certs/ldapscert.pem 
```
The LDAP server running the replica is configured as:
```
# slapd.conf
# global section
...
# Security - TLS section
# none

# replica DIT
database bdb
suffix "d=example,dc=com"
...
# replica consumer
syncrepl
 rid=000
 type=RefreshandPersist
 provider=ldaps://ldap-master.example.com
 bindmethod=simple
 searchbase="dc=example,dc=com"
 retry="5 3 300 +"
 attrs="*,+"
 binddn="...."
 credentials=....
...
```
Notes:
1. The CA (root) certificate used by the syncrepl consumer (and defined by TLS_CACERT in ldap.conf) above is the same as that used as a server certificate by the master DIT provider. This is an artifact of the single certificate process - in which it functions as both a server and a CA certificate - we used to generate the certificate. Using other self-signing processes the server certificate and the CA certificate are different - as is the case, always, for commercial certificates.
2. If, as discussed previously, ldaps service is provided on port 389 (for example to avoid firewall blocking issues) then the syncrepl definition will use the extended port format thus:
```
syncrepl 
 ...
 provider=ldaps://ldap-master.example.com:389
 ...
```
3. LDAP Servers as TLS Clients: The LDAP Server when acting as a syncrepl consumer is acting as a TLS Client and therefore requires to validate the server's certificate using the issuer's CA (root) certificate. Because this server is acting as a TLS Client it uses the LDAP Client location for TLS directives - specifically it uses the TLS_CACERT directive in ldap.conf. The TLS Client needs to generate a key-exchange message encrypted with the public key of the server which is obtained from the X.509 certificate sent from the server. The TLS Client also sends a list of acceptable cipher suites during the ClientHello part of the initial TLS handshake protocol controlled by the TLS Client TLS_CIPHER_SUITE directive (defaulted to send ALL available cipher suites - equivalent to the command openssl ciphers -v ALL). Now breathe deeply before reading the next sentence. If the LDAP Server, which is the syncrepl consumer and therefore a TLS Client, also provides another DIT access (such as cn=config), and assuming TLS support is also required to control access, then it would also be a TLS Server and require all the TLS Server directives defined in steps 2 and 3 above.

OpenLDAP TLS/SSL Mixed Configuration

If you jumped directly to this section without going through normal TLS Configuration please take a moment to at least read the introductory notes - preferably the whole section because you may get very confused, very fast otherwise - even after reading this section you may still get very confused, very fast! But hope springs external.

Configuration - Some TLS Users, Some Not

In this case we require that certain users will use TLS other users will not. For example, assume this policy:

Allow anonymous access (and unsecured communication) to a limited set of public LDAP records
LDAP Authenticated users (simple bind with unsecured communication) are allowed read access to public LDAP records plus limited (own record) update (write) permissions
Users with more than own record write permissions must use TLS and must authenticate (assumed all members of group=admin)
All replication consumers must use TLS/SSL
Remote access to cn=config must use TLS/SSL

The solution required uses ACLs and server directives as shown in the following process:

Generate a LDAP server and CA certificate: This step will generate a self-signed certificate - if a commercial X.509 (SSL) certificate is being used this process is not required and may be skipped in its entirety. A trivial one-command method is used to generate a single X.509 certificate that may be used to both validate the server and act as a CA (root) certificate for the client. This method is documented in detail with all dialogues. The command sequence is:
```
# optionally create new directories
mkdir /certs
mkdir /certs/keys
cd /certs
# create server/CA cert and private key without passphrase
# valid for 10 years using current RSA recommendations for key size
# RSA is used as the key-exchange protocol
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 
  -keyout keys/ldapskey.pem -out ldapscert.pem

# leaves the cert in 
# cert may used as a server or CA cert)
/certs/ldapscert.pem 
# leaves the private key in 
/certs/keys/ldapskey.pem

# set permissions
chown -R ldap:ldap /certs/*
chmod 0400 keys/ldapskey.pem
```
Notes:
1. For a full explanation of the openssl command parameters.
2. Key files normally have a passphrase (password) to protect the sensitive nature of the data. When used with a server such a passphrase is never used (inhibited by the -nodes argument)
3. Depending on certificate requirements other self-signed methods are described.
Add TLS and ACL directives to slapd.conf: (cn=config - see notes at end of section) The TLS directives required are added to the global section:
```
# slapd.conf
# global section
...
# Security - TLS section
TLSCertificateFile /certs/ldapscert.pem
TLSCertificateKeyFile /certs/keys/ldapskey.pem
TLSCipherSuite TLSv1+RSA:!NULL
# the following directive is the default but 
# is explicitly included for visibility reasons
TLSVerifyClient never
...

# user DIT
database bdb
suffix "d=example,dc=com"
# no rootdn or rootpw directives
# see notes on securing rootdn access
...
# ACLs
# ACL1 - access for consumer
# (assume binds to cn=replica,dc=example,dc=com)
# consumer using TLS allowed read access to whole DIT
# all others go to ACL2 (break)
access to *
 by dn.exact="cn=replica,dc=example,dc=com" tls_ssf=128 read
 by * break
# ACL2 - access to userpassword
# anonymous users can only authenticate
# authenticated users can modify their passwords (self)
# any tls user can modify the password 
access to attrs=userPassword
 by self         write
 by anonymous    auth
 by group.exact "cn=admins,ou=groups,dc=example,dc=com" tls_ssf=128 write
# ACL3
# limits anonymous access to a public subtree and read only
# any authenticated users can update their record (self)
# within public subtree
# tls users can write to whole of public subtree
access to dn.subtree="ou=public,dc=example,dc=com"
 by group.exact "cn=admins,ou=groups,dc=example,dc=com" tls_ssf=128 write
 by self      write
 by anonymous  read
 by users read
# ACL4
# any tls user can write to the rest of the DIT
access to * 
 by by group.exact "cn=admins,ou=groups,dc=example,dc=com" tls_ssf=128 write

# the above is very flat - if further rules are
# needed then replace ACL4 with the following
# which filters out all non tls users
# the break means that if a tls user 
# go the the next ACL - all others are stopped
# ACL4
access to * 
 by group.exact "cn=admins,ou=groups,dc=example,dc=com" tls_ssf=128 break
# ACL5 etc.
access ....

# replica provider
overlay syncprov

# cn=monitor DIT
database config
rootdn "cn=admin,cn=config"
rootpw {SSHA} hfkhfhfldkhlkhh
# SSF of 128 or greater is used to secure access
# to cn=config
security simple_bind=128
```
Notes:
1. For more information about TLSCipherSuite. The parameters used exclude all NULL (no encryption) suites. TLSv1 covers SSLv3. The EXPORT cipher suites are allowed - permitting any international connection. If performance or load is a significant issue then it would be better to use an explicit list of cipher suites that have acceptable performance or load characteristics rather than leave it to arbitrary TLS/SSL negotiation.
2. DSA Configuration: To be supplied.
3. cn=config: To be supplied.
4. ACL Notes:
  1. ACL1: This ACL, which could equally have been placed in a global section, is designed to filter out early the replica consumer (the DN cn=replica,dc=example,dc=com must appear in the DIT with a corresponding password). The by dn.exact="cn=replica,dc=example,dc=com" tls_ssf=128 read contains two conditions which works (but is not explicitly documented) and will be met once the consumer has successfully authenticated AND is using an SSF (TLS) of 128 or greater. In order for the replica (and indeed all others) to authenticate (or just access the DIT) the by * break must be present to allow continuation at ACL2.
  2. ACL2: Allow any authenticated user to modify their password, anonymous access is granted for auth purposes and any member of the group cn=admins,ou=groups,dc=example,dc=com AND which is using TLS can write to any password.
  3. ACL3: In the defined order - allows any member of the group cn=admins,ou=groups,dc=example,dc=com AND which is using TLS to write to any attribute of any entry in the public subtree of the database. Limits anonymous users to read access to a public subtree of the DIT (excluding the userPassword). Allows an authenticated user to change any part of their own entry and finally allows any authenticated user with or without TLS access) to only read the public subtree (with the exception of their entry - covered by self - excludes userPassword access).
  4. ACL4: Allows only members of the group cn=admins,ou=groups,dc=example,dc=com AND which is using TLS write access to write to any other part of the DIT. All other users are denied any access (implicit by * none.
5. LDAPS and LDAP URL listens: Control of the listening ports is accomplished by the use of the -h argument to slapd on startup. The default value if not defined (normal) equates to -h ldap:///. In this configuration we require both ldap and ldaps so the slapd startup command is:
```
slapd -h "ldap:/// ldaps:///" -u ldap -g ldap
```
  To make this automatic the startup script needs to be edited in linux (/etc/rc.d/init.c/slapd) or in the case of BSD /etc/rc.conf should include this line slapd_flags="ldap:/// ldaps:///".
6. Securing rootdn access: Once a DIT has been initially loaded what function does the rootdn perform? In all normal DIT cases rootdn-like privileges can be granted to any specific user (we'll call it a pseudo-superuser) using ACLs, thus the rootdn could be removed entirely. Fine grained control can now be exercised on the new pseudo-superuser using normal ACLs - the purpose for which they were designed. The only danger in this approach is that an error in ACLs may limit required permissions - in the worst case the rootdn could be restored temporarily and then removed once the problem was fixed. The best solution to securing rootdn access to a normal DIT is to remove it. Period. As in the above configuration.
  
  In cases where rootdn is the only method of access, such as with cn=config in the above example, a database specific security simple_bind=128 is used to force confidentiality.

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.