Chapter 2   Deployment Considerations


There are a number of issues you must resolve and options you should consider before you run the iPlanet Directory Server Access Management Edition (DSAME) installation program. This chapter provides information you should keep in mind as you plan your DSAME deployment.

Topics in this chapter include:

• Directory Issues

• Policy Management Issues

• Installing Other Products for Use with DSAME Services

• Hardware and Software Requirements

Directory Issues

---

The way you install and configure DSAME will depend upon your company's current directory environment and your long-term directory needs. Before attempting to install DSAME, you should plan your new directory—or optimize your existing directory—for the highest performance and extensibility. The following sections discuss how you can best leverage the Directory Information Tree (DIT) that comes with DSAME.

For detailed information regarding general Directory Server planning and implementation, see the Directory Server Deployment Guide available at the following URL:

  http://docs.iplanet.com/docs/manuals/directory.html

If You Already Have an Existing Directory

You can install DSAME against an existing iPlanet Directory Server that is already provisioned with user data. But immediately after you run the DSAME program, you must make modifications in both your existing directory and in the DSAME configuration so the two will work together. Modifications will vary depending upon your DIT structure, but may include:

• Adding DSAME object classes to your existing directory entries
  (This is required.)

• Adding your custom object classes to DSAME XML files

• Modifying your attribute naming scheme

These topics are discussed in detail in "Using an Existing Directory Server".

---

Note

If you're installing DSAME against an existing directory, the required directory modifications are complex. They require a high level of expertise in LDAP planning and implementation, as well as proficiency in XML. The procedures are complicated and can be time-consuming. Be sure to plan accordingly for this phase of deployment.

---

DSAME Schema

When you run the DSAME installation program, it checks to see if you already have an existing directory. If you don't have one, iPlanet Directory Server 5.1 is automatically installed for you. If you do have one, only the DSAME schema is installed for you; nothing else in your directory is modified.

Then, whether or not your directory is already provisioned with users, the following DSAME objects are created and stored in the directory:

• Special object classes

• A single organization

• Administrator roles

• DSAME service attributes and related policies

• A Super Administrator

The DSAME base suffix that is created during installation is designed for storing and managing user data. Special object classes identify the user and group entries in the directory that will managed by DSAME. These object classes make it possible for DSAME to manage only selected data—user data—and not interfere with other aspects of your tree such as servers or hardware.

The location and purpose of each of these objects are determined by whether you use a compliant or a default DIT.

Compliant vs. Default DIT

During installation, you must indicate whether you want to use an iPlanet-compliant DIT (also referred to as a compliant DIT), or the default DIT. A compliant DIT means that your directory information tree—whether it's a new one or an existing one—complies with the iPlanet DIT specification. The default DIT is simply one that does not comply with the iPlanet DIT specification.

The iPlanet-compliant DIT

The iPlanet-compliant DIT uses specialized directory objects, and its tree structure is optimized for use by hosting companies. It is useful when you want to maintain distinct branches or organizations in your directory tree so that one branch cannot access user information in another branch. Many DSAME customers want their users to share information across directory branches, and so will opt to use the default DIT.

When you choose the iPlanet- DIT (also referred to as the compliant DIT), your root suffix is assumed to contain groups and userids for top-level administrators. The default root suffix name is isp (lowercase); this name is configurable. In Figure 2-1, the root suffix is named MadisonParc. The DSAME based suffix, named ISP (uppercase), is created under the root. This is designed to contain the groups and userids for the companies you will host. This base suffix is not optional, and its name is not configurable.

In the Figure 2-1 example, the users are located under the company entry o=iplanet.com,o=ISP,o=rootsuffix. There are special top level administrator groups at the root suffix, but no users. Users are grouped in the company people containers.

Figure 2-1    The iPlanet-compliant Directory Information Tree (DIT).

Figure 2-2    A Default Directory Information Tree (DIT).

Default DITs

A default DIT is simply any DIT that does not comply with the rigid iPlanet-DIT specification. Most DSAME customers choose this option. You should choose the default DIT option if any of these are true:

• You plan to install DSAME against an existing directory that is already provisioned with user data.

• You will use DSAME in an intranet or extranet environment.

• You don't want to use the structure imposed by the iPlanet DIT.

When you choose the non-compliant option, the root suffix is also the DSAME base suffix. The default root suffix name is isp (lowercase); this name is configurable. In Figure 2-2, the root suffix is named MadisonParc.The root suffix can contain groups and userids for MadisonParc's employees and enterprise administration. A default organization, o=iplanet.com, is created under the root. This might be used to store directory entries for MadisonParc's non-administrator employees, partners, or customers.

Unsupported DITs

