Sun and OracleChannel SunHow to BuyLog In日本語

Sun OpenSSO Enterprise 8.0 Administration Guide
この本のみを検索
検索のヘルプ
内に含ま
その他のドキュメント
サポート リソース
 PDF 文書ファイルをダウンロードする (2148 KB)

Part III Directory Management and Default Services

This is part three of the Sun OpenSSO Enterprise 8.0 Administration Guide. The Directory Management chapter describes how to manage LDAP objects when OpenSSO Enterprise is deployed in Legacy Mode. The other chapters describe how to configure and use some of OpenSSO Enterprise's default services. This part contains the following chapters:

Chapter 11 Directory Management

The Directory Management tab is only displayed when you install OpenSSO Enterprise in Legacy mode. This directory management feature provides an identity management solution for Sun Directory Server-enabled OpenSSO Enterprise deployments.

For more information on the Legacy Mode installation option, see the Sun Java Enterprise System 5 Update 1 Installation Guide for UNIX

Managing Directory Objects

The Directory Management tab contains all the components needed to view and manage the Directory Server objects. This section explains the object types and details how to configure them. User, role, group, organization, sub organization and container objects can be defined, modified or deleted using either the OpenSSO Enterprise console or the command line interface. The console has default administrators with varying degrees of privileges used to create and manage the directory objects. (Additional administrators can be created based on roles.) The administrators are defined within the Directory Server when installed with OpenSSO Enterprise. The Directory Server objects you can manage are:

Organizations

An Organization represents the top-level of a hierarchical structure used by an enterprise to manage its departments and resources. Upon installation, OpenSSO Enterprise dynamically creates a top-level organization (defined during installation) to manage the OpenSSO Enterprise configurations. Additional organizations can be created after installation to manage separate enterprises. All created organizations fall beneath the top-level organization.

手順To Create an Organization

  1. Click the Directory Management tab.

  2. In the Organizations list, click New.

  3. Enter the values for the fields. Only Name is required. The fields are:

    Name

    Enter a value for the name of the Organization.

    Domain Name

    Enter the full Domain Name System (DNS) name for the organization, if it has one.

    Organization Status

    Choose a status of active or inactive . The default is active. This can be changed at any time during the life of the organization by selecting the Properties icon. Choosing inactive disables user access when logging in to the organization.

    Organization Aliases

    This field defines alias names for the organization, allowing you to use the aliases for authentication with a URL login. For example, if you have an organization named exampleorg, and define 123 and abc as aliases, you can log into the organization using any of the following URLs:

    http://machine.example.com/opensso/UI/Login?org=exampleorg

    http://machine.example.com/opensso/UI/Login?org=abc

    http://machine.example.com/opensso/UI/Login?org=123

    Organization alias names must be unique throughout the organization. You can use the Unique Attribute List to enforce uniqueness.

    DNS Alias Names

    Allows you to add alias names for the DNS name for the organization. This attribute only accepts “real” domain aliases (random strings are not allowed). For example, if you have a DNS named example.com, and define example1.com and example2.com as aliases for an organization named exampleorg, you can log into the organization using any of the following URLs:

    http://machine.example.com/opensso/UI/

    Login?org=exampleorg

    http://machine.example1.com/opensso/

    UI/Login?org=exampleorg

    http://machine.example2.com/opensso/

    UI/Login?org=exampleorg

    Unique Attribute List

    Allows you to add a list of unique attribute names for users in the organization. For example, if you add a unique attribute name specifying an email address, you would not be able to create two users with the same email address. This field also accepts a comma-separated list. Any one of the attribute names in the list defines uniqueness. For example, if the field contains PreferredDomain, AssociatedDomain and PreferredDomain is defined as http://www.example.com for a particular user, then the entire comma-separated list is defined as unique for http://www.example.com. Adding the naming attribute 'ou' to the Unique Attribute List will not enforce uniqueness for the default groups, people containers. (ou=Groups,ou=People). Uniqueness is enforced for all sub organizations.

    Note –

    Unique attributes can not be set in Realm mode.

  4. Click OK.

    The new organization displays in the Organization list. To edit any of the properties that you defined during creation of the organization, click the name of the organization you wish to edit, change the properties and click Save.

手順To Delete an Organization

  1. Select the checkbox next to the name of the organization to be deleted.

  2. Click Delete.

    Note –

    There is no warning message when performing a delete. All entries within the organization will be deleted and you can not perform an undo.

To Add an Organization to a Policy

OpenSSO Enterprise objects are added to a policy through the policy’s subject definition. When a policy is created or modified, organizations, roles, groups, and users can be defined as the subject. Once the subject is defined, the policy will be applied to the object. For more information, see Modifying Policies and Referrals.

Containers

The container entry is used when, due to object class and attribute differences, it is not possible to use an organization entry. It is important to remember that the OpenSSO Enterprise container entry and the OpenSSO Enterprise organization entry are not necessarily equivalent to the LDAP object classes organizationalUnit and organization. They are abstract identity entries. Ideally, the organization entry will be used instead of the container entry.

Note –

The display of containers is optional. To view containers you must select Show Containers in the Administration service under Configuration>Console Properties.

手順To Create a Container

  1. Select the location link of the organization or container where the new container will be created.

  2. Click the Containers tab.

  3. Click New in the Containers list.

  4. Enter the name of the container to be created.

  5. Click OK.

手順To Delete a Container

  1. Click the Containers tab.

  2. Select the checkbox next to the name of the container to be deleted.

  3. Click Delete.

    Note –

    Deleting a container will delete all objects that exist in that Container. This includes all objects and sub containers.

Group Containers

A group container is used to manage groups. It can contain only groups and other group containers. The group container Groups is dynamically assigned as the parent entry for all managed groups. Additional group containers can be added, if desired.

Note –

The display of group containers is optional. To view group containers you must select Enable Group Containers in the Administration service under Configuration>Console Properties.

手順To Create a Group Container

  1. Select the location link of the organization or the group container which will contain the new group container.

  2. Select the Group Containers tab.

  3. Click New in the Group Containers list.

  4. Enter a value in the Name field and click OK. The new group container displays in the Group Containers list.

手順To Delete a Group Container

  1. Navigate to the organization which contains the group container to be deleted.

  2. Choose the Group Containers tab.

  3. Select the checkbox next to the group container to be deleted.

  4. Click Delete.

Groups

A group represents a collection of users with a common function, feature or interest. Typically, this grouping has no privileges associated with it. Groups can exist at two levels; within an organization and within other managed groups. Groups that exist within other groups are called sub-groups. Sub groups are child nodes that “physically” exist within a parent group.

OpenSSO Enterprise also supports nested groups, which are “representations” of existing groups contained in a single group. As opposed to sub groups, nested groups can exist anywhere in the DIT. They allow you to quickly set up access permissions for a large number of users.

There are two types of groups you can create; static groups and dynamic groups. Users can only be manually added to static groups, while dynamic groups control the addition of users through a filter. Nested or sub groups can be added to both types.

Static Group

A static group is created based on the Managed Group Type you specify. Group members are added to a group entry using the groupOfNames or groupOfUniqueNames object class.

