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 schema

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

You can install DSAME schema by choosing option 3) iPlanet Directory Server Configuration for DSAME. Only the DSAME schema is installed on the server where the Directory Server is installed. The schema file 95ns-amschema.ldif file is added to your server schema directory.

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 Top-level 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 be 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.

Figure 2-1    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.

In Figure 2-1, the root suffix is named MadisonParc.The root suffix can contain groups and userids for MadisonParc's employees and enterprise administration. In Default DIT you can configure the default root suffix to the organization name. 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 Replication

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 can configure roles in the Roles page of the Administration Console. You can also create roles with specific permissions to provide a customer delegation model.

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
Top-Level Administrator	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 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 about setting up policies, see the iPlanet DSAME Administration Guide. For comprehensive information about DSAME policy agents and how to install and configure them, see the iPlanet Agent Pack documentation at http://docs.iplanet.com/docs/manuals/dsame.html#agent10

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 global 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 at http://docs.iplanet.com/docs/manuals/dsame.html

Installing Other Products for Use With DSAME Services

---

You can deploy DSAME with remote Web Servers, with LDAP load-balancer such as iPlanet Directory Access Router, 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 "URL Policy Agent".

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

iPlanet Application Server

You can install and configure DSAME Services to run on iPlanet Application Server for Solaris instead of on the default Web Server. This option is not available on the Windows platform.

URL Policy Agent

The DSAME URL policy agent can be installed on various web servers installed in your enterprise. The agent enforces access rules and policies that are set on specific pages stored on the server. The agent intercepts each request received by a configured Web Server and communicates with the Policy service. The Policy service authenticates the user's credentials, and then examines the user's roles and policies. If the user has the proper credentials and policy assignment, the agents allow the user to access the URL over HTTP.

The DSAME Policy Agent Pack contains a number of URL policy agents designed to work with DSAME. The Policy Agent Pack is a separate product and is available for download at the following URL:

http://www.iplanet.com/downloads/developer/5167.html

To install a URL policy agent, see the instructions that come with the product.

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 replication.You should install, configure and deploy iDS properly for DSAME to be successful. For more information, see "Support for Directory Replication and High Availability" for Solaris, or on page 199 for Windows.

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

LDAP Load-Balancers

You can configure DSAME to work with load-balancers such as iPlanet Directory Access Router. This might be useful if you want to precisely manage directory high availability. For more information, see "Support for Directory Replication and High Availability" for Solaris, or on page 199 for Windows.

For detailed iPlanet Directory Access Router 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-balancer, 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. The 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 computer system with 512MB to 2 GB RAM for Directory Server.

• One computer system with 512MB to 1GB RAM for iPlanet DSAME.

• 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.

Typically, directory resource requirements are high. The actual requirements differs from the above. They are based on customer specific, data, and usage characteristics.

Recommended Hardware Configurations

---

Hardware configurations for typical installations are as follows:

• One computer system for Directory Server with 512MB to 1GB memory and approximately 300MB disk space for minimal data in Directory Server.

• One computer system for DSAME (and iPlanet Web Server) and potentially iPlanet Application Server and URL Policy agents, with 512MB to 1GB memory and 25MB-100MB disk space. Log and debug files may require additional GB 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 you 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.1 is supported on the following platforms:

• Sun Solaris 2.8 (32-bit and 64-bit)

• Microsoft Windows 2000 Server SP 2

Patch Clusters for Solaris

When running iPlanet Directory Server on a Solaris 8 operating system, you must ensure that the recommended patch cluster is installed. Solaris patches are identified by two numbers, for example 108827-15. The first number (108827) identifies the patch itself. The second number identifies the version of the patch (15). 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. For detailed information on Web Server requirements for DSAME Web Agents, see the iPlanet Agent Pack documentation at the following URL:

http://docs.iplanet.com/docs/manuals/dsame.html#agent10

Application Server Requirements

If you choose to install DSAME services on iPlanet Application Server, both the Application Server as well as its iPlanet Web Server must already be installed and running. This deployment requires the following:

• iPlanet Web Server 6.0 SP2 on Solaris 2.8 (32-bit or 64-bit)

• iPlanet Application Server 6.5 on Solaris 2.8 (32-bit or 64-bit)

Web Browser Requirements

Administrators and end users use web browsers to perform user management tasks. DSAME supports the following web browsers:

• Netscape Communicator 4.79 on the following platforms: Solaris 8; Windows versions NT 4.0 SP6a and 98SE.

• Microsoft Internet Explorer 5.5 SP 2 on the following Windows versions: 2000 Professional, NT 4.0 SP 6a, and 98 SE.

• Microsoft Internet Explorer 6.0 on the following Windows versions: 2000 Professional, XP Professional, XP Home, NT 4.0 Sp6a.