Chapter 8 Identifying Administration and Monitoring Requirements

Directory Server Enterprise Edition administration has changed significantly since the previous version of Directory Server. These changes are described in detail in the Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

This chapter provides an overview of these changes and describes the administrative decisions that you must make in the planning phase of your deployment:

• Directory Server Enterprise Edition Administration Model

• Designing Backup and Restore Policies

• Designing a Logging Strategy

• Designing a Monitoring Strategy

• Data Administration With Directory Editor

• Grouping Directory Entries and Managing Attributes

Directory Server Enterprise Edition Administration Model

Directory Server Enterprise Edition gives the administrator more control over instance creation and administration. This control is achieved by using two new commands, dsadm and dsconf. These commands provide all the functionality previously supplied by the directoryserver command plus additional functionality.

The dsadm command enables the administrator to create, start, and stop a Directory Server instance. This command combines all operations that require file system access to the Directory Server instance. The command must be run on the machine that hosts the instance. It does not perform any operation that requires LDAP access to the instance or access to an agent.

In the new administration model, a Directory Server instance is no longer tied to a ServerRoot. Each Directory Server instance is a standalone directory that can be manipulated in the same manner as an ordinary standalone directory.

The dsconf command combines the administration operations that require write access to cn=config. The dsconf command is an LDAP client. It can only be executed on an active Directory Server instance. The command can be run remotely, enabling administrators to configure multiple instances from a single remote machine.

Directory Proxy Server provides two comparable commands, dpadm and dpconf. The dpadm command enables the administrator to create, start, and stop a Directory Proxy Server instance. The dpconf command enables the administrator to configure Directory Proxy Server by using LDAP and to access the Directory Server configuration through Directory Proxy Server.

In addition to these command-line utilities, Directory Server Enterprise Edition is integrated into the Java Web Console. The Console enables Directory Server Enterprise Edition and other Sun products to be managed from a centralized user interface. Directory Service Control Center (DSCC) is a service of the Java Web Console that is specifically for managing Directory Servers and Directory Proxy Servers. DSCC provides the same functionality as the command-line utilities, as well as wizards that enable you to configure several servers simultaneously. In addition, DSCC provides a replication topology drawing tool that enables you to monitor replication topologies graphically. This tool simplifies replication monitoring by providing a real-time view of individual masters, hubs, and consumers, and the replication agreements between them.

Remote Administration

The Directory Server Enterprise Edition administration model, described in the previous section, also enables remote administration of any Directory Server or Directory Proxy Server in the topology. Servers can be administered remotely using both the command-line utilities and the Java Web Console.

The dsadm and dpadm utilities cannot be run remotely. These utilities must be installed and run on the same machine as the server instance that is being administered. For details of the functionality provided with dsadm and dpadm, see the dsadm(1M) and dpadm(1M) man pages.

The dsconf and dpconf utilities can be run remotely. For details of the functionality provided with dsconf and dpconf, see the dsconf(1M) and dpconf(1M) man pages.

The following figure illustrates how the new administration model facilitates remote administration. This illustration shows that the console and configuration commands can be installed and run remotely from the Directory Server and Directory Proxy Server instances. The administration commands must be run locally to the instances.

Figure 8–1 Directory Server Enterprise Edition Administration Model

Designing Backup and Restore Policies

In any failure situation that involves data corruption or data loss, it is imperative that you have a recent backup of your data. Avoid reinitializing servers from other servers where possible. For information about how to back up data, seeChapter 8, Directory Server Backup and Restore, in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

This section provides an overview of what to consider when planning a backup and recovery strategy.

High-Level Backup and Recovery Principles

Apply the following high-level principles when designing a backup strategy:

• Identify the data that must be backed up.

  For Directory Server Enterprise Edition this data includes the following:

  • Shared binaries and plug-ins

  • Certificate database files

  • Configuration files

  • Log files and the change log database

  • Schema files

  • User data

• Ensure that your backup and recovery strategy includes the hardware, operating system, and software components.

• Decide whether you will keep binary backups or LDIF backups.

  A general recommendation is that you keep both. For more information, see Choosing a Backup Method and Choosing a Restoration Method.

• Build automation around backup and recovery tools, and ensure that automatic scripts are maintained.

  This strategy avoids unnecessary delays if you have to restore from a backup in an emergency.