Note –

By default, the managed group type is dynamic. You can change this default in the Administration service configuration.

Dynamic Group

A dynamic group is created through the use of an LDAP filter. All entries are funneled through the filter and dynamically assigned to the group. The filter would look for any attribute in an entry and return those that contain the attribute. For example, if you were to create a group based on a building number, you can use the filter to return a list all users containing the building number attribute.

Note –

OpenSSO Enterprise should be configured with Directory Server to use the referential integrity plug-in. When the referential integrity plug-in is enabled, it performs integrity updates on specified attributes immediately after a delete or rename operation. This ensures that relationships between related entries are maintained throughout the database. Database indexes enhance the search performance in Directory Server. For more information on enabling the plug-in, see the Sun Java OpenSSO Enterprise 6 Migration Guide.

手順To Create a Static Group

  1. Navigate to the organization, group, or group container where the new group will be created.

  2. From the Groups list, click New Static.

  3. Enter a name for the group in the Name field. Click Next.

  4. Select the Users Can Subscribe to this Group attribute to allow users to subscribe to the group themselves.

  5. Click OK.

    Once the group is created, you can edit the Users Can Subscribe to this Group attribute by selecting the name of the group and clicking the General tab.

手順To Add or Remove Members to a Static Group

  1. From the Groups list, select the group to which you will add members.

  2. Choose an action to perform in the Select Action menu. The actions you can perform are as follows:

    New User

    This action creates a new user and adds the user to the group when the user information is saved.

    Add User

    This action adds an existing user to the group. When you select this action, you create a search criteria which will specify users you wish to add. The fields used to construct the criteria use either an ANY or ALL operator. ALL returns users for all specified fields. ANY returns users for any one of the specified fields. If a field is left blank, it will match all possible entries for that particular attribute.

    Once you have constructed the search criteria, click Next. From the returned list of users, select the users you wish to add and click Finish.

    Add Group

    This action adds a nested group to the current group. When you select this action, you create a search criteria, including search scope, the name of the group (the asterisk wildcard is accepted), and you can specify whether users can subscribe to the group themselves. Once you have entered the information, click Next. From the returned list of groups, select the group you wish to add and click Finish.

    Remove Members

    This action will remove members (which includes users and groups) from the group, but will not delete them. Select the members you wish to remove and choose Remove Members from the Select Actions menu.

    Delete Members

    This action will permanently delete the member you select. Select the members you wish to delete and choose Delete Members.

手順To Create a Dynamic Group

  1. Navigate to the organization or group where the new group will be created.

  2. Click the Groups tab.

  3. Click New Dynamic.

  4. Enter a name for the group in the Name field.

  5. Construct the LDAP search filter.

    By default, OpenSSO Enterprise displays the Basic search filter interface. The Basic fields used to construct the filter use either an ANY or ALL operator. ALL returns users for all specified fields. ANY returns users for any one of the specified fields. If a field is left blank it will match all possible entries for that particular attribute.

  6. When you click OK all users matching the search criteria are automatically added to the group.

手順To Add or Remove Members to a Dynamic Group

  1. Form the Groups list, click the name of the group to which you will add members.

  2. Choose an action to perform in the Select Action menu. The actions you can perform are as follows:

    Add Group

    This action adds a nested group to the current group. When you select this action, you create a search criteria, including search scope, the name of the group (the asterisk wildcard is accepted), and you can specify whether users can subscribe to the group themselves. Once you have entered the information, click Next. From the returned list of groups, select the group you wish to add and click Finish.

    Remove Members

    This action will remove members (which includes groups) from the group, but will not delete them. Select the members you wish to remove and choose Remove Members.

    Delete Members

    This action will permanently delete the member you select. Select the members you wish to delete and choose Delete Members.

To Add a Group to a Policy

OpenSSO Enterprise objects are added to a policy through the policy’s subject definition. When a policy is created or modified, organizations, roles, groups, and users can be defined as the subject in the policy’s Subject page. Once the subject is defined, the policy will be applied to the object. For more information, see Modifying Policies and Referrals.

People Containers

A people container is the default LDAP organizational unit to which all users are assigned when they are created within an organization. People containers can be found at the organization level and at the people container level as a sub People Container. They can contain only other people containers and users. Additional people containers can be added into the organization, if desired.

Note –

The display of people containers is optional. To view People Containers you must select Enable People Containers in the Administration Service.

手順Create a People Container

  1. Navigate to the organization or people container where the new people container will be created.

  2. Click New from the People Container list.

  3. Enter the name of the people container to be created.

  4. Click OK.

手順To Delete a People Container

  1. Navigate to the organization or people container which contains the people container to be deleted.

  2. Select the checkbox next to the name of the people container to be deleted.

  3. Click Delete.

    Note –

    Deleting a people container will delete all objects that exist in that people container. This includes all users and sub people containers.

Users

A user represents an individual’s identity. Through the OpenSSO Enterprise Identity Management module, users can be created and deleted in organizations, containers and groups and can be added or removed from roles and/or groups. You can also assign services to the user.

Note –

If a user in a sub organization is created with the same user ID as amadmin, the login will fail for amadmin. If this problem occurs, the administrator should change the user’s ID through the Directory Server console. This enables the administrator to login to the default organization. Additionally, the DN to Start User Search in the authentication service can be set to the people container DN to ensure that a unique match is returned during the login process.

手順To Create a User

  1. Navigate to the organization, container or people container where the user is to be created.

  2. Click the user tab.

  3. Click New from the user list.

  4. Enter data for the following values:

    User ID

    This field takes the name of the user with which he or she will log into OpenSSO Enterprise. This property may be a non-DN value.

    First Name

    This field takes the first name of the user. The First Name value and the Last Name value identify the user in the Currently Logged In field. This is not a required value.

    Last Name

    This field takes the last name of the user. The First Name value and the Last Name value identify the user.

    Full Name

    This field takes the full name of the user.

    Password

    This field takes the password for the name specified in the User Id field.

    Password (Confirm)

    Confirm the password.

    User Status

    This option indicates whether the user is allowed to authenticate through OpenSSO Enterprise. Only active users can authenticate. The default value is Active.

  5. Click OK.

手順To Edit the User Profile

