Chapter 3 Configuring Access Manager With an Existing Directory Server

This chapter describes how to install and configure Sun Java™ System Access Manager 6 2005Q1 with an existing Directory Server that is already provisioned with user data, including:

Directory Server Considerations

Administrator Privileges to Directory Server

To install, upgrade, or configure Directory Server or to migrate your existing Directory Server data, you must have the appropriate Directory Server administrator privileges.

You can make modifications by using Directory Server Console, Directory Server command-line utilities such as ldapmodify or db2ldif utilities, or the sample scripts that are included with Access Manager.

Directory Server Upgrade

If you are using an earlier version of Directory Server (before the 2005Q1 release), consider upgrading to Directory Server 5 2005Q1 and then migrating your existing data to the upgraded directory. For information about upgrading Directory Server, see the Sun Java Enterprise System 2005Q1 Upgrade and Migration Guide (http://docs.sun.com/doc/819-0062).

Directory Server Backup

Before you make changes to your existing Directory Server data, back up your data using a utility such as db2ldif or db2bak or the Directory Server Console. For information about backing up your directory, refer to the Directory Server Administration Guide in the Directory Server Online Documentation.

Directory Server Utilities

Make sure that you’re using the correct version of Directory Server utilities such as ldapmodify and ldapsearch. To determine which utilities you are using, use the which command.

Do not use the Directory Server utilities included with either the Solaris or Linux operating system, which are in the /bin or /usr/bin directory. These directories might not contain the most recent version of these utilities.

Utilities included with Access Manager:

Utilities included with Directory Server:

Directory Server Libraries

To access the Directory Server libraries that are included with either Directory Server or Access Manager, set the LD_LIBRARY_PATH environment variable accordingly. For example, on Solaris systems, add AccessManager-base/SUNWam/ldaplib/ldapsdk and /usr/lib/mps/secv1 to your LD_LIBRARY_PATH to access the libraries included with Access Manager.

Directory Server Online Documentation

Installing Access Manager

Access Manager installation involves Running the Java ES Installer to install the first instance or Access Manager and Running the amconfig Script to deploy additional instances or to configure the first Access Manager instance if you specified the “Configure Later” option during installation.

Running the Java ES Installer

To install the first instance of Access Manager 6 2005Q1, run the Sun Java Enterprise System (Java ES) 2005Q1 installer. When you run the installer, you can also install other Java ES component products such as Application Server or Web Server.

For information about the Java ES installer, refer to the Sun Java Enterprise System Installation Guide (http://docs.sun.com/doc/819-0056).

During installation, if you the specify the “Configure Now” option, the “Access Manager: Directory Server Information (6 of 6)” panel asks the question: “Is Directory Server provisioned with user data?”. Choose “Yes” and then specify values for the object classes and naming attributes shown in Table 3-1 with the values that your are currently using in your Directory Server.

If you the specify the “Configure Now” option, the Java ES installer also displays a popup dialog box that asks:

The Directory Server does not have the Access Manager 6.3 directory information tree (DIT). Do you want the installer to load the DIT into your Directory Server?

Table 3-1 Object Classes and Naming Attributes For a Provisioned Directory
Item	Description
Organization Marker Object Class	Object class defined for the organization in the existing provisioned directory. Default value is sunISManagedOrganization.
Organization Naming Attribute	Naming attribute used to define organizations in the existing provisioned directory. Default value is o.
User Marker Object Class	Object class defined for users in the existing provisioned directory. Default value is inetorgperson.
User Naming Attribute	Naming attribute used for users in the existing provisioned directory. Default value is uid.

If you click Yes, the installer loads the Access Manager LDIF files, including install.ldif, installExisting.ldif, ds_remote_schema.ldif, ds_remote_schema_uninstall.ldif, sunAMClient_data.ldif, sunAMClient_schema.ldif, and sunone_schema2.ldif.

Running the amconfig Script

Run the amconfig script to deploy additional instances of Access Manager on other host servers or to configure the first instance if you specified the “Configure Later” option during installation.

First, copy the amsamplesilent and then set the variables in the new file to configure the new instance you want to deploy or configure. The amconfig script reads the configuration script input file and then calls other scripts as needed to create or configure the Access Manager instance.

If you are using an existing Directory Server, set the DIRECTORY_MODE in the configuration script input file as shown in Table 3-2.

Table 3-2 DIRECTORY_MODE Values for an Existing Directory Server
Value	Description
DIRECTORY_MODE=2	Use for an existing Directory Server DIT. The naming attributes and object classes are the same, so the configuration scripts load the installExisting.ldif and umsExisting.xml files. The configuration scripts also update the LDIF and properties files with the actual values entered during configuration (for example, BASE_DIR, SERVER_HOST, and ROOT_SUFFIX). This update is also referred to as “tag swapping,” because the configuration scripts replace the placeholder tags in the files with the actual configuration values.
DIRECTORY_MODE=3	Use for an existing Directory Server DIT when you want to do a manual load. The object classes and naming attributes are different, so the configuration scripts do not load the installExisting.ldif and umsExisting.xml files. The scripts perform tag swapping (described for mode 2). You should inspect and modify (if needed) the LDIF files and then manually load the LDIF files and services. For more information, see Configuring the Directory Server Schema Files.
DIRECTORY_MODE=4	Use for an existing multi-server installation. The configuration scripts do not load the LDIF files and services, because the operation is against an existing Access Manager installation. The scripts perform tag swapping only (described for mode 2) and add a server entry in the platform list.

Table 3-3 describes other variables that you need to set in the configuration script input file for an existing Directory Server.

Table 3-3 Configuration Script Input File Variables for an Existing Directory Server
Variable	Description
USER_NAMING_ATTR	Naming attribute used for users in the existing provisioned directory. Default value is uid.
ORG_NAMING_ATTR	Naming attribute used to define organizations in the existing provisioned directory. Default value is o.
ORG_OBJECT_CLASS	Object class defined for the organization in the existing provisioned directory. Default value is sunISManagedOrganization.
USER_OBJECT_CLASS	Object class defined for users in the existing provisioned directory. Default value is inetorgperson.

Set other variables in the configuration script input file as required for the instance you want to configure or create. For a description of the amconfig script and the variables in the amsamplesilent file, refer to the Sun Java System Access Manager Administration Guide (http://docs.sun.com/doc/817-7647).

NEW_INSTANCE specifies whether the configuration script should deploy Access Manager to a new user-created web container instance. Set to true to update the platform server list and DNS alias.

AM_ENC_PWD specifies the password encryption key.

Configuring the Directory Server Schema Files

In this scenario, you ran the amconfig script with DIRECTORY_MODE = 3 or 4, or you specified “No” when the Java ES installer asked this question:

The Directory Server does not have the Access Manager 6.3 directory information tree (DIT). Do you want the installer to load the DIT into your Directory Server?

Follow these steps, in order, to configure the Directory Server schema on Solaris systems:

Load the LDIF files for the Access Manager specific schema changes. For example:

# ldapmodify -h ds-host -p port -D"cn=directory manager" -w passwd -c -a -f /etc/opt/SUNWam/config/ldif/sunone_schema2.ldif
# ldapmodify -h ds-host -p port -D"cn=directory manager" -w passwd -c -a -f /etc/opt/SUNWam/config/ldif/ds_remote_schema.ldif

Load the LDIF files for the client data and its schema. For example:

# ldapmodify -h ds-host -p port -D"cn=directory manager" -w passwd -c -a -f /etc/opt/SUNWam/config/ldif/sunAMClient_schema.ldif
# ldapmodify -h ds-host -p port -D"cn=directory manager" -w passwd -c -a -f /etc/opt/SUNWam/config/ldif/sunAMClient_data.ldif

Load the LDIF file for the Access Manager specific entries. For example:

# ldapmodify -h ds-host -p port -D"cn=directory manager" -w passwd -c -a -f /etc/opt/SUNWam/config/ldif/installExisting.ldif

Add the Directory Server indexes and enable the plug-in:

# ldapmodify -h ds-host -p port -D"cn=directory manager" -w passwd -c -a -f /etc/opt/SUNWam/config/ldif/index.ldif
# ldapmodify -h ds-host -p port -D"cn=directory manager" -w passwd -c -a -f /etc/opt/SUNWam/config/ldif/plugin.ldif

For more information, see Configuring Directory Server.

Optionally, add any schema customizations that you might want for your deployment.

Load the Access Manager services using the amserveradmin script:

Change to the directory where the script is located. For example, on Solaris systems:
cd /etc/opt/SUNWam/config/ums

Open the umsExisting.xml file and verify that it has the correct naming attribute.

Edit the amserveradmin script and replace ums.xml with umsExisting.xml.

Run the amserveradmin script. For example:
# cd /etc/opt/SUNWam/config/ums/
# ./amserveradmin "cn=amadmin,ou=people,dc=example,dc=com" "passwd_amadmin"

If there are no errors in the Step a through Step d, restart the container and authentication helpers. You should be now able to login to the admin console.

Customizing After Installation

In this scenario, you specified Yes when the Java ES installer asked this question:

The Directory Server does not have the Access Manager 6.3 directory information tree (DIT). Do you want the installer to load the DIT into your Directory Server?

Then after installation, if you want to customize the Directory Server schema, follow these general steps:

Remove the DAI service.

Add your customizations to the XML files.

Re-add the DAI service.

Configuring Directory Server

After you have installed Access Manager, perform the following tasks (if they have not already been done) to configure Directory Server to work with Access Manager:

Enable the Referential Integrity Plug-In

Add Indexes for Access Manager

Enable the Referential Integrity Plug-In

When enabled, the referential integrity plug-in maintains integrity on specific attributes immediately after a Directory Server delete or modify operation. This plug-in ensures that relationships between related entries are maintained throughout the Directory Server database.

To enable the referential integrity plug-in, use the Directory Server Console or the ldapmodify command-line utility to load the plugin.ldif script, which is available in the following directory, depending on your platform:

Solaris systems: /etc/opt/SUNWam/config/ldif

Linux systems: /etc/opt/sun/identity/config/ldif

To enable the referential integrity plug-in using the Console

Make sure that Directory Server is running.

In Directory Server Console, click the Configuration tab.

In the left tree, expand the Plug-ins node.

In list of Plug-ins, click the “referential integrity postoperation” plug-in. Add the following attributes (if missing) to the arguments list of plugin (on right hand panel):

iplanet-am-modifiable-by

iplanet-am-static-group-dn

memberOf

In the properties area, check Enable plug-in.

Set the following arguments:

Argument 1 specifies the update interval in seconds. For example, 90 updates occur every 90 seconds, 3600 updates occur every hour, and so on.

The default for Argument 1 is 0, which updates immediately after every operation. However, be aware that immediate referential integrity checks after every operation can significantly impact server performance.

To determine a value that considers both data integrity and overall performance, refer to the Directory Server Performance Tuning Guide in the Directory Server Online Documentation.

Argument 2 specifies the absolute path of the referential integrity log file you plan to use.

Argument 3 is not used, but it must be present.

Click Save.

Restart Directory Server.

Add Indexes for Access Manager

Directory Server indexes improve the performance for searches of Directory Server data. Table 3-4 lists the recommended attributes that you should consider indexing for Access Manager (if they are not already indexed).

Table 3-4 Directory Server Attributes to Index for Access Manager
Attribute	Index Type
nsroledn	Equality, Presence, and Substring
memberof	Equality and Presence
iplanet-am-static-group-dn	Equality
iplanet-am-modifiable-by	Equality
iplanet-am-user-federation-info-key	Equality
sunxmlkeyvalue	Equality and Substring
o	Equality, Presence, and Substring
sunPreferredDomain	Equality, Presence, and Substring
associatedDomain	Equality, Presence, and Substring
sunOrganizationAlias	Equality, Presence, and Substring

You can add indexes using either the Directory Server Console or the ldapmodify command-line utility to load the index.ldif file, which is available in the following directory, depending on your platform:

Solaris systems: /etc/opt/SUNWam/config/ldif

Linux systems: /etc/opt/sun/identity/config/ldif

For more information about both the Console and ldapmodify, see the Sun Java System Directory Server Administration Guide in the Directory Server Online Documentation.

To add Directory Server indexes using the Console

Make sure that Directory Server is running.

In Directory Server Console, click the Configuration tab.

In the left tree, expand the Data node and select the suffix you want to index.

Click the Indexes tab in the right panel.

To add an index on an attribute that is not yet indexed, click Add Attribute. In the subsequent dialog, select one or more attributes to index, and click OK.

Check the index type for the attribute, as shown in Table 3-4.

Repeat these steps for other indexes you want to add.

Click Save.

When you are finished creating new indexes, click Close in the Indexes window.

For the new indexes to take effect, restart Directory Server.

Adding Access Manager Object Classes

Before Access Manager can recognize the data in an existing directory, you must add special object classes and attributes to entries for all organizations, groups, and users that will be managed by Access Manager. Access Manager includes the Directory Server Sample Data Migration Scripts to add these object classes to your directory.

You might consider the Access Manager object classes as markers that indicate the directory entries that you want to manage through Access Manager. These markers enable Access Manager to recognize the entries in your directory.

Approaches to Modifying Your Directory Tree

Make a few modifications in your LDIF and XML files and then start Access Manager to make sure that the modifications were done correctly before you continue with other modifications.

If you have experience modifying an LDAP directory server, consider making the required modifications to your directory tree before loading the Access Manager LDIF and XML configuration files. This approach is often prone to errors, but it is usually faster.

You can make these modifications by using Directory Server Console, or by using the ldapmodify or db2ldif utilities that are included with Directory Server. You can also use the Directory Server Sample Data Migration Scripts that are included with Access Manager.

Directory Server Sample Data Migration Scripts

Table 3-5 describes the Directory Server data migration scripts, which are available the following directory, depending on your platform:

Solaris systems: AccessManager-base/SUNWam/migration

Linux systems: AccessManager-base/sun/identity/migration

To run these sample scripts, Perl 5.x or later is required. Each script generates an LDIF file that you can inspect before making actual changes to your Directory Server directory tree.

Before you run a script, set your LD_LIBRARY_PATH appropriately, depending on your platform. For more information, see Directory Server Libraries.

Detailed steps for running each sample script are included under the description of each script. The general steps to run a script are:

In the script you plan to run, set the following variables:

$base to the base suffix of the directory tree to be managed by Access Manager. For example: "dc=MadisonParc,dc=com"

$LDAP_SEARCH to the path of your ldapsearch command. For example: "/opt/SUNWam/bin/ldapsearch".

$LDAP_MODIFY to the path of your ldapmodify command. For example: "/opt/SUNWam/bin/ldapmodify".

See Directory Server Utilities for more information.

Run the script “as is” and then inspect the generated LDIF file.

If the changes in the LDIF file are satisfactory, uncomment the ldapmodify command in the last line of the script.

Run the script a second time to make the actual changes.


Caution	These scripts make changes to your Directory Server data that cannot be automatically undone. Be sure to back up your data before running a script.

Table 3-5 Scripts for Adding Access Manager Marker Object Classes
Script	What it Does
update-o.pl	Adds the following to each organization entry: sunManagedOrganization sunISManagedOrganization sunNameSpace inetDomain inetDomainStatus See Marking Organizations.
update-people.pl	Adds iplanet-am-managed-people-container to each people container. See Marking People Containers.
update-ou.pl	Adds iplanet-am-managed-org-unit to each organizational unit. See Marking Organizational Units.
update-users.pl	Adds the following to each user entry: inetadmin iplanet-am-managed-person iplanet-am-user-service inetuser iPlanetPreferences inetOrgPerson See Marking Users.
udpate-static-groups.pl	Adds the following to each static group: iplanet-am-managed-static-group iplanet-am-managed-group See Marking Static Groups.
update-filtered-groups	Adds the following to each dynamic, or filtered, group: iplanet-am-managed-group iplanet-am-managed-filtered-group See Marking Dynamic (Filtered) Groups.
update-assignable-dynamic-groups	Adds the following to each assignable dynamic group: iplanet-am-managed-group iplanet-am-managed-assignable group See Marking Assignable Dynamic Groups.
update-groups.pl	Adds iplanet-am-managed-group-container to each organizational unit that contains groups. See Marking Group Containers.

Marking Organizations

If you used an existing organization as your default organization during installation, you do not have to make these changes. The installation program automatically adds these object classes and attributes. Continue with Marking People Containers.

If you have sub-organizations or custom organizations, make the following changes:

Add the following object classes to each organization entry:

sunManagedOrganization

sunNameSpace

inetDomain

Add the inetDomainStatus attribute to each organization entry.

In the MadisonParc example, these object classes and their attributes are added to the dc=Customers and dc=Suppliers organizations.

To run the update-o.pl script

Copy update-o.pl to the following directory:

DirectoryServer-base/shared/bin

In the script, set the following variables:

$base to the base suffix of the directory tree to be managed by Access Manager. For example: "dc=MadisonParc,dc=com"

$LDAP_SEARCH to the path of your ldapsearch command. For example: "/opt/SUNWam/bin/ldapsearch"

$LDAP_MODIFY to the path of your ldapmodify command. For example: "/usr/iplanet/servers/shared/bin/ldapmodify"

In the directory where the script is located, enter the following command:

perl update-o.pl

When prompted, provide the following information:

Enter Host Name: Enter the name of the computer system in which your Directory Server is installed.

Enter Bind User Name: Enter a user name that has sufficient privileges for accessing the entire directory. Example: cn=Directory Manager

Enter Bind password: Enter the password for the user you specified above.

Enter port number: Enter the Directory Server port number. Example: 389

Check the results in the file orgs-updated.ldif that is generated by the script, and verify that the appropriate changes are listed. The changes contained in this file will automatically be made in the directory in the next step.

Important Note: If there are organizations that you do not want to be managed by Access Manager, you should delete those entries from this orgs-updated.ldif now. Then, instead of going on to the next step, manually load the file using the following command:

ldapmodify -h hostname -p port -D bind_user -w password -a -c -f
orgs-updated.ldif

In the script update-o.pl, uncomment the last line and replace variables appropriately. For example, to add marker object classes to MadisonParc directory entries, the last line of the script is changed from this:

#system("$LDAP_MODIFY -h'$host' -p'$port' -D'$bind_user'
-w'$bind_pwd' -a -c -f orgs-updated.ldif");

to this:

system("$LDAP_MODIFY -h'ginac.MadisonParc.com' -p'389'
-D'cn=Directory Manager' -w'password' -a -c -f
orgs-updated.ldif");

where password is the Directory Manager password.

In Code Example 2-1, the modifications to the MadisonParc directory entries are indicated in bold:

Marking People Containers

People containers are typically assigned the ou attribute and are used to store all user entries for a branch of the directory. To each people container, add the iplanet-am-managed-people-container object class.

To run the update-people.pl script

Copy update-people.pl to the following directory:

DirectoryServer-base/shared/bin

Make sure that the $base variable is set to the base suffix of the directory tree to be managed by Access Manager. For example: dc=MadisonParc,dc=com

Also, make sure that the LDAP_SEARCH and LDAP_MODIFY variables are set correctly. For more information see Directory Server Utilities.

In the MadisonParc example, the script was also modified to include people containers located under the organizations. In Code Example 2-14, bold indicates the change in the search scope.

Code Example 3-2 Scope in update-people-container.pl is Modified


# run search to find all people containers, putting their DNs in to a file
system("$LDAP_SEARCH -h \"$host\" -p \"$port\" -D \"$bind_user\"
-w \"$bind_pwd\" -b \"$base\" -s sub -T \"(&(ou=$people)
*(!(objectclass=iplanet-am-)))\"** dn > people.dn");

In the directory where the script is located, at the command line enter the following:

perl update-people.pl

When prompted, provide the following information:

Enter Host Name: Enter the name of the computer system in which your Directory Server is installed.

Enter Bind User Name: Enter a user name that has sufficient privileges for accessing the entire directory. Example: cn=Directory Manager

Enter Bind password: Enter the password for the user you specified above.

Enter port number: Enter the Directory Server port number. For example: 389

Enter People Container: Enter the name of the people container that contains the uids you want to modify. For example: People

Check the results in the file people-updated.ldif which is created in the same directory as the script, and verify that the appropriate changes were made. The changes contained in this file will automatically be made in the directory in the next step.

Important Note: If there are people containers that you do not want to be managed by Access Manager, you should delete those entries from people-updated.ldif now. Then, instead of going on the to next step, manually load the file using the following command:

ldapmodify -h hostname -p port -D bind_user -w password -a -c -f
people-updated.ldif

In the script update-people.pl, uncomment the last line and replace variables appropriately. In the MadisonParc example, the last line of the script is changed from this:

#system("$LDAP_MODIFY -h'$host' -p'$port' -D'$bind_user'
-w'$bind_pwd' -a -c -f people-updated.ldif");

to this:

system("$LDAP_MODIFY -h'ginac.MadisonParc.com' -p'389'
-D'cn=Directory Manager' -w'password' -a -c -f
people-updated.ldif");

In Code Example 2-15, marker object class for the people container under dc=Customers is indicated in bold.

Code Example 3-3 People container entry with marker object class.

...
dn: ou=People,dc=Customers,dc=MadisonParc,dc=com
ou: People
objectClass: top
objectClass: organizationalunit
objectClass: iplanet-am-managed-people-container

Marking Organizational Units

Organizational units are typically assigned the ou attribute. To each container that is an organizational unit, add the following object class:

To run the update-ou.pl script

Copy update-ou.pl to the following directory:

DirectoryServer-base/shared/bin

Make sure that the $base variable is set to the base suffix of the directory tree to be managed by Access Manager. For example: dc=MadisonParc,dc=com

Also, make sure that the LDAP_SEARCH and LDAP_MODIFY variables are set correctly. For more information see Directory Server Utilities.

In the directory where the script is located, at the command line enter the following:

perl update-ou.pl

When prompted, provide the following information:

Enter Host Name: Enter the name of the computer system in which your Directory Server is installed.

Enter Bind User Name: Enter a user name that has sufficient privileges for accessing the entire directory. For example: cn=Directory Manager

Enter Bind password: Enter the password for the user you specified above.

Enter port number: Enter the Directory Server port number. For example: 389

Check the results in the file orgunit-updated.ldif which is created in the same directory as the script, and verify that the appropriate changes are listed. The changes contained in this file will automatically be made in the directory in the next step.

Important Note: If there are organizational units that you do not want to be managed by Access Manager, you should delete those entries from this ou-updated.ldif now. Then, instead of going on the to next step, manually load the file using the following command:

ldapmodify -h hostname -p port -D bind_user -w password -a -c -f
orgunit-updated.ldif

In the script update-ou.pl, uncomment the last line and replace variables appropriately. In the MadisonParc example, the last line of the script is changed from this:

#system("$LDAP_MODIFY -h'$host' -p'$port' -D'$bind_user'
-w'$bind_pwd' -a -c -f orgunit-updated.ldif");

to this:

system("$LDAP_MODIFY -h'ginac.MadisonParc.com' -p'389'
-D'cn=Directory Manager' -w'password' -a -c -f
orgunit-updated.ldif");

In Code Example 2-16, marker object class for the organizational units under dc=MadisonParc,dc=com is indicated in bold.

Marking Users

iplanet-am-managed-person

iplanet-am-user-service

inetuser

iPlanetPreferences

inetOrgPerson

inetadmin

To run the update-users.pl script

Copy update-users.pl to the following directory:

DirectoryServer-base/shared/bin

Make sure that the $base variable is set to the base suffix of the directory tree to be managed by Access Manager. For example: dc=MadisonParc,dc=com

Also, make sure that the LDAP_SEARCH and LDAP_MODIFY variables are set correctly. For more information see Directory Server Utilities.

In the directory where the script is located, at the command line enter the following:

perl udpate-users.pl

Check the results in the file users-updated.ldif which is created in the same directory as the script, and verify that the appropriate changes were made. The changes contained in this file will automatically be made in the directory in the next step.

Important Note: If there are users that you do not want to be managed by Access Manager, you should delete those entries from users-updated.ldif now. Then, instead of going on the to next step, manually load the file using the following command:

ldapmodify -h hostname -p port -D bind_user -w password -a -c -f
users-updated.ldif

In the script update-users.pl, uncomment the last line and replace variables appropriately. In the MadisonParc example, the last line of the script is changed from this:

#system("$LDAP_MODIFY -h'$host' -p'$port' -D'$bind_user'
-w'$bind_pwd' -a -c -f users-updated.ldif");

to this:

system("$LDAP_MODIFY -h'ginac.MadisonParc.com' -p'389'
-D'cn=Directory Manager' -w'password' -a -c -f
users-updated.ldif");

Code Example 3-5 User Entry With User Marker Object Class

dn: uid=scarter, ou=People, dc=MadisonParc,dc=com

nsUniqueId: d8855082-1dd111b2-8024a6c9-802bec30

givenName: Sam

telephoneNumber: +1 408 555 4798

sn: Carter

ou: Accounting

ou: People

l: Sunnyvale

roomNumber: 4612

mail: scarter@MadisonParc.com

facsimileTelephoneNumber: +1 408 555 9751

objectClass: top

objectClass: person

objectClass: organizationalPerson

objectClass: inetOrgPerson

objectClass: inetuser

objectClass: inetadmin

objectClass: iplanet-am-managed-person

objectClass: iplanetPreferences

objectClass: iplanet-am-user-service

uid: scarter

cn: Sam Carter

userPassword: {SSHA}3XwjhBgbt6ae5syCndDeANoossEGRJ1NdnLyZw==

employeeType: Manager

departmentNumber: 1000

businessCategory: East

inetUserStatus: Active

Marking Static Groups

Static groups formed by adding uids to the group entry. To each group entry containing values for the uniquemember attribute, add the following object classes:

iplanet-am-managed-static-group

iplanet-am-managed-group

To run the update-static-groups.pl script

Copy update-static-groups.pl to the following directory:

DirectoryServer-base/shared/bin

Make sure that the $base variable is set to the base suffix of the directory tree to be managed by Access Manager. For example: dc=MadisonParc,dc=com

Also, make sure that the LDAP_SEARCH and LDAP_MODIFY variables are set correctly. For more information see Directory Server Utilities.

In the directory where the script is located, at the command line enter the following:

perl update-static-groups.pl

When prompted, provide the following information:

Enter Host Name: Enter the name of the computer system in which your Directory Server is installed.

Enter Bind User Name: Enter a user name that has sufficient privileges for accessing the entire directory. For example: cn=Directory Manager

Enter Bind password: Enter the password for the user you specified above.

Enter port number: Enter the Directory Server port number. For example: 389

Check the results in the file static-groups-updated.ldif which is created in the same directory as the script, and verify that the appropriate changes are listed. The changes contained in this file will automatically be made in the directory in the next step.

Important Note: If there are static groups that you do not want to be managed by Access Manager, you should delete those entries from static-groups-updated.ldif now. Then, instead of going on the to next step, manually load the file using the following command:

ldapmodify -h hostname -p port -D bind_user -w password -a -c -f
static-groups-updated.ldif

In the script update-static-groups.pl, uncomment the last line, and replace variables appropriately. For example, in the MadisonParc example, the last line of the script is changed from this:

#system("$LDAP_MODIFY -h'$host' -p'$port' -D'$bind_user'
-w'$bind_pwd' -a -c -f static-groups-updated.ldif");

to this:

system("$LDAP_MODIFY -h'ginac.MadisonParc.com' -p'389'
-D'cn=Directory Manager' -w'password' -a -c -f
static-groups-updated.ldif");

In Code Example 2-18, marker object class for static groups is indicated in bold.

Marking Dynamic (Filtered) Groups

Dynamic or filtered groups are formed by building a search construct to find all user entries containing a specific attribute. These groups contain the memberURL attribute. To each group containing the attribute memberURL, add the following object classes:

iplanet-am-managed-group

iplanet-am-managed-filtered-group

To run the update-filtered-groups.pl script

Copy update-filtered-groups.pl to the following directory:

DirectoryServer-base/shared/bin

Make sure that the $base variable is set to the base suffix of the directory tree to be managed by Access Manager. For example: dc=MadisonParc,dc=com

Also, make sure that the LDAP_SEARCH and LDAP_MODIFY variables are set correctly. For more information see Directory Server Utilities.

In the directory where the script is located, at the command line enter the following:

perl update-filtered-groups.pl

When prompted, provide the following information:

Enter Host Name: Enter the name of the computer system in which your Directory Server is installed.

Enter Bind User Name: Enter a user name that has sufficient privileges for accessing the entire directory. For example: cn=Directory Manager

Enter Bind password: Enter the password for the user you specified above.

Enter port number: Enter the Directory Server port number. For example: 389

Check the results in the file filtered-groups-updated.ldif which is created in the same directory as the script, and verify that the appropriate changes were made. The changes contained in this file will automatically be made in the directory in the next step.

Important Note: If there are filtered or dynamic groups that you do not want to be managed by Access Manager, you should delete those entries from filtered-groups-updated.ldif now. Then, instead of going on the to next step, manually load the file using the following command:

ldapmodify -h hostname -p port -D bind_user -w password -a -c -f
filtered-groups-updated.ldif

In the script update-filtered-groups.pl, uncomment the last line in the update-o.pl file, and replace variables appropriately. In the MadisonParc example, the last line of the script is changed from this:

#system("$LDAP_MODIFY -h'$host' -p'$port' -D'$bind_user'
-w'$bind_pwd' -a -c -f filtered-groups-updated.ldif");

to this:

system("$LDAP_MODIFY -h'ginac.MadisonParc.com' -p'389'
-D'cn=Directory Manager' -w'password' -a -c -f
filtered-groups-updated.ldif");

In Code Example 2-19, marker object class for a filtered group is indicated in bold.

Marking Assignable Dynamic Groups

The assignable dynamic group is an Access Manager concept. In Access Manager, users in this type of group are typically allowed limited self-registration and account management privileges. In the MadisonParc example, users at the top level have administrators to create and manage their entries to comply with corporate specifications. Users under the Customers or Suppliers organizations are placed in assignable dynamic groups. The users can acquire membership by themselves when they log into the MadisonParc portal. Their membership entitles them to limited access to the MadisonParc portal; the information they provide at registration is minimal.

Add the following object classes to each dynamic group that you want to use as an assignable dynamic group in Access Manager:

iplanet-am-managed-group

iplanet-am-managed-assignable-group

To run the update-assignable-dynamic-groups.pl script

Copy update-assignable-dynamic-groups.pl to the following directory:

DirectoryServer-base/shared/bin

Make sure that the $base variable is set to the base suffix of the directory tree to be managed by Access Manager. For example: dc=MadisonParc,dc=com

Also, make sure that the LDAP_SEARCH and LDAP_MODIFY variables are set correctly. For more information see Directory Server Utilities.

In the directory where the script is located, at the command line enter the following:

perl update-assignable-dynamic-groups.pl

When prompted, provide the following information:

Enter Host Name: Enter the name of the computer system on which your Directory Server is installed.

Enter Bind User Name: Enter a user name that has sufficient privileges for accessing the entire directory. For example: cn=Directory Manager

Enter Bind password: Enter the password for the user you specified above.

Enter port number: Enter the Directory Server port number. For example: 389

Check the results in the file assignable-dynamic-groups-updated.ldif which is created in the same directory as the script, and verify that the appropriate changes were made. The changes contained in this file will automatically be made in the directory in the next step.

Important Note: If there are assignable dynamic groups that you do not want to be managed by Access Manager, you should delete those entries from this assignable-dynamic-groups-updated.ldif now. Then, instead of going on the to next step, manually load the file using the following command:

ldapmodify -h hostname -p port -D bind_user -w password -a -c -f
assignable-dynamic-groups-updated.ldif

In the script update-assignable-dynamic-groups.pl, uncomment the last line in the update-assignable-dynamic-groups.pl file, and replace variables appropriately. In the MadisonParc example, the last line of the script is changed from this:

#system("$LDAP_MODIFY -h'$host' -p'$port' -D'$bind_user'
-w'$bind_pwd' -a -c -f
assignable-dynamic-groups-updated.ldif");

to this:

system("$LDAP_MODIFY -h'ginac.MadisonParc.com' -p'389'
-D'cn=Directory Manager' -w'password' -a -c -f
assignable-dynamic-groups-updated.ldif");

Marking Group Containers

Group containers are organizational units (ou) that contain groups. To each group container that includes the ou:Groups attribute, add the following object class:

To run the update-groups.pl script

Copy update-groups.pl to the following directory:

DirectoryServer-base/shared/bin

Make sure that the $base variable is set to the base suffix of the directory tree to be managed by Access Manager. For example: dc=MadisonParc,dc=com

Also, make sure that the LDAP_SEARCH and LDAP_MODIFY variables are set correctly. For more information see Directory Server Utilities.

In the MadisonParc example, the script was also modified to include all group containers located under organizations. In Code Example 2-20, the script changes are indicated in bold.

Code Example 3-8 Scope in update-groups.pl is Modified.


# run search to find all group containers, putting their DNs in to a file
system("$LDAP_SEARCH -h \"$host\" -p \"$port\" -D \"$bind_user\"
-w \"$bind_pwd\" -b \"$base\" -T \"(&(ou=groups)
*(!(objectclass=iplanet-am-))(objectclass=organizationalunit))\**
" dn > group-container-updated.dn");

In the directory where the script is located, at the command line enter the following command:

perl update-groups.pl

When prompted, provide the following information:

Enter Host Name: Enter the name of the computer system in which your Directory Server is installed.

Enter Bind User Name: Enter a user name that has sufficient privileges for accessing the entire directory. For example: cn=Directory Manager

Enter Bind password: Enter the password for the user you specified above.

Enter port number: Enter the Directory Server port number. For example: 389

Check the results in the file groups-updated.ldif which is created in the same directory as the script, and verify that the appropriate changes were made. The changes contained in this file will automatically be made in the directory in the next step.

Important Note: If there are group containers that you do not want to be managed by Access Manager, you should delete those entries from this groups-updated.ldif now. Then, instead of going on the to next step, manually load the file using the following command:

ldapmodify -h hostname -p port -D bind_user -w password -a -c -f
groups-updated.ldif

In the script update-groups.pl, uncomment the last line, and replace variables appropriately. In the MadisonParc example, the last line of the script is changed from this:

#system("$LDAP_MODIFY -h'$host' -p'$port' -D'$bind_user'
-w'$bind_pwd' -a -c -f groups-updated.ldif");

to this:

system("$LDAP_MODIFY -h'ginac.MadisonParc.com' -p'389'
-D'cn=Directory Manager' -w'password' -a -c -f
groups-updated.ldif");

In Code Example 2-21, marker object class for a group under dc=Customers is indicated in bold.

Adding Custom Object Classes

If your existing directory tree contains custom object classes and attributes that are not included with Directory Server, you must add them to the Access Manager schema, as follows:

Modifying the Creation Templates

Adding Attributes to the Organization Schema

Adding Attributes to the User Schema

MadisonParc Examples

The examples in this section use a fictitious company named MadisonParc to show modifications you can make to your Directory Server and Access Manager.

The MadisonParc directory information tree (DIT) includes three organizational units (ou) at the top level of the tree: Groups, People, and Special Users. These organizational units contain entries for the MadisonParc employees. Two organizations (dc), Customers and Suppliers, which were created under the root level, contain entries for non-employees.

The MadisonParc example has two custom object classes: madisonparc-org and company, and three custom attributes: madisonparc-org-description, acctNumber, and companyName.These object classes and attributes are not included in the Access Manager or Directory Server schema.

These object classes and attributes distinguish MadisonParc employees at the top level of the directory tree from non-employees in the Customers and Suppliers organizations.

Table 3-6 describes the user-defined objects and attributes the MadisonParc directory information tree (DIT).

Before a MadisonParc administrator can use Access Manager to manage these custom objects, the following modifications must be made to the Access Manager schema:

Table 3-6 User-Defined Objects Used in the MadisonParc DIT
Object	Description
madisonparc-org	Object class added to all organization entries.
madisonparc-org-description	Attribute added to each organization entry; required by madisonparc-org.
company	Object class added to all user entries.
acctNumber	Attribute added to each user entry; required by the company object class.
companyName	Attribute added to each user entry; required by the company object class.

Add the two custom object classes and three custom attributes to the umsExisting.xml file.

Add madisonparc-org to the amEntrySpecific.xml file.

Add madisonparc-org-description to the amEntrySpecific.properties file.

Add companyName and acctNumber to the amUser.xml and amUser.properties files.

If your existing directory tree contains custom object classes or attributes, you can make similar changes in your directory and in your Access Manager XML files.

For more information about the Access Manager schema and customizing Access Manager, see the Sun Java System Access Manager Developer's Guide.

Modifying the Creation Templates

The creation templates configure Access Manager to add or allow specific object classes and attributes when these entries are created. To expose custom object classes in the Access Manager console, you must modify the creation templates for both users and organizations in the umsExisting.xml file.

In the MadisonParc example, the existing directory tree has new object classes for both users and organizations.

Directory Access Instructions (DAI) Service

When you install Access Manager, the ums.xml file is stored in Directory Server as the Directory Access Instructions (DAI) service. Access Manager does not allow you to load the umsExisting.xml file if the DAI service is already installed in Directory Server. Always remove the DAI service before modifying the umsExisting.xml file. Then after you have finished modifying the files, reload the DAI service into Directory Server.

To Modify the Creation Templates

If you loaded the Access Manager schema during installation or if you have already run the amserveradmin command for any reason, skip to Step 2.

Otherwise, remove the DAI service. For example on Solaris systems:

# cd opt/SUNWam/bin
# ./amadmin -u "user_naming_attibute=amadmin,ou=people,root_suffix"
-w password -r DAI

Locate the umsExisting.xml file. For example, on Solaris systems, the file is:

/etc/opt/SUNWam/config/ums/umsExisting.xml

Modify any custom naming attributes. For example, the MadisonParc directory tree uses the domain attribute instead of the organization attribute.

In the umsExisting.xml file, find the following SubConfiguration:

Change <Value>objectClass=organization</Value> to <Value>objectClass=domain</Value>

In Code Example 2-22, the bold text indicates the changed value. Note that three lines down, the naming attribute dc was changed by Access Manager during installation.

Code Example 3-10 Changing the Organization Naming Attribute in the Creation Template


<SubConfiguration name="BasicOrganization" id="CreationUmsObjects">
<AttributeValuePair> <Attribute name="name" />
<Value>BasicOrganization</Value>
</AttributeValuePair>
<AttributeValuePair> <Attribute name="javaclass" />
<Value>com.iplanet.ums.Organization</Value>
</AttributeValuePair>
<AttributeValuePair> <Attribute name="required" />
<Value>objectClass=top</Value>
<Value>objectClass=domain</Value>
<Value>objectClass=sunManagedOrganization</Value>
<Value>objectClass=sunNameSpace</Value>
<Value>dc</Value>
<Value>inetdomainstatus=Active</Value>
</AttributeValuePair>
<AttributeValuePair> <Attribute name="namingattribute"/>
<Value>dc</Value>
</AttributeValuePair>
<AttributeValuePair> <Attribute name="optional" />
<Value>*</Value>
</AttributeValuePair>
</SubConfiguration>

Add custom organization object classes.

In the MadisonParc example, madisonparc-org is added to the organization creation template. Under the following SubConfiguration:

"BasicOrganiation" id="CreationUmsObjects">

under the following element:

add the following:

<Value>objectClass=madisonparc-org</Value>
<Value>madisonparc-org-description</Value>

For example:

Code Example 3-11 Changing the Organization in the Creation Template


<SubConfiguration name="BasicOrganization" id="CreationUmsObjects">
<AttributeValuePair> <Attribute name="name" />
<Value>BasicOrganization</Value>
</AttributeValuePair>
<AttributeValuePair> <Attribute name="javaclass" />
<Value>com.iplanet.ums.Organization</Value>
</AttributeValuePair>
<AttributeValuePair> <Attribute name="required" />
<Value>objectClass=top</Value>
<Value>objectClass=domain</Value>
<Value>objectClass=sunManagedOrganization</Value>
<Value>objectClass=sunNameSpace</Value>
<Value>objectClass=madisonparc-org</Value>
<Value>dc</Value>
<Value>inetdomainstatus=Active</Value>
</AttributeValuePair>
<AttributeValuePair> <Attribute name="namingattribute"/>
<Value>dc</Value>
</AttributeValuePair>
<AttributeValuePair> <Attribute name="optional" />
<Value>*</Value>
<Value>madisonparc-org-description</Value>
</AttributeValuePair>
</SubConfiguration>

Add custom user object classes.

In the MadisonParc example, company is added to the user creation template. Under the following SubConfiguration:

"BasicUser" id="CreationUmsObjects">

under the following element:

add the following:

<Value>objectClass=company</Value>

For example:

Code Example 3-12 Adding Custom User Object Classes in the Creation Template


<SubConfiguration name="CreationTemplates" >
<SubConfiguration name="BasicUser" id="CreationUmsObjects">
<AttributeValuePair> <Attribute name="name" />
<Value>BasicUser</Value>
</AttributeValuePair>
<AttributeValuePair> <Attribute name="javaclass" />
<Value>com.iplanet.ums.User</Value>
</AttributeValuePair>
<AttributeValuePair> <Attribute name="required" />
<Value>objectClass=top</Value>
<Value>objectClass=person</Value>
<Value>objectClass=organizationalPerson</Value>
<Value>objectClass=inetOrgPerson</Value>
<Value>objectClass=iPlanetPreferences</Value>
<Value>objectClass=iplanet-am-user-service</Value>
<Value>objectClass=inetuser</Value>
<Value>objectClass=inetAdmin</Value>
<Value>objectClass=iplanet-am-managed-person</Value>
<Value>objectClass=company</Value>
<Value>cn=default</Value>
<Value>sn=default</Value>
<Value>uid</Value>
<Value>inetuserstatus=Active</Value>
</AttributeValuePair>
<AttributeValuePair> <Attribute name="optional" />
<Value>*</Value>
<Value>companyname</Value>
<Value>acctname</Value>
</AttributeValuePair>
<AttributeValuePair> <Attribute name="namingattribute"/>
<Value>uid</Value>
</AttributeValuePair>
</SubConfiguration>

Reload the DAI service (ums.xml file or umsExisting.xml file). For example on Solaris systems:

# cd opt/SUNWam/bin
# ./amadmin -u "user_naming_attibute=amadmin,ou=people,root_suffix" -w password
-s /etc/opt/SUNWam/config/ums/umsExisting.xml

Adding Attributes to the Organization Schema

To add attributes to the Organization schema, you must modify the following services files:

amEntrySpecific.xml

amEntrySpecific.properties

The Access Manager Console uses the information in amEntrySpecific.xml for display purposes. Each Access Manager abstract entry may have a subschema in this XML file. In the following example, you would add the object class external to the organization subschema. If the directory tree contained customized organizational units, groups, or people containers, you would add or modify their subschemas in the same XML file.

The subschema name for an organizational unit will be OrganizationalUnit. The subschema name for a people container will be PeopleContainer.

any attribute


Note	The User subschema is not configured here in the amEntrySpecific.xml file, but in the amUser.xml file (see Adding Attributes to the User Schema.) Although any service XML file may describe an attribute that is only for a user, the amEntrySpecific.xml file can serve as a default place holder for user attributes that are not tied to a particular service.

The any attribute in the XML descriptions can have five possible values: filter, display, adminDisplay, userReadOnly, required, or optional. These values tell the Console whether the attribute should appear in the GUI. Typically, required and optional are not both displayed at the same time; they are mutually exclusive.

adminDisplay. The attribute is read/write for administrators and is not displayed for regular users.

userReadOnly. The attribute is read/write for administrators but is read only for regular users. It is displayed as a label for regular users so that it is not editable. For example, the display, adminDisplay, and userReadOnly settings are used when displaying the user profile page and can be used to customize the page.

required. The attribute is displayed in the create page and requires a value during creation of the entry. If any=required, the attribute must have a value or the Console will not allow the Create operation. In the user interface, required fields are indicated with an asterisk (*). Use an empty string (" ") to tell the Administration Console to display nothing.

optional. The attribute is displayed in the create page but does not require a value during creation of the entry. If any=optional, the attribute will appear on the Create page without an asterisk. This would indicate that you don’t have to give it a value to create the entry. In the Create User page, the User ID is a required attribute but the First Name is optional.

In the following MadisonParc example, the attribute madisonparc-org-description will be displayed on the Organization page and will be required for creation. This is indicated by the use of the required value. It will also be used on the Search page in Access Manager Console, as indicated by the use of the filter value.

type attribute

The type attribute can use a string, string list, single choice, multiple choice, or boolean value. For example, the madisonparc-org-description attribute can have only one of two descriptions: internal or external). You would make this attribute a single choice; each description would be one of the choices. The Access Manager Console would display a list containing only these cities. If multiple cities were allowed, the attribute could be a multiple choice.

To add attributes from a custom organization to the organization subschema

In the following file add the custom object class to the subschema Organization. For example, on Solaris systems:

/etc/opt/SUNWam/config/xml/amEntrySpecific.xml

In this example, the custom object class madisonparc-org-description was added to amEntrySpecific.xml.

<AttributeSchema name="madisonparc-org-description"

type="single"

syntax="string"

any=required|filter

In the same amEntrySpecific.xml file, create internationalization (i18n) keys (also called index keys or localization keys) for each attribute. All i18n Keys in an organization must be made up of unique strings. The Access Manager Administration Console will use this key to look up the display name for the attribute.

<AttributeSchema name="madisonparc-org-description"

type="single"

syntax="string"

any="required|filter"

i18nKey="o3"

In the following file on Solaris systems:

AccessManager-base/SUNWam/locale/amEntrySpecific.properties

Add the value for i18n Key you created in Step 2. This is the name that will be displayed in the graphical user interface. For example:

iplanet-am-entry-specific-service-description=Access Manager Entry Specific

g1=Member List

g2=Users Can Subscribe to this Group

dg1=Membership Filter

r1=Membership Filter

o1=Full DNS name

o2=Organization Status

o3=Organization Description

All the attributes listed in the subschema are displayed in the Administration Console when an organization is displayed. If an attribute is not listed, the Administration Console will not display the attribute.



Tip	If an attribute has no i18n Key, it will not be displayed on the administration console. If you add an attribute, and you don’t see it in the administration console, be sure to check the i18n Key and properties.

Load all XML files.

In the /bin directory, execute the following command:

./amserveradmin -u "user_naming_attibute=amadmin,ou=people,root_suffix"
-w password

If you see any parsing errors, you should go back and double-check the changes you made in the previous steps. Also examine the syntax in the amEntrySpecific.xml file, and make sure you’ve used the correct syntax. If you need to look at syntax examples, look at the other service XML files located in the following directory on Solaris systems:

Adding Attributes to the User Schema

amUser.xml

amUser.properties

The amUser.xml file is where user attributes are described, just as organization and group schema are described in the amEntrySpecific.xml (see Step 2). The file amUser.xml describes the User service for Access Manager. Note that any service may describe an attribute that is for a user only. This file is just the default placeholder for user attributes that are not tied to a particular service.

When displaying a user’s attributes, the Access Manager Administration Console gets all attributes from all services that are subschema type User, and displays them using the same values as used in the amEntrySpecific.xml file (see the any attribute and the type attribute). In the following examples, a few attributes from the madisonparc-user object class are added to the file, thus it is not necessary to create a new service. It’s only necessary to modify, or extend, the iplanetamuserservice.

Additional Notes About the amUser.xml File

The file amUser.xml contains a special attribute. The any=display attribute tells Access Manager whether to display the attribute in the user profile page. This is a misleading name since it implies access control. It is strictly used for display. If this attribute is set to no then the console will not display the attribute.

Also note that the attributes are defined under subschema User and not Dynamic. Any attribute defined under User is physically an attribute in the user entry. If you want the attribute to be a role-based or organization-based attribute, then you would define it under the Dynamic subschema. For detailed information, see the Java System Access Manager Developer's Guide.

To add attributes from a custom organization to the user subschema

In the following file, add the attributes from the custom object class to the User subschema on Solaris systems:

/etc/opt/SUNWam/config/xml/amUser.xml

For example, the following two attributes from the custom object class company were added to the file:

<AttributeSchema name="companyname"

type=single

syntax=string

any=required|display

<AttributeSchema name="acctnumber"

type=single

syntax=string

any=required|filter|display

In the same amUser.xml file, create i18n Keys (also called index keys or localization keys) for each attribute. All i18n Keys in an organization must be made up of unique strings. The Access Manager Console will use this key to look up the display name for the attribute.

<AttributeSchema name="companyname"

type=single

syntax=string

any=required|display

i18nKey=u120

<AttributeSchema name="acctnumber"

type=single

syntax=string

any=required|filter|display

i18nKey=u121

Add values for the i18n Keys you created in Step 2 to the following file on Solaris systems:

AccessManager-base/SUNWam/locale/amUser.properties

For example:


iplanet-am-user-service-description=User
iwtUser-desc=Default User Profile
u101=UserId
u102=First Name
u103=Last Name
u104=Full Name
u105=Password
u106=Email Address
u107=Employee Number
u108=Telephone Number
u109=Manager
u110=Home Address
u111=User Status
u112=Account Expiration date (mm/dd/yyyy hh:mm)
u113=User Authentication Configuration
u114=User Alias List
u115=Preferred Locale
u116=Success URL
u117=Failure URL
u118=Federation Information Key
u119=Federation Information
u120=Company Name
u121=Account Number

Examine the syntax in the amUser.xml file, and make sure you’ve used the correct syntax. If you need to look at syntax examples, look at the other service XML files located in the following directory on Solaris systems:

Loading Access Manager LDIF Files

Access Manager provides LDIF files to make modifications to your existing Directory Server in the following directory, depending on your platform:

Solaris systems: /etc/opt/SUNWam/config/ldif/

Linux systems: /etc/opt/sun/identity/config/ldif/

The install.ldif and installExisting.ldif files contain Access Manager specific entries that are loaded into Directory Server by the Java Enterprise System installer and the amconfig script. Usually, you do not need to modify these files before they are loaded.

Other files include ds_remote_schema.ldif, ds_remote_schema_uninstall.ldif, sunAMClient_data.ldif, sunAMClient_schema.ldif, and sunone_schema2.ldif.

You must load the LDIF files using the ldapmodify utility, if you did not upgrade the Directory Server schema during installation.

Before you load the install.ldif and installExisting.ldif files, first change the place-holder administrator passwords to the actual passwords you are using.

# cd /etc/opt/SUNWam/config/ldif
# ldapmodify -v -c -D "cn=Directory manager" -w password -a -f name.ldif

where password is the Directory Manager password and name.ldif is the name of the LDIF file you want to load.

MadisonParc Example

Users and marker object classes required for Access Manager are added to dc=MadisonParc,dc=com and to dc=Customers and dc=Suppliers.

Default roles for organization and help desk administrators are created at the top level.

Default Access Control Instructions (ACIs) for those administrator entries are set up.

The Access Manager administration user amAdmin is created under the ou=People,dc=MadisonParc,dc=com people container. This is the top level administrator for Access Manager. This administrator has read and write access to the entire dc=MadisonParc,dc=com root suffix. You can add one of your users to this top level administrator role after the Access Manager Console is started.

Enabling Access Manager User Management

User Management includes all the components needed to view and manage the Access Manager objects (organizations, groups, users, services, roles policies, container objects, and agents). By default, User Management is enabled after you install Access Manager. However, if disabled, you can enable User Management using the Access Manager console.

To enable User Management

If necessary, restart Access Manager for any previous changes to take effect. Both Directory Server and the web container that runs Access Manager must also be running.

In the Access Manager console, click Service Configuration and then Administration.

In the Administration pane under Global, check Enable User Management.

Click Save.

You should now be able to see your existing groups and users under Organization in the Administration pane.

Verifying the Access Manager Installation

After you’ve installed Access Manager and configured Directory Server, you can verify the installation.

To verify the Access Manager installation

If necessary, start Directory Server.

Start Access Manager and the web container that Access Manager is using (Web Server or Application Server). For more information, the refer to the Sun Java System Access Manager Administration Guide (http://docs.sun.com/doc/817-7647).

Login to the Access Manager console as amAdmin using the password you specified during installation, with the following URL:

http://host.domain:port/amserver/

where host-name.domain-name:port is the fully qualified host name and port of the web container you are using. For example:

http://amhost.example.com:58080/amserver/

You should see the root suffix and organizations you specified during installation.

For the MadisonParc example used in this chapter, you would see the root suffix MadisonParc, and the two organizations Customers and Suppliers.

Previous Contents Index Next
Sun Java System Access Manager 6 2005Q1 Migration Guide