Previous     Contents     Index     Next     
iPlanet Delegated Administrator 4.5 Deployment and Customization Guide



Chapter 4   Enabling Optional Features


Once you've completed the basic installation, you can configure Delegated Administrator to use one or more optional features. This chapter provides instructions for enabling the following:



The Sample LDIF Data File

Directory Server uses the LDAP Data Interchange Format (LDIF) to describe a directory and directory entries in text format. An LDIF file is commonly used to initially build a directory database or to add large numbers of entries to the directory all at once.

Delegated Administrator comes with a sample LDIF file describing 20 domains and containing 50 users. The data in the sample LDIF file is entirely distinct from the default data that is created at installation. It is much larger by comparison, and requires some extra steps before you can use it.You can use this sample data for testing purposes or for learning how to use the product. Installing and using this sample data is entirely optional.

In order to use the contents of the sample LDIF file, use these instructions to do the following:

  • Download the sample LDIF file.

  • Add a base suffix in the directory for the sample data.

  • Import entries from the sample LDIF to the directory.

  • Modify the Delegated Administrator resource.properties file.


Downloading the Sample LDIF File

Go to the Delegated Administrator Documentation website at:

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

Follow instructions for downloading the file ds_big.ldif.


To Add the LDIF Base Suffix to the Directory

  1. On the Directory Server Console select the Configuration tab.

  2. Select the Database icon in the navigation tree.
    This displays the database settings in the right pane.

  3. Select the Settings tab.
    This tab contains a list of all the current suffixes in your directory.

  4. Click Add, and enter the new suffix o=ISP (or whatever you chose as the root of the installation).

  5. Click Save.


To Import the Sample LDIF Using the Directory Server Console

  1. On the Directory Server Console select the Configuration tab.

  2. From the Console menu, select Import.

  3. If you are running the Directory Server Console on the server's host machine, skip to step 4. Otherwise, if you want to import a file from the local machine, select "From local machine." If you want to import a file from the server's host, select "From server machine."

  4. Enter the full path to the file ds_big.ldif.

  5. Select Append Data to Database.
    When you import using this option, the server does not delete the contents of the directory before adding the entries from the LDIF file.

  6. Click OK.


To Modify the Properties File

  1. In the Delegated Administrator root, locate the file

    <DelegatedAdmin_root>/nda/classes/netscape/nda/servlet/resource.properties

  2. In the line NDAServlet-ldapsuffix=o=<your_suffix>, change the base suffix to o=ISP (or whatever you chose as the root of the installation).

  3. Save the file.

  4. Restart the Web Server.



Secure Sockets Layer (SSL)

Delegated Administrator can be configured to use SSL-based connections, called LDAPS connections, to Directory Server in its default DatabaseInterface. These instructions refer to the back-end connections between the Delegated Administrator servlet engine and the directory. The front-end connections between the client browser and the web server that serves Delegated Administrator are another matter. To configure the front-end connections between the client browser and the web server, see the documentation that came with your Web Server.

The default behavior of Delegated Administrator is to use non-SSL-based LDAP connections between the servlet engine and Directory Server.


To Use SSL-based LDAPS Connections

  1. Configure Directory Server and Web Server to support SSL-based LDAPS connections between them, following the instructions in the Directory Server Administrator's Guide.

  2. Open the file <DelegatedAdmin_root>/nda/classes/netscape/nda/servlet/resource.properties, and make the following changes:

    • Change the line LDAPDatabaseInterface-ldapssl=false to LDAPDatabaseInterface-ldapssl=true.

    • Modify the line LDAPDatabaseInterface-ldapsslport=<port number> to reference the new Directory Server LDAPS port as configured in step 1.

  3. Save the file.

  4. Restart the Web Server.



UserID Uniqueness

Delegated Administrator supports a flexible userID uniqueness policy. UserID uniqueness may be enforced within each organization, or across all organizations in the Delegated Administrator tree.

When userIDs are enforced to be unique only within each organization, then a userID such as bob can exist in multiple organizations without conflict. For example, there can be a bob in the Siroe organization and a bob in the Airius organization even though both organizations are managed by Delegated Administrator.