When a user who has not been assigned an administrative role authenticates to OpenSSO Enterprise, the default view is their own User Profile. Additionally, administrators with the proper privileges can edit user profiles. In this view the user can modify the values of the attributes particular to their personal profile. The attributes displayed in the User Profile view can be extended. For more information on adding customized attributes for objects and identities, see the OpenSSO Enterprise Developer's Guide.

  1. Select the user who's profile is to be edited. By default, the General view is displayed.

  2. Edit the following fields:

    First Name

    This field takes the first name of the user.

    Last Name

    This field takes the last name of the user.

    Full Name

    This field takes the full name of the user.

    Password

    Click the Edit link to add and confirm the user password.

    Email Address

    This field takes the email address of the user.

    Employee Number

    This field takes the employee number of the user.

    Telephone Number

    This field takes the telephone number of the user.

    Home Address

    This field can take the home address of the user.

    User Status

    This option indicates whether the user is allowed to authenticate through OpenSSO Enterprise. Only active users can authenticate through OpenSSO Enterprise. The default value is Active. Either of the following can be selected from the pull-down menu: .

    • Active: The user can authenticate through OpenSSO Enterprise.

    • Inactive: The user cannot authenticate through OpenSSO Enterprise, but the user profile remains stored in the directory.

      Note –

      Changing the user status to Inactive only affects authentication through OpenSSO Enterprise. The Directory Server uses the nsAccountLock attribute to determine user account status. User accounts inactivated for OpenSSO Enterprise authentication can still perform tasks that do not require OpenSSO Enterprise. To inactivate a user account in the directory, and not just for OpenSSO Enterprise authentication, set the value of nsAccountLock to true. If delegated administrators at your site will be inactivating users on a regular basis, consider adding the nsAccountLock attribute to the OpenSSO Enterprise User Profile page. See the Sun OpenSSO Enterprise 8.0 Developer’s Guide for details.

    Account Expiration Date

    If this attribute is present, the authentication service will disallow login if the current date and time has passed the specified Account Expiration Date. The format for this attribute is mm/dd/yyyy hh:mm.

    User Authentication Configuration

    This attribute sets the authentication chain for the user.

    User Alias List

    The field defines a list of aliases that may be applied to the user. In order to use any aliases configured in this attribute, the LDAP service has to be modified by adding the iplanet-am-user-alias-list attribute to the User Entry Search Attributes field in the LDAP service.

    Preferred Locale

    This field specifies the locale for the user.

    Success URL

    This attribute specifies the URL that the user will be redirected to upon successful authentication.

    Failure URL.

    This attribute specifies the URL that the user will be redirected to upon unsuccessful authentication.

    Password Reset Options

    This is used to select the questions on the forgotten password page, which is used to recover a forgotten password.

    User Discovery Resource Offering

    Sets the User Discovery service's resource offering for the user.

    MSIDSN Number

    Defines the user's MSISDN number if using MSISDN authentication.

手順To Add a User to Roles and Groups

  1. Click the Users tab.

  2. Click the name of the user you wish to modify.

  3. Select either the Roles or Groups tab.

  4. Select the role or group to which you wish to add the user and click Add.

  5. Click Save.

    Note –

    To remove a user from Roles or groups, Select roles or groups and click Remove and then Save.

To Add a User to a Policy

OpenSSO Enterprise objects are added to a policy through the policy’s subject definition. When a policy is created or modified, organizations, roles, groups, and users can be defined as the subject in the policy’s Subject page. Once the subject is defined, the policy will be applied to the object. For more information, see Modifying Policies and Referrals.

Roles

Roles are a Directory Server entry mechanism similar to the concept of a group. A group has members; a role has members. A role’s members are LDAP entries that possess the role. The criteria of the role itself is defined as an LDAP entry with attributes, identified by the Distinguished Name (DN) attribute of the entry. Directory Server has a number of different types of roles but OpenSSO Enterprise can manage only one of them: the managed role.

Note –

The other Directory Server role types can still be used in a directory deployment; they just can not be managed by the OpenSSO Enterprise console. Other Directory Server types can be used in a policy’s subject definition. For more information on policy subjects, see Creating Policies and Referrals.

Users can possess one or more roles. For example, a contractor role which has attributes from the Session Service and the Password Reset Service might be created. When new contractor employees join the company, the administrator can assign them this role rather than setting separate attributes in the contractor entry. If the contractor is working in the Engineering department and requires services and access rights applicable to an engineering employee, the administrator could assign the contractor to the engineering role as well as the contractor role.

OpenSSO Enterprise uses roles to apply access control instructions. When first installed, OpenSSO Enterprise configures access control instructions (ACIs) that define administrator permissions. These ACIs are then designated in roles (such as Organization Admin Role and Organization Help Desk Admin Role) which, when assigned to a user, define the user’s access permissions.

Users can view their assigned roles only if the Show Roles on User Profile Page attribute is enabled in the Administration Service.

Note –

OpenSSO Enterprise should be configured with Directory Server to use the referential integrity plug-in. When the referential integrity plug-in is enabled, it performs integrity updates on specified attributes immediately after a delete or rename operation. This ensures that relationships between related entries are maintained throughout the database. Database indexes enhance the search performance in Directory Server.

There are two types of roles:

  • Static: Static roles are created without adding users at the point of the role’s creation. Once the role is created, you can then add specific users to it. This gives you more control when adding users to a given role.

  • Dynamic: Dynamic roles are created through the use of an LDAP filter. All users are funneled through the filter and assigned to the role at the time of the role’s creation. The filter looks for any attribute value pair (for example, ca=user*) in an entry and automatically assign the users that contain the attribute to the role.

手順To Create a Static Role

  1. Go to the organization where the Role will be created.

  2. Click the Roles tab.

    A set of default roles are created when an organization is configured, and are displayed in the Roles list. The default roles are:

    Container Help Desk Admin. The Container Help Desk Admin role has read access to all entries in an organizational unit and write access to the userPassword attribute in user entries only in this container unit.

    Organization Help Desk Admin. The Organization Help Desk Administrator has read access to all entries in an organization and write access to the userPassword attribute.

    Note –

    When a sub organization is created, remember that the administration roles are created in the sub organization, not in the parent organization.

    Container Admin. The Container Admin role has read and write access to all entries in an LDAP organizational unit. In OpenSSO Enterprise, the LDAP organizational unit is often referred to as a container.

    Organization Policy Admin. The Organization Policy Administrator has read and write access to all policies, and can create, assign, modify, and delete all policies within that organization.

    People Admin. By default, any user entry in an newly created organization is a member of that organization. The People Administrator has read and write access to all user entries in the organization. Keep in mind that this role DOES NOT have read and write access to the attributes that contain role and group DNs therefore, they cannot modify the attributes of, or remove a user from, a role or a group.

    Note –

    Other containers can be configured with OpenSSO Enterprise to hold user entries, group entries or even other containers. To apply an Administrator role to a container created after the organization has already been configured, the Container Admin Role or Container Help Desk Admin defaults would be used.

    Group Admin. The Group Administrator created when a group is created has read and write access to all members of a specific group, and can create new users, assign users to the groups they manage, and delete the users the that they have created.

    When a group is created, the Group Administrator role is automatically generated with the necessary privileges to manage the group. The role is not automatically assigned to a group member. It must be assigned by the group’s creator, or anyone that has access to the Group Administrator Role.

    Top-level Admin. The Top-level Administrator has read and write access to all entries in the top-level organization. In other words, this Top-level Admin role has privileges for every configuration principal within the OpenSSO Enterprise application.

    Organization Admin. The Organization Administrator has read and write access to all entries in an organization. When an organization is created, the Organization Admin role is automatically generated with the necessary privileges to manage the organization.

  3. Click the New Static button.

  4. Enter a name for the role.

  5. Enter a description of the role.

  6. Choose the role type from the Type menu.

    The role can be either an Administrative role or a Service role. The role type is used by the console to determine and here to start the user in the OpenSSO Enterprise console. An administrative role notifies the console that the possessor of the role has administrative privileges; the service role notifies the console that the possessor is an end user.

  7. Choose a default set of permissions to apply to the role from the Access Permission menu. The permissions provide access to entries within the organization. The default permissions shown are in no particular order. The permissions are:

    No permissions

    No permissions are to be set on the role.

    Organization Admin

    The Organization Administrator has read and write access to all entries in the configured organization.

    Organization Help Desk Admin

    The Organization Help Desk Administrator has read access to all entries in the configured organization and write access to the userPassword attribute.

    Organization Policy Admin

    The Organization Policy Administrator has read and write access to all policies in the organization. The Organization Policy Administrator can not create a referral policy to a peer organization.

    Generally, the No Permissions ACI is assigned to Service roles, while Administrative roles are assigned any of the default ACIs.

