rsa authentication and deploymant planning

RSA Authentication Manager 7.0 Planning Guide

Contact InformationSee the RSA corporate web site for regional Customer Support telephone and fax numbers.

RSA Security Inc.www.rsa.com

TrademarksRSA and the RSA logo are registered trademarks of RSA Security Inc. in the United States and/or other countries. For the most up-to-date listing of RSA trademarks, see www.rsasecurity.com/legal/trademarks_list.pdf. EMC is a registered trademark of EMC Corporation. All other goods and/or services mentioned are trademarks of their respective companies.

License agreementThis software and the associated documentation are proprietary and confidential to RSA, are furnished under license, and may be used and copied only in accordance with the terms of such license and with the inclusion of the copyright notice below. This software and the documentation, and any copies thereof, may not be provided or otherwise made available to any other person.No title to or ownership of the software or documentation or any intellectual property rights thereto is hereby transferred. Any unauthorized use or reproduction of this software and the documentation may be subject to civil and/or criminal liability.This software is subject to change without notice and should not be construed as a commitment by RSA.

Third-party licensesThis product may include software developed by parties other than RSA. The text of the license agreements applicable to third-party software in this product may be viewed in the thirdpartylicenses.pdf file.

Note on encryption technologiesThis product may contain encryption technology. Many countries prohibit or restrict the use, import, or export of encryption technologies, and current use, import, and export regulations should be followed when using, importing or exporting this product.

DistributionLimit distribution of this document to trusted personnel.

RSA noticeThe RC5™ Block Encryption Algorithm With Data-Dependent Rotations is protected by U.S. Patent #5,724,428 and #5,835,600.

© 2007 RSA Security Inc. All rights reserved.First printing: January 2007

www.rsasecurity.com

www.rsasecurity.com/legal/trademarks_list.pdf


ContentsPreface................................................................................................................................... 7

About This Guide................................................................................................................ 7RSA Authentication Manager Documentation ................................................................... 7

Tutorials ....................................................................................................................... 7Related Documentation....................................................................................................... 8Getting Support and Service ............................................................................................... 8

Before You Call Customer Support............................................................................. 8

Chapter 1: Essential Terms and Concepts ..................................................... 9Understanding the RSA Authentication Manager Deployment Process ........................... 9Terms and Concepts to Know Before Planning ................................................................. 9

Deployment.................................................................................................................. 9Realm ........................................................................................................................... 9Security Domain ........................................................................................................ 10Instance .......................................................................................................................11Server Node ................................................................................................................11Primary Instance .........................................................................................................11Replica Instance..........................................................................................................11Agent.......................................................................................................................... 13

Chapter 2: Identifying Your Deployment Model ........................................ 15Using Scenarios to Plan Your Deployment ...................................................................... 15

The Small Deployment: Miller and Strauss, Attorneys at Law................................. 17The Medium-Sized Deployment: Greenley Biotechnologies .................................... 20The Large Deployment: FocalView Software Company .......................................... 25

Deployment Model Checklist ........................................................................................... 35

Chapter 3: The RSA Authentication Manager Architecture ............... 37About the RSA Authentication Manager Model............................................................... 37How Database Replication Works .................................................................................... 38Replication of Data ........................................................................................................... 40RSA Authentication Manager Database Architecture ...................................................... 41

Deciding Where to Store Data ................................................................................... 41Planning to Use the Internal Database As Your Data Store ...................................... 42Planning to Use an LDAP Directory As Your Data Store......................................... 42

Authentication of Users .................................................................................................... 42Planning Load Balancing Using Contact Lists ................................................................. 44Attack Prevention.............................................................................................................. 44RSA Authentication Manager Architecture Checklist...................................................... 46

Contents 3


Chapter 4: Planning RSA SecurID Protection............................................. 47Overview of the Authentication Experience ..................................................................... 47

RSA SecurID Tokens................................................................................................. 47Authentication Agents ............................................................................................... 47RSA Authentication Manager.................................................................................... 48

Deciding Which Resources to Protect with RSA SecurID ............................................... 49Protecting RSA Authentication Manager Servers ..................................................... 49Protecting Access Through a VPN ............................................................................ 49Protecting Access Through a Radius Server.............................................................. 49Protecting Access Through TACACS ....................................................................... 49Protecting Access to Outlook Web Access................................................................ 49Protecting Access to Web Pages................................................................................ 50Protecting FTP and Other UNIX-Based Protocols .................................................... 50Protecting Access to a CITRIX Server ...................................................................... 50Microsoft Windows Desktops ................................................................................... 50

Protecting Windows Desktops with RSA SecurID for Microsoft Windows .................... 50Deploying the Authentication Agent in a Microsoft Windows Environment ........... 51

RSA SecurID Protection Checklist ................................................................................... 58

Chapter 5: Assessing System and Security Requirements ............... 59System Requirements........................................................................................................ 59

Supported Browsers ................................................................................................... 61Maintaining Accurate System Time Settings ............................................................ 62Planning Port Usage................................................................................................... 62Planning for Peak Authentication Periods ................................................................. 63

Planning Management of the Master Password................................................................ 64Planning Physical Security................................................................................................ 64System and Security Requirements Checklist .................................................................. 65

Chapter 6: Planning for Failover and Disaster Recovery .................... 67Key Issues to Consider...................................................................................................... 67Planning for Possible Failure Situations ........................................................................... 67

Detecting a Failed Primary or Replica Instance ........................................................ 67What Happens After the Primary Instance Fails ....................................................... 68What Happens If a Replica Instance Fails ................................................................. 70Planning Recovery from the Loss of a Non-Database Server Node.......................... 71

Planning Regular Database Backups ................................................................................ 71Disaster Recovery Checklist ............................................................................................. 72

4 Contents


Chapter 7: Planning Your Installation.............................................................. 73Assessing Required Permissions for Installation .............................................................. 73Planning Your RSA Authentication Manager Installation ............................................... 74

Minimum Requirements for Machines ...................................................................... 75License Permissions................................................................................................... 75The Necessary Level of Security ............................................................................... 75Personnel to Perform the Installation......................................................................... 75The Best Time to Perform the Installation................................................................. 75Access Through Firewalls ......................................................................................... 76Access Through Proxy Servers.................................................................................. 76Migrating Users from an Existing RSA ACE/Server or

RSA Authentication Manager Deployment ............................................................ 76Planning Primary Instance Installation ............................................................................. 77Planning Replica Instance Installation.............................................................................. 77Planning Server Nodes Installation................................................................................... 78Planning LDAP Directory Integration .............................................................................. 78

Supported External Identity Sources ......................................................................... 79Selecting Read-Only or Read/Write .......................................................................... 79Establishing Security ................................................................................................. 80Performing the Integration......................................................................................... 80Mapping Attributes .................................................................................................... 80

Planning Active Directory Integration.............................................................................. 81Global Catalogs.......................................................................................................... 82

Planning Sun Java System Directory Server Integration .................................................. 83Conducting a Pilot Test..................................................................................................... 83Installation Checklist......................................................................................................... 84

Chapter 8: Planning for Administration.......................................................... 85About the RSA Authentication Manager Administrative Model...................................... 85Planning Administrative Roles, Permissions, and Scope ................................................. 85

Predefined Admininstrative Roles ............................................................................. 89Planning Administration Through the Microsoft Management Console (MMC) ............ 93Planning RSA Authentication Manager Training for Help Desk Administrators ............ 94Administration Checklist .................................................................................................. 95

Chapter 9: Planning PIN, Token, and Password Policies.................... 97Planning PIN Policy.......................................................................................................... 97

Determining PIN Creation Methods .......................................................................... 97Balancing Security and Ease of Use in Determining PIN Policy .............................. 98Planning PIN Requirements and Restrictions............................................................ 98Planning Multiple PIN Policies Through the Use of Security Domains ................. 100

Determining When to Lock Out Users After Failed Authentications............................. 100Planning Password Requirements and Restrictions ........................................................ 101Planning Emergency Access ........................................................................................... 102Policies Checklist ............................................................................................................ 105

Contents 5


Chapter 10: Planning RSA SecurID Token Deployment..................... 107Overview of RSA SecurID Token Types ....................................................................... 107

Hardware Tokens ..................................................................................................... 108RSA SecurID Software Tokens ............................................................................... 109

Determining Which Types of Tokens to Deploy ............................................................ 109Planning How to Deploy Tokens to Users.......................................................................110

Hardware Tokens ......................................................................................................110Software Tokens .......................................................................................................111

Planning User Training on the Use of RSA SecurID Tokens..........................................112Informing Users About the Planned Rollout ............................................................112Communicating Authentication Instructions to End Users ......................................113

Token Deployment Checklist...........................................................................................114

Chapter 11: Planning Logging and Reporting...........................................115About Logging and Reporting .........................................................................................115Planning Log Maintenance ..............................................................................................116

Planning Log Archiving ...........................................................................................117Planning Log Consolidation .....................................................................................118

Planning SNMP Trapping ................................................................................................118Planning Reporting ..........................................................................................................118

Available Reports .....................................................................................................119Scheduling Reports .................................................................................................. 120

Logging and Reporting Checklist ................................................................................... 120

Chapter 12: Completing The Deployment Checklist ............................ 121

Glossary ........................................................................................................................... 127

Index ................................................................................................................................... 143

6 Contents


Preface

About This GuideThis guide describes how to plan for an implementation of RSA Authentication Manager. It is intended for system architects, network planners, security officers and other trusted personnel whose responsibilities include system, network and corporate security. Do not make this guide available to the general user population.

RSA Authentication Manager DocumentationFor more information about RSA Authentication Manager, see the following documentation:

Release Notes. Provides information about what is new and changed in this release, as well as workarounds for known issues.

Getting Started. Lists what the kit includes (all media, diskettes, licenses, and documentation), specifies the location of documentation on the DVD or download kit, and lists RSA Security Customer Support web sites.

Planning Guide. Provides a general understanding of RSA Authentication Manager, its high-level architecture, its features, and deployment information and suggestions.

Installation and Configuration Guide. Describes detailed procedures on how to install and configure RSA Authentication Manager.

Administrator’s Guide. Provides information about how to administer users and security policy in RSA Authentication Manager.

Developer’s Guide. Provides information about developing custom programs using the RSA Authentication Manager application programming interfaces (APIs). Includes an overview of the APIs and Javadoc for Java APIs.

Authentication Manager Help. Describes day-to-day administration tasks performed in the RSA Security Console. To view Help, click the Help tab on the RSA Security Console.

TutorialsThe following interactive tutorials are included on the RSA Authentication Manager 7.0 DVD or in the download kit:

ConsoleAdministration. Provides Overview and How-To information about the tasks you can perform on the RSA Security Console. You can also access this tutorial from the RSA Security Console by clicking Help > Console Tutorial.

SecurIDToken_HowTo. Describes the steps to authenticate using various RSA SecurID tokens. This tutorial can be provided to end users as a training tool.

To view these tutorials, you must have Adobe Flash Player 8 or later. To download the viewer, go to http://www.adobe.com/products/flashplayer/.

Preface 7

www.adobe.com/products/flashplayer/


Related DocumentationRSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows documentation set. This documentation set is included with the Authentication Agent software. RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows works with RSA Authentication Manager 7.0 to protect your company’s local Windows desktops.

Getting Support and Service

RSA SecurCare Online offers a Knowledgebase that contains answers to common questions and solutions to known problems. It also offers information on new releases, important technical news, and software downloads.

The RSA Secured Partner Solutions Directory provides information about third-party hardware and software products that have been certified to work with RSA Security products. The directory includes Implementation Guides with step-by-step instructions and other information about interoperation of RSA Security products with these third-party products.

Before You Call Customer SupportMake sure you have access to the computer running the RSA Authentication Manager software.

Please have the following information available when you call:

Your RSA Security License ID. You can find this number on your license distribution media, or in the RSA Security Console by clicking Setup > Licenses > Manage Existing, and then clicking View Installed Licenses.

The Authentication Manager software version number. You can find this in the RSA Security Console by clicking Help > About RSA Security Console > See Software Version Information.

The names and versions of the third-party software products that support the Authentication Manager feature on which you are requesting support (operating system, data store, web server, and browser).

The make and model of the machine on which the problem occurs.

RSA SecurCare Online https://knowledge.rsasecurity.com

Customer Support Information www.rsasecurity.com/support

RSA Secured Partner Solutions Directory www.rsasecured.com

8 Preface

https://knowledge.rsasecurity.com

www.rsasecurity.com/support

www.rsasecured.com


1 Essential Terms and Concepts• Understanding the RSA Authentication Manager Deployment Process

• Terms and Concepts to Know Before Planning

Understanding the RSA Authentication Manager Deployment Process

In deploying Authentication Manager, start from the interior of your network (inside the corporate firewall) and work outward to the DMZ. The high-level overview of the process is:

• Install Authentication Manager on the internal server in each geographic location where authentication is required. This includes your backup and disaster recovery servers.

• Link your directory server to Authentication Manager, if you are not using the Authentication Manager internal database.

• Install authentication agent software on the users’ machines.

• Test authentication.

Terms and Concepts to Know Before Planning Make sure you understand the following terms and concepts before you use this document to plan your Authentication Manager installation.

DeploymentA deployment is the arrangement of Authentication Manager systems into appropriate locations in a network to perform authentication. The scenarios described in Chapter 2, “Identifying Your Deployment Model,” are deployments.

RealmA realm is a hierarchy of organizational units, called security domains, for administrative purposes. A realm includes all the objects that your administrators need to manage in Authentication Manager, including users, user groups, identity sources, tokens, policies, and more.

1: Essential Terms and Concepts 9


Security DomainIn Authentication Manager, a security domain is an organizational container that defines an area of administrative management within a realm. Security domains can be organized in terms of business units, for example, departments or partners. They establish ownership and namespaces for objects (users, roles, permissions, and so on) within the system. Security domains are hierarchical.

The following figure shows the concepts of realm and security domain.

Realm(Business Entity)

Top-Level Security Domain

(Includes lower-level security domains)

Lower-Level Security Domain(Business Site)

Lower-Level Security Domain(Business Site)

Lower-Level Security Domain

(Department)


(Department)


(Department)


(Department)

10 1: Essential Terms and Concepts


InstanceAn instance is one physical installation of Authentication Manager acting as a single cohesive processing unit. An instance can contain the database server (which is considered a server node) alone, or it can contain the database server with additional server nodes. The following figure shows these sample instances:

1. Database server

2. Database server with one additional server node

3. Database server with multiple additional server nodes

Server NodeA server node is an installation of Authentication Manager on a single server host. Each instance has one server node that contains the internal database. You can add additional server nodes to an instance to increase authentication performance. The additional server nodes cannot operate alone because they do not contain the internal database. You must connect the additional server nodes to the database server.

In the preceding figure, the data icon represents the database server. The small central processing unit icon represents an additional server node.

In deployments that use LDAP directories, the database server is connected directly to the LDAP directory server.

Primary InstanceThe primary instance is where authentication and all administrative actions occur. You must designate one instance as the primary instance for your deployment. All other instances in the deployment are replica instances.

Replica InstanceThe replica instance is a copy of your primary instance. You can view, but not update, administrative data on a replica instance.

The following figure shows these sample deployments containing primary and replica instances:

1. A single server node primary instance with a single server node replica instance

2. A single server node primary instance with multiple single server node replica instances

Data

1.

Instance

Data

2.

Instance

Data

3.

Instance



3. A multiple server node primary instance with a multiple server node replica instance

4. A multiple server node primary instance with multiple replica instances with multiple server nodes

Data

Data

Data

1. 2.

3. 4.

Data Data Data

Data

Data

Data

Data DataData

Server NodePrimary Instance

Key

Replica Instance

12 1: Essential Terms and Concepts


AgentAn agent is a software application installed on a device, such as a domain server, web server, or desktop computer, which enables authentication communication with Authentication Manager on the network server.

An agent protects the device on which it is installed. When a user attempts to log on, the agent passes the user’s logon credentials to Authentication Manager. Based on the pass or fail information that the agent receives from Authentication Manager, it either allows or prevents the user from accessing the device.



2 Identifying Your Deployment Model• Using Scenarios to Plan Your Deployment

• Deployment Model Checklist

Using Scenarios to Plan Your DeploymentRSA Authentication Manager is highly scalable and configurable. This means that you have many decisions to make in advance of your deployment. The sample deployment scenarios in this chapter illustrate a small, medium, or large deployment. Select and read the scenario that is most like your deployment.

Use the scenarios to visualize and understand the network and administrative aspects of planning a deployment. As you review the scenarios, consider how you will organize your deployment. Use the “Deployment Model Checklist” provided on page 35 to document your deployment plan.

Before you begin planning, make sure you understand the terms and concepts discussed in “Terms and Concepts to Know Before Planning” on page 9.

2: Identifying Your Deployment Model 15


The following table summarizes each scenario.

Element“The Small Deployment: Miller and Strauss, Attorneys at Law”

“The Medium-Sized Deployment: Greenley Biotechnologies”

“The Large Deployment: FocalView Software Company”

License Base Advanced Advanced

Number of Users 0 - 1,000 1,000 - 5,000 5,000 and up

Realms (Top-Level Security Domains)

1 1 1

Lower-Level Security Domains

None Multiple in one physical location

Multiple in multiple physical locations

Geographic Locations 1 1 Multiple

Number of Administrators 2 4 6

Number of IT Support Staff

0 20 50

Identity Source Authentication Manager Internal Database

Microsoft Active Directory

• Sun Java System Directory Server

• Microsoft Active Directory

Authentication Method for Internal Users

Password RSA SecurID RSA SecurID

Authentication Method for External Users

RSA SecurID RSA SecurID RSA SecurID

Policies Default • Default• Custom

• Default• Custom

16 2: Identifying Your Deployment Model


The Small Deployment: Miller and Strauss, Attorneys at LawThe small deployment scenario depicts a fictitious law firm called Miller and Strauss, Attorneys at Law. The firm employs 50 people, working as one business unit, and needs a secure, cost-effective way to allow remote users to access its network. Miller and Strauss, therefore, chose to implement a virtual private network (VPN) secured by RSA SecurID two-factor authentication.

For Miller and Strauss, deploying RSA Authentication Manager:

• Provides a secure way for personnel from outside the office to access highly confidential information on the company’s network

• Assures, with certainty, that users are who they say they are

• Provides a record of each log on to the VPN

• Provides for failover and disaster recovery

• Requires no increase in IT staff

The following figure shows the Miller and Strauss network, including users who need to access resources locally and remotely.

Intranet

Authentication Managers

Data

Internet

Remote Users (with VPN client )

Domain Server

Local Users (Windows Password Authentication Only)

Windows PasswordProtected Resources

(File servers, DBs)

Miller and Strauss, Attorneys at Law

ProxyServer

Data

Primary

Replica

SecurID ReadyAuthentication

Agent VPN Server

Firewall Firewall

DMZ

RSA SecurID Authentication

Required

Data



The following figure shows how Miller and Strauss organized users, groups, tokens, and so on for administration in their Authentication Manager deployment.



Use the following information about the Miller and Strauss scenario to help you visualize and understand what you need to consider as you plan the network and administrative organization of your deployment.

RealmWhen RSA Authentication Manager is installed, a single realm is instantiated by default. Miller and Strauss does not need to segregate any of the user population, so no additional realms are required for this deployment.

LicenseMiller and Strauss purchased the Base license, which allows the firm to have one primary instance and one replica instance.

Authentication AgentsWhen external users want to gain access to the Miller and Strauss internal network, they must connect to the VPN server and authenticate. Miller and Strauss purchased a VPN server with an embedded RSA Authentication Agent. Internal users use password authentication to access the company’s internal network.

Note: For a list of RSA Security partners who supply hardware with embedded RSA Authentication Agents, go to www.rsasecured.com.

InstancesThe primary instance and the replica instance both handle authentication requests. When a user attempts to authenticate for access to your network, the agent sends the request to the machine that is least busy. The replica instance is also for backup and disaster recovery purposes.

Identity SourcesBecause this firm has no pre-existing identity source, the administrators chose to use the internal database that is embedded in Authentication Manager to store all Authentication Manager user and token data.

Security DomainsMiller and Strauss has one security domain, which contains all users, administrative roles, authentication agents, tokens, and reports.

PoliciesMiller and Strauss determined that the Authentication Manager defaults for realm (single), security domain (single), agents (unrestricted), groups (none), and policies (such as password, lockout, token, and session lifetime) are appropriate. These policies satisfy the firm’s requirements and facilitate a simpler installation. No customizing is required.

Information Technology StaffMiller and Strauss has two administrators who perform administration for the firm. Both are Super Admins. There is no additional IT support staff.



The Medium-Sized Deployment: Greenley BiotechnologiesThe medium-sized deployment scenario depicts a fictitious company called Greenley Biotechnologies. Greenley Biotechnologies employs 2,500 people and most of them work on-site. Some sales and customer support personnel work off-site, but all personnel operate as one business unit.

Greenley Biotechnologies needs a secure way to allow internal and external users to access highly sensitive data that is located on three internal servers. Greenley Biotechnologies, therefore, chose to implement a virtual private network (VPN) secured by RSA SecurID two-factor authentication.

For Greenley Biotechnologies, deploying RSA Authentication Manager:

• Requires all internal and external users to use two-factor authentication to access its network

• Enables administration on a department-by-department basis


• Supports multiple platforms

• Enables integration of Active Directory as the identity source

• Provides for failover and disaster recovery

• Provides records of all authentication activity



al Users ntication)

ources DBs)

curID cation ired

The following figure shows the Greenley Biotechnologies network, including users who need to access resources locally and remotely.


Internet

Remote Users

