With Directory Server, a naming context is one of the root suffixes of the directory namespace. Every naming context corresponds to a database. To create a naming context, you complete three steps:

The installation process creates two default naming contexts that correspond to a special configuration naming context and a naming context intended for user data. You can create additional naming contexts during installation following the steps I just outlined. If you create a naming context after installation via the administrative console, Directory Server performs the first and third steps for you; you must then manually create the corresponding entry via LDIF or an add operation.

The online documentation that refers to the configuration naming context is confusing, and it does a poor job of explaining the two configuration naming contexts. Every Directory Server has a cn=config naming context that holds the local configuration data for that server. In addition, there is another configuration naming context named o=NetscapeRoot, which exists on only a single Directory Server. The o=NetscapeRoot naming context stores configuration data for administration of one or more servers. This naming context stores the entire distributed directory's configuration information. In addition to being used by Directory Server, other products including Mail, Certificate, and Metadirectory use it to store their configuration information. By directing the Administrative Console toward the server with o=NetscapeRoot, you can view and manage all the servers in one spot.

The configuration naming context includes special authentication identities, plug-in configuration (under cn=plugins, cn=config), the database configuration settings (under cn=ldbm database,cn=plugins,cn=config), indexing information (under cn=index,cn=databaseName,cn=ldbm database, cn=plugins,cn=config), and support for all actions that cannot be performed through existing LDAP operations, such as start or stop of the service. Figure 8-1 shows the layout of cn=config. To find details about the configuration parameters stored within this naming context, see the following sections: Database Functionality, Indexing, Chaining, Plug-ins, Replication, and Special Configuration Parameters.

Figure 8-1. Configuration naming context

The second naming context initially created during installation is intended for user data. By default, you choose the name of this naming context; however, if you select express installation, Directory Server uses a name that matches the LDAP dc component string of the DNS suffix of the server. So if I ran express installation on dir1.mycompany.com, this naming context would be dc=mycompany,dc=com. This naming context is empty and only needs to be populated with Mycompany's directory data.

Like OpenLDAP, LDBM database technology underlies Direc tory Server. The database is the unit of indexing, replication, and storage. All indexing, replication, and storage activities are performed on a database as a whole. Therefore, if you need a different configuration for any of these functionalities on different portions of the directory, you will need to configure multiple databases. By default there is a single database, but multiple databases are supported. In contrast to OpenLDAP, you can dynamically add databases without service outage.

Naming contexts are associated with a database that processes all operations. A special attribute, nsslapd-state, at the root entry of a naming context determines what the directory does with requests for entries in a given suffix. The value backend indicates the normal state where the database processes all operations. In contrast, the value disabled prevents any operations from succeeding. The value referral indicates that the directory should return the referral value stored in the nsslapd-referral attribute for all requests to this naming context. In contrast, the value referral on update indicates that only update-oriented requests return the referral, and all other requests are processed by the database.

The attribute nsslapd-backend is used to specify the name of the database or database link associated with a naming context. This attribute is multivalued; but to make use of multiple values, you must employ special distribution functions to determine which value is used for any given request. Mycompany might specify two databases for a naming context if the number of entries in the naming context is significantly large. Special assistance from Sun or Netscape is needed to obtain the plug-in necessary for proper distribution when you use multiple databases per naming context. There are also several restrictions on this type of naming context that result in your not being able to move an entry out of a database.

You may configure separate indexing options on each database. Presence, equality, approximate, substring, international, and browsing (virtual list view) are all the possible indexes for attri butes. Multiple types of indexing are allowed for each attribute, and a different collection of indexing types is allowed for each attribute.

The approximate match (or soundex) index implemented by Directory Server works only with the English language. The details of what types of matches work with the approximate index are in the online documentation. The international index is used to associate special language-specific matching rules with attributes so they can be sorted and searched for in accordance with the rules of the language. This approach enables a directory in one locale to have different language behavior from a server in another locale—even if the directory entries are identical on both servers. The browsing index speeds use of the virtual list view control—a control you may remember from previous chapters. The Directory Server management console uses this control.