手順To Add Users to a Static Role

  1. Click the name of the role to which you wish to add users.

  2. In the Members list, select Add User from the Select Action menu.

  3. Enter the information for the search criteria. You can choose to search for users based on one or more the displayed fields The fields are:

    Match

    Allows you to select the fields you wish to include for the filter. ALL returns users for all specified fields. ANY returns users for any one of the specified fields.

    First Name

    Search for users by their first name.

    User ID

    Search for a user by User ID.

    Last Name

    Search for users by their last name.

    Full Name

    Search for users by their full name.

    User Status

    Search for users by their status (active or inactive)

  4. Click Next to begin the search. The results of the search are displayed.

  5. Choose the users from the names returned by selecting the checkbox next to the user name.

  6. Click Finish.

    The Users are now assigned to the role.

手順To Create a Dynamic Role

  1. Go to the organization where the Role will be created.

  2. Click the Roles tab.

    A set of default roles are created when an organization is configured, and are displayed in the Roles list. The default roles are:

    Container Help Desk Admin. The Container Help Desk Admin role has read access to all entries in an organizational unit and write access to the userPassword attribute in user entries only in this container unit.

    Organization Help Desk Admin. The Organization Help Desk Administrator has read access to all entries in an organization and write access to the userPassword attribute.

    Note –

    When a sub organization is created, remember that the administration roles are created in the sub organization, not in the parent organization.

    Container Admin. The Container Admin role has read and write access to all entries in an LDAP organizational unit. In OpenSSO Enterprise, the LDAP organizational unit is often referred to as a container.

    Organization Policy Admin. The Organization Policy Administrator has read and write access to all policies, and can create, assign, modify, and delete all policies within that organization.

    People Admin. By default, any user entry in an newly created organization is a member of that organization. The People Administrator has read and write access to all user entries in the organization. Keep in mind that this role DOES NOT have read and write access to the attributes that contain role and group DNs therefore, they cannot modify the attributes of, or remove a user from, a role or a group.

    Note –

    Other containers can be configured with OpenSSO Enterprise to hold user entries, group entries or even other containers. To apply an Administrator role to a container created after the organization has already been configured, the Container Admin Role or Container Help Desk Admin defaults would be used.

    Group Admin. The Group Administrator created when a group is created has read and write access to all members of a specific group, and can create new users, assign users to the groups they manage, and delete the users the that they have created.

    When a group is created, the Group Administrator role is automatically generated with the necessary privileges to manage the group. The role is not automatically assigned to a group member. It must be assigned by the group’s creator, or anyone that has access to the Group Administrator Role.

    Top-level Admin. The Top-level Administrator has read and write access to all entries in the top-level organization. In other words, this Top-level Admin role has privileges for every configuration principal within the OpenSSO Enterprise application.

    Organization Admin. The Organization Administrator has read and write access to all entries in an organization. When an organization is created, the Organization Admin role is automatically generated with the necessary privileges to manage the organization.

  3. Click the New Dynamic button.

  4. Enter a name for the role.

  5. Enter a description for the role.

  6. Choose the role type from the Type menu.

    The role can be either an Administrative role or a Service role. The role type is used by the console to determine and where to start the user in the OpenSSO Enterprise console. An administrative role notifies the console that the possessor of the role has administrative privileges; the service role notifies the console that the possessor is an end user.

  7. Choose a default set of permissions to apply to the role from the Access Permission menu. The permissions provide access to entries within the organization. The default permissions shown are in no particular order. The permissions are:

    No permissions

    No permissions are to be set on the role.

    Organization Admin

    The Organization Administrator has read and write access to all entries in the configured organization.

    Organization Help Desk Admin

    The Organization Help Desk Administrator has read access to all entries in the configured organization and write access to the userPassword attribute.

    Organization Policy Admin

    The Organization Policy Administrator has read and write access to all policies in the organization. The Organization Policy Administrator can not create a referral policy to a peer organization.

    Generally, the No Permissions ACI is assigned to Service roles, while Administrative roles are assigned any of the default ACIs.

  8. Enter the information for the search criteria. The fields are:

    Match

    Allows you to include an operator for any the fields you wish to include for the filter. ALL returns users for all specified fields. ANY returns users for any one of the specified fields.

    First Name

    Search for users by their first name.

    User ID

    Search for a user by User ID.

    Last Name

    Search for users by their last name.

    Full Name

    Search for users by their full name.

    User Status

    Search for users by their status (active or inactive)

  9. Click OK to initiate the search based on the filter criteria. The users defined by the filter criteria are automatically assigned to the role.

手順To Remove Users from a Role

  1. Navigate to the Organization that contains the role to modify.

    Choose Organizations from the View menu in the Identity Management module and select the Roles tab.

  2. Select the role to modify.

  3. Choose Users from the View menu.

  4. Select the checkbox next to each user to be removed.

  5. Click Remove user from the Select Action menu.

    The users are now removed from the role.

To Add a Role to a Policy

OpenSSO Enterprise objects are added to a policy through the policy’s subject definition. When a policy is created or modified, organizations, roles, groups, and users can be defined as the subject in the policy’s Subject page. Once the subject is defined, the policy will be applied to the object. For more information, see Modifying Policies and Referrals.

Chapter 12 Current Sessions

This chapter describes the session management features of OpenSSO Enterprise. The Session Management module provides a solution for viewing user session information and managing user sessions. It keeps track of various session times as well as allowing the administrator to terminate a session. System administrators should ignore the Load Balancer servers listed in the Platform Server list.

The Current Sessions Interface

The Current Sessions module interface allows an administrator, with the appropriate permissions, to view the session information for any user who is currently logged in to OpenSSO Enterprise.

Session Management

The Session Management frame displays the name of the OpenSSO Enterprise that is currently being managed.

Session Information

The Session Information window displays all of the users who are currently logged into OpenSSO Enterprise, and displays the session time for each user. The display fields are:

User ID. Displays the user ID of the user who is currently logged in.

Time Left. Displays the amount of time (in minutes) remaining that the user has for that session before having to re-authenticate.

Max Session Time. Displays the maximum time (in minutes) that the user can be logged in before the session expires and must re-authenticate to regain access.

Idle Time.. Displays the time (in minutes) that the user has been idle.

Max Idle Time.Displays the maximum time (in minutes) that a user can remain idle before having to re-authenticate.

The time limits are defined by the administrator in the Session Management Service.

