RSA Authentication Manager 7.0 Planning Guide

RSA Authentication Manager 7.0 Planning Guide

Contact Information See the RSA corporate web site for regional Customer Support telephone and fax numbers. RSA Security Inc. www.rsa.com Trademarks RSA 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 agreement This 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 licenses This 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 technologies This 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. Distribution Limit distribution of this document to trusted personnel. RSA notice The 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

Contents Preface... 7 About This Guide...7 RSA Authentication Manager Documentation... 7 Tutorials...7 Related Documentation... 8 Getting Support and Service... 8 Before You Call Customer Support... 8 Chapter 1: Essential Terms and Concepts... 9 Understanding the RSA Authentication Manager Deployment Process... 9 Terms and Concepts to Know Before Planning... 9 Deployment... 9 Realm...9 Security Domain... 10 Instance...11 Server Node...11 Primary Instance...11 Replica Instance...11 Agent... 13 Chapter 2: Identifying Your Deployment Model... 15 Using Scenarios to Plan Your Deployment... 15 The Small Deployment: Miller and Strauss, Attorneys at Law... 17 The Medium-Sized Deployment: Greenley Biotechnologies... 20 The Large Deployment: FocalView Software Company... 25 Deployment Model Checklist... 35 Chapter 3: The RSA Authentication Manager Architecture... 37 About the RSA Authentication Manager Model... 37 How Database Replication Works... 38 Replication of Data... 40 RSA Authentication Manager Database Architecture... 41 Deciding Where to Store Data... 41 Planning to Use the Internal Database As Your Data Store... 42 Planning to Use an LDAP Directory As Your Data Store... 42 Authentication of Users... 42 Planning Load Balancing Using Contact Lists... 44 Attack Prevention... 44 RSA Authentication Manager Architecture Checklist... 46 Contents 3

Chapter 4: Planning RSA SecurID Protection... 47 Overview of the Authentication Experience... 47 RSA SecurID Tokens... 47 Authentication Agents... 47 RSA Authentication Manager... 48 Deciding Which Resources to Protect with RSA SecurID... 49 Protecting RSA Authentication Manager Servers... 49 Protecting Access Through a VPN... 49 Protecting Access Through a Radius Server... 49 Protecting Access Through TACACS... 49 Protecting Access to Outlook Web Access... 49 Protecting Access to Web Pages... 50 Protecting FTP and Other UNIX-Based Protocols... 50 Protecting Access to a CITRIX Server... 50 Microsoft Windows Desktops... 50 Protecting Windows Desktops with RSA SecurID for Microsoft Windows... 50 Deploying the Authentication Agent in a Microsoft Windows Environment... 51 RSA SecurID Protection Checklist... 58 Chapter 5: Assessing System and Security Requirements... 59 System Requirements... 59 Supported Browsers... 61 Maintaining Accurate System Time Settings... 62 Planning Port Usage... 62 Planning for Peak Authentication Periods... 63 Planning Management of the Master Password... 64 Planning Physical Security... 64 System and Security Requirements Checklist... 65 Chapter 6: Planning for Failover and Disaster Recovery... 67 Key Issues to Consider... 67 Planning for Possible Failure Situations... 67 Detecting a Failed Primary or Replica Instance... 67 What Happens After the Primary Instance Fails... 68 What Happens If a Replica Instance Fails... 70 Planning Recovery from the Loss of a Non-Database Server Node... 71 Planning Regular Database Backups... 71 Disaster Recovery Checklist... 72 4 Contents

Chapter 7: Planning Your Installation... 73 Assessing Required Permissions for Installation... 73 Planning Your RSA Authentication Manager Installation... 74 Minimum Requirements for Machines... 75 License Permissions... 75 The Necessary Level of Security... 75 Personnel to Perform the Installation... 75 The Best Time to Perform the Installation... 75 Access Through Firewalls... 76 Access Through Proxy Servers... 76 Migrating Users from an Existing RSA ACE/Server or RSA Authentication Manager Deployment... 76 Planning Primary Instance Installation... 77 Planning Replica Instance Installation... 77 Planning Server Nodes Installation... 78 Planning LDAP Directory Integration... 78 Supported External Identity Sources... 79 Selecting Read-Only or Read/Write... 79 Establishing Security... 80 Performing the Integration... 80 Mapping Attributes... 80 Planning Active Directory Integration... 81 Global Catalogs... 82 Planning Sun Java System Directory Server Integration... 83 Conducting a Pilot Test... 83 Installation Checklist... 84 Chapter 8: Planning for Administration... 85 About the RSA Authentication Manager Administrative Model... 85 Planning Administrative Roles, Permissions, and Scope... 85 Predefined Admininstrative Roles... 89 Planning Administration Through the Microsoft Management Console (MMC)... 93 Planning RSA Authentication Manager Training for Help Desk Administrators... 94 Administration Checklist... 95 Chapter 9: Planning PIN, Token, and Password Policies... 97 Planning PIN Policy... 97 Determining PIN Creation Methods... 97 Balancing Security and Ease of Use in Determining PIN Policy... 98 Planning PIN Requirements and Restrictions... 98 Planning Multiple PIN Policies Through the Use of Security Domains... 100 Determining When to Lock Out Users After Failed Authentications... 100 Planning Password Requirements and Restrictions... 101 Planning Emergency Access... 102 Policies Checklist... 105 Contents 5

Chapter 10: Planning RSA SecurID Token Deployment... 107 Overview of RSA SecurID Token Types... 107 Hardware Tokens... 108 RSA SecurID Software Tokens... 109 Determining Which Types of Tokens to Deploy... 109 Planning How to Deploy Tokens to Users...110 Hardware Tokens...110 Software Tokens...111 Planning User Training on the Use of RSA SecurID Tokens...112 Informing Users About the Planned Rollout...112 Communicating Authentication Instructions to End Users...113 Token Deployment Checklist...114 Chapter 11: Planning Logging and Reporting...115 About Logging and Reporting...115 Planning Log Maintenance...116 Planning Log Archiving...117 Planning Log Consolidation...118 Planning SNMP Trapping...118 Planning Reporting...118 Available Reports...119 Scheduling Reports... 120 Logging and Reporting Checklist... 120 Chapter 12: Completing The Deployment Checklist... 121 Glossary... 127 Index... 143 6 Contents

Preface About This Guide This 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 Documentation For 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. Tutorials The 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

