© 2007 RSA Security Inc. All rights reserved. First printing: January 2007
Trademarks
RSA and the RSA logo are registered trademarks of RSA Security Inc. in the United States and/or other countries. For the most up-to-date listing of RSA trademarks, see www.rsasecurity.com/legal/trademarks_list.pdf. EMC is a registered trademark of EMC Corporation. All other goods and/or services mentioned are trademarks of their respective companies. License agreement
This software and the associated documentation are proprietary and confidential to RSA, are furnished under license, and may be used and copied only in accordance with the terms of such license and with the inclusion of the copyright notice below. This software and the documentation, and any copies thereof, may not be provided or otherwise made available to any other person.
No title to or ownership of the software or documentation or any intellectual property rights thereto is hereby transferred. Any unauthorized use or reproduction of this software and the documentation may be subject to civil and/or criminal liability. This software is subject to change without notice and should not be construed as a commitment by RSA.
Third-party licenses
This product may include software developed by parties other than RSA. The text of the license agreements applicable to third-party software in this product may be viewed in the thirdpartylicenses.pdf file.
Note on encryption technologies
This product may contain encryption technology. Many countries prohibit or restrict the use, import, or export of encryption technologies, and current use, import, and export regulations should be followed when using, importing or exporting this product.
Distribution
Limit distribution of this document to trusted personnel. RSA notice
The RC5™ Block Encryption Algorithm With Data-Dependent Rotations is protected by U.S. Patent #5,724,428 and #5,835,600.
Contents
Preface
... 7About 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
... 9Understanding the RSA Authentication Manager Deployment Process ... 9
Terms and Concepts to Know Before Planning ... 9
Deployment... 9
Realm ... 9
Security Domain ... 10
Instance ...11
Server Node ...11
Primary Instance ...11
Replica Instance...11
Agent... 13
Chapter 2: Identifying Your Deployment Model
... 15Using Scenarios to Plan Your Deployment ... 15
The Small Deployment: Miller and Strauss, Attorneys at Law... 17
The Medium-Sized Deployment: Greenley Biotechnologies ... 20
The Large Deployment: FocalView Software Company ... 25
Deployment Model Checklist ... 35
Chapter 3: The RSA Authentication Manager Architecture
... 37About the RSA Authentication Manager Model... 37
How Database Replication Works ... 38
Replication of Data ... 40
RSA Authentication Manager Database Architecture ... 41
Deciding Where to Store Data ... 41
Planning to Use the Internal Database As Your Data Store ... 42
Planning to Use an LDAP Directory As Your Data Store... 42
Authentication of Users ... 42
Planning Load Balancing Using Contact Lists ... 44
Attack Prevention... 44
Chapter 4: Planning RSA SecurID Protection
... 47Overview of the Authentication Experience... 47
RSA SecurID Tokens... 47
Authentication Agents ... 47
RSA Authentication Manager... 48
Deciding Which Resources to Protect with RSA SecurID ... 49
Protecting RSA Authentication Manager Servers ... 49
Protecting Access Through a VPN ... 49
Protecting Access Through a Radius Server... 49
Protecting Access Through TACACS ... 49
Protecting Access to Outlook Web Access... 49
Protecting Access to Web Pages... 50
Protecting FTP and Other UNIX-Based Protocols ... 50
Protecting Access to a CITRIX Server ... 50
Microsoft Windows Desktops ... 50
Protecting Windows Desktops with RSA SecurID for Microsoft Windows ... 50
Deploying the Authentication Agent in a Microsoft Windows Environment ... 51
RSA SecurID Protection Checklist ... 58
Chapter 5: Assessing System and Security Requirements
... 59System Requirements... 59
Supported Browsers... 61
Maintaining Accurate System Time Settings ... 62
Planning Port Usage... 62
Planning for Peak Authentication Periods ... 63
Planning Management of the Master Password... 64
Planning Physical Security... 64
System and Security Requirements Checklist ... 65
Chapter 6: Planning for Failover and Disaster Recovery
... 67Key Issues to Consider... 67
Planning for Possible Failure Situations ... 67
Detecting a Failed Primary or Replica Instance ... 67
What Happens After the Primary Instance Fails ... 68
What Happens If a Replica Instance Fails ... 70
Planning Recovery from the Loss of a Non-Database Server Node... 71
Planning Regular Database Backups ... 71
Chapter 7: Planning Your Installation
... 73Assessing Required Permissions for Installation ... 73
Planning Your RSA Authentication Manager Installation ... 74
Minimum Requirements for Machines ... 75
License Permissions... 75
The Necessary Level of Security ... 75
Personnel to Perform the Installation... 75
The Best Time to Perform the Installation... 75
Access Through Firewalls ... 76
Access Through Proxy Servers... 76
Migrating Users from an Existing RSA ACE/Server or RSA Authentication Manager Deployment ... 76
Planning Primary Instance Installation ... 77
Planning Replica Instance Installation... 77
Planning Server Nodes Installation... 78
Planning LDAP Directory Integration ... 78
Supported External Identity Sources ... 79
Selecting Read-Only or Read/Write ... 79
Establishing Security ... 80
Performing the Integration... 80
Mapping Attributes ... 80
Planning Active Directory Integration... 81
Global Catalogs... 82
Planning Sun Java System Directory Server Integration ... 83
Conducting a Pilot Test... 83
Installation Checklist... 84
Chapter 8: Planning for Administration
... 85About the RSA Authentication Manager Administrative Model... 85
Planning Administrative Roles, Permissions, and Scope ... 85
Predefined Admininstrative Roles ... 89
Planning Administration Through the Microsoft Management Console (MMC) ... 93
Planning RSA Authentication Manager Training for Help Desk Administrators ... 94
Administration Checklist ... 95
Chapter 9: Planning PIN, Token, and Password Policies
... 97Planning PIN Policy... 97
Determining PIN Creation Methods ... 97
Balancing Security and Ease of Use in Determining PIN Policy ... 98
Planning PIN Requirements and Restrictions... 98
Chapter 10: Planning RSA SecurID Token Deployment
... 107Overview of RSA SecurID Token Types ... 107
Hardware Tokens... 108
RSA SecurID Software Tokens ... 109
Determining Which Types of Tokens to Deploy ... 109
Planning How to Deploy Tokens to Users...110
Hardware Tokens...110
Software Tokens ...111
Planning User Training on the Use of RSA SecurID Tokens...112
Informing Users About the Planned Rollout ...112
Communicating Authentication Instructions to End Users ...113
Token Deployment Checklist...114
Chapter 11: Planning Logging and Reporting
...115About Logging and Reporting ...115
Planning Log Maintenance ...116
Planning Log Archiving ...117
Planning Log Consolidation ...118
Planning SNMP Trapping ...118
Planning Reporting ...118
Available Reports ...119
Scheduling Reports ... 120
Logging and Reporting Checklist ... 120
Chapter 12: Completing The Deployment Checklist
... 121Glossary
... 127Preface
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
Related Documentation
RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows
documentation set. This documentation set is included with the Authentication Agent software. RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows works with RSA Authentication Manager 7.0 to protect your company’s local Windows desktops.
Getting Support and Service
RSA SecurCare Online 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.
RSA SecurCare Online https://knowledge.rsasecurity.com Customer Support Information www.rsasecurity.com/support RSA Secured Partner Solutions Directory www.rsasecured.com
1
Essential Terms and Concepts
• Understanding the RSA Authentication Manager Deployment Process
• Terms and Concepts to Know Before Planning
Understanding the RSA Authentication Manager Deployment
Process
In deploying Authentication Manager, start from the interior of your network (inside the corporate firewall) and work outward to the DMZ. The high-level overview of the process is:
• Install Authentication Manager on the internal server in each geographic location where authentication is required. This includes your backup and disaster recovery servers.
• Link your directory server to Authentication Manager, if you are not using the Authentication Manager internal database.
• Install authentication agent software on the users’ machines. • Test authentication.
Terms and Concepts to Know Before Planning
Make sure you understand the following terms and concepts before you use this document to plan your Authentication Manager installation.
Deployment
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.
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)
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
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
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.
Replica Instance
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 Data
1.
Instance
Data 2.
Instance
Data 3.
3. A multiple server node primary instance with a multiple server node replica instance
4. A multiple server node primary instance with multiple replica instances with multiple server nodes
Data
Data Data
1. 2.
3. 4.
Data Data Data
Data
Data
Data
Data Data
Data
Server Node Primary Instance
Key
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.
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.
The following table summarizes each scenario.
Element
“The Small Deployment: Miller and Strauss, Attorneys at Law”
“The Medium-Sized Deployment: Greenley Biotechnologies”
“The Large Deployment: FocalView Software
Company”
License Base Advanced Advanced
Number of Users 0 - 1,000 1,000 - 5,000 5,000 and up Realms (Top-Level
Security Domains)
1 1 1
Lower-Level Security Domains
None Multiple in one physical location
Multiple in multiple physical locations
Geographic Locations 1 1 Multiple
Number of Administrators 2 4 6
Number of IT Support Staff
0 20 50
Identity Source Authentication Manager Internal Database
Microsoft Active Directory
• Sun Java System Directory Server • Microsoft Active
Directory Authentication Method for
Internal Users
Password RSA SecurID RSA SecurID Authentication Method for
External Users
RSA SecurID RSA SecurID RSA SecurID
Policies Default • Default
• Custom
• Default • Custom
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.
Intranet Authentication
Managers
Data Internet
Remote Users
(with VPN client )
Domain Server
Local Users (Windows Password Authentication Only)
Windows Password Protected Resources
(File servers, DBs)
Miller and Strauss, Attorneys at Law
Proxy Server
Data
Primary
Replica
SecurID Ready Authentication
Agent
VPN Server
Firewall Firewall
DMZ
RSA SecurID Authentication Required
The following figure shows how Miller and Strauss organized users, groups, tokens, and so on for administration in their Authentication Manager deployment.
Use the following information about the Miller and Strauss scenario to help you visualize and understand what you need to consider as you plan the network and administrative organization of your deployment.
Realm
When RSA Authentication Manager is installed, a single realm is instantiated by default. Miller and Strauss does not need to segregate any of the user population, so no additional realms are required for this deployment.
License
Miller and Strauss purchased the Base license, which allows the firm to have one primary instance and one replica instance.
Authentication Agents
When external users want to gain access to the Miller and Strauss internal network, they must connect to the VPN server and authenticate. Miller and Strauss purchased a VPN server with an embedded RSA Authentication Agent. Internal users use
password authentication to access the company’s internal network.
Note: For a list of RSA Security partners who supply hardware with embedded
RSA Authentication Agents, go to www.rsasecured.com.
Instances
The primary instance and the replica instance both handle authentication requests. When a user attempts to authenticate for access to your network, the agent sends the request to the machine that is least busy. The replica instance is also for backup and disaster recovery purposes.
Identity Sources
Because this firm has no pre-existing identity source, the administrators chose to use the internal database that is embedded in Authentication Manager to store all
Authentication Manager user and token data.
Security Domains
Miller and Strauss has one security domain, which contains all users, administrative roles, authentication agents, tokens, and reports.
Policies
Miller and Strauss determined that the Authentication Manager defaults for realm (single), security domain (single), agents (unrestricted), groups (none), and policies (such as password, lockout, token, and session lifetime) are appropriate. These policies satisfy the firm’s requirements and facilitate a simpler installation. No customizing is required.
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
The following figure shows the Greenley Biotechnologies network, including users who need to access resources locally and remotely.
Authentication Managers
Internet Remote Users
Internal Users
(SecurID for Windows Local Authentication) Greenley Biotechnologies
VPN Server
Proxy Server
Data
Primary Replica Server Node Server Node PAM Protected Server (Finance) Data Domain Controller 3 (HR) Data (R&D) Data OWA Back End CITRIX Server Protected Resources
(File servers, DBs)
Web Server OWA Front End Firewall Citrix Presentation Server DMZ (Local Authentication Component Installed) Web Agent Installed Authentication Agent Installed Firewall Domain Controller 2 Domain Controller 1 SecurID Ready Authentication Agent RSA SecurID Authentication Required RSA SecurID Authentication Required Authentication Agent Installed Authentication Agent Installed Authentication Agent Data Web Agent Installed
The following figure shows how Greenley Biotechnologies organized users, groups, tokens, and so on for administration in their Authentication Manager deployment.
Use the following information about the Greenley Biotechnologies scenario to help you visualize and understand what you need to consider as you plan the network and administrative organization of your deployment.
Realm
There is one realm in this scenario because there is no need to segregate user populations.
Note: If the company wants to keep any of its business units separate, perhaps for
regulatory reasons, additional realms can be created. Administrators from one realm cannot manage resources (for example, users, tokens, or policies) in another realm.
License
Greenley Biotechnologies purchased an Advanced license, which allows the firm to have a primary instance, and multiple replica instances and server nodes.
Authentication Agents
To meet the Greenley Biotechnologies authentication requirements, the
RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows is installed on the external users’ laptops and internal users’ desktops. The agent provides access to the users’ laptops and desktops. When remote users want to gain access to the Greenley Biotechnologies internal network, they must connect to the VPN server. (Greenley Biotechnologies purchased a VPN server with an embedded
RSA Authentication Agent.)
Note: For a list of RSA Security partners who supply hardware with these embedded
RSA Authentication Agents, go to www.rsasecured.com. Greenley Biotechnologies downloaded RSA Authentication Agents for their web server and Outlook Web Access server. See your RSA Security sales representative for a list of
RSA Authentication Agents that you can download.
Instances
Greenley Biothechnologies has an Advanced license, which allows the company to include server nodes in its system. The network administrator determined that one primary instance (a database server and an additional server node) and one replica instance (a database server and an additional server node) is appropriate for the company’s anticipated level of authentication activity. The primary instance and the replica instance both handle authentication requests. When a user attempts to authenticate for access to the network, the agent sends the request to the server node that is least busy. (Remember, the database server is a node.) The replica instance is also for backup and disaster recovery purposes. The company can add more server nodes as it grows.
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
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
The following figure shows the FocalView Software network, including users who need to access resources locally and remotely.
Authentication Managers
Internet Remote Users
Internal Users
(SecurID for Windows Local Authentication)
VPN Server Proxy Server
Data Data
Primary Replica Server Node Server Node PAM Protected Server Domain Controller OWA Back End CITRIX Server Web Server OWA Front End Firewall Citrix Presentation Server DMZ Web Agent Installed Firewall Authentication Managers Internet Remote Users Internal Users
(SecurID for Windows Local Authentication) VPN Server Proxy Server RSA SecurID Authentication Required Da ta Replica Server Node PAM Protected Server Domain Controller OWA Back End CITRIX Server Web Server OWA Front End Firewall Citrix Presentation Server DMZ RSA SecurID Authentication Required Web Agent Installed Authentication Agent Installed Authentication Agent Installed Firewall SecurID Ready Authentication Agent Boston New York Authentication Managers Internet Remote Users Internal Users
(SecurID for Windows Local Authentication) VPN Server Proxy Server Da ta Replica Server Node PAM Protected Server Domain Controller OWA Back End CITRIX Server Web Server OWA Front End Firewall Citrix Presentation Server DMZ LAC Component Installed Web Agent Installed Firewall (Finance) Data (HR) Data (R&D) Data Protected Resources
(File servers, DBs)
San Jose Authentication Agent Installed Authentication Agent Installed RSA SecurID Authentication Required RSA SecurID Authentication Required Authentication
Agent Installed Agent InstalledAuthentication
Authentication Agent Installed Authentication Agent Installed SecurID Ready Authentication Agent Authentication Agent Installed Authentication Agent Installed Authentication Agent Installed RSA SecurID Authentication Required Authentication Agent Installed Authentication Agent Installed Authentication Agent Installed SecurID Ready Authentication Agent RSA SecurID Authentication Required Authentication Agent (Local Authentication Component Installed)
FocalView Software
The following figure shows how FocalView Software organized users, groups, tokens, and so on for administration in their Authentication Manager deployment.
Use the following information about the Miller and Strauss scenario to help you visualize and understand what you need to consider as you plan the network and administrative organization of your deployment.
Realm
This scenario has one realm because all three locations act as one business unit and the company does not need to segregate any user populations for administrative purposes. FocalView Software recently acquired the San Jose company and added it to the realm. If the company develops or acquires other business units in the future, they can be added to the realm. If the company wants to keep any of its business units separate, perhaps for regulatory reasons, additional realms can be created to segregate user populations for administrative purposes. This separation occurs because each realm uses its own identity source. Administrators from one realm cannot access or manage resources that belong to another realm, for example, users, tokens, or policies.
License
FocalView Software purchased an Advanced license, which allows the firm to have a primary instance, multiple replica instances, and multiple server nodes.
Authentication Agents
To meet FocalView Software authentication requirements, the
RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows is installed on external users’ laptops and internal users’ desktops. The agent provides access to the users’ laptops and desktops. When remote users want to gain access to the FocalView Software internal network, they must connect to the VPN server.
(FocalView Software purchased a VPN server and a Citrix Presentation server with an embedded RSA Authentication Agent.)
Note: For a list of RSA Security partners who supply hardware with embedded
RSA Authentication Agents, go to www.rsasecured.com.FocalView Software downloaded RSA Authentication Agents for their web server and OWA server. See your RSA Security sales representative for a list of RSA Authentication Agents that you can download.
Instances
When the Super Admins at FocalView Software planned their deployment, they determined the need to have instances of Authentication Manager in each geographic location. They required quick authentication and localized administration. With an instance in each location, requests for authentication are handled locally. This is faster than requiring requests from every location to pass through one location. It also enables the company to delegate certain administrative privileges to local administrators and to install local security domains.
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.
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
Deployment Model Checklist
Use this checklist to begin documenting your plan.Element Description Your Plan
License type Know which license you have: • Base
• Advanced
Realm Know how many realms you
want.
Security Domain • Understand how
Authentication Manager uses top-level and lower-level security domains.
• Know how many lower-level security domains you need, what you want in them, and how you want their hierarchy organized.
Authentication Know which types of users you require to authenticate:
• Internal users • External users
Know how you want types of users to authenticate:
• Password
• RSA SecurID token
Physical location Know where you want to locate your Primary Instance and each
Replica Instance.
Identity source Know what identity source you plan to use:
• Internal database • Active Directory • Active Directory Global
Catalog
• Sun Java System Directory Server
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
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.
In this “hub and spoke” model, two replica instances never communicate directly.
Administrative Updates Data Flow
Database Server Boston1
Primary Instance
Server Node Boston1
Database Server San Jose
Replica Instance
Server Node San Jose
Database Server New York
Replica Instance
Server Node New York Database Server
Boston2
Replica Instance
Server Node Boston2
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.
You should know:
• You can see the changes at any instance after the changes have been propagated. • If a replica instance contains more recent changes than those received from the
primary instance, the replica instance can reject the less timely data.
• If Authentication Manager does not load the database after the data has been changed, you see obsolete data at the replica instance.
Runtime Updates Data Flow
Database Server Boston1
Primary Instance
Server Node Boston1
Database Server San Jose
Replica Instance
Server Node San Jose
Database Server New York
Replica Instance
Server Node New York Database Server
Boston2
Replica Instance
Server Node Boston2
Replication of 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.
Replicated Data
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 Change That Is Replicated
User Any change to the user’s fixed passcode or PIN.
Agent • The creation of an agent through agent auto-registration.
• Assignment of an agent to a contact list. See “Planning Load Balancing Using Contact Lists,”on page 44.
• Updating a node secret.
Token Any changes that occur as a result of the following activities: • Authentication.
• Token replacement, including disabling, unassigning and deleting an existing token, and assigning and enabling a replacement token. The exact changes that occur depend upon how you configure Authentication Manager to handle token replacement. See “Replacing Tokens” in the
Administrator’s Guide.
• Emergency passcode processing.
• The distribution of offline authentication data to agents. • Seed initialization of a Software Toolbar Token.
Log data on a replica instance is not replicated in the same way as changes resulting from authentication. Log data is sent only to the primary instance, or to a designated centralized log, and is not replicated to all instances in your system.
Important: The user and user group data that resides in your LDAP directory is not
replicated by Authentication Manager. In a replicated LDAP environment, it is your responsibility to properly configure LDAP to replicate LDAP changes.
RSA Authentication Manager Database 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
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.
In the Authentication Manager model, the process of authentication is an interaction of three distinct products:
• An RSA SecurID token, which generates a random number at a set interval of time, usually one minute. The random number, known as a tokencode, combined with a user’s personal identification number (PIN), produces a passcode. A token can be a hardware device or a piece of software installed on a device (PC, Palm Pilot, Pocket PC, Blackberry).
Requiring both the tokencode and the PIN is known as two-factor authentication: something you have (the token and tokencode displayed on it) and something you know (the PIN). The user presents the PIN and tokencode, or passcode, at the logon prompt to access a protected resource.
• An authentication agent, which is software that, when installed, requires any user logging on to provide the correct RSA SecurID passcode, in addition to any other required logon information (such as User ID and network password).
Agent software is available for many platforms, including Microsoft Windows and multiple versions of UNIX, and many purposes, including protecting access to networks, desktops and web sites. Additionally, there are many third-party vendors who have partnered with RSA Security to provide built-in support for RSA SecurID authentication in their products. These products include RADIUS servers, Virtual Private Network (VPN) Servers, and routers.
For more information about supported products, see the RSA Secured Partners Solutions Directory at http://rsasecurity.agora.com/rsasecured/.
• Authentication Manager, which processes the authentication request, verifying the supplied passcode.
To authenticate a user, Authentication Manager needs, at a minimum, the following information:
• A user record containing a User ID and other personal information about the user (for example, first name, last name, group associations, if any). You can configure an LDAP directory server as the identity source, or you can enter the user
information into the internal database using the RSA Security Console. When deciding which method is best for you, consider which data store (and therefore which administrator) “owns” the data.
• An agent record, which lists the name of the machine on which the agent is installed. The existence of an agent record in the internal database identifies the agent to Authentication Manager and enables Authentication Manager to respond to authentication requests from the agent.
• A token record, which enables Authentication Manager to generate the same tokencode that is displaying on a user’s RSA SecurID token.
• Under most circumstances, a user PIN, which is used in conjunction with the tokencode to form the passcode.
Planning Load Balancing Using Contact Lists
Authentication Manager provides load balancing through contact lists, which contain a list of all the server nodes where the authentication agent can direct authentication requests. After an agent contacts Authentication Manager, Authentication Manager provides the agent with the contact list.
Important: Do not use any third-party load balancing products. Authentication agents
perform their own load balancing and server discovery. The authentication agent protocol is not compatible with third-party UDP load balancing products.
Agents receive notification from Authentication Manager of any changes to the contact list. Periodically, the agent reviews all the server nodes listed in the contact list to determine where to send authentication requests. The agent uses metrics such as response performance to determine where to send requests.
There are two types of contact lists:
Automatic Contact Lists. Automatic lists are automatically maintained by Authentication Manager, and are automatically updated each time a new server node is added to the deployment. An automatic contact list is assigned to each instance in your deployment. The list contains the IP addresses of each server node in the instance the contact list is assigned to, and the IP address of one server node from each other instance in your deployment, up to a limit of 11. Agents are sent automatic contact lists by default.
Manual Contact Lists. Manual lists are maintained by administrators. They must be manually updated to reflect the most recent list of server nodes. Manual lists can contain the IP address of any server node in the deployment, up to a limit of 11 server nodes.
For almost all organizations, automatic contact lists are sufficient. However, you may choose to create a manual contact list if you have a specific way that you want to route authentication requests. For instructions on adding manual contact lists, see the Help topic, “Add a Manual Contact List.”
Note: You can override the contact list, and thereby direct an agent to a particular
instance by configuring the sdopts.rec file on the agent. See the RSA Authentication Agent 6.1.1 Special Edition for Microsoft Windows Installation and Administration Guide.
Attack Prevention
Authentication Manager provides protection against unauthorized users attempting to hack into your systems, either using compromised credentials, like a stolen token, PIN, or passcode, or through a brute force method, like attempting to authenticate multiple times using randomly generated passcodes.
Evasion of Attack
The following evasion-of-attack features do notreplace 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 essentialto 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.
RSA Authentication Manager Architecture Checklist
3 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.
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
The process of authentication is an interaction of three distinct products: • RSA SecurID tokens
• Authentication agents
• RSA Authentication Manager
RSA SecurID Tokens
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 Agents
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.
During an authentication, Authentication Manager and the agent software work in the following way:
1. A user initiates an authentication request by logging on to a system.
2. The agent software prompts the user to enter a User ID and an RSA SecurID passcode.
3. The agent software sends the entered data to Authentication Manager.
The packets containing the data are encrypted using a shared key called a node secret, which is known only to Authentication Manager and the agent. The node secret itself is encrypted on the agent and in the database.
4. Authentication Manager receives the User ID and passcode and looks for the user record in a specified identity source.
Authentication Manager stores information about the user in the internal database, or in an associated LDAP directory server, known in Authentication Manager as an identity source.
5. Authentication Manager calculates the correct value of the passcode by accessing the token record of the token assigned to the user, and, using data contained in the token record, generating the passcode.
6. If the passcode is correct, Authentication Manager approves the authentication request, and allows the user access to the network.
RSA Authentication Manager Model Authentication AgentMachines with
Installed
RSA Authentication
Manager Instance
Internal Database LDAP Directory
User with RSA SecurID token