You can display a specific user session, or a specific range of user sessions, by entering a string in the User ID field and clicking Filter. Wildcards are permitted.

Clicking the Refresh button will update the user session display.

Terminating a Session

Administrators with appropriate permissions can terminate a user session at any time.

手順To Terminate a Session

  1. Select the user session that you wish to terminate.

  2. Click Invalidate Session.

    To terminate multiple sessions, select the individual sessions and click the Invalidate Sessions button.

Chapter 13 Password Reset Service

OpenSSO Enterprise provides a Password Reset service to allow users to reset their password for access to a given service or application protected by OpenSSO Enterprise. The Password Reset service attributes, defined by the top-level administrator, control user validation credentials (in the form of secret questions), control the mechanism for new or existing password notification, and sets possible lockout intervals for incorrect user validation.

Your configuration must meet the following prerequisites in order for the Password Reset service to work:

Registering the Password Reset Service

The Password Reset service does not need to be registered for the realm in which the user resides. If the Password Reset service does not exist in the organization in which the user resides, it will inherit the values defined for the service in Service Configuration.

手順To Register Password Reset for Users in a Different Realm

  1. Navigate to the realm to which you will register the password for the user.

  2. Click the realm name and click the Services tab.

    If it has not been added to the realm, click the Add button.

  3. Select Password Reset and click Next

    The Password Reset service attributes will be displayed. For attribute definitions, see the online help or Password Reset in Sun OpenSSO Enterprise 8.0 Administration Reference.

  4. Click Finish.

Configuring the Password Reset Service

Once the Password Reset service has been registered, the service must be configured by a user with administrator privileges.

手順To Configure the Service

  1. Select the realm for which the Password Reset service is registered.

  2. Click the Services tab.

  3. Click Password Reset from the services list.

  4. The Password Reset attributes appear, allowing you to define requirements for the Password Reset service. Make sure that the Password Reset service is enabled (it is by default). At a minimum, the following attributes must be defined:

    • User Validation

      • Secret Question

      • Bind DN

      • Bind Password

    The Bind DN attribute must contain a user with privileges for resetting the password (for example, Help Desk Administrator). Due a limitation in Directory Server, Password Reset does not work when the bind DN is cn=Directory Manager. The remaining attributes are optional. See the online help for a description of the service attributes.

  5. Enable Force Change Password After Reset.

    This optional step is the key part for the password reset service to force the user to change their password after a password reset. If this is not enabled then password reset service will ignore the pwdreset control from the Directory Server. This particular option is meaningful only if the password policy in the Directory Server is enabled to force the users to change the password upon an administrator-controlled password reset occurrence, so you must make a configuration change for the Directory Server.

    You can enable Force Change Password After Reset globally by selecting it in the global Password Reset attributes, or you can select if for individual users by selecting a User profile, clicking on Password Reset Options, and enabling the attribute.

  6. Select the Personal Question Enabled attribute if the user is to define his/her unique personal questions. Once the attributes are defined, click Save.

手順To Localize the Secret Question

If you are running a localized version of the OpenSSO Enterprise, and wish to display the secret question in a character set specific to you locale, perform the following:

  1. Add the secret question key to the Current Values list under the Secret Question attribute in the Password Reset service. For example, favorite-color.

  2. Add the key to the amPasswordReset.properties file with the question that you want to displays the value of this key. For example:

    favorite-color=What is your favorite color?

  3. Add the same key with the localized question to AMPasswordReset_locale.properties. When the user attempts to changes his or her password, the localized question is displayed.

Password Reset Lockout

The Password Reset service contains a lockout feature that will restrict users to a certain number of attempts to correctly answer their secret questions. The lockout feature is configured through the Password Reset service attributes. See the online help for a description of the service attributes. Password Reset supports two types of lockout, memory lockout and physical lockout.

Memory Lockout

This is a temporary lockout and is in effect only when the value in the Password Reset Failure Lockout Duration attribute is greater than zero and the Enable Password Reset Failure Lockout attribute is enabled. This lockout will prevent users from resetting their password through the Password Reset web application. The lockout lasts for the duration specified in Password Reset Failure Lockout Duration, or until the server is restarted. See the online help or Password Reset in Sun OpenSSO Enterprise 8.0 Administration Reference for a description of the service attributes.

Physical Lockout

This is a more permanent lockout. If the value set in the Password Reset Failure Lockout Count attribute is set to 0 and the Enable Password Reset Failure Lockout attribute is enabled, the users’ account status is changed to inactive when he or she incorrectly answers the secret questions. See the online help, or Password Reset in Sun OpenSSO Enterprise 8.0 Administration Reference for a description of the service attributes.

Password Policies

A password policy is a set of rules to govern how passwords are used in a given directory. Password policies are defined in the Directory Server, typically through the Directory Server console. A secure password policy minimizes the risks associated with easily-guessed passwords by enforcing the following:

  • Users must change their passwords according to a schedule.

  • Users must provide non-trivial passwords.

  • Accounts may be locked after a number of binds with the wrong password.

Directory Server provides several ways to set password policy at any node in a tree and there are several ways to set the policy. For details refer to the Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide.

Note –

In Directory Server, the password policy contains an attribute, passwordExp, that defines whether user passwords will expire after a given number of seconds. If the administrator sets the passwordExp attribute to on, this sets the expiration for the end-user's password as well as the OpenSSO Enterprise's administration accounts, such as amldap, dsame, and puser. When the OpenSSO Enterprise administrator's account password expires, and an end-user is logged in, the user will receive the password change screen. However, OpenSSO Enterprise does not specify the user to which the password change screen pertains. In this case, the screen is intended for the administrator and the end-user will be unable to change the password.

To resolve this, the administrator must log in to the Directory Server and change the amldap, dsame, and puser passwords, or change the passwordExpirationTime attribute for some time in the future.

手順Example: To Create a Password Policy in Directory Server for Force Password Change After Reset

The following example shows how to configure the Directory Server to work with the Force Password Change After Reset attribute. This involves creating a password policy and assigning to it to a range of user identities.

This sample password policy forces users to change their password after an administrator reset (Any password change that is not done by the self modify is considered as password reset, meaning that the attribute pwdreset will be true.)

  1. Enter the following text in to a file called passwdPolicy.ldif:


    dn: cn=AMUsersPasswordPolicy,dc=red,dc=iplanet,dc=com
objectClass: top
objectClass: pwdPolicy
objectClass: LDAPsubentry
cn: AMUsersPasswordPolicy
pwdMustChange: TRUE
pwdattribute: userPassword

  2. Execute the following command:

    ldapmodify -D"cn=directory manager" -w admin123 -c -a -f passwdPolicy.ldif

    This will add the password policy to the Directory Server.

  3. Assign this policy to user identities. For example, enter the following text in to a file called AddPwdPolicy.ldif:


    dn:uid=example_user,ou=people,dc=red,dc=iplanet,dc=com
changetype:modify
add: pwdPolicySubentry
pwdPolicySubentry:cn=AMUsersPasswordPolicy,dc=red,dc=iplanet,dc=com

  4. Execute the following command:

    ldapmodify -D"cn=directory manager" -w admin123 -c -a -f AddPwdPolicy.ldif