Related Documentation RSA 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 Customer Support Information RSA Secured Partner Solutions Directory https://knowledge.rsasecurity.com www.rsasecurity.com/support www.rsasecured.com 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 Support Make 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. 8 Preface

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 Deployment Make sure you understand the following terms and concepts before you use this document to plan your Authentication Manager installation. A 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. Realm A 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 Domain In 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) Lower-Level Security Domain (Department) Lower-Level Security Domain (Department) Lower-Level Security Domain (Department) 10 1: Essential Terms and Concepts

Instance An 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 1. 2. 3. Data Data Data Instance Instance Instance Server Node A 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 Instance Replica Instance The 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. The 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 1: Essential Terms and Concepts 11

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 1. 2. Data Data Data Data Data Data 3. 4. Data Data Data Data Data Data Key Primary Instance Replica Instance Server Node 12 1: Essential Terms and Concepts

Agent An 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. 1: Essential Terms and Concepts 13

2 Identifying Your Deployment Model Using Scenarios to Plan Your Deployment Deployment Model Checklist Using Scenarios to Plan Your Deployment RSA 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 Authentication Method for External Users Password RSA SecurID RSA SecurID 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 Law The 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. Remote Users (with VPN client ) Miller and Strauss, Attorneys at Law Intranet Internet DMZ Authentication Managers Primary RSA SecurID Authentication Required Firewall SecurID Ready Authentication Agent VPN Server Proxy Server Firewall Data Domain Server Data Windows Password Protected Resources (File servers, DBs) Data Replica Local Users (Windows Password Authentication Only) 2: Identifying Your Deployment Model 17

The following figure shows how Miller and Strauss organized users, groups, tokens, and so on for administration in their Authentication Manager deployment. 18 2: Identifying Your Deployment Model

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. Realm When 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. License Miller and Strauss purchased the Base license, which allows the firm to have one primary instance and one replica instance. Authentication Agents When 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. Instances The 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 Sources Because 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 Domains Miller and Strauss has one security domain, which contains all users, administrative roles, authentication agents, tokens, and reports. Policies Miller 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 Staff Miller and Strauss has two administrators who perform administration for the firm. Both are Super Admins. There is no additional IT support staff. 2: Identifying Your Deployment Model 19

The Medium-Sized Deployment: Greenley Biotechnologies The 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 Assures, with certainty, that users are who they say they are Supports multiple platforms Enables integration of Active Directory as the identity source Provides for failover and disaster recovery Provides records of all authentication activity 20 2: Identifying Your Deployment Model

The following figure shows the Greenley Biotechnologies network, including users who need to access resources locally and remotely. Remote Users Internet Authentication Agent Installed Greenley Biotechnologies Authentication Agent Installed RSA SecurID Authentication Required Firewall Web Agent Installed DMZ Web Server Primary Authentication Managers Server Replica Node Server Node Domain Controller 3 Protected Resources (File servers, DBs) Data (R&D) Data Authentication Agent Installed VPN Server Citrix Presentation Server Proxy Server Data Data Domain Controller 2 Data (HR) SecurID Ready Authentication Agent Firewall Domain Controller 1 (Finance) Web Agent Installed OWA Front End PAM Protected Server OWA Back End CITRIX Server Authentication Agent (Local Authentication Component Installed) RSA SecurID Authentication Required Internal Users (SecurID for Windows Local Authentication) 2: Identifying Your Deployment Model 21

The following figure shows how Greenley Biotechnologies organized users, groups, tokens, and so on for administration in their Authentication Manager deployment. 22 2: Identifying Your Deployment Model

2: Identifying Your Deployment Model 23

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. Realm There 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. License Greenley Biotechnologies purchased an Advanced license, which allows the firm to have a primary instance, and multiple replica instances and server nodes. Authentication Agents To 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. Instances Greenley 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. 24 2: Identifying Your Deployment Model

Identity Sources This 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 Domains Greenley 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. Policies Due 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 Staff In 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 Company The 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. 2: Identifying Your Deployment Model 25

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 Assures, with certainty, that users are who they say they are Supports multiple platforms Provides local and remote administration and authentication Enables integration with multiple identity sources 26 2: Identifying Your Deployment Model

The following figure shows the FocalView Software network, including users who need to access resources locally and remotely. Remote Users FocalView Software Firewall Internet Remote Users Internet DMZ Web Server Web Agent Installed Citrix Presentation Authentication Server Agent Installed Authentication Proxy Agent VPN Server ServerInstalled SecurID Ready Authentication Agent Firewall Authentication Agent Installed Authentication Agent Installed OWA Front End PAM Protected Server RSA SecurID Authentication Required Authentication Managers OWA Back End RSA SecurID Authentication Required Replica Server Node Da ta CITRIX Server New York Domain Controller Internal Users (SecurID for Windows Local Authentication) San Jose Internal Users (SecurID for Windows Local Authentication) LAC Component Installed Domain Controller Server Replica Node Da ta RSA SecurID Authentication Required Authentication Agent Installed Authentication Managers CITRIX Server OWA Back End RSA SecurID Authentication Required Web Agent Installed Citrix Presentation Server Authentication Proxy Agent Installed VPN Server Authentication Server Agent Installed Firewall PAM Protected Server Authentication Agent Installed DMZ Web Server SecurID Ready Authentication Agent OWA Authentication Front Agent End Installed Remote Users Internet Firewall Authentication Agent Installed Authentication Agent Installed RSA SecurID Authentication Required Firewall Web Agent Installed DMZ Web Server Primary Authentication Managers Boston Server Replica Server Node Node Protected Resources (File servers, DBs) Data (R&D) Authentication Agent Installed VPN Server Citrix Presentation Server Proxy Authentication Server Agent Installed Data Data Domain Controller Data (HR) SecurID Ready Authentication Agent Authentication Agent Installed OWA Front End PAM Protected Server Firewall OWA Back End CITRIX Server Authentication Agent (Local Authentication Component Installed) Data (Finance) RSA SecurID Authentication Required Internal Users (SecurID for Windows Local Authentication) 2: Identifying Your Deployment Model 27

The following figure shows how FocalView Software organized users, groups, tokens, and so on for administration in their Authentication Manager deployment. 28 2: Identifying Your Deployment Model

2: Identifying Your Deployment Model 29

30 2: Identifying Your Deployment Model