The indexing configuration information is in entries within the configuration naming context in three different locations. Each entry that represents an index has five attributes that specify the indexing applied to that database. nsSystemIndex is a Boolean value that indicates whether the index is mandatory for basic directory operation. Mandatory indexes cannot be removed. nsMatchingRule denotes the OID of a collation order. This allows the index to order attributes as desired. cn specifies the attribute to be indexed. Description is used to provide a meaningful description of what the index does. nsIndexType denotes the type of indexing to perform, as well as which attribute values should be indexed. Valid values of this attribute include those listed in Table 8-1.

In general, when you want to create an index on a database, you create an entry under the container cn=index, cn=databaseName,cn=ldbm database,cn=plugins,cn=config where databaseName is the name of the database to which the index applies. There are a couple of exceptions. International indexing requires the use of matching rules together with the OID for the locale desired. The browsing or virtual list view indexing is configured via a different mechanism that is executed via the vlvindex command. There are two initial sets of indexes. The system indexes are required for Directory Server to work properly, and can't be deleted or modified. The system indexes are listed in Table F-1 in Appendix F. The default indexes, which apply to all databases, are listed in Table F-2 in Appendix F. You can modify the default indexes. To find the default indexes, look in the container cn=default indexes, cn=config,cn=ldbm database,cn=plugins,cn=config.

An external referral is called a default referral within the product documentation. One default referral is allowed for the directory. In addition, you can set one default referral per naming context (per database). The documentation calls these latter instances suffix referrals. Suffix referrals are valid regardless of whether that naming context is disabled. All these default referrals are not entries in the directory; instead, they are a configuration option stored as an attribute of the naming context. Using this design, default referrals work even if the database associated with the naming context is disabled or unreachable.

The documentation calls all other referrals smart referrals. Smart referrals redirect clients from any directory entry that isn't a suffix. A smart referral simply uses the ref attribute as specified in the Internet-draft regarding LDAP referrals. Smart referrals have two options that let you specify whether the referral redirects on all requests for the entry or just on modify requests.

All Directory Server referrals use the LDAP URL syntax according to the standard.

Chaining is supported by Directory Server, and the way it is implemented deserves more detail than the brief coverage in Chapter 5. You will recall that with chaining, the LDAP server chases the referral instead of the client. With Directory Server, chaining is enabled via a special object class that directs the server to channel requests to a chaining plug-in. The chaining plug-in is enabled by default. An entry of this object class can have no children, and it holds only a single attribute. This attribute is a database link to another directory server, not an LDAP URL as referrals normally are. Chaining is supported only to other instances of Directory Server, not to LDAP servers from other vendors.

Directory Server chaining can sidestep another issue that referrals don't. With referrals, the client must bind again to the server to which it is redirected. With chaining, this action is handled by the first server. Not only that, but with referrals you usually need a copy of the binding entry on each server. Chaining can eliminate this requirement.

Multiple levels of chaining are allowed. This is called cascading chaining. Loops in chaining are detected and prevented by a special LDAP control called Loop Detection. By default, you must enable this control on each database. To enable the control on the database specified by the entry, add the OID of the Loop Detection control, 1.3.6.1.4.1.1466.29539.12, to the nsTransmittedControls attribute in the cn=config, cn=chaining database,cn=plugins,cn=config entry. The Loop Detection control then uses the nsHopLimit attribute described next to detect loops.

The nsHopLimit attribute limits the number of times a request can be passed to another server via chaining. This attribute is used to prevent looping or to limit operations that cause excessive chaining. There are several other attributes that affect the behavior of chaining; for more detail, turn to Appendix G for the URLs to the online documentation.

Plug-ins and requests that use controls have implications when chaining is encountered. Additional configuration to allow plug-ins and controls to work is required by default. This default lack of functionality limits the security exposure and is therefore a good thing. Adding the OID of an LDAP control to the nsTransmittedControls attribute of the cn=config, cn=chaining database,cn=plugins,cn=config entry allows requests using that control to chain for the chaining database specified by the entry.

The database links associated with a naming context that is chaining to a remote server are stored under the entry cn=chaining database,cn=plugins,cn=config. The nsslapd-referral attribute is used to indicate the remote naming context that this database link will manage. The nsMultiplexorBindDN attribute stores the binding account, whereas nsMultiplexorCredentials stores the password. The remote server is indicated by specifying an LDAP URL to just the server's hostname via the nsFarmServerURL attribute.

