Best Practices Guide for Sun Java System Directory Server

Observe these guidelines when developing the LDAP client:

Specify the LDAP version 3 protocol. Version 2 is largely outdated and classified as historical protocol only. If you do not specify the version, some APIs default to version 2.
Reuse connections. Repeatedly establishing and closing connections can degrade performance, especially if you are using the Secure Sockets Layer (SSL). Keeping pooled connections available can dramatically improve performance and reduce the server load.
Be kind--unbind. A major cause of connection leakage is neglecting to close a connection when the process is complete.
Analyze failures. Try to determine from the result code whether to retry the operation or reestablish the server connection. Even if you must restart Directory Server, you may not need to restart your application. The fewer the restarts, the less the overhead.
Apply authentication policies. If your application performs user authentication tasks, be sure to implement the appropriate password policy response controls.
Watch the access logs. Learn to read and interpret the Directory Server access logs. They can help you quickly diagnose problems and pinpoint locations of unindexed searches or inefficient operations.
Use APIs wherever possible. Avoid directly searching LDAP servers because such avoidance insulate you from schema and other server-specific configurations. For example, if your application uses Identity Server or Sun Java System Portal Server (formerly Sun ONE Portal Server and hereinafter called Portal Server), which includes Identity Server, use the Identity Server API.
Handle referrals properly. Don't assume that you are communicating with a master directory server. Instead, return referrals for both searches and revisions.

In general, a good practice is to follow only one referral URL and, in case of problems, fall back to the other URLs.
Don't depend on the order of the entries or attributes in Directory Server. Those attributes are subject to change and may vary from version to version. See Request for Comments (RFC) 2251: LDAP version 3.
Make object class and attribute names case-insensitive. Again, see RFC 2251: LDAP version 3.
Familiarize yourself with the specifications. In particular, read RFC 3377: Technical Specification for LDAP version 3, which collects all version 3 specifications (2251-2556, 2829, and 2830).

Here are the recommendations for implementing access control instructions (ACIs):

For protection, revise ACIs so that access is granted to authenticated users only. However, certain components of the directory, in particular the root Directory Server-specific entry (called the DSE) and schema definitions, should be available without authentication.
Whenever possible, add ACIs to safeguard data. For example, if certain information in Directory Server is sensitive, insert ACIs to restrict access to the entry or attribute in question. Then use the db2ldif utility to convert the extracted data to readable text and place the data in a protected directory that can be accessed only by authorized personnel, such as system administrators.
For individual accounts, employ groups or roles to grant access to resources instead of applying ACIs to those accounts. A single set of ACIs for a group can enforce the access rule for all group members.
Write simple ACI rules. ACI rules are additive. Complex rules can be difficult to test and decipher and might lead to a maintenance nightmare.
Design macros to optimize performance and reduce the number of ACIs you must maintain.

When you update schema elements in LDAP, Directory Server automatically writes those changes to the 99user.ldif file rather than to the file in which the schema elements were first defined, such as 99customapp.ldif. As a result, other schema definitions you may have made in custom schema files may be overwritten.

In practice, manually add definitions of schema extensions to the 99user.ldif file. That way, you avoid duplication of elements and the risk of the schemas being overwritten at a later date.

Besides processing requests in LDAP, Directory Server 5.2 and later versions also respond to requests sent in Directory Service Markup Language (DSML) version 2--another way for clients to encode directory operations. Directory Server processes DSML in the same way it processes any other request with the same access-control and security capabilities. In fact, processing in DSML offers the advantage that many other types of clients can access your directory content.

Directory Server supports DSML version 2 over HTTP/1.1 and uses Simple Object Access Protocol (SOAP) version 1.1 as the transport protocol. DSML is not enabled with the default installation of Directory Server: You must explicitly turn it on after installation.

If you implement simple authentication only, Directory Server sends user passwords over the wire in readable text, rendering them vulnerable to security attacks. To head off that threat, enable communications between the client and the LDAP server with SSL and authenticate access to your applications with server certificates. TABLE 1 shows the pros and cons of this approach.

TABLE 1 Pros and Cons of Using Certificate Authentication

Pros	Cons
Client-server communications are encrypted, affording protection to user credentials.	Running SSL is computationally extensive and requires numerous processing cycles. For efficiency, you should install hardware SSL accelerators.
No passwords are sent over the network.	A digital certificate is required for each server installation and for each client. The cost thus incurred rises with the number of clients that use certificate-based authentication. Also, certificate renewals imply ongoing costs.
Communications between the client and the server are encrypted.	A certificate is physically stored on the client machine. Besides safeguarding the machines from theft, you should also assign passwords to the certificates.

Clearly, certificate-based authentication is a more secure mechanism for protecting privacy. However, you must balance the benefits against the accompanying costs. If, for example, LDAP communications in your environment occur behind the corporate firewall only, simple authentication might be an acceptable solution.

Another commonly adopted method is SSL-based encryption with simple authentication, which is compatible with a wide range of client applications. Also, given that the biggest performance hit occurs when the connection is first established, your applications should use persistent connections.

The major difference between a referral system and a chained system is the location of the data. In the former, data reside on the client side; in the latter, they are located on the server side.

Chaining reduces complexity in the client but requires more server configurations because chained servers must collaborate with remote servers and send the results to directory clients. With referrals, the client must locate the referral and collate the search results. Referrals also offer more flexibility for client applications. Besides, with a referral system, you can keep users better informed of the progress of distributed directory operations.