2: Identifying Your Deployment Model 31

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. Realm This 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 Agents To 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. Instances When 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. 32 2: Identifying Your Deployment Model

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 Sources FocalView 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 Domains The 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. 2: Identifying Your Deployment Model 33

Policies The 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 Staff The 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 34 2: Identifying Your Deployment Model

Deployment Model Checklist Use this checklist to begin documenting your plan. Element Description Your Plan License type Realm Security Domain Authentication Physical location Identity source Agent Know which license you have: Base Advanced Know how many realms you want. 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. Know which types of users you require to authenticate: Internal users External users Know how you want types of users to authenticate: Password RSA SecurID token Know where you want to locate your Primary Instance and each Replica Instance. Know what identity source you plan to use: Internal database Active Directory Active Directory Global Catalog Sun Java System Directory Server Know where you need agents installed and what types to install. 2: Identifying Your Deployment Model 35

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 Model Authentication 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 Works You 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 Updates You 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. Administrative Updates Data Flow Primary Instance Replica Instance Server Node Boston1 Server Node Boston2 Database Server Boston1 Database Server Boston2 Replica Instance Replica Instance Server Node San Jose Server Node New York Database Server San Jose Database Server New York In this hub and spoke model, two replica instances never communicate directly. 38 3: The RSA Authentication Manager Architecture

Runtime Updates Runtime 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. Runtime Updates Data Flow Primary Instance Replica Instance Server Node Boston1 Server Node Boston2 Database Server Boston1 Database Server Boston2 Replica Instance Server Node San Jose Replica Instance Server Node New York Database Server San Jose Database Server New York 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. 3: The RSA Authentication Manager Architecture 39

Replication of Data Replicated Data In 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. All 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 User Agent Token Change That Is Replicated Any change to the user s fixed passcode or PIN. 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. 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. 40 3: The RSA Authentication Manager Architecture

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 Architecture You 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 Data When 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. 3: The RSA Authentication Manager Architecture 41

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 Store If 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 Store You 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 Users In 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. 42 3: The RSA Authentication Manager Architecture

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. 3: The RSA Authentication Manager Architecture 43

Planning Load Balancing Using Contact Lists Authentication 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 Prevention Authentication 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. 44 3: The RSA Authentication Manager Architecture

Evasion of Attack The 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 Passcodes To 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 PINs To 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 Passcodes To 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. 3: The RSA Authentication Manager Architecture 45

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. 46 3: The RSA Authentication Manager Architecture

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 Experience RSA SecurID Tokens Authentication Agents The process of authentication is an interaction of three distinct products: RSA SecurID tokens Authentication agents RSA Authentication Manager An 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 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 Manager As 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. RSA Authentication Manager Model Machines with Authentication Agent Installed User with RSA SecurID token LDAP Directory RSA Authentication Manager Instance Internal Database 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. 48 4: Planning RSA SecurID Protection

Deciding Which Resources to Protect with RSA SecurID Authentication 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 Servers By 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 VPN As 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 Server If 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 TACACS RSA 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 Access Authentication 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. 4: Planning RSA SecurID Protection 49

Protecting Access to Web Pages Authentication 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 Protocols Authentication 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 Server Authentication 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 Desktops Authentication 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. 50 4: Planning RSA SecurID Protection

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. User's Computer with Authentication Agent Installed 1. During logon, the Authentication Agent prompts the user for an RSA SecurID passcode and passes it to the Authentication Manager. RSA Authentication Manager 2. Authentication Manager verifies the passcode and sends the verification status to the Authentication Agent. If the passcode is correct, the user gains access to the Windows desktop. Deploying the Authentication Agent in a Microsoft Windows Environment The 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. Business Needs A simple, consistent, secure way for users to authenticate Different security policies for individual departments An efficient way to manage the policies Efficient deployment of the Authentication Agent An easy way for administrators to access non-administrative users desktops Solution 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. Assign users computers to authentication groups and manage security policies at the group level. Create a preconfigured network installation package that you distribute or make available on the network. Users can install the Authentication Agent silently, without intervention. Exempt administrators from having to enter RSA SecurID passcodes to access users desktops. 4: Planning RSA SecurID Protection 51

The following figure shows a sample local authentication setup for a medium-sized company. Database Server Server Node Database Server Server Node Authentication Managers Data Data No Connection to Authentication Manager RSA SecurID Authentication Required Internal Users (RSA SecurID for Microsoft Windows Local Authentication) Local Authentication Client Component Installed and Offline Authentication Enabled 52 4: Planning RSA SecurID Protection

Planning Which Users to Challenge Which 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 users The 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 Experience When 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 Integration Windows 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. 4: Planning RSA SecurID Protection 53

Offline Authentication You 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. Online Connection User's Computer RSA Authentication Manager Offline Broken Connection When the user is online, Authentication Manager downloads offline data to the user's computer. User's Computer With Offline Data When the user attempts to authenticate offline, the Authentication Agent prompts the user for RSA SecurID logon credentials and verifies them against the locally stored offline data. RSA Authentication Manager Security Policies for Offline Authentication You 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. 54 4: Planning RSA SecurID Protection

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 Agent The following table lists the RSA Authentication Agent components and where to install them. Component RSA Authentication Manager RSA Authentication Agent Local Authentication Client component Location On a secure computer Every computer you want to protect with RSA SecurID The following figure shows the setup for local authentication. User's Computer Component: Local Authentication Client RSA Authentication Manager Planning Local Authentication Deployment Use 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. Deployment Steps 1. Install and set up RSA Authentication Manager 7.0. 2. Create Microsoft Windows challenge groups. 3. Install the Local Authentication Client component on every computer you want to protect. Installation and Administration Guide Reference The chapter Requirements and Preparations Create Groups of Users to Challenge with RSA SecurID in the chapter Requirements and Preparations The chapter Installing RSA Authentication Agent 7.0 for Microsoft Windows 4: Planning RSA SecurID Protection 55

Deployment Steps Installation and Administration Guide Reference 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 Creating a Preconfigured Network Installation Package The 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 Access You 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. 56 4: Planning RSA SecurID Protection

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 Database Preparing Users How 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. How 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 Administrators How 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. 4: Planning RSA SecurID Protection 57

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. 58 4: Planning RSA SecurID Protection