Directory Server relies primarily on command-line executables for client functionality. The command-line executables ldapsearch, ldapmodify, and ldapdelete are provided to enable normal client operations. Full online documentation is available at http://docs.sun.com/source/816-5608-10/utilities.htm#12904. In addition to this user-oriented client software, the primary tool for administering the server and the directory contents is the Administrative Console, a graphical Java application that can be run remotely.

However, there are also some graphical interface clients available for typical users. For example, the Netscape Communicator browser is designed to work well with Directory Server. It provides support for

There are also a few other Sun products that provide a graphical interface that may be appropriate for client users that have special directory roles. iPlanet Delegated Administrator and iPlanet Console are two such products (for more information, see the following section, Management).

By default, Directory Server provides ten controls that extend the functionality of the server. Some of these controls provide support for functionality I have already mentioned, like chaining, while others support functionality I haven't discussed yet, like proxy authorization. What follows is a short description of each control. For greater detail, go to the online documentation at http://docs.sun.com/source/816-5616-10/controls.htm#999558, although note that not all the controls are well documented.

Directory Server allows the directory functionality to be extended via plug-ins. These plug-ins are special code components that can be installed and enabled to provide functionality that is outside the default configuration. This description sounds very similar to that of an LDAP control. But in general, plug-ins are used to provide functionality that isn't directly related to a client request or response. More specifically, plug-ins let you extend and control the directory functionality without relying on the client invoking a control. Many plug-ins are related to checking the validity of client input for a specific syntax for searching and sorting. For example, many of the language- and locale-specific syntax rules are implemented via syntax plug-ins. These plug-ins are called by the search system for ordering and matching.

You can also write your own custom syntax-checking plug-in to enforce specific rules not known to the vendor-supplied plug-ins. For example, say that as the directory administrator you wanted every access control specifier to be checked for validity (further suppose that there is no schema-checking process). Because controls require that the client invoke them, if you deployed this validity check via a control, you would have no guarantee that every access control specifier was valid. Other LDAP servers incorporate this type of functionality in the schema-checking process without giving any choice on the configuration. As the directory administrator, you have no control over whether the access control specifier is checked for validity, aside from turning off the entire schema-checking process. But with Directory Server, you can control this smaller piece of functionality, electing to turn it off or on without affecting any other functionality. You might still turn off all schema checking, but you now have the luxury of picking and choosing which syntaxes to check. You can also write your own custom syntax-checking plug-in to enforce specific rules not known to the vendor-supplied plug-ins.

The configuration for each Directory Server plug-in has a separate entry and set of attributes under cn=plugins,cn=config. Because many of the plug-ins supply syntax-checking, their configuration is limited to an on/off toggle. But some plug-ins are more complex and have extensive configuration. All plug-ins are instances of the nsSlapdPlugin object class, which inherits from the extensibleObject object class. As you'll recall, extensibleObject is the most flexible object class, with every defined attribute available to it.

There are 31 plug-ins provided with Directory Server. Roles, class of service, multimaster replication, chaining, database operation, language-specific LDAP operation, password encryption, and ACL resolution are each supported directly or indirectly via plug-ins. As alluded to earlier, each of the 12 supported syntaxes is implemented via plug-ins. I don't discuss these plug-ins in detail here, but you can find a complete list with descriptions in Appendix F.

Both static and dynamic groups are supported. Static groups are of object class groupOfNames, with a multivalued member attribute with the DN of each entry that is a member. The DN of another static or dynamic group can also be a value of member. This is called a nested group. Dynamic groups are of the object class groupOfURLs, with a multivalued memberURL attribute that contains a URL search filter. These search filters are evaluated at the time of access to generate the list of group membership. In contrast to static groups, the DN of another static or dynamic group is not a valid value of memberURL. However, you can create an entry with both the groupOfNames and the groupOfURLs object classes. This group entry would allow you to define both dynamic and static membership with nested groups. Because Directory Server uses dynamic membership and doesn't implement a back reference (called a linked attribute in Chapter 7) like Active Directory does, there is no simple way to enumerate all the groups to which a given entry belongs.

Roles are like groups, but they take the opposite approach. Instead of listing the DN of member entries on the role entry, the DN of the role entry is listed on each of the member entries. In other words, the user entry asserts its memberships, instead of the role asserting the membership. This is more conducive to being able to list every role assigned to a given entry, while being less conducive to listing every entry that belongs to a role.

