6: Administering Users
131
RSA Authentication Manager 8.1 Administrator’s Guide
A RADIUS user attribute can be mapped to an identity source attribute. For 
more information, see Map a RADIUS User Attribute Definition to an 
Identity Source Attribute
on page 321.
11. Click Save.
Logon Alias
A logon alias allows users to log on with a user group ID. The user group ID is 
associated with a user group that has access to a restricted agent or that has been 
enabled on an unrestricted agent.
For example, users can have a User ID based on their first initial and last name, such 
as, “kmiller,” as well as an administrative User ID with a specific name, for example 
“root.” If a logon alias is established, Authentication Manager verifies the 
authentication using the user’s passcode, regardless of the User ID that the user 
entered to log on to the operating system. For backward compatibility, a shell value is 
also maintained by the system.
A logon alias can also be used in deployments where there are users with the same 
User ID. An alias that further identifies the user may prevent conflicts when these 
users attempt to authenticate. In the authentication settings for a user, you can also 
prevent a user from authenticating with the default User ID and instead require that the 
user authenticate with an alias.
To allow a user to authenticate with a logon alias on a restricted agent, you must grant 
the user group that is associated with the alias access to the agent. Although all users 
within a deployment can access an unrestricted agent, a user cannot authenticate with 
a logon alias until you enable the user group that is associated with the alias on the 
unrestricted agent. 
You can assign logon aliases on the Authentication Settings page in the Security 
Console. This page is accessed through the user Context menu.
For instructions, see Manage User Authentication Settings
on page 129.
Unlock a User
RSA Authentication Manager locks out users who violate the lockout policy. Locked 
out users cannot authenticate until they are unlocked.
The lockout policy specifies the number of failed authentication attempts allowed 
before the system locks the account. A lockout policy can unlock users after a specific 
time period, or you can require an administrator to manually unlock the user.
Procedure
1. In the Security Console, click Identity > Users > Manage Existing.
2. Use the search fields to find the user that you want to unlock. Some fields are case 
sensitive. 
3. Click the user that you want to unlock, and select Edit.
4. Under Account Information, go to Locked Status, and clear all options that are 
selected.
5. Click Save.
Convert pdf to editable ppt - software application dll: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
Convert pdf to editable ppt - software application dll: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
132
6: Administering Users
RSA Authentication Manager 8.1 Administrator’s Guide
Incorrect Passcode Count
The system counts each time the assigned user enters an incorrect passcode, clearing 
this count automatically with each correct passcode. If a user enters more incorrect 
passcodes than are allowed by the SecurID token policy and then enters a correct 
passcode, the user is prompted for the next tokencode. If you do not want a user to be 
prompted for the next tokencode, you can use the Security Console to clear the 
number of incorrect passcodes entered. 
This operation only clears the existing count. To clear future counts, you must perform 
the procedure again.
For instructions, see Manage User Authentication Settings
on page 129.
Managing Security Questions
Security questions is an authentication method that requires users to answer questions 
in order to authenticate. During enrollment or when users access the Self-Service 
Console for the first time, users are presented with several questions, which they must 
answer. Later when users authenticate, the users must answer a subset of these 
questions with the same answers that they provided during enrollment. 
Security questions are used under the following conditions:
• when the primary authentication method results in a failed authentication
• to confirm identity for risk-based authentication (RBA)
If you want to allow users to change their answers, you must clear their existing 
answers. For example, you might need to do this when users forget their answers, or 
when users believe that their answers are compromised. After you clear a user’s 
answers, the user is prompted to provide new answers at the next logon. For 
instructions, see the Security Console Help topic “Clear Security Question Answers.”
A file of questions is provided for English-speaking users, which you can modify to 
create a new question file. You can also create a file of non-English questions in any 
supported language. When you create a new set of questions or modify just one 
question, the new file replaces the existing file. 
You specify the number of questions that users must answer during enrollment or 
when accessing the Self-Service Console for the first time. You also specify the 
number of questions that users must answer during authentication. The number of 
questions that you specify for enrollment should be greater than the number of 
questions that you specify for authentication. If you specify fewer questions for 
authentication than you specify for enrollment, users can choose which questions to 
answer for authentication.
For self-service troubleshooting, the number of available questions must exceed the 
number of questions required for authentication.
software application dll:Online Convert PDF to Text file. Best free online PDF txt
RasterEdge PDF document conversion SDK provides reliable and effective .NET solution for Visual C# developers to convert PDF document to editable & searchable
www.rasteredge.com
6: Administering Users
133
RSA Authentication Manager 8.1 Administrator’s Guide
Set Requirements for Security Questions
You specify the number of security questions that users must answer during 
enrollment or when they access the Self-Service Console for the first time, and the 
number of questions that users must answer correctly during authentication. If the 
total number of security questions specified for enrollment exceeds the number of 
questions specified for authentication, the user can choose which questions to answer 
for authentication.
Procedure
1. In the Security Console, click Setup > System Settings.
2. Click Security Questions Requirements.
3. In the Enrollment field, specify the number of questions users must answer 
during enrollment. Modifying this setting does not affect users who are currently 
enrolled.
4. In the Authentication field, specify the number of questions users must answer 
correctly during authentication.
5. Click Save.
Custom Security Questions
You can customize the text and language of security questions by creating and 
importing a customized XML file into the database. When you create a new security 
questions file, you can make the following modifications:
• Change the existing English text. Edit the existing XML file to change the 
wording of the existing questions or add new questions of your own.
• Change the language. Create a new XML file using the provided template. 
Specify the language ID, and enter the security questions written in the selected 
language.
The RSA Authentication Manager 8.1 download kit includes a security questions 
sample file (SecurityQuestionsSample.xml) that you can use as a template. The file 
looks similar to the following example:
<?xml version=”1.0” encoding=”UTF-8”?>
<SECURITY_QUESTIONS>
<LANGUAGE id=”en_US”>
<QUESTION>first question</QUESTION>
<QUESTION>second question</QUESTION>
<QUESTION>third question</QUESTION>
</LANGUAGE>
</SECURITY_QUESTIONS>
The Security Questions Sample folder on the RSA Authentication Manager 8.1 
download kit also includes a security questions file schema (SecurityQuestions.xsd) 
for validating a modified or new security questions file.
A deployment can have only one active security questions file. If you modify the 
existing security questions and import the modified file, users must complete security 
questions enrollment again.
134
6: Administering Users
RSA Authentication Manager 8.1 Administrator’s Guide
Follow these guidelines when customizing security questions:
• Create a separate XML file for each LANGUAGE. For example, if you need 
questions in three languages, you must create three language files. 
• Each XML file must include the XML language attribute that identifies the 
language used to write the questions. For a list of supported language ID codes, 
see the Security Console Help topic “Language Codes for Security Questions.”
• You must type the text in the actual language. Authentication Manager does not 
translate languages. 
• A security question can contain up to 255 characters.
• The security questions file must contain at least as many security questions as you 
have specified for enrollment. For more information, see the Security Console 
Help topic “Set Requirements for Security Questions.”
• You cannot delete a security questions file.
Modify the Security Questions File
Security questions are contained in an XML file that is saved in the database. A set of 
default questions is provided for English speaking users. You can modify the default 
questions by changing them or adding additional questions. Once your work is 
finished, you import the modified XML file into the database. When you import the 
new file, the language set in the new file replaces the corresponding set in the system. 
For example, all of the English questions in the new file replace all of the previous 
English questions. Therefore, if you modify even one question in the existing file, you 
must reimport the entire file.
Decide carefully whether to modify an existing security questions file. Each time you 
import a file to modify existing questions, all of the user answers to the previous 
questions are deleted. Users must reenter their answers. RSA recommends that you 
customize the security questions before any users answer the security questions.
Procedure
1. View the example in the security questions sample file 
(SecurityQuestionSample.xml) in the RSA Authentication Manager 8.1 
download kit.
2. Create a separate security questions XML file for each LANGUAGE element. For 
example, if you need questions in three languages, create a file for each language.
3. Type the security questions in each file using the actual language. Authentication 
Manager does not translate languages. A security question can contain up to 255 
characters. Add at least as many security questions as are required by your 
security questions enrollment setting.
4. Make sure that each XML file includes a language ID code that matches the 
language of the text. For a list of supported language ID codes, see the Security 
Console Help topic “Language Codes for Security Questions.”
5. Validate each file using the security questions file schema 
(SecurityQuestions.xsd) in the RSA Authentication Manager 8.1 download kit.
6: Administering Users
135
RSA Authentication Manager 8.1 Administrator’s Guide
Next Step
Import each new security questions file. For instructions, see the Security Console 
Help topic “Import Security Questions.”
Emergency Online Authentication
Online authentication provides emergency access for users with missing or damaged 
tokens. Even with a missing token, users can continue to have two-factor 
authentication using an online emergency access tokencode, an 8-character 
alphanumeric code generated by Authentication Manager. 
The format of the online emergency access tokencode is determined by the token 
policy of the associated security domain. For example, if the security domain’s token 
policy allows special characters, the online emergency access tokencode can include 
special characters.
If a user has an expired token, assign a new token, and then provide temporary access. 
An online emergency access tokencode cannot be assigned to a user with an expired 
token. For instructions, see Provide an Offline Emergency Passcode
on page 139.
The following table lists the types of online emergency access tokencodes. Both 
tokencode types replace the tokencode generated by the user’s token.
Users can also use the Self-Service Console to request temporary access to 
Authentication Manager without the assistance of an administrator. For more 
information, see RSA Self-Service
on page 241.
Tokencode Type
Description
Temporary fixed tokencode
• Can be used more than once. 
• Must be combined with the user’s RSA SecurID 
PIN to create a passcode.
• Is displayed on the Self-Service Console.
One-time tokencode
• Issued in sets. You can determine the number of 
tokencodes in a set.
• Must be combined with the user’s RSA SecurID 
PIN to create a passcode.
• Is displayed on the Self-Service Console.
• Users can download the set of one-time 
tokencodes in a file.
• Each tokencode in the set can only be used once.
136
6: Administering Users
RSA Authentication Manager 8.1 Administrator’s Guide
Assign a Set of One-Time Tokencodes
You can provide temporary access for a user whose token has been permanently lost 
or destroyed by assigning a set of one-time tokencodes. A one-time tokencode 
replaces the tokencode generated by the user's missing token. Users must enter their 
PIN and a one-time tokencode to perform two-factor authentication.
Each one-time tokencode in a set can be used once. A set of tokencodes allows a user 
to authenticate multiple times without contacting an administrator each time.
Procedure
1. In the Security Console, click Authentication > SecurID Tokens > Manage 
Existing.
2. Use the search fields to find the appropriate token.
3. From the search results, click the token with which you want to work.
4. From the context menu, click Emergency Access Tokencodes.
5. On the Manage Emergency Access Tokencodes page, select the Online 
Emergency Access checkbox to enable authentication with an online emergency 
access tokencode.
6. Select Set of One-Time Tokencodes.
7. Enter the number of tokencodes that you want to generate.
8. Click Generate Codes. The set of tokencodes displays below the Generate Codes 
button.
9. Record the set of one-time tokencodes so you can communicate them to the user.
10. Select one of the following options for the Emergency Access Tokencode 
Lifetime:
• No expiration.
• Set an expiration date for the tokencode.
11. In the If Token Becomes Available field, configure how Authentication Manager 
handles lost or unavailable tokens that become available.
• Deny authentication with the recovered token.
If a token is permanently lost or stolen, deny authentication with the 
recovered token so that it cannot be used for authentication if recovered by an 
unauthorized individual. This is essential if the lost token does not require a 
PIN. 
• Allow authentication with the recovered token while simultaneously disabling 
the emergency access tokencode.
• Allow authentication with the recovered token only after the emergency 
access tokencode has expired.
12. Click Save.
6: Administering Users
137
RSA Authentication Manager 8.1 Administrator’s Guide
Assign a Temporary Fixed Tokencode
Occasionally, it is necessary to give a user temporary access to resources protected by 
RSA SecurID. For example, you can give temporary access to a user whose existing 
token has been lost or destroyed. Temporary access allows a user to access protected 
resources while waiting for a replacement token.
This procedure provides a user with temporary emergency access using a temporary 
fixed tokencode. 
A temporary fixed tokencode replaces the tokencode generated by the user's token. 
Similar to the regular tokencode, the temporary fixed tokencode is entered with the 
user's PIN to create a passcode. By using a PIN with the temporary fixed tokencode, 
the user can still achieve two-factor authentication.
Procedure
1. In the Security Console, click Authentication > SecurID Tokens > Manage 
Existing.
2. On the Assigned tab, use the search fields to find the lost or destroyed token.
3. From the search results, click the lost or destroyed token, and from the context 
menu, select Emergency Access Tokencodes.
4. On the Manage Emergency Access Tokencodes page, select Online Emergency 
Access.
5. For Type of Emergency Access Tokencode(s), select Temporary Fixed 
Tokencode.
6. Click Generate New Code. The tokencode displays next to the Generate New 
Code button.
7. Record the emergency access tokencode so that you can communicate it to the 
user.
8. For Emergency Access Tokencode Lifetime, select either No expiration or 
select Expire on and specify an expiration date.
You may want to limit the length of time the one time tokencode can be used. 
Because the one-time tokencode is a fixed code, it is not as secure as the 
pseudorandom number generated by a token. 
9. For If Token Becomes Available, select one of the following options:
• Deny authentication with token.
Select this option if the token is permanently lost or stolen. This option 
prevents the token from being used for authentication if recovered. This 
safeguards the protected resources in the event the token is found by an 
unauthorized individual who attempts to authenticate.
• Allow authentication with token at any time and disable online 
emergency tokencode.
Select this option if the token is temporarily unavailable (for example, the 
user left the token at home). When the user recovers the token, he or she can 
immediately resume using the token for authentication. The online emergency 
access tokencode is disabled as soon as the recovered token is used.
138
6: Administering Users
RSA Authentication Manager 8.1 Administrator’s Guide
• Allow authentication with token only after the emergency code lifetime 
has expired and disable online emergency tokencode.
You can choose this option for misplaced tokens. When the missing token is 
recovered, it cannot be used for authentication until the online emergency 
access tokencode expires.
10. Click Save.
Emergency Offline Authentication
Offline authentication provides emergency access for RSA SecurID for Windows 
users who require emergency access while authenticating offline. These are users with 
lost or stolen tokens, or users who have forgotten their PIN. Temporary emergency 
access can be provided in two ways:
• Offline emergency access tokencode. Use this option if the user’s token is 
unavailable. The Offline Emergency Access Tokencode is used with the user’s 
PIN.
• Offline emergency passcode. Use this option if a user has forgotten his or her 
PIN. The offline emergency passcode is used in place of the user’s PIN and 
tokencode.
RSA SecurID for Windows users may need temporary emergency access so that they 
can authenticate while working offline. Temporary emergency access is necessary for 
users with misplaced, lost, or stolen tokens, or users who have forgotten their PIN.
For offline authentication, the system generates and downloads an offline passcode or 
tokencode before the user needs it. Providing emergency offline authentication codes 
must be done in advance. Authentication codes cannot be sent to a user who is offline.
Provide an Offline Emergency Access Tokencode
An offline emergency access tokencode replaces the tokencode generated by the user's 
token. Similar to the tokencode used in non-emergency circumstances, the user enters 
the offline emergency access tokencode with a PIN to create a passcode, thus 
achieving two-factor authentication. 
You can configure the following: 
• Specify that a new offline emergency access tokencode is downloaded the next 
time the user authenticates online.
• Allow the offline emergency access tokencode to be used for online and offline 
authentication.
Before You Begin
• The user’s security domain must allow offline authentication and permit the user 
to download offline emergency access tokencodes.
• The user must have authenticated to an agent that supports offline authentication 
and the agent has downloaded days of offline authentication data.
6: Administering Users
139
RSA Authentication Manager 8.1 Administrator’s Guide
Procedure
1. In the Security Console, click Authentication > SecurID Tokens > Manage 
Existing.
2. Use the search fields to find the token for the user who needs an offline emergency 
access tokencode.
3. From the search results, click the token.
4. From the context menu, click Emergency Access Tokencodes.
5. On the Manage Emergency Access Tokencodes page, note the Offline Emergency 
Access Tokencode and its expiration date.
6. Select Reset Offline Emergency Access Tokencode, if you want the user to 
download a new offline emergency access tokencode the next time he or she 
authenticates online. If selected, the new tokencode downloads automatically.
7. Click Use offline code for online access, if you want the offline emergency 
access tokencode used for online authentication.
8. Click Save.
Provide an Offline Emergency Passcode
An offline emergency passcode takes the place of the passcode (PIN + tokencode) that 
the user normally enters. The user does not need to possess the token or know the PIN 
to authenticate offline.
Before You Begin
Confirm the following:
• The user’s security domain allows offline authentication and permits the user to 
download offline emergency access tokencodes.
• The user has authenticated to an agent that supports offline authentication and the 
agent has downloaded days of offline authentication data.
Procedure
1. In the Security Console, click Identity > Users > Manage Existing.
2. Use the search fields to find the user who needs an offline emergency passcode.
3. From the search results, click the user.
4. From the context menu, click Manage Emergency Offline Access.
5. On the Manage Emergency Access Passcodes page, note the Offline Emergency 
Passcode and its expiration date.
6. Select Reset Offline Emergency Access Passcode, if you want the user to 
download a new offline emergency passcode the next time he or she authenticates 
online. If selected, the new passcode downloads automatically.
7. Click Update.
140
6: Administering Users
RSA Authentication Manager 8.1 Administrator’s Guide
RSA SecurID PINs
A personal identification number (PIN) is a numeric password used to authenticate a 
user. 
To increase security, you can set the token policy to require users to create PINs 
containing both letters and numbers and to change their PINs at regular intervals. See 
Token Policy
on page 80.
Misplaced or stolen PINs puts protected resources at risk. For this reason, you should 
instruct users to report compromised PINs as soon as possible. 
When a user reports a compromised PIN, you can require the user to change his or her 
PIN after the next successful authentication.
When a user is required to change a PIN, the user must know his or her current PIN. 
To change a PIN, the user authenticates using the existing PIN and tokencode. After 
successfully authenticating, the user is prompted to create and confirm a new PIN, and 
the PIN is associated with the user’s token.
For example, suppose a user reports that she used her computer at a local coffee shop, 
and now she is worried that someone may have seen her type her PIN. After you 
receive the report, you use the Security Console to require the user to change her PIN. 
For instructions, see Require Users to Change Their RSA SecurID PINs
on page 141.
The token policy may require the user to use a system-generated PIN instead of 
creating one. After the next authentication, the system provides the user with a new, 
system-generated PIN. The user then authenticates again using the new, 
system-generated PIN.
If users forget their PINs, you cannot require them to change their PINS in order to 
obtain a new one because users need to know their PINs in order to change them. 
When a user forgets his or her PIN, you must clear the PIN before the user can create 
a new one. For instructions, see, Clear an RSA SecurID PIN
on page 142.
Users can also use Self-Service to reset their PINs.
Set an Initial On-Demand Authentication PIN for a User
On-demand authentication (ODA) always requires a PIN to request a tokencode. You 
can set the initial PIN for the user. The following procedure is for a user who is not yet 
enabled for ODA.
Procedure
1. In the Security Console, click Identity > Users > Manage Existing.
2. Use the search fields to find the user for whom you want to enable ODA and set 
an initial PIN.
3. Click the user.
4. Select SecurID Tokens.
5. Under On-Demand Authentication, select Enable User.
6. For Expiration Date, specify No expiration or the date when on-demand 
authentication expires.
Documents you may be interested
Documents you may be interested