5 Assessing System and Security Requirements System Requirements Planning Management of the Master Password Planning Physical Security System and Security Requirements Checklist System Requirements Make 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 Operating System Hardware Disk Space Memory Requirements Page File Microsoft Windows Server 2003 Enterprise, SP1 (32-bit) Intel Xeon 2.8 GHz or equivalent 60 GB free space recommended 20 GB free space minimum Disk 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. 2 GB 2 GB Linux System Requirements Operating System Red Hat Enterprise Linux 4.0-1 ES (32-bit x86) Hardware Disk Space Memory Requirements Swap Space Kernel Version Kernel Parameters Intel Xeon 2.8 GHz or equivalent 60 GB free space recommended 20 GB free space minimum Disk 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. 2 GB 2 GB 2.6.9-22.EL and later Maximum shared memory must be at least 256 MB 60 5: Assessing System and Security Requirements

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

Maintaining Accurate System Time Settings Authentication 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 Usage Authentication 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. 62 5: Assessing System and Security Requirements

Port Number Protocol Service Description 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 7006 TCP WebLogic administration console/ssl 7008 TCP WebLogic administration console override/ssl 7012 TCP RSA Security Console override/ssl 7014 TCP RSA Security Console proxy server override/ssl Used for load balancing of administration in an instance with multiple server nodes. This port is used for SSL connections. Internal use only. Internal use only. Internal use only. Internal use only. 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 Periods It 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. 5: Assessing System and Security Requirements 63

Planning Management of the Master Password Secure 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 Security Ensure 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. 64 5: Assessing System and Security Requirements

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. 5: Assessing System and Security Requirements 65

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 Consider This 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 Instance Use the Manage Replication utility to detect any failed instances. See the chapter Disaster Recovery, in the Administrator s Guide. Why an Instance Might Fail You 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 failure In 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 Fails When 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 Recovery Process Steps 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. Before 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 Recovered At 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. 6: Planning for Failover and Disaster Recovery 69

Step 2: Promote a Replica Instance If 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 Instances Because 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 Instance Establish 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 Fails When 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. 70 6: Planning for Failover and Disaster Recovery

Planning Recovery If a Replica Instance Fails If 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 Node When 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 Backups The 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 Backups Replica 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. 6: Planning for Failover and Disaster Recovery 71

Formulating a Backup Policy Decide 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 Backups You 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. 72 6: Planning for Failover and Disaster Recovery

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 Installation The 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 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 Component Administrator Administrator Who Needs Access 7: Planning Your Installation 73

Component 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 Administrator Administrator Who Needs Access Planning Your RSA Authentication Manager Installation Develop 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 74 7: Planning Your Installation

Minimum Requirements for Machines License Permissions There 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. Your 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 Security Plan 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 Installation Primary 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 Installation Develop 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 7: Planning Your Installation 75

Access Through Firewalls Plan 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 Servers If 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. 76 7: Planning Your Installation

Planning Primary Instance Installation Select 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 Instance The 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 Installation Plan 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 Instance The 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. 7: Planning Your Installation 77

Planning Server Nodes Installation To 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 Node The 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 Integration Develop 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. 78 7: Planning Your Installation

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 Sources Authentication Manager supports Windows Server 2003 Active Directory and Sun Java System Directory Server 5.2. Selecting Read-Only or Read/Write Authentication 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. 7: Planning Your Installation 79

Establishing Security RSA 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 Integration Mapping Attributes RSA 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 Your 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. 80 7: Planning Your Installation

For mapping users: Authentication Manager Attribute Maps to Your LDAP Directory Attribute First Name Middle Name Last Name User ID E-mail Certificate DN Password For mapping user groups: 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 Planning Active Directory Integration You 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. 7: Planning Your Installation 81

Global Catalogs 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 administration If 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 isolation If 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. When 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. 82 7: Planning Your Installation

Planning Sun Java System Directory Server Integration When 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 Test You 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 7: Planning Your Installation 83

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. 84 7: Planning Your Installation

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 Model Administrators 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 Scope In 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 Roles When 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. Permissions The 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. Scope The 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. 8: Planning for Administration 87

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. 88 8: Planning for Administration

Use the following checklist to help you make decisions about administrative roles and scope. Questions to ask about roles, permissions, and scope Predefined Admininstrative Roles 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? Authentication 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 Admin This 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. 8: Planning for Administration 89

Realm Administrator This 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 Administrator This 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 90 8: Planning for Administration

User Administrator This 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: Users User groups Reports Tokens Add, delete, edit, view View user group, assign user group membership Add, delete, edit, view, run, schedule 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 Token Administrator This 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. The default permissions for this role limit management to the following: Users Reports Tokens View Add, delete, edit, view report definition, run, schedule 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 8: Planning for Administration 91

Privileged Help Desk Administrator This 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. The default permissions for this role limit management to the following: Users User groups Reports Tokens User accounts Agents View, reset passwords, enable and disable accounts, terminate active sessions View user groups Run, schedule View token, reset SecurID PINs, resynchronize tokens, manage online and offline emergency access tokencodes Manage fixed passcode, manage logon aliases, edit default shell, manage incorrect passcode count, clear cached Windows credential, manage offline emergency access passcode View Help Desk Administrator This 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. The default permissions for this role limit management to the following: Users User groups Tokens User accounts Agents View, reset passwords, enable and disable accounts, terminate active sessions View user groups View token, reset SecurID PINs, resynchronize tokens, enable and disable SecurID tokens Manage logon aliases, edit default shell, manage incorrect passcode count, clear cached Windows credential View 92 8: Planning for Administration

Agent Administrator This 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. The default permissions for this role limit management to the following: Users User groups Reports Agents View View user groups, assign user group membership Add, delete, edit, view report definition, run, schedule Add, delete, edit, view, manage node secret, grant user groups access to agents 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. 8: Planning for Administration 93

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 94 8: Planning for Administration

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 Checklist Use 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. 8: Planning for Administration 95

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 Policy A 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 Methods Authentication 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 Policy One 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 Restrictions Authentication Manager allows you to configure the following PIN requirements and restrictions. Requiring Use of System-Generated PINs Enabling 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 Changes Enabling 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 PINs Setting 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 Lengths Setting 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 Dictionary The 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 Requirements Requiring 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. 9: Planning PIN, Token, and Password Policies 99

Planning Multiple PIN Policies Through the Use of Security Domains You 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 Authentications As 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. 100 9: Planning PIN, Token, and Password Policies

Planning Password Requirements and Restrictions In 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 Requirements You 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. 9: Planning PIN, Token, and Password Policies 101

Planning Emergency Access Determine 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. 102 9: Planning PIN, Token, and Password Policies