• Determine a retention and rotation strategy.

  This strategy includes how often you perform backups and how long you keep them. When determining retention and rotation of backups, be aware of the purge delay and its impact on backups in a replicated topology. As modifications occur on a supplier, changes are recorded in the change log. Without a method of emptying the change log, its size would continue to increase until the change log consumed all available disk space. By default, changes are purged every seven days. This period is known as the purge delay. When a change has been purged, the change can no longer be replicated. For this reason, make sure that databases are backed up at least as often as the purge delay.

• Use the backup and recovery tools provided with Directory Server Enterprise Edition rather than merely performing a system backup and recovery.

Choosing a Backup Method

Directory Server Enterprise Edition provides two methods of backing up data: binary backup and backup to an LDIF file. Both of these methods have advantages and limitations, and knowing how to use each method will assist you in planning an effective backup strategy.

Binary Backup

Binary backup produces a copy of the database files, and is performed at the file-system level. The output of a binary backup is a set of binary files containing all entries, indexes, the change log, and the transaction log. A binary backup does not contain configuration data.

Binary backup is performed using one of the following commands:

• dsadm backup must be run offline, that is, when the Directory Server instance is stopped. The command must be run on the local server containing the Directory Server instance.

• dsconf backup can be run online and remote to the Directory Server instance.

Binary backup has the following advantages:

• All suffixes can be backed up at the same time.

• Binary backup is significantly faster than a backup to LDIF.

• The replication change log is backed up.

Binary backup has one limitation. Restoration from a binary backup can be performed only on a server with an identical configuration.

This limitation implies the following:

• Both machines must use the same hardware and the same operating system, including any service packs or patches.

• Both machines must have the same version of Directory Server installed, including binary format (32 bits or 64 bits), service packs and patch levels.

• Both servers must have the same directory tree that is divided into the same suffixes. The database files for all suffixes must be copied together Individual suffixes cannot be copied.

• Each suffix must have the same indexes configured on both servers, including virtual list view (VLV) indexes. The database files for the suffixes must have the same name.

• Each server must have the same suffixes configured as replicas. If fractional replication is configured, fractional replication must be configured identically on all master servers.

• Attribute encryption must not be used on either server.

At a minimum, you need to perform a regular binary backup on each set of coherent machines. Coherent machines are machines that have an identical configuration, as defined previously.

---

Note –

Because restoration from a local backup is easier, perform a binary backup on each server.

---

These abbreviations are used in the remaining diagrams in this chapter:

M = master replica

RA = replication agreement

The following figure assumes that M1 and M2 have an identical configuration and that M3 and M4 have an identical configuration. In this scenario, a binary backup would be performed on M1 and on M3. In the case of failure, M1 or M2 could be restored from the binary backup of M1 (db1). M3 or M4 could be restored from the binary backup of M3 (db2). M1 and M2 could not be restored from the binary backup of M3. M3 and M4 could not be restored from the binary backup of M1.

Figure 8–2 Offline Binary Backup

For details on how to use the binary backup commands, see Binary Backup in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

Backup to LDIF

Backup to LDIF is performed at the suffix level. The output of a backup to LDIF is a formatted LDIF file, which is a copy of the data contained in the suffix. As such, this process takes longer than a binary backup.

Backup to LDIF is performed using one of the following commands:

• dsadm export must be run offline, that is, when the Directory Server instance is stopped. This command must be run on the local server containing the Directory Server instance.

• dsconf export can be run online and remote to the Directory Server instance.

---

Note –

Replication information is backed up unless you use the -Q option when running these commands.

The dse.ldif configuration file is not backed up in a backup to LDIF. To enable you to restore a previous configuration, back this file up manually.

---

Backup to LDIF has the following advantages:

• Backup to LDIF can be performed from any server, regardless of its configuration.

• Restoration from an LDIF backup can be performed on any server, regardless of its configuration.

Backup to LDIF has one limitation. In situations where rapid backup and restoration are required, backup to LDIF might take too long to be viable.

You need to perform a regular backup by using backup to LDIF for each replicated suffix, on a single master in your topology.

In the following figure, dsadm export is performed for each replicated suffix, on one master only (M1).

Figure 8–3 Offline Backup to LDIF

