Troubleshooting guide

24 1: Important RSA Authentication Manager 8.1 Changes
RSA Authentication Manager 6.1 to 8.1 Migration Guide
Policies and Security Domains
Security domains enforce system policies which control various aspects of a user’s
interaction with Authentication Manager, such as RSA SecurID PIN lifetime and
format, fixed passcode lifetime and format, password length, format, and frequency of
change.
Each security domain has the following assigned policies:
• Password policies
• Token policies
• Lockout policies
• Risk-based authentication policies
• Self-service troubleshooting policies
• Offline authentication policies
• Workflow policies
• Risk-based authentication message policies
When you create a new security domain, the default policy is automatically assigned,
or you can assign a custom policy. You can designate which policy is used as the
default, and you can change the default as needed.
Lower-level security domains do not inherit policies from upper-level security
domains. New security domains are assigned the default policy regardless of which
policy is assigned to security domains above them in the hierarchy. For example, if the
top-level security domain is assigned a custom policy, lower-level security domains
are still assigned the default policy.
Changes to User Groups
The ability to create hierarchies of security domains has lessened the need for groups
or user groups, as they are known in version 8.1. As a result, user groups no longer
function as they did in version 6.1.
User groups have the following characteristics:
• They can contain multiple users and user groups.
User groups in an external identity source can contain only users and user groups
belonging to the same identity source. User groups in the internal database can
contain users and user groups from any identity source in the deployment.
• They can encompass users and user groups that are managed in different security
domains. This means that users in security domain A and users in security domain
B can both be members of the same user group and thus access the same protected
resources.
Because any object in the deployment (users, user groups, agents, and so on) can
exist only in one security domain, you may encounter situations where the
privileges of the administrators of the security domain, in which the group resides,
do not allow them to see all members of the migrated group.
• A user can be a member of more than one user group.