For Offline Users 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. 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 See the chapter Preparing RSA Authentication Manager for Administration in the Administrator s Guide. 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 See the chapter Preparing RSA Authentication Manager for Administration in the Administrator s Guide. 9: Planning PIN, Token, and Password Policies 103

For Administrators Method Description Characteristics More Information Reserve password 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. 104 9: Planning PIN, Token, and Password Policies

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. 9: Planning PIN, Token, and Password Policies 105

10 Planning 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 Types RSA 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 Tokens RSA 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 Tokens The 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 Token RSA 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 Deploy When 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. 10: Planning RSA SecurID Token Deployment 109

Planning How to Deploy Tokens to Users Hardware Tokens The types of token you use, ease of administration, and security are factors in determining the method of token distribution that you use. The 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. 110 10: Planning RSA SecurID Token Deployment

Software Tokens An 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 Protection The 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 Device When 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 Tokens You 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 Files Authentication 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. 10: Planning RSA SecurID Token Deployment 111

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 Tokens Deploying 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 Rollout Give 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 112 10: Planning RSA SecurID Token Deployment

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 Users RSA 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. 10: Planning RSA SecurID Token Deployment 113

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. 114 10: Planning RSA SecurID Token Deployment

11 Planning Logging and Reporting About Logging and Reporting Planning Log Maintenance Planning SNMP Trapping Planning Reporting Logging and Reporting Checklist About Logging and Reporting Audit 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 reports There 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 logging The 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 Monitor This 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 Maintenance Consider 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. Log Audit information System information Runtime information Trace information Description 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. 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. Includes any runtime activity, such as authentication and authorization of users. 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. 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 116 11: Planning Logging and Reporting

Planning Log Archiving 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. 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. 11: Planning Logging and Reporting 117

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 Consolidation The 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 Trapping If 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 Reporting The 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. 118 11: Planning Logging and Reporting

Available Reports You 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 Administrators by Security Domain Disabled Users Activity Report of an Administrator Runtime Activity Report Administrators with a Specified Role Expired Users Accounts Diagnostic Report on Orphaned Users and Groups User Group Life Cycle Activity Report Non-User or Group Object Life Cycle Activity Report System Log Report Users with Days Since Last Log On, Using Specific Token Users with Tokens with Wildcard Report Description 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. Lists all registered users who have a disabled account in a specific security domain. Lists all administrator activities. Lists all runtime activities initiated by users. Lists all administrators assigned a specific role. Lists all registered users with expired accounts in a specific security domain. 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. 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. Lists all activities for a specific domain object other than a user or group. Lists all log entries from the system log. Shows the number of days since the user s last logon and the date of last logon for a specific token type. 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. 11: Planning Logging and Reporting 119

Scheduling Reports You 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. 120 11: Planning Logging and Reporting

12 Completing The Deployment Checklist Use the following checklist to specify installation and configuration information for your deployment. Distribute this list to the appropriate personnel. Deployment Checklist Pre-Installation Element Description Your Plan License type Platform Base Advanced Windows Linux Master password 12: Completing The Deployment Checklist 121

Installation Element Description Your Plan 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 Element Description Your Plan Identity source(s) LDAP Number and type For example: RSA Authentication Manager internal database Active Directory Active Directory forests Sun Java System Directory Server 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 12: Completing The Deployment Checklist 123

Administrative Configuration Element Description Your Plan Realm Number Names Security domains Top-level name Lower-level names Token(s) Number and type For 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 124 12: Completing The Deployment Checklist

Element Description Your Plan Method of PIN creation For 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 recovered For 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 12: Completing The Deployment Checklist 125

Post-Installation Element Description Your Plan Resources to protect Agents For example: File servers Databases Identity sources Number Physical location of agents Name and IP address of agents 126 12: Completing The Deployment Checklist

Glossary Term Active Directory Active Directory forest AD adjudicator administrative command administrative role administrator Advanced Encryption Standard (AES) Advanced license AES agent Agent Auto-Registration Service agent host Definition The directory service that is included with Microsoft Windows Server 2003 and Microsoft Windows 2000 Server. A federation of identity servers for Windows Server environments. All identity servers share a common schema, configuration, and Global Catalog. See Active Directory. 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. A command other than a system-generated command. A collection of permissions and the scope within which those permissions apply. Any user with one or more administrative roles that grants administrative permission to manage administrative resources. 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. Authentication Manager license that allows a primary instance, multiple replica instances, and multiple server nodes. See Advanced Encryption Standard. 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. 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. The machine on which an agent is installed. Glossary 127

Term Agent Protocol Server attribute attribute mapping audit information audit log authentication authentication authority authentication broker authentication method authentication policy authentication protocol Authentication Server Definition 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. 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. 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. 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. 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. The process of reliably determining the identity of a user or process. The central entry point for authentication services. A component that handles the authentication process and issuance of authentication tickets. The type of procedure required for obtaining authentication, such as a one-step procedure, a multiple-option procedure, or a chained procedure. A collection of rules that specify the authentication requirements. An authentication policy may be associated with one or more resources. The convention used to transfer credentials of a user during authentication. For example, HTTP-BASIC/DIGEST, NTLM, Kerberos, and SPNEGO. An Authentication Manager component made up of services that handle authentication requests, database operations, and connections to the RSA Security Console. 128 Glossary

Term authenticator authorization authorization data auto-registration Base license cache certificate chained authentication CIDR Classless Inter-Domain Routing (CIDR) client time-out CLU cluster Definition 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). The process of determining if a user is allowed to perform an operation on a resource. 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. 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. Authentication Manager license that allows one primary instance and one replica instance. Also see Advanced license. 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. An asymmetric key that corresponds with a private key. Either self-signed or signed with the private key of another certificate. 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. See Classless Inter-Domain Routing. 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. The amount of time (in seconds) that the user s desktop can be inactive before reauthentication is required. See command line utility. An instance consisting of a database server and one or more server nodes. Glossary 129

Term command line utility (CLU) connection pool contact list context-based authentication core attributes cryptographic algorithm CT-KIP CT-KIP client CT-KIP enabled token CT-KIP protocol messages CT-KIP protocol transport binding CT-KIP server Definition A utility that provides a command line user interface. A group of identical database connections between Authentication Manager and the data store. A list of server nodes provided by the Authentication Manager to the agent, where the agent can direct authentication requests. 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. 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. 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. Cryptographic Token-Key Initialization Protocol. A program that implements the CT-KIP client-side protocol and interacts with a CT-KIP server for the secure initialization of tokens. 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. The Protocol Data Units (PDU) exchanged between client and server in order to generate a seed on both server and client. Specifies a binding of the CT-KIP message interaction such as requests and responses to a transport protocol such as HTTP. 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. 130 Glossary