For information about how to use the backup to LDIF commands, see Backing Up to LDIF in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

Choosing a Restoration Method

Directory Server Enterprise Edition provides two methods of restoring data: binary restore and restoration from an LDIF file. As with the backup methods, both of these methods have advantages and limitations.

Binary Restore

Binary restore copies data at the database level. Binary restore is performed using one of the following commands:

• dsadm restore must be run offline, that is, when the Directory Server instance is stopped. This command must be run on the local server containing the Directory Server instance.

• dsconf restore can be run online and remote to the Directory Server instance.

Binary restore has the following advantages:

• All suffixes can be restored at the same time.

• The replication change log is restored.

• Binary restore is significantly faster than restoring from an LDIF file.

Binary restore has the following limitations:

• Restoration can be performed only on a server with an identical configuration, as defined in Binary Backup. For more information about restoring data with the binary restore feature, see Binary Restore in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

• If you are not aware that your database was corrupt when you performed the binary backup, you risk restoring a corrupt database. Binary backup creates an exact copy of the database.

Binary restore is the preferred restoration method if the machines have an identical configuration and time is a major consideration.

The following figure assumes that M1 and M2 have an identical configuration and that M3 and M4 have an identical configuration. In this scenario, M1 or M2 can be restored from the binary backup of M1 (db1). M3 or M4 can be restored from the binary backup of M3 (db2).

Figure 8–4 Offline Binary Restore

Restoration From LDIF

Restoration from an LDIF file is performed at the suffix level. As such, this process takes longer than a binary restore. Restoration from LDIF can be performed using one of the following commands:

• dsadm import must be run offline, that is, when the Directory Server instance is stopped. This command must be run on the local server containing the Directory Server instance.

• dsconf import can be run online and remote to the Directory Server instance.

Restoration from an LDIF file has the following advantages:

• This command can be performed on any server, regardless of its configuration.

• A single LDIF file can be used to deploy an entire directory service, regardless of its replication topology. This functionality is particularly useful for the dynamic expansion and contraction of a directory service according to anticipated business needs.

Restoration from an LDIF file has one limitation. In situations where rapid restoration is required, this method might take too long to be viable. For more information about restoring data from an LDIF file, see Importing Data From an LDIF File in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

In the following figure, dsadmin import is performed for each replicated suffix, on one master only (M1).

Figure 8–5 Offline Restoration From LDIF

Designing a Logging Strategy

Logging is managed and configured at the individual server level. While logging is enabled by default, it can be reconfigured or disabled according to the requirements of your deployment. Designing a logging strategy assists with planning hardware requirements. For more information, see Hardware Sizing For Directory Server.

This section describes the logging facility of Directory Server Enterprise Edition.

Defining Logging Policies

Each Directory Server in a topology stores logging information in three files:

• Access log. Lists the clients that connect to the server and the operations requested.

• Error log. Provides information about server errors.

• Audit log. Gives details about modifications to suffixes and to the configuration.

Each Directory Proxy Server in a topology stores logging information in two files:

• Access log. Lists the clients that connect to Directory Proxy Server and the operations requested.

• Error log. Contains server error messages.

You can manage the log files for both Directory Server and Directory Proxy Server in these ways:

• Defining log file creation policies

• Defining log file deletion policies

• Manually creating and deleting log files

• Defining log file permissions

Defining Log File Creation Policies

A log file creation policy enables you to periodically archive the current log and start a new log file. Log file creation policies can be defined for Directory Server and Directory Proxy Server from the Directory Control Center or using the command-line utilities.

When defining a log file creation policy, consider the following:

• How many logs do you want to keep?

  When this number of logs is reached, the oldest log file in the folder is deleted before a new log is created. If this value is set to 1, the logs are not rotated and grow indefinitely.

• What is the maximum size, in Megabytes, for each log file?

  When a log file reaches this maximum size or the maximum age defined in the next item, the file is archived. A new log file is started.

• How often should the current log file be archived?

  The default is every day.

• At what time of day should log files be rotated?

  Time-based rotation makes operations like log analysis and trending easier, because each log file covers the same time period.

Log file rotation can also be based on a combination of criteria. For example, you can specify that logs be rotated at 23h30 only if the file size is greater than 10 Megabytes.

For details on how to set up a log file creation policy, see Configuring Logs for Directory Server in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

