RSA Authentication
Manager Express
Technical Workshop
Dave Taku, CISSP – Product Manager
Chris Crellin – Product Manager
© Copyright 2011 EMC Corporation. All rights reserved.
1
Agenda
© Copyright 2011 EMC Corporation. All rights reserved.
10:00
Welcome
Session #1
10:10 – 10:40
10:40 – 11:00
11:00 – 11:15
11:15– 11:45
Product Overview
AMX Demo
Sales Tools
Deep Dive: The RSA Risk Engine
11:45 – 12:30
Lunch
Session #2
12:30 – 13:00
13:00 – 13:30
13:30 – 14:00
RBA Integration
Deployment Best Practices
Troubleshooting
14:00
Wrap Up
2
RSA Authentication: Innovation Timeline
Understand the customer’s need to balance
Cost
Passwords
Convenience
RSA Authentication
Manager Express
Security
Enterprise
B2C Applications
Small & Mid-Size
Organizations
More than 1,000 users
More than 10,000 users
Fewer than 2,500 users
Hardware
tokens
Software
tokens
© Copyright 2011 EMC Corporation. All rights reserved.
SMS & text
messaging
Risk-Based
Authentication
(B2C)
Convenient, userfriendly strong auth
with lower TCO
3
Authentication Market by the Numbers
124
45
123456
Millions of SSL VPN users in 20121
Percent of companies still using
passwords for remote access
authentication2
Most commonly used password3
1 Gartner
Specialized SSL VPN Equipment, 2008
Forrester Enterprise And SMB Security Survey, North America And Europe, Q3 2008
3 http://igigi.baywords.com/rockyou-com-passwords-list/
2
© Copyright 2011 EMC Corporation. All rights reserved.
4
© Copyright 2011 EMC Corporation. All rights reserved.
5
What We’ve Heard
Secure Access for Mobility and Collaboration
Before Scenario
Required Capabilities
“Lack of confidence about who is remotely
accessing information”
Proven authentication technology
“Users struggle with cumbersome security
mechanisms”
Convenient and user-friendly solution
“Diverse end-user base results in varying
requirements”
“Security Solutions are Complex and
Expensive”
“Meeting and proving compliance is complex
and time consuming”
Authentication solutions suitable for employees,
contractors, partners, and clients
Easy to deploy and manage solution that integrates
seamlessly
Fast to implement solution that can be proven to
meet compliance requirements
Cost-effective strong authentication that is stronger
than a password, but easy to use for IT staff and endusers
© Copyright 2011 EMC Corporation. All rights reserved.
SOLUTI
ON
6
Introducing Authentication Manager Express
Multi-factor authentication with zero footprint
On-Demand Authentication
Risk-Based Authentication
Easy to Manage
Appliance Platform
© Copyright 2011 EMC Corporation. All rights reserved.
7
On-Demand Authentication (SMS)
• One-Time Password (OTP) delivered via SMS or
email
– Based on the RSA SecurID algorithm
– Compatible with any mobile phone from any carrier
– Open support for many third party SMS gateways and
modems
– No software to deploy or tokens to manage
– Provides multi-factor authentication:
• Factor #1 – PIN
• Factor #2 – Mobile device or e-mail account
© Copyright 2011 EMC Corporation. All rights reserved.
8
Risk-Based Authentication
How it Works
Device
Identification
User
Behavior
SSL VPN
Authentication
Policy
PASS
Activity Details
Web Browser
Assurance
Level
Web
Portals
RISKY
RSA
Risk Engine
OWA
Protected
Resources
Identity
Challenge
PASS
?
SharePoint
© Copyright 2011 EMC Corporation. All rights reserved.
OnDemand
Tokencode
Challenge
Questions
FAIL
Access Denied
9
Use Case: Web-Based Remote Access
For Employees, Contractors, Partners and Clients
Employee Mobility
SSL VPN
SSL VPN and web-based
email for employees &
contractors
Government
Web Portals
State and local agencies
that must adhere to
compliance regulations
OWA
Manufacturing
SharePoint
Vendors accessing an
Order Management System
hosted by XenApp
© Copyright 2011 EMC Corporation. All rights reserved.
Professional Services
A Law Firm that exchanges
sensitive information with
clients using an online
portal
Healthcare
Community Health Clinics
eliminating the “token
necklace” for medical staff
Employees &
Contractors
Partners &
Vendors
Clients
10
Customer Challenges
Related Before Scenarios that Compel Action
– Purchase or deployment an SSL VPN in need of
authentication
– Development of a new business plan to launch an online
portal for partners, customers or employees
– Emergence of new or renewed government/industry
regulations
– Awareness of emerging threats
– Incidents of breach, loss, or fraud
– Reconsideration of strong authentication solutions based on
awareness of new options including AMX
– Appearance of a new security officer/executive
© Copyright 2011 EMC Corporation. All rights reserved.
11
Wins across all verticals and use cases
Healthcar
e
Hospitals
Clinics
Finance
Retai
l
Local banks Traditiona
l
Credit
unions
Manufacturin
g
Governme
nt
Service
s
Industrial
Local
government
Consultin
g
Biotech
Online
Transportatio
n
Technolog
y
Devices
Insurance
Defense
Accountin
g
SSL VPNs, Citrix, OWA, SharePoint, web portals
© Copyright 2011 EMC Corporation. All rights reserved.
12
Abt Associates
Theater: Americas (US)
Company Profile: Mission-driven consulting company with 2,000 employees across 40
countries
Use Case: Secure remote access to Cisco SSL-VPN
Number of Users: 1,600
Customer requirements:
• Out of the box integration with Cisco SSL-VPN
• Easy for users; previous token-based solution was challenging for the remote user base
• Customizable challenge questions across multiple languages
How AMX solved the problem:
• Out of the box integration with leading SSL VPN vendors meant a simple integration with the
existing Cisco solution.
• Behind the scenes risk-based authentication simplified the login process for Abt users, reduced
help desk calls, and improved employee satisfaction with the company’s IT systems.
• Customizable challenge questions enabled IT management to deploy step-up challenge questions
in thirteen required languages.
© Copyright 2011 EMC Corporation. All rights reserved.
13
Datametrix
Theater: Europe (Norway)
Company Profile: Provider of IP-based solutions that enable secure communication through
data, voice, and video.
Use Case: Secure access to a customer (B2B) web portal
Number of Users: 500
Customer requirements:
• Secure access to the web portal
• Strong authentication that is easy for users
• Prevent terminated users from gaining unauthorized access
How AMX solved the problem:
• Proven risk-based authentication technology secures access to web-based applications
• The transparent multi-factor authentication solution protects against unauthorized access without
negatively impacting the customer login experience
• Device binding and email challenge prevent terminated users from gaining access even if accounts
were still active.
© Copyright 2011 EMC Corporation. All rights reserved.
14
Bernas, Padiberas Nasional Berhad
Theater: Asia Pacific (Malaysia)
Company Profile: Malaysian national company dedicated to managing the procurement,
warehousing, distribution, marketing and exporting of all domestically grown rice.
Use Case: Secure remote access to Citrix
Number of Users: 250
Customer requirements:
• Strong authentication to protect sensitive customer information
• Integration with existing Citrix solution
• Easy for remote and technologically unsophisticated users to use
How AMX solved the problem:
• Lightweight nature of AMX means a simple deployment process using minimal IT resources
• Prewritten integration scripts enabled a simple, out of the box integration with the existing Citrix
solution
• Behind the scenes risk-based authentication means nothing new for users to learn, no end user
disruption
© Copyright 2011 EMC Corporation. All rights reserved.
15
In Summary…
AMX addresses the growing demand for tokenless
authentication
• WHO: Small and mid-size organizations with less than 2500 users that are still
using passwords today.
• WHAT: A convenient and user-friendly strong authentication solution based on two
tokenless authentication technologies: Risk-Based and On-Demand.
• WHERE: Browser-based remote access to SSL-VPNs, web portals, and other
web-based applications.
• WHEN: Remote access and information sharing with employees, contractors,
partners, and clients.
• HOW: An easy-to-manage and cost-effective hardware appliance that integrates
out-of-the-box with the leading web-based solutions.
• WHY: Traditional strong authentication alternatives are too expensive, complex, or
cumbersome to meet the need.
© Copyright 2011 EMC Corporation. All rights reserved.
16
AMX Demo
© Copyright 2011 EMC Corporation. All rights reserved.
17
Licensing, Configuration, and Pricing
• Licensing: Single SKU perpetual licensing
– Licensed per registered user
– Includes all authentication options
– Credentials are re-assignable
– Does not expire
• Pricing: Volume based pricing tiers (similar to
Authentication Manager)
– Appliance bundles are available
– No tokens to purchase or renew
• Maintenance:
– Annual software maintenance is 21% of
license fee
– 3-year AHR is included with the h/w
appliance
RSA Authentication Appliance 130
• Same as the SecurID Appliance 130 (1U
hardened Linux OS)
• Scalable up to 2,500 users
• Primary + Replica (1)
AMX Web Tier Server
• Required for RBA deployments
• Installs on a separate Windows or Linux
server (not included)
• Included with all AMX appliance orders
Years 4 and 5 optional and additional
© Copyright 2011 EMC Corporation. All rights reserved.
18
AMX 1.0 vs. AM 7.1
COMPONENTS
USE CASES
DEPLOYMEN
T
Authentication Manager Express
1.0
RSA Authentication Manager 7.1
License size
Up to 2,500 registered users
No limit to number of registered users on software;
50k on RSA SecurID Appliance
Market
Mid-sized organizations from 50 – 2,000
users
Small, medium, and large enterprise
Target customers
Healthcare, higher education, legal services,
retail, technology
Financial, healthcare, retail, technology, telecom
Authentication methods
Risk based
On-demand (SMS or email)
SecurID (hardware & software tokens)
On-demand (SMS or email)
Applications
SSL VPNs
Web-based applications
VPNs (SSL and IPSec)
Web-based applications
OS (Windows, Linux, etc.)
Wireless, Routers, legacy, & more…
Platform
RSA Authentication Appliance 130
Software: Widows, Linux, Solaris, VMware
RSA Authentication Appliance (130 or 250)
Replicas
1 replica supported
Up to 15 (five on the Appliance)
RADIUS
N/A
Full RADIUS client included
Native LDAP
Microsoft AD (2003/2008/2008R2)
Read Only
Microsoft AD (2003/2008/2008R2), Sun JSDS
Read Only or R/W
Web Tier
DMZ deployment of RBA and Self Service
N/A
© Copyright 2011 EMC Corporation. All rights reserved.
19
Deal Qualification Checklist
• Use to quickly evaluate
AMX customer fit
– Green: No Issues
– Yellow: Caution
– Red: Stop
• Review
recommendations for
flagged items
© Copyright 2011 EMC Corporation. All rights reserved.
20
RSA Partner Central
• Collateral
– Datasheet, solutions brief, etc.
– All localized (Polish, Hungarian, Czech,
German, etc.)
• Demo/POC
– Overview/demo (5-min Flash video)
– Technical demo (12-min video)
– Remote Validation Center (RVC)
– NFR Kits: appliance and VM options
• Sales Tools
– Deal qualification checklist
– Quick reference guide
– AM vs. AMX comparison
– FAQ
© Copyright 2011 EMC Corporation. All rights reserved.
21
Additional Training Opportunities
• RSA Educational Services (Online Training)
– SALES: Introduction to Selling RSA Authentication Manager
Express
– TECHNICAL: What’s New: RSA Authentication Manager Express
© Copyright 2011 EMC Corporation. All rights reserved.
22
Understanding
the RSA Risk
Engine
© Copyright 2011 EMC Corporation. All rights reserved.
23
The RSA Risk Engine
• Proven sophisticated risk engine
– Same risk engine as Adaptive Auth
– Protects 250+ million online identities
RSA Risk Engine
• Optimized for Enterprise use cases
– Optimized for: Network Security vs.
Fraud Mitigation
– Predictable: Use case vs. challenge
rate
– Simplified: Assurance levels vs. risk
scoring
• Self tuning risk model adapts to each
customer environment
– Common device characteristics are
de-prioritized in the risk score
– Suspicious behavior is based on
norms for the overall user population
© Copyright 2011 EMC Corporation. All rights reserved.
24
The RSA Risk Engine
Device
Identification
User
Behavior
SSL VPN
Authentication
Policy
PASS
Activity Details
Web Browser
Assurance
Level
Web
Portals
RISKY
RSA
Risk Engine
OWA
Protected
Resources
Identity
Challenge
PASS
?
SharePoint
© Copyright 2011 EMC Corporation. All rights reserved.
OnDemand
Tokencode
Challenge
Questions
FAIL
Access Denied
25
Device Identification
• Device information is a collection of facts about a user’s machine. These
collected facts are evaluated by the risk engine to help identify fraudulent
authentication attempts.
• For each device that interacts with AMX, the following information is
captured:
– Device Fingerprint
– Network Forensics
– Device Token
• If the device can be identified as a registered device for that user, the
authentication attempt is considered low risk; otherwise, the user is
considered a higher risk and will be challenged.
© Copyright 2011 EMC Corporation. All rights reserved.
26
Device Identification
Device Fingerprint
• Analyzes the detailed hardware and software characteristics of each
computer
– User agent string: The version, platform, and the acceptance-language header (the
user’s language preference)
– System Display: Width, height, and color depth of the user’s screen
– Software Fingerprint: Browser components and plug-ins installed on the device
– Browser language: The language of the actual browser
– Time zone: The user’s current time zone in GMT
– Language: The user’s browser language and the system language
– Cookies: Whether or not the user has cookies enabled on their device
– Java-enabled: Whether or not the user has java enabled on their device.
© Copyright 2011 EMC Corporation. All rights reserved.
27
Device Identification
Network Forensics
• Matches device IP configuration to previously registered IP addresses
for that machine
• Supports DHCP with partial credit based on strength of match:
– Exact IP address: Perfect match
– Same Class C subnet: Strong match
– Same Class B/A subnet: Weak match
Note: IP address is used as an identifying device characteristic,
but the risk associated with a new, unrecognized, or stale IP
address is also evaluated as part of the behavioral analysis
© Copyright 2011 EMC Corporation. All rights reserved.
28
Device Identification
Device Token
• Device tokens are created and placed on the user’s machine for future
identification using a combination of cookies and Flash Shared Objects
(FSO’s)
• Device Token Recovery can automatically restore user-deleted tokens
based on device forensics
• Device Token Theft Protection prevents impersonation of a device using
a stolen token (e.g., via malware) through a combination of techniques
– Encryption of the device ID in the token prevents reuse on another computer
– Tokens generation counter prevents replay of an older token
© Copyright 2011 EMC Corporation. All rights reserved.
29
Device Identification
Putting it all together
• Device tokens (cookies/FSO)
ensure a unique match
• Without device tokens,
strength of match is
determined by statistical
probability
• The risk engine automatically
updates its scoring algorithm
based on the statistical
probability of certain
characteristics within each
unique deployment.
© Copyright 2011 EMC Corporation. All rights reserved.
Match with existing
attributes in profile?
Collective statistics
What’s the probability of a
random match ?
User Profile
User
IP address
cookie
Attribute
Value
cookie
...
0%
IP class B
124.55
3%
recently used user-agents
match
ü
user-agent
MSIE 5.5
recently used SW fingerprints
match
ü
IP class B +
user-agent
combination
recently used cookies
ü
match
SW fingerprint recently used IP class B
user-agent
no match
...
%
1.5%
0.1%
30
Behavioral analysis (predictors)
• Evaluates behavioral trends for each user/device and corporately across
all users in the organization
– Anomalous behavior increases the risk associated with an authentication attempt
– Common behavior lowers the relevance of this factor in the overall risk score
• Three categories of behavior are evaluated
– Profile anomalies: recent password or account changes
– Comparative anomalies: e.g., new or infrequently used IP address are higher risk
– Velocity anomalies: high velocity of users of a single IP/device or high velocity of IP
addresses for a single user
• Overall impact of behavior anomalies are based on frequency and
recentness
– Higher velocity and/or lower statistical probability increase the risk score
– Recent events are considered high risk but become less impactful over time
© Copyright 2011 EMC Corporation. All rights reserved.
31
Examples of Risky Behavior
• Low Risk: Common activities that nonetheless could be associated with
fraud
– New accounts, recently modified accounts, or authentications from
previously unknown locations
• Medium Risk: Multiple activities combined in a suspicious way
– Authenticating from an unusual location soon after a failed Identity
Confirmation challenge
• High Risk: Clearly identified fraudulent activity
– Authenticating from a machine with an invalid or modified cookie
Note: The older a risk event, the less impact it has
on your risk score
© Copyright 2011 EMC Corporation. All rights reserved.
32
Assurance Levels
• Assurance Level: The degree of confidence associated with each user
authentication attempt
Strong
Device
Match
Increases
Assurance
Risky User
Behavior
Decreases
Assurance
• Minimum Assurance Level:
– Minimum assurance required to authenticate without being challenged
– Defined by policy (multiple policies can be created)
– Four pre-defined assurance threshold – HIGH, MED-HIGH, MEDIUM, LOW
© Copyright 2011 EMC Corporation. All rights reserved.
33
Identifying the Key Assurance Level
Contributors for each authentication attempt
Overall Assurance Level
– Assurance based on device identification and
behavioral predictors
– Five levels from Very Low to High
– Assurance < the defined policy threshold will
result in an Identity Challenge
Device Identification Score (Arg 3 - 5)
(raises the overall assurance level)
– Highest contributing token element
– Highest contributing networking element
– Highest contributing device fingerprint element
Behavioral Analysis Score (Arg 3 - 5)
(lowers the overall assurance level)
– Highest contributing profile anomaly
– Highest contributing comparative anomaly
– Highest contributing velocity anomaly
© Copyright 2011 EMC Corporation. All rights reserved.
34
Selecting a Minimum Assurance Level
• High Assurance: BEST for protecting sensitive assets when higher challenge rates are
acceptable
• Authentication from easily-identifiable, corporate-owned assets (e.g., an employee laptop)
• Users that regularly authenticate from the same location (e.g., branch office, partner location, or an
employee’s home)
• Medium-High Assurance (Recommended): VERY GOOD for protecting sensitive assets
when higher challenge rates are not acceptable
• Authentication from corporate and individual-owned assets when policy can be dictated (e.g.,
cookies must be enabled).
• Laptop users that frequently authenticate while traveling
• Medium Assurance: GOOD when a balance between protection and end user convenience
is required
• Authentication from uncontrolled, Individual-owned assets (e.g., a personal laptop or home PC)
• When corporate policy cannot be enforced or when tracking objects (e.g., cookies or flash shared
objects) cannot be reliably used
• Low Assurance: Provides the lowest level of protection and should only be used with the
least sensitive assets and when end user convenience is the overriding priority.
• Provides only minimum device assurance while challenging users primarily based on suspicious
behavior
© Copyright 2011 EMC Corporation. All rights reserved.
35
Other Determining Factors
• The risk engine requires a learning period:
– During which it is building up a profile of users, their devices, and of the general user
population behavior. During this initial period, users may be challenged at a higher
rate
• The risk engine employs soft matching techniques:
– That allow for a partial match based on statistical probability. For example, the risk
engine may have insufficient information to unequivocally identify a device, but it will
use a variety of forensic tools to assess the probability of a match and adjust its
scoring accordingly.
• The AMX risk engine employs a self-tuning model:
– That dynamically compensates its statistical matching algorithms based on the
commonality of certain parameters within your deployment. A self-tuning model
improves security while optimizing the model for your specific deployment and
reducing overall challenge rates, but this also means that results could vary over time
© Copyright 2011 EMC Corporation. All rights reserved.
36
Silent Collection
•
Enables a seamless migration of users
from passwords to RBA without preprovisioning or other administrator
intervention
• During silent collection, the risk engine:
•
–
–
Passively monitors user authentications attempts
–
–
Automatically registers user devices
Updates its risk model based on collected profile
and behavioral data
Does NOT challenge high risk users
If a user achieves the minimum
assurance threshold they are prompted
to complete the self-enrollment process
© Copyright 2011 EMC Corporation. All rights reserved.
37
Silent Collection
Pros and Cons
Pros
– Seamless transition with minimum disruption for end users
– No administrator intervention required
– User-specific silent collection period minimizes the collection
window
– Useful for initial AMX roll out and for on-boarding of new users
– Better tuned risk engine before users are challenged
Cons
– During the collection period, authentication is password-only
– Some risk that an attacker could bind an unauthorized machine
– Collection period can expire before the user completes enrollment
© Copyright 2011 EMC Corporation. All rights reserved.
38
Lunch
© Copyright 2011 EMC Corporation. All rights reserved.
39
Agenda
© Copyright 2011 EMC Corporation. All rights reserved.
10:00
Welcome
Session #1
10:10 – 10:40
10:40 – 11:00
11:00 – 11:15
11:15– 11:45
Product Overview
AMX Demo
Sales Tools
Deep Dive: The RSA Risk Engine
11:45 – 12:30
Lunch
Session #2
12:30 – 13:00
13:00 – 13:30
13:30 – 14:00
RBA Integration
Deployment Best Practices
Troubleshooting
14:00
Wrap Up
40
AMX Integration
© Copyright 2011 EMC Corporation. All rights reserved.
41
On-Demand Authentication Flow
Internet
Intranet
DMZ
SSL-VPN
SecurID
Agent
1. Connect to SSL-VPN
4. Access Granted
Protected
Resource
s
2. Validate PIN
3. Validate On-Demand
tokencode
2. Send On-Demand tokencode
© Copyright 2011 EMC Corporation. All rights reserved.
AMX
Appliance
42
Risk-Based Authentication Flow
Intranet
DMZ
Login Page
(w/RBA
script)
1. Connect to SSL-VPN
SSL-VPN
6. Redirect to SSL
VPN with artifact
© Copyright 2011 EMC Corporation. All rights reserved.
7. Validate artifact
using SecurID APIs
RBA Service
2. RBA integration script
redirects the browser to the
AMX web tier
8. Access Granted
SecurID
Agent
Internet
AMX Web
Tier
5. Return “auth
artifact”
Protected
Resource
s
4. Risk Assessment
(challenge if
necessary)
AMX
Appliance
3. Authenticate user
43
Generating an RBA Integration Script
1. Configure authentication agent
2. Select third-party product from “Integration Javascript” drop down
3. Download customized integration script (am_integration.js )
4. Follow Implementation Guide to apply the script to the third-party product
© Copyright 2011 EMC Corporation. All rights reserved.
44
RBA Integration Script
• Adds Risk-Based Authentication to an existing SecurID
Agent
– Custom JavaScript added to the logon page of the protected resource
– Redirects the user to the RBA logon service (AMX web tier)
– Created during the SecurID agent configuration process and deployed outof-band to the protected resource
• Requires a product-specific RBA Integration Template
– Certified Integration Templates
• Bundled with each new AMX release
• Updates available on RSA Secured (www.rsasecured.com) and RSA.com between releases
– Custom Integration Templates
• Can be developed using the RBA Integration Template and reference examples
© Copyright 2011 EMC Corporation. All rights reserved.
45
RSA Secured Partner Solutions
Plug-and-Play Integration and Certified Interoperability
• Certified and supported by RSA
• Implementation Guides with illustrated
step-by-step instructions
• Builds upon SecurID agents already
embedded in hundreds of products
IMPORTANT NOTES!!
1.
If customer’s product differs from the version
in the Implementation Guide, check with
Partner Engineering to confirm compatibility
2.
If single sign-on (SSO) is a requirement,
check the Implementation Guide to confirm
support
© Copyright 2011 EMC Corporation. All rights reserved.
Visit www.rsasecured.com to view all supported
solutions or to request new product integrations
46
Does an RBA Integration Template Exist? If
not, can I create one?
• A certified RBA integration template already exists if either of
the following is true:
– It is a certified “RSA Secured” solution for Authentication Manager Express
– It is compatible with the RSA Authentication Agent for Web for SecurID
• Web applications built on IIS or Apache web servers
• Examples: Outlook Web Access, SharePoint, etc.
• A custom RBA integration template can be developed if ALL
of the following are true:
– It is a certified “RSA Secured” solution for SecurID
– Integration uses the native SecurID APIs (RADIUS implementations are NOT
supported)
– The user interface is browser-based – i.e., It does NOT require an installed client
Note: ODA does not require an integration template since ODA is natively supported by
SecurID authentication agents
© Copyright 2011 EMC Corporation. All rights reserved.
47
Deployment
Best Practices
© Copyright 2011 EMC Corporation. All rights reserved.
48
Deployment Best Practices
•
Confirm the use case is a good fit for AMX
–
•
Plan in advance for the network deployment
–
–
–
–
–
•
Using the Deal Qualification Checklist
What Deployment Scenario will be used?
Does the customer require server redundancy?
Will the deployment require web tier servers?
What is my load balancing strategy?
Do I have the latest integration script and Implementation Guide
for the application to be protected?
Collect network configuration data using AMX planning
tools
–
IP addresses, host names, firewall ports, etc.
© Copyright 2011 EMC Corporation. All rights reserved.
49
Deal Qualification: Common Deal
Breakers
• AMX does not support RADIUS
• SSO requires one of the
following:
– Kerberos Constrained
Delegation (KCD)
– Offline authentication API
(Citrix only)
• Separate web tier server
required if RBA or Self-Service
will be accessed from outside
the firewall
© Copyright 2011 EMC Corporation. All rights reserved.
50
AMX Deployments Scenarios
From the AMX Planning Guide
1. Primary Only
–
Unprotected ODA deployments
2. Primary + Replica Server
–
Redundant ODA deployments
3. Primary + Web Tier
–
Unprotected RBA deployments
4. Primary + Replica + Web Tier (x2)
–
Redundant RBA deployments
© Copyright 2011 EMC Corporation. All rights reserved.
51
AMX Web Tier
• Enables secure access to RBA and Self-Service from the
Internet without the need for a reverse proxy
• Web tier provides the following benefits:
– Separates RBA and Self-Service from the appliance for secure DMZ
deployment
• Blocks Internet access to the Security Console
• Makes RBA and Self-Service available from the Internet on SSL port
443
– Allows the use of publicly-signed SSL certificates
– Enables RBA cookies to work across both Primary and Replica
– Allows customization of the RBA logon pages
• Web tier required for almost all RBA use cases!
© Copyright 2011 EMC Corporation. All rights reserved.
52
Typical Web Tier Server Deployment
© Copyright 2011 EMC Corporation. All rights reserved.
53
Planning for Web Tier deployments
• AMX web tiers should be installed on servers in your DMZ
– Windows 2003/2008, Red Hat 5, or ESX 4.x
• Primary + Replica deployments require two web tier servers
– Each web tier is bound to its respective backend server
• Web tier servers do NOT support automatic load balancing
– Use an external load balancer or DNS round robin
• Web tier deployments require physical and virtual hostnames
– Virtual hostname (shared URL for load balancing RBA authentication requests)
– Primary web tier hostname (Primary web tier URL for self-service & user enrollment)
– Replica web tier hostname (used only if the replica is promoted)
• If replacing the web tier SSL certificates , use wildcard(*) or SAN
certificates
– Simplifies the deployment with a single certificate for primary, replica, and virtual host
– Allows both web tier servers to use the same tracking objects for RBA device binding
© Copyright 2011 EMC Corporation. All rights reserved.
54
Confused?
Use the AMX
Deployment Checklist
© Copyright 2011 EMC Corporation. All rights reserved.
55
Troubleshooting
Risk-Based
Authentication
© Copyright 2011 EMC Corporation. All rights reserved.
56
Troubleshooting RBA
• Review the four stages of an RBA authentication
1. Redirect to the web tier
2. Primary authentication
3. RBA authentication (with or without identity
confirmation)
4. Artifact generation & resolution
• At what stage is the authentication failing?
– Do you see the web tier logon page?
– Is authentication successful in the activity monitor?
– Is the artifact generated and resolved?
© Copyright 2011 EMC Corporation. All rights reserved.
57
Problem: Redirect to Web Tier
Intranet
DMZ
Login Page
(w/RBA
script)
1. Connect to SSL-VPN
SSL-VPN
6. Redirect to SSL
VPN with artifact
© Copyright 2011 EMC Corporation. All rights reserved.
7. Validate artifact
using SecurID APIs
RBA Service
2. RBA integration script
redirects the browser to the
AMX web tier
8. Access Granted
SecurID
Agent
Internet
AMX Web
Tier
5. Return “auth
artifact”
Protected
Resource
s
4. Risk Assessment
(challenge if
necessary)
AMX
Appliance
3. Authenticate user
58
Troubleshooting Web Tier Redirect
• Review Implementation Guide – is RBA integration script
deployed correctly?
• Do you have the latest script updates? (check
rsasecured.com)
• Is virtualhost configured correctly?
– Single web tier
– With DNS round robin
– With a load balancer
• Is the virtualhost in DNS? Does it have a public IP address?
• Did you change the virtualhost or load balancer
configuration AFTER deploying the RBA integration script?
– NOTE: If you modify the virtualhost or load balancer configuration, you will
need to generate a new web tier package (requires re-installation of the
web tier) and generate a new RBA integration script
© Copyright 2011 EMC Corporation. All rights reserved.
59
Problem: Primary Authentication Failing
Intranet
DMZ
Login Page
(w/RBA
script)
1. Connect to SSL-VPN
SSL-VPN
6. Redirect to SSL
VPN with artifact
7. Validate artifact
using SecurID APIs
RBA Service
2. RBA integration script
redirects the browser to the
AMX web tier
8. Access Granted
SecurID
Agent
Internet
AMX Web
Tier
5. Return “auth
artifact”
Protected
Resource
s
4. Risk Assessment
(challenge if
necessary)
AMX
Appliance
3. Authenticate user
© Copyright 2011 EMC Corporation. All rights reserved.
60
Troubleshooting Primary Authentication
• Can the web tier reach the AMX appliance?
– Are all necessary firewall ports open?
– Can the web tier resolve the appliance hostname (DNS
or hosts file)
• Is the primary web tier in DNS? Does it have a
public IP address? (required for first-time
authentication of AD users)
• Does the user record exist? Can AMX connect to
AD?
• Has the user configured their challenge methods?
© Copyright 2011 EMC Corporation. All rights reserved.
61
Problem: RBA Challenge Failing
Intranet
DMZ
Login Page
(w/RBA
script)
1. Connect to SSL-VPN
SSL-VPN
6. Redirect to SSL
VPN with artifact
© Copyright 2011 EMC Corporation. All rights reserved.
7. Validate artifact
using SecurID APIs
RBA Service
2. RBA integration script
redirects the browser to the
AMX web tier
8. Access Granted
SecurID
Agent
Internet
AMX Web
Tier
5. Return “auth
artifact”
Protected
Resource
s
4. Risk Assessment
(challenge if
necessary)
AMX
Appliance
3. Authenticate user
62
Troubleshooting RBA Challenge
• SQ: Answers must be exact match
• ODA: Troubleshoot like Authentication
Manager 7.1
© Copyright 2011 EMC Corporation. All rights reserved.
63
Problem: Artifact is Generated but Never
Returned to AMX
Intranet
DMZ
Login Page
(w/RBA
script)
1. Connect to SSL-VPN
SSL-VPN
6. Redirect to SSL
VPN with artifact
© Copyright 2011 EMC Corporation. All rights reserved.
7. Validate artifact
using SecurID APIs
RBA Service
2. RBA integration script
redirects the browser to the
AMX web tier
8. Access Granted
SecurID
Agent
Internet
AMX Web
Tier
5. Return “auth
artifact”
Protected
Resource
s
4. Risk Assessment
(challenge if
necessary)
AMX
Appliance
3. Authenticate user
64
Troubleshooting Artifact Replay
• Is SecurID agent configured correctly?
– Troubleshoot like a SecurID agent (e.g., is node secret present? Is
port 5500 open?)
– Tip: before deploying the RBA integration script, make sure the
agent configuration is working by performing a test ODA
authentication.
• Does the agent configuration include ALL agent IP
addresses? Is the public IP address configured as the
agent’s primary IP (if not, the artifact will be rejected as
invalid)
• Is the agent configured as a restricted agent? Does the user
have access to this agent?
© Copyright 2011 EMC Corporation. All rights reserved.
65
Other RBA Problems
• User is ALWAYS challenged
–
–
–
–
Are cookies/FSO disabled?
Is private browsing turned on?
Is javascript disabled?
Is assurance level too high? (see Admin Guide)
• User is NEVER challenged
– Is assurance level too low?
– Is silent collection configured?
• User is not prompted to enroll during silent collection period
– User will not be allowed to enroll until they authentication with a high
enough assurance level. Troubleshoot similar to the case where a user is
always challenged.
– Some high risk activity (e.g., invalid cookie) will prevent a user ever being
able to enroll.
© Copyright 2011 EMC Corporation. All rights reserved.
66
THANK YOU
© Copyright 2011 EMC Corporation. All rights reserved.
67
Scenario 2a:Primary Instance with Web Tier
Using a Public IP address
AMX Appliance
amx = 192.168.1.101 (private)
Private
7012
5500, 5580
7002, 7006,
7012, 7022
DMZ
Inbound Ports (DMZ -> Private):
• webtier -> amx:
7002, 7006, 7012, 7022
• sslvpn -> amx:
5500/UDP, 5580
Outbound Ports (Private -> DMZ):
• amx -> webtier: 7012
Web Tier
webtier = 123.0.0.101 (public)
SSL-VPN
DMZ
443
Internet
Inbound Ports (Internet -> DMZ)
• client -> webtier: 443
Outbound Ports (DMZ -> Internet):
• None
Notes:
Internet
sslvpn.company.com
© Copyright 2011 EMC Corporation. All rights reserved.
webtier.company.com
1.
A public IP address is required for the webtier server.
2.
Webtier hostname must be published to your external DNS and
resolve to its respective public IP address:
• webtier.company.com:
123.0.0.101
3.
In AMX, set the virtual hostname to be the same as the webtier
hostname.
68
Scenario 2b:Primary Instance with Web Tier
Using a NAT firewall
AMX Appliance
amx = 192.168.1.101 (private)
Private
7012
5500, 5580
7002, 7006,
7012, 7022
DMZ
Inbound Ports (DMZ -> Private):
• webtier -> amx:
7002, 7006, 7012, 7022
• sslvpn -> amx:
5500/UDP, 5580
Outbound Ports (Private -> DMZ):
• amx -> webtier: 7012
Web Tier
webtier = 10.10.1.101 (private)
123.0.0.101 (public)
SSL-VPN
DMZ
NAT Firewall
Internet
443
Inbound Ports (Internet -> DMZ)
• client -> webtier: 443
Outbound Ports (DMZ -> Internet):
• None
Notes:
Internet
sslvpn.company.com
© Copyright 2011 EMC Corporation. All rights reserved.
webtier.company.com
1.
A public IP address is required for the webtier server.
2.
Webtier hostname must be published to your external DNS and
resolve to its respective public IP address:
• webtier.company.com:
123.0.0.101
3.
Configure your NAT firewall to map the webtier public IP to its
respective internal IP :
• 123.0.0.101 (public) -> NAT -> 10.10.1.101 (private)
4.
In AMX, set the virtual hostname to be the same as the webtier
hostname.
69
Scenario 4a:Primary/Replica with Web Tiers
DNS round robin and Public IP addresses
Primary Appliance
Replica Appliance
primary = 192.168.1.101 (private)
replica = 192.168.1.102 (private)
2334, 7002
2334, 7002
7012
5500, 5580
Private
7012
7002, 7006,
7012, 7022
7002, 7006,
7012, 7022
DMZ
Primary Web Tier
Replica Web Tier
webtier-1 = 123.0.0.101 (public)
webtier-2 = 123.0.0.102 (public)
SSL-VPN
Inbound Ports (DMZ -> Private):
• webtier-1 -> primary:
7002, 7006, 7012, 7022
• webtier-2 -> replica:
7002, 7006, 7012, 7022
• sslvpn -> primary/replica:
5500/UDP, 5580
Outbound Ports (Private -> DMZ):
• primary -> webtier-1: 7012
• replica -> webtier-2: 7012
virtualhost =123.0.0.101, 123.0.0.102 (public)
DMZ
443
443
443
Internet
Inbound Ports (Internet -> DMZ)
• client -> webtier-n/virtualhost: 443
Outbound Ports (DMZ -> Internet):
• None
DNS round robin
Notes:
Internet
sslvpn.company.com
webtier1.company.com
© Copyright 2011 EMC Corporation. All rights reserved.
virtualhost.company.com
1.
One public IP address is required for each webtier server.
2.
Webtier hostnames must be published to your external DNS and
resolve to their respective public IP addresses:
• webtier-1.company.com: 123.0.0.101
• webtier-2.company.com: 123.0.0.102
• virtualhost.company.com: 123.0.0.101, 123.0.0.102 (using
DNS round robin)
70
Scenario 4b:Primary/Replica with Web Tiers
DNS round robin and NAT
Primary Appliance
Replica Appliance
primary = 192.168.1.101 (private)
replica = 192.168.1.102 (private)
2334, 7002
2334, 7002
7012
5500, 5580
Private
7012
7002, 7006,
7012, 7022
7002, 7006,
7012, 7022
DMZ
Primary Web Tier
Replica Web Tier
webtier-1 =10.10.1.101 (private)
123.0.0.101 (public)
webtier-2 =10.10.1.102 (private)
123.0.0.102 (public)
SSL-VPN
Inbound Ports (DMZ -> Private):
• webtier-1 -> primary:
7002, 7006, 7012, 7022
• webtier-2 -> replica:
7002, 7006, 7012, 7022
• sslvpn -> primary/replica:
5500/UDP, 5580
Outbound Ports (Private -> DMZ):
• primary -> webtier-1: 7012
• replica -> webtier-2: 7012
virtualhost =123.0.0.101, 123.0.0.102 (public)
DMZ
NAT Firewall
443
443
Internet
443
Inbound Ports (Internet -> DMZ)
• client -> webtier-n/virtualhost: 443
Outbound Ports (DMZ -> Internet):
• None
DNS round robin
Notes:
Internet
sslvpn.company.com
webtier1.company.com
© Copyright 2011 EMC Corporation. All rights reserved.
1.
One public IP address is required for each webtier server.
2.
Webtier hostnames must be published to your external DNS and
resolve to their respective public IP addresses:
• webtier-1.company.com: 123.0.0.101
• webtier-2.company.com: 123.0.0.102
• virtualhost.company.com: 123.0.0.101, 123.0.0.102 (using
DNS round robin)
3.
Configure your NAT firewall to map each public IP to its respective
internal IP :
• 123.0.0.101 (public) -> NAT -> 10.10.1.101 (private)
• 123.0.0.102 (public) -> NAT -> 10.10.1.102 (private)
71
virtualhost.company.com
Scenario 4c:Primary/Replica with Web Tiers
Load Balancer and Public IP addresses
Primary Appliance
Replica Appliance
primary = 192.168.1.101 (private)
replica = 192.168.1.102 (private)
2334, 7002
2334, 7002
7012
5500, 5580
Private
7012
7002, 7006,
7012, 7022
7002, 7006,
7012, 7022
Primary Web Tier
DMZ
Replica Web Tier
webtier-1 = 123.0.0.101 (public)
Inbound Ports (DMZ -> Private):
• webtier-1 -> primary:
7002, 7006, 7012, 7022
• webtier-2 -> replica:
7002, 7006, 7012, 7022
• sslvpn -> primary/replica:
5500/UDP, 5580
Outbound Ports (Private -> DMZ):
• primary -> webtier-1: 7012
• replica -> webtier-2: 7012
webtier-2 = 123.0.0.102 (public)
443 or 7023
443 or 7023
Load Balancer
SSL-VPN
lb_host = 123.0.0.103 (public)
443
443
DMZ
Inbound Ports (Internet -> DMZ)
• client -> webtier-n/lb_host: 443
Internet
Outbound Ports (DMZ -> Internet):
• None
Notes:
Internet
sslvpn.company.com
webtier1.company.com
© Copyright 2011 EMC Corporation. All rights reserved.
1.
One public IP address is required for each webtier server and for
the load balancer.
2.
Webtier and load balancer hostnames must be published to your
external DNS and resolve to their respective public IP addresses:
• webtier-1.company.com: 123.0.0.101
• webtier-2.company.com: 123.0.0.102
• lb_host.company.com:
123.0.0.103
3.
In AMX, set the virtual hostname to be the same as the hostname
of your load balancer (lb_host).
virtualhost.company.com
72