RSA Authentication Manager 7.0 Planning Guide

Transcription

1 RSA Authentication Manager 7.0 Planning Guide

2 Contact Information See the RSA corporate web site for regional Customer Support telephone and fax numbers. RSA Security Inc. 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 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, RSA Security Inc. All rights reserved. First printing: January 2007

3 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 Instance...11 Server Node...11 Primary Instance...11 Replica Instance...11 Agent Chapter 2: Identifying Your Deployment Model Using Scenarios to Plan Your Deployment The Small Deployment: Miller and Strauss, Attorneys at Law The Medium-Sized Deployment: Greenley Biotechnologies The Large Deployment: FocalView Software Company Deployment Model Checklist Chapter 3: The RSA Authentication Manager Architecture About the RSA Authentication Manager Model How Database Replication Works Replication of Data RSA Authentication Manager Database Architecture Deciding Where to Store Data Planning to Use the Internal Database As Your Data Store Planning to Use an LDAP Directory As Your Data Store Authentication of Users Planning Load Balancing Using Contact Lists Attack Prevention RSA Authentication Manager Architecture Checklist Contents 3

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

5 Chapter 7: Planning Your Installation Assessing Required Permissions for Installation Planning Your RSA Authentication Manager Installation 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 Planning Primary Instance Installation Planning Replica Instance Installation Planning Server Nodes Installation Planning LDAP Directory Integration Supported External Identity Sources Selecting Read-Only or Read/Write Establishing Security Performing the Integration Mapping Attributes Planning Active Directory Integration Global Catalogs Planning Sun Java System Directory Server Integration Conducting a Pilot Test Installation Checklist Chapter 8: Planning for Administration About the RSA Authentication Manager Administrative Model Planning Administrative Roles, Permissions, and Scope Predefined Admininstrative Roles Planning Administration Through the Microsoft Management Console (MMC) Planning RSA Authentication Manager Training for Help Desk Administrators Administration Checklist Chapter 9: Planning PIN, Token, and Password Policies Planning PIN Policy Determining PIN Creation Methods Balancing Security and Ease of Use in Determining PIN Policy Planning PIN Requirements and Restrictions Planning Multiple PIN Policies Through the Use of Security Domains Determining When to Lock Out Users After Failed Authentications Planning Password Requirements and Restrictions Planning Emergency Access Policies Checklist Contents 5

6 Chapter 10: Planning RSA SecurID Token Deployment Overview of RSA SecurID Token Types Hardware Tokens RSA SecurID Software Tokens Determining Which Types of Tokens to Deploy Planning How to Deploy Tokens to Users Hardware Tokens Software Tokens Planning User Training on the Use of RSA SecurID Tokens Informing Users About the Planned Rollout Communicating Authentication Instructions to End Users Token Deployment Checklist Chapter 11: Planning Logging and Reporting About Logging and Reporting Planning Log Maintenance Planning Log Archiving Planning Log Consolidation Planning SNMP Trapping Planning Reporting Available Reports Scheduling Reports Logging and Reporting Checklist Chapter 12: Completing The Deployment Checklist Glossary Index Contents

7 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 Preface 7

8 Related Documentation RSA Authentication Agent Special Edition for Microsoft Windows documentation set. This documentation set is included with the Authentication Agent software. RSA Authentication Agent 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 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

9 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

10 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

11 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 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

12 3. A multiple server node primary instance with a multiple server node replica instance 4. A multiple server node primary instance with multiple replica instances with multiple server nodes Data Data Data Data Data Data Data Data Data Data Data Data Key Primary Instance Replica Instance Server Node 12 1: Essential Terms and Concepts

13 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

14

15 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

16 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) Lower-Level Security Domains None Multiple in one physical location Multiple in multiple physical locations Geographic Locations 1 1 Multiple Number of Administrators Number of IT Support Staff 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

17 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

18 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

19 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 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

20 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

21 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

22 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

23 2: Identifying Your Deployment Model 23

24 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 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 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

25 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

26 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

27 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

28 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

29 2: Identifying Your Deployment Model 29

30 30 2: Identifying Your Deployment Model

31 2: Identifying Your Deployment Model 31

32 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 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 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

33 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

34 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

35 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

36

37 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

38 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

39 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

40 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

41 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

42 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

43 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 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

44 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 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

45 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

46 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

47 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

48 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

49 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 Note: If you are protecting desktop access to the machine by installing RSA Authentication Agent 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 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 4: Planning RSA SecurID Protection 49

50 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 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 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 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 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

51 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

52 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

53 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 Special Edition for Microsoft Windows Installation and Administration Guide. 4: Planning RSA SecurID Protection 53

54 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 Special Edition for Microsoft Windows Installation and Administration Guide. 54 4: Planning RSA SecurID Protection

55 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 Special Edition for Microsoft Windows Installation and Administration Guide. Deployment Steps 1. Install and set up RSA Authentication Manager 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

56 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 Special Edition for Microsoft Windows in the RSA Authentication Agent 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 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

57 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 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

58 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 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

59 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

60 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 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 EL and later Maximum shared memory must be at least 256 MB 60 5: Assessing System and Security Requirements

61 Packages (RPM) The following packages (or later versions) must be installed: binutils compat-db compat-libstdc coreutils or later control-center gcc gcc-c gnome-libs glibc-common glibc initscripts or later libstc libaio make libstc++-devel pdksh setarch sysstat xscreensaver 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 and later On Linux Firefox 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

62 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 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 UDP SNMP Agent Used to communicate with a Network Management Server using the Simple Network Management Protocol TCP Oracle DB Used to replicate data between instances UDP Agent authentication Used for communication with authentication agents. This service receives authentication requests from agents and sends replies 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

63 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 TCP RSA Security Console/SSL Used for SSL-encrypted administration connections 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

64 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 : Assessing System and Security Requirements

65 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

66

67 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

68 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

69 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

70 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

71 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

72 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

73 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

74 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

75 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

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

77 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

78 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

79 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

80 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

81 For mapping users: Authentication Manager Attribute Maps to Your LDAP Directory Attribute First Name Middle Name Last Name User ID 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

82 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

83 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

84 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

85 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

86 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

87 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

88 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

89 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

90 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

91 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

92 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

93 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

94 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

95 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

96

97 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

98 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

99 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

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

101 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

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

103 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

104 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 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 Special Edition for Microsoft Windows Installation and Administration Guide : Planning PIN, Token, and Password Policies

105 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

106

107 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

108 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 : Planning RSA SecurID Token Deployment