Defining Log File Deletion Policies

A log file deletion policy enables you to automatically delete old archived logs. Log file deletion policies can be defined for Directory Server and Directory Proxy Server from the Directory Service Control Center or using the command-line utilities. A log file deletion policy is not applied unless you have defined a log file creation policy. Log file deletion will not work if you have just one log file. The server evaluates and applies the log file deletion policy at the time of log rotation.

When defining a log file deletion policy, consider the following:

• What is the maximum size of the combined archived logs?

  When the maximum size is reached, the oldest archived log is automatically deleted.

• What is the minimum free disk space that should be available?

  When the free disk space reaches this minimum value, the oldest archived log is automatically deleted.

• What is the maximum age of log files?

  When a log file reaches this maximum age, the log file is automatically deleted.

For details on how to set up a log file deletion policy, see Configuring Logs for Directory Server in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

Manually Creating and Deleting Log Files

Manual file rotation and forced log rotation do not apply to Directory Proxy Server.

If you do not want to define automatic creation and deletion policies for Directory Server, you can create and delete log files manually. In addition, Directory Server provides a task that enables you to rotate any log immediately, regardless of the defined creation policy. This functionality might be useful if, for example, an event occurs that needs to be examined in more detail. The immediate rotation function causes the server to create a new log file. The previous file can therefore be examined without the server appending logs to this file.

For information about how to rotate logs manually and how to force log rotation, see Rotating Directory Server Logs Manually in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

Defining Permissions on Log Files

In previous versions of Directory Server, log files could only be read by the directory manager. Directory Server Enterprise Edition enables server administrators to define the permissions with which log files are created. For information about how to define log file permissions, see Configuring Logs for Directory Server in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

Designing a Monitoring Strategy

An effective monitoring and event management strategy is crucial to a successful deployment. Such a strategy defines which events should be monitored, which tools to use, and what action to take should an event occur. If you have a plan for commonplace events, possible outages and reduced levels of service can be prevented. This strategy improves the availability and quality of service of your directory.

To design a monitoring strategy, do the following:

• Select the appropriate monitoring tools. See Monitoring Tools Provided With Directory Server Enterprise Edition.

• Identify the key areas to be monitored in the directory architecture.

  These areas are frequently the same as the sizing and tuning attributes. See Identifying Monitoring Areas.

• Define what triggers an event or alarm condition when monitoring the key performance measure.

  This strategy implies defining an acceptable level of performance or operation for each performance measure.

• Determine what action should be taken when an alarm condition occurs.

Monitoring Tools Provided With Directory Server Enterprise Edition

This section provides a summary of the monitoring tools that are available in Directory Server Enterprise Edition as well as additional tools that can be used to monitor server activity.

The monitoring areas described in Identifying Monitoring Areas can be monitored using one or more of these tools.

• Command-line tools. Include operating system-specific tools to monitor performance such as disk usage, LDAP tools such as ldapsearch to collect server statistics stored in the directory, third-party tools, or custom shell or Perl scripts.

• Directory Server and Directory Proxy Server logs. Include the access, audit, and error logs. These logs can be monitored manually or parsed using custom scripts to extract monitoring information that is relevant to your deployment. The Directory Server Resource Kit provides a log analyzer tool, logconv, that enables you to analyze the access logs. The log analyzer tool extracts usage statistics and counts the occurrences of significant events. For more information about this tool, see logconv(1). For information about viewing and configuring log files, see Chapter 14, Directory Server Logging, in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

• Directory Service Control Center (DSCC). Is a graphical user interface that enables you to monitor directory operations in real time. DSCC provides general server information, including a resource summary, current resource usage, connection status, and global database cache information. It also provides general database information, such as the database type, status, and entry cache statistics. Cache information and information relative to each index file within the database is also provided. In addition, DSCC provides information relative to the connections and the operations performed on each chained suffix.

• Replication monitoring tools. Include the command-line tools, repldisc, insync and entrycmp.

  These tools enable you to do the following:

  • Monitor the state of synchronization between a master replica and one or more consumer replicas

  • Compare the same entry on two or more different replicas so that you can assess replication status

  • Depict your complete replication topology, which is particularly beneficial when dealing with complex directory deployments

  For more information, see repldisc(1), insync(1) and entrycmp(1).

  You can also monitor replication status by using the DCC. For more information about monitoring replication, see Getting Replication Status in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