To enable this functionality, every user entry has two special operational attributes called nsRole and nsRoleDN. nsRoleDN provides a mechanism to explicitly add the entry to a role. If I wanted to add myself to a role, I'd add the DN value of the desired role to my nsRoleDN attribute. nsRole is a read-only attribute maintained by the directory itself, and it lists every role to which the entry belongs. In actuality, the value of this attribute isn't statically maintained; it is dynamically calculated upon request. As a result, nsRole can't be used in any search filter. The value of nsRole is based on the value of nsRoleDN for that entry plus any of the dynamic and nested roles that may apply.

There are several types of role entries, with many object classes representing them. Table 8-2 lists all these role object classes and gives a brief description of each. In practice, only three of the object classes are used to create entries: nsNestedRoleDefinition, nsManagedRoleDefinition, and nsFilteredRoleDefinition. Managed roles are the basic role entry. Nested roles provide a mechanism to have one role belong to another role. Filtered roles allow the membership of a role to be determined dynamically via a search filter.

Roles are not compatible with chaining in all cases. Both an entry and its role entry must exist on the chained server or else the role mechanism (which automatically updates nsRole) will fail. If your servers are fully replicated, using roles will not be an issue; but otherwise, it will require careful planning. Of course, you probably wouldn't use chaining if you had a fully replicated environment. Roles are also dangerous with respect to user access control. Users are typically given full control of their entries, but this design lets them join any role they want, thus compromising access control based on roles. This limitation requires careful access control definition and awareness among directory administrators.

You can inactivate role entries, a step that inactivates all the entries that belong to that role. This might be an effective way to temporarily disable authentication to a set of entries. Reactivation of the role re-enables access to that set of entries. You can also delete role entries, though deletions can cause problems because of the way roles are implemented. Each entry that asserts membership in a deleted role is not automatically updated, unless the Referential Integrity plug-in is configured to search the nsRoleDN attribute for deleted role entries. For more information on plug-ins, see the earlier section Plug-ins, and for additional material on the Referential Integrity plug-in, see Appendix F.

The Class of Service (CoS) mechanism is used to associate a single attribute value on many entries. This is an important mechanism in simplifying management of recurring data. CoS values are calculated dynamically at the time of the request for the attribute. This results in a significantly smaller storage profile. However, the attribute that is dynamically asserted cannot be used in a search filter. The usefulness of CoS is limited to attributes that you wouldn't use to find entries. But regardless, CoS is somewhat useful, and it represents an important feature that deserves further development. In fact, this is the only mechanism of its kind on any LDAP server.

An example of a situation in which CoS might be used demonstrates its usefulness. At Mycompany all of the person entries at Muppet HQ have the same address. If Muppet HQ moved, it would be annoying to modify all the addresses manually, although LDIF could be used to speed this process. CoS simplifies this process even further by providing a way to make a single modification that affects all these entries at once.

You can use the Class of Service mechanism to dynamically assert a static attribute value or to assert a dynamically determined value. In the Muppet HQ example, a static value is asserted. However, the value could be asserted in a dynamic fashion. Consider another example: Luke Skywalker is the manager of a team of people within the Engineering organization at Mycompany. Each of their person entries reflects this relationship with an o=Engineering attribute pair. However, there is a big shakeup at Mycompany, and Luke's entire team is reorganized into the Marketing organization within Mycompany. CoS allows Luke's team members to have their o attributes dynamically linked to the value of Luke's o attribute. Each team member's o attribute is linked to the manager entry, which in this case indicates Luke's entry. CoS follows this path to Luke's entry and uses his o value for each team member's entry. Sounds pretty tricky, huh? Let's take a look at how this works.

Table 8-3 lists all the CoS object classes. Of these object classes, only four are commonly used: cosTemplate, cosClassicDefinition, cosIndirectDefinition, and cosPointerDefinition. cosClassicDefinition, cosIndirectDefinition, and cosPointerDefinition are used to specify the scope of affected entries and are called CoS definition entries. A CoS definition entry determines the scope of affected entries by its placement in the directory; all child entries below the parent of a CoS definition entry are affected. All the CoS definition entries have a mandatory cosAttribute. The cosAttribute specifies which attribute will have its value asserted. The cosAttribute can be multivalued; more than one attribute can be asserted. Each of the three types of CoS definition entries also has an attribute called a specifier. The specifier is used in determining the value of the attribute specified in cosAttribute. The specifier attribute is used differently for each object class, allowing fine-grained control of how attributes are evaluated based on the object classes of an entry. This diversity in how the attribute is used provides a richer mechanism.