Intern(SecurID for Windows Local Authe

Greenley Biotechnologies

VPN Server

ProxyServer

Data

Primary Replica ServerNode

ServerNode

PAM Protected

Server

(Finance)

Data

Domain Controller 3

(HR)

Data

(R&D)

Data

OWA Back End

CITRIX Server

Protected Res(File servers,

WebServer

OWA Front End

Firewall

Citrix Presentation Server

DMZ

(Local Authentication

Component Installed)

Web Agent Installed

Authentication Agent Installed

Firewall

Domain Controller 2

Domain Controller 1

SecurID ReadyAuthentication

Agent

RSA SeAuthenti

Requ


RequiredAuthentication Agent Installed


Authentication Agent

Data

Web Agent Installed



The following figure shows how Greenley Biotechnologies organized users, groups, tokens, and so on for administration in their Authentication Manager deployment.



Use the following information about the Greenley Biotechnologies scenario to help you visualize and understand what you need to consider as you plan the network and administrative organization of your deployment.

RealmThere is one realm in this scenario because there is no need to segregate user populations.

Note: If the company wants to keep any of its business units separate, perhaps for regulatory reasons, additional realms can be created. Administrators from one realm cannot manage resources (for example, users, tokens, or policies) in another realm.

LicenseGreenley Biotechnologies purchased an Advanced license, which allows the firm to have a primary instance, and multiple replica instances and server nodes.

Authentication AgentsTo meet the Greenley Biotechnologies authentication requirements, the RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows is installed on the external users’ laptops and internal users’ desktops. The agent provides access to the users’ laptops and desktops. When remote users want to gain access to the Greenley Biotechnologies internal network, they must connect to the VPN server. (Greenley Biotechnologies purchased a VPN server with an embedded RSA Authentication Agent.)

Note: For a list of RSA Security partners who supply hardware with these embedded RSA Authentication Agents, go to www.rsasecured.com. Greenley Biotechnologies downloaded RSA Authentication Agents for their web server and Outlook Web Access server. See your RSA Security sales representative for a list of RSA Authentication Agents that you can download.

InstancesGreenley Biothechnologies has an Advanced license, which allows the company to include server nodes in its system. The network administrator determined that one primary instance (a database server and an additional server node) and one replica instance (a database server and an additional server node) is appropriate for the company’s anticipated level of authentication activity. The primary instance and the replica instance both handle authentication requests. When a user attempts to authenticate for access to the network, the agent sends the request to the server node that is least busy. (Remember, the database server is a node.) The replica instance is also for backup and disaster recovery purposes. The company can add more server nodes as it grows.


www.rsasecured.com


Identity SourcesThis scenario has one identity source, which is outside of Authentication Manager. It is an Active Directory that contains all users from all departments. Integrating this identity source with Authentication Manager required running the Initialize Identity Source utility to create and deploy the resource adapters. The administrator then used the RSA Security Console to create the identity source record and map Authentication Manager attributes to the Active Directory attributes.

Security DomainsGreenley Biotechnologies employs two Super Admins and two Privileged Help Desk Administrators among its Information Technology staff. The Super Admins delegated some of the administrative responsibilities to the two Privileged Help Desk Administrators, so the scope of the Privileged Help Desk Administrator role includes all security domains. The Privileged Help Desk Administrator is a predefined role that was modified by Greenley Biotechnologies to include the following permissions:

• Move users and groups between security domains

• View security domains

• Manage agents

The Super Admins created security domains for Research and Development, Human Resources, and Finance. The realm contains the policies for the security domains. The security domains contain users who are members of these departments.

The security domains also contain reports that are particular to a department. Reports that cover the entire organization are contained in the realm.

PoliciesDue to the sensitive nature of the Finance department’s work, its password policies are stricter, and require more frequent password changes than the other departments. Lockout and token policies are stricter than those of other departments, too. The Super Admins configured custom password, lockout, and token policies for the Finance department.

The Human Resources and Research and Development departments rely on the Authentication Manager default policies.

Information Technology StaffIn addition to the four administrators, there is a staff of 20 who are assigned the predefined Help Desk Administrator role.

The Large Deployment: FocalView Software CompanyThe large deployment scenario depicts a fictitious company called FocalView Software Company. FocalView Software employs 15,000 people in three locations.

FocalView Software needs a secure way to allow internal and external users to access highly sensitive data that is located on internal servers. FocalView Software, therefore, chose to implement a virtual private network (VPN) secured by RSA SecurID two-factor authentication.



The FocalView Software network is built on Windows and Linux platforms, and it uses Active Directory and Sun Java System Directory Server for identity sources.

For FocalView Software, deployment of RSA Authentication Manager:

• Efficiently sustains authentication activity for 15,000 employees located in multiple time zones without burdening other resources

• Provides a full complement of logging and reporting capabilities


• Supports multiple platforms

• Provides local and remote administration and authentication

• Enables integration with multiple identity sources



The following figure shows the FocalView Software network, including users who need to access resources locally and remotely.


Internet

Remote Users

Internal Users (SecurID for Windows Local Authentication)

VPN Server

ProxyServer

Data Data

Primary Replica ServerNode

ServerNode

PAM Protected

Server

Domain Controller

OWA Back End

CITRIX Server

WebServer

OWA Front End

Firewall

Citrix Presentation Server

DMZ

Web Agent Installed

Firewall


Internet

Remote Users

Internal Users (SecurID for Windows Local

Authentication)

VPN ServerProxyServer


Required

Data

Replica ServerNode

PAM Protected

Server

Domain Controller

OWA Back End

CITRIX Server

WebServer

OWA Front End

Firewall

Citrix Presentation

Server

DMZ


Required

Web Agent Installed



Firewall

SecurIDReady


Boston

New YorkAuthentication

Managers

Internet

Remote Users

Internal Users (SecurID for Windows Local Authentication)

VPN ServerProxyServer

Data

ReplicaServerNode

PAM Protected

ServerDomain Controller

OWA Back End

CITRIX Server

WebServer

OWA Front End

Firewall

Citrix Presentation

Server

DMZ

LAC Component

Installed

Web Agent Installed

Firewall

(Finance)

Data

(HR)

Data

(R&D)

Data

Protected Resources (File servers, DBs)

San Jose


AuthenticationAgent

Installed


Required


Required




AuthenticationAgent

Installed

SecurIDReady


AuthenticationAgent

Installed




Required




SecurIDReady



Required

Authentication Agent (Local

Authentication Component

Installed)

FocalView Software



The following figure shows how FocalView Software organized users, groups, tokens, and so on for administration in their Authentication Manager deployment.



Use the following information about the Miller and Strauss scenario to help you visualize and understand what you need to consider as you plan the network and administrative organization of your deployment.

RealmThis scenario has one realm because all three locations act as one business unit and the company does not need to segregate any user populations for administrative purposes.

FocalView Software recently acquired the San Jose company and added it to the realm. If the company develops or acquires other business units in the future, they can be added to the realm. If the company wants to keep any of its business units separate, perhaps for regulatory reasons, additional realms can be created to segregate user populations for administrative purposes. This separation occurs because each realm uses its own identity source. Administrators from one realm cannot access or manage resources that belong to another realm, for example, users, tokens, or policies.

License

FocalView Software purchased an Advanced license, which allows the firm to have a primary instance, multiple replica instances, and multiple server nodes.

Authentication AgentsTo meet FocalView Software authentication requirements, the RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows is installed on external users’ laptops and internal users’ desktops. The agent provides access to the users’ laptops and desktops. When remote users want to gain access to the FocalView Software internal network, they must connect to the VPN server. (FocalView Software purchased a VPN server and a Citrix Presentation server with an embedded RSA Authentication Agent.)

Note: For a list of RSA Security partners who supply hardware with embedded RSA Authentication Agents, go to www.rsasecured.com. FocalView Software downloaded RSA Authentication Agents for their web server and OWA server. See your RSA Security sales representative for a list of RSA Authentication Agents that you can download.

InstancesWhen the Super Admins at FocalView Software planned their deployment, they determined the need to have instances of Authentication Manager in each geographic location. They required quick authentication and localized administration. With an instance in each location, requests for authentication are handled locally. This is faster than requiring requests from every location to pass through one location. It also enables the company to delegate certain administrative privileges to local administrators and to install local security domains.


www.rsasecured.com


In this scenario, there is a primary instance and a replica instance in Boston. New York and San Jose each have a replica instance. FocalView Software has the Advanced license, which allows the company to include server nodes in its system. The Boston location has a primary instance cluster and a replica instance cluster, both containing two server nodes. New York and San Jose each have a replica instance cluster containing two server nodes.

If the primary instance in Boston becomes unavailable for some reason, the replica instance can be promoted to a primary instance. The former primary instance in Boston is demoted to a replica instance because there is only one primary instance allowed in a realm. If both instances in Boston become unavailable, one of the replica instances in New York or San Jose can be promoted to a primary instance.

Identity SourcesFocalView Software uses an Active Directory forest as the identity source for its Boston and New York locations. The San Jose location uses the Sun Java System Directory Server for its identity source.

Integrating these identity sources with Authentication Manager required running the Initialize Identity Source utility to create and deploy the resource adapters. The administrator then used the RSA Security Console to create the identity source record and map Authentication Manager attributes to the Active Directory and Sun Java System Directory Server attributes.

Security DomainsThe Super Admins delegated some of the administrative responsibilities to the Privileged Help Desk Administrators in each location, but they did not want to grant them access to other security domains. The solution is to create multiple security domains because administrative scope can be limited to the security domain. The Privileged Help Desk Administrators can access machines on-site and handle local issues more efficiently.

Users assigned to Boston, New York, and San Jose are contained in the lower-level security domains associated with those locations. Authentication Manager agents are installed on machines at each location and are contained in the location’s security domain. This enables the Privileged Help Desk Administrators at the location to manage agent records and access the machines containing the agents.

Tokens assigned to users at a location are contained in that locations’s security domain. Unassigned tokens may be contained in specific security domains, too, which facilitates assignment and delivery to new users. FocalView Software has 17,000 tokens on file. There are 15,000 users who are assigned at least one RSA SecurID token. The remaining 2,000 are for users who have more than one token and for a reserve supply for replacements or new assignments.

Reports specific to a location are contained in the lower-level security domains. Those of a more general nature are contained in the top-level security domain.



PoliciesThe FocalView Software Super Admins determined that the Authentication Manager default policies meet the requirements for the company’s top-level security domain, as well as for the Boston and New York security domains. The default policies cover passwords, lockout, token, and offline authentication.

FocalView Software recently acquired the San Jose location, where the administrators prefer stricter password, lockout, and token policies than the default policies used in Boston and New York. The administrators in San Jose customized their security policies to require more frequent password changes, and less forgiving lockout and token policies.

Information Technology StaffThe FocalView Software deployment requires four Super Admins and two administrators. The two administrators have all administrative permissions, except Super Admin only permissions.

An additional IT staff of 50 performs general administrative tasks and staffs the Help Desk. There are 20 Privileged Help Desk Administrators in Boston, 15 in New York, and 15 in San Jose. Their scope is limited to the security domain where they are located and to the identity source where their respective users are stored. They have all of the permissions for their role, plus the following custom privileges:

• Move users and groups among the security domains

• View security domains

• Manage agents



Deployment Model ChecklistUse this checklist to begin documenting your plan.

Element Description Your Plan

License type Know which license you have:• Base • Advanced

Realm Know how many realms you want.

Security Domain • Understand how Authentication Manager uses top-level and lower-level security domains.

• Know how many lower-level security domains you need, what you want in them, and how you want their hierarchy organized.

Authentication Know which types of users you require to authenticate:• Internal users• External usersKnow how you want types of users to authenticate:• Password• RSA SecurID token

Physical location Know where you want to locate your Primary Instance and each Replica Instance.

Identity source Know what identity source you plan to use:• Internal database • Active Directory • Active Directory Global

Catalog• Sun Java System Directory

Server

Agent Know where you need agents installed and what types to install.



3 The RSA Authentication Manager Architecture• About the RSA Authentication Manager Model

• How Database Replication Works

• Replication of Data

• RSA Authentication Manager Database Architecture

• Authentication of Users

• Planning Load Balancing Using Contact Lists

• Attack Prevention

• RSA Authentication Manager Architecture Checklist

About the RSA Authentication Manager ModelAuthentication Manager provides authentication services that allow you to verify the identity of each user attempting to access desktops, laptops, and network resources. An Authentication Manager deployment can consist of one or as many as six instances (one primary instance and five replica instances).

In the Authentication Manager model:

• The primary instance enables authentication and administration of Authentication Manager.

• The replica instance enables authentication and failover of authentication. It also provides the ability to recover administration capabilities and Authentication Manager data in the event that the primary instance fails.

A single instance of Authentication Manager can handle administration and authentication of users in a deployment with a small user population. However, RSA Security recommends that at least two instances (one primary instance and one replica instance) be installed for the following reasons:

• To safeguard data in the internal database, because replication ensures that each instance contains the most up-to-date data

• To provide continuous authentication in the event that an instance fails

• To provide a method of recovering administrative capabilities in the event that the primary instance fails

3: The RSA Authentication Manager Architecture 37


You can install Authentication Manager on a single machine or on multiple machines. Each machine is called a server node. In an instance that uses multiple server nodes, whether a primary instance or a replica instance, only one server node contains a copy of the database. This server node is known as the database server. All server nodes authenticate users. On a primary instance with multiple server nodes, all server nodes provide administrative access to the database through the RSA Security Console.

How Database Replication WorksYou can install a replica instance as a means of minimizing data loss in the event of a hardware crash. Replicated instances allow authentication to continue while the primary instance is being brought back online. Although certain functions may be disabled or performance may decrease, the product’s core functions continue to operate.

The following sections describe how the primary and replica instances interact.

Administrative UpdatesYou must perform all administrative changes, such as adding or deleting users, at the primary instance. The primary instance propagates the administrative changes to all replica instances, as shown in the following figure.

In this “hub and spoke” model, two replica instances never communicate directly.

Administrative Updates Data Flow

Database ServerBoston1

Primary Instance

Server NodeBoston1

Database ServerSan Jose

Replica Instance

Server Node San Jose

Database ServerNew York

Replica Instance

Server Node New York


Replica Instance

Server NodeBoston2

38 3: The RSA Authentication Manager Architecture


Runtime UpdatesRuntime changes, such as those resulting from user authentication, can be initiated at any primary or replica instance. If the runtime change occurs at a replica instance, the change is first propagated to the primary instance. The primary instance then propagates the change to all other replica instances.

The following figure shows:

1. Runtime authentication changes occur at the replica instance in San Jose.

2. San Jose updates the primary instance in Boston.

3. Boston updates the other replicas.

You should know:

• You can see the changes at any instance after the changes have been propagated.

• If a replica instance contains more recent changes than those received from the primary instance, the replica instance can reject the less timely data.

• If Authentication Manager does not load the database after the data has been changed, you see obsolete data at the replica instance.

Runtime Updates Data Flow


Primary Instance

Server NodeBoston1

Database ServerSan Jose

Replica Instance

Server NodeSan Jose

Database ServerNew York

Replica Instance

Server NodeNew York


Replica Instance

Server NodeBoston2



Replication of DataIn Authentication Manager, administration and authentication activities result in changes to the internal database. Administrative changes can be performed only on the the primary instance, which replicates these changes to all of the replica instances in the deployment. Authentication changes can occur on both the primary and replica instances. Each replica instance replicates its authentication changes to the primary instance, which then replicates those changes to all other replica instances in the deployment.

For example, an administrator assigns a token to a user. The database on the primary instance now contains new information about the user and the token, resulting from the administrative action of assigning the token to the user. The primary instance replicates this new information to the replica instances. When the user attempts to authenticate to a replica instance, the replica instance changes the user record to indicate that the user authenticated, and sends that new information to the primary instance. The primary instance then replicates the change to the other replica instances.

Replicated DataAll changes that occur on a primary instance are replicated to each replica instance in the deployment. All changes that occur on a replica instance are replicated to the primary instance, which then replicates the changes to all other replica instances in the deployment.

The following table lists the runtime changes that can occur on a replica instance.

Object Change That Is Replicated

User Any change to the user’s fixed passcode or PIN.

Agent • The creation of an agent through agent auto-registration.• Assignment of an agent to a contact list. See “Planning Load Balancing Using

Contact Lists,”on page 44.• Updating a node secret.

Token Any changes that occur as a result of the following activities:

• Authentication.• Token replacement, including disabling, unassigning and deleting an

existing token, and assigning and enabling a replacement token. The exact changes that occur depend upon how you configure Authentication Manager to handle token replacement. See “Replacing Tokens” in the Administrator’s Guide.

• Emergency passcode processing.• The distribution of offline authentication data to agents.• Seed initialization of a Software Toolbar Token.



Log data on a replica instance is not replicated in the same way as changes resulting from authentication. Log data is sent only to the primary instance, or to a designated centralized log, and is not replicated to all instances in your system.

Important: The user and user group data that resides in your LDAP directory is not replicated by Authentication Manager. In a replicated LDAP environment, it is your responsibility to properly configure LDAP to replicate LDAP changes.

RSA Authentication Manager Database ArchitectureYou must decide whether to use the Authentication Manager internal database or an external LDAP directory to store user and group data.

Authentication Manager includes an internal database that stores all of the data required to administer and run the system. Authentication Manager uses the internal database to store product-specific information, including agent data, token data, and reports. However, for deployments with existing LDAP data stores, Authentication Manager also offers the ability to use existing user and user group data by connecting to an LDAP directory.

Deciding Where to Store DataWhen planning how to store and access Authentication Manager data, you need to make a decision about which data stores to use as the location of user and user group data. The location of the data is known as an identity source. An identity source represents the physical source of the data of the users and user groups that you manage through the RSA Security Console. An identity source can be one of the following:

• A subtree in an LDAP directory server, such as Sun Java System Directory Server or Microsoft Active Directory, which usually contains user and user group data

• The Authentication Manager internal database, which defines product-specific data, and can contain user and user group data

If your data resides in a heterogeneous, multi-directory LDAP environment, Authentication Manager allows you to specify any or all of the identity sources listed. For example, you can use both a Microsoft Active Directory Server and a Sun Java System Directory Server as identity sources. This functionality accommodates environments that have evolved over time, due to acquisitions, upgrades, or architectural changes. For example, when you first install Authentication Manager, you can specify the internal database as the single identity source, but accommodate a growing user population when an LDAP directory is introduced into your system.

When choosing whether to use the internal database or the LDAP directory, consider your current network setup and needs.

If you have a potentially large population of users and one or more existing LDAP directory servers, you can specify the LDAP directories, or subtrees within them, as identity sources. If you have a small number of users and have not set up an LDAP directory, you may find that the internal database provided with Authentication Manager meets your needs.



Using the internal database as your identity source does require additional administrative effort. User and user group data must be manually entered into the database through the RSA Security Console. There is also the problem of potentially having the same data in two separate places, for example, in the internal database and in a Human Resources or Payroll database. This duplicate data would also need to be tracked and kept synchronized manually.

Planning to Use the Internal Database As Your Data StoreIf your deployment uses the internal database as your only identity source, all data is stored in the internal database and there is no need to specify an LDAP directory as an identity source.

Planning to Use an LDAP Directory As Your Data StoreYou can access the user and user group data in the LDAP directory through the RSA Security Console in read-only mode or read/write mode, depending on how you set up permissions on the LDAP directory, and how you configure the identity source when you associate it with Authentication Manager. The decision to enable read/write access to the LDAP directory is likely based upon the existing corporate policies of your company, and the division of responsibilities in your organization. See “Selecting Read-Only or Read/Write,” on page 79.

The user and user group data in the LDAP directory is referenced by default when you specify an LDAP directory as an identity source. You can view and, if write-access is enabled, manage additional data residing in your LDAP directory by mapping the additional data in the LDAP directory to extension fields in the internal database that are accessible through the RSA Security Console. See “Mapping Attributes,” on page 80.

Different administrators, with different security levels, may manage Authentication Manager and the LDAP directory. If the LDAP directory is the authoritative source for user information, disabling a user through LDAP administration affects the ability of the user to authenticate.

• Do you want LDAP administrators to have the ability to disable a user’s ability to authenticate?

• Do you want Authentication Manager administrators to have the ability to edit LDAP data?

Note: Access to the LDAP directory through the RSA Security Console is encrypted using SSL.

Authentication of UsersIn a typical logon situation, authentication is usually handled by the operating system, using a User ID and a static, non-changing password. This method, known as one-factor authentication, is inherently insecure, as the static password opens up the possibility of brute force attacks, which are attempts to access the system by trying every possible password.



In the Authentication Manager model, the process of authentication is an interaction of three distinct products:

• An RSA SecurID token, which generates a random number at a set interval of time, usually one minute. The random number, known as a tokencode, combined with a user’s personal identification number (PIN), produces a passcode. A token can be a hardware device or a piece of software installed on a device (PC, Palm Pilot, Pocket PC, Blackberry). Requiring both the tokencode and the PIN is known as two-factor authentication: something you have (the token and tokencode displayed on it) and something you know (the PIN). The user presents the PIN and tokencode, or passcode, at the logon prompt to access a protected resource.

• An authentication agent, which is software that, when installed, requires any user logging on to provide the correct RSA SecurID passcode, in addition to any other required logon information (such as User ID and network password).Agent software is available for many platforms, including Microsoft Windows and multiple versions of UNIX, and many purposes, including protecting access to networks, desktops and web sites. Additionally, there are many third-party vendors who have partnered with RSA Security to provide built-in support for RSA SecurID authentication in their products. These products include RADIUS servers, Virtual Private Network (VPN) Servers, and routers.

For more information about supported products, see the RSA Secured Partners Solutions Directory at http://rsasecurity.agora.com/rsasecured/.

• Authentication Manager, which processes the authentication request, verifying the supplied passcode.

To authenticate a user, Authentication Manager needs, at a minimum, the following information:

• A user record containing a User ID and other personal information about the user (for example, first name, last name, group associations, if any). You can configure an LDAP directory server as the identity source, or you can enter the user information into the internal database using the RSA Security Console. When deciding which method is best for you, consider which data store (and therefore which administrator) “owns” the data.

• An agent record, which lists the name of the machine on which the agent is installed. The existence of an agent record in the internal database identifies the agent to Authentication Manager and enables Authentication Manager to respond to authentication requests from the agent.

• A token record, which enables Authentication Manager to generate the same tokencode that is displaying on a user’s RSA SecurID token.

• Under most circumstances, a user PIN, which is used in conjunction with the tokencode to form the passcode.



Planning Load Balancing Using Contact ListsAuthentication Manager provides load balancing through contact lists, which contain a list of all the server nodes where the authentication agent can direct authentication requests. After an agent contacts Authentication Manager, Authentication Manager provides the agent with the contact list.

Important: Do not use any third-party load balancing products. Authentication agents perform their own load balancing and server discovery. The authentication agent protocol is not compatible with third-party UDP load balancing products.

Agents receive notification from Authentication Manager of any changes to the contact list. Periodically, the agent reviews all the server nodes listed in the contact list to determine where to send authentication requests. The agent uses metrics such as response performance to determine where to send requests.

There are two types of contact lists:

Automatic Contact Lists. Automatic lists are automatically maintained by Authentication Manager, and are automatically updated each time a new server node is added to the deployment. An automatic contact list is assigned to each instance in your deployment. The list contains the IP addresses of each server node in the instance the contact list is assigned to, and the IP address of one server node from each other instance in your deployment, up to a limit of 11. Agents are sent automatic contact lists by default.

Manual Contact Lists. Manual lists are maintained by administrators. They must be manually updated to reflect the most recent list of server nodes. Manual lists can contain the IP address of any server node in the deployment, up to a limit of 11 server nodes.

For almost all organizations, automatic contact lists are sufficient. However, you may choose to create a manual contact list if you have a specific way that you want to route authentication requests. For instructions on adding manual contact lists, see the Help topic, “Add a Manual Contact List.”

Note: You can override the contact list, and thereby direct an agent to a particular instance by configuring the sdopts.rec file on the agent. See the RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows Installation and Administration Guide.

Attack PreventionAuthentication Manager provides protection against unauthorized users attempting to hack into your systems, either using compromised credentials, like a stolen token, PIN, or passcode, or through a brute force method, like attempting to authenticate multiple times using randomly generated passcodes.



Evasion of AttackThe following evasion-of-attack features do not replace the need to implement and use the product properly nor can they offer protection against an intruder who has both a user’s PIN and RSA SecurID token.

It is essential to observe the following:

• All users must protect the secrecy of their PINs and the physical security of their tokens.

• Administrators must respond immediately to disable compromised PINs and missing tokens.

• Physically secure the machine where Authentication Manager is installed.

Protection Against Random Guessing of PasscodesTo protect against the random guessing of passcodes, Authentication Manager employs lockout policies, which allow you to configure a specific number of allowed incorrect authentication attempts. When this number is exceeded, the user is locked out. This prevents users from entering passcode after passcode in an attempt to guess a correct passcode.

Administrators can define a lockout policy for each security domain. Lockout policies specify:

• The maximum number of failed authentication attempts a user can make within a given period of time.

• Whether an administrator must re-enable users, or users are automatically re-enabled after a given period of time.

Protecting Against Compromised PINsTo protect against a stolen PIN, Authentication Manager employs token policies, which you can configure to prompt users for a second tokencode after a series of failed logon attempts. In this case, Authentication Manager is effectively requiring the user to prove that the token is in his or her possession. For example, if an unauthorized user with a stolen PIN eventually succeeds in guessing a valid tokencode, he is denied access when he does not correctly enter the next tokencode generated by the token. See Chapter 9, “Planning PIN, Token, and Password Policies.”

Protecting Against Stolen PasscodesTo protect against the use of stolen passcodes, Authentication Manager checks that a passcode has not been used in any previous authentication attempt. In a real-time replay attack, an intruder attempts to gain access with a captured passcode by capturing a passcode as a user logs on and submitting the same passcode to another application to log on within the acceptable time frame.



RSA Authentication Manager Architecture Checklist

Action Item

Understand the roles that the primary instance and replica instance play.

Understand how replication works.

Understand which data is replicated by Authentication Manager.

Decide how user and user group data is stored:• In the internal database• In an LDAP directory

Understand the parts of the Authentication Manager that enable authentication.

Understand the role of contact lists in load balancing.

Understand the methods of attack prevention provided by the Authentication Manager.



4 Planning RSA SecurID Protection• Overview of the Authentication Experience

• Deciding Which Resources to Protect with RSA SecurID

• Protecting Windows Desktops with RSA SecurID for Microsoft Windows

• RSA SecurID Protection Checklist

Overview of the Authentication ExperienceThe process of authentication is an interaction of three distinct products:

• RSA SecurID tokens

• Authentication agents

• RSA Authentication Manager

RSA SecurID TokensAn RSA SecurID token is a hardware device or a piece of software installed on a device (PC, Palm Pilot, Pocket PC, Blackberry) that generates and displays a random number that, when combined with a PIN, enables users to securely log on to a PC, network, or web page. The random number is called a tokencode.

In addition to the tokencode, RSA SecurID requires a PIN, either created by the user or Authentication Manager. You decide the requirements for creating PINs. For example, users tend to create easy to remember PINs that have personal relevance, such as birthdays or parts of telephone numbers. A co-worker who knows the user well may be able to easily guess a PIN. You can set PIN creation requirements that minimize the chance of this occurring.

Requiring both the tokencode and the PIN is known as two-factor authentication: something you have (the token and tokencode displayed on it) and something you know (the PIN). The tokencode and the PIN combined are called a passcode in the Authentication Manager system. The user presents the passcode at the logon prompt while trying to access a protected resource.

RSA Security, or your vendor, ships a token seed file that you must import into the data store. The seed file is used to generate the tokencode on Authentication Manager when an authentication request is received from an agent.

Authentication AgentsAuthentication agent software protects the resource. When installed on a machine, the authentication agent requires any user logging on to provide the correct RSA SecurID passcode, in addition to any other required logon information (such as User ID and network password).

4: Planning RSA SecurID Protection 47


RSA Authentication ManagerAs in any typical password-based system, the system must verify the password. For typical one-factor systems, a record of the user’s password resides somewhere on the network or system, and the provided password is compared with the stored record. If the two passwords match, the user is granted access.

Authentication Manager verifies the supplied passcodes, and responds to the request sent by the authentication agent, as shown in the following figure.

During an authentication, Authentication Manager and the agent software work in the following way:

1. A user initiates an authentication request by logging on to a system.

2. The agent software prompts the user to enter a User ID and an RSA SecurID passcode.

3. The agent software sends the entered data to Authentication Manager.The packets containing the data are encrypted using a shared key called a node secret, which is known only to Authentication Manager and the agent. The node secret itself is encrypted on the agent and in the database.

4. Authentication Manager receives the User ID and passcode and looks for the user record in a specified identity source. Authentication Manager stores information about the user in the internal database, or in an associated LDAP directory server, known in Authentication Manager as an identity source.

5. Authentication Manager calculates the correct value of the passcode by accessing the token record of the token assigned to the user, and, using data contained in the token record, generating the passcode.

6. If the passcode is correct, Authentication Manager approves the authentication request, and allows the user access to the network.

RSA Authentication Manager Model Machines withAuthentication Agent

Installed

RSAAuthentication

ManagerInstance

InternalDatabase

LDAP Directory

User with RSASecurID token

48 4: Planning RSA SecurID Protection


Deciding Which Resources to Protect with RSA SecurIDAuthentication Manager can protect a wide variety of resources, regardless of the method used to access those resources. The following sections list a number of access methods and refer to the products that can be used to provide that protection.

Protecting RSA Authentication Manager ServersBy default, administrative access to the RSA Security Console is protected by a static password that is subject to the password policies you configure in the Security Console. The Console is browser-based, and all connections through it are SSL-encrypted. You can easily configure Authentication Manager to require administrators to authenticate to the Security Console using RSA SecurID authentication. However, direct access to the machine itself is not protected until you install an authentication agent on it, and configure it to require authentication at log on.

Protecting Access Through a VPNAs illustrated in any of the scenarios, Authentication Manager protects connections through Virtual Private Networks, when used in conjunction with third-party VPN servers that embed the RSA Authentication Agent. For more information about supported VPN servers, search the Secured Partner Solutions Directory at http://rsasecurity.agora.com/rsasecured/.

Note: If you are protecting desktop access to the machine by installing RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows, a remote user is required to authenticate twice, once to gain access to the desktop, and again to access the network through the VPN.

Protecting Access Through a Radius ServerIf you already use RADIUS servers to authenticate users accessing your resources, Authentication Manager can accommodate RADIUS servers that contain an embedded authentication agent. A RADIUS server configured to handle RSA SecurID authentications forwards such requests to Authentication Manager, which processes the request and returns the result to the RADIUS server, that either allows or denies access to the user.

Protecting Access Through TACACSRSA Security provides an authentication agent that specifically supports the TACACS (Terminal Access Controller Access Control System) protocol for UNIX. The software and documentation for TACACS support is included on the RSA Authentication Manager 7.0 DVD or download kit.

Protecting Access to Outlook Web AccessAuthentication Manager protects end-user access to Microsoft Outlook e-mail accounts through the web interface (OWA) using the RSA Authentication Agent 5.3 for Web for Internet Information Services installed on a Microsoft Exchange server. See http://www.rsasecurity.com/node.asp?id=2807.



Protecting Access to Web PagesAuthentication Manager protects end-user access to individual web pages or entire web sites using the RSA Authentication Agent for Web on a variety of web server platforms, including Microsoft IIS, Apache and Sun Java Web Server. See http://www.rsasecurity.com/node.asp?id=2573.

Protecting FTP and Other UNIX-Based ProtocolsAuthentication Manager protects access to UNIX and LINUX systems when using system entry services such as login, dtlogin, passwd, rlogin, telnet, ftp and su, as well as OpenSSH, through the agent for UNIX or Linux, which implements the Pluggable Authentication Module (PAM) protocol. To download the agent, go to http://www.rsasecurity.com/node.asp?id=1177.

Protecting Access to a CITRIX ServerAuthentication Manager protects access to applications running on CITRIX. For more information, including implementation guides and solution briefs, go to http://rsasecurity.agora.com/rsasecured/.

Microsoft Windows DesktopsAuthentication Manager protects access to users’ local Windows desktops. See the following section, “Protecting Windows Desktops with RSA SecurID for Microsoft Windows.”

Protecting Windows Desktops with RSA SecurID for Microsoft Windows

RSA Authentication Manager 7.0 works with RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows to protect your company’s local Windows desktops. If the Authentication Agent is not enabled for users’ computers, users can log on to their desktops with only a Windows password. If the Authentication Agent is enabled, users must enter an RSA SecurID passcode in addition to their Windows password. If password integration is enabled, users can access their Windows desktops using only an RSA SecurID passcode.



The protection that the Authentication Agent provides for local Windows desktops is called local authentication. The following figure shows the RSA SecurID local authentication process.

Deploying the Authentication Agent in a Microsoft Windows EnvironmentThe following table describes the typical business needs for a medium-sized company employing 2,500 people in an environment that primarily uses Microsoft Windows and how you can use RSA SecurID for Microsoft Windows to satisfy those needs.

2. Authentication Managerverifies the passcode andsends the verification status tothe Authentication Agent.If the passcode is correct, theuser gains access to theWindows desktop.

1. During logon, the Authentication Agentprompts the user for an RSA SecurIDpasscode and passes it to theAuthentication Manager.

RSA Authentication ManagerUser's Computer withAuthentication Agent

Installed

Business Needs Solution

A simple, consistent, secure way for users to authenticate

• Integrate the Microsoft Windows password with the RSA SecurID logon so users need to provide only their passcodes.

• Configure authentication using RSA SecurID passcodes if the connection to the internal network becomes unavailable.

Different security policies for individual departmentsAn efficient way to manage the policies

• Assign users’ computers to authentication groups and manage security policies at the group level.

Efficient deployment of the Authentication Agent

• Create a preconfigured network installation package that you distribute or make available on the network. Users can install the Authentication Agent silently, without intervention.

An easy way for administrators to access non-administrative users’ desktops

• Exempt administrators from having to enter RSA SecurID passcodes to access users’ desktops.



The following figure shows a sample local authentication setup for a medium-sized company.

AuthenticationManagers

Internal Users(RSA SecurID for Microsoft W indows Local Authentication)

RSA SecurIDAuthentication

Required

Database Server

Local Authentication ClientComponent Installed andOffline Authentication Enabled

No Connection toAuthenticationManager

Database Server ServerNode

Data Data

ServerNode



Planning Which Users to ChallengeWhich users do you want to challenge? Do you want to exempt administrators from the challenge? You can configure the Authentication Agent to challenge:

• All users• A group of users• All users except a specified group of usersThe Authentication Agent uses default Windows groups (such as Domain Users or Dial-in Users), or groups that you create yourself using the Windows Computer Management interface. If you want to use non-default groups, you must create them before you configure the Authentication Agent.

For instructions on creating groups, see your Windows documentation. For instructions on configuring the RSA Authentication Agent, see the Authentication Agent Help topic “Specifying Users and Groups to Challenge With RSA SecurID.”

Planning the User Authentication ExperienceWhen planning the user authentication experience, consider these issues:

• Does your security policy require users to change their Windows passwords frequently?

• Are you concerned about users forgetting their Windows passwords?

• Do you want the authentication process to be the same whether users are online or offline to your corporate network?

The following sections describe how you can enhance the user experience.

Simplifying Logon Using Windows Password IntegrationWindows password integration incorporates the Microsoft Windows password into the RSA SecurID logon process. Integration allows users to access their Windows desktops using only their RSA SecurID passcodes.

One way to use password integration is to require users to provide Windows logon passwords during an initial connected authentication, and again when their passwords expire (for example, every 90 days, or in accordance with your security policy). When a user creates a new password, Authentication Manager stores it in the user’s record in the internal database. During subsequent authentications, the user provides only an RSA SecurID passcode. The Authentication Agent gets the Windows password from Authentication Manager and passes it to the Windows logon process, so the user does not have to enter the password.

When the password is about to expire, the user is prompted to create a new password. Ordinarily, to create a new password, you have to type your old password as well. However, the password expiration prompt automatically fills in the expiring password. Therefore, users never need to remember their passwords after entering them.

See “Windows Password Integration” in the chapter “Overview” in the RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows Installation and Administration Guide.



Offline AuthenticationYou can use offline authentication (available with the Authentication Manager Advanced license) to require users to authenticate to their Windows desktops with RSA SecurID passcodes even if their computer is not connected to the network. Users authenticate to their Windows desktops in the same way whether working online or offline.

The following figure shows how offline authentication works.

Security Policies for Offline AuthenticationYou can define separate offline authentication policies for individual departments. For example, suppose your Finance department has stricter security policies than the rest of the company. Finance employees can belong to the Finance security domain, while all other employees belong to the General security domain. The offline authentication policy for the Finance security domain might allow employees 10 offline days at a time and requires employees to change their Windows passwords every 60 days, while the policy for the General security domain might be more liberal. See the chapter “Offline Authentication” in the RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows Installation and Administration Guide.

RSA Authentication Manager

When the user attempts toauthenticate offline, theAuthentication Agent prompts theuser for RSA SecurID logoncredentials and verifies themagainst the locally stored offlinedata.

Connection

When the user is online,Authentication Managerdownloads offline data to theuser's computer.

User's Computer

BrokenConnection

Online

Offline

User's Computer With Offline Data




You create offline authentication policies through Authentication Manager, and you enforce the policies by assigning them to security domains. See “Setting Offline Authentication Requirements” in the chapter “Preparing RSA Authentication Manager for Administration” in the Administrator’s Guide.

Planning to Install RSA Authentication AgentThe following table lists the RSA Authentication Agent components and where to install them.

The following figure shows the setup for local authentication.

Planning Local Authentication DeploymentUse the following table to review the basic steps to deploy local authentication. All documentation references are in the RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows Installation and Administration Guide.

Component Location

RSA Authentication Manager On a secure computer

RSA Authentication Agent Local Authentication Client component

Every computer you want to protect with RSA SecurID


User's Computer

Component: Local Authentication Client

Deployment Steps Installation and Administration Guide Reference

1. Install and set up RSA Authentication Manager 7.0.

The chapter “Requirements and Preparations”

2. Create Microsoft Windows challenge groups.

“Create Groups of Users to Challenge with RSA SecurID” in the chapter “Requirements and Preparations”

3. Install the Local Authentication Client component on every computer you want to protect.

The chapter “Installing RSA Authentication Agent 7.0 for Microsoft Windows”



Creating a Preconfigured Network Installation PackageThe Authentication Agent must be installed on each computer whose desktop you want to protect. After the installation, each computer must be registered in the Authentication Manager internal database. In medium and large enterprises, these tasks can be time consuming. To expedite the process, you can create a preconfigured network installation package and make it available on the network. Users can access the package to install the software on their own, without performing complex configuration. See “Creating and Running a Network Installation Package” in the chapter “Installing RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows” in the RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows Installation and Administration Guide.

An installation package can include the Automated Agent Host Registration and Update utility. When installed on Agent host computers, the utility automatically registers the Authentication Agent in the Authentication Manager internal database, eliminating the need for manual registration. See the appendix “Automated Registration of Agent Hosts” in the RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows Installation and Administration Guide.

Planning Emergency AccessYou need to think about how users and administrators will access protected Windows desktops under unusual circumstances. Emergency access enables users and administrators to access protected resources when users lose their tokens, forget their PINs, or run out of offline days.

4. If you are using Dynamic Host Configuration Protocol (DHCP) to assign IP addresses, install and configure the Automated Agent Host Registration and Update utility on the protected computers.

The appendix “Automated Registration of Agent Hosts”

5. Start RSA Security Center. “Step 2: Start RSA Security Center” in the chapter “Installing RSA Authentication Agent 7.0 for Microsoft Windows”

6. Verify the status of the authentication environment and perform a test authentication.

“Step 3: Verify the Status of the Authentication Environment” and “Step 4: Test Authentication” in the chapter “Installing RSA Authentication Agent 7.0 for Microsoft Windows”

7. Configure local authentication. The chapter “Configuring Local Authentication”

Deployment Steps Installation and Administration Guide Reference



Administrators who install and configure software for non-administrative employees need access to users’ computers. To facilitate this, you can configure the Authentication Agent to challenge everyone for passcodes except administrators. To do this, create a Windows group for administrators on the Authentication Agent host computer, and challenge all users except members of the administrative group.

You can also add the Exempt Administrator Account to a network installation package. This saves the administrator the time of setting up the exempt group manually on each individual Authentication Agent host computer. See “Exempt Administrator Account” in the chapter “Overview” and “Creating and Running a Network Installation Package” in the chapter “Installing RSA Authentication Manager 7.0 for Microsoft Windows” in the RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows Installation and Administration Guide.

For more information about all emergency access methods, see “Planning Emergency Access” on page 102.

Preparing the RSA Authentication Manager DatabaseHow do you want to add user records to the Authentication Manager database? Do you currently maintain user records in an LDAP database? To facilitate RSA SecurID protection for Windows desktops, you must register every user that you want to challenge as an RSA SecurID user in the Authentication Manager internal database. You can add user records to the internal database manually, or use your existing Active Directory or LDAP directory. See the chapter “Preparing RSA Authentication Manager for Administration” in the Administrator’s Guide.

Preparing UsersHow will you instruct users on how to authenticate with RSA SecurID? After you register users in the Authentication Manager internal database and deploy enabled tokens, you must instruct users about the authentication process and how to use their tokens. See Chapter 10, “Planning RSA SecurID Token Deployment” on page 107.

Preparing Help Desk AdministratorsHow will you educate Help Desk Administrators about assisting employees who authenticate using RSA SecurID? Users get emergency codes and lost token passwords from their Help Desk Administrators. Therefore, you must devise a plan for educating Help Desk Administrators about authenticating and emergency access methods. See “Planning RSA Authentication Manager Training for Help Desk Administrators” on page 94.



RSA SecurID Protection Checklist

Action Item

Determine which methods of access you want to protect with RSA SecurID authentication.

Decide which resources you want to protect:• Authentication Manager Server• VPN connections• RADIUS Server• Microsoft Access e-mail accounts• Web pages• UNIX server• Citrix server• Windows desktops

To protect Windows desktops

Decide which users you want to challenge with RSA SecurID passcodes.

Decide whether you want to challenge users for RSA SecurID passcodes when they authenticate offline from the network.

Decide whether you want users to enter Windows passwords and passcodes, or only passcodes.

Decide whether you want to challenge administrators for their RSA SecurID passcodes.

Decide which emergency access methods you want to use.

Decide whether you want to register Authentication Agent hosts manually or automatically using the Automated Agent Host Registration and Update utility.

Decide how you want to install the Authentication Agent software.



5 Assessing System and Security Requirements• System Requirements

• Planning Management of the Master Password

• Planning Physical Security

• System and Security Requirements Checklist

System RequirementsMake sure your system meets these requirements for supported platform and system components.

Note: Machines hosting the primary instance, replica instances, and server nodes must all use the same operating system.

Important: In a multi-node deployment, performance and scalability are affected by the hardware on which the database server and server nodes are installed. The database server handles authentication requests from the server nodes, as well as administration connections through the server nodes. The primary instance database server has the additional burden of handling all replication to and from the replica instances. In terms of CPU speed, memory, and disk speed, RSA Security recommends that the database server be significantly more powerful than the server nodes, and that the primary instance database server be the most powerful machine in your deployment.

5: Assessing System and Security Requirements 59


Windows System Requirements

Linux System Requirements

Operating System Microsoft Windows Server 2003 Enterprise, SP1 (32-bit)

Hardware Intel Xeon 2.8 GHz or equivalent

Disk Space 60 GB free space recommended20 GB free space minimumDisk space usage depends on the scale of your deployment. With high numbers in excess of 1,000,000 token users, logging and archiving may take up greater amounts of space.Important: Do not allow all disk space to become consumed. At that point, Authentication Manager may stop operating and be difficult to restore.

Memory Requirements 2 GB

Page File 2 GB

Operating System Red Hat Enterprise Linux 4.0-1 ES (32-bit x86)

Hardware Intel Xeon 2.8 GHz or equivalent

Disk Space 60 GB free space recommended20 GB free space minimumDisk space usage depends on the scale of your deployment. With high numbers in excess of 1,000,000 token users, logging and archiving may take up greater amounts of space.Important: Do not allow all disk space to become consumed. At that point, Authentication Manager may stop operating and be difficult to restore.

Memory Requirements 2 GB

Swap Space 2 GB

Kernel Version 2.6.9-22.EL and later

Kernel Parameters Maximum shared memory must be at least 256 MB

60 5: Assessing System and Security Requirements


Supported BrowsersThis section describes the browsers supported for the RSA Security Console. Browser support differs between Windows and Linux platforms.

On Windows• Internet Explorer 6.0 with SP2

• Firefox 1.0.7 and later

On Linux• Firefox 1.0.7 and later

Note: On all browsers, JavaScript must be enabled. Internet Explorer may require configuration depending on your security level.

For instructions on enabling JavaScript, see “Logging On to the RSA Security Console” in the Installation and Configuration Guide.

Packages (RPM) The following packages (or later versions) must be installed:binutils-2.15.92.0.2-12compat-db-4.1.29-5compat-libstdc++-296.2.9.6-132.7.2coreutils 5.2.1-31.2 or latercontrol-center-2.8.0-12gcc-3.4.3-22.1gcc-c++-3.4.3-22.1gnome-libs-1.4.1.2.90-44.1glibc-common-3.4.3-22.1glibc-2.3.2-95.20initscripts 7.93.20 or later libstc++-3.4.3-22.1libaio-0.3.96make-3.80-5libstc++-devel-3.4.3-22.1pdksh-5.2.14-30setarch-1.6-1 sysstat-5.0.5-1xscreensaver-4.18-5Note: To check your RPM versions on Linux, use the command, rpm -q package name.



Maintaining Accurate System Time SettingsAuthentication Manager relies on standard time settings known as Coordinated Universal Time (UTC). The time, date, and time zone settings on computers running Authentication Manager must always be correct in relation to UTC.

Make sure that the time on the computer on which you are installing Authentication Manager is set to the Local Time and corresponds to the Coordinated Universal Time (UTC). For example, if UTC is 11:43 a.m. and Authentication Manager is installed on a computer in the Eastern Standard Time Zone in the United States, make sure the computer clock is set to 6:43 a.m. This differs during daylight savings time.

To get UTC, go to www.time.gov.

Note: If you employ an NTP service, enable it on the primary instance only. The primary instance typically maintains the replica instance’s time synchronization automatically.

Planning Port UsageAuthentication Manager requires open port numbers to enable authentication, administration, replication, and other services on the network. Configure your system to open the required ports for Authentication Manager.

Port Number Protocol Service Description

1161 UDP SNMP Agent Used to communicate with a Network Management System using the Simple Network Management Protocol.

1162 UDP SNMP Agent Used to communicate with a Network Management Server using the Simple Network Management Protocol.

2334 TCP Oracle DB Used to replicate data between instances.

5500 UDP Agent authentication Used for communication with authentication agents. This service receives authentication requests from agents and sends replies.

5550 TCP Agent auto-registration Used for communication with authentication agents that are attempting to register with Authentication Manager.



RSA Security recommends that you reserve these ports for Authentication Manager, and make sure no other applications or services are configured to use them.

Planning for Peak Authentication PeriodsIt is likely during daily operation that your users will log on to the network at specific times, requiring Authentication Manager to authenticate large numbers of users in a relatively short time frame. These peak authentication times usually occur when employees arrive at work and after they return from lunch. If you have multiple geographic sites, peak authentication periods may occur throughout the day. Determine the times each day that the highest rates of authentication occur.

For example, FocalView Software has offices in Boston and San Jose. The three hour time difference means that peak authentication periods may occur from 8:00 a.m. - 9:00 a.m. (when employees in Boston arrive to work), 11:00 a.m. - 12:00 p.m. (when employees in San Jose arrive to work), 1:00 p.m. - 2:00 p.m. (when employees in Boston return from lunch), and 3:00 p.m - 4:00 p.m. (when employees in San Jose return from lunch).

The use of a replica instance in San Jose and the contact list feature of Authentication Manager help to alleviate some of the burden of the peak authentication period. RSA Security recommends that you monitor the CPU performance of Authentication Manager during these peak periods in order to gauge the effect on your system.

5580 TCP Offline Authentication service

Used to receive requests for additional offline authentication data, and send the offline data to agents.

7002 TCP RSA Security Console/SSL Used for SSL-encrypted administration connections.

7004 TCP RSA Security Console proxy server/SSL

Used for load balancing of administration in an instance with multiple server nodes. This port is used for SSL connections.

7006 TCP WebLogic administration console/SSL

Internal use only.

7008 TCP WebLogic administration console override/SSL

Internal use only.

7012 TCP RSA Security Console override/SSL

Internal use only.

7014 TCP RSA Security Console proxy server override/SSL

Internal use only.

Port Number Protocol Service Description



Planning Management of the Master PasswordSecure the set of Authentication Manager passwords.

It is imperative that you secure the master password, as it protects all of the system passwords required to run Authentication Manager. The master password is specified during the installation of the primary instance, and is the same as the Super Admin password. The master password is required in the following situations:

• To install server nodes and replica instances

• To encrypt and decrypt protected data in the internal database

• To run Authentication Manager command line utilities that enable you to perform tasks like archiving log files, importing secure sockets layer (SSL) certificates, and managing other system passwords

As part of failover and disaster recovery planning, the master password can be exported as part of a backup of all of the system passwords, and exported to an encrypted, password-protected file. When recovering from a failure, the file can be imported back into the system. RSA Security strongly recommends storing the exported file in a safe and secure manner.

Planning Physical SecurityEnsure the physical security of the equipment running Authentication Manager by following any existing corporate guidelines your company has already instituted. RSA Security recommends locating the equipment in a locked location accessible to the minimum number of required, trusted personnel.

Minimize the number and types of connections that can be made to the Authentication Manager machine. Block access through ports that are not necessary to the functionality of Authentication Manager. See “Planning Port Usage” on page 62.



System and Security Requirements Checklist

Action Item

Determine if your designated systems meet all of the Authentication Manager requirements.

Determine which browsers will be used to access the RSA Security Console.

Ensure that you have the ability to open all of the ports that Authentication Manager requires to be open.

Determine when the highest rates of authentication occur on your system.

Plan how you will store the Authentication Manager master password.

Determine if you need to protect Authentication Manager machines with RSA SecurID authentication, and make sure that you have the appropriate authentication agent software.



6 Planning for Failover and Disaster Recovery• Key Issues to Consider

• Planning for Possible Failure Situations

• Planning Regular Database Backups

• Disaster Recovery Checklist

Key Issues to ConsiderThis chapter guides you through the process of creating a plan for recovering a failed primary instance, replica instance, or non-database server node. The failure of an instance or server node can substantially affect authentication throughput. If and when a failure occurs, you must respond quickly and effectively. To prepare for a disaster recovery situation, familiarize yourself with these issues:

• How can I detect an instance failure?

• Why would an instance fail?

• How does the failure of a primary instance or replica instance affect administration and authentication performance?

• What are the recovery steps I need to go through if an instance fails?

• How can I plan regular database backups to ensure against data loss?

Planning for Possible Failure Situations

Detecting a Failed Primary or Replica InstanceUse the Manage Replication utility to detect any failed instances. See the chapter “Disaster Recovery,” in the Administrator’s Guide.

Why an Instance Might FailYou need to familiarize yourself with different failure situations so that you can respond quickly during an actual failure. A primary instance or replica instance might fail for any of the following reasons:

• Power failureIn this case, you know that the instance can be restarted when power is restored. You probably do not need to take further action. When the primary instance is restarted, Authentication Manager synchronizes the databases.

6: Planning for Failover and Disaster Recovery 67


• Hardware failure Estimate the level of effort required to replace the hardware component. Take into account the fact that you might have to reinstall Authentication Manager for all server nodes in the instance.

• Database corruption If runtime or console error messages indicate that the database is corrupted, you can assume that all databases in the deployment are also corrupted. You must restore the primary instance database from a previous backup using the Manage Backups utility.

• Inoperable database A database is inoperable if it runs out of disk space, or if its configuration prevents Authentication Manager from accessing it. If the surviving replica instance appears to function normally, you need to promote the replica instance to be a primary instance. See the chapter “Disaster Recovery,” in the Administrator’s Guide.

• Network failure When Wide Area Network (WAN) connectivity is lost between a replica instance and a primary instance, the disconnected replica instance can neither send nor receive database updates. Transactions sent to the replica instance quickly queue up, consuming valuable disk space. Consider removing the replica instance from the system. After removal, agents update their contact lists and stop routing transactions to the disconnected server node. You can add another replica instance to improve performance.

What Happens After the Primary Instance FailsWhen a primary instance database server fails, the following events occur:

• You cannot administer the system. You can read administrative data through a replica instance, but you cannot modify this data until a new primary instance is configured (a replica instance is promoted) or the original one is restarted.

• Authentication performance slows down. All server nodes that connect to the database stop functioning and do not process runtime or administrative requests.

• Help Desk Administrators are blocked.

• Users who are permanently locked out cannot be restored. Users who are locked out for a specific length of time because of authentication failures can be restored.

• You lose the copy of the database that resides on the failed database server, increasing general failure risk.

• Data accumulates at replica instances, waiting to update the primary instance. In extreme situations, disk space might fill up.

• You lose all database updates that occurred on any replica instances after the primary instance failed, plus any updates that occurred at the primary instance but were not yet propagated to all replica instances before the failure.

68 6: Planning for Failover and Disaster Recovery


Planning Recovery If a Primary Instance Fails Follow these guidelines to ensure quick recovery if the primary instance fails.

• Set up a replica instance at the same geographic site where the primary instance is located. The same personnel who administer the primary instance can easily access this local replica instance in case of emergency.

• Train your staff to learn recovery procedures and make sure they have the necessary privileges to promote a replica instance if the primary instance fails. If your staff is familiar with these steps before a real emergency occurs, they can anticipate what needs to be done and act quickly if the primary instance actually fails. See the following section, “Recovery Process Steps.”

• If you are deploying software tokens using remote token key generation, the token key generation URLs and service addresses that you have distributed to users, but that users have not yet used, become invalid when a primary instance fails. If your proxy server supports failover mode, you can configure it to pass CT-KIP data to the new primary instance. This allows users to use the original token key generation URLs and service addresses and saves administrators from the task of sending new URLs to users. See “Using Remote Token Key Generation to Deploy Software Tokens (CT-KIP)” on page 112.

Recovery Process StepsBefore a real emergency occurs, review these steps for recovering a primary instance or promoting a replica instance.

• “Step 1: Determine Whether the Primary Instance Can be Recovered” on page 69

• “Step 2: Promote a Replica Instance” on page 70

• “Step 3: Reattach and Resynchronize the Replica Instances” on page 70

• “Step 4: Replace the Promoted Replica Instance” on page 70

For detailed instructions on promoting, reattaching, and resynchronizing replica instances, see the chapter “Disaster Recovery,” in the Administrator’s Guide. The following sections provide more information about each step.

Step 1: Determine Whether the Primary Instance Can be RecoveredAt the site where the primary instance is located, trained and authorized personnel must decide whether to fix the problem that caused the instance failure, or to promote a replica instance to take over for the failed primary instance. When deciding whether to recover the failed primary instance, consider these issues:

• How long do you estimate the primary instance will be unavailable?

• Can the problem be fixed?

• Does the surviving replica instance have enough disk space to handle transactions that will queue up while the primary instance is down?

If you cannot recover the primary instance, go to step 2: “Step 2: Promote a Replica Instance”.



Step 2: Promote a Replica InstanceIf the primary instance cannot be recovered, you need to promote a replica instance as soon as possible. During the promotion, the original primary instance is automatically detached from all replica instances in the deployment. All configuration data referring to the original primary instance is removed from all replica instances.

When selecting a replica instance for promotion, choose the one that contains the most current data.

During the promotion process, the replica being promoted is temporarily offline. The other replica instances continue to process runtime requests while the new primary is being promoted. When the primary instance goes online, the replica instances forward the request records.

Step 3: Reattach and Resynchronize the Replica InstancesBecause all replica instances were detached from the original primary instance during promotion, you must manually reattach them to the new primary instance. After reattaching, any changes that occurred on the replica instances since the detachment are propagated to the new primary.

You also need to resynchronize data for all instances with the new primary instance, to ensure identical data at each instance. The replica instance is reinitialized with data from the new primary instance, including the changes that the primary instance just received from the replica instance. Replica instances being resynchronized are temporarily offline, but the primary instance continues to process administrative and authentication requests.

Step 4: Replace the Promoted Replica InstanceEstablish a new replica instance to replace the promoted instance as soon as possible. The network is vulnerable to further decreases in service until the lost instance is restored.

What Happens If a Replica Instance FailsWhen a replica instance fails, the following events occur:

• Administrative capabilities continue as usual, since they are performed at the primary instance.

• Authentication performance slows down. This decline might continue even after the failed instance is repaired and brought back online, while the databases is being synchronized with other instances.

• You lose the copy of the database that resides on the failed database server, increasing the general failure risk.

• Data flowing to this instance is queued in the primary instance database server, potentially filling up disk space. The consumption of disk space depends on how many transactions the replica handles per hour or day. After you restart the failed replica instance, the queued data updates it.



Planning Recovery If a Replica Instance FailsIf a failed replica instance cannot be recovered, remove the failed replica instance from the system and install a new replica instance as soon as possible to ensure failover and scalability. See the chapter “Installing a Replica Instance for Failover,” in the Installation and Configuration Guide.

Important: RSA Authentication Agents route authentication requests to specific replica instances based on information defined in an automatic contact list, manual contact list, or an sdconf.rec file. When you configure the agents, make sure they point to multiple replica instances. If an agent is configured to use just one replica instance and that instance fails, transactions intended for the failed replica instance queue up and consume valuable disk space.

Planning Recovery from the Loss of a Non-Database Server NodeWhen you lose a server node that does not host a database server, the instance where the server node resides continues to function, with the following consequences:

• Authentication throughput performance declines for the entire instance, especially during peak authentication periods.

• Uncommitted, partial transactions being processed at the time of failure are lost.

If the node is down for an extended period of time, consider removing the server node from the deployment and replacing it. After you replace it, agents update their contacts lists, stop sending transactions to the failed server node, and instead use the new server node.

Planning Regular Database BackupsThe Manage Backups utility backs up and restores all data in the database, including configuration, policy, log, users, and groups, in one operation.

Note: The utility backs up the entire database at once. You cannot back up only part of the database.

Why You Must Perform BackupsReplica instances can be considered backups of the primary instance. However, data can still be lost if you inadvertently delete data from the primary instance and that mistake is propagated to the replicas. Using the Manage Backups utility on a regular basis can help minimize this type of data loss.



Formulating a Backup PolicyDecide how often you need to create backups and where to store backup data. Different organizations have different needs and requirements. Consider these issues:

• How critical is the data?

• What regulations does your industry require you to follow?

• How much data can you afford to lose in the event of a crash? To minimize data loss, perform frequent backups.

• Because the backup operation can affect general system performance, consider running backups during off-peak periods. The database can still service requests while you perform the backup.

Many organizations store one backup copy at an off-site location.

Automated BackupsYou can automate database backups by writing a script that calls the Manage Backups utility. Make sure the script sends the data either to a disk that is separate from the actual database, or to tape. These measures prevent a single point of failure for the database and backup. See the chapter “Disaster Recovery” in the Administrator’s Guide.

Disaster Recovery Checklist

Action Item

Create a plan for recovering a failed primary instance, replica instance, or non-database server node.

Understand how replication works so you can make appropriate decisions if an instance fails.

Know how administrative and runtime changes are propagated to the replica instances.

Learn how to monitor the status of each instance and detect any failures.

Familiarize yourself with different failure situations so that you can respond quickly during an actual failure.

Understand the consequences of losing a primary instance, replica instance, or non-database server node.

Review the steps for recovering a primary instance or promoting a replica instance.

Learn how to use the Manage Backups utility to back up the primary instance database.

Develop a backup plan. Decide how often you need to create backups and where to store backup data.

Write a script to automate backups.



7 Planning Your Installation• Assessing Required Permissions for Installation

• Planning Your RSA Authentication Manager Installation

• Planning Primary Instance Installation

• Planning Replica Instance Installation

• Planning Server Nodes Installation

• Planning LDAP Directory Integration

• Planning Active Directory Integration

• Planning Sun Java System Directory Server Integration

• Conducting a Pilot Test

• Installation Checklist

Assessing Required Permissions for InstallationThe installation process often requires coordination among the people who have permissions to access and administer the various components in your network. Use the following planner to document the personnel whom you need to coordinate for access to the components of your network during installation.

Component Component Administrator

Administrator Who Needs Access

Operating system

Firewall portals

Virtual Private Network (VPN) server

Wireless router

Protected resources

Desktop machines

Primary instance, replica instances, and server nodes

Web server

Proxy server

7: Planning Your Installation 73


Planning Your RSA Authentication Manager InstallationDevelop a plan for the physical installation of instances and server nodes. Plan to install your primary instance first because certain information is required from the installed primary instance before you can install replica instances or server nodes.

Consider the following factors to include in your installation plan:

• “Minimum Requirements for Machines”

• “License Permissions”

• “The Necessary Level of Security”

• “Personnel to Perform the Installation”

• “The Best Time to Perform the Installation”

• “Access Through Firewalls”

• “Access Through Proxy Servers”

• “Migrating Users from an Existing RSA ACE/Server or RSA Authentication Manager Deployment”

Authentication agents

Outlook Web Access (OWA) server

Citrix Presentation server

Internet Authentication Server (IAS)

Remote Authentication Dial-In User Service (RADIUS)

Domain controllers

Pluggable Authentication Module (PAM) protected server

RSA Authentication Manager internal database

Active Directory identity source

Sun Java System Directory Server identity source

Component Component Administrator

Administrator Who Needs Access

74 7: Planning Your Installation


Minimum Requirements for MachinesThere are minimum requirements for the machines used for Authentication Manager. Consider whether the minimum requirements are sufficient for your authentication and administrative activity. If not, you may need to include more powerful machines in your plan. See “System Requirements” on page 59. All machines in your deployment must run the same operating system.

License PermissionsYour installation personnel need to understand how the license type impacts the installation of Authentication Manager. Review these license types with your installers:

• Base License. Allows a primary instance and one replica instance. (Multiple replica instances and server nodes are not allowed.)

• Advanced License. Allows a primary instance plus multiple replica instances and server nodes.

The Necessary Level of SecurityPlan the level of security you require for assets and users. You might require different levels of authentication from some users than from others.

Consider the following factors:

• The degree of authentication required for each asset that you want to protect

• The degree of authentication required for each type of user

• The number of security domains you require

• Which assets to place in which security domains

Personnel to Perform the InstallationPrimary instances, replica instances, and server nodes are core components of the Authentication Manager system. They contain sensitive data and administrative information. RSA Security recommends that only your most trusted personnel perform your Authentication Manager installations. If your plan requires installing replica instances and server nodes in more than one geographic location, plan for trusted personnel to do so in each location.

The Best Time to Perform the InstallationDevelop a timetable for installation. To perform the installation with minimal disruption to your employees and customers, consider the following:

• The number of replica instances and server nodes to install

• The total amount of time that it will take for the installation

• Your system’s peak and off-peak usage times

• Your business hours

• The possible effect on your offices in other time zones

• The hours specified in your support plan when RSA Security support is available



Access Through FirewallsPlan which ports to open for Authentication Manager communications.

RSA Security recommends that you install all Authentication Manager servers behind a firewall. To enable authentication through firewalls and accommodate Network Address Translation (NAT), the RSA Security Console allows you to configure alias IP addresses for your Authentication Manager instances and alternate IP addresses for your authentication agents. You can assign four distinct IP addresses (the original IP address and up to three aliases) to each Authentication Manager instance. You can assign an unlimited number of alternate IP addresses (one primary IP address) to your agents.

Your installers need to know the agent’s primary and alternate IP addresses and the Authentication Manager primary IP address and aliases for each instance. If your deployment includes multiple locations, your installers also need to know the ports used for Authentication Manager communications and processes (such as replication). You may need to open some new ports in your firewall, or clear some existing ports for your deployment. See “Planning Port Usage” on page 62.

Access Through Proxy ServersIf your deployment includes multiple agents (Authentication Agent for Windows and Authentication Agent for Web) behind your proxy server, and Authentication Manager is on your internal network, plan to configure alias IP addresses in Authentication Manager for each agent host. Plan to configure your proxy server in such a way that each agent has a one-to-one IP address mapping to the proxy server internal IP address, and use this alias IP address for the respective agent host.

Migrating Users from an Existing RSA ACE/Server or RSA Authentication Manager Deployment

To migrate users and tokens from an existing deployment of RSA ACE/Server 6.0 or RSA Authentication Manager 6.1 to your new RSA Authentication Manager 7.0 deployment, you can use the Migration utility.

The Migration utility is available from RSA SecurCare Online at https://knowledge.rsasecurity.com.



Planning Primary Instance InstallationSelect a machine for your primary instance. There is only one primary instance per deployment. All other instances are replicas.

Your consolidated log file is located on your primary instance. Administrators who have permission to read the log file will need access to this machine.

Note: You must install the primary instance before you can create replica and node packages, which are required for replica instance and server node installation.

The Machine for the Primary InstanceThe machine on which the primary instance is installed must meet minimum requirements. See “System Requirements” on page 59. If your deployment requires higher specifications, plan to acquire and prepare a machine accordingly.

Planning Replica Instance InstallationPlan the number, requirements, and locations of your replica instances. Plan where to locate them to provide for failover, disaster recovery, and local authentication for geographically dispersed offices.

To link a replica instance to a primary instance, you must first install the primary instance and then gather data from it for use in the replica instance installation. Remember, you must have an Advanced license to install more than one replica instance.

Adding a replica to your system means that you need to plan for additional hardware because the replica instance must be installed on a machine other than the primary instance. It is recommended that you install at least one replica instance for failover and disaster recovery.

If you have the Base license, you can install one replica instance. If you have the Advanced license, you can install up to 5 replica instances.

The Machine for the Replica InstanceThe machine on which the replica instance is installed must meet minimum requirements. See “System Requirements” on page 59. If your deployment requires higher specifications, plan to acquire and prepare a machine accordingly.



Planning Server Nodes InstallationTo further enhance authentication performance, you can add server nodes. You must have the Advanced license to add server nodes. Consider whether you need to add server nodes to some, or all, authenticating servers to increase authentication performance.

Server nodes must be installed on the same platform as the primary instance or replica instance, for example, Microsoft Windows or Linux. The host for the server node must be in the same subnet as its primary instance or replica instance database server.

You must first install your primary instance and any replica instances to which you want to add a server node. These selected servers must be prepared by gathering data from them for use in the server node installation. See “Preparing to Install a Server Node” in the Installation and Configuration Guide.

Note: Authentication Manager is not compatible with third-party UDP load balancing products.

The Machine for the Server NodeThe server node machines must meet minimum requirements. See “System Requirements” on page 59. If your deployment requires higher specifications, plan to acquire the necessary hardware.

Planning LDAP Directory IntegrationDevelop a plan for integrating your external directory server with Authentication Manager.

If your deployment includes using an external directory server, then it must be integrated with Authentication Manager. The relationship of the Authentication Manager internal database to an external one is that users, user groups, and custom attribute data are stored in the external identity source. All other data, including agent and token data, is stored in the internal database.

Authentication Manager enables you to integrate LDAP identity sources without modifying the LDAP schema, which makes installation easier. Integrating LDAP requires running the Initialize Identity Source utility. The administrators then use the RSA Security Console to create the identity source record and map Authentication Manager attributes to the LDAP attributes.

All information that is specific to Authentication Manager, such as Authentication Manager security policies and user-token associations, resides only in the internal database. Linkages between Authentication Manager information and LDAP user records are also maintained in the internal database.

RSA Security recommends that you install Authentication Manager on a different machine than your LDAP server. This provides greater security, enables you to lock down one of the machines in an emergency, and enhances performance. Both machines must be on the same network.



Consider the following factors before you integrate your external identity source with Authentication Manager:

• Supported external identity sources

• Selecting read-only or read/write

• Establishing security

• Performing the integration

• Mapping attributes

• Physical co-location of replicated LDAP directory instances with Authentication Manager instances.

Supported External Identity SourcesAuthentication Manager supports Windows Server 2003 Active Directory and Sun Java System Directory Server 5.2.

Selecting Read-Only or Read/WriteAuthentication Manager supports either read-only or read/write operations on your LDAP directory. You must select either Read-Only or Read/Write when you connect Authentication Manager to your identity source. Consider your decision carefully because to change it you must delete and redefine the identity source definition.

Read-Only

• You cannot make changes to the data in your LDAP directory through the RSA Security Console.

• You must make changes to the data in your LDAP directory through the LDAP directory’s native user interface.

Read/Write

• You can manage users and make changes to the data in your LDAP directory through the RSA Security Console and your LDAP directory’s native user interface.

• You can use Authentication Manager to push changes in the LDAP directory’s data to the primary and replica instances.



Establishing SecurityRSA Security recommends that you encrypt data in transit between Authentication Manager and your identity source. Authentication Manager provides an encrypted Secure Sockets Layer (SSL) certificate of authority in your domain controllers that connect to your LDAP server. This protects the data in transit. An SSL certificate is required for Active Directory. It is optional for Sun Java System Directory Server.

To establish SSL, you import a certificate of authority from Authentication Manager and register it on your LDAP directory server. Plan to do this on each LDAP directory server for which you want an SSL connection to Authentication Manager.

For Active Directory there are additional important considerations for password policies and group membership support. See “Overview of LDAP Directory Integration” in the Installation and Configuration Guide.

Performing the IntegrationRSA Security recommends that you select a technician with a background in LDAP and knowledge of your directory server deployment to perform your integration. Some of the tasks require using the Initialize Identity Source utility and others are performed through the RSA Security Console.

Depending on your configuration and LDAP directory, there may also be important tasks to prepare the directory for integration. See “Overview of LDAP Directory Integration” in the Installation and Configuration Guide.

The integration process is as follows:

• Prepare for integration

• Deploy resource adapters using the Initialize Identity Source utility

• Add the identity source

• Link the identity source to a realm

• Verify the identity source

Mapping AttributesYour LDAP directory contains attributes about the data that it contains, just as Authentication Manager contains attributes about the data that it contains. You need to map the attributes in Authentication Manager to those in your LDAP directory, so that they can communicate. This is accomplished through the RSA Security Console, where you map users, user groups, and a limited number of custom attributes.

Before you begin mapping, gather the following information:

• The names of the attributes in Authentication Manager

• The names of the attributes in your LDAP directory

• Your plan for which attributes to map to each other

Use the following checklists to plan your mapping strategy.



For mapping users:

For mapping user groups:

Planning Active Directory IntegrationYou have many decisions to make when integrating Windows Server 2003 Active Directory as your identity source. Some of them are irreversible. Others are costly to reverse. RSA Security recommends that you seek people who are extremely knowledgeable about Active Directory, your network topology, and your business requirements for using Authentication Manager to plan your Active Directory integration.

Authentication Manager Attribute Maps to Your LDAP Directory Attribute

First Name

Middle Name

Last Name

User ID

E-mail

Certificate DN

Password

Authentication Manager Attribute Maps to Your LDAP Directory Attribute

User Group Name

Search Filter

Search Scope

RDN Attribute

Object Classes

Membership Attribute

User Membership Attribute

Required Attribute

Base DN



Consider what information and personnel you need to perform the process of integrating Active Directory. Plan how you want to configure User Groups and Users. The following process applies to each Active Directory that you integrate.

1. Add the Active Directory server to Authentication Manager.

2. Select directory settings.

3. Map attributes.

4. Install and enable the Certificate of Authority.

When this process is completed, you can securely connect to the Active Directory through the RSA Security Console.

Active Directory Forests

There is no requirement to deploy an additional forest when you need to create non-contiguous DNS namespaces for your enterprise. You can create two domain trees. For example, one is rooted at your-company.com and the other is rooted at your-company-europe.com. The Active Directory concept of Domain Tree supports this configuration.

Active Directory forests are commonly used in the following situations:

• Autonomous administrationIf your organization contains multiple divisions working with different schemas and configuration models, or if you cannot unify pre-existing environments, consider adding a new forest.

• Access isolationIf you need to isolate certain divisions, or personnel, consider adding a new forest. Establishing multiple forests with no trust between them is a possible solution when you have regulatory requirements to guarantee that certain users cannot gain access to certain resources.

Active Directory has a default password policy that is stricter than the Authentication Manager policy. This can cause errors when adding and updating users. To prevent this, you must either relax the Active Directory requirements or make the Authentication Manager requirements stricter.

Global CatalogsWhen configuring your deployment, you must link all Active Directories and your Global Catalog to your realm.

You can use a Global Catalog with Authentication Manager as a normal domain, rather than as a runtime identity source with a domain identity source. This approach eliminates the complexity of configuring an identity source for every single domain in the forest and having to establish the associations between the domain identity sources and the runtime identity sources.



Planning Sun Java System Directory Server IntegrationWhen integrating Authentication Manager with Sun Java System Directory Server, you have the option to establish a Secure Sockets Layer (SSL).

If you want to establish a SSL, plan to import a certificate of authority from Authentication Manager and enable it on your Sun Java System Directory Server. Plan to do this on each Sun Java System Directory Server for which you want an SSL connection to Authentication Manager.

Consider what information and personnel you need to perform the process of integrating Sun Java System Directory Server. Plan how you want to configure user groups and users. The following process applies to each Sun Java System Directory Server that you integrate.

1. Add the Sun Java System Directory Server to Authentication Manager.

2. Select directory settings.

3. Map attributes.

Conducting a Pilot TestYou can perform a pilot test of Authentication Manager to learn the basics of installing a primary instance, a replica instance, a server node, an agent, and to perform a test authentication in advance of your live deployment. Other advantages include safely testing:

• System connections

• Disaster recovery

• Administrative tasks

• Reports

Consider the following when you plan your pilot test:

• The scope of the test

• How much hardware you will need

• How much disk space is required

• Your time frame for staging and performing the test

• The types of disaster recovery to test

• The number and types of authentication to test



Installation Checklist

Action Item

Coordinate access to your network components.

Develop a plan for the physical installation of instances and additional server nodes.

Assess your machine requirements.

Understand how the type of license affects your deployment plan.

Plan the level of security you require for assets and users.

Assign personnel to installation tasks.

Develop a timetable for installation.

Plan which ports to open for Authentication Manager communications.

Select a machine for your primary instance.

Confirm that the primary instance machine meets minimum requirements.

Plan the number, requirements, and locations of your replica instances.

Confirm that replica instance machines meet minimum requirements.

Select and prepare one or more machines for server node installation.

Confirm that server node machines meet minimum requirements.

Confirm that your external directory server is supported.

Develop a plan for integrating your external directory server with Authentication Manager.

Decide which tool you want to use to manage users in your identity source.

Plan to protect data in transit between Authentication Manager and your identity source.

Understand the LDAP directory integration process.

Determine if you want Authentication Manager to have read access or read/write access to your directory.

Select any Authentication Manager attributes that you want to map to your LDAP directory.

Develop a plan for integrating Active Directory.

Plan how you want to use Global Catalogs.

Develop a plan for integrating Sun Java System Directory Server.

Plan a pilot test.



8 Planning for Administration• About the RSA Authentication Manager Administrative Model

• Planning Administrative Roles, Permissions, and Scope

• Planning Administration Through the Microsoft Management Console (MMC)

• Planning RSA Authentication Manager Training for Help Desk Administrators

• Administration Checklist

About the RSA Authentication Manager Administrative ModelAdministrators manage all aspects of your Authentication Manager deployment, such as users, tokens, and security domains. The Authentication Manager administrative model is built on the concepts of roles, permissions, and scope. When you assign an administrative role to a user, the user becomes an administrator and can log on to the RSA Security Console and the optional Microsoft Management Console to administer Authentication Manager.

Authentication Manager includes a set of predefined administrative roles and it enables you to create custom ones. You can create as many types of administrators, and as many of each type, as your deployment requires. See “Predefined Admininstrative Roles” on page 89.

Authentication Manager administrators are defined by three elements:

• Role

• Permission

• Scope

Planning Administrative Roles, Permissions, and ScopeIn Authentication Manager, administrative roles control which aspects of the system an administrator can manage, for example, user accounts. Administrative permissions govern the actions an administrator can perform, for example, assign tokens to users. Administrative scope controls the boundaries of an administrator’s authority. Scope is limited by the security domain.

An administrative role has two components:

• A collection of permissions based on a job function profile

• The scope in which the permissions apply

8: Planning for Administration 85


Administrative RolesWhen you assign an administrative role to a user, the user becomes an administrator. You can assign administrative roles to any user in your identity source. When you do so, you give the user permission to perform the administrative actions specified by the role within the specified security domain.

Authentication Manager provides a set of predefined roles that you can assign to users, allowing them to manage specific aspects of your deployment. You can assign these predefined roles in their default form, or you can modify them by editing the permissions assigned to the roles.

For example, if you do not want administrators with the Help Desk role to be able to view authentication agents, you can use the RSA Security Console to edit that role and remove that permission.

You may assign more than one administrative role to an administrator. The role, which includes scope, defines where the administrator can act. In this way, an administrator can perform a specific set of tasks in one security domain and a different set in another security domain. The scope of the role is maintained when an administrator is assigned multiple roles. Keep in mind that an administrator can have two roles that have some, or all of the same permissions, but with different scope.

When assigning roles to administrators, be sure to assign roles that grant only enough permission to accomplish their tasks. Avoid granting administrative roles that are overly broad.

Help Desk Administrators need sufficient security permissions to view and change certain user, group, token and user account data. Depending on your deployment, they might need access to multiple security domains. Plan to configure the Help Desk Administrator role with enough permission to perform the job, but not so much as to permit access to other areas or data.

In the FocalView Software scenario, one administrator has one role that grants permission to manage users in the San Jose security domain, and another role that grants permission to manage tokens in the New York security domain. This administrator can manage users in the San Jose security domain, but not in the New York security domain. This administrator can manage tokens in the New York security domain, but not in the San Jose security domain. If this administrator tries to search for users in the New York security domain, no users are returned because the role does not grant permission to manage them.

PermissionsThe permissions you assign to an administrative role govern the actions that may be taken by an administrator assigned the role. Be sure to assign enough permissions to administrative roles so that administrators can manage all the objects, such as users, user groups, and attributes, necessary to accomplish their assigned tasks, but not so many as to let them manage objects not vital to their responsibilities.

For example, an administrator’s only task is assigning tokens to users. You assign the following permissions to the role:

• View users

• View tokens

86 8: Planning for Administration


• Assign tokens to users

• Issue assigned software tokens

• Replace assigned tokens

• Import tokens (optional)

• Enable and disable tokens (optional)

The optional permissions in the previous example give the administrative role slightly expanded capabilities that complement the stated task of assigning tokens to users. Notice that this role does not include permission to add and delete users, resynchronize tokens or manage emergency offline authentication. These permissions are not related to the stated task of assigning tokens to users.

When you assign permissions to a role, keep in mind that an administrator in that role might need to associate two objects in the deployment. The administrator must have the appropriate permissions and scope for both objects at both ends of the association. For example:

• To assign tokens to users, an administrator must be able to view tokens, assign tokens, and view users.

• To move users between security domains, an administrator must be able to view security domains and users.

• To assign administrative roles to users, an administrator must be able to view roles, assign roles, and view users.

ScopeThe scope of an administrative role controls where an administrator may perform specified administrative tasks. Scope consists of two parts:

• The portion of the security domain hierarchy that the administrative role can manage

• The identity sources the administrative role can manage

Be sure to assign a scope broad enough so that the administrator can access all the necessary security domains and identity sources. Avoid assigning a scope so unnecessarily broad as to grant access to security domains and identity sources where the administrator has no responsibilities.

For example, a Help Desk Administrator can edit the user record of any other administrator within his scope. This means that a Help Desk Administrator can change the password of a higher-level administrator and gain the administrative privileges of the higher-level administrator. To avoid such situations, assign the higher-level administrator to a security domain that is not within the scope of the Help Desk Administrator.

In the FocalView Software scenario, one administrator’s only responsibility is to assign users to user groups in Boston. This administrator’s role has a scope that includes only the Boston location. It does not include the New York or San Jose security domains because they are not a part of this administrator’s responsibilities.



When you plan the scope of your administrative roles, consider:

• The role manages within the security domain where the role definition was saved. This includes all of the lower-level security domains in the same security domain.

• You can limit the scope of an administrative role for those security domains that are at or below the level of the security domain that owns the role. An administrative role can only manage down the security domain hierarchy, never up.

• An administrative role that manages a top-level security domain always manages the lower-level security domains beneath it.

For example, consider the following hierarchy:

• You can scope an administrative role saved in the top-level security domain to manage any one or more security domains in the realm. For example, it can manage only security domain F, or every security domain in the realm.

• An administrative role saved in security domain A can be defined to manage security domains: A, C, and E, or A, D, and F.

• An administrative role saved in security domain C manages security domains C and E, or E.

• An administrative role saved in security domain E can be defined to manage only security domain E.

• An administrator whose own LDAP record resides in security domain E can manage users in security domain A, C, D, and F if the administrator’s role was saved at or above security domain A and includes C, D, and F.



Use the following checklist to help you make decisions about administrative roles and scope.

Predefined Admininstrative RolesAuthentication Manager provides you with a set of predefined roles that you can assign to users, allowing them to manage specific aspects of your deployment. You can assign predefined roles in their default form, or you can edit the permissions assigned to the roles through the RSA Security Console. The following sections describe the default administrative roles.

Super AdminThis role grants complete administrative responsibility for Authentication Manager. The Super Admin role is the only role with full administrative permission in all realms and security domains in your deployment. You can use it to create other administrators and to create your realm and security domain hierarchy.

You can assign the Super Admin role to as many administrators as you want, but RSA Security recommends you only assign it to the most trusted administrators because the Super Admin role has a broad scope and a wide array of permissions. You assign the Super Admin role in the same way that you assign all other administrative roles.

RSA Security recommends that you assign the Super Admin role to at least two administrators. This ensures that you still have full administrative control in situations where a Super Admin leaves for vacation or some other extended absence.

In the FocalView Software scenario, the company has locations in Boston, New York, and San Jose. The company has four Super Admins: two in Boston, and one each in New York and San Jose. This arrangement allows for a vacation or extended-leave backup for the Super Admins in the Boston headquarters, where most system management occurs. It also allows the deployment to be managed from New York or San Jose if the Boston headquarters loses connectivity, or is otherwise unable to manage the deployment.

No one can modify the Super Admin role, including the administrators assigned the Super Admin role. It is possible, though not recommended by RSA Security, to delete the Super Admin role.

The Super Admin can delegate some of the responsibilities of this role.

Questions to ask about roles, permissions, and scope

Which, if any, of the predefined roles meet your requirements?

Do you need custom roles and what are their requirements?

What are the responsibilities for each role?

What are the permissions for each role?

What is the scope of each role?

Which users get which role?



Realm AdministratorThis role grants complete administrative responsibility for managing all aspects of the realm. This role is limited in scope to the realm in which it is created and it does not include Super Admin permissions. The Realm Administrator can delegate some of the responsibilities of this role.

The default permissions for this role include complete management of the following:

• All realm permissions

• Replica instances

• Disaster recovery

• Agent deployment

• Import tokens

• Lower-level security domains

• Groups

• User assignments

• Reports

• Log maintenance

Security Domain AdministratorThis role grants complete administrative responsibility to manage all aspects of a branch of the security domain tree. This administrator has all permissions within that branch except to manage top-level objects such as policies and attribute definitions. By default, this role’s scope includes the entire realm. If you want to limit this role’s scope to a lower-level security domain in the realm, edit this role, or duplicate this role and then edit the scope of the duplicate role. This role has the same permissions as the Realm Administrators and Super Admins, but is limited to the security domain in which it is created. The Security Domain Administrator can delegate some of the responsibilities of this role.

The default permissions for this role include complete management of the following:

• Security domains

• Administrative roles

• Permissions

• User groups

• Reports

• Tokens

• User accounts

• Agents and server nodes



User AdministratorThis role grants administrative responsibility to manage users, assign tokens to users, and access selected authentication agents. This administrator cannot delegate any of the responsibilities of this role.

The default permissions for this role limit management to the following:

Token AdministratorThis administrative role grants complete administrative responsibility to import and manage tokens, and to assign tokens to users. This administrator cannot delegate any of the responsibilities of this role.


Users Add, delete, edit, view

User groups View user group, assign user group membership

Reports Add, delete, edit, view, run, schedule

Tokens View token, reset SecurID PINs, enable and disable SecurID tokens, resynchronize tokens, assign tokens to users, replace tokens, issue software tokens, manage online and offline emergency access tokencodes

User accounts Manage fixed passcode, manage logon aliases, edit default shell, manage incorrect passcode count, clear cached Windows credential, manage offline emergency access passcode

Agents View, grant user groups access to restricted authentication agents

Users View

Reports Add, delete, edit, view report definition, run, schedule

Tokens Import, delete, edit, view token, reset SecurID PINS, resynchronize tokens, manage online and offline emergency access tokencodes, assign tokens to users, replace tokens, issue software tokens, export tokens, manage incorrect passcode count



Privileged Help Desk AdministratorThis role grants administrative responsibility to resolve user access issues through password reset, and unlocking or enabling accounts. It also grants permission to view and provide offline emergency access help. This administrator cannot delegate any of the responsibilities of this role.


Help Desk AdministratorThis role grants administrative responsibility to resolve user access issues through password reset, and unlocking or enabling accounts. This administrator cannot delegate any of the responsibilities of this role.


Users View, reset passwords, enable and disable accounts, terminate active sessions

User groups View user groups

Reports Run, schedule

Tokens View token, reset SecurID PINs, resynchronize tokens, manage online and offline emergency access tokencodes

User accounts

Manage fixed passcode, manage logon aliases, edit default shell, manage incorrect passcode count, clear cached Windows credential, manage offline emergency access passcode

Agents View

Users View, reset passwords, enable and disable accounts, terminate active sessions

User groups View user groups

Tokens View token, reset SecurID PINs, resynchronize tokens, enable and disable SecurID tokens

User accounts Manage logon aliases, edit default shell, manage incorrect passcode count, clear cached Windows credential

Agents View



Agent AdministratorThis role grants administrative responsibility to manage authentication agents and grants access to selected authentication agents. This administrator cannot delegate any of the responsibilities of this role.


Planning Administration Through the Microsoft Management Console (MMC)

The information in this section applies only to Authentication Manager customers who use Active Directory for their identity source. The Authentication Manager MMC snap-in is an option that enables you to use the Microsoft Management Console (MMC) for Active Directory to perform many of your token-related tasks. This eliminates the need for Active Directory administrators to log on to the RSA Security Console whenever they need to enable or disable a token, assign a token, and so on. It also enables you to delegate limited responsibility to specific administrators for token-related tasks.

The MMC snap-in enables administrators to perform the following tasks:

• Assign and unassign tokens to users

• Enable, disable, and edit users’ tokens

• Edit user authentication attributes

• Edit token properties

• Manage PINs

• Replace tokens

• Generate and download seed files

• Provide emergency access

The pages in the Authentication Manager MMC snap-in are designed to match the corresponding pages in the RSA Security Console. This provides consistency for administrators who want to use both tools for token-related tasks.

Users View

User groups View user groups, assign user group membership

Reports Add, delete, edit, view report definition, run, schedule

Agents Add, delete, edit, view, manage node secret, grant user groups access to agents



If you have Active Directory and plan to install the Authentication Manager snap-in, plan to deploy the MMC snap-in on the machines where the Active Directory administrator has permission to perform Active Directory administration tasks. There are two possible deployment scenarios:

• Install the MMC snap-in on the machine that serves as the domain controller.

• Install the MMC snap-in on the machine where the Active Directory user and MMC is installed to manage Active Directory remotely.

Planning RSA Authentication Manager Training for Help Desk Administrators

Help Desk Administrators typically spend their time working with end-user issues, rather than system issues. Their jobs are highly task oriented, and they focus on the following areas:

• Users

• User groups

• Tokens

• User accounts

• Agents

If you have any tasks that are unique and specific to your business, remember to add them to your list of training topics. The following list contains topics for the tasks most commonly performed by Help Desk Administrators:

• Viewing users

• Viewing user and token data

• Assigning and unassigning tokens

• Enabling and disabling user accounts

• Enabling, re-enabling, disabling, and editing user tokens

• Editing user authentication attributes

• Editing token properties

• Synchronizing tokens

• Viewing and resetting RSA SecurID PINs

• Viewing and resetting passwords

• Replacing tokens

• Managing logon aliases

• Editing the default shell for user accounts

• Generating and downloading seed files

• Managing an incorrect passcode count



• Clearing a cached Windows credential

• Providing emergency access

• Terminating active sessions

• Viewing agents

• Viewing user groups

Help Desk Administrator training should also include awareness of the tactics of unauthorized individuals who try to enter your system by way of your Help Desk. Plan to provide strategies to your Help Desk Administrators for dealing with such attempts.

Administration ChecklistUse the following checklist to help you plan for administration.

Action Item

Understand how administrators are defined.

Understand the relationship between role, permissions, and scope.

Decide whether to use the MMC snap-in.

Develop a training plan for Help Desk Administrators.



9 Planning PIN, Token, and Password Policies• Planning PIN Policy

• Determining When to Lock Out Users After Failed Authentications

• Planning Password Requirements and Restrictions

• Planning Emergency Access

• Policies Checklist

Planning PIN PolicyA PIN is the second factor of the RSA SecurID two-factor authentication solution, and as such, the policies you apply to the creation and use of PINs is an integral part of securing your systems.

Determining PIN Creation MethodsAuthentication Manager provides two methods of PIN creation:

• System-generated PINs are created by Authentication Manager based on the PIN policies you set.

• User-generated PINs allow users to select their own PINs, within the restrictions of the PIN policies you set.

Note: Regardless of the method you select, PINs are assigned to users during their first authentication attempt.

You can specify the following characteristics of PINs:

• The PIN creation method, either system-generated or user-generated.

• The length of a PIN. Authentication Manager allows you to select a range of between 4 and 8 characters.

• Which characters are allowed or required in a PIN. PINs can be alphabetic, numeric, or a combination of both, and the minimum number of numeric or alphabetic characters can be set as well.

• An expiration date, a maximum and minimum lifetime for the PIN.

• Restrict the reuse of user-generated PINs, so that your users cannot continue to use the same PIN repeatedly.

• Exclude certain obvious words that users typically select.

9: Planning PIN, Token, and Password Policies 97


Balancing Security and Ease of Use in Determining PIN PolicyOne of the most common security issues regarding PINs (and passwords) is employees writing them down on a piece of paper and leaving it in a convenient location. Even when employees are discouraged from such behavior, the problem of forgetting long, complex, system-generated PINs creates an additional administrative burden on your Help Desk. When setting token policies in regards to PINs, the goal is to create a situation that balances security and ease of use.

For example, longer PINs are more difficult to remember, but more secure, while shorter PINs are easier to remember, but also easier to guess. If you set your policy to use shorter PINs to ensure that employees remember them and do not write them down, you can offset this by requiring alphanumeric PINs that must be changed more frequently.

The longer a PIN is valid, there is a greater risk that it will be compromised. A short maximum lifetime may increase security. However, it may also be counterproductive in that remembering a new PIN, especially a system-generated PIN, is difficult and may increase the number of employees who write down their PINs, which negates the effectiveness of the strict policy.

When allowing users to create their own PINs, you run the risk that they may select easily guessed PINs, such as birthdays, or the names of pets or children. You can set your policy to exclude certain words, and to require alphanumeric characters.

Planning PIN Requirements and RestrictionsAuthentication Manager allows you to configure the following PIN requirements and restrictions.

• Requiring Use of System-Generated PINsEnabling this feature ensures that users’ PINs are random and therefore less likely to be guessed by an unauthorized person attempting to access your network.

• Requiring Periodic PIN ChangesEnabling this option allows you to set minimum and maximum PIN lifetimes. The minimum PIN lifetime is the minimum amount of time that a password can exist before the user can change it. The maximum password lifetime is the maximum amount of time a user can keep a password before being required to change it.

Setting a minimum PIN lifetime prevents users from circumventing any restrictions on the reuse of old PINs that you may have set. For example, if users are restricted from reusing their five most recent PINs, the minimum PIN lifetime prevents them from immediately changing their PIN six times so they can reuse a particular PIN.

98 9: Planning PIN, Token, and Password Policies


Setting a maximum PIN lifetime prevents users from indefinitely keeping the same PIN, which increases the likelihood that it might be guessed by an unauthorized person trying to access your network.

Note: Be sure to balance security of the system and ease of use for the members of your organization. An overly strict maximum lifetime, such as one that requires a PIN change every seven days, may be counterproductive in that remembering a new PIN every seven days is difficult and may increase the number of employees who write down their PINs, which negates the effectiveness of the strict policy.

• Restricting Reuse of Old PINsSetting a restriction on the reuse of old PINs prevents users from reusing the same two or three PINs over and over, which decreases the likelihood that an unauthorized person may guess a PIN.

• Limiting PIN LengthsSetting minimum and maximum PIN lengths prevents users from creating PINs that are too short and easily guessed by an unauthorized person attempting to access your network, or that are too long and difficult to be remembered by authorized users.

Note: Be sure to balance security of the system and ease of use for the members of your organization. Required PIN lengths that are too long may be counterproductive in that remembering a long PIN is difficult and may increase the number of employees who write down their PINs, which negates the effectiveness of the strict policy. Long PINs that users cannot remember can also lead to more users locked out of your network, and therefore more calls to the Help Desk for assistance.

• Using an Excluded Words DictionaryThe excluded words dictionary prevents users from using common, and therefore, easily guessed words as PINs. The excluded words dictionary is a record of words that users cannot use as PINs, including several thousand commonly used words that are likely to be included as part of any dictionary attacks on the system.

• Setting PIN Character RequirementsRequiring specific characters in PINs can make guessing the PIN more difficult. You can require alphabetic or numeric characters.

Note: The PIN character requirements do not apply to software tokens and PINPads. Software tokens and PINPads require numeric PINs.



Planning Multiple PIN Policies Through the Use of Security DomainsYou can place greater restrictions on users associated with a particular security domain by defining multiple PIN policies. By defining additional policies, you can require some employees to adhere to more strict standards when selecting and using PINs.

For example, Greenley Biotechnologies has three security domains, one for Research and Development (R&D), one for Human Resources (HR) and one for Finance. The administrator has determined that the default policy is adequate for protecting the R&D and HR security domains, but given new government compliance regulations, the administrator has decided to define a more strict policy for the Finance security domain. As a result, users in the Finance security domain require longer PINs and more frequent PIN changes.

Determining When to Lock Out Users After Failed AuthenticationsAs a security measure against unauthorized users attempting to authenticate to your network using stolen credentials (either a stolen PIN, with guessed tokencodes, or guessed PINs with correct passcodes read from a stolen token), Authentication Manager has the ability to lock user accounts under certain conditions that you can specify in one or more lockout policies.

Lockout policies define how many failed logon attempts users can make before Authentication Manager locks their account. You assign lockout policies to security domains. The lockout policy assigned to a security domain dictates the lockout requirements for all the users assigned to that security domain.

One lockout policy is always designated as the default policy, which is assigned to each new security domain unless another policy is explicitly assigned to a security domain. Lockout policies assigned to top-level security domains are not inherited by lower-level domains.

You can set lockout policies in the following ways:

• Never lock the user’s account, regardless of the number of incorrect authentication attempts made by the user.

• Lock the user’s account after a certain number of consecutive failed authentication attempts over a period of days.

• Unlock the user’s account automatically after a specific period of time, or require the administrator to manually unlock the user’s account.



Planning Password Requirements and RestrictionsIn general, Authentication Manager passwords are only used as the default method for administrators logging on to the RSA Security Console. Consider this purpose when you determine which requirements and restrictions you want to use for your password policies in Authentication Manager.

Password policies define users’ password length, format, and frequency of change, and are assigned on a per security domain basis. One password policy is always designated as the default policy, and assigned to each new security domain that is created. You can use the default password policy or apply a custom policy to each security domain.

Password policies assigned to top-level security domains are not inherited by lower-level domains. For example, if you assign a custom policy to the top-level security domain, security domains you create below it in the hierarchy are still assigned the default password policy.

Password policies are put in place to overcome the shortcomings of static passwords by not allowing users to engage in the typical behavior that users exhibit when confronted with passwords. For example, most users pick easily-guessed passwords like birthdays, or the names of pets, children, or favorite fictional characters. The use of an excluded words dictionary, as described below, can account for some of these typical behaviors.

Authentication Manager allows you to configure the following password requirements and restrictions.

• Requiring Use of System-Generated Passwords

• Requiring Periodic Password Changes

• Restricting Reuse of Old Passwords

• Limiting Password Lengths

• Using an Excluded Words Dictionary

• Setting Password Character RequirementsYou can require the following types of characters:

– Alphabetic characters

– Uppercase characters

– Lowercase characters

– Numeric characters

– Non-alphanumeric characters

The requirements and restrictions for passwords are similar to the requirements and restrictions for PINs. When considering how to configure your password policies, the same issues that apply to PIN policies apply to password policies. See “Planning PIN Requirements and Restrictions” on page 98.



Planning Emergency AccessDetermine how you want users to authenticate when they do not have their assigned tokens in their possession.

Users occasionally lose, misplace, or damage their tokens. While a damaged token is an inconvenience for the user, and an additional burden for an administrator, a lost or stolen token compromises the security of the system, as it can end up in the hands of an unauthorized individual who may attempt to authenticate.

Important: When a user reports a missing token, immediately disable the token so that it cannot be used for authentication. This safeguards the system in the event the token is found by an unauthorized individual who attempts to authenticate.

Regardless of the exact circumstances, users still need to authenticate, even without a token. In these situations, two-factor authentication is still possible with the use of an emergency access tokencode. Similar to a tokencode generated by an RSA SecurID token, the emergency access tokencode is a fixed tokencode generated by Authentication Manager and assigned to the user, and used with the user’s PIN to create the passcode.

For example, assume you are a Help Desk Administrator for the New York security domain. One of your users lost his token. You disable the token in case it is found by an unauthorized individual. Despite having lost his token, the user needs to authenticate immediately. You assign an emergency access tokencode for him to use for authentication until you can replace the lost token.

While emergency access tokencodes provide a quick and convenient way to deal with a typical problem, they do open the system up to additional risks. Given that an emergency access tokencode is a fixed tokencode, it is not as secure as the tokencode generated by a token. To alleviate any security concerns, Authentication Manager allows you to set restrictions on how the system handles emergency access tokencodes on a case by case basis. You can set an expiration date for the emergency access tokencode and also select how the system handles the use of a recovered token.

Setting an expiration date limits the length of time that the emergency access tokencode can be used and reduces the likelihood that an unauthorized individual may guess the code.

Additionally, you can specify what happens if the missing token is recovered (if the user finds the lost token, for example). You can choose to:

• Deny authentication with the recovered token. This setting protects the system when the person who recovered the token is not the authorized user.

• Allow authentication with the recovered token while simultaneously disabling the emergency access tokencode, making it invalid as soon as the user attempts to authenticate with the recovered token.

• Allow authentication with the recovered token only after the emergency access tokencode has expired.



In a situation where the token is permanently lost, Authentication Manager provides the ability to disable the token so that it cannot be used for authentication. After disabling the token, you can grant temporary access by generating an emergency access tokencode for the user.

Important: There is no system-wide policy governing the behavior of emergency access tokencodes. The administrator handling a particular situation determines the appropriate behavior for that situation.

The following tables describe the emergency access methods and show where to find more information.

For Offline Users

Method Description Characteristics Reference

Offline emergency access tokencode

Users whose computers are not connected to the network can access their protected computers without a tokencode (for example, when they have lost their tokens).

• Must be combined with the user’s RSA SecurID PIN

• Created by an Authentication Manager administrator

• Valid until the user’s lost token status is changed

See the chapter “Preparing RSA Authentication Manager for Administration” in the Administrator’s Guide.

Offline Emergency Access Passcode

Users whose computers are not connected to the network can access their protected computers without a PIN (for example, when they have forgotten their PINs).

• Used in place of a PIN and a tokencode

• Valid for one authentication only


For Online Users

Method Description Characteristics More Information

Online emergency access tokencode

Users whose computers are online with the network can access their protected computers without a tokencode (for example, when they have lost their tokens).

• Must be combined with the user’s RSA SecurID PIN

• Created by an Authentication Manager administrator

• Valid until the user’s lost token status is changed




For Administrators

Method Description Characteristics More Information

Reservepassword

Administrators can authenticate to a user’s computer as that user without entering a passcode.

• Set by an administrator on each Authentication Agent host

• Never expires

See “Set a Reserve Password” in the chapter “Configuring Local Authentication” in the RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows Installation and Administration Guide.

Exempt administrator account

Administrators can authenticate to protected computers as themselves with only a password.

• Created during Agent installation for the administrator performing the installation

• Created on each Authentication Agent host

• Protected by simple Windows password security

• For greater security, identifies the account by a Well-Known Security Identifier (SID) instead of a user name

See “Exempt Administrator Account” in the chapter “Overview” in the RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows Installation and Administration Guide.



Policies Checklist

Action Item

Determine how many distinct policies you need.• Define a default policy.• Define policies for specific security domains.

Determine how PINs will be created:• System-generated• User-generated

Determine how many failed authentication attempts a user can make before the user account is locked.

Determine how a locked user account will be unlocked:• Automatically, after a set length of time• Manually, by an administrator

Determine password policies and restrictions.

Determine how administrators manage emergency access situations:• Specify whether emergency access tokencodes expire.• Specify the appropriate behavior when a token is recovered.

Determine character restrictions for PINs, passwords, and emergency access tokencodes.



10Planning RSA SecurID Token Deployment• Overview of RSA SecurID Token Types

• Determining Which Types of Tokens to Deploy

• Planning How to Deploy Tokens to Users

• Planning User Training on the Use of RSA SecurID Tokens

• Token Deployment Checklist

Overview of RSA SecurID Token TypesRSA SecurID tokens calculate and display tokencodes, which change at a specified interval, usually every 60 seconds. The passcode used to authenticate is a combination of the user’s PIN and the tokencode currently displayed on the token.

There are two types of RSA SecurID tokens:

Hardware token. A device manufactured by RSA Security containing a microprocessor that calculates and displays tokencodes. Hardware tokens include standard tokens, key fobs, and PINPads.

Software token. A software file installed on a client workstation, an RSA Smart Card, a personal digital assistant (PDA), or a cell phone.

Note: The RSA Security Console provides a centralized administration interface for issuing RSA SecurID software tokens to the supported device types. You can add information to software tokens, such as device serial number or token nickname, using token attributes fields.

10: Planning RSA SecurID Token Deployment 107


Hardware TokensRSA Security provides the following hardware tokens.

Standard token. A credit-card-shaped hardware device that is easily portable and extremely durable. It displays a unique code generated by the RSA SecurID or AES industry-standard algorithm in combination with the unique seed contained in the token and an internal clock.

PINPad. A credit-card-shaped hardware device that is portable and extremely durable. It differs from the standard token in that the user enters the PIN directly into the token by way of a 10-digit numeric keypad contained on the card. The generated passcode displayed is a hash-encrypted combination of the PIN and the current tokencode.

Key fob. A standard-sized hardware device that connects easily to any key ring and fits into a user’s pocket or small carrying case. It operates identically to the standard token.

RSA SecurID 700. A smaller key fob model that connects easily to any key ring and is very convenient for the end user. It operates identically to the standard token.

USB token. A multi-function device that combines the features of the traditional RSA SecurID hardware token with a smart chip based on Sun Java technology packaged in a more convenient USB form factor. In addition to generating passcodes, it is capable of storing multiple X.509 digital certificates which enable authentication, digital signature, and file encryption applications. The device can also store several User ID and password combinations for logon to password-enabled applications. Support for mixed credential types enables the device to be used for more applications. When connected, the RSA SecurID SID800 authenticator enables applications to programmatically access tokencodes, eliminating the need for users to type their code.

108 10: Planning RSA SecurID Token Deployment


RSA SecurID Software TokensThe software token is a software application and a generated token seed file. You can install the application on a desktop or laptop PC, a personal digital assistant, a cell phone, or an RSA Smart Card. The application requires a token seed record, which you can generate in the RSA Security Console and then deliver to the installed software token applications. The RSA Security Console provides a centralized administration interface for issuing RSA SecurID software tokens to the supported device types.

RSA SecurID software tokens are available for the following platforms:

• Windows Desktops

• Windows Mobile 2003

• Palm Handhelds

• BlackBerry Handhelds

• Mobile Phones

• RSA SecurID Software Toolbar TokenRSA SecurID Software Toolbar Token 1.0 is a software-based security token that users install into a Mozilla Firefox or Microsoft Internet Explorer browser toolbar. To access resources protected by Authentication Manager, users must provide an 8-digit code from their toolbar in addition to the credentials that they normally provide (user name and password) to enter a protected site.

Determining Which Types of Tokens to DeployWhen deciding which type of tokens to deploy, the complexity of your deployment, the size of your user population, and the ease of distribution are important factors. Determine which types of tokens best meet the needs of your users and your deployment.

For example, suppose your organization has internal users who must authenticate with an RSA SecurID token when they log on to their desktop computer, as well as a remote sales force whose members must authenticate with an RSA SecurID token when they log on to their laptop computers.

You might choose to distribute hardware tokens to your internal users. Because they generally log on at their desktop machine each day, the internal users are less likely to lose their tokens than someone who travels frequently. If you distribute fobs, many users choose to attach the fob to their key chain, so that as long as they have their car keys, they have their token.

You might choose to distribute software tokens to your remote sales force. Your sales force is on the go constantly, and with a software token installed directly on a PDA or cell phone, they will be less likely to leave it at home, or lose it in an airport. As long as they have their PDA, they have their token.



Planning How to Deploy Tokens to UsersThe types of token you use, ease of administration, and security are factors in determining the method of token distribution that you use.

Hardware TokensThe methods of delivering hardware tokens are:

• Users receive tokens at a central location.This is the most secure method, although this may not be feasible for all users. To accommodate delivery, locate trained administrative personnel at each office site. The advantage of this distribution method is the assurance that the hardware tokens are delivered to the right users and that they work when users receive them.

For example, for both Miller & Strauss and Greenley Biotechnologies, this method may be easily used, as they both have a single geographical site. Miller & Strauss in particular only uses tokens for remote users working from home or on the road, but who work regularly in the office.

For FocalView Software Company, this method may be more difficult to implement, as the large user population means more administrative overhead when direct contact with the users is required.

• Users receive tokens in the mail.Mailing hardware tokens through interoffice mail, post, or overnight express, for example, may be more feasible for your organization. However, this usually involves more up-front work to ensure success. You will need to develop a process for generating mailing labels, mailing the hardware tokens, and verifying that users receive their tokens. The most secure recommendation is to set tokens to disabled. Send any information about enabling tokens separately from the actual tokens or make it accessible only from a secure location. You will also want to group users so that mailing can be accomplished in a controlled manner.

Use secure methods such as the following to distribute hardware tokens to users:

• Distribute tokens that are assigned but disabled.

• Enable a token only after you are satisfied that it is in the possession of the assigned user and that the user is ready to log on for the first time using this token.

• If you must distribute enabled tokens to assigned users, do so through secure channels (such as having them delivered in person by trusted staff members).

Ultimately, you may need to use a combination of these delivery methods.



Software TokensAn RSA SecurID software token is a software-based token that resides on a user’s computer, an RSA Smart Card, or any of the other supported devices. Software token files are generated using the RSA Security Console, and must be distributed to end users and installed on desktops and handheld devices.

The following sections describe the issues that you need to consider before implementing software tokens. Before issuing software tokens to users through the RSA Security Console, you must decide how you want to distribute the tokens. You can post software token applications on your network and require users to download and install them, and then install the seed record. You can assign the task of installing the application and the seed record to your IT personnel.

Enabling Copy ProtectionThe Enable Copy Protection option ensures that the software token cannot be copied or moved from the directory in which it is installed on a user’s computer or other device. By default, the option is enabled. Enabling copy protection is a simple process that increases administrative control over the use of software tokens and presents little administrative burden. RSA Security strongly recommends that you use copy protection.

Binding a Software Token to a DeviceWhen you issue the token, you can include the serial number of the device in the token file. If the serial number in the token file does not match the serial number of the device, the token cannot be installed. Binding a software token to a device increases administrative control over the use of software tokens and presents little administrative burden.

Selecting a Method for Issuing Software TokensYou may issue multiple software tokens at one time, and specify a single file in which to save them (best used for situations in which an administrator is installing the tokens), or separate files for each token (best used when end users are installing tokens on their own PCs or devices).

Using Passwords to Protect Software Token FilesAuthentication Manager allows you to specify a password that protects the issued software token. The type of password protection depends on which method of issuing tokens you select.

• If you select a single file for all issued software tokens, you can protect the file with a password of your choice.

• If you select separate files for each issued software token, you can specify a single password of your choice, specify the User ID of the user to whom you issue the token, or a combination of the two for each file.



Using Remote Token Key Generation to Deploy Software Tokens (CT-KIP)When you assign a software token to a user, you can optionally select to use remote token key generation to deploy a token on user devices. This option uses the Cryptographic Token-Key Initialization Protocol (CT-KIP) and can only be used with CT-KIP-capable SecurID software tokens.

Remote token key generation enables Authentication Manager and the device that hosts the software token, such as a web browser, to simultaneously and securely generate the same token seed on a device and Authentication Manager.

This allows you to put a token seed on a user’s device without actually sending the token seed through e-mail or putting it on electronic media such as a floppy disk. This greatly decreases the chances that the token seed will be intercepted by an unauthorized person.

Note: If you install RSA Authentication Manager inside a secure DMZ, you may decide only to allow traffic to it through a proxy server. If the primary instance fails, token key generation URLs and service addresses that you have distributed to users, but that users have not yet used, become invalid. If your proxy server supports failover mode, you can configure it to pass CT-KIP data to the new primary instance. See the section “Using Remote Token Key Generation to Deploy Software Tokens (CT-KIP)” in the chapter “Protecting Network Resources with RSA SecurID” in the Administrator’s Guide.

Planning User Training on the Use of RSA SecurID TokensDeploying Authentication Manager changes the way users log on to their systems, and to the network. It increases the level of responsibility of your end users for the security of your systems, and requires them to safeguard their tokens and PINs. It is imperative that you train users and administrators in the use and care of their tokens.

When considering the training needs of both your end users, ask yourself the following questions:

• When and how will you inform end users about the planned rollout of RSA SecurID tokens?

• How will you communicate authentication instructions to end users?

Informing Users About the Planned RolloutGive users advance notice of the scheduled changeover. By doing so, you give them a chance to ask questions and clear up any confusion before you implement the new procedures.

You may want to inform users through one of the following methods:

• E-mail• Company/IT/MIS newsletter• Intranet



For example, Miller & Strauss is a small company that can roll out tokens to all of its users in a fairly short time, so e-mail is likely the quickest method of informing users about the requirement of using RSA SecurID tokens, and the time frame in which the rollout will occur. Greenley Biotechnologies is a large company, with multiple geographic sites, and so is likely to roll out RSA SecurID authentication over an extended period of time. Notification of the rollout is published on the intranet and in the company newsletter, with e-mail notifications sent to users whose rollout date is within a week.

Communicating Authentication Instructions to End UsersRSA Security recommends that you provide documentation with each token. If you plan on mailing hardware tokens to your users, consider including a small card with instructions for locating a more detailed procedure or a telephone number to call to enable the device. If you plan to distribute hardware tokens directly to users, consider giving them complete procedures as part of the package. A good understanding of your user base, including your users’ work habits and technical levels, helps in this effort.

Alternatively, you can include the instructions with the initial notification to users of the planned rollout, or include a URL where they can download the instructions.

Consider the following options:

• Using Documentation Provided by RSA Security: RSA Security provides sample instructions that you customize to reflect your company’s procedures. If you are deploying the RSA SecurID Authenticator SID800 to your users, see the RSA Security Center Help and the RSA Authenticator Utility 1.0 User’s Quick Reference, both of which are provided with the RSA Authenticator Utility 1.0, for end-user instructions.

• Writing Your Own Documentation: If you choose to write your own documentation, be sure to document procedures for performing certain functions, including enabling the token, setting an initial PIN, resetting a PIN, and acquiring help with authentication problems. You may want to include screenshots of different processes.

Note: How you configure PIN policies can affect the user’s experience, and therefore the instructions that you provide to your users. For example, depending on how you configure PIN generation, users may be asked to create their own PIN, accept a system-generated PIN, or choose between the two methods.

• Using the RSA SecurID Tour: RSA Security provides an online interactive tour that you can view at http://www.rsasecurity.com/node.asp?id=1159. The tour explains the concept of two-factor authentication, the different types of RSA SecurID authenticators, and the procedures associated with two-factor authentication.



Token Deployment Checklist

Action Item

Determine which types of tokens you will be using in your deployment.

Decide how you want to distribute tokens.• Users will pick up tokens at a central location.• Users will receive tokens through the mail.

If you are distributing software tokens, determine if you will:• Enable copy protection.• Bind the token to a handheld device.• Assign a nickname to each token.

Determine the method you will use to issue software tokens:• One token per file• Multiple tokens per file

Determine if you will use password protect issued software token files, and how:• Password• User ID• Combination

Determine when and how you will inform users about the rollout of RSA SecurID tokens.



11Planning Logging and Reporting• About Logging and Reporting

• Planning Log Maintenance

• Planning SNMP Trapping

• Planning Reporting

• Logging and Reporting Checklist

About Logging and ReportingAudit information about all significant aspects of any administrative or runtime action performed by an administrator or end user in a single deployment is recorded in the central data store. The system also provides a de-centralized tracing log capability, per component, to help you resolve issues at the local level. Consider which logging and reporting options you want to use.

Review the following RSA Authentication Manager tools and consider how you want to manage logging and reporting:

• Standard reportsThere are a number of report templates, which you can easily modify and save through the RSA Security Console. You can send saved reports to other administrators for use in their domains.

• Event loggingThe system automatically logs all authentication and administrative events and stores them in a database. You can encrypt the information that is stored in the log entries, as well as the logging information that is transferred between each component and the central data store.

• The Activity MonitorThis tool enables you to view authentication and administration activity in real-time. It is especially useful for resolving user’s issues because you can watch their activity, as they attempt to use the system.

Permission to view logs is controlled by the security domain. Administrators can view only the log messages for the security domains within their administrative scope.

Permission to run reports is controlled by administrative roles.

11: Planning Logging and Reporting 115


Planning Log MaintenanceConsider how you want to manage your log files. Authentication Manager automatically logs all authentication and administration events. There are four types of log files generated by the system.

All audit log messages are sent to the Authentication Manager internal database for storage. You cannot filter audit log messages. You can only filter trace log messages that appear to the users at the time of the event. Use your log monitor to filter the following trace log attributes:

• Admin User ID

• Security domain

• Affected User ID

• Authenticator serial number

• User group

• Authentication agent hostname

• Authentication Manager instance

Log Description

Audit information Includes the date and type of action performed, which are used to validate a certain state of the data. Authentication and authorization policies are based on the state of the data.

System information Provides information about the environment, internal processes, state, or events in the system. For example, activation or deactivation, connection refresh or reclaim events, and so on.

Runtime information Includes any runtime activity, such as authentication and authorization of users.

Trace information Used for resolving user issues in a production deployment, where code debugging is not possible. Trace logs usually capture enough information to help you follow the thread of execution with appropriate contextual data.

116 11: Planning Logging and Reporting


Planning for audit log maintenance includes selecting a rotation scheme to help you manage the size of the file that contains all of the administrative, system, and runtime messages. Authentication Manager provides three file rotation schemes:

• Never rotate log file

• By file size

• On schedule

Plan to specify a maximum file size, the number of files to back up, and polling frequency.

Planning Log Archiving Archiving is the process by which log records are converted to flat files, removed from the database, copied onto external media, and moved to a long-term storage location. Without archiving, logs grow until they consume all available disk space. A large site with many authentications per hour fills up quickly, while a smaller site might fill disk space more slowly.

Authentication Manager provides a Log Archival utility for converting database logs to flat files, exporting logs from the database, and purging them. You can use the utility to set up one or more schedules (as log archive policies) for creating and optionally purging log files.

Important: Once all disk space is consumed, Authentication Manager may stop operating and be difficult to restore. You must devise policies and procedures to ensure that logs are archived from the database and moved to external media on a regular basis. You can use the the Log Archival utility to create log files, but you are responsible for removing the files from the disk and copying them to a secure external media.

Consider these questions:

• How often do you need to archive log files? Consider your company’s particular audit trail requirements, and the amount of disk space available for logs in the database.

• How often will you purge logs from the archive? Consider how much disk space is available in the archive, and how often you expect to access the archived logs.

• What is the maximum length of time you want to capture in each log file? This decision affects the size of each file and the total number of log files. The number of files equals the total time stored in archive files divided by the maximum file size, rounded up to the nearest integer number of files. For example, if the offline storage time is 180 days and the default log size is 30 days, six logs are created over time.

Consider:

– How often will data be archived?

– Available disk space.

– The volume of data being archived.

– How you will access the logs if you need them.



You can choose to use fewer (larger) log files, or more (smaller) log files.

You can also export logs to third-party systems.

Planning Log ConsolidationThe system provides a mechanism to consolidate all Authentication Manager log files in your realm. Consider how you want to manage your files.

Each replica instance automatically sends its log files to the database in the primary instance. In this way, all of your Authentication Manager logs are consolidated into one database. Note that this service does not include any operating system log files originating in the replica instances because those are not automatically sent to the primary instance. They remain on the replica instance. You may want to configure your Network Management Server to retrieve such information.

If you want any of your Authentication Manager log files sent to your system log, you can configure the primary instance to send messages to the Windows Event Log or Linux SysLog. For instructions, see the Help topic, “Configure Logging.”

If the physical location of the log files is a concern in your deployment plan, perhaps because a key administrator is in a certain location, consider where you locate your primary instance because that is also where your consolidated log file is located.

Planning SNMP TrappingIf your company utilizes a Network Management System (NMS), consider enabling the SNMP agent for your Authentication Manager instances and using the NMS to monitor critical events and overall system health. For instructions on enabling network monitoring, see the Help topic, “Configure for SNMP Trapping.”

Planning ReportingThe information that you can query for a report is controlled by your administrative scope. The scope of the data collected in a report is governed by either of the following:

• Administrative permissions of the administrator executing the report

• Administrative permission of the Run-As identity in the report definition

If you plan to delegate running reports to other administrators, be sure that you trust them to view all of the information that they can see in such reports. Consider designing delegated reports in a way that limits the kinds of information that others can view, and select only your most trusted administrators to run them.



Available ReportsYou can select among the report templates included in Authentication Manager and customize them to fit your requirements through the RSA Security Console. As you plan your deployment, consider which reports you need and from where you want them.

The following reports are available in this release of Authentication Manager.

Report Name Report Description

Administrators by Security Domain

Lists all administrators who are assigned a role with a scope that is explicitly or implicitly included in the specific security domain. For example, a lower-level security domain is implicitly considered as managed by an administrator who has permission to a higher-level security domain.

Disabled Users Lists all registered users who have a disabled account in a specific security domain.

Activity Report of an Administrator

Lists all administrator activities.

Runtime Activity Report Lists all runtime activities initiated by users.

Administrators with a Specified Role

Lists all administrators assigned a specific role.

Expired Users Accounts Lists all registered users with expired accounts in a specific security domain.

Diagnostic Report on Orphaned Users and Groups

Lists users and groups that are in a pending state in the system. For example, diagnosing negative runtime authentication results or an administrative interface that displays confusing results.

User Group Life Cycle Activity Report

Lists all activities for a specific user or group domain object. For example, the administrative actions performed on the user’s record by an administrator.

Non-User or Group Object Life Cycle Activity Report

Lists all activities for a specific domain object other than a user or group.

System Log Report Lists all log entries from the system log.

Users with Days Since Last Log On, Using Specific Token

Shows the number of days since the user’s last logon and the date of last logon for a specific token type.

Users with Tokens with Wildcard

Lists all users with RSA SecurID tokens. Use it to generate reports such as Users With Lost Tokens, Users With Disabled Tokens, Users With Software Tokens, and Users With Tokens.



Scheduling ReportsYou can run reports manually at any time, or you can schedule them to run automatically at predetermined times. This enables you to meet any requirements for recurring reports, while enabling you to run reports in response to unplanned requests. Both tasks are accomplished through the Reporting tab on the RSA Security Console.

Logging and Reporting Checklist

Action Item

Consider which logging and reporting options you want to use.

Consider how you want to manage your log files.

Decide if, and how often, you want to archive log files.

Consider how you want to manage log files.

Consider what information and alerts you want to trap and send to your NMS.

Plan who has permission to run reports.

Review the available reports.

Plan when and how you want your reports to run.



12Completing The Deployment ChecklistUse the following checklist to specify installation and configuration information for your deployment. Distribute this list to the appropriate personnel.

Deployment Checklist

Pre-Installation


License type • Base • Advanced

Platform • Windows• Linux

Master password

12: Completing The Deployment Checklist 121


Installation


Primary instance Physical location

Name and IP address of the database server

Name and IP address of any server nodes

Replica instances Number of instances

Physical location(s)

Name and IP address of the database server

Name and IP address of any server nodes

122 12: Completing The Deployment Checklist


Identity Source Configuration


Identity source(s) Number and typeFor example:• RSA Authentication Manager

internal database • Active Directory • Active Directory forests • Sun Java System Directory

Server

LDAP URL of the LDAP identity source

User defined unique identity source name

LDAP server user name

LDAP server password

URL of the failover identity source (optional)

Authentication Manager administrator user name

Authentication Manager administrator password



Administrative Configuration


Realm Number

Names

Security domains Top-level name

Lower-level names

Token(s) Number and typeFor example:• RSA SecurID token • RSA Smart Card • RSA SecurID Software

Toolbar Token• RSA USB token

Contact person for obtaining token seed records

Policies Number of custom policies

Names of security domains requiring custom policies




Method of PIN creationFor example:• System-generated• User-generated

Length of PINs (4-8 characters)

Character restrictions on PINs

Number of failed authentication attempts allowed before user lockout

Method of unlocking locked user.For example:• Automatically• Manually

Password lifetime

Maximum and minimum password length

Number of restricted old passwords

Excluded words dictionary

Character restrictions on password

Lifetime of Emergency Access Tokencodes

Behavior of Emergency Access Tokencode when token is recoveredFor example:• Deny authentication with the

token• Allow authentication with the

token and disable the Emergency Access Tokencode

• Allow authentication with the token only after the Emergency Access Tokencode expires



Post-Installation


Resources to protect

For example:• File servers • Databases • Identity sources

Agents Number

Physical location of agents

Name and IP address of agents



Glossary

Term Definition

Active Directory The directory service that is included with Microsoft Windows Server 2003 and Microsoft Windows 2000 Server.

Active Directory forest A federation of identity servers for Windows Server environments. All identity servers share a common schema, configuration, and Global Catalog.

AD See Active Directory.

adjudicator A component that defends Authentication Manager against replay attacks in which an intruder attempts to reuse an old passcode or acquires the current passcode for a token and sets the system clock back to use the captured passcode.

administrative command A command other than a system-generated command.

administrative role A collection of permissions and the scope within which those permissions apply.

administrator Any user with one or more administrative roles that grants administrative permission to manage administrative resources.

Advanced Encryption Standard (AES) The current cryptographic standard, adopted by the National Institute of Standards and Technology (NIST) in November, 2001. AES replaces Data Encryption Standard (DES) because it is considered to be more secure.

Advanced license Authentication Manager license that allows a primary instance, multiple replica instances, and multiple server nodes.

AES See Advanced Encryption Standard.

agent A software application installed on a device, such as a domain server, web server, or desktop computer, which enables authentication communication with Authentication Manager on the network server.

Agent Auto-Registration Service A utility included in the RSA Authentication Agent software that enables you to automatically register new authentication agents in the internal database, and updates the IP addresses for existing agents.

agent host The machine on which an agent is installed.

Glossary 127


Agent Protocol Server The Authentication Manager component that manages the ACE protocol packet traffic to and from agents. The inbound request packets are routed to the appropriate message handler. The response packets are sent to the originating agent.

attribute A characteristic that defines the state, appearance, value, or setting of something. In Authentication Manager, attributes are values associated with users and user groups. For example, each user group has three standard attributes called Name, Identity Source, and Security Domain.

attribute mapping The process of relating a user or user group attribute, such as User ID or Last Name, to one or more identity sources linked to a given realm. No attribute mapping is required in a deployment where the internal database is the primary identity source.

audit information Data found in the audit log representing a history of system events or activity including changes to policy or configuration, authentications, authorizations, and so on.

audit log A system-generated file that is a record of system events or activity. The system includes four such files, called the Trace, Administrative, Runtime Audit ,and System logs.

authentication The process of reliably determining the identity of a user or process.

authentication authority The central entry point for authentication services.

authentication broker A component that handles the authentication process and issuance of authentication tickets.

authentication method The type of procedure required for obtaining authentication, such as a one-step procedure, a multiple-option procedure, or a chained procedure.

authentication policy A collection of rules that specify the authentication requirements. An authentication policy may be associated with one or more resources.

authentication protocol The convention used to transfer credentials of a user during authentication. For example, HTTP-BASIC/DIGEST, NTLM, Kerberos, and SPNEGO.

Authentication Server An Authentication Manager component made up of services that handle authentication requests, database operations, and connections to the RSA Security Console.

Term Definition

128 Glossary


authenticator A mechanism for users to verify their identity to the Authentication Manager. This can be either hardware (for example, RSA SecurID) or software (for example, RSA SecurID software token).

authorization The process of determining if a user is allowed to perform an operation on a resource.

authorization data A container of information defined by the provisioning server, which is necessary to complete the provisioning of a CT_KIP ready token. Authorization data includes the appropriate serial number and places the new token credentials in the Authentication Manager database.

auto-registration A setting which, if enabled, permits unregistered users to become registered upon a successful authentication to a system-managed resource. If auto-registration is disabled, only an administrative action can register users. Also see registered user and unregistered user.

Base license Authentication Manager license that allows one primary instance and one replica instance. Also see Advanced license.

cache A type of computer memory with fast access time that is used for storing frequently used instructions or data. Users cannot directly interact with the cache.

certificate An asymmetric key that corresponds with a private key. Either self-signed or signed with the private key of another certificate.

chained authentication The process of creating a strong form of authentication by combining two weaker forms. For example, the user is required to use a PIN and a tokencode.

CIDR See Classless Inter-Domain Routing.

Classless Inter-Domain Routing (CIDR) A bitwise, prefix-based standard for the interpretation of IP addresses. CIDR replaces the old A, B, and C address scheme for more efficient allocation of IP addresses.

client time-out The amount of time (in seconds) that the user’s desktop can be inactive before reauthentication is required.

CLU See command line utility.

cluster An instance consisting of a database server and one or more server nodes.

Term Definition

Glossary 129


command line utility (CLU) A utility that provides a command line user interface.

connection pool A group of identical database connections between Authentication Manager and the data store.

contact list A list of server nodes provided by the Authentication Manager to the agent, where the agent can direct authentication requests.

context-based authentication An authentication sequence in which the system presents the user with only the authentication options that are appropriate for the User ID entered. The options are based on policy requirements and the authenticators that the user owns.

core attributes The fixed set of attributes commonly used by all RSA Security products to create a user. These attributes are always part of the primary user record, whether the deployment is in an LDAP or RDBMS environment. You cannot exclude core attributes from a view, but they are available for delegation.

cryptographic algorithm A mathematical function that uses plain text as the input and produces cipher text as the output and vice-versa. It is used for encryption and decryption.

CT-KIP Cryptographic Token-Key Initialization Protocol.

CT-KIP client A program that implements the CT-KIP client-side protocol and interacts with a CT-KIP server for the secure initialization of tokens.

CT-KIP enabled token A token that is capable of storing the authorization data and seed generated as a result of CT-KIP operations between a CT-KIP 1.0 client and an RSA Authentication Manager 7.0 CT-KIP server.

CT-KIP protocol messages The Protocol Data Units (PDU) exchanged between client and server in order to generate a seed on both server and client.

CT-KIP protocol transport binding Specifies a binding of the CT-KIP message interaction such as requests and responses to a transport protocol such as HTTP.

CT-KIP server A software component of Authentication Manager that implements the CT-KIP server-side protocol and interacts with a CT-KIP client application for the secure initialization of tokens.

Term Definition

130 Glossary


CT-KIP toolkit An implementation of the CT-KIP client-server protocol. It provides the API for creating CT-KIP server or client applications.

customer name The name of the enterprise to which the license is issued.

data encryption standard operation (DES) The cryptographic standard prior to November 2001, when the National Institute of Standards and Technology (NIST) adopted the Advanced Encryption Standard (AES).

data store A data source such as a relational database (Oracle or DB2) or directory server (Sun Java System Directory Server or Microsoft Active Directory). Each type of data source manages and accesses data differently.

Data Transfer Object (DTO) Simple object used to pass data between tiers. It does not contain business logic.

database server The server where the database is installed.

delegated administration A scheme for defining the scope and responsibilities of a set of administrators. It permits administrators to delegate a portion of their responsibilities to another administrator.

denial of service The result of barraging a server with requests that consume all the available system resources, or of passing malformed input data that can cause the system to stop responding.

deployment The arrangement of Authentication Manager elements into appropriate locations in a network to perform authentication.

DES See data encryption standard operations.

DTO See data transfer object.

dump An RSA ACE/Server format used to back up, restore, and merge database information. A dump file is a binary data file that contains all database tables and columns in table-dependency order.

EAP See extensible authentication protocol.

emergency access The process for enabling a token for a user whose token is not available or is not functioning. Used in connection with offline authentication access.

emergency access passcode A complete authentication code that, if enabled, can be used by a user to perform an offline authentication without an authenticator or PIN.

Term Definition

Glossary 131


emergency access tokencode A partial authentication code that, if enabled, can be used by a user to perform an offline authentication without an authenticator. The user is required to provide his or her PIN.

Evaluation license Authorizes an evaluation copy of the product at a customer site.

extensible authentication protocol (EAP) An authentication protocol that supports multiple authentication methods, including one-time passcodes used for RSA SecurID authentication.

external attributes Customer-defined attributes for which the value is dynamically derived through a callout function (class). These are necessary for RSA ClearTrust backward compatibility. You can report and query on these attributes.

failover mode Refers to the state in which the connection pool management service has to use the secondary connection pools for serving the connection requests, because the primary connection pools are not available due to the failed primary.

floating license An enterprise license that is not attached to any particular product and instance combination. It can apply to any machine running the product.

four-pass CT-KIP The exchange of two protocol data units (PDUs) between the client and server.

Global Catalog A read-only, replicated repository of a subset of the attributes of all entries in a forest.

graded authentication A mechanism for noting the relative strengths of authentication methods (either individually or as combinations). For example, an RSA SecurID token is better than a user name and password. Equivalently ranked methods may be used interchangeably.

high-water-mark The highest numbered interval used by a user to authenticate.

identity attribute definitions Customer-defined attributes that are mapped to an existing customer-defined schema element. They are always stored in the same physical repository as the user’s or user group’s core attribute data. You can search, query, and report on these attributes. Each identity attribute definition must map to an existing attribute in the LDAP or RDBMS.

Term Definition

132 Glossary


Identity Management Services The set of shared components, toolkits, and services used to build RSA Security products, for example, Authentication Manager.

identity source A data store containing user and user group data. The data store can be the internal database or an external directory server, such as Sun Java System Directory Server or Microsoft Active Directory.

IMS See Identity Management Services.

initial time-out The wait time, in seconds, before the initial remote access prompt appears. (The term is used in relation to remote RSA SecurID authentication.)

instance A single database server, or a database server and one or more server nodes, acting as a single cohesive processing unit.

instance ID This ID identifies a single logical installation of a product or component. For example, in a non-clustered environment, it identifies the database server. In a clustered environment, it identifies the database server and the entire cluster of server nodes. Likewise for web agents, a single agent may have a unique instance ID or an entire server farm may share a single instance ID.

instance name The name assigned to an instance. It is either the hostname where a single server node is installed or the cluster name where the clustered instance is installed.

interval A value used to represent a specific time-based PRN code being generated by an authenticator.

internal database The Authentication Manager proprietary data source.

J2EE Java 2 Enterprise Edition. A framework for building enterprise applications using Java technology.

Java Cryptographic Architecture (JCA) The set of APIs provided by the Java 2 platform that establishes the architecture and encapsulates limited cryptographic functionality from various cryptographic providers.

Java Cryptographic Extensions (JCE) The set of APIs provided by the Java 2 platform that encapsulates additional cryptographic functionality from various cryptographic providers.

Term Definition

Glossary 133


Java Management Extensions (JMX) The set of APIs provided by the Java 2 platform that enables building distributed, web-based, dynamic and modular solutions for managing and monitoring devices, applications, and service-driven networks.

Java Messaging Service (JMS) A standard Java interface for interacting with message queues and topics.

Java Server Pages (JSP) A commonly used technology for dynamic web content.

JCA See Java Cryptographic Architecture.

JCE See Java Cryptographic Extensions.

JKS The Java 2 platform implementation of a keystore provided by Sun Microsystems.

JMS See Java Messaging Service.

JMX See Java Management Extensions.

JSP See Java Server Pages.

keystore The Java 2 platform facility for storing keys and certificates.

Key Management The management of the generation, use, storage, security, exchange, and replacement of cryptographic keys.

Key Management encryption key The key used for encryption or decryption operations of keys managed by Key Management Services.

LAC See Local Authentication Client.

license A verifiable piece of information that represents permission from RSA Security to use Authentication Manager, its features, or both. A license is a component of the License Management Service.

license category A way of grouping different types of licenses. Base license, Advanced license, and Evaluation license are the three license categories.

license creation date The date when the license file was created.

license deployment Specifies either a server or floating license.

license file An XML file containing license data that is common across all IMS-based products. The categories of data are: client, product, and feature. A license file is a component of LMS.

Term Definition

134 Glossary


license file version The version of the license schema to which the generated license conforms.

license ID An internal identifier associated with the license. RSA Manufacturing assigns the license ID.

License Management Service (LMS) A service responsible for managing and validating software licenses.

license.rec A license record file containing the database key needed to extract critical information from the DMP file.

LMS See License Management Service.

Local Authentication Client (LAC) An RSA Authentication Agent component that requires users to enter valid RSA SecurID passcodes to access their Microsoft Windows desktops.

locked license A license limited to a specific server instance. See server license.

lockout policy A set of conditions specifying the conditions under which an account is locked and whether the account must be unlocked by an administrator or will unlock on its own after a designated amount of time. Lockout policies are applied to security domains.

log archival Creates a backup copy of the log for noncurrent, permanent storage.

logging service A component responsible for recording system, audit, and trace events.

lower-level security domain In a security domain hierarchy, a security domain that is nested within another security domain.

Management Information Base (MIB) A type of virtual database used to manage the devices (switches and routers, for example) in a communication network. For example, SNMP uses MIB to specify the data in a device subsystem.

MD5 An algorithm that produces a 128-bit message digest.

member user A user who is a member of a member user group.

Term Definition

Glossary 135


member user group A user group that is a member of another user group. For example, an organization might define a Sales Managers user group within a North America user group.All member user groups must belong to the same identity source as the parent group, with one exception: any user group from any identity source can be assigned to a parent group that is stored in the internal database.

MIB See Management Information Base.

Microsoft Management Console (MMC) A user interface through which system administrators can configure and monitor the system.

MMC See Microsoft Management Console.

namespace A set of names. A namespace defines a scope for a collection of names.

Network Management System (NMS) Software used to manage and administer a network. The NMS uses SNMP to monitor networked devices and is responsible for polling and receiving SNMP traps from agents in the network.

NEXUS The external marketing name for the RSA Security Identity and Access Management vision and strategy. NEXUS is not a product.

NMS See Network Management System.

NMS administrator The person monitoring the network (through the NMS) for significant events. Also known as a network administrator.

node secret A long-lived symmetric key that the agent uses to encrypt the data in the authentication request. Authentication Manager generates the authentication request when a user makes a successful authentication attempt. The node secret is known only to the Authentication Manager and the agent.

object Describes the following: security domains, identity sources, attributes, users, user groups, administrative roles, and policies.

offset A value used to represent the amount of time an authenticator’s internal clock has drifted over time.

PAM See Pluggable Authentication Modules.

passcode A code entered by a user to authenticate. The passcode is a combination of a PIN and a tokencode.

Term Definition

136 Glossary


password-based encryption The process of obscuring information so that it is unreadable without knowledge of the password.

password policy A set of specifications that define what constitutes a valid password and the conditions under which the password expires. Password policies are applied to security domains.

PDU See Protocol Data Unit.

permissions Specifies which tasks an administrator is allowed to perform.

Pluggable Authentication Modules (PAM) Mechanisms that allow the integration of new authentication methods into an API, independent of the existing API authentication scheme.

primary connection pool Refers to the connection pools containing the connections to the primary instance database server.

primary instance The instance of the Authentication Manager software installation at which authentication and all administrative actions occur.

private key In asymmetric key cryptography, the cryptographic key that corresponds to the public key. The private key is usually protected by some external mechanism (for example, smart card, password encrypted, and so on).

PRN See pseudorandom number.

Protocol Data Unit A packet of data exchanged between two application programs across a network.

provisioning data The provisioning server-defined data. This is a container of information necessary to complete the provisioning of a token device. Its format is not specified by CT-KIP because it is outside the realm of CT-KIP, but it is necessary for provisioning.

pseudorandom number (PRN) A random number or sequence of numbers derived from a single seed value.

public key In asymmetric key cryptography, the cryptographic key that corresponds with the private key. The public key is usually encapsulated within a certificate.

RADIUS See Remote Authentication Dial-In User Service.

Term Definition

Glossary 137


realm An entire security domain hierarchy consisting of a top-level security domain and all of its lower-level security domains. A realm includes all of the objects managed within the security domain hierarchy (users, tokens, and password policies, for example). Each realm manages users and user groups in one or more identity sources.

regular time-out The number of seconds before remote access prompts time out. The term is used in relation to remote RSA SecurID authentication.

Remote Authentication Dial-In User Service (RADIUS)

A UDP-based protocol for administering and securing remote access to a network.

remote EAP (extensible authentication protocol) A remote authentication feature that requires users to submit RSA SecurID passcodes in order to open remote connections to the network. EAP has a graphical user interface and enhanced security and is supported in both Point-to-Point Protocol (PPP) authentication environments and non-PPP authentication environments, including Point-to-Point Tunneling Protocol (PPTP) VPN connections, 802.1x wired, and 802.11 wireless connections, and other specialized network media.

remote post-dial Refers to the dial-in Point-to-Point Protocol (PPP) authentication support. With a post-dial terminal-based connection, when remote users dial in, a terminal-like character interface presents a simple user name and passcode prompt. If the right passcode is entered, the PPP connection is established. If the wrong passcode is entered, the dial-up connection is severed.

replica instance The instance of the Authentication Manager software installation at which authentication occurs and at which an administrator can view the administrative data.No administrative actions are performed on the replica instance. All administrative actions are performed on the primary instance.

RSA Security Console A user interface through which the user performs tasks using Authentication Manager.

RSA Security EAP The RSA Security implementation of the EAP 15 authentication protocol that facilitates RSA SecurID authentication to networks in PPP, PPTP (VPN), and 802.1x (wireless or port access) environments.

Term Definition

138 Glossary


RSA Security Protected OTP The RSA Security implementation of the EAP 32 authentication protocol that facilitates RSA SecurID authentication to networks in PPP, PPTP (VPN), and 802.1x (wireless or port access) environments.

runtime Describes automated processing behavior—behavior that occurs without direct administrator interaction.

runtime command A logon or logoff command.

runtime identity source The runtime representation of the identity source. Runtime identity sources are used during runtime operations, such as authentication and group membership resolution instead of the corresponding administrative source, which is used for all other operations. This is an integral part of Active Directory forest support, which uses the Global Catalog during runtime operations.

scope In a realm, the security domain or domains within which a role’s permissions apply.

secondary connection pool Refers to the connection pools containing the connections to the secondary data stores.

Secure Sockets Layer (SSL) A protocol that uses cryptography to enable secure communication over the Internet. SSL is widely supported by leading web browsers and web servers.

security domain A container that defines an area of administrative management responsibility, typically in terms of business units, departments, partners, and so on. Security domains establish ownership and namespaces for objects (users, roles, permissions, and so on) within the system. They are hierarchical.

server license A non-floating license that is associated with the product and instance for which it is installed. The license applies to the specific instance hosting the product.

server node An installation of Authentication Manager on a single server host. Each instance has one server node that contains the internal database. You can add additional server nodes to an instance. The additional server nodes cannot operate alone because they do not contain the internal database.

session An encounter between a user and a software application that contains data pertaining to the user’s interaction with the application. A session begins when the user logs on to the software application and ends when the user logs off of the software application.

Term Definition

Glossary 139


session policy A set of specifications designating the restrictions on overall session lifetime and multiple session handling. Session policies are applied to an instance.

SHA1 A secure hash algorithm function that produces a 160-bit hash result.

Simple Network Management Protocol (SNMP) A protocol for exchanging information about networked devices and processes. SNMP uses MIBs to specify the management data, and then uses the User Datagram Protocol (UDP) to pass the data between SNMP management stations and the SNMP agents.

single sign-on (SSO) The process of requiring only a single user authentication event in order to access multiple applications and resources.

snap-in A software program designed to function as a modular component of another software application. For example, the MMC has a variety of snap-ins that offer different functionality (for example, Device Manager).

SNMP See Simple Network Management Protocol.

SNMP Agent Software module that performs the network management functions requested by network management stations.

SNMP trap An asynchronous event that is generated by the agent to tell the NMS that a significant event has occurred. SNMP traps are designed to capture errors and reveal their locations.

SSL See Secure Sockets Layer.

SSO See single sign-on.

Super Admin An administrator who has all permissions within the system. A Super Admin:• Can create and delete realms• Can link identity sources to realms• Has full permissions within any realm• Can assign administrative roles within any realm

symmetric key A key that allows the same key value for the encryption and decryption of data.

system event System-generated information related to nonfunctional system events such as server startup and shutdown, failover events, replication events, and so on.

system log Persistable store for recording system events.

Term Definition

140 Glossary


TACACS+ See Terminal Access Controller Access Control System+.

Terminal Access Controller Access Control System+ (TACACS+)

A remote authentication protocol that is used to communicate with an authentication server. Allows a remote access server to communicate with an authentication server in order to determine if a user has access to the network.

token A hardware device or software program that generates a pseudorandom number that is used in authentication procedures to verify a user’s identity.

tokencode The random number displayed on the front of a user’s RSA SecurID token. Tokencodes change at a specified time interval, typically every 60 seconds.

top-level security domain The top-level security domain is the first security domain in the security domain hierarchy (realm). The top-level security domain is unique in that it links to the identity source or sources and manages password, locking, and authentication policy for the entire realm.

trace log Persistable store for trace information.

two-factor authentication An authentication protocol requiring two different ways of establishing and proving identity.

two-pass CT-KIP The exchange of one protocol data unit (PDU) between the client and server.

UDP See User Datagram Protocol.

user An account managed by the system that is usually a person, but may be a computer or a web service.

User Datagram Protocol (UDP) A protocol that allows programs on networked computers to communicate with one another by sending short messages called datagrams.

user group A collection of users, other user groups, or both.

User ID A character string that the system uses to identify a user attempting to authenticate.Typically a User ID is the user’s first initial followed by the last name. For example, Jane Doe’s User ID might be jdoe.

Term Definition

Glossary 141


IndexAActive Directory

definition, 127forest, definition, 127Global Catalog, 82integration of forests, 82integration process, 81Microsoft Management Console, 93runtime identity source, 82supported version, 79

Active Directory forestdefinition, 127

Activity Monitor, 115adjudicator

definition, 127administration

Authentication Manager model, 85LDAP privileges, 42Microsoft Management Console, 93planning roles, permissions, and

scope, 85RSA Security Console, 93SNMP trapping, 118where to perform, 11

administrative commanddefinition, 127

administrative roleassigning, 86custom, 85definition, 127predefined, 85, 89

administratorabout, 85assigning roles, 86definition, 127permissions, 86predefined roles, 89scope, 87training topics, 94–95

Advanced licensedefinition, 127

agentdefinition, 127definition and concept, 13

Agent Auto-Registration Servicedefinition, 127

agent hostdefinition, 127

Agent Protocol Serverdefinition, 128

agent record, 43archive. See loggingarchiving

disk space, 117frequency, 117purge logs, 117

attributedefinition, 128mapping, 80

attribute mappingdefinition, 128

audit informationdefinition, 128

audit logdefinition, 128

authenticationdata required by Authentication

Manager, 43definition, 128emergency access, 56end-user experience, 47example, 48offline, 54process, 9, 43when not connected to the network, 54

authentication agentdeploying, 51embedded, 19, 24, 32, 43protecting Windows desktops, 50role of, 47RSA Security partners, 19, 24, 32, 43software, 43third-party, 19, 24, 32, 43

authentication authoritydefinition, 128

authentication policydefinition, 128

Authentication Serverdefinition, 128

authenticatordefinition, 129

authorizationdefinition, 129

authorization datadefinition, 129

automatic contact lists, 44

Index 143


auto-registrationdefinition, 129

BBase license

definition, 129browser

security, 61support, 61

Ccache

definition, 129certificate

definition, 129certificate of authority, 80chained authentication

definition, 129character requirements

PINs, 99checklist

administration, 95architecture, 46deployment, 121deployment model, 35disaster recovery, 72installation, 84logging and reporting, 120policies, 105RSA SecurID protection, 58system and security requirements, 65token deployment, 114

CITRIXprotecting access to servers, 50

CLU. See Command Line Utilitycluster

definition, 129server node, 11

command line utilitydefinition, 130Initialize Identity Source, 25, 33Migration, 76

communicationagent to server, 13

concepts. See definitions and conceptsconnection pool

definition, 130contact list

definition, 130

contact lists, 44automatic, 44manual, 44

context-based authenticationdefinition, 130

Coordinated Universal Time, 62core attributes

definition, 130Cryptographic Token-Key Initialization

Protocol, 112client, 130enabled token, 130failover, 69, 112server, 130toolkit, 131

CT-KIP. See Cryptographic Token-Key Initialization Protocol

Ddamaged tokens, 102data replication, 40data store

definition, 131Data Transfer Object

definition, 131database server, 38

definition, 131default policy

for lockout, 100definitions and concepts, 9–13delegated administration

definition, 131deployment

definition, 131definition and concept, 9

deployment model checklist, 35disk space, 60DTO. See Data Transfer Objectdump file

definition, 131

Eemergency access, 56, 102

definition, 131example, 102

emergency access passcodedefinition, 131

emergency access tokencode, 102definition, 132expiration date, 102

evasion-of-attack, 45

144 Index


excluded wordspasswords, 101PINs, 99

existing Authentication Managermigrating data, 76

expirationof emergency access tokencode, 102

extension fields and LDAP, 42

Ffailover mode

definition, 132Firefox, 61FTP

protecting, 50

GGlobal Catalog

Active Directory, 82definition, 132integration, 82runtime identity source, 82

graded authenticationdefinition, 132

Hhardware requirements, 60

Iidentity attribute definitions

definition, 132Identity Management Services

definition, 133identity source

Active Directory integration, 81choosing, 41definition, 41, 133establishing security, 80integration, 78mapping attributes, 80performing integration, 80Sun Java System Directory Server

integration, 83types, 41, 79using LDAP, 42

IMS. See Identity Management ServicesInitialize Identity Source utility, 25, 33

installationcoordinating, 73firewall access, 76Microsoft Management Console, 94permissions, 73personnel, 75primary instance, 77replica instance, 77security, 75server node, 78timetable, 75

instancedefinition, 133definition and concept, 11

integrationActive Directory, 81Active Directory forests, 82certificate of authority, 80DNS namespaces, 82Global Catalog, 82IIS, 80LDAP directory, 78mapping attributes, 80process, 80read/write, 79read-only, 79Secure Sockets Layer, 80Sun Java System Directory Server, 83supported LDAP directories, 79

internal databasedefinition, 133

Internet Explorer, 61

JJavaScript, 61

Kkernel parameter requirements, 60Key Management encryption key

definition, 134keystore

definition, 134

LLAC. See Local Authentication Clientlarge scenario

logical deployment, 28physical deployment, 25

Index 145


LDAPand replication, 41ensuring sufficient administrative

privileges, 42integration, 78mapping attributes, 42storing data in, 42using as an identity source, 41using LDAP data, 42

LDAP directoryread/write, 79read-only, 79supported types, 79

licenseAdvanced, 75, 127Base, 75, 129

license IDdetermining, 8

Linuxrequirements, 60

load balancingcontact lists, 44

local authenticationin a Windows environment, 51

Local Authentication Clientdefinition, 135

locking user accounts, 100lockout policy, 100

definition, 135log archival

definition, 135logging

archive, 117consolidation, 118create log files, 117file types, 116files not included, 118log files location, 118maintenance, 116Network Management System, 118planning, 115types, 115

logging servicedefinition, 135

logical deploymentlarge, 28medium, 22small, 18

lost tokens, 102lower-level security domain

definition, 135

Mmanual contact lists, 44mapping LDAP data, 42master password

export for backup, 64recovery, 64securing, 64

medium scenariological deployment, 22physical deployment, 20

member userdefinition, 135

member user groupdefinition, 136

memory requirements, 60Microsoft Management Console

Active Directory, 94administration, 93definition, 136installation, 94

migrating users and tokens, 76Migration utility, 76MMC. See Microsoft Management Console

Nnamespace

definition, 136Network Management System, 136

logging, 118node secret

definition, 136node. See server node

Oobject

definition, 136offline authentication, 54

planning security policies, 54OpenSSH

support for, 50Outlook Web Access

protecting access through, 49

PPAM. See Pluggable Authentication Modulepasscode

definition, 136stolen, 45

146 Index


passwordpolicies, 101requirements, 101

password policydefinition, 137

permissionsassigning, 86definition, 137

physical deploymentlarge scenario, 25medium scenario, 20small scenario, 17

pilot testconsiderations, 83

PINscharacter requirements, 99characteristics of, 97methods of creation, 97stolen, 45

Pluggable Authentication Module, 50protecting other protocols, 50

policieslockout, 100password, 101

port usagedescription, 62port number, 62protocol, 62service, 62

primary connection pooldefinition, 137

primary instancedefinition, 137definition and concept, 11functionality, 37installation, 77number allowed, 11

private keydefinition, 137

protecting Windows desktops, 50provisioning data

definition, 137public key

definition, 137purge logs. See archiving

RRADIUS. See Remote Authentication Dial-

In User Service

realmdefinition, 138definition and concept, 9

Red Hat Package Managerversions required, 61

Remote Authentication Dial-In User Servicedefinition, 138protecting access through, 49

replica instancedefinition, 138definition and concept, 11functionality, 37installation, 77number allowed, 77requirements, 77role in backing up data, 37

replicated data, 40replication, 38, 40

and LDAP, 41reports

permissions, 118planning, 115run-as, 118scheduling, 119types available, 119

requirementsmachines, 75primary instance, 77replica instance, 77server node, 78

roles. See administrative roleRPM. See Red Hat Package ManagerRSA SecurID token

definition, 47RSA SecurID tokens. See tokensRSA Security Console

definition, 138integration, 80supported browsers, 61

RSA Security partners, 19, 24, 32, 43runtime

definition, 139runtime changes, 39runtime identity source

as a normal domain, 82definition, 139Global Catalog, 82

Index 147


Sscenarios

large, 25medium, 20small, 17summary table, 16

scopeassigning, 87definition, 139definition and concept, 87

sdopts.rec file, 44Secure Sockets Layer

definition, 139establishing, 80integration, 80Sun Java System Directory Server, 83

securityof connections, 64of equipment, 64

Security Consoledefinition, 138integration, 80supported browsers, 61

security domaindefinition, 139definition and concept, 10

server node, 38cluster, 11definition, 139definition and concept, 11installation, 78requirements, 78

sessiondefinition, 139

Simple Network Management ProtocolAgent, 140definition, 140trap, 140Trapping, Network Management

Server, 118single sign-on

definition, 140small scenario

logical deployment, 18physical deployment, 17

snap-indefinition, 140

SNMP. See Simple Network Management Protocol

SSL. See Secure Sockets LayerSSO. See single sign on

stolen passcodes, 45stolen PINs, 45storing data

determining best location, 41in LDAP, 42user data, 41

Sun Java System Directory Serverintegration process, 83Secure Sockets Layer, 83supported version, 79

Super Admindefinition, 140

supported browsersRSA Security Console, 61

swap space requirements, 60system

required packages, 61system clock

setting, 62system events

log types, 116system requirements

Linux, 60Microsoft Windows, 60

system-generated PINs, 97

TTACACS. See Terminal Access Controller

Access Control Systemtelnet

protecting access through, 50Terminal Access Controller Access Control

Systemprotecting access through, 49

third-party authentication agent, 43time synchronization, 62token record, 43tokencode

definition, 141tokens, 107

Cryptographic Token-Code Initialization Protocol, 112

definition, 141emergency access, 102lost or damaged, 102remote token key generation, 112software, 111training users, 112

top-level security domaindefinition, 141

148 Index


trace logdefinition, 141

training topics, 94two-factor authentication, 43

definition, 141

Uuser

definition, 141user group

definition, 141User ID

definition, 141user record, 43user-generated PINs, 97

UTC. See Coordinated Universal Time

Vversion number, determining, 8Virtual Private Network

protectingVPN. See Virtual Private Network

Wweb pages

protecting access to, 50Windows Event Log, 118Windows password integration, 53Windows requirements, 60

Index 149

rsa authentication and deploymant planning

Documents