Chapter 2   Deployment Planning


There are a number of issues you must resolve and options you can consider before you begin to install Delegated Administrator. This chapter provides information you'll need for planning and installing Delegated Administrator. The chapter includes the following sections:

• Determining Your Delegated Administrator Needs

• Flexible DIT Options

• Options to Consider Before Installation

• Implications of Customizing Delegated Administrator

Determining Your Delegated Administrator Needs

---

When you install Delegated Administrator, if you are provisioning a directory for the first time, a base suffix is automatically created for you. It is designed for storing and managing user data. Special object classes identify the user and group entries managed by Delegated Administrator. These object classes make it possible for Delegated Administrator to manage only selected data—user data—and not interfere with other aspects of your tree such as servers, services, or hardware. The way you use the default base suffix depends upon your company's current directory environment and your long-term directory needs.

Figure 2-1    Delegated Administrator Default Administrator Types.

The following are common scenarios for Delegated Administrator 4.5 customers:

• You are provisioning a user database for the first time.

• You have already deployed a directory server and have provisioned it with user accounts, but have not deployed Delegated Administrator.

• You have already deployed a directory server with a pre-4.5 version of Delegated Administrator.

In any case, before attempting to install Delegated Administrator 4.5, you should plan or optimize your user directory structure for performance and extensibility. The following sections offer suggestions for effectively using the Delegated Administrator base suffix. For detailed information regarding general directory planning and implementation, see the Directory Server Deployment Guide available at the following URL:
http://home.netscape.com/eng/server/directory/4.1/deploy/contents.htm.

The Delegated Administrator DIT

The default Delegated Administrator base suffix contains directory entries and appropriate Access Control Instructions (ACIs) required to support seven types of administrators:

• Top-level Administrator

• Top-level Help Desk Administrator

• Organization Administrator

• Organization Help Desk Administrator

• Group Administrator

• End User (acting as an Administrator)

• Authentication Administrator

In Figure 2-2, the End User is represented by a uid such as uid=chris. The Authentication Administrator is represented by uid=NDAUser.

Figure 2-2    Implementation of the Delegated Administrator DIT.

Each administrator has specific privileges as defined in the Delegated Administrator ACIs (see Table 2-1). To see the actual ACIs, see Appendix , "Delegated Administrator Access Control Instructions (ACIs)," on page 427. The Top-level Administrator has the widest scope of access privileges. Administrators further down in the tree have a more narrow scope of administrative responsibilities.

Table 2-1    A summary of Administrator privileges.

		Can modify these directory entries
Administrator	Access Privileges	Root	Organi- zation	Group	Others' Accounts	Own Account
Top-level	Can create, modify, and delete entries across all organizations; can change organizations size limits.Typically creates new organizations and groups; creates peer Top-level administrators.
Organization	Can create, modify, and delete entries in all groups within own organization; cannot change organization size limits.Typically creates new organizations and groups; creates peer organization administrators.
Group	Can create, modify, and delete entries within own group; cannot change group size limits. Typically creates new groups and new user entries; creates peer group administrators.
Top-level Help Desk	Can modify Password attribute for any user across all organizations.
Organization Help Desk	Can modify Password attribute for any user in own organization.
User Account	Can access own directory entry; can modify only selected user attributes.
Authentication Administrator	Is not a real user, but a directory entry used only for authentication purposes.

The Authentication Administrator

The Authentication Administrator is a user entry, uid=NDAUser, stored under ou=config in Directory Server. Its special purpose is to act as an agent for Delegated Administrator, binding to the directory during authentication when necessary.

Organizations and Groups

A Delegated Administrator organization (called a domain in previous versions of the program) is a container for multiple user-directory entries. It is similar to an administrative organization such as o in LDAP, but it is not exactly the same. It uses the object class NSManagedDomain. By default, each Delegated Administrator organization includes containers ou=Groups and ou=People. The information about each organization unit is stored in two subtrees. The Groups subtree stores group information, and the People subtree stores user entries.

When you create a Delegated Administrator organization, a new entry is created in the directory. The following is the directory entry for the default organization Siroe.com:

dn: o=Siroe, o=ISP objectClass: top objectClass: organization objectClass: nsManagedDomain # objectClass: nsUniquenessDomain o: Siroe.com nsMaxUsers: 1000 nsMaxDepts: 100 nsMaxMailLists: 1000 nsNumMailLists: 0 nsMaxDomains: 10 nsNumDepts: 0 nsNumUsers: 0 nsNumDomains: 0