However, when userIDs are enforced to be unique across all organizations, if the userID bob exists in the Siroe organization, you cannot create a userID bob in the Airius organization. By default, userID uniqueness is enforced across all organizations.


The UserID Uniqueness Plug-In

Netscape Directory Server comes with a plug-in that you can use to enforce uniqueness of an attribute within a subtree such as an organization. The plug-in can be configured through a marker— an entry above the insertion point of a new entry. The entry has an object class that identifies it as the top of a uniqueness tree.


How it Works

In the following example (see Figure 4-1), nsManagedDomain is the object class used as the marker of the uniqueness tree. Uniqueness is enforced within each of the following organizations:

  • o=East,o=Siroe,o=ISP

  • o=West,o=Siroe,o=ISP

  • o=Airius,o=ISP

o=Siroe,o=ISP could be a uniqueness domain, but its only container children also have the marker object class, and uniqueness is enforced from the bottom up.

Figure 4-1    The objectclass nsManagedDomain marks the top of each uniqueness tree.

If you want to enforce uniqueness across non-nested suborganizations, you can use a configuration such as in Figure 4-2. In this example, nsUnique is the marker objectclass and person (for uid=joe) is the objectclass to enforce uniqueness on.

Figure 4-2    The objectclass nsUnique marks each ou=People container as the top of a uniqueness tree.

This configuration has a separate uniqueness domain for each ou=People container. There are four uniqueness domains, with no overlap.


Configuring the UserID Plug-in

If you're installing Delegated Adminstrator against an existing directory information tree (DIT), you must first add the appropriate objectclasses to your existing directory entries. See Appendix , "Using an Existing User Directory," for more information. Then use the following instructions to configure the plug-in. Once the plug-in is configured, the necessary object classes are automatically added each time you use Delegated Administrator to create new objects.


To Configure the UserID Plug-in

  1. Stop Directory Server.

  2. In the Directory Server root, locate the following file:

    <Directory_root>/slapd-<identifier>/config/slapd.ldbm.conf

  3. Be sure that the following line is commented out (begins with a pound sign). Example:


  4. Modify the following plug-in invocation line to meet your needs;:

    plugin preoperation on "attribute uniqueness" <Directory_server_root>/lib/uid-plugin.so NSUniqueAttr_Init "attribute=uid" "markerObjectClass=nsUniquenessDomain" "requiredObjectClass=nsManagedPerson"

    The plug-in invocation line takes the following:

    • attribute. Specifies the attribute name.

    • markerObjectClass. Specifies the object class that marks the top of the uniqueness tree.

    • requiredObjectClass. Optinal. Specifies an object class which must be present in an entry in order for uniqueness to be enforced.

    Example:

    To enforce uid uniquness within a tree with the object class nsManagedDomain at the top (Figure 4-1), and where only entries with the object class nsManagedPerson are considered, modify the entry as follows:

    plugin preoperation on "attribute uniqueness" <Directory_server_root>/lib/uid-plugin.so NSUniqueAttr_Init "attribute=uid" "markerObjectClass=nsManagedDomain" "requiredObjectClass=nsManagedPerson"

  5. Save the file.

  6. Restart Directory Server.



User Directory Failover

After you've installed Delegated Administrator for the first time, the Directory server you used during installation becomes the "master" Directory server. You can set up other Directory servers that use the same base suffix as the master Directory server so that if the master fails for any reason, then Delegated Administrator fails over or uses a backup of the master.

Before you can enable user directory failover in Delegated Administrator, you must set up Server-Initiated Replication (SIR) agreements in each Directory server that you will use as a backup. For detailed information about directory replication, see the documentation that comes with Directory server:

  • Directory Server Administrator's Guide at http://docs.iplanet.com/docs/manuals/directory/41/admin/replicat.htm

  • Directory Server Deployment Guide at http://docs.iplanet.com/docs/manuals/directory/deploy30/rep.htm#1013789


Setting up the Directory Servers

In each Directory server you plan to use for Delegated Administrator directory failover, make sure the server uses the same Base DN, Bind DN and Bind Password. After you've set up the Directory servers for SIR agreements, then you can enable user directory failover in Delegated Administrator.