Before looking at the details of each of the specifier attributes, we first need to take a look at the cosTemplate object class. A cosTemplate entry is called a CoS template. A CoS template is usually placed in the same directory container as the CoS definition entry, but this placement isn't required. You use a CoS template to assert one or many attribute values, and it can have an assigned priority in case more than one template matches a specifier (more on specifiers later). Higher numbers have higher priority, but zero is the highest priority. The key purpose of a CoS template is to statically define the value of the attribute being asserted. To achieve this purpose, all attributes need to be available to it. So in summary, I define a CoS template with the static value of the attribute I'm asserting via CoS.

Pointer CoS

Pointer CoS determines resolution by directly pointing to a template entry with the value

The simplest type of CoS is pointer CoS. With pointer CoS (a cosPointerDefinition entry), the specifier attribute is cosTemplateDN. cosTemplateDN indicates a DN of a CoS template. A base-level search commences using this DN as the baseDN, and a presence search filter with the value of the cosAttribute (which is the name of an attribute). The value returned from the template is then asserted on all the affected entries. Consider Figure 8-2, which uses the Muppet HQ example (where the address was changed) to illustrate how pointer CoS works.

Figure 8-2. Pointer CoS example

The CoS definition determines that the postalAddress value will be asserted for all entries below the Muppets OU. It specifies the CoS template for resolution of the value. The CoS template specifies the postalAddress value, and this value overrides the static value on Gonzo's entry as well as all the other entries under ou=Muppets.

Classic CoS

Classic CoS determines resolution using a dynamic mechanism to point to a template entry with the value

The second type of CoS is called classic CoS. Classic CoS (a cosClassicDefinition entry) is similar to pointer CoS in that a CoS template provides the value of the attribute indicated by cosAttribute. However, the DN of the CoS template is not completely indicated by the specifier attribute cosTemplateDN.

The DN of the CoS template is formed by prepending “cn=” to the value in the classic CoS attribute cosSpecifier and appending the DN in cosTemplateDN. Figure 8-3 provides an example of classic CoS.

Figure 8-3. Classic CoS example

The CoS definition determines that the postalAddress value will be asserted for all entries below the People OU. It specifies the CoS template for resolution of the value is also under the ou=People container, and that the cn of the template should be determined by the value of the o attribute on the target entry. For Luke's entry, the value of o is Engineering, so the CoS template that applies is cn=Engineering. This CoS template specifies the postalAddress value, and this value overrides the static value on Luke's entry. In combination with many more CoS templates, this approach could be used to dynamically assign everyone's address based on the organization to which each person belongs.

Indirect CoS

Indirect CoS determines resolution by using a normal entry instead of a template entry

The third type of CoS is called indirect CoS. With indirect CoS (a cosIndirectDefinition entry), the specifier attribute is cosIndirectSpecifier. cosIndirectSpecifier indicates an attribute on the target entry. The target entry's attribute contains a DN value. This DN value is used as if it were a CoS template (but it doesn't need to be a CoS template). The attribute indicated by cosAttribute is queried on this DN, and the value returned is asserted by CoS. With indirect CoS, each target entry's attribute may have a different DN value and thus have a different value for the CoS attribute. Consider Figure 8-4, which uses the Luke Skywalker reorganization example (when the o was asserted via the manager's entry) to illustrate how indirect CoS works.

Figure 8-4. Indirect CoS example

The CoS definition determines that the o value will be asserted for all entries below the Staff OU. It specifies the manager attribute will specify the DN used to resolve the value. On Wedge's entry, his manager attribute indicates Luke's entry. Luke's entry has an o attribute value of Marketing, so Wedge's entry gets the same value. However, on the Stormtrooper entry, the manager attribute indicates Anakin's entry. Anakin's entry has an o attribute value of Sales, which is applied to Stormtrooper's entry.