While most provisioned DITs can be reconfigured to work with DSAME, in some cases reconfiguration is not recommended. In general, if your existing DIT uses more than one type of directory entry (examples: dc, o, and ou) to define organizations, your user data will be recognized by DSAME only under certain conditions. For detailed information, see "DITs That Cannot Be Managed by DSAME" of this manual.

Directory Replications

If you plan to use replicated directories with DSAME, you should define your database replication agreements before running the DSAME installation program. See "Support for Directory Replication and High Availability" of this manual for more information.

Policy Management Issues

---

Delegated administration and web access management in DSAME are implemented through the use of specialized roles and policies. These are created for you at installation, and can be viewed and managed in the DSAME graphical user interface. As you plan your directory structure, consider how you can leverage these pre-defined DSAME objects to meet your enterprise needs.

Roles

DSAME roles are an extension of the roles functionality that comes with Directory Server. In Directory Server, a role is an entry grouping mechanism. This grouping mechanism is designed to be more flexible than a static group, and easy to maintain like a dynamic group.

In DSAME, the concept of roles is the same as in Directory Server, but with an added level of abstraction. When you install DSAME, several administrator roles are automatically created for you. Each administrator role specifies a different scope of access control, providing a means for delegating user account administration. You can configure a role to contain any combination of access control instructions (ACIs), policy rules or service attributes. You configure roles in the Roles page of the Administration Console.

The following table summarizes the DSAME administrator roles and the scope of write permissions that correspond to each role.

Table 2-1    The Default DSAME Administrator Roles

Administrator Role	Has permissions to modify directory entries at this level of the tree:
	Base Suffix	Role Definitions	Organization	Group	User	Own Entry
SuperAdmin	X	X	X	X	X	X
Top-Level Help Desk*			X*
Organization			X	X	X	X
Organization Help Desk*			X*
Container				X	X	X
Container Help Desk*			X*
Group				X	X	X
People Container					X	X
User (self-administrator)						X
* Help Desk Administrators can only modify passwords of users within their own branch of the tree.

When you create a directory entry, the appropriate administrator roles and access control instructions (ACIs) are created and assigned to the directory entry. You can then assign a role to an individual user.

For example, when you use DSAME to create a new organization, two new roles are automatically created and stored in the directory:

• Organization administrator role

• Organization help desk administrator

If you assign the organization administrator role to a user, mikeb, within the organization, then mikeb inherits all the permissions accorded an organization administrator. If you assign the help desk administrator role to a user, ginac, then ginac inherits the more restricted permissions of a help desk administrator. Ultimately, you'll find that using roles instead of group-based ACIs is more efficient and requires less maintenance.

Policies and URL Policy Agents

You can control access to web resources in your enterprise by applying policy to roles and organizations. A policy is made up of rules. A rule grants or denies a user access to a specified resource such as a service or a page of content stored in a server. URL Policy agents, which you install on the Web Servers in your enterprise, evaluate and enforce the policies you define.

When a user tries to access a protected resource such as a web page stored on a server in your enterprise, the DSAME Policy feature evaluates the rules attached to the user's organization, role, or userid. Based upon the net result of the rules and policies assigned to the user, the individual is either granted or denied access to the web page. You can configure rules and policies in the Administration Console. For more information, see the iPlanet DSAME Administration Guide.

Service Attributes

You can use service attributes to define how services will work with DSAME. Some service attributes are set at the global level and impact the entire DIT, some impact only individual users, and some can be set at multiple levels. To specify a value for an attribute, it's important to understand the scope of its effect. To make this easier, service attributes are organized into the following categories: global, dynamic, policy, and user.

Global. Global attributes apply to the entire DIT. You can set these values in Service Management view.

Dynamic. Dynamic attributes can be set in Service Management at the platform level or in User Management view for an organization or role. These values can also be inherited from a parent object.

Policy. Policy attributes can be set in Policy Management view. Once policy is defined, it can be applied to one or more roles and organizations. These values can also be inherited from a parent object.

User. User attributes apply to individual user entries. You can set these values in Organization Management view.

You can use the Administration Console to configure and set policy for services. For more information, see the iPlanet DSAME Administration Guide..

Installing Other Products for Use with DSAME Services

---

You can deploy DSAME with remote Web Servers, with load-balancing applications such as iPlanet Directory Access Router (iPlanet DAR), and in multi-master replications. Before you run the DSAME installation program, consider how these products might fit into your deployment. In many cases, you must install and configure these products before you install DSAME.

Remote Web Servers

In this manual, Web Servers are "remote" relative to the Web Server that runs DSAME Policy and Management services. You may already have remote Web Servers deployed to serve content pages for your enterprise. You may want to install additional ones. A remote server becomes integrated with DSAME only when you install a URL policy agent on it. For more information, see Chapter 6 "Installing URL Policy Agents" on page 115 of this manual.