Note If the Directory servers are in SSL mode, and you are using multiple Certificate Manangers to import certificates, be sure that each certificate manager has a different name.



To Set Up the Directory Servers for Failover

  1. In each of the Directory servers you want to use as backup directories, manually create the same base suffix that you created in the master Directory server when you first installed Delegated Administrator.

    1. On the Directory Server Console select the Configuration tab.

    2. Select the Database icon in the navigation tree. This displays the database settings in the right pane.

    3. Select the Settings tab. This tab contains a list of all the current suffixes in your directory.

    4. To add the new suffix, click Add and enter the suffix in the field that appears.

    5. To modify an existing suffix, double-click the suffix in the list and make your changes.

    6. Click Save.

  2. Follow the instructions in the Directory Server Administrator's Guide for creating a supplier-initiated replication (SIR) agreement. (See http://docs.iplanet.com/docs/manuals/directory/41/admin/replicat.htm#1047117.) As you follow the instructions:

    • The master Directory server is the supplier server, and the backup servers are the consumer server.

    • When prompted, select the base suffix you used when you installed Delegated Administrator for the first time (the suffix in the master Directory server.)


Enabling User Directory Failover in Delegated Administrator

Once you've set up replication agreements between the master Directory server and all backup servers, you must configure Delegated Administrator.


To Enable User Directory Failover in Delegated Administrator

  1. Locate the following file:

    <DelegatedAdmin_root>/nda/classes/netscape/nda/servlet/resource.properties

  2. Modify the variable LDAPDatabaseInterface-ldaphost variable to include a space-separated list of backup servers. Example:

    LDAPDatabaseInterface-ldaphost=<host1>:<port1> <host2>:<port2> <host3>:<port3>

    Providing a port number is optional. However, if the the port number is missing, it will default to the LDAP port value obtained from the same resource.properties file. If security is turned off, the value is obtained from LDAPDatabaseInterface-ldapport. If security is turned on for the LDAP connection, the value is obtained from LDAPDatabaseInterface-ldapsslport .

  3. If you want to establish an SSL connection between the Directory server and Delegated Administrator, you must also add this line to the resource.properties file:

    LDAPDatabaseInterface-ldapssl=true ###*

  4. Restart the Web Server against which Delegated Administrator was installed .



Password Reset Policy

A password policy is a set of rules that govern how passwords are evaluated in the user directory. The password policy mechanism provided by the Directory Server allows you to dictate such things as minimum password length or when users' passwords expire. When a user attempts to bind to the directory, the Directory Server uses the rules defined by the password policy to ensure that the password is valid before allowing the user to bind to the directory.

Delegated Administrator extends the password reset and expiration policies to the users it manages. To make this work, you must modify the password policies in Directory Server, and then modify the Delegated Administrator configuration.


To Modify the Password Policy

  1. In the Directory Server Console, click the Configuration tab, and then click the Database folder.

  2. Select the Passwords tab in the right pane. The following password parameters are configurable. For detailed information about these parameters, see the Directory Server 4.11 Administrator's Guide. The first parameter listed here is the one that can be extended to Delegated Administrator.

    User must change password after reset. To specify that users must change their password the first time they log on, select this option.

    User May change password. To specify that users can change their own passwords, select this option.

    Allow Changes in X Day(s). To specify that users cannot change their password for a specified number of days, enter the number of days they cannot change their passwords.

    Keep Password History. To configure the server to maintain a history list of passwords used by each user, select this option.

    Remember X Passwords. If you configure the server to keep password histories (above), specify the number of passwords you want the server to keep for each user.

    Password never Expires. If you do not want user passwords to expire, select this option..

    Password Expires After X Days. If you want users to have to change their passwords periodically, select this option, and then enter the number of days that a user password is valid.

    Send Warning X Days Before Password Expires. If you have turned password expiration on (above), you need to enter the number of days before the password expires to send a warning to the user.

    Check Password Syntax. If you want the server to check the syntax of a user password to make sure it meets the minimum requirements, select this option.

    Password Minimum Length. If you turn password syntax checking on (above), you need to specify the minimum acceptable length.

    Password Encryption. Use the drop-down list to specify what encryption method you want the server to use when storing passwords.

  3. When you have finished making changes to the password policy, click Save.


