| Sun ONE Identity Server 6.1 Migration Guide |
Chapter 2
Upgrading from DSAME 5.1 to Identity Server 6.0This appendix provides steps for upgrading a iPlanet DSAME 5.1 installation to Sun ONE Identity Server 6.0. It includes reference sections that describe specific changes between DSAME 5.1 and Identity 6.0.
The following topics are included in this appendix:
Overview of Procedures and Migration ScriptsIt is expected that the person conducting upgrade procedures is familiar with Directory Server commands, schema semantics, directory information trees (DITs) Identity Server schema and Identity Server DIT structures. In addition, familiarity with XML and Identity Server installation procedure are required.
Roadmap of Upgrading Tasks
You can think of the upgrade process as having three major parts:
- Before you can begin migrating data, you must uninstall DSAME 5.1, and install Identity Server 6.0. For detailed instructions, see "Pre-Data Migration Tasks".
During data migration, first you migrate DSAME schema, policies, authentication entries, and services. Then in Identity Server 6.0, you update authentication entries, console service entries, and policies. For detailed instructions, see "Data Migration Tasks".
After you’ve migrated data, you can enable Federation Management. Then you must re-do any customization you may have done in the DSAME 5.1 console or in any pre-6.0 agents. There are also a small number of miscellaneous modifications you must make to Identity Server 6.0 configuration. For detailed instructions, see "Post-Data Migration Tasks".
The Figure 2-1 provides a detailed summary or roadmap of the tasks required for upgrading a DSAME 5.1 installation. Use the roadmap as a checklist as you proceed through the upgrade tasks.
Migration Scripts
Identity Server 6.0 provides a set of Perl scripts to migrate DSAME 5.1 data to Identity Server 6.0. The migration procedure is complex, but these scripts handle many of those complexities. Typically, scripts generate an input file and an output file. Both these files are retained after the scripts are run. This helps in checking the entries in output files. The input files will contain the entries in 5.1 format, while the output files will have the entries in 6.0 format.
When using these migration scripts, keep the following in mind:
- The output file needs to be loaded using ldapmodify command. It is not done automatically so that entries in the file can be checked before loading them.
- If you are running a script more than once, make sure to remove the old input and output files generated by the script. Some scripts append the output to an existing file because of which you may get errors while running ldapmodify commands.
- Each script contains additional information in them, which you must read before running the script. Additionally, in each script, you may have to set some variables or check the values of the variables before running the script.
- The migration scripts are case sensitive. The scripts will look for Identity Server attributes, object classes, and values that are in lower case. If you’ve customized your Identity Server 5.1 deployment with attribute names or object class names that contain upper case letters, then before running the scripts you must change those names to lower case letters.
Figure 2-1 Roadmap of upgrade tasks.
Pre-Data Migration TasksBefore you can begin data migration, you must uninstall DSAME 5.1 and install Identity Server 6.0 schema. It’s always a good practice to back up your existing installation before making changes of this scope.
Backing up the Existing Installation
Be sure that the DSAME 5.1 installation is completely backed up.
The Web Server data must be backed up manually. You can use the copy and tar commands for this. Any changes done to the Web Server files after the 5.1 installation must be backed up. Table 2-1 lists directories must also be backed up, and provides a brief descript of what is contained in each directory.
You can refer to these backups, to make corresponding changes once Identity Server 6.0 is installed. These changes need to be done manually after the Identity Server 6.0 is installed.
You should also backup logs, debug and install files. Table 2-2 lists the files that must be backed up and their location.
Back up any other data that needs to be updated after the 6.0 migration.
Uninstalling DSAME 5.1
Use the DSAME 5.1 uninstallation program to remove components of DSAME. But you must not remove Directory Server 5.1.
On Solaris
To remove DSAME components on Solaris:
- Run aminstall script from DSAME 5.1.
- Choose the following option:
1) Remove existing components, then continue installation
- At the next prompt, choose the following option to remove DSAME Management and Policy services.
1) DSAME Management and Policy Services
- Run aminstall script again and choose option 1.
- At the next prompt, choose the following option to remove Directory Server Configuration.
3) iPlanet Directory Server Configuration for DSAME
This will remove the schema configuration for the Directory Server.
- If Directory Server and Identity Server exist on different computer systems, then after installation is complete, you must manually remove the DSAME 5.1 schema file 95ns-amschema.ldif from the Directory Server schema directory.
- Check for the SUNWamjdk package after the uninstallation is complete using the following command:
pkginfo |grep SUNWamjdk
- If the SUNWamjdk package is present, remove it using the following command:
pkgrm SUNWamjdk
- Restart Directory Server after you have uninstalled the DSAME components.
On Windows
To uninstall DSAME 5.1 components, follow these steps:
- Run the DSAME 5.1 uninstallation program. Refer to DSAME 5.1 Installation and Configuration Guide for detailed steps. You can find this guide online at: http://docs.sun.com/source/816-5626-10/.
- Select partial uninstallation.
- Choose DSAME Management and Policy services.
The above steps do not remove Directory Server configuration for DSAME on Windows. In order to configure the Directory Server of DSAME 5.1 to Identity Server 6.0 schema in the next step, you must uninstall DSAME 5.1 schema configuration. Remove DSAME 5.1 schema file, 95ns-amschema.ldif from the Directory Server schema directory. In addition, the productregistry file must be updated to remove the directory server configuration component. You may remove the productregistry file itself. Please be sure to keep a backup of the productregistry file. If you remove the productregistry file, you can choose Add/Remove programs to remove Directory Server installation later.
Installing Identity Server Schema
Using the Identity Server 6.0 installation program, configure Directory Server to work with Identity Server 6.0. For detailed instructions, see the section “Installing Identity Server Schema” in the Identity Server 6.0 Installation and Configuration Guide.
Installing Identity Server 6.0 on Directory Server 5.1
You may need to make some changes to the Directory Server that exists with DSAME. This Directory Server supports a DIT like this:
Here isp is not really an organization. In such cases, the entry isp must be updated before you install Identity Server 6.0. If DSAME 5.1 Directory Server has an organization (flat DIT) as top level entry, then this change is not necessary before installing Identity Server 6.0. If the top level entry has iplanet-am-service-status attribute set, Identity Server 6.0 installation does not modify the Directory Server DIT. To retain the 5.1 DIT structure, add this attribute to the top level entry.
- Run the following command to update the top level entry, if it is not an organization:
- Use the right dn in the above command for your installation. If the top level entry in your DSAME 5.1 DIT is already an organization, then you shouldn't run the above command. You may run ldapsearch on the top level entry to check if this attribute is set.
- Now, install Identity Server 6.0 on this Directory Server. During installation, choose the option of installing with an existing DIT.
- While installing Identity Server 6.0, be sure the following entries have the same values as in DSAME 5.1 installation:
- directory root suffix
- directory manager password
- admin user
- admin password
- directory server host
- directory server port
- console deployment description
- services deployment descriptor
Refer to the AMConfig.properties file from the DSAME 5.1 installation backup for any values you are not sure. Also, retain the DSAME 5.1 values for organization object class, organization naming attribute, user object class and user naming attribute.
This step does not modify Directory Server data and schema. It only installs Identity Server 6.0 packages, libraries, configuration files, jar files, etc.
Data Migration TasksOnce Identity Server 6.0 is installed and the Directory Server schema is updated, the Directory Server data must be modified to Identity Server 6.0 format. All the migration scripts needed for this are located under the directory <install dir>/SUNWam/migration/51to60. The scripts contain additional information, which you must read before running the scripts. It will help you set some variables in each script or check the values of the variables.
In Identity Server 6.0, policy, authentication and console components have changed significantly from DSAME 5.1 and hence need to be migrated. However, Identity Server entries such as roles, groups, users, organizations, organizationalUnits and ACIs remain as they were in DSAME 5.1. They need not be migrated. The following entries of DSAME 5.1 need to be updated to Identity Server 6.0: Services branch, Organization, OrganizationalUnit, Policies, Roles, and Users.
Migrating DSAME 5.1 data to Identity Server 6.0 involves the following tasks:
Migrating Schema Changes
Identity Server 6.0 has seen some schema changes from DSAME 5.1. For example, objectClass iplanet-am-managed-org for the organization has been changed to sunManagedOrganization. The attribute iplanet-am-domain-name is changed to sunPreferredDomain. Similarly, there are other schema changes. A script, update-schema.pl is provided to migrate schema changes. Run this script to migrate schema changes. Refer to the script for additional information. It generates an input file, 51entries.ldif and an output file, 60entries.ldif. Run ldapmodify on this output ldif file. The last line of the script specifies the syntax for running the ldapmodify command on this output file. DSAME 5.1 entries are updated to Identity Server 6.0 schema when you run this script.
Migrating DSAME 5.1 Policies
DSAME 5.1 uses Class of Service (CoS) templates for policy implementation. The policy definition does not contain subjects to which the policy is assigned. Instead, policy must be explicitly assigned to a role or an organization. When a policy is assigned to an organization or a role, a CoS template is created. There is one CoS template for each organization or role that has a URL policy assigned.
In Identity Server 6.0, policy implementation is not done using CoS templates. The policy definition itself contains the subjects like organization or roles. Using the policy CoS templates, the DSAME 5.1 policies must be converted to Identity Server 6.0 policies to contain the subjects in the policy definition itself.
To convert the DSAME 5.1 policies to Identity Server 6.0 policies, the script update-polices.pl is provided. This script can be run for each organization or top level organization. If only one organization is specified to the script, it generates one output file containing 5.1 policies converted to 6.0 format for that organization. If the top level organization is specified, one XML file for each organization that has policies under the top level organization is generated. The output file name is of the format <rdn>-<rdn>.xml. For example, if o=iplanet.com,o=isp has some policies, the output file is o=iplanet.com-o=isp.xml. Run update-policies.pl script to generate XML files for the organization that have policies in DSAME 5.1. Refer to the script for additional details.
DSAME 5.1 has domain URL service. This service lets you do policy delegation control. This is somewhat similar to referral policies in Identity Server 6.0. If there are any domain URL policies defined, they must be backed up manually in this migration step.
For each domain URL policy, a referral policy may need to be created in Identity Server 6.0. Based on the domain URL policies, corresponding referral policies must be created in Identity Server 6.0. This needs to be done manually. No script is provided for this purpose. Refer to the section "Updating Policies to Identity Server 6.0" for more details.
This step must be run before migrating services. The output generated in this step will be used after the step "Updating Policies to Identity Server 6.0".
The URL policy DTD for DSAME 5.1 is located under DSAME_root/SUNWam/dtd.
The URL policy DTD for Identity Server 6.0 is installed under IS_root/SunWam/dtd.
Migrating Authentication Entries
Authentication services have changed significantly in Identity Server 6.0. These include changes in attribute names, attribute values, and default values and removal of attributes. The authentication information is present for each organization. The migration must update authentication entries for all organizations.
Run the authentication migration script, update-auth.pl. The script generates an output file, 51to60auth-entries.ldif. It also generates an input file 51auth-entries.dn.
The output files generated in this step will be used in the step "Updating Authentication Entries to Identity Server 6.0".
Refer to the section "Changes in Authentication Services" for the details on changes in authentication services from DSAME 5.1 to Identity Server 6.0.
Migrating Services
Each of the DSAME services needs to be removed and the corresponding Identity Server 6.0 service loaded. In addition, all the new Identity Server 6.0 services must also be loaded. The services branch has global schema information for each of the services and may contain entries specific to an organization. If the top level DSAME entry is an organization itself, like o=sun.com, then the services branch under sun.com will contain global schema and organization specific entries as well. The organization-specific entries depend on what services have been registered for this organization. Follow this procedure to update the services branch.
- If the top level entry is not an organization (such as o=isp, not an Identity Server organization), go to step 3. If the top level is an organization, go to step 2.
- Run update-toporg-services.pl script. This script backs up organization entries for various authentication services and Identity Server Console service registered for the top level organization. The organization entries for the services reside under the global services entry for the top level organization. In order to update global services to 6.0, those services must be removed and loaded from 6.0. This step keeps a backup of the organization entries that reside under global services entry. Refer to this script for details. Check that it covers all the services which have organization specific entries (refer to step 3 as well).
This script generates 51to60toporg-template.ldif output file. It also generates, 51toporg-template.dn input file.
- Use Directory Server console to remove the DSAME services. If you added other services, don't remove them. The following services must be removed.
iPlanetAMAdminConsoleService
iPlanetAMAuthService
iPlanetAMAuthAnonymousService
iPlanetAMAuthCertService
iPlanetAMAuthLDAPService
iPlanetAMAuthMembershipService
iPlanetAMAuthNTService
iPlanetAMAuthRadiusService
iPlanetAMAuthSafewordService
iPlanetAMAuthUnixService
iPlanetAMClientDetectionService
iPlanetAMDomainURLAccessService
iPlanetAMEntrySpecificService
iPlanetAMLoggingService
iPlanetAMNamingService
iPlanetAMPlatformService
iPlanetAMPolicyService
iPlanetAMSessionService
iPlanetAMUserService
iPlanetAMWebAgentService
DAI
If you have not added any additional services, you can remove the entire services branch under the top level entry.
- Run load-services.pl to load Identity Server 6.0 services. This script loads all Identity Server 6.0 services. It uses the services XML <install dir>/SUNWam/config/ums/ums.xml and the XML files under <install dir>/SUNWam/config/xml.
- Load the output file generated (51to60toporg-template.ldif) in step 2 above. This is required only if top level organization is an Identity Server organization. Use the ldapmodify command to load the output file. Refer to the last line in the output file for the syntax ("system" is not required, as that is used to run the script from the Perl script itself).
For details on Identity Server services changes in 6.0, refer to "Services in Identity Server 6.0".
Updating Authentication Entries to Identity Server 6.0
Load the output file generated in the step "Migrating Authentication Entries." Use the ldapmodify command to load this. You can refer to the last line in the script for the syntax. This step migrates the DSAME 5.1 authentication entries to Identity Server 6.0. In addition, the following procedures may be necessary.
Customized 5.1 HTML templates, if any, need to be changed to 6.0 JSP-based templates.
Any customized authentication module need to be rewritten using AMLoginModule.java. Screen properties need to be changed to use the XML- based Authentication module properties. Refer to Identity Server 6.0 documentation for more details on writing custom authentication modules.
User's authentication module configuration will not be migrated automatically. If any authentication module is selected for any user in DSAME 5.1, it will not be available for that user after migration. The required authentication modules need to be configured manually for that user in Identity Server 6.0.
The user's default login URL attribute (iplanet-am-user-default-url) is no longer available in 6.0. This attribute is not migrated to 6.0 automatically. The value of this attribute can be set to iplanet-am-auth-login-success-url in the core authentication service or the planet-am-auth-login-success-url in the authentication configuration service or to a custom attribute depending on the deployment needs. This attribute must be migrated and removed from the user entries. Otherwise user entries that have this attribute can't be modified (you will get object class violation error).
Updating Identity Server Console Service Entries to 6.0
There are changes in the Identity Server 6.0 Console service that affect the Console display. The Domain URL Service is no longer available in 6.0. Because of the policy changes in 6.0, Web Agent service and Domain URL service need not be registered to organization, role and user entries. A script is provided to update entries to reflect these changes.
- Run update-services.pl script to update the Console service if it is registered to any organization. The script generates input files, 51console.ldif and 51services.ldif and an output file, 60services.ldif.
- Run the ldapmodify command on the output file 60services.ldif. This command migrates console service entries registered for the organization. It also migrates organization, roles and user entries for Domain URL and Web Agent services.
Updating Policies to Identity Server 6.0
Before loading the updated policies in the Directory Server, the DSAME 5.1 policies must be deleted. Run the delete-policies script to delete all policies. It generates an input file delete-policies.dn and an output file, delete-policies.ldif. Run ldapdelete command on delete-policies.ldif to delete all 5.1 policies. Make sure all the entries specified in delete-policies.ldif are deleted. If you get errors for the entries that don't exist in the Directory Server, remove those entries from the ldif file and continue deleting other entries of the file. The delete-policies.ldif file may have some duplicate entries. It may give errors while deleting already deleted entries (for duplicate entries). You can ignore such errors. You can run ldapdelete in continuous mode to ignore such errors.
Identity Server 6.0 has a new Policy Configuration service. This service specifies various configuration attributes used by policy components like subjects, referrals and conditions. In order to create policies in an organization, policy configuration service must be registered. For each organization, before loading the policies to that organization, this service must be registered. You can login to Identity Server 6.0 Console and register these services to each organization. You can also use the amadmin command to register this service to each organization.
Starting with the top level organization, run the following command to load Identity Server 6.0 policies:
IS_root/bin/amadmin -u amadmin id -w password -t output migrated policy file for the organization
In Identity Server 6.0, the policies can have a description along with the policy name. Also individual elements of policy such as rules, subjects, conditions and referrals have names. When importing DSAME 5.1 policies, the names for these elements and description are automatically generated. The names can be modified after the policies are imported.
Identity Server 6.0 has the concept of referral policies. Refer to the Identity Server 6.0 documentation for more details on this. In order to create policies in sub organizations, there must be referral policies from the top level organization. Referral policies do policy delegation based on the resource referrals.
Consider the following DIT:
o=isp
/\
o=siroe.com o=iplanet.com
In order to create policies at siroe.com or iplanet.com, there must be a referral policy at o=isp.com to siroe.com and iplanet.com.
The referral policies at o=isp.com must contain the resource or resource prefix being managed at o=siroe.com or o=iplanet.com. If siroe.com manages http://www.siroe.com/, the referral policy at o=isp.com must contain the resource http://www.siroe.com/ in its rule and it must refer to siroe.com organization. For other resources being managed at o=siroe.com, other referral policies must be created at o=isp. Only after creating the top level referral policies, the policies at the sub-organization must be updated by running the command specified above. If there are no referral policies at the parent level for the resource specified at the sub org level policies, policy creation fails. So it is important to create referral policies at the parent level to the sub organization level before running the above command. Refer to the policy output file for each sub organization and check the resources contained in the XML files. For each of those resources, a referral policy must exist at the top level before loading the policy output XML file for that sub organization.
DSAME 5.1 has domain URL service. This service lets you do policy delegation control. This is somewhat similar to referral policies in 6.0. The key difference is that the domain URL service is enforced during policy evaluation, referral policies are enforced during policy creation as well as policy evaluation. Only the top level administrator can create domain URL policies in DSAME 5.1 by default.
In DSAME 5.1, using the above DIT, one could create policies in siroe.com giving access to resources in iplanet.com and vice versa. However the top level admin at o=isp, can create domain URL policies at o=siroe.com,o=isp. This policy specifies what is allowed in this organization. If the domain URL policy says, allow http://www.siroe.com/*, only those resources allowed in URL policies that match http://www.siroe.com/* would be returned during policy evaluation. This is enforced using referral policies in 6.0. For each domain URL policy created in DSAME 5.1, a corresponding referral policy must be created in 6.0. This step must be done manually.
Identity Server 6.0 has policy administrator role for policy management. The policy administrator has privileges to create, delete or modify policies and to assign services to organizations. For each organization in 6.0, policy administrator role must be created. Run update-policy-roles.pl script. It generates an output file, add-policy-roles.ldif. It also generates an input file, 51org-entries.dn. Load the output file generated by this script using ldapmodify. Refer to the syntax at the end of the script. This step creates various policy admin roles in Directory Server.
Post-Data Migration Tasks(Optional) Enabling Federation Management
Identity Server 6.0 implements Liberty Alliance Phase 1 specifications. When you migrate services (see ""Migrating Services""), two services are loaded for Federation Management. They are iPlanetAMAuthenticationDomainConfigService and iPlanetAMProviderConfigService. These services must be registered before you can use the Federation management features. An ldif file named liberty-services.ldif is provided to register these services.
Substitute the value of ROOT_SUFFIX in this file with the top-level organization. Run ldamodify on this ldif file. If the entries specified in this file are present in Identity Server 6.0, remove those entries from this ldif file and load the remaining entries. After this step, Federation management is enabled in Identity Server 6.0.
Miscellaneous 5.1-to-6.0 Modifications
Once the services and authentication entries are migrated, users should be able to successfully log in to Identity Server 6.0. If the Directory Server is on the same machine as Identity Server 6.0, edit <installdir>/bin/amserver script and modify the NDS_SERVER variable to point to the correct Directory Server instance.
Restart the Identity Server and login to the Identity Server 6.0 Console. If the default login URL of 5.1 in the core authentication service is not modified (<protocol>://<host>:<port>/amserver/login), you can use default login URL of Identity Server 6.0 (<protocol>://<host>:<port>/amserver/UI/Login) to login to Identity Server 6.0 Console. There is a known issue in 5.1, where the default login url is set to /amserver/login sometimes instead of <protocol>://<host>/amserver/login in core authentication service. In such cases, you can't use 6.0 default login URL to login. You need to modify the associated domain attribute of the default org to the 6.0 default login URL(<protocol>://<host>/amserver/UI/Login) to access the console using 6.0 default login URL. Use the fully qualified domain name for host and use the correct deployment descriptor in the URL. Note that the associated domain attribute value does not have port number in it but while accessing the console, need to specify the port. You can also use the URL of the form <protocol>://<host>:<port>/amserver/UI/Login?org=<org RDN> . It is a good idea to check for login, before migrating other entries. The migration is a step-by-step process; the steps should be validated as and when possible.
User management is not enabled by default. After the login to Identity Server Console, go to Service Configuration tab. Edit Administration service. Click on "Enable User Management" check box and save the service. Now you can go to Identity Management tab for user management functions.
IS 6.0 has introduced a new user, amldapuser. This user is used to bind and search the directory for LDAP, Membership authentication modules. This user is also used in the policy config service. Once the LDAP, Membership or Policy Config Service is registered to an organization, password for this user must be explicitly entered in those services. The password is the amldapuser password entered during Identity Server 6.0 installation. In addition, this user must also be created. Run the following two commands to create this user and to set access rights to this user.
<path to ldapmodify>/ldapmodify -D "cn=directory manager" -w <password>
dn: cn=amldapuser,ou=DSAME Users,ROOT_SUFFIX
changetype: add
objectclass: inetuser
objectclass: organizationalperson
objectclass: person
objectclass: top
cn: amldapuser
sn: amldapuser
userPassword: <password>
<path to ldapmodify>/ldapmodify -D "cn=directory manager" -w <password>
dn: ROOT_SUFFIX
changetype: modify
add: aci
aci: (target="ldap:///ROOT_SUFFIX")(targetattr="*")(version 3.0; acl "special ldap auth user rights"; allow (read,search) userdn = "ldap:///cn=amldapuser,ou=DSAME Users,ROOT_SUFFIX";)
In the above commands, specify the Directory Manager password for the -w option. Replace ROOT_SUFFIX with the your install root entry. Specify the amldapuser password for the userPassword attribute in the first command.
Note that if the LDAP and Membership services are already registered to an organization in IS 5.1, the bind DN used for the user search is "dsameuser". Change that user to the "amldapuser" created above and the password to the amldapuser password. This should be done in all the organizations where these two services are registered. If they are kept as "dsameuser", it will continue to work, but for Identity Server 6.0, it is recommended that you use "amldapuser".
The Identity Server user’s profile has an account expiration date attribute. The account expiration date format in DSAME 5.1 is mm/dd/yy hh:mm, while the account expiration date format in 6.0 is mm/dd/yyyy hh:mm. The attribute format is present in the file amUser.properties present in the directory named locale. If the account expiration attribute is set for the users in DSAME 5.1, the format of the date should be changed to 6.0 format, when modifying the users profile from Identity Server Console, to save the users profile changes. Alternatively, the date format can be changed to use the DSAME 5.1 format in amUser.properties. The ldapmodify command can also be used to modify the account expiration attribute value.
If there are any specific changes made to AMConfig.properties in DSAME 5.1, those changes must also be made in AMConfig.properties after Identity Server 6.0 is installed.
Migrating Console Changes
If any console customization has been done in DSAME 5.1, those changes must be migrated to console files in Identity Server 6.0.
This step must be done manually. No scripts are provided for this purpose.
The above steps migrate Directory Server Data, Schema and any customized data to 6.0. Once the steps are complete, you should restart Identity Server 6.0.
Migrating Agents
Agents 1.0 or 1.1 do not work with Identity Server 6.0. You must have Agents 2.0 to work with Identity Server 6.0. In order to migrate agents, you must uninstall Agents 1.0 or 1.1 and then install Agents 2.0.
- Backup any configuration changes made in 1.0 or 1.1 agents. For example changes done to AMAgent.properties.
- Install 2.0 agents.
- Make changes to 2.0 configuration files.
- Restart the agents.
Note
1. Any changes done to DSAME 5.1 XML files are not migrated in this procedure. Once Identity Server 6.0 is installed, those changes need to be manually updated in the 6.0 XML files. One way to do this is to update the 6.0 XML files before loading them.
2. The script update-rootsuffix.pl is not used in the migration procedure. This script can be used in step 3.4, if this script is available from another Identity Server 6.0 install. This script updates the top level entry to have iplanet-am-service-staus attribute.
Changes in Authentication ServicesThis section describes in detail the changes in authentication services.
Authentication Service (Core) [amAuth.xml]
Attribute Changes
Global
Organization
- Removed "iplanet-am-auth-chaining-modules"
- Removed "iplanet-am-auth-chaining-enabled"
- Removed "iplanet-am-auth-non-interactive-modules"
- Removed "iplanet-am-auth-default-url"
- Removed "iplanet-am-auth-user-based"
- Removed "iplanet-am-auth-login-worker-class"
- Added "iplanet-am-auth-org-config"
- Added "iplanet-am-auth-login-success-url"
- Added "iplanet-am-auth-login-failure-url"
- Added "iplanet-am-auth-post-login-process-class
- Added "iplanet-am-auth-username-generator-enabled"
- Added "iplanet-am-auth-username-generator-class
- Changed "iplanet-am-auth-menu" to "iplanet-am-auth-allowed-modules"
- In "iplanet-am-auth-admin-auth-module",
- In "iplanet-am-auth-login-failure-count", Changed Default Value from 3 to 5
- In "iplanet-am-auth-login-failure-duration", Changed Default Value from 15 to 300
- In "iplanet-am-auth-lockout-warn-user", Changed Default Value from 1 to 4
- In "iplanet-am-auth-default-auth-level", Changed ’syntax’ from "string" to "number"
Authentication related attribute changes in User Service [amUser.xml]
Attribute Changes
Dynamic
User
All "Organization" attributes in the following xml files
Table 2-3 summarizes the UI changes for authentication interface. The left column lists the filenames used in DSAME 5.1.1, the center column provides a brief description of each file, and the right column lists the filenames used in Identity Server 6.0.
Table 2-3 GUI Changes in the Authentication Interface
DSAME 5.1.1 Filename
Description
IS 6.0 Filename
1.
account_expired.html
Your account has expired. Contact your system administrator.
account_expired.jsp
2.
configuration.html
Configuration error.
configuration.jsp
3.
disclaimer.html
This is a sample disclaimer template.
disclaimer.jsp
4.
invalidPCookieUserid.html
Persistent Cookie Username does not exist in the Persistent Cookie Domain.
invalidPCookieUserid.jsp
5.
invalidPassword.html
The password entered does not contain enough characters.
invalidPassword.jsp
6.
invalid_domain.html
No such domain.
invalid_domain.jsp
7.
login_denied.html
User has no profile in this organization.
login_denied.jsp
8.
login_fail_template.html
Authentication failed.
login_failed_template.jsp
9.
login_menu.html
Authentication Menu
the tag rows will be replaced with login_menu_modules.html.
removed
10.
login_menu_modules.html
Authentication Menu will loop and display (replace the tag inside) this file with all the available modules
removed
11.
login_prompt.html
User based login page.
Login.jsp
12.
login_success.html
You have logged in successfully, but your system has no default login page.
Login.jsp
13.
login_template.html
Login/Password page
Login.jsp
14.
login_timeout_template.html
Your login session has timed out.
session_timeout.jsp
15.
logout.html
You have logged out.
Logout.jsp
16.
max_sessions.html
Maximum Sessions Limit Reached.
Message.jsp
17.
membership.html
Self Registration Module
membership.jsp
18.
membershipSkeleton.html
removed
19.
missingReqField.html
One of the required fields was not completed.
missingReqField.jsp
20.
module_denied.html
Your authentication module is denied.
module_denied.jsp
21.
noConfirmation.html
Missing the confirmation password field.
noConfirmation.jsp
22.
noLoginWorker.html
Authentication Page Generator not found.
removed
23.
noPassword.html
There was no password entered.
noPassword.jsp
24.
noUserName.html
There was no user name entered.
noUserName.jsp
25.
noUserProfile.html
No user profile was found matching the user name.
noUserProfile.jsp
26.
org_inactive.html
This organization is not active.
org_inactive.jsp
27.
passwordMismatch.html
The password and the confirm password do not match.
passwordMismatch.jsp
28.
privilege_failure.html
User does not have access to this operation.
Message.jsp
29.
profileException.html
An error occurred while storing the user profile.
profileException.jsp
30.
radius_patch.html
RADIUS authentication requires i-Planet patch 1.
Message.jsp
31.
register.html
Self Registration
register.jsp
32.
session_invalid.html
Your session is invalid.
removed
33.
session_timeout.html
Your session is timed out.
session_timeout.jsp
34.
userExists.html
A user already exists with this name.
userExists.jsp
35.
userPasswordSame.html
The User Name and Password fields cannot have the same value.
userPasswordSame.jsp
36.
user_inactive.html
This user is not active.
user_inactive.jsp
37.
wrongPassword.html
The password entered is invalid.
wrongPassword.jsp
38.
add
Displays internal authentication framework errors.
auth_error_template.jsp
39.
add
No configuration found/defined for a user for an organization.
noConfig.jsp
40.
add
User is not in a Role. (for ’role’ based authentication.)
userDenied.jsp
Services in Identity Server 6.0The following are the new services in Identity Server 6.0:
The following services have been removed in 6.0:
The following services remain quite similar in DSAME 5.1 and Identity Server 6.0:
- Identity Server Console Service (amAdminConsole.xml)
- Auth Anonymous Service (amAuthAnonymous.xml)
- Auth Membership Service (amAuthMembership.xml)
- Auth Cert Service (amAuthCert.xml)
- Auth LDAP Service (amAuthLDAP.xml)
- Auth NT Service (amAuthNT.xml)
- Auth Radius Service (amAuthRadius.xml)
- Auth SafeWord Service (amAuthSafeWord.xml)
- Auth Unix Service (amAuthUnix.xml)
- Client Detection Service (amClientDetection.xml)
- Naming Service (amNaming.xml)
- Platform Service (amPlatform.xml)
- Session Service (amSession.xml)
- URL Agent Service (amWebAgent.xml)
- Entry Specific Service (amEntrySpecific.xml)
- User (amUser.xml)
The following services have changed significantly in 6.0:
Name Changes to Attributes and Object ClassesTable 2-4 lists the names of attributes that have been renamed in Identity Server 6, and provides the new name for each attribute.
Table 2-4 Renamed Attributes
Old Attribute Name
New Attribute Name
iplanetserviceschema
sunserviceschema
iplanetserviceid
sunserviceid
iplanetsmspriority
sunservicepriority
iplanetpluginschema
sunpluginschema
iplanetkeyvalue
sunkeyvalue
iplanetpluginid
sunpluginid
iplanetxmlkeyvalue
sunxmlkeyvalue
iplanet-am-domain-name
sunPrefferedDomain
Table 2-5 lists the names of object classes that have been renamed in Identity Server 6.0, and provides the new name for each object class.
Table 2-5 Renamed Object Classes
Old Object Class
New Object Class
iplanetservice
sunservice
iplanetservicecomponent
sunservicecomponent
iplanetorgservice
sunorgservice
iplanetserviceplugin
sunserviceplugin
iplanet-am-managed-org
sunManagedOrganization
In addition, iplanet-am-unique-attribute-list and iplanet-am-attribute-uniqueness-enabled attributes are removed from Identity Server Console Service. A new attribute sunNameSapceUniqueAttrs in the new object class sunNameSpace is added to the organization entries to accommodate unique attribute list removed from Identity Server Console Service.