• Simple Network Management Protocol (SNMP). Is the standard mechanism for global network control and monitoring, and enables network administrators to centralize network monitoring activity.

  For information about monitoring using an SNMP agent, see Chapter 15, Directory Server Monitoring, in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

• Java ES Monitoring Framework. Enables monitoring of performance and other statistics through JMX. For more information, see Directory Server and CMM/JMX in Sun Java System Directory Server Enterprise Edition 6.1 Reference.

Identifying Monitoring Areas

What you monitor, and to what extent, depends on your specific deployment. In general, however, include the following elements in your monitoring strategy:

• Server activity such as resource usage, server status, and connection information

• Database activity such as cache, transactions, locks, and log information

• Disk status including available disk space and threshold information

• Replication activity including status (whether or not replication is running), and the state of synchronization

• Indexing efficiency including unindexed searches, search filters, and frequently used indexes

• Security status including failed bind attempts, open connections, and effective rights

Data Administration With Directory Editor

The Directory Editor component of Directory Server Enterprise Edition is a Java web application that enables you to manage directory data by using a web browser. Directory Editor provides all users with remote access to directory data without having to install any client software.

Directory Editor offers the following functionality:

• Enables administrators and end users to create and edit directory users, groups, and containers.

• Supports several concurrent users, depending on the application server and underlying hardware.

• Supports large enterprise directory installations.

• Enables customization, branding, and embedding of the interface.

  Customization dynamically adapts to the Directory Server schema.

• Enables customization through the configuration of forms, rather than by direct programming.

• Supports SSL-encrypted transmissions between the client browser and Directory Server.

• Limits access to menus and functions, based on roles.

  Roles are scanned to match group names. Roles have access to certain capabilities, which are high-level actions such as Browse, Configure, Debug, Edit, Create, and Search.

• Limits access to the data based on the existing ACIs in Directory Server. It is not necessary to define ACIs that are specific to Directory Editor.

• Enables paged display of large volumes of data, based on the virtual list view (VLV) index.

For details on installing, configuring, and using Directory Editor, see the Directory Editor Documentation Collection.

Grouping Directory Entries and Managing Attributes

The directory information tree organizes entries hierarchically. This hierarchy is a type of grouping mechanism. The hierarchy is not well suited for associations between dispersed entries, for organizations that change frequently, or for data that is repeated in many entries. Directory Server groups and roles offer more flexible associations between entries. The class of service (CoS) mechanism enables you to manage attributes so that the attributes are shared between entries. This sharing is done in a way that is invisible to applications.

These entry grouping and attribute management mechanisms are described in detail in Chapter 8, Directory Server Groups and Roles, in Sun Java System Directory Server Enterprise Edition 6.1 Reference and in Chapter 9, Directory Server Class of Service, in Sun Java System Directory Server Enterprise Edition 6.1 Reference.

This section provides an overview of the grouping mechanisms that is sufficient to design an administrative strategy. It does not explain how the mechanisms work or how to set them up.

The section is divided into the following topics:

• Static and Dynamic Groups

• Managed, Filtered, and Nested Roles

• Deciding Between Groups and Roles

• Managing Attributes With Class of Service

Static and Dynamic Groups

Directory Server distinguishes between two types of groups:

• Static groups. Explicitly name their member entries.

• Dynamic groups. Specify a filter and all entries that match the filter are members of the group. These groups are dynamic because membership is defined each time the filter is evaluated.

Managed, Filtered, and Nested Roles

Roles are an entry grouping mechanism. Roles enable you to determine role membership as soon as an entry is retrieved from the directory. Each role has members, or entries that possess the role. As with groups, you can specify role members explicitly or dynamically.

Directory Server supports the following three types of roles:

• Managed roles. Explicitly assign a role to member entries.

• Filtered roles. Automatically make entries members if the entries match a specified LDAP filter. In this way, the role depends on the attributes contained in each entry.

• Nested roles. Enable you to create roles that contain other roles.

Deciding Between Groups and Roles