Term CT-KIP toolkit customer name data encryption standard operation (DES) data store Data Transfer Object (DTO) database server delegated administration denial of service deployment DES DTO dump EAP emergency access emergency access passcode Definition An implementation of the CT-KIP client-server protocol. It provides the API for creating CT-KIP server or client applications. The name of the enterprise to which the license is issued. The cryptographic standard prior to November 2001, when the National Institute of Standards and Technology (NIST) adopted the Advanced Encryption Standard (AES). 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. Simple object used to pass data between tiers. It does not contain business logic. The server where the database is installed. 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. 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. The arrangement of Authentication Manager elements into appropriate locations in a network to perform authentication. See data encryption standard operations. See data transfer object. 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. See extensible authentication protocol. 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. A complete authentication code that, if enabled, can be used by a user to perform an offline authentication without an authenticator or PIN. Glossary 131

Term emergency access tokencode Evaluation license extensible authentication protocol (EAP) external attributes failover mode floating license four-pass CT-KIP Global Catalog graded authentication high-water-mark identity attribute definitions Definition 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. Authorizes an evaluation copy of the product at a customer site. An authentication protocol that supports multiple authentication methods, including one-time passcodes used for RSA SecurID authentication. 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. 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. An enterprise license that is not attached to any particular product and instance combination. It can apply to any machine running the product. The exchange of two protocol data units (PDUs) between the client and server. A read-only, replicated repository of a subset of the attributes of all entries in a forest. 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. The highest numbered interval used by a user to authenticate. 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. 132 Glossary

Term Identity Management Services identity source IMS initial time-out instance instance ID instance name interval internal database J2EE Java Cryptographic Architecture (JCA) Java Cryptographic Extensions (JCE) Definition The set of shared components, toolkits, and services used to build RSA Security products, for example, Authentication Manager. 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. See Identity Management Services. The wait time, in seconds, before the initial remote access prompt appears. (The term is used in relation to remote RSA SecurID authentication.) A single database server, or a database server and one or more server nodes, acting as a single cohesive processing unit. 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. 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. A value used to represent a specific time-based PRN code being generated by an authenticator. The Authentication Manager proprietary data source. Java 2 Enterprise Edition. A framework for building enterprise applications using Java technology. The set of APIs provided by the Java 2 platform that establishes the architecture and encapsulates limited cryptographic functionality from various cryptographic providers. The set of APIs provided by the Java 2 platform that encapsulates additional cryptographic functionality from various cryptographic providers. Glossary 133

Term Java Management Extensions (JMX) Java Messaging Service (JMS) Java Server Pages (JSP) JCA JCE JKS JMS JMX JSP keystore Key Management Key Management encryption key LAC license license category license creation date license deployment license file Definition 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. A standard Java interface for interacting with message queues and topics. A commonly used technology for dynamic web content. See Java Cryptographic Architecture. See Java Cryptographic Extensions. The Java 2 platform implementation of a keystore provided by Sun Microsystems. See Java Messaging Service. See Java Management Extensions. See Java Server Pages. The Java 2 platform facility for storing keys and certificates. The management of the generation, use, storage, security, exchange, and replacement of cryptographic keys. The key used for encryption or decryption operations of keys managed by Key Management Services. See Local Authentication Client. 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. A way of grouping different types of licenses. Base license, Advanced license, and Evaluation license are the three license categories. The date when the license file was created. Specifies either a server or floating license. 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. 134 Glossary

Term license file version license ID License Management Service (LMS) license.rec LMS Local Authentication Client (LAC) locked license lockout policy log archival logging service lower-level security domain Management Information Base (MIB) MD5 member user Definition The version of the license schema to which the generated license conforms. An internal identifier associated with the license. RSA Manufacturing assigns the license ID. A service responsible for managing and validating software licenses. A license record file containing the database key needed to extract critical information from the DMP file. See License Management Service. An RSA Authentication Agent component that requires users to enter valid RSA SecurID passcodes to access their Microsoft Windows desktops. A license limited to a specific server instance. See server license. 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. Creates a backup copy of the log for noncurrent, permanent storage. A component responsible for recording system, audit, and trace events. In a security domain hierarchy, a security domain that is nested within another security domain. 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. An algorithm that produces a 128-bit message digest. A user who is a member of a member user group. Glossary 135

Term member user group MIB Microsoft Management Console (MMC) MMC namespace Network Management System (NMS) NEXUS NMS NMS administrator node secret object offset PAM passcode Definition 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. See Management Information Base. A user interface through which system administrators can configure and monitor the system. See Microsoft Management Console. A set of names. A namespace defines a scope for a collection of names. 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. The external marketing name for the RSA Security Identity and Access Management vision and strategy. NEXUS is not a product. See Network Management System. The person monitoring the network (through the NMS) for significant events. Also known as a network administrator. 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. Describes the following: security domains, identity sources, attributes, users, user groups, administrative roles, and policies. A value used to represent the amount of time an authenticator s internal clock has drifted over time. See Pluggable Authentication Modules. A code entered by a user to authenticate. The passcode is a combination of a PIN and a tokencode. 136 Glossary

Term password-based encryption password policy PDU permissions Pluggable Authentication Modules (PAM) primary connection pool primary instance private key PRN Protocol Data Unit provisioning data pseudorandom number (PRN) public key RADIUS Definition The process of obscuring information so that it is unreadable without knowledge of the password. 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. See Protocol Data Unit. Specifies which tasks an administrator is allowed to perform. Mechanisms that allow the integration of new authentication methods into an API, independent of the existing API authentication scheme. Refers to the connection pools containing the connections to the primary instance database server. The instance of the Authentication Manager software installation at which authentication and all administrative actions occur. 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). See pseudorandom number. A packet of data exchanged between two application programs across a network. 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. A random number or sequence of numbers derived from a single seed value. In asymmetric key cryptography, the cryptographic key that corresponds with the private key. The public key is usually encapsulated within a certificate. See Remote Authentication Dial-In User Service. Glossary 137