Password Reset for End Users

The following sections describe the user experience for the Password Reset service.

Customizing Password Reset

Once the Password Reset service has been enabled and the attributes defined by the administrator, users are able to log into the OpenSSO Enterprise console in order to customize their secret questions.

手順To Customize Password Reset

  1. The user logs into the OpenSSO Enterprise console, providing Username and Password and is successfully authenticated.

  2. In the User Profile page, the user selects Password Reset Options. This displays the Available Questions Answer Screen.

  3. The user is presented with the available questions that the administrator defined for the service, such as:

    • What is your pet’s name?

      • What is your favorite TV show?

      • What is your mother’s maiden name?

      • What is your favorite restaurant?

  4. The user selects the secret questions, up to the maximum number of questions that the administrator defined for the realm (the maximum amount is defined the Password Reset Service). The user then provides answers to the selected questions. These questions and answers will be the basis for resetting the user’s password (see the following section). If the administrator has selected the Personal Question Enabled attribute, text fields are provided, allowing the user to enter a unique secret question and provide an answer.

  5. The user clicks Save.

Resetting Forgotten Passwords

In the case where users forget their password, OpenSSO Enterprise uses the Password Reset web application to randomly generate new passwords and notify the user of the new password. A typical forgotten password scenario follows:

手順To Reset Forgotten Passwords

  1. The user logs into the Password Reset web application from a URL given to them by the administrator. For example:

    http://hostname:port /uri/password (for the default realm)

    or

    http://hostname:port/deploy_uri /ui/PWResetUserValidation?realm=realmname, where realmname is the name of the realm.

    Note –

    If the Password Reset service is not enabled for a parent realm but is enabled for a sub-realm, users must use the following syntax to access the service:


    http://hostname: port/deploy_uri/ui/PWResetUserValidation?realm=realmname

  2. The user enters the user ID.

  3. The user is presented with the personal questions that were defined in the Password Reset service and select by the user during customization. If the user has not previously logged into the User Profile page and customized the personal questions, the password will not be generated.

    Once the user answers the questions correctly, the new password is generated and emailed to the user. Attempt notification is sent to the user whether the questions are answered correctly or not. Users must have their email address entered in the User Profile page in order for the new password and attempt notification to be received.

Chapter 14 Logging Service

OpenSSO Enterprise provides a Logging Service to record information such as user activity, traffic patterns, and authorization violations. In addition, the debug files allow administrators to troubleshoot their installation.

Log Files

The log files record a number of events for each of the services. These files should be checked by the administrator on a regular basis. The default directory for the log files is ConfigurationDirectory/uri/log/, where ConfigurationDirectory is the configuration directory, and uri is the OpenSSO deployment URI specified during OpenSSO configuration and deployment time. These tags are interpreted at run time, such that each deployed OpenSSO instance has its own logging directory. This is particularly useful when there are multiple OpenSSO instances per system. The log file directory can be configured in the Logging Service by using the OpenSSO Enterprise console or ssoadm command-line utility. An absolute path may also be configured as the log file directory.

See Chapter 15, Recording Events with the Logging Service, in Sun OpenSSO Enterprise 8.0 Technical Overview for a detailed list of the default log file types, the information that is recorded, and log file formats.

For attribute definitions for the Logging Service, see the online help by clicking the Help button in the OpenSSO Enterprise Console or Logging in Sun OpenSSO Enterprise 8.0 Administration Reference.

OpenSSO Enterprise Logs

There are two different types of service log files: access and error. Access log files may contain records of action attempts and successful results. Error log files record errors that occur within the OpenSSO Enterprise services. Flat log files are appended with the .error or .access extension. Database column names end with _ERROR or _ACCESS for an Oracle database, or _error or _access for MySQL databases. For example, a flat file logging console events is named amConsole.access, while a database column logging the same events is named AMCONSOLE_ACCESS. The following sections describe the log files recorded by the Logging Service.

Session Logs

The Logging Service records the following events for the Session Service:

  • Login

  • Logout

  • Session Idle TimeOut

  • Session Max TimeOut

  • Failed To Login

  • Session Reactivation

  • Session Destroy

The session logs are prefixed with amSSO.

Console Logs

The OpenSSO Enterprise console logs record the creation, deletion, and modification of identity-related entities, policies, and services including, among others, realms, users, policies, and groups. It also records modifications of user attributes including passwords and the addition of users to or removal from groups. Additionally, the console logs record delegation and data store activities. The console logs are prefixed with amConsole.

Authentication Logs

Authentication component logs user logins and logouts. The authentication logs are prefixed with amAuthentication.

Federation Logs

The Federation component logs federation-related events including, but not limited to, the creation of a circle of trust and the creation of a Hosted Provider. The federation logs are prefixed with amFederation.

Policy Logs

The Policy component records policy-related events including, but not limited to, policy administration (policy creation, deletion and modification) and policy evaluation. The policy logs are prefixed with amPolicy.

Agent Logs

The policy agent logs are responsible for logging exceptions regarding log resources that were either allowed or denied to a user. The agent logs are prefixed with amAgent. amAgent logs reside on the agent server only. Agent events are logged on the OpenSSO Enterprise server in the Authentication Logs. For more information on this function, see the documentation for the policy agent in question.

SAML Logs

The SAML component records SAML-related events including, but not limited to, assertion and artifact creation or removal, response and request details, and SOAP errors. The session logs are prefixed with amSAML.

ssoadm Logs

The ssoadm logs record events that occur during operations using the ssoadm command line tool. These include operations that have OpenSSO administration console equivalents. The ssoadm command line logs are located in the logging directory specified when running the setup script for the administration tools unzipped from ssoAdminTools.zip. The main logs are prefixed with ssoadm; other task-related log files are also have access and error suffixes.

Logging Features

The Logging Service has a number of special features which can be enabled for additional functionality.

Secure Logging

This optional feature adds additional security to the logging function. Secure Logging enables detection of unauthorized changes to, or tampering of, the security logs. No special coding is required to leverage this feature. Secure Logging is accomplished by using a preregistered certificate configured by the system administrator. A Manifest Analysis and Certification (MAC) is generated and stored for every log record. A special signature log record is periodically inserted that represents the signature for the contents of the log written to that point. The combination of the two records ensures that the logs have not been tampered with. There are two methods to enable secure logging; through a through a Java Cryptography Extension (JCE) provider and through a Java Security Server (JSS) provider.

Note –

Secure logging can only be used for flat files. This option does not work for Database (DB) logging.