A Delegated Administrator group (called a department in previous versions of Delegated Administrator) is similar to an administrative group such as ou in LDAP, but the two are not exactly the same. A Delegated Administrator group is a set of users that share a common value for the attribute memberOf. When you create a group, a new entry is added to the directory. Group entries include the object class nsmanagedDeptAdminGroup. For example, the following entry is located under ou=Groups in the Siroe organization.

dn: cn=Domain Administrators, ou=Groups, o=Siroe, o=ISP objectClass: top objectClass: groupOfUniqueNames objectClass: nsManagedDeptAdminGroup objectClass: inetAdmin cn: Domain Administrators adminRole: Domain Administrators uniqueMember: uid=michael, ou=People, o=Siroe, o=ISP

When you add a user to a group, you are adding the group's name to the user's directory entry; the group name becomes a value for the attribute memberOf. For example, the following user entry is located in ou=People under the Siroe organization. The memberOf attribute indicates which groups the user belongs to. In this example, the user is a member of the Domain Administrators group.

dn: uid=michael, ou=People, o=Siroe, o=ISP objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: nsManagedPerson objectClass: mailRecipient objectClass: nsMessagingServerUser uid: michael userPassword: morton cn: Michael Morton sn: Morton givenName: Michael telephoneNumber: 650.555.1212 mail: michael@Siroe.com nsDADomain: Siroe nsDACapability: mailListCreate memberOf: cn=Domain Administrators, ou=Groups, o=Siroe, o=ISP

Figure 2-5 on page 34 illustrates the locations of the Siroe organization and the Organization Administrators' group in the default Delegated Administrator tree.

Configuration Branch

In the default Delegated Administrator base suffix, the configuration branch is located at the same level as the top-level organizations, although this is configurable during installation. In Figure 2-1, the configuration branch is located at the same level as the default organization Siroe. It contains information about Delegated Administrator data types, servlets, macros, and operations mapping. You can see this information when you view the Directory Server through Netscape Console.

Figure 2-3    Use the Directory Server window to view Delegated Administrator configuration.

Guidelines for Optimal Performance

While Delegated Administrator can handle millions of users, you can optimize search and page-handling performance if you design your directory tree using these guidelines:

• Delegated Administrator will easily handle a user directory with over 1,000,000 users. However, for best performance, iPlanet recommends that you plan for no more than 100 total organizations, and no more than 100 groups in a single organization.

• If possible, the directory tree should be designed with a minimal number of hosting branches. These are branches in the tree which have numerous hosted organizations beneath them. A flatter tree design requires fewer Delegated Administrator templates to be modified for use.

• Minimize the number of indexes within the directory server to just the indexes which are going to be used. While it is possible to enable numerous attributes to search upon, this is not recommended. The maintenance of those additional attributes will have a negative impact upon performance.

• See the Directory Server Deployment Guide for more information about optimal performance and turning.

Provisioning a User Directory for the First Time

If you don't already have a directory deployed, you'll be installing Netscape Directory Server 4.12. You can use the Delegated Administrator tree as the base suffix in your new directory. Two groups of administrators are created at the top level of the tree. A default organization, named Siroe, was designed to help you get started right away. At the top-level of the Delegated Administrator suffix, the user chris is a member of the Service Administrators group. He can change the organization name, create new administrators, and create new organizations.

You can use the default tree whether yours is a hosting environment or an internal intranet. For example, Figure 2-4 illustrates how a hosting company might adapt the Delegated Administrator tree.

Figure 2-4    Delegated Administrator DIT in a hosting environment

Figure 2-5 illustrates how a company might use the Delegated Administrator tree for its internal intranet. In any case, when provisioning your user directory for the first time, you should also follow the guidelines in the Directory Server Deployment Guide.

Figure 2-5    Delegated Administrator tree used in an intranet

Using an Existing User DIT

If you've already deployed and provisioned a directory server, you'll need to modify your existing DIT to include Delegated Administrator object classes, attributes, and Access Control Instructions (ACIs). Once you make the necessary changes, you can install Delegated Administrator and use it to add new organizations and suborganizations to your tree, create new administrators and administrator types. Depending upon your DIT, there may be additional customization work you have to do to make Delegated Administrator work with your directory.

For detailed information on reconciling your existing DIT and the Delegated Administrator DIT, see Using an Existing User Directory.

Upgrading an Existing Delegated Administrator Installation

When upgrading an existing instance of Delegated Administrator, you must reconcile your existing directory information tree (DIT) and the Delegated Administrator tree. Depending upon your existing DIT, this reconciliation may include:

• Modifying the user directory to include Delegated Administrator object classes, attributes, and Access Control Instructions (ACIs)

• Modifying Delegated Administrator attributes and ACIs to support your existing tree.

• If you've modified Delegated Administrator templates (the user interface), making those changes to the templates in the upgraded instance.

• Upgrading Delegated Administrator to version 4.5.

For detailed information on upgrading Delegated Administrator instances, see Upgrading from Delegated Administrator Version 4.11.

Flexible DIT Options

---

Delegated Administrator provides the means to create new containers and administrator roles in your directory. This makes it possible for you to design a tree that extends beyond the base suffix, or to adapt your existing user directory more easily to the Delegated Administrator tree.

Nested Containers

The default Delegated Administrator tree uses a single level of organizations, and a single level of groups beneath each organization (see Figure 2-2). However, you can add multiple levels of organizations and groups to the tree to meet your enterprise or hosting needs. A container can use any LDAP container attribute such as o, ou, or cn, as long as it conforms to these five rules:

• Each organization must include a container for user entries; groups cannot include containers for user entries.

• A group can be created beneath an organization.

• An organization can be created beneath an organization; it is called a suborganization.

• A group can be created beneath a group; it is called a subgoup.

• An organization cannot exist beneath a group.

Whether you need to create nested containers depends upon your directory needs. For example, CompanyABC is a single company with offices worldwide. It's installing Directory Server for the first time, expressly for use with Delegated Administrator. It treats each of its office location as a separate operation. Although most day-to-day user lookups and data management happen within a single location, the CompanyABC must still be able to roll up financials and employee records for the entire company. CompanyABC easily adapts the Delegated Administrator default tree for its purposes.

Figure 2-6    This intranet uses Delegated Administrator default organizations and groups.

CompanyXYZ hosts a number of companies, and uses an existing instance of Directory Server. Each company has its own unique tree structure, in some cases requiring multiple levels of organizations. Company XYZ uses Delegated Administrator to create suborganizations and subgroups that map to the existing directory instance (see Figure 2-7).

Figure 2-7    This hosting company created new suborganizations and subgroups to map to an existing user directory.

By default, both Top-level and Organizations Administrators can create organizations and suborganizations, groups and subgroups. Group Administrators can create only groups and subgroups.

Customized Administrator Types

The default Delegated Administrator types (Top-level, Organization, Help Desk, and Group) will meet basic directory needs. But you may find it necessary to modify one or more of these types, or to create a brand new type. For example, CompanyABC wants to restrict the access privileges of all Help Desk Administrators. After modifying the administrator type, the Help Desk Administrator will be able to initiate the edit password procedure, but he will not be able to access the password the user enters during the procedure. In this case, Company ABC modifies the Help Desk Administrator type by extending the SetPassword functionality.

In another example of customization, CompanyABC creates a new suborganization. Since Delegated Administrator does not have a Suborganization Administrator group, CompanyABC creates a new administrator type. For detailed information on creating new administrator types, see Chapter 14 "Customizing Configuration in the Directory."

Options to Consider Before Installation

---

Before you begin to install Delegated Administrator, you should have a clear vision of the optional features you want to implement. The following custom configurations require the use of other servers working with Delegated Administrator, and may take extra preparation or time to deploy.

Directory Server Configuration and User Data

During installation, you'll be asked to specify locations for two types of directory information: configuration data and user data. Delegated Administrator will store information about its datatypes, servlets, macros, and operations mapping in the configuration branch of the Directory Server. When you modify user and group information in Delegated Administrator, those changes are made in the user directory.

Both configuration directory and user directory must exist on the same computer system. If Delegated Administrator is configured to use a configuration suffix that differs from the user suffix, Top-level and Organization Administrators can not access the configuration files.

If you're deploying Directory Server with Delegated Administrator for the first time, follow the guidelines regarding directory configuration in the Directory Server Deployment Guide.

Optimizing Directory Searches

When performing a generic or too broadly defined search on a large directory, Delegated Administrator will time out. You can optimize Delegated Administrator page handling and search performance by modifying the Directory Server configuration. The following measures are necessary when any organization in your directory exceeds 5000 users:

• Add indexes for the nsdadomain, memberof, and uid attributes.

• Reset the lookthroughlimit parameter.

• Reset sizelimit parameters.

• Set the All ID Threshold value appropriately.

See "Chapter 3 "Basic Installation and Configuration" in the Delegated Administrator Deployment and Customization Guide for further instruction.