Directory Server defines three types of replicas. Labeling these types differently is largely for the purpose of understanding the replication functionality employed. A master replica allows both read- and write-oriented LDAP operations. A consumer replica is read-only and is a replicated copy of another master replica. The consumer server returns a referral to the master replica for all add, modify, modifyRDN, and delete operations. This referral reflects the fact that the consumer server is read-only, and that writes must be made to the master server. A hub replica is a consumer replica that distributes directory entries via replication to other consumer replicas. Directory Server replication follows a push model. In other words, the master replica (which might also be a hub) initiates replication. A consumer replica cannot request updates.

Replication agreements control which consumer replicas receive replication from a master replica. These agreements determine the target consumer, the database to replicate, scheduling for the replication, the authentication for the connection, and the encryption used for the traffic. The scheduling options include recurring periodic replication, a specific schedule, or immediate replication as changes happen. SSL encryption is fully supported via replication. Multiple-master replication is configured by setting up two replication agreements, one on each of the two master replicas. Each replication agreement uses a server thread as well as a file descriptor.

A change log tracks all changes to a master replica. This change log is used to determine what changes should be replicated to consumer replicas. Only the directory uses the change log; however, this data can be shared with clients through the Retro Change Log plug-in, which allows access to a parallel copy of the change log via LDAP. This separate and parallel change log can be enabled and disabled independently of the one used strictly by the replication process. Changes for multiple replicas on a master server are logged to a shared change log.

In a multiple-master architecture, collision resolution is determined by the last change made. Each change includes a timestamp that is used for determining collision resolution. If the server can't determine a resolution for a collision, manual resolution by a directory administrator is required. The replication process automatically flags the entry with a special operational attribute nsds5ReplConflict. Naming collisions result in the second entry having its DN appended with the nsUniqueID attribute, so the second entry has a globally unique value.

There are some requirements when you use replication. A special entry called the Replication Manager entry is required to support replication. This entry exists on both the master and consumer replica servers. This entry has a special level of authorization on the consumer server and is not restricted by access controls set on the consumer server. Because of the sensitivity of this entry, it cannot be in the replication data. The Attribute Uniqueness plug-in cannot be used with multiple-master replication. The Referential Integrity plug-in can be run only on a single-master server in a multiple-master architecture.

The directory schema is replicated with the replica by default. In fact, the first steps performed in every replication transaction are verifying and replicating the schema as required. These steps help to ensure that the remainder of the replication can succeed. If part of the schema was missing and an entry included that schema element, the directory would have problems. After the schema has been replicated, the remainder of directory data replication proceeds.

The earlier section Naming Context highlights the importance of the information stored within cn=config. Most of the feature-specific configuration options available have been covered; however, there are many more options that can be configured.

These configuration options include the common ones that other products offer. However, Directory Server adds an additional layer of control. For example, the directory administrator can set resource limits on a per-user basis to restrict the basic LDAP functionality that a client is capable of performing. These limits include the maximum number of entries returned in an operation, a time limit, an idle timeout, and the maximum number of entries that will be examined to perform a single operation. Of course, these limits can be set at the server level as with other products, but Directory Server provides a greater degree of flexibility than its competitors.

Other options include turning off all access control checking, control over what operations are audited to a log file, control over what level of detail is written to the error log, control over the number of nested groups allowed, password lockout features, and SSL settings. Performance tuning options like maximum number of file handles available or threads per connection are also available.

The full details of the information stored in the configuration naming context are well documented online at http://docs.sun.com/source/816-5608-10/config.htm#12904.

Among the authentication methods that Directory Server provides are anonymous authentication, simple authentication, simple authentication over TLS, authentication via certificate-based identity, and DIGEST-MD5 authentication with SASL. Like most LDAP servers, the basic unit of authentication is focused on the entry representing the client user. The password is stored as an attribute of the user entry, and other authorization information is stored as part of this entry. For example, password history can be stored to keep a user from reusing old passwords. If nsAccountLock is set to TRUE, it will inactivate an entry's ability to bind. It can also be set on role entries to inactivate all the users associated with that role.

In addition to password-based authentication, you can configure clients to use certificate-based authentication. You use the userCertificate attribute of the user's entry to store the certificate in binary format for the client. The DN indicated by the certificate must either match the DN of the user's entry or be mapped to this entry.