手順To Enable Secure Logging through a JSS Provider

  1. Create a certificate with the name Logger and install it in the key store specified by the Logging Service configuration's Logging Certificate Store Location.

    The key store's password is expected to be the same as the top-level administrator password. The default location set during OpenSSO Enterprise configuration time is ConfigurationDirectory/uri/Logger.jks/, where ConfigurationDirectory is the configuration directory, and uri is the OpenSSO deployment URI specified during OpenSSO configuration and deployment time. These tags are interpreted at run time, such that each deployed OpenSSO instance has its own key store. It is particularly useful when there are multiple OpenSSO instances per system. Information on getting certificates can be found in Obtaining Secure Socket Layer Certificates in Deployment Example: Single Sign-On, Load Balancing and Failover Using Sun OpenSSO Enterprise 8.0.

  2. Turn on Secure Logging in the Logging Service configuration using the OpenSSO Enterprise administration console and save the change. The administrator can also modify the default values for the other Logging Service attributes.

    If the logging directory is changed from the default /log directory, make sure that the directory is writable by the user ID and that the OpenSSO Enterprise's web application is running. Also set the directory's permissions to 0700, as the logging service will create the directory, if it does not exist, with permissions set to 0755.

  3. Verify Secure Log Archives.

    To detect unauthorized changes or tampering of the secure logs, look for error messages that are written by the Logging Service's periodic verification process to ConfigurationDirectory/uri/debug/amLog. To manually check for tampering, run the amverifyarchive command-line utility, which is included in the ssoAdminTools.zip file.

  4. Changing from a JCE Provider to a JSS Provider

    The default secure log helper provider is the JCE provider, com.sun.identity.log.secure.impl.SecureLogHelperJCEImpl, as specified by the iplanet-am-logging-secure-log-helper attribute in the iPlanetAMLoggingService's schema. Refer to the opensso/xml/amLogging.xml file from the opensso.zip file.

    To change to the JSS provider, use the ssoadm command-line utility:

    ./ssoadm set-attr-defs --servicename iPlanetAMLoggingService --schematype global --attributevalues iplanet-am-logging-secure-log-helper-class-name= com.sun.identity.log.secure.SecureLogHelperJSSImpl --adminid amadmin --password-file amadminpass

    To verify the change:

    ./ssoadm get-attr-defs --servicename iPlanetAMLoggingService --attributenames iplanet-am-logging-secure-log-helper-class-name --schematype global --adminid amadmin --password-file amadminpass

Logging Level Attributes and Properties

There are attributes in the Logging Service configuration that affect logging output. The Log Status can be set to Inactive to disable all logging output. The Logging Level can be set to one of the java.util.logging.Level values other than the default INFO to get more or less detailed logging output.

Additionally, an individual log file's logging level can be specified in the Configuration > Servers and Sites > server-name > Advanced page. For a given log file, for exampleamSAML.access, add a property name, iplanet-am-logging.amSAML.access.level with Property Value FINER (or any of the java.util.logging.Levelvalues). The logging level specified here for the log file will take precedence over the Logging Service's Logging Level setting.

Database Logging

This feature provides logging to Oracle or MySQL databases. No special coding is required to enable this feature. In the Logging Service configuration (Configuration > System > Logging), set the Logging Type to DB, set the Database User Name, Database User Password, and Database Driver Name. The default driver name is set for Oracle, oracle.jdbc.driver.OracleDriver. For MySQL, it is typically com.mysql.jdbc.Driver. Be sure to put the JDBC driver's .zip or .jar file in the OpenSSO Enterprise web app's classpath (e.g., WEB-INF/lib, jre/lib/ext).

The DB Failure Memory Buffer Size specifies how many records per table to buffer if the connection to the database fails. If more records are queued before the connection is reestablished, older records will be discarded.

Remote Logging

OpenSSO Enterprise supports remote logging. This allows a remote client application using the OpenSSO client SDK, or another OpenSSO Enterprise server (in the same Site) to use an OpenSSO Enterprise server's Logging Services.

Remote Client Logging

A remote client using the OpenSSO Enterprise client SDK may log to an OpenSSO Enterprise server. For example, the OpenSSO Enterprise client sdk samples refer to the samples/sdk/resources/AMConfig.properties set up by the samples/sdk/scripts/setup.sh script. In particular, the com.iplanet.am.naming.url property's value points to the target OpenSSO Enterprise server's Naming service, which provides the location of the Logging Service. In order for the remote client to successfully log to the target OpenSSO Enterprise server, the entity making the logging request must have Log Writing permission on the target OpenSSO Enterprise server.

Remote OpenSSO Enterprise Server Logging

Another OpenSSO Enterprise server may use an OpenSSO Enterprise server's Logging Services if both are in the same Site. The remote OpenSSO Enterprise server sets its Logging Service URL in the administration console (Configuration > System > Naming) to the target OpenSSO Enterprise server's Logging Service, by changing the attribute's protocol, host, port, and uri values accordingly. Logginservice does not usually need to be changed.

Debug Files

The debug files are not a feature of the Logging Service. They are written using different APIs which are independent of the logging APIs. Debug files are stored in ConfigurationDirectory/uri/debug. This location, along with the level of the debug information, is configurable through the OpenSSO Enterprise Console. Go to Configuration > Sites and Servers >server-name > General and edit the Debug Directory attribute.

Debug Levels

There are several levels of information that can be recorded to the debug files. The debug level is set using the Debug Level attribute located at Configuration > Sites and Servers >server-name > General.

  1. Off: No debug information is recorded.

  2. Error: This level is used for production. During production, there should be no errors in the debug files.

  3. Warning: This level allows Error and Warning debug messages to be written.

  4. Message: This level allows detailed code tracing.

    Note –

    Warning and Message levels should not be used in production. They cause severe performance degradation and an abundance of debug messages.

Debug Output Files

By default there are separate debug files, corresponding to the major service components of OpenSSO Enterprise:

  • Authentication

  • CoreSystem

  • amAuthContextLocal

  • WebServices

  • IDRepo

  • Policy

  • Configuration

  • Session

  • Federation

