## Define a root DN for superuser privileges.
rootdn "cn=Manager,dc=plainjoe,dc=org"
## Define the password used with rootdn. This is a salted secure hash of the phrase
## "secret."
rootpw {SSHA}2aksIaicAvwc+DhCrXUFlhgWsbBJPLxy
You aren't required to define a root password. If no rootpw directive is present, the rootdn is authenticated using the server's default authentication method (e.g., SASL). OpenLDAP 2.1 uses a DN representation of an SASL identify. The general syntax is:
uid=name,[cn=realm],cn=SASL Mechanism,cn=auth
The cn= realm portion on the DN is omitted if the mechanism does not support the concept of realms or if the one specified is the default realm for the server. If your OpenLDAP server existed within the PLAINJOE.ORG realm and you chose to use a Kerberos 5 principal named [email protected] as the rootdn, it would appear as:
rootdn "uid=ldapadmin,cn=gssapi,cn=auth"
The next two parameters should be left to their default values:
lastmod
This parameter determines whether slapd will maintain the operational attributes modifiersName, modifyTimestamp, creatorsName, and createTimestamp for all entries defined in core.schema. The default behavior is to maintain the information for all entries. The option accepts a value of off or on. Disabling this parameter means that client-side caching of information is not possible because no marker exists to test whether an entry has been updated.
readonly
The readonly parameter allows a server to disable all update access, including update access by the rootdn. Directory data is writable by default, assuming that there are no access control lists in place. Under some circumstances, such as backing up the data, you may want to prevent the directory from accepting modifications. Like the lastmod parameter, the readonly options also accept the values off or on.
bdb backend-specific parameters
The database parameters discussed up to this point are applicable to OpenLDAP's various database backends in general. This section examines several parameters that are used only by the bdb database.
The directory and mode parameters define the physical location and filesystem permissions of the created database files. These parameters are necessary because, when using an ldbm backend, slapd manages the data store itself. In the following configuration file, the directory and mode parameters tell slapd and the other LDAP tools how to locate and store the database files for this partition. The files are stored in the directory /var/ldap/plainjoe.org/ and created with read/write permission (0600) for the owner only (the account under which the slapd daemon runs).
## Define the beginning of example database.
database bdb
## Define the root suffix you serve.
suffix "dc=plainjoe,dc=org"
## Define a root DN for superuser privileges.
rootdn "cn=Manager,dc=plainjoe,dc=org"
## Define the password used with rootdn. This is the Base64-encoded MD5 hash of
## "secret."
rootpw {SSHA}2aksIaicAvwc+DhCrXUFlhgWsbBJPLxy
## Directory containing the database files
directory /var/ldap/plainjoe.org
## Files should be created rw for the owner **only**.
mode 0600
* * *
Warning
It's a good idea to maintain tight security on the physical database files even if the directory server is a closed box (i.e., no users can log into the server and run a shell). It is easier to manage the server when the only way to access the backend storage is via slapd itself.
* * *
The index parameter specifies the attributes on which slapd should maintain indexes. These indexes are used to optimize searches, similar to the indexes used by a relational database management system. slapd supports four types of indexes. However, not all attributes support all four index types. Each index type corresponds to one of the matching rules defined in the directory schema.
approx (approximate)
Indexes the information for an approximate, or phonetic, match of an attribute's value.
eq (equality)
Indexes the information necessary to perform an exact match of an attribute value. The match may be case-sensitive or whitespace-sensitive, depending on the matching rules defined in the attribute's syntax.
pres (presence)
Indexes the information necessary to determine if an attribute has any value at all. If an attribute does not possess a value, then the attribute is not present in the directory entry.
sub (substring)
Indexes the information necessary to perform a simple substring match on attribute values.
There can be multiple index definitions for the same database—and even multiple attributes or index types—on the same line. Each attribute or index type should be separated by a comma; use whitespace to separate the attribute list from the list of index types. Here's how to define an equality and presence index on the cn attribute:
## Maintain presence and equality searches on the cn and uid attributes.
index cn pres,eq
Which indexes should be maintained depends on the client applications that the server will support and the types of searches that those applications will perform. The best way to determine which indexes to maintain is to include the search processing debug output (loglevel 32) in the server's log file.
* * *
Note
OpenLDAP 2 requires an equality index on the objectClass attribute for performance reasons.
## Must be maintained for performance reasons
index objectClass eq
* * *
I cannot stress the use of proper indexes enough. Misconfigured indexes are probably the number one reason administrators experience performance problems with OpenLDAP servers. Many of the applications and scenarios presented later in the book focus on functionality and not necessarily performance. This should not be construed as lessening the importance of properly indexing the attributes used freqently in searches. It simply means that I assume you have learned your lesson about indexes here and can fill in the blanks later.
While an indexed database offers many performance benefits over flat text files, these benefits can be increased by caching entries and indexes in memory to prevent disk I/O in response to common searches. The cachesize parameter allows you to tune caching according to the needs of the directory.
The cachesize parameter defines the number of entries that should be cached in memory. The default is to cache 1,000 entries. If your total directory size is less than 1,000 entries, there is no need to modify this setting. If, however, your directory contains 1,000,000 entries, a cache size of 100,000 would not be unusual.
* * *
Warning
When setting parameters to integer values in slapd.conf, make sure to remove commas from the number. For example, 100,000 should be entered as 100000.
* * *
Here is what the database section looks like so far:
## Define the beginning of example database.
database bdb
## Define the root suffix you serve.
suffix "dc=plainjoe,dc=org"
## Define a root DN for superuser privileges. This is the Base64-encoded MD5 hash of
## "secret."
rootdn "cn=Manager,dc=plainjoe,dc=org"
## Define the password used with rootdn.
rootpw {SSHA}2aksIaicAvwc+DhCrXUFlhgWsbBJPLxy
## Directory containing the database files
directory /var/ldap/plainjoe.org
## Files should be created rw for the owner **only**.
mode 0600
## Indexes to maintain
index objectClass eq
index cn pres,eq
## db tuning parameters; cache 2,000 entries in memory
cachesize 2000
Access Control Lists (ACLs)
The Directory ACLs provided by OpenLDAP are simple in their synt
ax, yet very flexible and powerful in their implementation. The basic idea is to define Who has Access to What? The most frequent forms of "Who" include:
*
Matches any connected user, including anonymous connection
self
The DN of the currently connected user, assuming he has been successfully authenticated by a previous bind request
anonymous
Nonauthenticated user connections
users
Authenticated user connections
Regular expression
Matches a DN or an SASL identity
Remember that the login name used to specify a user for authentication takes the form of a DN (e.g., dn="cn=gerald carter,ou=people,dc=plainjoe,dc=org") or an SASL identify (e.g., dn="uid=jerry,cn=gssapi,cn=auth"). The self value is used as a shortcut for the DN of the authenticated user of the current session. The examples later in this section will help clarify this concept.
The notion of an access level is a new concept. Table 3-7 summarizes the various access privileges. Higher levels possess all of the capabilities of the lower levels. For example, compare access implies auth access, and write access implies read, search, compare, and auth.
Table 3-7. Summary of access levels from most (top) to least (bottom)
Access level
Permission granted
write
Access to update attribute values (e.g., Change this telephoneNumber to 555-2345).
read
Access to read search results (e.g., Show me all the entries with a telephoneNumber of 555*).
search
Access to apply search filters (e.g., Are there any entries with a telephoneNumber of 555*).
compare
Access to compare attributes (e.g., Is your telephoneNumber 555-1234?).
auth
Access to bind (authenticate). This requires that the client send a username in the form of a DN and some type of credentials to prove his or her identity.
none
No access.
The simplest way to control access is to define a default level of authorization. A global slapd.conf parameter defines the default access given to a user in the absence of a more explicit rule. For example, adding the following lines to the global section of slapd.conf gives all users search access unless an explicit ACL says otherwise:
## Give users search access when no other ACL applies.
defaultaccess search
Finally, the "What" defines the entry and attributes to which the ACL should apply. It is composed of three basic parts, all of which are optional.
A regular expression defining the DN of the proposed target of the ACL. The actual syntax is dn.targetstyle = regex, in which targetstyle is one of base, subtree, one, or children, and regex is a regular expression representing a DN. The targetstyle, which defaults to subtree, is used to broaden or narrow the scope of the ACL. If, for example, the targetstyle is set to one, the ACL applies only to children immediately below the defined DN. Very rarely does this setting need be changed from its default. The regex follows normal regular expression rules, with the addition that the DN must be in normalized form. The most common error is to add extra whitespace between components of the DN—for example, you can't add a space after the comma in dc=plainjoe,dc=org.
An LDAP search filter that conforms to RFC 2254. (More on LDAP searches will be covered in the next chapter.) The syntax for specifying a filter is filter= ldapFilter.
A comma-separated list of attribute names taking the form attrs= attributeList. If this item is not present, the ACL applies to all attributes held by the entry that matches the DN regular expression pattern.
If none of these components are present, a single asterisk (*) is used as a placeholder (for "What") to include everything.
Now that we've looked at the parts of an ACL, let's see how to put an ACL together. It is easiest to understand the syntax of an ACL by examining some practical uses. The following ACL grants read access to everyone:
# Simple ACL granting read access to the world
access to *
by * read
The space at the beginning of the second line indicates that this is a continuation of the previous line. This control list could have been written on a single line, but the multiline style is more readable for complex ACLs.
This next example restricts access to the userPassword attribute; any user can access the attribute, but can access it only for authentication purposes. Users can't read or write this attribute.
# Restrict userPassword to be used for authentication only.
access to attrs=userPassword
by * auth
If a user should be allowed to modify her own password in the directory, the ACL would need to be rewritten as follows:
# Restrict userPassword to be used for authentication only, but allow users to modify
# their own passwords.
access to attrs=userPassword
by self write
by * auth
Once authenticated, a user can write her own password. Anyone is allowed to use passwords for authentication purposes.
ACLs are evaluated on a "first match wins" basis. An ACL listed first takes precedence over ACLs mentioned later. This means that more restrictive ACLs should be listed prior to more general ones. Consider what behavior would result from the following two ACLs. What sort of access would be granted to the userPassword attribute?
# Simple ACL granting read access to the world
access to *
by * read
# Restrict userPassword to be used for authentication only, but allow users to modify
# their own passwords.
access to attrs=userPassword
by self write
by * auth
The previous ACLs grant all users (anonymous and authenticated) read access to userPassword. This clearly isn't a policy you would want. To achieve the desired effect of restricting read privileges to this attribute, the ACLs should be ordered as follows:
# Restrict userPassword to be used for authentication only, but allow users to modify
# their own passwords.
access to attrs=userPassword
by self write
by * auth
# Simple ACL granting read access to the world
access to *
by * read
For the next example, assume that the following conditions are met:
Administrative user accounts are located beneath the DN ou=admins,ou=eng, dc=plainjoe,dc=org.
Normal user accounts are located beneath ou=users,ou=eng,dc=plainjoe,dc=org.
Normal users should not be able to view passwords of other users.
A user should be able to modify his password.
Administrative users should be able to modify any user's password.
We can model these rules with the following ACL:
# Set control on the userPassword attribute.
access to dn=".*,ou=eng,dc=plainjoe,dc=org"
attrs=userPassword
by self write
by * auth
by dn=".*,ou=admins,ou=eng,dc=plainjoe,dc=org" write
ACLs can very often be written in more than one equivalent form. The following access rule is functionally identical to the one just presented:
# Set control on the userPassword attribute.
access to dn.children="ou=eng,dc=plainjoe,dc=org"
attrs=userPassword
by self write
by * auth
by dn.children="ou=admins,ou=eng,dc=plainjoe,dc=org" write
These examples are only a few possibilities of what can be done. We will continue to explore ACLs as a means of securing our server as we add more information into the directory in later chapters.
Chapter 4. OpenLDAP: Building a Company White Pages
The previous chapter discussed how to install OpenLDAP and provided an overview of the slapd configuration file, slapd.conf. However, we have yet to la
unch the server, let alone add any data to the directory. Using the slapd.conf from Chapter 3 as a starting point, this chapter shows you how to create a company directory for storing employee contact information, including postal addresses, email addresses, and phone numbers.
A Starting Point
Here is the slapd configuration file developed in Chapter 3. We will change some of the entries in this listing as things progress.
# /usr/local/etc/openldap/slapd.conf
# Global section
## Include the minimum schema required.
include /usr/local/etc/openldap/schema/core.schema
## Added logging parameters
loglevel 296
pidfile /usr/local/var/slapd.pid
argsfile /usr/local/var/slapd.args
## TLS options for slapd
TLSCipherSuite HIGH
TLSCertificateFile /etc/local/slapd-cert.pem
TLSCertificateKeyFile /etc/local/slapd-key.pem
## Misc security settings
password-hash {SSHA}
#######################################################
## Define the beginning of example database.
database bdb
## Define the root suffix you serve.
suffix "dc=plainjoe,dc=org"
## Define a root DN for superuser privileges.
LDAP System Administration Page 8