Messaging Server Support

You can configure Delegated Administrator so that when you create a user account, Messaging Server-related attributes are added to user's entry in the directory. This makes it possible for Messaging Server to deliver mail to the user. Delegated Administrator provides three levels of support for Messaging Server. During Delegated Administrator installation, you must choose one of the following:

• No Messaging Server
  Choose this option if you do not intend to use Netscape Messaging Server or iPlanet Messaging Server. For example, choose this option if you are using a different brand of server, or if you do not use Directory Server for managing Messaging Server configuration.

• Netscape Messaging Server 4.1
  Choose this option if you already have Messaging Server 4.1 deployed, or are planning to install it with Delegated Administrator.

• iPlanet Messaging Server 5.0
  Choose this option if you already have Sun Internet Messaging Server 4.x installed, or if you are planning to install iPlanet Messaging Server 5.0.

Although you don't have to have Messaging Server already installed, you'll save yourself a few steps later on if you can enter the Messaging Server URL during Delegated Administrator installation. After installing Delegated Administrator, you must configure the Messaging Server so the two will work together. For detailed information, see Enabling Optional Features.

---

Note	Messaging Server does not support LDAP over an SSL connection at this time.

---

Certificate-based Authentication

Certificate-based authentication is a means of confirming a user's identity before allowing the user access to Delegated Administrator. When you configure Delegated Administration for certificate-based authentication, Administrators and End Users log in using digital certificates instead of user names and passwords. This provides an extra measure of security for your directory.

Certificate-based authentication is part of the Secure Sockets Layer (SSL) protocol. It requires the use of a Certificate Server—your own or one belonging to a trusted Certificate Authority. You should have a thorough knowledge of SSL and some experience using Certificate Server before attempting to enable this feature. See "Enabling Optional Features" on page 71 for more information.

Class of Service

Class of Service (CoS) is an LDAP feature that enables you to manage a group of attributes that describe a category or class of service. Once you've defined the attributes and created the new classes in the directory, you can automatically assign a class of service to selected user entries. This eliminates having to store all service-related attributes in each user entry in the directory. It also makes it easier to make changes when necessary. If a class of service changes, you need only change its attributes in the class definition. You don't have to change the attribute values in each user entry.

Setting up this feature requires a special directory plugin. The Class of Service plugin is automatically installed when you install Delegated Administrator, but needs to be configured before it can be used. Detailed instructions are in Step 2: Configure the Directory Server Plug-ins.

Other Configuration Options

While planning your deployment, you should also consider a number of options that can be enabled after installing Delegated Administrator. You'll find detailed information about each of the following options in Chapter 4 "Enabling Optional Features." Topics include:

• Secure Sockets Layer (SSL)

• User ID Uniqueness

• User Directory Failover

• Password Reset Policy

• Single Sign-On with Netegrity SiteMinder

Implications of Customizing Delegated Administrator

---

You can customize Delegated Administrator in three ways:

• Modify templates.

• Modify the directory configuration.

• Extend the servlet functionality.

As you plan your Delegated Administrator deployment, be sure to think through the impact of your planned changes.

Modifying the templates. Many changes to the user interface require only minor changes in the template's HTML code. For example, to change a field in the Search interface, you need only copy a few lines of HTML code from an existing field, and paste them into an HTML template file. There are no back-end changes to make.

However, your modified template may cause inconsistencies throughout the user interface that you'll want to address. For example, any time you add an input field to the user interface, you may want the information that you entered into that field to display in other parts of the interface. You'll have to modify related templates, and perhaps also modify Help file that corresponds to each template you modify.

Modifying the directory configuration. Each time you add nested containers, or create a new administrator role, you'll be modifying ACI's and directory schema. These changes require changes in the directory configuration, more far-reaching than changes to the user interface. Additionally, you'll also have to create new templates that correspond to the Administrator or container.

Extending servlet functionality. Extending a servlet requires writing additional servlet code. For example, by default, the Help Desk Administrator has access privileges to read and write users' passwords. CompanyABC wants to customize the Help Desk Administrator role so that he can initiate setting the password, but cannot actually read the password that the user enters.

Since the servlet already exists, CompanyABC can simply extend the servlet functionality. You accomplish this by extending the base class, NDAServlet, and implementing the execute() method. The ACI entries for the Help Desk Administrator must also be modified.

If you're thinking of customizing Delegated Administrator at all, you should read Part 4, "Customizing Delegated Administrator," on page 285 of this manual.