RSA Authentication Manager Express

1© Copyright 2011 EMC Corporation. All rights reserved.

RSA Authentication Manager ExpressTechnical Workshop

Dave Taku, CISSP – Product ManagerChris Crellin – Product Manager


Agenda10:00 Welcome

Session #110:10 – 10:40 Product Overview10:40 – 11:00 AMX Demo11:00 – 11:15 Sales Tools11:15– 11:45 Deep Dive: The RSA Risk

Engine11:45 – 12:30 Lunch

Session #212:30 – 13:00 RBA Integration13:00 – 13:30 Deployment Best

Practices13:30 – 14:00 Troubleshooting

14:00 Wrap Up


RSA Authentication: Innovation Timeline

Passwords Hardware tokens

Software tokens

SMS & text messaging

Understand the customer’s need to balanceCost Convenience Security

EnterpriseMore than 1,000 users

B2C ApplicationsMore than 10,000 users

Small & Mid-Size Organizations Fewer than 2,500 users

RSA Authentication Manager Express

Risk-Based Authentication

(B2C)

Convenient, user-friendly strong auth

with lower TCO


Authentication Market by the Numbers

12445

123456

1 Gartner Specialized SSL VPN Equipment, 20082 Forrester Enterprise And SMB Security Survey, North America And Europe, Q3 20083 http://igigi.baywords.com/rockyou-com-passwords-list/

Millions of SSL VPN users in 20121

Percent of companies still using passwords for remote access authentication2

Most commonly used password3


forRSA Authentication

Manager Express

Net New customers are the ideal


What We’ve HeardSecure Access for Mobility and Collaboration

Before Scenario

“Lack of confidence about who is remotely accessing information”

“Security Solutions are Complex and Expensive”

“Diverse end-user base results in varying requirements”

“Users struggle with cumbersome security mechanisms”

“Meeting and proving compliance is complex and time consuming”

Proven authentication technology

Convenient and user-friendly solution

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

SOLUTION

Cost-effective strong authentication that is stronger than a password, but easy to use for IT staff and end-users

Required Capabilities


Introducing Authentication Manager ExpressMulti-factor authentication with zero footprint

On-Demand Authentication

Easy to ManageAppliance Platform

Risk-Based Authentication


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


Risk-Based AuthenticationHow it Works

Web Browser

RSARisk Engine

Device Identificati

on

UserBehavior

PASS

FAIL

Protected ResourcesPAS

S

RISKY

Identity Challenge

?On-

Demand Tokencode

Challenge Questions Access

Denied

SSL VPN

OWA

SharePoint

Web Portals

Authentication Policy

Assurance Level

Activity Details


ManufacturingVendors accessing an Order Management System hosted by XenApp

GovernmentState and local agencies that must adhere to compliance regulations

Use Case: Web-Based Remote AccessFor Employees, Contractors, Partners and Clients

Employees & Contractors

Partners & Vendors

Clients

Employee MobilitySSL VPN and web-based email for employees & contractors

HealthcareCommunity Health Clinics eliminating the “token necklace” for medical staff

Professional ServicesA Law Firm that exchanges sensitive information with clients using an online portal

SSL VPN

OWA

SharePoint

Web Portals


Customer ChallengesRelated 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


Healthcare

Finance Retail

Manufacturing

Government

Services

Hospitals

Clinics

Insurance

Local banks

Credit unions

Traditional

Online

Industrial

Biotech

Devices

Local governmen

t

Transportation

Defense

Consulting

Technology

Accounting

SSL VPNs, Citrix, OWA, SharePoint, web portals

Wins across all verticals and use cases


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.


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.


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


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.


AMX Demo


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

applianceYears 4 and 5 optional and additional

• Same as the SecurID Appliance 130 (1U hardened Linux OS)

• Scalable up to 2,500 users

• Primary + Replica (1)

RSA Authentication Appliance 130

AMX Web Tier Server

• Required for RBA deployments

• Installs on a separate Windows or Linux server (not included)

• Included with all AMX appliance orders


AMX 1.0 vs. AM 7.1Authentication Manager Express

1.0RSA Authentication Manager 7.1

DEPLOYMENT

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

USE CASES

Authentication methods Risk basedOn-demand (SMS or email)

SecurID (hardware & software tokens)On-demand (SMS or email)

Applications SSL VPNsWeb-based applications

VPNs (SSL and IPSec)Web-based applicationsOS (Windows, Linux, etc.)Wireless, Routers, legacy, & more…

COMPONENTS

Platform RSA Authentication Appliance 130 Software: Widows, Linux, Solaris, VMwareRSA 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 JSDSRead Only or R/W

Web Tier DMZ deployment of RBA and Self Service

N/A


Deal Qualification Checklist• Use to quickly

evaluate AMX customer fit

– Green: No Issues– Yellow: Caution– Red: Stop

• Review recommendations for flagged items


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


Additional Training Opportunities• RSA Educational Services (Online Training)

– SALES: Introduction to Selling RSA Authentication Manager Express