To Modify the Delegated Administrator Configuration

  1. In the directory where Delegated Administrator is installed, locate this file:

    <DelegatedAdmin_root>/nda/classes/netscape/nda/servlet/resource.properties

  2. In the following property, the default value is false. To enable password change after reset, set this property to true:

    LDAPDatabaseInterface-ldapenablepasswordreset

  3. This property specifies the correction to be added to GMT to obtain local (standard) time on the server:

    LDAPDatabaseInterface-ldapservertimeoffset

    The Delegated Administrator servlets may be running at a location other than where the Directory Server is installed. If the servlets are running in the same time zone as the Directory Server, this property need not be set. Otherwise, set it to a string of the form: [-]HH:MM. For example, for the Pacific Time Zone, this string would be -8:00. This property uses standard time only and so corrections should not be made for Daylight Savings Time.

  4. This property specifies the OS type of the host running the Directory Server. This is required to handle the different password expiration times used by the iPlanet Directory Server, based upon the type of OS. Set this property to either unix (the default) or nt as appropriate.

    LDAPDatabaseInterface-ldapserverostype

  5. In order for the changes to this file to take effect, restart the Web Server.



Single Sign-On

Delegated Administrator supports Single Sign-On through the use of Netegrity SiteMinder. Single Sign-On is a means for a user to log in once, using a single password, and obtain authenticated access to all servers that user is authorized to use. This feature has a number of benefits to both users and administrators including the following:

  • Ease of use.

    Users can log in once and not be interrupted by repeated requests for passwords.

  • Password are limited to local machine.

    To log in, the user types a single password that protects the private-key database on the local machine. Passwords are not sent over the network.

  • Simplified management.

    Administrators can control who is allowed access to which servers by controlling the lists of certificate authorities maintained by client and server software. These lists are shorter than lists of user names and passwords and don't change as often.

  • Access control is not affected.

    Single sign-on involves replacing client authentication mechanisms, not access-control mechanisms. Administrators don't need to change existing ACLs that may have been originally set up to work with basic password authentication.


Before You Begin

Before installing and configuring SiteMinder Policy Server to work with Delegated Administrator, the following must be installed and running:

  • Directory Server 4.12

  • Enterprise Server 4.1SP2

  • iDA 4.5


Installing Siteminder on Windows NT

  • When installing Siteminder on Windows NT, you must log into a Windows NT 4.0 account with local administrator privileges.

  • For detailed installation instructions, see the SiteMinder Installation Guide that comes with the product.


Installing the Siteminder on Solaris

SiteMinder requires Solaris 2.5.1 or later. The following patches are required and recommended for the following versions of Solaris2.6

  • Solaris 2.6 kernel update = 105181-17

  • C++ shared library = 105591-07

  • libc = 105210-25

  • libthread = 105568-14

  • patchadd = 106125-08

For detailed installation instructions, see the SiteMinder Installation Guide that comes with the product.


Configuring SiteMinder

To configure SiteMinder to work with Delegated Administrator, use the instructions in this section and the Netegrity SiteMinder manual entitled SiteMinder Policy Server Operation Guide to perform the following:

  • Log in to SiteMinder

  • Create Agents

  • Create a User Directory

  • Create a Domain Policy

  • Create a Realm

  • Create a Rule

  • Create Policies from a Domain


To Log in to SiteMinder

  1. Start your browser and enter the URL for the Policy Server you'll be using with Delegated Administrator. The URL should contain the hostname of the computer system on which the Policy Server is installed, and the port number that you used when you installed Web Server. The URL should take the following form:

    http: //<hostname:portname>/siteminder

    Example: http://interlaken.red.iplanet.com:85/siteminder

  2. In the Administrator login page, click Administer SiteMinder.

  3. In the SiteMinder Administration window, enter the following:

    User Name. Enter SiteMinder. This user name is the default Super User for which you entered a password during the installation.

    Password. Enter the password you defined in step of Installing the Policy Server .

  4. Follow the instructions in the next section, "To Create Agents."