The functionality of the groups and roles mechanisms overlap somewhat. Both mechanisms have advantages and disadvantages. Generally, the roles mechanism is designed to provide frequently required functionality more efficiently. Because the choice of a grouping mechanism influences server complexity and determines how clients process membership information, you must plan your grouping mechanism carefully. To decide which mechanism is more suitable, you need to understand the typical membership queries and management operations that are performed.

Advantages of the Groups Mechanism

Groups have the following advantages:

• Static groups are the only standards-based grouping mechanism. Static groups are therefore interoperable with most client applications and LDAP servers.

• Static groups are preferable to roles for enumerating members.

  If you only need to enumerate members of a given set, static groups are less costly. Enumerating members of a static group by retrieving the member attribute is easier than recovering all entries that share a role. In Directory Server 6.1, significant performance improvements have been made for large multi-valued attributes. Equality matching and modify operations on these attributes are greatly improved, specifically in relation to static groups. Membership testing for group entries has also been improved. These improvements remove some of the previous restrictions on static groups, specifically the restriction on group size.

  Directory Server 6.1 also provides group membership directly in user entries, with the isMemberOf operational attribute. This feature applies to static groups only but includes nested groups. For more information, see Managing Groups in Sun Java System Directory Server Enterprise Edition 6.1 Administration Guide.

• Static groups are preferable to roles for management operations such as assigning and removing members.

  Static groups are the simplest mechanism for assigning a user to a set or removing a user from a set. Special access rights are not required to add the user to the group.

  The right to create the group entry automatically gives you the right to assign members to that group. This is not the case for managed and filtered roles. In these roles, the administrator must also have the right to write the nsroledn attribute to the user entry. The same access right restrictions also apply indirectly to nested roles. The ability to create a nested role implies the ability to pull together other roles that have already been defined.

• Dynamic groups are preferable to roles for use in filter-based ACIs.

  If you only need to find all members based on a filter, such as for designating bind rules in ACIs, use dynamic groups. Although filtered roles are similar to dynamic groups, filtered roles trigger the roles mechanism and generate the virtual nsRole attribute. If your client does not need the nsRole value, use dynamic groups to avoid the overhead of this computation.

• Groups are preferable to roles for adding or removing sets into or from existing sets.

  If you want to add a set to an existing set, or remove a set from an existing set, the groups mechanism is simplest. The groups mechanism presents no nesting restrictions. The roles mechanism only allows nested roles to receive other roles.

• Groups are preferable to roles if flexibility of scope for grouping entries is critical.

  Groups are flexible in terms of scope because the scope for possible members is the entire directory, regardless of where the group definition entries are located. Although roles can also extend their scope beyond a given subtree, they can only do so by adding the scope-extending attribute nsRoleScopeDN to a nested role.

Advantages of the Roles Mechanism

Roles have the following advantages:

• Roles are preferable to dynamic groups if you want to enumerate members of a set and find all sets of which a given entry is a member. Static groups also provide this functionality with the isMemberOf attribute.

  Roles push membership information out to the user entry where this information can be cached to make subsequent membership tests more efficient. The server performs all computations, and the client only needs to read the values of the nsRole attribute. In addition, all types of roles appear in this attribute, allowing the client to process all roles uniformly. Roles can perform both operations more efficiently and with simpler clients than is possible with dynamic groups.

• Roles are preferable to groups if you want to integrate your grouping mechanism with existing Directory Server functionality such as CoS, Password Policy, Account Inactivation, and ACIs.

  If you want to use the membership of a set “naturally” in the server, roles are a better option. This implies that you use the membership computations that the server does automatically. Roles can be used in resource-oriented ACIs, as a basis for CoS, as part of more complex search filters, and with Password Policy, Account Inactivation, and so forth. Groups do not allow this kind of integration.

Restricting Permissions on Roles

Be aware of the following issues when using roles:

• The nsRole attribute can only be assigned by the roles mechanism. While this attribute cannot be assigned or modified by any directory user, it is potentially readable by any directory user. Define access controls to keep this attribute from being read by unauthorized users.

• The nsRoleDN attribute defines managed role membership. You need to decide whether users can add or remove themselves from the role. To keep from modifying their own roles, you must define an ACI to that effect.

• Filtered roles determine membership through filters that are based on the existence or the values of attributes in user entries. Assign the user permissions of these attributes carefully to control who can define membership in the filtered role.

Managing Attributes With Class of Service