For detailed Web Server installation and administration information, see the documentation that comes with the server, or access the documentation on the Internet at http://docs.iplanet.com/docs/manuals/enterprise.html.

Multiple Directory Servers for Failover and High Availability

For your convenience, a stand-alone version of Directory Server 5.1 is included in the DSAME product CD. You can use the DSAME installation program to install this version of Directory server for the purposes of upgrading, setting up failover directories, or for setting up multi-master replications. For more information, see "Configuring DSAME to Support Directory Replication", and "Installing a Stand-Alone iPlanet Directory Server".

For detailed Directory Server deployment and installation information, see the documentation that comes with the server, or access the documentation on the Internet at http://docs.iplanet.com/docs/manuals/directory.html.

Load-Balancing Applications

You can configure DSAME to work with load-balancing applications such as iPlanet Directory Access Router (iPlanet DAR). This might be useful if you want to precisely manage directory high availability. For more information, see "Configuring a Load-Balancing Application to Work With DSAME".

For detailed iDAR installation and administration information, access the documentation on the Internet at http://docs.iplanet.com/docs/manuals/dar.html.

For information on any other load-balancing application, see the documentation that comes with the product.

Hardware and Software Requirements

---

You must make sure that the systems on which you plan to install DSAME meet the minimum hardware, software, and operating system requirements. While all the DSAME components can theoretically be installed on a single server machine, you will most likely not want to do this. Please review the installation and deployment information in each component's documentation before designing your DSAME deployment. Recommended procedure is to consult with iPlanet Professional Services or another iPlanet-certified system integrator before designing and deploying an iPlanet DSAME installation.

Optimal Hardware Requirements

Hardware requirements for optimal performance and scalability are as follows:

• One 4-CPU Sun™ Enterprise™ 450 for Directory Server with 512MB to 2 GB RAM.

• One 4-CPU Sun Enterprise 450 and iPlanet Web Server together with 512MB to 1GB RAM.

• If you have existing web servers that need to be protected, the URL Policy Enforcement Point/Policy agent needs to be installed on each web server and requires 10 MB of disk space.

Recommended Hardware Configurations

---

Hardware configurationss for typical installations are as follows:

• One Sun Enterprise 450 2-4 CPU for Directory Server with 512MB to 1GB memory and approximately 300MB disk space for minimal data in Directory Server.

• One Sun Enterprise 450 2-4 CPUs for DSAME (and iPlanet Web Server) and potentially URL Policy Enforcement Point/Policy agents, with 512MB to 1GB memory and 25MB-100MB disk space (log and debug files may required additional disk space over time).

• For large installations, you should plan at least 2GB disk space to support the product binaries, databases, and log files (log files require 1 GB by default); 4GB and greater may be required for very large directories.

• If customers have existing web servers that need to be protected, the URL Policy agent needs to be installed on each web server. The agent requires 10 MB of disk space.

• Table 2-2 contains some guidelines for disk space and memory requirements depending on the number of entries managed by your Directory Server.

Table 2-2    Directory Server Disk Space Guidelines

Number of Entries	Disk Space and Memory Required
10,000 - 250,000 entries	Free disk space: 2 GB, Free memory: 256 MB
250,000 - 1,000,000 entries	Free disk space: 4 GB, Free memory: 512 MB
Over 1,000,000 entries	Free disk space: 8 GB, Free memory: 1 GB

Operating System Requirements

DSAME Version 5.0 is supported on the following platforms:

• Sun Solaris 8 for SPARC 22.6 (32-bit)

• Sun Solaris 8 for Solaris 2.8 (32-bit and 63-bit)

• Microsoft Windows 2000 Server

Patch Clusters for Solaris

When running iPlanet Directory Server on a Solaris operating system, you must ensure that the recommended patch cluster is installed. Solaris patches are identified by two numbers, for example 106125-10. The first number (106125) identifies the patch itself. The second number identifies the version of the patch (10). We recommend installing the latest version of the patch in order to benefit from the latest fixes.

Use the command 'showrev -p' to list the patches currently installed on your machine. All patches can be downloaded from http://sunsolve.sun.com. At that site, go to Patches>Recommended & Security Patches to see the list of Recommended & Security Patch Clusters for Solaris'.

For any patches not found in the above cluster, please go to Patches>Patchfinder on http://sunsolve.sun.com.

Remote Web Server Requirements

DSAME Web Agents use approximately 10 MB of disk space and are supported on the following web servers:

• iPlanet Web Server 6.0

• iPlanet Web Server 4.1 Service Pack 8

Web Browser Requirements

Administrators and end users use web browsers to perform user management tasks. You can access the DSAME from a browser in the Unix or PC environment.

• Netscape Communicator 4.75

• Microsoft Internet Explorer 5.5 Service Pack 1