To Create Agents

  1. In the SiteMinder Administration window, from the Edit menu, choose System Configuration, and then choose Create Agent. Enter the following:

    Name. Enter the name of the Agent. This is the the same as the name of the host computer system where SiteMinder is installed. The Agent name must correspond to the Agent name that you entered when you installed the Agent.

    Description. (Optional) Enter a brief description of the Agent.

    Agent Type. Select SiteMinder.

    IP Address or Host Name. Enter the IP address or name of the computer system where SiteMinder is installed.

    Shared Secret. Enter an alphanumeric Shared Secret.

    Confirm Shared Secret. Enter the Shared Secret again to confirm it.

    Shared Secret Assigned to. Enter the name of the Agent used when the Agent was installed on the Web server.

  2. Click Apply to save the changes, or click OK to save the changes and return to the SiteMinder Administration window. Then follow the instructions in the in the next section, "To Create a User Directory."


To Create a User Directory.

  1. In the SiteMinder Administration window, from the Edit Menu, choose System Configuration, and then choose Create User Directory. In the SiteMinder User Directory dialog box enter the following:

    Name. Enter the name of the user directory. Example: ldap

  2. Click Directory Setup , and enter the following:

    Server. Enter the IP address for computer system where the user directory is installed. Example: 192.18.122.91

    LDAP Search:

    In Root: Enter the Delegated Administrator root DN. Example: o=ISP

    LDAP User DN Lookup

    In Start: Enter "uid="

    In End: Enter ",ou=People,o=Siroe,o=isp

  3. Click Apply to save the changes, or click OK to save the changes and return to the SiteMinder Administration window. Then follow the instructions in the next section, "To Create a Policy Domain."


To Create a Policy Domain

  1. In the SiteMinder Administration window, from the Edit menu, choose System Configuration, and then choose Create Policy Domain. In the SiteMinder Policy Domain window, enter the following:

    Name. Enter a name for the policy domain. Example: nda and servlet.

    Description. Enter a brief description of the policy domain.

  2. Click User Directory.

  3. From the drop-down list at the bottom of the tab, select a user directory you want to include in the policy domain, and then click the Add button.

    SiteMinder adds the directory you've specified to the list displayed in the User Directory tab. User directories that serve as the authentication directores in a directory mapping are displayed as well.

  4. Click Apply to save the changes.

  5. Follow the instructions in the next section, "To Create a Realm."


To Create a Realm

  1. In the Siteminder Administration window, click the Policies Domain icon

  2. In the Policies Domain window, click the Realms tab, and then click Create.

  3. In the Realms window, enter the following:

    Name. Enter a name for the policy domain. Example: nda.

    Description. Enter a brief description of the policy domain.

  4. Click Resource, and enter the following:

    Agent. Displays the agent name. Example: winnie

    Resource. Enter a resource name. Example /nda/

    • Make sure authentication scheme shows "Basic"

    • Make sure Default Resource Protection sellected "Protected" .

  5. Click OK to save the data.

  6. Repeat steps 1 through 4 to create another realm for the servlet, then follow the instructions in the next section, "To Create a Rule."


To Create a Rule

  1. In the Siteminder Administration window, click the Domain tab.

  2. Click Policy Domain, and then click the plus symbol (+) to expand the list of policy domains which you want to add a rule.

  3. Right click the realm/nested realm to which you want to add a rule. From the pop-up menu, select Create Rule under Realm and the SiteMinder dialog box opens

  4. In the SiteMinder Rule window, enter the following:

    Name. Enter the name of the new rule. Example: nda rule.

    Description. (Optional) Enter a brief description of the new rule.

    Realm and Resources. From the drop-down list, select the name of the realm that includes the resources to which this rule will apply. Example: nda.

  5. By default, the Realm drop-down list is set to the name of the realm you selected when you opened the SiteMinder Realm dialog box.

    • Make sure Resource: shows "*" .

    • Make sure that under Allow/Deny and Enable/Disable, the Allow Access option is selected.

    • Make sure that under Enable or Disable this rule, the Enabled option is selected.

  6. In theAction group box, select Web Agent Actions.

  7. Select all Get Put Post.

  8. Click Apply to save the rule, or click OK to save the rule and return to the SiteMinder Administration window .

  9. Repeat steps 1 through 7 to create a rule for servlet rule, and then follow the instructions in the next section, "To Create Policies from Domains."