Directory Server supports pass-thru authentication. This means that one Directory Server passes credentials to another Direc tory Server so the client user doesn't have to bind to each server separately. It also means that the user's entry doesn't have to be replicated to every Directory Server to access data stored in that server. This functionality requires the Pass Thru Authentication (PTA) plug-in. This plug-in has a few useful configuration options. For example, you can specify that the two Directory Servers encrypt all pass-thru authentication communications. For more details, go to the online documentation, Chapter 16 of the Administrator's Guide, at http://docs.sun.com/source/816-5606-10/pasthru.htm#1068035.

Although proxy authorization isn't an authentication method, it is used to impersonate another identity. As a user with access to specific directory resources, I can give the proxy right for my user entry to another user's entry. That user can then impersonate me, accessing directory resources as if a bind operation had been issued with my user entry. This other user does not need the password of my account to exercise the proxy right I've delegated. Instead, the other user employs proxy authorization at the time of each request to the directory by specifying the Proxy Authorization control. The control requires a single value known as the ProxyDN. Only users who have been specifically given proxy rights can impersonate my entry. To give the proxy right to another user, I must define a special statement called an access control instruction (ACI) that gives the other user account some specific subset of the directory access rights I hold.

With Directory Server, an ACI is the essential unit used to define the directory access controls. A collection of access control instructions is called an access control list. An ACI is logically represented as an attribute of an entry, called the aci attribute. Each ACI can have multiple values that together form an access control list. There are four components to an ACI entry: a target, heading, permissions, and bind rules. By default, the access control specified in the aci attribute of an entry affects that entry and every child entry below that entry. This default behavior occurs only when the ACI target isn't specified. Application of the ACI to all child entries is accomplished via a feature unique to Directory Server called dynamic inheritance.

Inheritance occurs when a configuration setting, in this case an access control, propagates to children entries. With static inheritance, the access control is copied to each of the entries below it. Microsoft's Active Directory is an example of an LDAP server that uses static inheritance. With dynamic inheritance, the access control is never copied to subordinate objects. Instead, when a user tries to access an entry, the access control of that entry and every parent container must be checked. When more than one ACI applies, the union is effective. Denying access takes precedence over allowing access, so a deny all at the root of the directory would effectively restrict everyone from the entire directory.

There is a subtle difference between static inheritance and dynamic inheritance. This difference can affect performance dramatically, depending on how you make use of access controls in your directory. Static inheritance inflicts a load at the time of applying access controls, whereas dynamic inheritance increases the potential burden at the time of access. Minimizing this burden involves carefully crafting the ACIs. This task can almost be an art form, and it is best to test the configuration for performance impact.

In fact, the syntax and specific access control factors that ACIs provide are complex enough that they require extended coverage and study. For this reason, I've placed the extended over view of ACIs in Appendix F. Each of the components of an ACI is given specific attention, the access control factors offered are highlighted, and a number of examples are presented to illustrate the proper use of ACIs.

Because ACIs can become complex and lengthy, Directory Server offers a feature to help simplify them. This feature is called macros. Macros can reduce the number of ACI statements needed when a repeating pattern of ACIs is required. They can also simplify a nonrepetitive ACI.

Macros are placeholders that are used to represent a DN, or a portion of a DN, in an ACI. In other words, a portion of the target DN can be saved as a variable to be plugged in later in the ACI statement. Macros are essentially dynamic DNs in ACIs. You might use a macro to save a DN in the target and later use this saved DN in the bind rule of the ACI. When used with wildcards, a single macro ACI can replace multiple ACI statements throughout the directory. Having many ACIs is bad for performance and also harder to administer. Macro ACIs, including examples, are also covered in detail in Appendix F.

SSL v2, SSL v3, and TLS are available by default for session encryption. Several encryption algorithms are provided, including RC2, RC4, DES, and Triple DES. Key lengths of 1024 bits are supported with TLS.

The cn=encryption,cn=config entry holds the server encryption settings. On this entry you can configure the SSL session timeout, whether encryption is allowed or required, and enable which of the available algorithms can be used by clients. These settings transcend the authorization controls specified in ACI statements. So if you require session encryption here, all client access must be encrypted whether or not the ACI access control requires it.