The Class of Service (CoS) mechanism allows attributes to be shared between entries. Like the role mechanism, CoS generates virtual attributes on the entries as the entries are retrieved. CoS does not define membership, but it does allow related entries to share data for coherency and space considerations. CoS values are calculated dynamically when the values are requested. CoS functionality and the various types of CoS are described in detail in the Sun Java System Directory Server Enterprise Edition 6.1 Reference.

The following sections examine the ways in which you can use the CoS functionality as intended, while avoiding performance pitfalls:

• Using CoS When Many Entries Share the Same Value

• Using CoS When Entries Have Natural Relationships

• Avoiding Excessive CoS Definitions

---

Note –

CoS generation always impacts performance. Client applications that search for more attributes than they actually need can compound the problem.

If you can influence how client applications are written, remind developers that client applications perform much better when looking up only those attribute values that they actually need.

---

Using CoS When Many Entries Share the Same Value

CoS provides substantial benefits for relatively low cost when you need the same attribute value to appear on numerous entries in a subtree.

Imagine, for example, a directory for MyCompany, Inc. in which every user entry under ou=People has a companyName attribute. Contractors have real values for companyName attributes on their entries, but all regular employees have a single CoS-generated value, MyCompany, Inc., for companyName. The following figure demonstrates this example with pointer CoS. Notice that CoS generates companyName values for all permanent employees without overriding real, not CoS-generated, companyName values stored for contractor employees. The company name is generated only for those entries for which companyName is an allowed attribute.

Figure 8–6 Generating CompanyName With Pointer CoS

In cases where many entries share the same value, pointer CoS works particularly well. The ease of maintaining companyName for permanent employees offsets the additional processing cost of generating attribute values. Deep directory information trees (DITs) tend to bring together entries that share common characteristics. Pointer CoS can be used in deep DITs to generate common attribute values by placing CoS definitions at appropriate branches in the tree.

Using CoS When Entries Have Natural Relationships

CoS also provides substantial data administration benefits when directory data has natural relationships.

Consider an enterprise directory in which every employee has a manager. Every employee shares a mail stop and fax number with the nearest administrative assistant. Figure 8–7 demonstrates the use of indirect CoS to retrieve the department number from the manager entry. In Figure 8–8, the mail stop and fax number are retrieved from the administrative assistant entry.

Figure 8–7 Generating DepartmentNumber With Indirect CoS

In this implementation, the manager’s entry has a real value for departmentNumber, and this real value overrides any generated value. Directory Server does not generate attribute values from CoS-generated attribute values. Thus, in the Figure 8–7 example, the department number attribute value needs to be managed only on the manager's entry. Likewise, for the example shown in Figure 8–8, mail stop and fax number attributes need to be managed only on the administrative assistant’s entry.

Figure 8–8 Generating Mail Stop and Fax Number With Indirect CoS

A single CoS definition entry can be used to exploit relationships such as these for many different entries in the directory.

Another natural relationship is service level. Consider an Internet service provider that offers customers standard, silver, gold, and platinum packages. A customer’s disk quota, number of mailboxes, and rights to prepaid support levels depend on the service level purchased. The following figure demonstrates how a classic CoS scheme enables this functionality.

Figure 8–9 Generating Servic-Level Data With Classic CoS

One CoS definition might be associated with multiple CoS template entries.

Avoiding Excessive CoS Definitions

Directory Server optimizes CoS when one classic CoS definition entry is associated with multiple CoS template entries. Directory Server does not optimize CoS if many CoS definitions potentially apply. Instead, Directory Server checks each CoS definition to determine whether the definition applies. This behavior leads to performance problems if you have thousands of CoS definitions.

This situation can arise in a modified version of the example shown in Figure 8–9. Consider an Internet service provider that offers customers delegated administration of their customers’ service level. Each customer provides definition entries for standard, silver, gold, and platinum service levels. Ramping up to 1000 customers means creating 1000 classic CoS definitions. Directory Server performance would be affected as it runs through the list of 1000 CoS definitions to determine which apply. If you must use CoS in this sort of situation, consider indirect CoS. In indirect CoS, customers’ entries identify the entries that define their class of service allotments.

When you start approaching the limit of having different CoS schemes for every target entry or two, you are better off updating the real values. You then achieve better performance by reading real, not CoS-generated values.