To Create Policies from Domains

  1. In the SiteMinder Administration window, click Domain.

  2. Click Policie Domains, and then click the name of the policy you created.

  3. In the Policy Properties window, enter the following:

    Name. Enter the name of the policy. Example: nda and servlet.

    Description. Enter a brief description of the Agent.

  4. Click Users.

  5. Use ldapmodify to add the proxy account entry .

    dn: uid=proxy, ou=people, o=iplanet.com

  6. In the Policy User/Groups, from Available member side, select the user and group you want to move to current members areas. If you do not see the users you want to move, select Search Sign-on.

    1. In the Search Sign-on window, select Attribute-Value Pair, and enter the following:

      Attribute. Add "uid"

      Value. Add "*"

    2. Click OK.

  7. A list of users is generated. Use the arrows to move all Delegated Administrator users.

  8. Click Rules.

  9. Select Add/Remove Rules, and then select Rules from Available Member. Use the arrows to move to the current member. Move each policy you've created.

  10. Click Apply

  11. Click OK to save the data.


Configuring the Directory Server

The proxy user account will be used to bind to the Directory for proxied authentication. This user account must be created in a base suffix other than the Delegated Administrator base suffix. The following is an an example of a proxy user account entry:

dn: uid=proxy, ou=people,o=Siroe, o=iplanet.com
objectclass: top
objectclass: person
objectclass: organizationalperson
objectclass: inetorgperson
objectclass: proxy
uid: proxy
givenname: Proxy
sn: Auth
cn: Proxy Auth


To create a proxy account

  1. Go to the <Directory_server_root>/shared/bin directory where Directory server is installed. Examples:

    Unix. cd /usr/netscape/server4/shared/bin

    Windows NT. cd \netscape\server4\shared\bin

  2. Use ldapmodify to add the proxy account entry. For example:


    dn: uid=proxy, ou=people,o=Siroe, o=iplanet.com
    objectclass: top
    objectclass: person
    objectclass: organizationalPerson
    objectclass: inetOrgPerson
    uid: proxy
    givenname: Proxy
    sn: Auth
    userpassword: proxypassword
    cn: Proxy Auth


    Ctrl-D (UNIX)
    Ctrl-Z (NT)


To Create an ACI for proxied authorization

  1. Go to the <Directory_server_root>/shared/bin directory where the Directory Server 4.1 is installed Examples:

    Unix. cd /usr/netscape/server4/shared/bin

    Windows NT. cd \netscape\server4\shared\bin

  2. Use ldapmodify to add an ACI to the base entry. For example:

    ldapmodify -h <host_name> -p <port_number> -D "cn=directory manager" -w password

    dn: o=ISP
    changetype: modify
    add: aci
    aci: (target="ldap:///o=ISP")(targetattr="*")(version 3.0; acl
    "proxy";allow (proxy) userdn="ldap:///uid=proxy, ou=people,o=iplanet.com";)

    Ctrl-D (UNIX)
    Ctrl-Z (NT)


Configuring Delegated Administrator

Once the proxy user account has been created in the Directory, you must configure Delegated Administrator for proxied authentication. Use the instructions in this section to add the proxy user DN and password to the resources.properties file.


To Configure Delegated Administrator for Proxied Authentication

In the file <DelegatedAdmin_root>/nda/classes/netscape/nda/servlet/resources.properties, remove the comment character (#) from the following entries, and modify appropriately:

#LDAPDatabaseInterface-ldapauthdn=<Proxy Authentication DN>

#LDAPDatabaseInterface-ldapauthpw=<Proxy Authentication Password>

Examples:

LDAPDatabaseInterface-ldapauthdn=uid=proxy,o=people, o=iplanet.com

LDAPDatabaseInterface-ldapauthpw=proxypassword


Restarting the Web Server

For the changes to take effect, restart the Web Server.


Previous     Contents     Index     Next     
Copyright © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.

Last Updated May 24, 2001