Again, weigh the pros and cons and make an informed choice for your needs.

Adopt these good practices when reading or writing data:

Interact efficiently with groups and roles. For example, to check whether a user belongs to a group, you need not retrieve the entire list of group members.
When retrieving from the directory an entry that you might need in the near future, implement a cache on the client side for the information. That way, you read the entry once only during the same operation.
To reduce the traffic over the network and speed up searches, retrieve only the attributes you need.
Don't immediately read back an entry as soon as you write to it because doing so might cause problems in a replicated environment, let alone that the read operation is likely redundant. Instead, have faith in the code returned by the server and take that as confirmation for the write operation.

For efficiency in searching and sorting, bear in mind the following:

Avoid subtree searches that match a large number of entries. To retrieve one entry only, do the following:
- If you are using the LDAP JDK, call the LDAPConnection.read() method, not the LDAPConnection.search() method.
- If you are using JNDI, call the Context.lookup() method, not the DirContext.search() method.
Use multivalue attributes sparingly. If you must use them, for example, in the case of static groups, minimize the number of values in a multivalued attribute. And when updating multivalue attributes, delete and add specific values instead of replacing all the values with new ones.
In large databases, establish unindexed searches from searches on indexed attributes.
For searches and sorts, ensure that you correctly set the limits for the following attributes:
- nsslapd-sizelimit -- This attribute specifies the maximum number of entries to return from a search operation. As soon as this limit is reached, the server returns an error message: Exceeded size limit error. The default value is 2000. A value of -1 means no limit, which we do not recommend.
- nsslapd-lookthroughlimit -- This attribute specifies the maximum number of entries that Directory Server checks in response to a search request. If you bind as the Directory Manager, unlimited is the default and overrides other settings. However, if you set a a value for the operational attribute nsLookThroughlimit in the entry for binding, that value overrides the default. A value of -1 means no limit, which we do not recommend.
- nsslapd-allidsthreshold -- The value for this attribute typically falls within a range of approximately 5 percent of the total number of entries in the directory. Since a change to this value requires a rebuild of all the indexes, you should set it before populating the database. For efficiency, avoid setting a high value (above 50,000) for this attribute--not even for large deployments.
- nsslapd-timelimit -- This attribute specifies the search time limit for the database link in seconds. The default is 3600. A value of -1 means no limit, which we do not recommend.
To avoid impacting the server's performance, use server-side sorting only when absolutely necessary. Server-side sorting requires specific indexing in case of a large numbers of entries and incurs extra cycles. Likewise, to optimize performance, avoid persistent searches.
Server-side sorting can benefit from virtual list view (VLV) indexes. If a sorted search must occur regularly, add an appropriate VLV index.

Here are our recommendations for indexing and partitioning:

A sound indexing strategy enhances performance because indexes accelerate searches. An index contains a list of values, each associated with a list of corresponding identifiers. By referencing the identifiers, Directory Server can quickly look up entries. Otherwise, Directory Server may have to check every entry in a suffix to find the matches for a search.

Index tuning for a Directory Server instance means maintaining only those indexes for which the benefits from faster search processing offset the costs incurred in processing updates and acquiring additional space. Maintaining useful indexes is an excellent practice. Conversely, maintaining unused indexes for attributes on which clients rarely search is a waste.
Because Directory Server aims at providing fast responses to read operations (queries), it is not a good choice for storing data that change frequently, such as inventory counts, purchase orders, and performance metrics. To achieve its goal, Directory Server depends heavily on indexing and storing data in memory cache. If the read-to-write ratio of Directory Server is low, the server's performance eventually becomes limited to the capacity of the master server.

First and foremost, to ensure the availability of the entire directory service, provide the backup server with sufficient redundancy for a full restore. Following are suggestions that will help you ensure the availability of an LDAP backup server:

High availability -- To prevent the server from becoming a single point of failure, implement Sun Cluster and the LDAP data-service monitor. If the backup server is a replica of the master supplier, it cannot serve as one of the masters in a multimaster topology. For optimal performance, availability, and data integrity, isolate the backup server from write activities.
No single points of failure -- To prevent a disk from becoming a single point of failure, implement a structure of Redundant Array of Inexpensive Disks (RAID).
Optimization of the content network -- Offload backup, recovery, and replication traffic to an isolated backup network. In addition, assign administrative and operational tasks to a similar private network.
Isolation of backup networks -- Place all noncontent-related traffic on an isolated backup network to prevent unwanted prying by snoopers who might access the directory through the content network.
Centralization of backup storage -- To streamline the backup and recovery strategy and minimize the amount of local storage per server, store all Directory Server backups on a central server. Centralizing backups also makes for an economical tape archival because fewer media and less backup time are required.
Backup rotations -- To preserve legacy backups for a number of rotations or a predefined period of time, rotate the backup files for Directory Server.
Tape archival system -- Create a daily full tape backup of all directories. That way, if the disks attached to a directory server are lost, you can still recover the data. Retain those backup tapes on site for at least one or two weeks so that they are easily accessible. Afterwards, the chances that they are required for immediate access are slim and you can transfer them off site for remote storage.
Management of change logs -- A short duration for change logs can be problematic because, if a restore becomes necessary after the expiry of the change log or after a purge of old entries, data loss may result. As a precaution, keep change-log entries around for at least a week.

Change log requirements vary with applications, however, so plan according to your needs.

SDN Home > Identity Management > Reference > Technical Articles & Tips >