– TECHNICAL: What’s New: RSA Authentication Manager Express


Understanding the RSA Risk Engine


The RSA Risk Engine• Proven sophisticated risk engine

– Same risk engine as Adaptive Auth– Protects 250+ million online

identities• 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

RSA Risk Engine


The RSA Risk Engine

Web Browser

RSARisk Engine

Device Identificati

on

UserBehavior

PASS

FAIL

Protected ResourcesPAS

S

RISKY

Identity Challenge

?On-

Demand Tokencode

Challenge Questions Access

Denied

SSL VPN

OWA

SharePoint

Web Portals

Authentication Policy

Assurance Level

Activity Details


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.


Device IdentificationDevice 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.


Device IdentificationNetwork 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


Device IdentificationDevice 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


Device IdentificationPutting 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.

User Profile

UsercookieSW fingerprintuser-agent

recently used cookies

recently used IP class B

Match with existing attributes in profile?

Collective statisticsWhat’s the probability of a

random match ?

cookie

IP class B

user-agent

124.55

MSIE 5.5

...

%

0%

3%

1.5%

ValueAttribute

üIP address

recently used user-agents

ürecently used SW fingerprints

ü match

match

match

no match

IP class B + user-agent combination

... 0.1%


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


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


• Assurance Level: The degree of confidence associated with each user authentication attempt

• 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

Assurance Levels

Strong Device Match

Risky UserBehavior

Increases Assurance

Decreases Assurance


Identifying the Key Assurance Level Contributors for each authentication attemptOverall 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


• 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

Selecting a Minimum Assurance Level


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


• Enables a seamless migration of users from passwords to RBA without pre-provisioning or other administrator intervention

• During silent collection, the risk engine:– Passively monitors user authentications attempts– Updates its risk model based on collected profile

and behavioral data– Automatically registers user devices– Does NOT challenge high risk users

• If a user achieves the minimum assurance threshold they are prompted to complete the self-enrollment process

Silent Collection


Silent CollectionPros and ConsPros

– 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


Lunch


Agenda10:00 Welcome

Session #110:10 – 10:40 Product Overview10:40 – 11:00 AMX Demo11:00 – 11:15 Sales Tools11:15– 11:45 Deep Dive: The RSA Risk

Engine11:45 – 12:30 Lunch

Session #212:30 – 13:00 RBA Integration13:00 – 13:30 Deployment Best

Practices13:30 – 14:00 Troubleshooting

14:00 Wrap Up


AMX Integration


On-Demand Authentication Flow

SSL-VPN

AMX Appliance

Secu

rID

Agen

t

DMZInternet

1. Connect to SSL-VPN

2. Validate PIN

4. Access Granted Protected

Resources

Intranet

3. Validate On-Demand tokencode

2. Send On-Demand tokencode


Risk-Based Authentication Flow

AMX WebTier

SSL-VPN

AMX Appliance

Secu

rID

Agen

t

DMZInternet


2. RBA integration script redirects the browser to

the AMX web tier 3. Authenticate user

RBA ServiceLogin Page

(w/RBA script)

4. Risk Assessment(challenge if necessary)

5. Return “auth artifact”

6. Redirect to SSL VPN with

artifact 7. Validate artifact using SecurID APIs


Resources

Intranet


Generating an RBA Integration Script

1. Configure authentication agent2. Select third-party product from “Integration Javascript” drop down3. Download customized integration script (am_integration.js )4. Follow Implementation Guide to apply the script to the third-party product


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 out-of-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

http://www.rsasecured.com/

http://edelivery.rsasecurity.com/patches/rsa_amx/10/custom_rba_integration.zip


RSA Secured Partner SolutionsPlug-and-Play Integration and Certified Interoperability

Visit www.rsasecured.com to view all supported solutions or to request new product integrations

• 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

http://www.rsasecured.com/


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

clientNote: ODA does not require an integration template since ODA is natively supported by SecurID authentication agents


Deployment Best Practices


Deployment Best Practices• Confirm the use case is a good fit for AMX

– Using the Deal Qualification Checklist• Plan in advance for the network deployment

– 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.


• 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

Deal Qualification: Common Deal Breakers


AMX Deployments ScenariosFrom the AMX Planning Guide1. Primary Only

– Unprotected ODA deployments2. Primary + Replica Server

– Redundant ODA deployments3. Primary + Web Tier

– Unprotected RBA deployments4. Primary + Replica + Web Tier (x2)

– Redundant RBA deployments


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!


Typical Web Tier Server Deployment


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


Confused?Use the AMX Deployment Checklist


Troubleshooting Risk-Based Authentication


Troubleshooting RBA• Review the four stages of an RBA authentication

1. Redirect to the web tier2. Primary authentication3. 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?


Problem: Redirect to Web Tier

AMX WebTier

SSL-VPN

AMX Appliance

Secu

rID

Agen

t

DMZInternet





(w/RBA script)






Resources

Intranet


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


Problem: Primary Authentication Failing

