6: Administering Users
151
RSA Authentication Manager 8.1 Administrator’s Guide
For more information, see the Security Console Help topic “Set Restricted Access 
Times for User Groups.”
Restricted Access Times for Users in Nested User Groups
In general, user groups nested in a parent group share the same restricted access times 
with the parent user group. However, when both the parent and the nested user groups 
are granted access to the same agent, time restrictions are combined in the same way 
that times are combined for users in multiple user groups.
For example, suppose that a user is a member of two user groups: Marketing and 
Sales. Marketing is nested within Sales, and both groups have access to the same 
restricted agent. If the restricted access time for members of Marketing is from 
8:00 a.m. to 5:00 p.m. and the restricted access time for members of Sales is from 
9:00 a.m. to 7:00 p.m., a member of Marketing can access the restricted agent from 
8:00 a.m. to 7:00p.m.
Access to Restricted Agents by Active Directory Groups
Active Directory supports multiple types of groups. When configured to use Active 
Directory as an identity source, Authentication Manager supports only Universal 
groups. 
When you select an Active Directory group for access on a restricted agent, make sure 
that you select a Universal group. If you use any other type of Active Directory group, 
the user may not be able to authenticate. When you view the Active Directory groups 
from the Security Console, the Security Console displays all groups, regardless of 
type. 
The Security Console cannot display a user’s primary Active Directory user group, 
such as Domain Users. The group appears empty even though it has members.
View User Groups Allowed to Authenticate on a Restricted Agent
Use the Security Console to view user groups that are allowed to authenticate on a 
restricted agent. User groups directly granted access to the restricted agent are only 
displayed in the search results. Nested user groups are not displayed.
Procedure
1. In the Security Console, click Access > Authentication Agents > Manage 
Existing.
2. Click the Restricted tab.
3. Use the search fields to find the agent whose user groups you want to view.
4. Click the agent, and select User Groups with Access.
5. Click the user group that you want to view, and select View.
Add pdf to powerpoint - SDK software service:C# Create PDF from PowerPoint Library to convert pptx, ppt to PDF in C#.net, ASP.NET MVC, WinForms, WPF
Online C# Tutorial for Creating PDF from Microsoft PowerPoint Presentation
www.rasteredge.com
Add pdf to powerpoint - SDK software service:VB.NET Create PDF from PowerPoint Library to convert pptx, ppt to PDF in vb.net, ASP.NET MVC, WinForms, WPF
VB.NET Tutorial for Export PDF file from Microsoft Office PowerPoint
www.rasteredge.com
152
6: Administering Users
RSA Authentication Manager 8.1 Administrator’s Guide
User Data in an LDAP Directory
Changes made to user data in an LDAP directory can affect authentication and 
administration of the user when the change in the directory modifies the user’s 
distinguished name (DN), the user’s User ID, or both. If a user’s DN or User ID is 
changed, Authentication Manager can no longer find the user in the LDAP directory 
that was designated as his or her identity source. A user (or a user group) in this state 
is known as “unresolvable.” RSA recommends removing references to unresolvable 
users and user groups because unresolvable users count against the license user limit if 
they have assigned authenticators.
How a User Becomes Unresolvable
Unresolvable users are users that can no longer be found in the LDAP directory that 
was designated as their identity source.
A user becomes unresolvable for any of the following reasons:
• The user is deleted from the LDAP directory.
• The user is moved outside the scope of the base DN of the identity source.
• The user is moved outside the scope of all identity sources.
• The scope of the identity source is narrowed so that it no longer includes the user.
• The Search Filter of the identity source is modified so that it no longer contains 
the user.
• The user is moved to an identity source in the same physical directory using the 
delete and add method, and the Unique Identifier is configured to use the default 
value.
• The user is moved to an identity source in a different physical directory.
Users who become unresolvable are reported as missing from the identity source.
After cleaning up users who have been moved to a different identity source, you 
re-establish these users in Authentication Manager by enabling them for 
authentication, or assigning them administrative roles.
Some directory management tools move users by deleting and re-adding them to the 
directory. In these cases, Authentication Manager cannot find the users after the move 
when the default Unique Identifier is used. Deleting and adding the user back to the 
directory creates a new value for ObjectGUID, the default Unique Identifier. To 
maintain the same value for your users, configure a customized attribute as the Unique 
Identifier.
How a User Group Becomes Unresolvable
Unresolvable user groups are user groups that can no longer be found in the LDAP 
directory that was designated as their identity source.
A user group becomes unresolvable for any of the following reasons:
• The user group is deleted from an LDAP directory.
• The user group is moved.
SDK software service:C# PDF insert image Library: insert images into PDF in C#.net, ASP
C#.NET PDF SDK - Add Image to PDF Page in C#.NET. How to Insert & Add Image, Picture or Logo on PDF Page Using C#.NET. Add Image to PDF Page Using C#.NET.
www.rasteredge.com
SDK software service:VB.NET PDF insert image library: insert images into PDF in vb.net
VB.NET PDF - Add Image to PDF Page in VB.NET. Guide VB.NET Programmers How to Add Images in PDF Document Using XDoc.PDF SDK for VB.NET.
www.rasteredge.com
6: Administering Users
153
RSA Authentication Manager 8.1 Administrator’s Guide
• The scope of the identity source is narrowed so that it no longer includes the user 
group.
• The Search Filter of the identity source is modified so that it no longer contains 
the user group.
Manual Cleanup for Unresolvable Users
RSA recommends cleaning up unresolvable users for the following reasons:
• Unresolvable users count against the license user limit. After cleaning up 
unresolvable users, the count is reduced, and you can register more users in your 
deployment.
• Tokens assigned to unresolvable users remain assigned to them. After cleaning up 
unresolvable users, you can assign their tokens to other users.
If users are moved to an identity source in a different physical directory, reassign 
the tokens to the same users. You also need to reassign any fixed passcodes, 
on-demand tokencode settings, and administrative roles that users had prior to 
being moved. 
The manual cleanup process removes the association between the users in an LDAP 
directory and RSA-specific data in the internal database. For instructions, see Clean 
Up Unresolvable Users Manually
on page 153.
During a manual cleanup, RSA Authentication Manager generates a list of 
unresolvable users from linked identity sources. You can preview the users affected by 
the cleanup before removing all references to the users. By default, all unresolvable 
users in linked identity sources are cleaned up. A manual cleanup does not clean up 
user groups.
The manual cleanup process applies only to LDAP directory identity sources that are 
linked to the system. If an identity source is not linked, no users are unresolvable, and 
no manual cleanup is necessary.
Clean Up Unresolvable Users Manually
You can clean up unresolvable users manually on an as-needed basis. The cleanup 
process removes the association between the users in an LDAP directory and 
RSA-specific data in the internal database.
Before You Begin
You must be a Super Admin.
Procedure
1. In the Security Console, click Setup > Identity Sources > Clean Up 
Unresolvable Users.
2. Select the name of the identity source that you want to clean up, or select All.
SDK software service:VB.NET PDF Password Library: add, remove, edit PDF file password
VB: Add Password to PDF with Permission Settings Applied. This VB.NET example shows how to add PDF file password with access permission setting.
www.rasteredge.com
SDK software service:C# PDF Password Library: add, remove, edit PDF file password in C#
C# Sample Code: Add Password to PDF with Permission Settings Applied in C#.NET. This example shows how to add PDF file password with access permission setting.
www.rasteredge.com
154
6: Administering Users
RSA Authentication Manager 8.1 Administrator’s Guide
3. In the Grace Period field, do one of the following:
• If you want to clean up users who have been unresolvable for more than the 
specified number of days, select the checkbox.
• If you want to clean up users immediately when they are found to be 
unresolvable, clear the checkbox.
The Grace Period is used to prevent cleanup for any users and user groups that 
may have been mistakenly removed from the directory or moved to an OU out of 
scope of the identity source. You can specify how many days the users must be 
unresolvable before they are cleaned up, and take corrective action beforehand. 
By default, this field is enabled to clean unresolvable users after seven days.
4. Click Next.
The list of unresolvable users builds and displays in the Preview panel when 
complete. The Preview displays up to 500 results at a time. If you see exactly 500 
results, you may need to clean up additional users. In this case, RSA recommends 
running a report based on the Users and User Groups Missing From Identity 
Source report template to view a complete list of unresolvable users. For more 
information, see Add a Report
on page 340.
5. In the Preview pane, review the list of users. Click the column names to sort the 
list. If the list is empty, there are no unresolvable users.
6. Click Clean Up Now.
Important: 
You cannot cancel the cleanup. When you click Clean Up Now, 
all associations between the users and objects in the internal database are 
removed.
When the clean up process completes, the Configure Settings pane displays a 
success message.
Scheduling Cleanup for Unresolvable Users and User Groups
The scheduled cleanup job deletes references to unresolvable users and user groups 
from the internal database. 
The scheduled cleanup job runs against linked and unlinked identity sources and can 
be configured to run on a daily, weekly or monthly basis. The job is canceled if the 
number of unresolvable users exceeds the specified Cleanup Limit. The limit helps 
avoid accidentally disassociating a large number of users from their authentication 
data if changes are made to these users directly in an LDAP directory. The default 
limit is 50 users.
SDK software service:C# PDF Sticky Note Library: add, delete, update PDF note in C#.net
C#.NET PDF SDK - Add Sticky Note to PDF Page in C#.NET. Able to add notes to PDF using C# source code in Visual Studio .NET framework.
www.rasteredge.com
SDK software service:C# WinForms Viewer: Load, View, Convert, Annotate and Edit
allowed to load and view PowerPoint without Microsoft Office software installed, create PDF file, Tiff image and HTML file from PowerPoint, add annotations to
www.rasteredge.com
6: Administering Users
155
RSA Authentication Manager 8.1 Administrator’s Guide
RSA recommends cleaning up unresolvable users for the following reasons:
• Unresolvable users count against the license user limit. After cleaning up 
unresolvable users, the count is reduced, and you can register more users in your 
deployment.
• Tokens assigned to unresolvable users remain assigned to them. After cleaning up 
unresolvable users, you can assign their tokens to other users.
If users are moved to an identity source in a different physical directory, reassign 
the tokens to the same users. You also need to reassign any fixed passcodes, 
on-demand tokencode settings, and administrative roles that users had prior to 
being moved. 
RSA recommends scheduling a cleanup for the following reasons:
• Before deleting an identity source
To delete an identity source you must first unlink the identity source from the 
system, run the scheduled cleanup, and use the Operations Console to delete the 
identity source. The scheduled cleanup deletes all references to users and groups 
from the internal database that were associated with the unlinked identity source. 
For more information, see the Security Console Help topic “Unlink Identity 
Sources from the System.”
If you need to temporarily unlink an identity source (for example to add an 
associated Global Catalog) do not run a cleanup job. When you relink the identity 
source, all users from that identity source will be resolvable again. Authentication 
Manager will be able to locate those users as it did before the unlink operation.
• After narrowing the identity source scope
After you narrow the scope of an identity source, some users and user groups may 
become unresolvable and unable to authenticate. You must run the scheduled 
cleanup job after editing the identity source. When you run the job, make sure that 
you disable the Grace Period and Cleanup Limit if they are set, and re-enable 
those settings after this single cleanup runs.
You can use the following options to modify the cleanup process:
Cleanup Limit. The Cleanup Limit cancels the automated cleanup when more 
than the specified number of unresolvable users are found in the database. This 
limit helps prevent accidentally disassociating a large number of users from their 
authentication data if changes are made to these users directly in the identity 
source. 
When the cleanup is canceled, you can run the “Users and User Groups Missing 
From the Identity Source” report to see a list of unresolvable users. The list may 
contain users that you do not want to clean up. For example, these may be users 
who are mistakenly deleted from the directory or moved from location to another 
in the same directory.
Grace Period. The Grace Period restricts the cleanup to users who have been 
unresolvable for more than a specified number of days. Specifying a Grace Period 
gives you time to correct any unintended changes to users in the directory. For 
example, some users may have been deleted or moved accidentally.
SDK software service:C# HTML5 Viewer: Load, View, Convert, Annotate and Edit PowerPoint
load and view PowerPoint without Microsoft Office software installed, convert PowerPoint to PDF file, Tiff image and HTML file, as well as add annotations in
www.rasteredge.com
SDK software service:RasterEdge XDoc.PowerPoint for .NET - SDK for PowerPoint Document
Convert. Convert PowerPoint to PDF. Extract, copy and paste PowerPoint Pages. Annotation & Thumbnail. Add and burn annotation to PowerPoint.
www.rasteredge.com
156
6: Administering Users
RSA Authentication Manager 8.1 Administrator’s Guide
Use the Grace Period to avoid cleaning up users when any of the following actions 
occur accidentally in linked identity sources:
• A user is deleted.
• A user is moved to an organizational unit (OU) outside of any identity source 
in your deployment.
• A user’s name is changed.
Schedule a Cleanup Job
The schedule cleanup job repairs or deletes references to unresolvable users and user 
groups from the internal database. Unresolvable users are users whose designated 
identity source no longer contains any record of the user. When a user is moved to 
another identity within the same LDAP directory, the cleanup job repairs the 
references.
Procedure
1. In the Security Console, click Setup > Identity Sources > Schedule Cleanup.
2. To schedule the cleanup job to run, under Cleanup Status, select Enable 
scheduled cleanup of unresolvable users and user groups from linked identity 
sources, and all users and user groups from unlinked identity sources. By 
default, this checkbox is cleared, and the field is disabled.
If you disable a cleanup that you have configured, the next time that you access 
this page, all of the fields are reset to the default values and all of the 
configuration changes that you made previously are lost.
3. In the Cleanup Limit field, do one of the following:
• Leave the default.
By default, this field is enabled and the limit is 50 users. The limit must be a 
positive number greater than zero. The cleanup is canceled when more than a 
specified number of unresolvable or unlinked user references are found. The 
limit helps avoid accidentally disassociating a large number of users from 
their authentication and authorization data if changes are made to these users 
directly in their identity source.
• If you want to clean up all unresolvable users and user groups, clear the 
Cleanup Limit checkbox.
Important: 
Before you delete an identity source that is unlinked, clear this 
checkbox when you run the cleanup.
4. In the Grace Period field, do one of the following:
• Leave the default.
By default this field is enabled and set to seven days. This value must be a 
positive number greater than zero. This field is ignored for unlinked identity 
sources. Only users who have been unresolvable for more than the specified 
number of days are cleaned. This field helps prevent the cleanup of users that 
may have been mistakenly removed from the directory or moved to an OU out 
of scope of the identity source. You have an opportunity to take corrective 
action before the cleanup.
6: Administering Users
157
RSA Authentication Manager 8.1 Administrator’s Guide
• If you want to clean users immediately when they are found to be 
unresolvable, clear the Grace Period checkbox.
Note: 
The Grace Period does not apply to user groups. User groups are 
deleted immediately after they are found to be unresolvable.
5. If the Cleanup Limit is exceeded and the cleanup is canceled, run the Users and 
User Groups Missing From Identity Source report to determine which users you 
need to clean up. After viewing the report, you can specify a limit that allows the 
cleanup to run successfully or perform a manual cleanup. For more information, 
the Security Console Help topic “View a Report Template” and Scheduling 
Cleanup for Unresolvable Users and User Groups
on page 154.
Note: 
When you use Schedule Cleanup before deleting an unlinked identity 
source, make sure you clear the Cleanup Limit checkbox so that no limit 
applies. Also clear this checkbox when you run this job after narrowing the 
scope of an identity source.
6. Under Schedule, use the Start field to select the date you want the cleanup to run 
for the first time.
7. Use the Frequency fields to select how often, and on which days, you want the 
cleanup to take place.
8. Use the Run Time field to specify what time you want the cleanup to run.
9. Use the Expire fields if you want the settings to expire on a specific date. If you 
do not select a date, the settings do not expire.
10. When you are done scheduling cleanup, click Save.
Next Steps
After cleaning up users who have been moved to a different identity source, you need 
to reestablish these users in Authentication Manager by assigning administrative roles 
and enabling them for authentication.
Moving Users in an LDAP Directory
When a user is moved within an LDAP directory that is a linked identity source, 
Authentication Manager can detect the move and update the user when any of the 
following events occur:
• A scheduled cleanup is run.
• An administrator runs a manual cleanup of all identity sources or of the identity 
source containing the user.
• An administrator modifies a user’s record in the Security Console.
• The user attempts to authenticate.
158
6: Administering Users
RSA Authentication Manager 8.1 Administrator’s Guide
Moving Users within an Identity Source
If a user is moved within an LDAP directory and remains within the same identity 
source, the user can still authenticate and be administered unless the user’s Unique 
Identifier changes. Some directory management tools change the Unique Identifier 
because the move is performed by deleting and re-adding the user to the directory. 
In these cases, Authentication Manager cannot find the users after the move because 
deleting and adding the user back to the directory creates a new value for the attribute 
designated as the default Unique Identifier (ObjectGUID in Active Directory or 
nsUniqueID in Oracle Directory Server). To avoid this situation, configure a 
customized attribute as the Unique Identifier.
Moving Users Outside the Scope of the Original Identity Source
If a user is moved within an LDAP directory and is outside the scope of the original 
identity source, the user can still authenticate and be administered as long as the 
following criteria are met:
• The user still resides in the same physical directory.
• An identity source is configured in Authentication Manager that meets the 
following criteria:
– The identity source exists in the same physical directory as the original 
identity source.
– The identity source encompasses the user’s new DN.
– Both identity sources use the same attribute for the User ID.
– Both identity sources use the same attribute for the Unique Identifier.
While you can configure the identity source after the user is moved, a user who 
attempts to authenticate before the identity source is configured is denied access 
for an hour after the authentication attempt. 
• The method used to move the user must not delete and re-add the user when the 
identity source is configured to use the default Unique Identifier.
If these criteria are not met, the move causes the user to become unresolvable. For 
information about how to manage an unresolvable user, see Manual Cleanup for 
Unresolvable Users
on page 153.
Impact of Moving a User Within an LDAP Directory
Moving a user in the directory affects Authentication Manager in the following ways:
• The user’s first authentication attempt might fail. This failed attempt does not 
count against the user lockout policy.
To minimize the number of users who experience this initial authentication 
failure, schedule a periodic cleanup. For instructions, see Schedule a Cleanup Job
on page 156.
• When replication is out of sync, or a replica instance is unavailable, there can be a 
delay in updating the system with the user’s new identity source. In these cases, 
the user is denied access until replication is restored.
6: Administering Users
159
RSA Authentication Manager 8.1 Administrator’s Guide
• For users who authenticate with aliases, group associations are not retained when 
the user is moved to a different identity source. 
The user alias, shell, and any RADIUS profile assigned to the alias are retained 
from the old identity source. 
You must reassociate the alias, shell, and any RADIUS profile to a group in the 
new identity source. To do this, edit the alias in the user’s authentication settings, 
and select a group in the new identity source to associate the alias with the group.
For more information on updating authentication settings, see Manage User 
Authentication Settings
on page 129.
• The ability to authenticate through restricted agents can be lost when the user is 
moved to a different identity source.
If a user’s distinguished name (DN) changes on the Oracle Directory Server/Sun 
Java System Directory Server, the user is removed from all LDAP group 
memberships. If this user belonged to a group with permission to authenticate on a 
restricted agent, the user can no longer authenticate through the restricted agent. 
If the user is a member of a group in the new identity source with permission to 
authenticate on a restricted agent, you do not need to take any action. If the user is 
not a member of a group in the new identity source with permission to 
authenticate on a restricted agent, you must add the user to the group in the 
directory location that is specified as the new identity source, and associate the 
group with the restricted agent.
When group membership is changed directly in an LDAP directory, 
Authentication Manager may not immediately recognize these changes because 
group membership is cached. As a result, Authentication Manager sees the user as 
a member of the group in the original identity source until the cached value 
expires, typically after 10 minutes.
Users can authenticate through a restricted agent for a short time after they move, 
even though they are removed from all groups associated with the restricted agent. 
To ensure that the change in group membership is recognized immediately, flush 
the cache after making the changes in the directory. For more information, see 
Flush the Cache
on page 376.
• The user can be modified by a different administrator. 
If the original administrator does not have privileges on the new identity source, 
he or she will no longer have the ability to administer the user. However, an 
administrator with privileges on the new identity source is able to administer the 
user.
• When a user is moved to a different identity source, the Security Console 
recognizes the user in the new identity source immediately.
If administrators need to address any issues arising from the move, instruct them 
to search for the user in the new identity source, not the old identity source.
160
6: Administering Users
RSA Authentication Manager 8.1 Administrator’s Guide
Modifying a User in an LDAP Directory
When a user’s User ID is changed in an LDAP directory, Authentication Manager 
automatically detects the change and updates the user when any of the following 
events occur:
• A scheduled cleanup is run.
• An administrator runs a manual cleanup of all identity sources or of the identity 
source containing the user.
• An administrator modifies a user’s record in the Security Console.
• The user attempts to authenticate using the old User ID.
Changing the User ID in the directory affects Authentication Manager in the following 
ways:
• The first authentication attempt made by the user can fail.
If a user attempts to authenticate before another event has updated the User ID, he 
or she may experience an authentication failure. If users are denied access, 
instruct them to use the old User ID for the first authentication attempt after the 
change, and then use the new User ID for all subsequent authentication attempts.
If User ID is mapped to a user’s email, the initial authentication failure may not 
occur.
• The Security Console recognizes the new User ID immediately.
If administrators need to deal with any issues arising from the User ID changing, 
instruct them to search for the user by the new User ID, not the old User ID.
The User ID is updated and the user can authenticate using the new User ID after 
an administrator manages the user, for example, the administrator views the user 
record.
• The ability to authenticate through restricted authentication agents can be lost 
when default settings are used in Sun Java System Directory Server/Oracle 
Directory Server Enterprise Edition identity sources.
The default settings in Sun Java System Directory Server/Oracle Directory Server 
Enterprise Edition use the uid attribute as the Naming Attribute. The default 
settings in Authentication Manager map User ID to the uid attribute. With these 
settings configured for Sun Java System Directory Server/Oracle Directory Server 
Enterprise Edition identity sources, any modification to the User ID (uid) changes 
the user’s distinguished name, which removes all LDAP group memberships for 
the user. 
If a user whose DN changed belonged to a group with permission to authenticate on a 
restricted agent, the user can no longer authenticate through the restricted agent. To 
enable this user to authenticate through the restricted agent, you must re-add the user 
to the group associated with the restricted agent.
Documents you may be interested
Documents you may be interested