Part III Directory Management and Default Services
This is part three of the Sun Java System Access Manager 7 2005Q4
Administration Guide. The Directory Management chapter describes how
to manage Directory objects when Access Manager is deployed in Legacy
Mode. The other chapters describe how to configure and use some of
Access Manager's default services. This part contains the following
chapters:
Chapter 10 Directory
Management
The Directory Management tab is only displayed when you install
Access Manager in Legacy mode. This directory management feature provides
an identity management solution for Sun Java System Directory Server-enabled
Access Manager deployments.
For more information on the Legacy Mode installation option, see the Sun Java Enterprise System 2005Q4 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 Access Manager 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 Access Manager. 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, Access Manager dynamically creates a top-level organization
(defined during installation) to manage the Access Manager 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
-
Click the Directory Management tab.
-
In the Organizations list, click New.
-
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/amserver/UI/Login?org=exampleorg
http://machine.example.com/amserver/UI/Login?org=abc
http://machine.example.com/amserver/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/amserver/UI/
Login?org=exampleorg
http://machine.example1.com/amserver/
UI/Login?org=exampleorg
http://machine.example2.com/amserver/
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 the following list of attribute names:
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 that URL.
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.
-
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
-
Select the checkbox next to the name of the organization to be
deleted.
-
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
Access Manager 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 Managing Policies.
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 Access Manager container entry
and the Access Manager 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
-
Select the location link of the organization or container where
the new container will be created.
-
Click the Containers tab.
-
Click New in the Containers list.
-
Enter the name of the container to be created.
-
Click OK.
To Delete a Container
-
Click the Containers tab.
-
Select the checkbox next to the name of the container to be deleted.
-
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
-
Select the location link of the organization or the group container
which will contain the new group container.
-
Select the Group Containers tab.
-
Click New in the Group Containers list.
-
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
-
Navigate to the organization which contains the group container
to be deleted.
-
Choose the Group Containers tab.
-
Select the checkbox next to the group container to be deleted.
-
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.
Access Manager 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 –
Access Manager 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 System Access Manager 6 2005Q1 Migration Guide.
To Create a Static Group
-
Navigate to the organization, group, or group container where
the new group will be created.
-
From the Groups list, click New Static.
-
Enter a name for the group in the Name field. Click Next.
-
Select the Users Can Subscribe to this Group attribute to allow
users to subscribe to the group themselves.
-
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
-
From the Groups list, select the group to which you will add members.
-
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 “*” 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 member(s) 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 member(s) you wish to delete and choose Delete Members.
To Create a Dynamic Group
-
Navigate to the organization or group where the new group will
be created.
-
Click the Groups tab.
-
Click New Dynamic.
-
Enter a name for the group in the Name field.
-
Construct the LDAP search filter.
By default, Access
Manager 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.
-
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
-
Form the Groups list, click the name of the group to which you
will add members.
-
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 “*” 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 member(s) you wish to remove
and choose Remove Members
- Delete Members
-
This action will permanently delete the member you select.
Select the member(s) you wish to delete and choose Delete Members.
To Add a Group to a Policy
Access Manager 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 Managing Policies.
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
-
Navigate to the organization or people container where the new
people container will be created.
-
Click New from the People Container list.
-
Enter the name of the people container to be created.
-
Click OK.
To Delete a People Container
-
Navigate to the organization or people container which contains
the people container to be deleted.
-
Select the checkbox next to the name of the people container to
be deleted.
-
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 Access Manager 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
-
Navigate to the organization, container or people container where
the user is to be created.
-
Click the user tab.
-
Click New from the user list.
-
Enter data for the following values:
- User ID
-
This field takes the name of the user with which he or she
will log into Access Manager. 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 Access manager. Only active users can authenticate. The default value
is Active.
-
Click OK.
To Edit the User Profile
When a user who has not been assigned an administrative role authenticates
to the Access Manager, 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 Access Manager Developer's Guide.
-
Select the user who's profile is to be edited. By default, the
General view is displayed.
-
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 Access Manager. Only active users can authenticate through Access
Manager. The default value is Active. Either of the following can be selected
from the pull-down menu: .
-
Active — The user can authenticate through Access Manager.
-
Inactive — The user cannot authenticate through Access
Manager, but the user profile remains stored in the directory.
Note –
Changing the user status to Inactive only affects authentication
through Access Manager. The Directory Server uses the nsAccountLock attribute to determine user account status. User accounts inactivated
for Access Manager authentication can still perform tasks that do not require
Access Manager. To inactivate a user account in the directory, and not just
for Access Manager authentication, set the value of nsAccountLock to false. If delegated administrators at your site will be inactivating
users on a regular basis, consider adding the nsAccountLock attribute
to the Access Manager User Profile page. See the Sun Java System Access Manager 7 2005Q4 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
-
Click the Users tab.
-
Click the name of the user you wish to modify.
-
Select either the Roles or Groups tab.
-
Select the role or group to which you wish to add the user and
click Add.
-
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
Access Manager 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 Managing Policies.
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 Access Manager 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 Access Manager console. Other
Directory Server types can be used in a policy’s subject definition.
For more information on policy subjects, see Creating Policies.
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.
Access Manager uses roles to apply access control instructions. When
first installed, Access Manager 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 –
Access Manager 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 System Access Manager 6 2005Q1 Migration Guide.
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
-
Go to the organization where the Role will be created.
-
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 Access Manager, 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 Access Manager 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 Access Manager 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.
-
Click the New Static button.
-
Enter a name for the role.
-
Enter a description of the role.
-
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 Access Manager
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.
-
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
-
Click the name of the role to which you wish to add users.
-
In the Members list, select Add User from the Select Action menu.
-
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)
-
Click Next to begin the search. The results of the search are
displayed.
-
Choose the users from the names returned by selecting the checkbox
next to the user name.
-
Click Finish.
The Users are now assigned to the role.
To Create a Dynamic Role
-
Go to the organization where the Role will be created.
-
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 Access Manager, 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 Access Manager 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 Access Manager 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.
-
Click the New Dynamic button.
-
Enter a name for the role.
-
Enter a description for the role.
-
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 Access Manager
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.
-
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.
-
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)
-
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
-
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.
-
Select the role to modify.
-
Choose Users from the View menu.
-
Select the checkbox next to each user to be removed.
-
Click Remove user from the Select Action menu.
The
users are now removed from the role.
To Add a Role to a Policy
Access Manager 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 Managing Policies.
Chapter 11 Current Sessions
This chapter describes the session management features of Access Manager. 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 Access Manager.
Session Management
The Session Management frame displays the name of the Access Manager that is
currently being managed.
Session Information
The Session Information window displays all of the users who are currently logged
into Access Manager, 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
-
Select the user session that you wish to terminate.
-
Click Terminate.
Chapter 12 Password Reset Service
Access Manager provides a Password Reset service to allow users to reset their
password for access to a given service or application protected by Access Manager.
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.
This chapter contains the following sections:
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
-
Navigate to the realm to which you will register the password for the
user.
-
Click the realm name and click the Services tab.
If it has
not been added to the realm, click the Add button.
-
Select the r Password Reset and click Next
The Password Reset
service attributes will be displayed. For attribute definitions, see the online help.
-
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
-
Select the realm for which the Password Reset service is registered.
-
Click the Services tab.
-
Click Password Reset from the services list.
-
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.
Note –
Access Manager automatically installs the Password Reset web application
for random password generation. However, you can write your own plug-in classes for
password generation and password notification. See the following Readme.html files
in the following locations for samples for these plug-in classes.
PasswordGenerator:
AccessManager-base/SUNWam/samples/console/PasswordGenerator
|
NotifyPassword:
AccessManager-base/SUNWam/samples/console/NotifyPassword
|
-
Select the Personal Question Enabled attribute if the user is to define
his/her unique personal questions. Once the attributes are defined, click Save.
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 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 for a description
of the service attributes.
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 Access Manager console in order
to customize their secret questions.
To Customize Password Reset
-
The user logs into the Access Manager console, providing Username and
Password and is successfully authenticated.
-
In the User Profile page, the user selects Password Reset Options. This
displays the Available Questions Answer Screen.
-
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?
-
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.
-
The user clicks Save.
Resetting Forgotten Passwords
In the case where users forget their password, Access Manager 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
-
The user logs into the Password Reset web application from a URL given
to them by the administrator. For example:
http://hostname:port /ampassword (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
|
-
The user enters the user id.
-
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.
Password Policies
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 following Directory
Server documentation:
http://docs.sun.com/source/816-6700-10/aci.html#14773
http://docs.sun.com/source/816-6698-10/useracct.html#14386
Chapter 13 Logging
Service
Sun Java™ System Access Manager 7 2005Q4 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 it
monitors. These files should be checked by the administrator on a regular
basis. The default directory for the log files is /var/opt/SUNWam/logs for SPARC systems and /var/opt/sun/identity for
Linux systems. The log file directory can be configured in the Logging Service
by using the Access Manager console.
See How the Logging Feature Works in Sun Java System Access Manager 7 2005Q4 Technical Overview in the
Sun Java System Access Manager 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 Access Manager Console.
Access Manager Service 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 Access Manager services.
Flat log files are appended with the .error or .access extension. Database column names end with _ERROR or _ACCESS for Oracle databases, 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 Access Manager console logs record the creation, deletion and modification
of identity-related objects, policies and services including, among others,
organizations, organizational units, users, roles, policies and groups. It
also records modifications of user attributes including passwords and the
addition or removal of users to or from roles and groups. Additionally, the
console logs write 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 an Authentication Domain 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 Access Manager
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.
amAdmin Logs
The command line logs record event errors that occur during operations
using the command line tools. These include, but are not limited to, loading
a service schema, creating policy and deleting users. The command line logs
are prefixed with amAdmin.
Logging Features
The Logging Service has a number of special features which can be enabled
for additional functionality. They include To Enable Secure Logging, Command
Line Logging and Remote Logging.
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 pre-registered certificate configured
by the system administrator. This 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.
To Enable Secure Logging
-
Create a certificate with the name Logger and
install it in the deployment container running Access Manager. See the documentation
for the deployment container for details.
-
Turn on Secure Logging in the Logging Service configuration using
the Access Manager console and save the change. The administrator can also
modify the default values for the other attributes in the Logging Service.
If the logging directory is changed from the default (/var/opt/SUMWam/logs), make sure that the permissions are set to
0700. The logging service will create the directory, if it does not exist,
but it will create the directory with permissions set to 0755.
Additionally, if you specify a different directory from the default, you must
change the following parameter to the new directory in the web container's
server.policy file:
permission
java.io.FilePermission “/var/opt/SUNWam/logs/*”,”delete,write”
-
Create a file in the AccessManager-base/SUNWam/config directory that contains the certificate
database password and name it .wtpass.
Note –
The file name and the path to it is configurable in the AMConfig.properties file. For more information see the "Certificate
Database" in Appendix A, AMConfig.properties File.
Ensure that the deployment container user is the
only administrator with read permissions to this file for security reasons.
-
Restart the server.
The secure log directory should
be cleared, as some misleading verification errors may be written to the /var/opt/SUNWam/debug/amLog file when the secure logging was started.
To detect unauthorized changes or tampering of the security logs,
look for error messages that are written by the verification process to /var/opt/SUNWam/debug/amLog. To manually check for tampering, run
the VerifyArchive utility. See Chapter 19, The VerifyArchive Command Line Tool for more information.
Command Line Logging
The amadmin command line tool has the ability to
create, modify and delete identity objects (organizations, users, and roles,
for example) in Directory Server. This tool can also load, create, and register
service templates. The Logging Service can record these actions by invoking
the -t option. If the com.iplanet.am.logstatus property in AMConfig.properties is enabled
(ACTIVE) then a log record will be created. (This property is enabled by default.)
The command line logs are prefixed with amAdmin. See Chapter 14, The amadmin Command Line Tool for
more information.
Logging Properties
There are properties in the AMConfig.properties file
that affect logging output:
-
com.iplanet.am.logstatus=ACTIVE
-
This property will enable or disable logging. The default
is ACTIVE.
-
iplanet-am-logging.service.level= level
-
service is
the service's normal debug file name. level is
one of the java.util.logging.Level values and denotes
the level of detail recorded in the logs. The levels are SEVERE, WARNING,
INFO, CONFIG, FINE, FINER, and FINEST. Most services do not record log levels
with higher detail than INFO.
Remote Logging
Access Manager supports remote logging. This allows a client application
using a host where the Access Manager SDK is installedto create log records
on an instance of Access Manager deployed on a remote machine. Remote logging
can be initiated in any of the following scenarios:
-
When the logging URL in the Naming Service of one Access Manager
instance points to a remote instance and there is a trust relationship configured
between the two, logs will be written to the remote Access Manager instance.
-
When the Access Manager SDK is installed against a remote
Access Manager instance and a client (or a simple Java class) running on the
SDK server uses the logging APIs, the logs will be written to the remote Access
Manager machine.
-
When logging APIs are used by Access Manager agents.
To Enable Remote Logging
-
If using Sun Java System Web Server, the following environment
variables need to be set in the server.xml configuration
file:
-
java.util.logging.manager=com.sun.identity.log.LogManager
-
java.util.logging.config.file=/AccessManager-base /SUNwam/lib/LogConfig.properties
-
If the Java™ 2 Platform, Standard Edition being used
is 1.4 or later, this is accomplished by invoking the following at the command
line:
java -cp /AccessManager-base /SUNWam/lib/am_logging.jar:/AccessManager-base /SUNWam/lib/xercesImpl.jar:/AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/AccessManager-base /SUNWam/lib/jaas.jar:/AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/AccessManager-base /SUNWam/lib/servlet.jar:/AccessManager-base /SUNWam/locale:/AccessManager-base/SUNWam/lib/am_services.jar:/ AccessManager-base/SUNWam/lib/am_sdk.jar:/ AccessManager-base/SUNWam/lib/jss311.jar:/ AccessManager-base/SUNWam/lib:.
-Djava.util.logging.manager=com.sun.identity.log.LogManager
-Djava.util.logging.config.file=/AccessManager-base /SUNwam/lib/LogConfig.properties
<logTestClass>
-
If the Java 2 Platform, Standard Edition being used is earlier
than 1.4, this is accomplished by invoking the following at the command line:
java -Xbootclasspath/a:/AccessManager-base /SUNWam/lib/jdk_logging.jar -cp /AccessManager-base /SUNWam/lib/am_logging.jar:/AccessManager-base /SUNWam/lib/xercesImpl.jar:/AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/AccessManager-base /SUNWam/lib/jaas.jar:/AccessManager-base /SUNWam/lib/xmlParserAPIs.jar:/AccessManager-base /SUNWam/lib/servlet.jar:/AccessManager-base /SUNWam/locale:/AccessManager-base/SUNWam/lib/am_services.jar:/ AccessManager-base/SUNWam/lib/am_sdk.jar:/ AccessManager-base/SUNWam/lib/jss311.jar:/ AccessManager-base/SUNWam/lib:.
-Djava.util.logging.manager=com.sun.identity.log.LogManager
-Djava.util.logging.config.file=/AccessManager-base /SUNwam/lib/LogConfig.properties
<logTestClass>
-
Ensure that the following parameters are configured in LogConfig.properties located in AccessManager-base/SUNWam/lib :
-
iplanet-am-logging-remote-handler=com.sun.identity.
log.handlers.RemoteHandler
-
iplanet-am-logging-remote-formatter=com.sun.
identity.log.handlers.RemoteFormatter
-
iplanet-am-logging-remote-buffer-size=1
Remote logging supports buffering on the basis of the number of log
records. This value defines the log buffer size by the number of records.
Once the buffer is full, all buffered records will be flushed to the server.
-
iplanet-am-logging-buffer-time-in-seconds=3600
This value defines the time-out period in which to invoke the log buffer-cleaner
thread.
-
iplanet-am-logging-time-buffering-status=OFF
This value defines whether log buffering (and the buffer-cleaner thread)
is enabled. By default this feature is turned off.
Note –
Whenever
a log file is empty, secure logging may show "verification failure." This
is because when the number of created files is equal to the archive size,
secure logging will archive from this set and start again. It most instances,
you can ignore this error. Once the number of records is equal to the archive
size, the error will not be displayed.
Error and Access Logs
Two types of Access Manager log files exist: access log files and error
log files.
Access log files record general auditing information concerning
the Access Manager deployment. A log may contain a single record for an event
such as a successful authentication. A log may contain multiple records for
the same event. For example, when an administrator uses the console to change
an attribute value, the Logging Service logs the attempt to change in one
record. Logging Service also logs the results of the execution of the change
in a second record.
Error log files record errors that occur within the application.
While an operation error is recorded in the error log, the operation attempt
is recorded in the access log file.
Flat log files are appended with the .error or .access extension. Database column names end with _ERROR or _ACCESS. For example, a flat file logging
console events is named amConsole.access while a database
column logging the same events is named AMCONSOLE_ACCESS or amConsole_access.
The following table provides a brief description of the log file
produced by each Access Manager component.
Table 13–1 Access Manager Component Logs
|
Component
|
Log Filename Prefix
|
Information Logged
|
|
Session
|
amSSO
|
Session management attributes values such as login time, logout time,
timeout limits.
|
|
Administration Console
|
amConsole
|
User actions performed through the administration console such as creation,
deletion and modification of identity-related objects, realms, and policies.
|
|
Authentication
|
amAuthentication
|
User logins and logouts.
|
|
Identity Federation
|
amFederation
|
Federation-related events such as the creation of an Authentication
Domain and the creation of a Hosted Provider. The federation logs are prefixed
with amFederation.
|
|
Authorization (Policy)
|
amPolicy
|
Policy-related events such as policy creation, deletion, or modification,
and policy evaluation.
|
|
Policy Agent
|
amAgent
|
Exceptions regarding resources that were either accessed by a user or
denied access to a user. amAgent logs reside on the server
where the policy agent is installed. Agent events are logged on the Access
Manager machine in the Authentication logs.
|
|
SAML
|
amSAML
|
SAML-related events such as assertion and artifact creation or removal,
response and request details, and SOAP errors.
|
|
Command-line
|
amAdmin
|
Event errors that occur during operations using the command line tools.
Examples are: loading a service schema, creating policy, and deleting users.
|
See Appendix C, Log File Reference for list and description of the Access Manager log files.
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 /var/opt/SUNWam/debug. This location, along
with the level of the debug information, is configurable in the AMConfig.properties file, located in the AccessManager-base/SUNWam/lib/ directory. For more information
on the debug properties, see Appendix A, AMConfig.properties File.
Debug Levels
There are several levels of information that can be recorded to the
debug files. The debug level is set using the com.iplanet.services.debug.level property in AMConfig.properties.
-
Off—No debug information is recorded.
-
Error—This level is used for production. During production,
there should be no errors in the debug files.
-
Warning—Currently, using this level is not recommended.
-
Message—This level alerts to possible issues using code
tracing. Most Access Manager modules use this level to send debug messages.
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
A debug file does not get created until a module writes to it. Therefore,
in the default error mode no debug files may be generated.
The debug files that get created on a basic login with the debug level set
to message include:
-
amAuth
-
amAuthConfig
-
amAuthContextLocal
-
amAuthLDAP
-
amCallback
-
amClientDetection
-
amConsole
-
amFileLookup
-
amJSS
-
amLog
-
amLoginModule
-
amLoginViewBean
-
amNaming
-
amProfile
-
amSDK
-
amSSOProvider
-
amSessionEncodeURL
-
amThreadManager
The most often used files are the amSDK, amProfile and all files pertaining to authentication. The information
captured includes the date, time and message type (Error, Warning, Message).
Using Debug Files
The debug level, by default, is set to error. The
debug files might be useful to an administrator when they are:
-
Writing a custom authentication module.
-
Writing a custom application using the Access manager SDKs.
The amProfile and amSDK debug files
capture this information.
-
Troubleshooting access permissions while using the console
or SDK. The amProfile and amSDK debug
files also capture this information.
-
Troubleshooting SSL.
-
Troubleshooting the LDAP authentication module. The amAuthLDAP debug file captures this information.
The debug files should go hand in hand with any troubleshooting guide
we might have in the future. For example when SSL fails, someone might turn
on debug to message and look in the amJSS debug file
for any specific certificate errors.
Multiple Access Manager Instances And Debug Files
Access Manager contains the ammultiserverinstall script
that can be used to configure numerous instances of the server. If the multiple
server instances are configured to use different debug directories, each individual
instance has to have both read and write permissions to the debug directories.
Dieses Buch im PDF-Format herunterladen (1965 KB)