AMX WebTier

SSL-VPN

AMX Appliance

Secu

rID

Agen

t

DMZInternet



the AMX web tier

3. Authenticate user


(w/RBA script)






Resources

Intranet


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?


Problem: RBA Challenge Failing

AMX WebTier

SSL-VPN

AMX Appliance

Secu

rID

Agen

t

DMZInternet





(w/RBA script)






Resources

Intranet


Troubleshooting RBA Challenge• SQ: Answers must be exact match• ODA: Troubleshoot like Authentication Manager 7.1


Problem: Artifact is Generated but Never Returned to AMX

AMX WebTier

SSL-VPN

AMX Appliance

Secu

rID

Agen

t

DMZInternet





(w/RBA script)






Resources

Intranet


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?


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.


THANK YOU


Scenario 2a: Primary Instance with Web TierUsing a Public IP address

Inbound Ports (DMZ -> Private): • webtier -> amx:

7002, 7006, 7012, 7022

• sslvpn -> amx: 5500/UDP, 5580

Outbound Ports (Private -> DMZ):• amx -> webtier: 7012

Inbound Ports (Internet -> DMZ)• client -> webtier: 443

Outbound Ports (DMZ -> Internet):

• None

70127002, 7006, 7012, 7022

PrivateDMZ

DMZInternet

Notes: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.

AMX Applianceamx = 192.168.1.101 (private)

sslvpn.company.com

Web Tierwebtier = 123.0.0.101 (public)

5500, 5580

webtier.company.com

Internet

443

SSL-VPN


Scenario 2b: Primary Instance with Web Tier Using a NAT firewall

Inbound Ports (DMZ -> Private): • webtier -> amx:

7002, 7006, 7012, 7022

• sslvpn -> amx: 5500/UDP, 5580

Outbound Ports (Private -> DMZ):• amx -> webtier: 7012

Inbound Ports (Internet -> DMZ)• client -> webtier: 443

Outbound Ports (DMZ -> Internet):

• None

70127002, 7006, 7012, 7022

PrivateDMZ

DMZInternet

Notes: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.

AMX Applianceamx = 192.168.1.101 (private)

sslvpn.company.com

Web Tierwebtier = 10.10.1.101 (private)

123.0.0.101 (public)

5500, 5580

webtier.company.com

Internet

SSL-VPN

443

NAT Firewall


Scenario 4a: Primary/Replica with Web TiersDNS round robin and Public IP addresses

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

Inbound Ports (Internet -> DMZ)• client -> webtier-n/virtualhost:

443Outbound Ports (DMZ -> Internet):

• None

Replica Appliancereplica = 192.168.1.102 (private)

Replica Web Tierwebtier-2 = 123.0.0.102 (public)

7012 70127002, 7006, 7012, 7022

7002, 7006, 7012, 7022

PrivateDMZ

DMZInternet

Notes: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)

Primary Applianceprimary = 192.168.1.101 (private)

Primary Web Tierwebtier-1 = 123.0.0.101 (public)

5500, 5580

DNS round robin

443 443

virtualhost.company.comwebtier-1.company.com

Internet

443

virtualhost =123.0.0.101, 123.0.0.102 (public)

2334, 7002

2334, 7002

sslvpn.company.com

SSL-VPN


Scenario 4b: Primary/Replica with Web TiersDNS round robin and NAT

Inbound Ports (Internet -> DMZ)• client -> webtier-n/virtualhost:


• None


7002, 7006, 7012, 7022

• webtier-2 -> replica: 7002, 7006, 7012, 7022



7012 70127002, 7006, 7012, 7022

7002, 7006, 7012, 7022

PrivateDMZ

DMZInternet

Notes: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 :




Replica Web Tierwebtier-2 = 10.10.1.102 (private)

123.0.0.102 (public)


Primary Web Tierwebtier-1 = 10.10.1.101 (private)

123.0.0.101 (public)

5500, 5580


Internet

NAT Firewall

DNS round robin

443443 443

virtualhost =123.0.0.101, 123.0.0.102 (public)

2334, 7002

2334, 7002

SSL-VPN

sslvpn.company.com


Scenario 4c: Primary/Replica with Web TiersLoad Balancer and Public IP addresses

Inbound Ports (Internet -> DMZ)• client -> webtier-n/lb_host:


• None


7002, 7006, 7012, 7022

• webtier-2 -> replica: 7002, 7006, 7012, 7022



443

7012 70127002, 7006, 7012, 7022

7002, 7006, 7012, 7022

PrivateDMZ

DMZInternet

Notes: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).

Load Balancerlb_host = 123.0.0.103 (public)

443 or 7023 443 or 7023


Replica Web Tierwebtier-2 = 123.0.0.102 (public)


Primary Web Tierwebtier-1 = 123.0.0.101 (public)

5500, 5580


443

Internet

2334, 7002

2334, 7002

SSL-VPN

sslvpn.company.com

RSA Authentication Manager Express

Documents

Transcript of RSA Authentication Manager Express