Term realm regular time-out Remote Authentication Dial-In User Service (RADIUS) remote EAP (extensible authentication protocol) remote post-dial replica instance RSA Security Console Definition 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. The number of seconds before remote access prompts time out. The term is used in relation to remote RSA SecurID authentication. A UDP-based protocol for administering and securing remote access to a network. 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. 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. 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. 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. 138 Glossary

Term Definition 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 runtime command runtime identity source scope secondary connection pool Secure Sockets Layer (SSL) security domain server license server node session Describes automated processing behavior behavior that occurs without direct administrator interaction. A logon or logoff command. 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. In a realm, the security domain or domains within which a role s permissions apply. Refers to the connection pools containing the connections to the secondary data stores. A protocol that uses cryptography to enable secure communication over the Internet. SSL is widely supported by leading web browsers and web servers. 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. 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. 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. 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. Glossary 139

Term session policy SHA1 Simple Network Management Protocol (SNMP) single sign-on (SSO) snap-in SNMP SNMP Agent SNMP trap SSL SSO Super Admin symmetric key system event system log Definition A set of specifications designating the restrictions on overall session lifetime and multiple session handling. Session policies are applied to an instance. A secure hash algorithm function that produces a 160-bit hash result. 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. The process of requiring only a single user authentication event in order to access multiple applications and resources. 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). See Simple Network Management Protocol. Software module that performs the network management functions requested by network management stations. 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. See Secure Sockets Layer. See single sign-on. 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 A key that allows the same key value for the encryption and decryption of data. System-generated information related to nonfunctional system events such as server startup and shutdown, failover events, replication events, and so on. Persistable store for recording system events. 140 Glossary

Term TACACS+ Terminal Access Controller Access Control System+ (TACACS+) token tokencode top-level security domain trace log two-factor authentication two-pass CT-KIP UDP user User Datagram Protocol (UDP) user group User ID Definition See Terminal Access Controller Access Control System+. 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. A hardware device or software program that generates a pseudorandom number that is used in authentication procedures to verify a user s identity. 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. 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. Persistable store for trace information. An authentication protocol requiring two different ways of establishing and proving identity. The exchange of one protocol data unit (PDU) between the client and server. See User Datagram Protocol. An account managed by the system that is usually a person, but may be a computer or a web service. A protocol that allows programs on networked computers to communicate with one another by sending short messages called datagrams. A collection of users, other user groups, or both. 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. Glossary 141

Index A Active Directory definition, 127 forest, definition, 127 Global Catalog, 82 integration of forests, 82 integration process, 81 Microsoft Management Console, 93 runtime identity source, 82 supported version, 79 Active Directory forest definition, 127 Activity Monitor, 115 adjudicator definition, 127 administration Authentication Manager model, 85 LDAP privileges, 42 Microsoft Management Console, 93 planning roles, permissions, and scope, 85 RSA Security Console, 93 SNMP trapping, 118 where to perform, 11 administrative command definition, 127 administrative role assigning, 86 custom, 85 definition, 127 predefined, 85, 89 administrator about, 85 assigning roles, 86 definition, 127 permissions, 86 predefined roles, 89 scope, 87 training topics, 94 95 Advanced license definition, 127 agent definition, 127 definition and concept, 13 Agent Auto-Registration Service definition, 127 agent host definition, 127 Agent Protocol Server definition, 128 agent record, 43 archive. See logging archiving disk space, 117 frequency, 117 purge logs, 117 attribute definition, 128 mapping, 80 attribute mapping definition, 128 audit information definition, 128 audit log definition, 128 authentication data required by Authentication Manager, 43 definition, 128 emergency access, 56 end-user experience, 47 example, 48 offline, 54 process, 9, 43 when not connected to the network, 54 authentication agent deploying, 51 embedded, 19, 24, 32, 43 protecting Windows desktops, 50 role of, 47 RSA Security partners, 19, 24, 32, 43 software, 43 third-party, 19, 24, 32, 43 authentication authority definition, 128 authentication policy definition, 128 Authentication Server definition, 128 authenticator definition, 129 authorization definition, 129 authorization data definition, 129 automatic contact lists, 44 Index 143

auto-registration definition, 129 B Base license definition, 129 browser security, 61 support, 61 C cache definition, 129 certificate definition, 129 certificate of authority, 80 chained authentication definition, 129 character requirements PINs, 99 checklist administration, 95 architecture, 46 deployment, 121 deployment model, 35 disaster recovery, 72 installation, 84 logging and reporting, 120 policies, 105 RSA SecurID protection, 58 system and security requirements, 65 token deployment, 114 CITRIX protecting access to servers, 50 CLU. See Command Line Utility cluster definition, 129 server node, 11 command line utility definition, 130 Initialize Identity Source, 25, 33 Migration, 76 communication agent to server, 13 concepts. See definitions and concepts connection pool definition, 130 contact list definition, 130 contact lists, 44 automatic, 44 manual, 44 context-based authentication definition, 130 Coordinated Universal Time, 62 core attributes definition, 130 Cryptographic Token-Key Initialization Protocol, 112 client, 130 enabled token, 130 failover, 69, 112 server, 130 toolkit, 131 CT-KIP. See Cryptographic Token-Key Initialization Protocol D damaged tokens, 102 data replication, 40 data store definition, 131 Data Transfer Object definition, 131 database server, 38 definition, 131 default policy for lockout, 100 definitions and concepts, 9 13 delegated administration definition, 131 deployment definition, 131 definition and concept, 9 deployment model checklist, 35 disk space, 60 DTO. See Data Transfer Object dump file definition, 131 E emergency access, 56, 102 definition, 131 example, 102 emergency access passcode definition, 131 emergency access tokencode, 102 definition, 132 expiration date, 102 evasion-of-attack, 45 144 Index