Debug output can be combined into one file through the administration console (Configuration > Sites and Servers > server-name > General. Turn the Merge Debug Files attribute to ON.

Chapter 15 Backing Up and Restoring Configuration Data

OpenSSO Enterprise creates and manages configuration and service management data in the embedded configuration datastore. If this data becomes corrupt or if some of it is missing, OpenSSO Enterprise will not function properly. Because of this, it is recommended that you backup your configuration datastore on a regular basis. Thus, in the event of a machine crash or other corrupting influence, you can restore the configuration data to its previous, non-corrupt state. This chapter describes the backup and restore procedures for the OpenSSO Enterprise server configuration data and contains the following sections.

Understanding Backup and Restore

OpenSSO Enterprise supports the following types of configuration datastores:

Caution – Caution –

The procedures in this chapter do not apply to the user datastore.

  • Embedded configuration datastore: Configuration data is stored on the server local to the instance of OpenSSO Enterprise with an exposed LDAP port. This is the default datastore installed during initial configuration of OpenSSO Enterprise.

  • Sun Directory Server configuration datastore: Configuration data is stored in an instance of Sun Directory Server, which can be selected and configured during initial configuration of OpenSSO Enterprise.

The backup and restore procedures are dependent on the following:

  • The OpenSSO Enterprise bits are not corrupted.

  • The backup and restore procedures described in this document pertain only to the service configuration information stored in the defined configuration datastore. All other product files (including the bootstrap file, debug/log files, and key store files) are in the configuration directory defined during deployment (for example, /opensso) and are NOT in the scope of the these procedures.

  • All of the restore options provided require the OpenSSO Enterprise web application to be re-configured thus, it is assumed that some configuration parameters will have to be used during the product reconfiguration. As long as the original system-generated configuration file .configParam (created as the result of a successful OpenSSO configuration and located in the configuration directory defined during OpenSSO Enterprise deployment; by default /opensso) is backed up, the information in it can be used to create a configuration file for use as input to the command-line configurator. For more information, see Chapter 5, Configuring OpenSSO Enterprise Using the Command-Line Configurator, in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.

  • After OpenSSO Enterprise is successfully configured, it is assumed that no OpenDS interface or any other utility is used directly to manipulate the configuration data store.

Backing Up the Configuration Datastore

To Backup the Configuration Datastore describes how to back up the data contained the configuration datastore.

手順To Backup the Configuration Datastore

Before You Begin

Make sure that the configuration datastore is running, but there are no write procedures being sent to the configuration datastore.

  1. Export the service configuration data to an XML file using the ssoadm command line utility option export-svc-cfg. For example:

    $ cd sso_tools_dir

    $ ./ssoadm export-svc-cfg –u username –f password file location –e key to encyrpt password –o XML-backup-file

    Note –

    If multiple servers are configured to share the same configuration store, the step is only required to be executed once on one of the servers.

  2. Move XML-backup-file (from the previous step) to a secure location.

    It is recommended to also create an MD5 hash of this file and to store it in a secure location. Use the hash file for future verification.

Restoring the Configuration Data Store

It contains the following procedures:

This section contains instructions to restore saved configuration data to the OpenSSO Enterprise configuration data store or the Directory Server configuration data store. Restoration of the configuration data can be done by loading an XML file or through directory replication. There are two methods to restore the configuration data for the OpenSSO configuration data store:

Loading XML

Use this option if there is only one OpenSSO Enterprise instance and it is corrupted or, multiple servers are configured to share the same configuration datastore and all instances are corrupted.

Directory Replication

Use this option in the case where multiple OpenSSO Enterprise instances are configured to share the same configuration datastore and at least one of the instances is uncorrupted.

This section contains the following procedures.

手順To Restore the Embedded Configuration Datastore by Loading XML

Use this option if there is only one OpenSSO Enterprise instance and it is corrupted or, multiple servers are configured to share the same configuration datastore and all instances are corrupted. If multiple instances of OpenSSO Enterprise are configured to share the same configuration datastore, repeat steps 1 through 4 on each instance first and then do step 5 and step 6.

  1. Stop all instances of OpenSSO Enterprise.

  2. Remove all files and directories from the existing configuration directory.

    $ rm -rf configuration_directory

  3. Restart all instances of OpenSSO Enterprise.

  4. Reconfigure the OpenSSO Enterprise web application by accessing the OpenSSO Enterprise configurator.

    All configuration attributes must be redefined as they were originally defined. For the configuration of the second and all succeeding OpenSSO Enterprise instances, choose the Add to Existing Deployment option during configuration and point it to the first instance.

  5. Import the saved service configuration data to the configuration datastore using the ssoadmin command line utility option import-svc-cfg.

    ./ssoadm import-svc-cfg -u username -f password_file_location -e key_to_enctrypt_password -X backup_xml_file

    In the case of the multiple server configuration, this step only needs to be done once.

  6. Restart all OpenSSO Enterprise instances.

手順To Restore by Replication of the OpenSSO Configuration Data store

Before You Begin

Use this option in the case where multiple OpenSSO Enterprise instances are configured to share the same configuration datastore and at least one of the instances is uncorrupted.

  1. Log in to the console of an uncorrupted instance of OpenSSO Enterprise as administrator.

  2. Remove the corrupted OpenSSO Enterprise instance(s) from the platform server list.

    The de-provisioning of the OpenSSO configuration datastore node will take effect after all the OpenSSO servers are restarted.

  3. Remove all files and directories from the existing configuration directory for all corrupted instances of OpenSSO Enterprise.

    $ rm -rf configuration_directory

  4. Restart all instances of OpenSSO Enterprise including those that are corrupted.

  5. Reconfigure the OpenSSO Enterprise web application on the corrupted OpenSSO Enterprise instance by accessing the OpenSSO Enterprise configurator.

    All configuration attributes must be redefined as they were originally defined.

  6. Import the saved service configuration data to the configuration datastore using the ssoadm command line utility option import-svc-cfg.

    ./ssoadm import-svc-cfg -u username -f password_file_location -e key_to_enctrypt_password -X backup_xml_file

    In the case of the multiple server configuration, this step only needs to be done once.

  7. Restart all OpenSSO Enterprise instances.

手順To Restore the Directory Server Configuration Datastore by Loading XML

Use this option if there is only one OpenSSO Enterprise instance and it is corrupted or, multiple servers are configured to share the same configuration datastore and all instances are corrupted. If multiple instances of OpenSSO Enterprise are configured to share the same configuration datastore, repeat steps 1 through 4 on each instance first and then do step 5 and step 6.

  1. Stop all OpenSSO Enterprise instances.

  2. Remove all files and directories from the existing configuration directory.

    $ rm -rf configuration_directory

  3. Confirm that the Directory Server configuration datastore is up and running with no OpenSSO Enterprise service configuration.

  4. Reconfigure the OpenSSO Enterprise web application by accessing the OpenSSO Enterprise configurator.

    All configuration attributes must be redefined as they were originally defined. For the configuration of the second and all succeeding OpenSSO Enterprise instances, choose the Add to Existing Deployment option during configuration and point it to the first instance.

  5. (Optional) Repeat these steps on each instance of OpenSSO Enterprise that is configured to share the same Directory Server configuration datastore.

  6. Import the saved service configuration data to the configuration datastore using the ssoadmin command line utility option import-svc-cfg.

    ./ssoadm import-svc-cfg –u username -f password_file_location –e key_to_enctrypt_password -X backup_xml_file

    In the case of the multi-server configuration, this step only needs to be done once.

  7. Restart all OpenSSO Enterprise instances.

手順To Restore by Replication of the Directory Server Configuration Datastore

Before You Begin

Use this option in the case where multiple OpenSSO Enterprise instances are configured to share the same configuration datastore and at least one of the instances is uncorrupted.

  1. Log in to the console of an uncorrupted instance of OpenSSO Enterprise as administrator.

  2. Remove the corrupted OpenSSO Enterprise instance(s) from the platform server list.

    The de-provisioning of the OpenSSO configuration datastore node will take effect after all the OpenSSO servers are restarted.

  3. Remove all files and directories from the existing configuration directory for all corrupted instances of OpenSSO Enterprise.

    $ rm -rf configuration_directory

  4. Restart all of the OpenSSO Enterprise servers including those that are corrupted.

  5. Reconfigure the OpenSSO Enterprise web application by accessing the OpenSSO Enterprise configurator.

    All configuration attributes must be redefined as they were originally defined.

  6. Import the saved service configuration data to the configuration datastore using the ssoadm command line utility option import-svc-cfg.

    ./ssoadm import-svc-cfg -u username -f password_file_location -e key_to_enctrypt_password -X backup_xml_file

    In the case of the multi-server configuration, this step only needs to be done once.

  7. Restart all OpenSSO Enterprise instances.