excluded words passwords, 101 PINs, 99 existing Authentication Manager migrating data, 76 expiration of emergency access tokencode, 102 extension fields and LDAP, 42 F failover mode definition, 132 Firefox, 61 FTP protecting, 50 G Global Catalog Active Directory, 82 definition, 132 integration, 82 runtime identity source, 82 graded authentication definition, 132 H hardware requirements, 60 I identity attribute definitions definition, 132 Identity Management Services definition, 133 identity source Active Directory integration, 81 choosing, 41 definition, 41, 133 establishing security, 80 integration, 78 mapping attributes, 80 performing integration, 80 Sun Java System Directory Server integration, 83 types, 41, 79 using LDAP, 42 IMS. See Identity Management Services Initialize Identity Source utility, 25, 33 installation coordinating, 73 firewall access, 76 Microsoft Management Console, 94 permissions, 73 personnel, 75 primary instance, 77 replica instance, 77 security, 75 server node, 78 timetable, 75 instance definition, 133 definition and concept, 11 integration Active Directory, 81 Active Directory forests, 82 certificate of authority, 80 DNS namespaces, 82 Global Catalog, 82 IIS, 80 LDAP directory, 78 mapping attributes, 80 process, 80 read/write, 79 read-only, 79 Secure Sockets Layer, 80 Sun Java System Directory Server, 83 supported LDAP directories, 79 internal database definition, 133 Internet Explorer, 61 J JavaScript, 61 K kernel parameter requirements, 60 Key Management encryption key definition, 134 keystore definition, 134 L LAC. See Local Authentication Client large scenario logical deployment, 28 physical deployment, 25 Index 145

LDAP and replication, 41 ensuring sufficient administrative privileges, 42 integration, 78 mapping attributes, 42 storing data in, 42 using as an identity source, 41 using LDAP data, 42 LDAP directory read/write, 79 read-only, 79 supported types, 79 license Advanced, 75, 127 Base, 75, 129 license ID determining, 8 Linux requirements, 60 load balancing contact lists, 44 local authentication in a Windows environment, 51 Local Authentication Client definition, 135 locking user accounts, 100 lockout policy, 100 definition, 135 log archival definition, 135 logging archive, 117 consolidation, 118 create log files, 117 file types, 116 files not included, 118 log files location, 118 maintenance, 116 Network Management System, 118 planning, 115 types, 115 logging service definition, 135 logical deployment large, 28 medium, 22 small, 18 lost tokens, 102 lower-level security domain definition, 135 M manual contact lists, 44 mapping LDAP data, 42 master password export for backup, 64 recovery, 64 securing, 64 medium scenario logical deployment, 22 physical deployment, 20 member user definition, 135 member user group definition, 136 memory requirements, 60 Microsoft Management Console Active Directory, 94 administration, 93 definition, 136 installation, 94 migrating users and tokens, 76 Migration utility, 76 MMC. See Microsoft Management Console N namespace definition, 136 Network Management System, 136 logging, 118 node secret definition, 136 node. See server node O object definition, 136 offline authentication, 54 planning security policies, 54 OpenSSH support for, 50 Outlook Web Access protecting access through, 49 P PAM. See Pluggable Authentication Module passcode definition, 136 stolen, 45 146 Index

password policies, 101 requirements, 101 password policy definition, 137 permissions assigning, 86 definition, 137 physical deployment large scenario, 25 medium scenario, 20 small scenario, 17 pilot test considerations, 83 PINs character requirements, 99 characteristics of, 97 methods of creation, 97 stolen, 45 Pluggable Authentication Module, 50 protecting other protocols, 50 policies lockout, 100 password, 101 port usage description, 62 port number, 62 protocol, 62 service, 62 primary connection pool definition, 137 primary instance definition, 137 definition and concept, 11 functionality, 37 installation, 77 number allowed, 11 private key definition, 137 protecting Windows desktops, 50 provisioning data definition, 137 public key definition, 137 purge logs. See archiving R RADIUS. See Remote Authentication Dial- In User Service realm definition, 138 definition and concept, 9 Red Hat Package Manager versions required, 61 Remote Authentication Dial-In User Service definition, 138 protecting access through, 49 replica instance definition, 138 definition and concept, 11 functionality, 37 installation, 77 number allowed, 77 requirements, 77 role in backing up data, 37 replicated data, 40 replication, 38, 40 and LDAP, 41 reports permissions, 118 planning, 115 run-as, 118 scheduling, 119 types available, 119 requirements machines, 75 primary instance, 77 replica instance, 77 server node, 78 roles. See administrative role RPM. See Red Hat Package Manager RSA SecurID token definition, 47 RSA SecurID tokens. See tokens RSA Security Console definition, 138 integration, 80 supported browsers, 61 RSA Security partners, 19, 24, 32, 43 runtime definition, 139 runtime changes, 39 runtime identity source as a normal domain, 82 definition, 139 Global Catalog, 82 Index 147

S scenarios large, 25 medium, 20 small, 17 summary table, 16 scope assigning, 87 definition, 139 definition and concept, 87 sdopts.rec file, 44 Secure Sockets Layer definition, 139 establishing, 80 integration, 80 Sun Java System Directory Server, 83 security of connections, 64 of equipment, 64 Security Console definition, 138 integration, 80 supported browsers, 61 security domain definition, 139 definition and concept, 10 server node, 38 cluster, 11 definition, 139 definition and concept, 11 installation, 78 requirements, 78 session definition, 139 Simple Network Management Protocol Agent, 140 definition, 140 trap, 140 Trapping, Network Management Server, 118 single sign-on definition, 140 small scenario logical deployment, 18 physical deployment, 17 snap-in definition, 140 SNMP. See Simple Network Management Protocol SSL. See Secure Sockets Layer SSO. See single sign on stolen passcodes, 45 stolen PINs, 45 storing data determining best location, 41 in LDAP, 42 user data, 41 Sun Java System Directory Server integration process, 83 Secure Sockets Layer, 83 supported version, 79 Super Admin definition, 140 supported browsers RSA Security Console, 61 swap space requirements, 60 system required packages, 61 system clock setting, 62 system events log types, 116 system requirements Linux, 60 Microsoft Windows, 60 system-generated PINs, 97 T TACACS. See Terminal Access Controller Access Control System telnet protecting access through, 50 Terminal Access Controller Access Control System protecting access through, 49 third-party authentication agent, 43 time synchronization, 62 token record, 43 tokencode definition, 141 tokens, 107 Cryptographic Token-Code Initialization Protocol, 112 definition, 141 emergency access, 102 lost or damaged, 102 remote token key generation, 112 software, 111 training users, 112 top-level security domain definition, 141 148 Index

trace log definition, 141 training topics, 94 two-factor authentication, 43 definition, 141 U user definition, 141 user group definition, 141 User ID definition, 141 user record, 43 user-generated PINs, 97 UTC. See Coordinated Universal Time V version number, determining, 8 Virtual Private Network protecting VPN. See Virtual Private Network W web pages protecting access to, 50 Windows Event Log, 118 Windows password integration, 53 Windows requirements, 60 Index 149