Administration Guide

Administration Guide
Secure Access
Administration Guide
Release
7.0
Published: 2011-10-13
Part Number: , Revision 2
Copyright © 2011, Juniper Networks, Inc.
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
This product includes the Envoy SNMP Engine, developed by Epilogue Technology, an Integrated Systems Company. Copyright © 1986-1997,
Epilogue Technology Corporation. All rights reserved. This program and its documentation were developed at private expense, and no part
of them is in the public domain.
This product includes memory allocation software developed by Mark Moraes, copyright © 1988, 1989, 1993, University of Toronto.
This product includes FreeBSD software developed by the University of California, Berkeley, and its contributors. All of the documentation
and software included in the 4.4BSD and 4.4BSD-Lite Releases is copyrighted by the Regents of the University of California. Copyright ©
1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994. The Regents of the University of California. All rights reserved.
GateD software copyright © 1995, the Regents of the University. All rights reserved. Gate Daemon was originated and developed through
release 3.0 by Cornell University and its collaborators. Gated is based on Kirton’s EGP, UC Berkeley’s routing daemon (routed), and DCN’s
HELLO routing protocol. Development of Gated has been supported in part by the National Science Foundation. Portions of the GateD
software copyright © 1988, Regents of the University of California. All rights reserved. Portions of the GateD software copyright © 1991, D.
L. S. Associates.
This product includes software developed by Maker Communications, Inc., copyright © 1996, 1997, Maker Communications, Inc.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United
States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other
trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify,
transfer, or otherwise revise this publication without notice.
Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are
owned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312,
6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.
Secure Access Administration Guide
Revision History
February 2010—Integrate Version 7.0 new features
The information in this document is current as of the date listed in the revision history.
END USER LICENSE AGREEMENT
The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks
software. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at
http://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to the terms and conditions
of that EULA.
ii
Copyright © 2011, Juniper Networks, Inc.
Abbreviated Table of Contents
Front Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii
Part 1
Getting Started
Chapter 1
Initial Verification and Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Chapter 2
Introduction to the SA Series Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Part 2
Access Management Framework
Chapter 3
General Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Chapter 4
User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Chapter 5
Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Chapter 6
Virtual Desktop Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Chapter 7
Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Chapter 8
Authentication and Directory Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Chapter 9
Authentication Realms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Chapter 10
Sign-In Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Chapter 11
Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Chapter 12
Synchronizing User Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Part 3
Endpoint Defense
Chapter 13
Host Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Chapter 14
Cache Cleaner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Part 4
Remote Access
Chapter 15
Hosted Java Applets Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Chapter 16
Citrix Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Chapter 17
Lotus iNotes Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Chapter 18
Microsoft OWA Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Chapter 19
Microsoft Sharepoint Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Chapter 20
Web Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Chapter 21
File Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Chapter 22
Secure Application Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Chapter 23
Telnet/SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Chapter 24
Terminal Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Copyright © 2011, Juniper Networks, Inc.
iii
Secure Access Administration Guide
Chapter 25
Secure Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Chapter 26
Email Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Chapter 27
Network Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
Part 5
System Management
Chapter 28
General System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Chapter 29
Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Chapter 30
System Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Chapter 31
Logging and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
Chapter 32
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
Chapter 33
Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Chapter 34
Delegating Administrator Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863
Chapter 35
Instant Virtual System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873
Chapter 36
SA Series Appliance and IDP Interoperability . . . . . . . . . . . . . . . . . . . . . . . . 927
Part 6
System Services
Chapter 37
SA Series Appliance Serial Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939
Chapter 38
Customizable Admin and End-User UIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945
Chapter 39
SA6000 Series Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947
Chapter 40
SA4500 and SA6500 Series Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
Chapter 41
Secure Access FIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
Chapter 42
SA4500 and SA6500 FIPS Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
Chapter 43
Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
Chapter 44
Multi-Language Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
Chapter 45
Handheld Devices and PDAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
Chapter 46
Using IKEv2 with the SA Series Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Chapter 47
Writing Custom Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005
Part 7
Index
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027
iv
Copyright © 2011, Juniper Networks, Inc.
Table of Contents
Front Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii
Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii
Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiv
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiv
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxv
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxv
Part 1
Getting Started
Chapter 1
Initial Verification and Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Verifying User Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Creating a Test Scenario to Learn SA Series Appliance Concepts and Best
Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Defining a User Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Defining a Resource Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Defining an Authentication Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Defining an Authentication Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Defining a Sign-In Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Using the Test Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Default Settings for Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Chapter 2
Introduction to the SA Series Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
SA Series Solution Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Securing Traffic With SA Series Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authenticating Users With Existing Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Fine-Tuning Access to the SA Series SSL VPN Appliance and the Resources It
Intermediates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Creating a Seamless Integration Between the SA Series SSL VPN Appliance and
the Resources It Intermediates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Protecting Against Infected Computers and Other Security Concerns . . . . . . . . . . 21
Ensuring Redundancy in the SA Series Environment . . . . . . . . . . . . . . . . . . . . . . . 22
Making the SA Series Interface Match My Company’s Look-and-Feel . . . . . . . . . 22
Enabling Users on a Variety of Computers and Devices to Use the SA Series SSL
VPN Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Providing Secure Access for My International Users . . . . . . . . . . . . . . . . . . . . . . . . 23
Configuring the SA Series SSL VPN Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Network and Security Manager and the Infranet Controller . . . . . . . . . . . . . . . . . . 25
How the SA Series SSL VPN Appliance and NSM communicate . . . . . . . . . . 25
Available Services and Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . 26
DMI Communication with the SA Series SSL VPN Appliance . . . . . . . . . . . . . 27
Configuring the SA Series SSL VPN Appliance for the Initial DMI Connection . . . . 27
Copyright © 2011, Juniper Networks, Inc.
v
Secure Access Administration Guide
Managing Large Binary Data Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Uploading and Linking Large Binary Data Files With NSM . . . . . . . . . . . . . . . . . . . 30
Importing Custom Sign-In Pages With NSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Importing Antivirus LiveUpdate Settings With NSM . . . . . . . . . . . . . . . . . . . . . . . . 32
Importing Endpoint Security Assessment Plug-in (ESAP) Packages With
NSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Uploading a Third-Party Host Checker Policy With NSM . . . . . . . . . . . . . . . . . . . . 34
Linking to a Third-Party Host Checker Policy Shared Object With NSM . . . . . . . . 35
Linking to a Secure Virtual Workspace Wallpaper Image Shared Object With
NSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Importing Hosted Java Applets With NSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Importing a Custom Citrix Client .cab File With NSM . . . . . . . . . . . . . . . . . . . . . . . 37
Junos Pulse Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Session Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Location Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Security Certificates on Junos Pulse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Platform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Downloading Junos Pulse to Endpoints with Security Software Installed . . . 39
Configuring the Junos Pulse Client for a Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
The Client Installer Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Junos Pulse Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Junos Pulse Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Junos Pulse Client Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Default Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Client Connection Set Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Creating a Client Connection Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Configuring Connection Rules for Location Awareness . . . . . . . . . . . . . . . . . . . . . 48
Junos Pulse Component Set Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Creating a Client Component Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Creating an Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Part 2
Access Management Framework
Chapter 3
General Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Access Management Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Policies, Rules & Restrictions, and Conditions Overview . . . . . . . . . . . . . . . . . . . . 58
Accessing Authentication Realms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Accessing User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Accessing Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Policies, Rules & Restrictions, and Conditions Evaluation . . . . . . . . . . . . . . . . . . . 60
Dynamic Policy Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Understanding Dynamic Policy Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Understanding Standard Policy Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Enabling Dynamic Policy Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Specifying Source IP Access Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Specifying Source IP Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Specifying Browser Access Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Specifying Certificate Access Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
vi
Copyright © 2011, Juniper Networks, Inc.
Table of Contents
Specifying Password Access Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Specifying Session Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
IF-MAP Federation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
IF-MAP Federation Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
IF-MAP Federation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
IF-MAP Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Task Summary: Configuring IF-MAP Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Configuring IF-MAP Server Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Configuring the IF-MAP Federation Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
IF--MAP Federation Network Timing Considerations . . . . . . . . . . . . . . . . . . . . . . . 78
Session-Export and Session-Import Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Default Session-Export and Session-Import Policy Action . . . . . . . . . . . . . . . 81
Advanced Session-Export and Session-Import Policies . . . . . . . . . . . . . . . . . 81
Configuring Session-Export Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Session-Import Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Troubleshooting the IF-MAP Federation Network . . . . . . . . . . . . . . . . . . . . . . . . . 84
Viewing Active Users on the IF-MAP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Trusted Server List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Administrator and User Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
White List Flow Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Chapter 4
User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
User Roles Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
User Role Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Permissive Merge Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Configuration of User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Configuring General Role Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Role Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Specifying Role-Based Source IP Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Specifying Role Session Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Customizing the SA Series SSL VPN Appliance Welcome Page . . . . . . . . . . . . . . 98
Defining Default Options for User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Customizing Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Customizing UI Views for User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Chapter 5
Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Resource Profile Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Defining Resource Profile Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Defining Resource Profile Autopolicies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Defining Resource Profile Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Defining Resource Profile Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Resource Profile Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Chapter 6
Virtual Desktop Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Virtual Desktop Resource Profile Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Configuring a Citrix XenDesktop Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . 120
Configuring a VMware View Manager Resource Profile . . . . . . . . . . . . . . . . . . . . . 121
Defining Bookmarks for a Virtual Desktop Profile . . . . . . . . . . . . . . . . . . . . . . . . . 122
Configuring the Client Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Copyright © 2011, Juniper Networks, Inc.
vii
Secure Access Administration Guide
Connecting to the Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Chapter 7
Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Resource Policy Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Specifying Resources for a Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
General Notes About the Canonical Formats . . . . . . . . . . . . . . . . . . . . . . . . 129
Specifying Server Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Resource Policy Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Creating Detailed Rules for Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Writing a Detailed Rule for Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Customizing Resource Policy UI Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Chapter 8
Authentication and Directory Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
About Authentication and Directory Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Task Summary: Configuring Authentication Servers . . . . . . . . . . . . . . . . . . . . . . . 139
About Anonymous Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Anonymous Server Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Defining an Anonymous Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Using an RSA ACE/Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Defining an ACE/Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Using Active Directory or NT Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Defining an Active Directory or Windows NT Domain Server Instance . . . . . . . . . 146
Multi-Domain User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Windows 2000 and Windows 2003 Multi-Domain Authentication . . . . . . . 148
Windows NT4 Multi-Domain Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 148
NT User Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Using the Kerberos Debugging Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Active Directory and NT Group Lookup Support . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Active Directory Lookup Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
NT4 Group Lookup Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Certificate Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Configuring a Certificate Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Using an LDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Defining an LDAP Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Configuring LDAP Search Attributes for Meeting Creators . . . . . . . . . . . . . . . . . . 156
Enabling LDAP Password Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Enabling LDAP Password Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Supported LDAP Directories and Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Troubleshooting LDAP Password Management on the SA Series
Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Using a Local Authentication Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Defining a Local Authentication Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Creating User Accounts on a Local Authentication Server . . . . . . . . . . . . . . . . . . 164
Configuring an NIS Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Configuring a RADIUS Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
User Experience for RADIUS Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Using CASQUE Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Defining an SA Series RADIUS Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Enabling RADIUS Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
viii
Copyright © 2011, Juniper Networks, Inc.
Table of Contents
General RADIUS Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Understanding Clustering Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Understanding the Interim Update Feature . . . . . . . . . . . . . . . . . . . . . . . . . . 182
eTrust SiteMinder Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Authentication Using Various Authentication Schemes . . . . . . . . . . . . . . . . 186
Determining the Username . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Configuring SiteMinder to Work with the SA Series SSL VPN Appliance . . . . . . . 187
Configuring the SiteMinder Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Creating a SiteMinder Authentication Scheme for the SA Series SSL VPN
Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Creating a SiteMinder Domain for the SA Series SSL VPN Appliance . . . . . . . . . . 191
Creating a SiteMinder Realm for the SA Series SSL VPN Appliance . . . . . . . . . . . 191
Creating a Rule/Response Pair to Pass Usernames to the SA Series SSL VPN
Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Configuring the SA Series SSL VPN Appliance to Work with SiteMinder . . . . . . . 193
Using SiteMinder User Attributes for Secure Access Role Mapping . . . . . . . . . . . 202
Defining a SiteMinder Realm for Automatic Sign-In . . . . . . . . . . . . . . . . . . . . . . . 203
Debugging SiteMinder and Secure Access Issues . . . . . . . . . . . . . . . . . . . . . . . . 204
Configuring a SAML Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Using the Artifact Profile and POST Profile . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Using the Artifact Profile Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Using the POST Profile Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Understanding Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Creating a new SAML Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Configuring the SAML Server Instance to Use an Artifact Profile . . . . . . . . . . . . . 210
Configuring the SAML Server Instance to Use the POST Profile . . . . . . . . . . . . . . 211
Chapter 9
Authentication Realms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Authentication Realm Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Creating an Authentication Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Defining Authentication Access Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Role Mapping Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Specifying Role Mapping Rules for an Authentication Realm . . . . . . . . . . . . . . . . 217
Using the LDAP Server Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Customizing User Realm UI Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Chapter 10
Sign-In Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
About Sign-In Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Task Summary: Configuring Sign In Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
About Configuring Sign In Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Configuring User Sign In Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Defining authorization-only access policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Defining Meeting Sign-In Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Configuring Sign-In pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Configuring Standard Sign-In Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Copyright © 2011, Juniper Networks, Inc.
ix
Secure Access Administration Guide
Chapter 11
Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
About Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
About Multiple Sign-In Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Task Summary: Configuring Multiple Authentication Servers . . . . . . . . . . . . . . . 239
Task Summary: Enabling SSO to Resources Protected by Basic
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Task Summary: Enabling SSO to Resources Protected by NTLM . . . . . . . . . . . . 240
Multiple Sign-In Credentials Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Configuring SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Configuring SAML SSO Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Creating a Single Sign-On POST Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Creating a SAM Access Control Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . 256
Creating a Trust Relationship Between SAML-Enabled Systems . . . . . . . . . . . . 259
Configuring Trusted Application URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Configuring an Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Configuring Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Configuring SSO Transactions: Artifact Profile . . . . . . . . . . . . . . . . . . . 260
Configuring SSO Transactions: POST Profile . . . . . . . . . . . . . . . . . . . . . 261
Configuring Access Control Transactions . . . . . . . . . . . . . . . . . . . . . . . . 261
Configuring User Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Chapter 12
Synchronizing User Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
About User Record Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Enabling User Record Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Configuring the User Record Synchronization Authentication Server . . . . . . . . . 266
Configuring the User Record Synchronization Server . . . . . . . . . . . . . . . . . . . . . . 266
Configuring the User Record Synchronization Client . . . . . . . . . . . . . . . . . . . . . . 267
Configuring the User Record Synchronization Database . . . . . . . . . . . . . . . . . . . 268
Part 3
Endpoint Defense
Chapter 13
Host Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Host Checker and Trusted Network Computing . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Task Summary: Configuring Host Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Creating Global Host Checker Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Enabling Enhanced Endpoint Security Functionality . . . . . . . . . . . . . . . . . . . . . . 278
Enabling Connection Control Host Checker Policies (Windows Only) . . . . . . . . 280
Creating and Configuring New Client-side Host Checker Policies . . . . . . . . . . . . 281
Checking for Third-Party Applications Using Predefined Rules (Windows
Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Configuring a Predefined Antivirus Rule with Remediation Options . . . . . . . . . . 284
Configuring a Predefined Firewall Rule with Remediation Options (Windows
Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Configuring a Pre-defined AntiSpyware Rule (Windows Only) . . . . . . . . . . . . . . 287
Configuring Virus Signature Version Monitoring and Patch Assessment Data
Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
x
Copyright © 2011, Juniper Networks, Inc.
Table of Contents
Specifying Customized Requirements Using Custom Rules . . . . . . . . . . . . . . . . 290
Using a Wildcard or Environment Variable in a Host Checker Rule . . . . . . . . . . . 295
Configuring Patch Assessment Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Using a System Management Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Configuring Patch Assessment Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Using Third-party Integrity Measurement Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 301
Configuring a Remote IMV Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Implementing the Third-Party IMV Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Implementing Host Checker Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Executing Host Checker Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
About Host Checker Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Remediating Host Checker Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
General Host Checker Remediation User Experience . . . . . . . . . . . . . . . . . . 314
Configuring General Host Checker Remediation . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Upgrading the Endpoint Security Assessment Plug-In . . . . . . . . . . . . . . . . . . . . . 317
Defining Host Checker Pre-Authentication Access Tunnels . . . . . . . . . . . . . . . . . 319
Specifying Host Checker Pre-Authentication Access Tunnel Definitions . . . . . . 320
Specifying General Host Checker Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Specifying Host Checker Installation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Using Host Checker with the GINA Automatic Sign-In Function . . . . . . . . . . . . . 326
Installing Host Checker Automatically or Manually . . . . . . . . . . . . . . . . . . . . . . . 327
Using Host Checker Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Configuring Host Checker for Windows Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Requiring Junos Pulse Mobile Security for SA Series Gateway Access . . . . . 329
Using Proxy Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Enabling the Secure Virtual Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Secure Virtual Workspace Restrictions and Defaults . . . . . . . . . . . . . . . . . . . 331
Configuring the Secure Virtual Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Defining Secure Virtual Workspace Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 332
Defining a Secure Virtual Workspace Application Policy . . . . . . . . . . . . . . . . . . . 334
Defining a Secure Virtual Workspace Security Policy . . . . . . . . . . . . . . . . . . . . . . 335
Defining Secure Virtual Workspace Environment Options . . . . . . . . . . . . . . . . . . 336
Defining Secure Virtual Workspace Remediation Policy . . . . . . . . . . . . . . . . . . . . 337
Chapter 14
Cache Cleaner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
About Cache Cleaner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Setting Global Cache Cleaner Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Implementing Cache Cleaner Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Specifying Cache Cleaner Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
About Cache Cleaner Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Part 4
Remote Access
Chapter 15
Hosted Java Applets Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
About Hosted Java Applet Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Task Summary: Hosting Java Applets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Uploading Java Applets to Secure Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Signing Uploaded Java Applets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Creating HTML Pages That Reference Uploaded Java Applets . . . . . . . . . . . . . . 350
Copyright © 2011, Juniper Networks, Inc.
xi
Secure Access Administration Guide
Accessing Java Applet Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Creating a Hosted Java Applet Resource Profile . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Configuring Hosted Java Applet Resource Profile Bookmarks . . . . . . . . . . . . . . . 352
Creating Hosted Java Applets Bookmarks Through the User Roles Page . . . . . . 354
Required Attributes for Uploaded Java Applets . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Required Parameters for Uploaded Java Applets . . . . . . . . . . . . . . . . . . . . . . . . . 356
Use case: Creating a Citrix JICA 9.5 Java Applet Bookmark . . . . . . . . . . . . . . . . . 357
Chapter 16
Citrix Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
About Citrix Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Comparing Secure Access Access Mechanisms for Configuring Citrix . . . . . . . . 362
Creating Resource Profiles Using Citrix Web Applications . . . . . . . . . . . . . . . . . . 365
Chapter 17
Lotus iNotes Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Creating Resource Profiles Using the Lotus iNotes Template . . . . . . . . . . . . . . . . 371
Chapter 18
Microsoft OWA Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Creating Resource Profiles Using the Microsoft OWA Template . . . . . . . . . . . . . 375
Chapter 19
Microsoft Sharepoint Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Creating Resource Profiles Using the Microsoft Sharepoint Template . . . . . . . . 379
Chapter 20
Web Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Web Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Task summary: Configuring the Web Rewriting Feature . . . . . . . . . . . . . . . . . . . 384
Web Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Remote SSO Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Passthrough Proxy Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Task Summary: Configuring Passthrough Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Examples of Using Passthrough Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Creating a Custom Web Application Resource Profile . . . . . . . . . . . . . . . . . . . . . 391
Defining a Web Access Control Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Defining a Single Sign-On Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Defining a Caching Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Defining a Java Access Control Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Defining a Rewriting Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Defining a Web Compression Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Defining Web Resource Profile Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Specifying Web Browsing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Resource Policy Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Writing a Web Access Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Defining Single Sign-On Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
About Basic, NTLM and Kerberos Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Writing the Basic, NTLM and Kerberos Resources . . . . . . . . . . . . . . . . . . . . . . . . 418
Writing a Basic Authentication, NTLM or Kerberos Intermediation Resource
Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Writing a Remote SSO Form POST Resource Policy . . . . . . . . . . . . . . . . . . . . . . 424
Writing a Remote SSO Headers/Cookies Resource Policy . . . . . . . . . . . . . . . . . . 426
Writing a Web Caching Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
About OWA and Lotus Notes Caching Resource Policies . . . . . . . . . . . . . . . . . . 430
Specifying General Caching Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
xii
Copyright © 2011, Juniper Networks, Inc.
Table of Contents
Writing a Java Access Control Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Writing a Java Code Signing Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Creating a Selective Rewriting Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Creating a Passthrough Proxy Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Creating a Custom Header Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Creating an ActiveX Parameter Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . 440
Restoring the Default SA Series Appliance ActiveX Resource Policies . . . . . . . . 442
Creating Rewriting Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Writing a Web Compression Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Defining an OWA Compression Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . 448
Writing a Web Proxy Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Specifying Web Proxy Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Writing An HTTP 1.1 Protocol Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Creating a Cross Domain Access Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Defining Resource Policies: General Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Managing Resource Policies: Customizing UI Views . . . . . . . . . . . . . . . . . . . . . . . 453
Chapter 21
File Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
File Rewriting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Creating a File Rewriting Resource Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Creating a File Access Control Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Creating a File Compression Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Creating a Single Sign-On Autopolicy (Windows Only) . . . . . . . . . . . . . . . . . . . . 459
Configuring File Resource Profile Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Creating Windows File Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Creating Advanced Bookmarks to Windows Resources . . . . . . . . . . . . . . . . . . . 463
Creating Windows Bookmarks that Map to LDAP Servers . . . . . . . . . . . . . . . . . 464
Defining General Windows File Browsing Options . . . . . . . . . . . . . . . . . . . . . . . . 464
Writing a File Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Windows File Resources Canonical Format . . . . . . . . . . . . . . . . . . . . . . . . . 465
Writing a Windows Access Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Writing a Windows SSO Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Writing a Windows Compression Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . 468
Defining General File Writing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Creating Unix File Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Creating Advanced Bookmarks to UNIX Resources . . . . . . . . . . . . . . . . . . . . . . . . 471
Defining General Unix File Browsing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Defining UNIX/NFS File Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Canonical Format: UNIX/NFS File Resources . . . . . . . . . . . . . . . . . . . . . . . . 473
Writing UNIX/NFS Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Writing a Unix/NFS Compression Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . 474
Defining General UNIX/NFS File Writing Options . . . . . . . . . . . . . . . . . . . . . . . . . 475
Chapter 22
Secure Application Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Secure Application Manager Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Task Summary: Configuring WSAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Launching Network Connect During a WSAM Session . . . . . . . . . . . . . . . . . . . . . 479
Debugging WSAM Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
About WSAM Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Creating WSAM Client Application Resource Profiles . . . . . . . . . . . . . . . . . . . . . . 481
Copyright © 2011, Juniper Networks, Inc.
xiii
Secure Access Administration Guide
Creating WSAM Destination Network Resource Profiles . . . . . . . . . . . . . . . . . . . 482
Specifying Applications and Servers for WSAM to Secure . . . . . . . . . . . . . . . . . 483
Specifying Applications that Need to Bypass WSAM . . . . . . . . . . . . . . . . . . . . . 485
Specifying Role-Level WSAM Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Specifying Application Servers that Users can Access . . . . . . . . . . . . . . . . . . . . 488
Specifying Resource Level WSAM Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Using the WSAM Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
JSAM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Task Summary: Configuring JSAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Using JSAM for Client/Server Communications . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Assigning IP Loopback Addresses to Servers . . . . . . . . . . . . . . . . . . . . . . . . 497
Using Static Loopback Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
IP Loopback Address Considerations When Merging Roles . . . . . . . . . . . . . 499
Resolving Host Names to Localhost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Configuring a PC that Connects to the SA Series Appliance Through a Proxy
Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Using JSAM for Client/Server Communications . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Assigning IP Loopback Addresses to Servers . . . . . . . . . . . . . . . . . . . . . . . . 502
Using Static Loopback Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
IP Loopback Address Considerations When Merging Roles . . . . . . . . . . . . . 504
Resolving Host Names to Localhost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Determining the SA Series Appliance-Assigned Loopback Address . . . . . . . . . . 505
Using JSAM for Client/Server Communications . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Assigning IP Loopback Addresses to Servers . . . . . . . . . . . . . . . . . . . . . . . . 508
Using Static Loopback Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
IP Loopback Address Considerations When Merging Roles . . . . . . . . . . . . . 509
Resolving Host Names to Localhost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
Configuring External DNS Servers and User Machines . . . . . . . . . . . . . . . . . . . . . 511
JSAM Linux and Macintosh Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Standard Application Support: MS Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Client/Server Communication Using JSAM . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Standard Application Support: Lotus Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Client/Server Communication Using JSAM . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Configuring the Lotus Notes Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Standard Application Support: Citrix Web Interface for MetaFrame (NFuse
Classic) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Enabling Citrix Published Applications on the Citrix Native Client . . . . . . . . . . . . 517
Enabling Citrix Secure Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
Creating a JSAM Application Resource Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Specifying Applications for JSAM to Secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Specifying Role Level JSAM Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Automatically Launching JSAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
Specifying Application Servers that Users Can Access . . . . . . . . . . . . . . . . . . . . 530
Specifying Resource Level JSAM Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
xiv
Copyright © 2011, Juniper Networks, Inc.
Table of Contents
Chapter 23
Telnet/SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
About Telnet/SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Task summary: Configuring the Telnet/SSH Feature . . . . . . . . . . . . . . . . . . . . . . 534
Creating a Telnet/SSH Resource Profile: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Associating Bookmarks with Telnet/SSH Resource Profiles . . . . . . . . . . . . . . . . 536
Configuring General Telnet/SSH Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Writing a Telnet/SSH Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
Chapter 24
Terminal Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
About Terminal services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
Terminal Services User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
Task Summary: Configuring the Terminal Services Feature . . . . . . . . . . . . . . . . . 545
Terminal Services Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Configuring Citrix to Support ICA Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 548
About Terminal Services Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
Configuring a Windows Terminal Services Resource Profile . . . . . . . . . . . . . . . . . 551
Defining a Hosted Java Applet Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Defining a Bookmark for a Windows Terminal Services Profile . . . . . . . . . . . . . . 555
Creating a Windows Terminal Services Bookmark Through the User Roles
Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
Defining Display Options for the Windows Terminal Services Session . . . . . . . . 557
Defining SSO Options for the Windows Terminal Services Session . . . . . . . . . . 558
Defining Application Settings for the Windows Terminal Services Session . . . . 558
Defining Application Settings for the Windows Terminal Services Session . . . . 559
Defining Desktop Settings for the Windows Terminal Services Session . . . . . . . 560
Creating a Citrix Terminal Services Resource Profile Using Default ICA
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
Defining a Bookmark for a Citrix Profile Using Default ICA Settings . . . . . . . . . . 562
Defining Display Options for the Citrix Terminal Services Session . . . . . . . . . . . 564
Defining SSO Options for the Citrix Terminal Services Session . . . . . . . . . . . . . . 565
Defining Application, Auto-Launch, and Session Reliability Settings for the Citrix
Terminal Services Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
Defining Device Connections for the Citrix Terminal Services Session . . . . . . . . 567
Creating a Citrix Resource Profile That Uses a Custom ICA File . . . . . . . . . . . . . 568
Defining a Bookmark for a Citrix Profile Using a Custom ICA File . . . . . . . . . . . . 570
Creating a Citrix Profile That Lists Published Applications . . . . . . . . . . . . . . . . . . 571
Defining a Bookmark for a Citrix Profile Listing Applications . . . . . . . . . . . . . . . . 572
Creating Session Bookmarks to Your Terminal Server . . . . . . . . . . . . . . . . . . . . . 574
Creating Advanced Terminal Services Session Bookmarks . . . . . . . . . . . . . . . . . 575
Creating Links from an External Site to a Terminal Services Session
Bookmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Specifying General Terminal Services Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Configuring Terminal Services Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . 590
Specifying the Terminal Services Resource Option . . . . . . . . . . . . . . . . . . . . . . . . 591
Using the Remote Desktop Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Copyright © 2011, Juniper Networks, Inc.
xv
Secure Access Administration Guide
Chapter 25
Secure Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Secure Meeting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Scheduling Meetings Through the SA Series End-User Console . . . . . . . . . . . . . 594
Scheduling Meetings Through Microsoft Outlook . . . . . . . . . . . . . . . . . . . . . . . . 595
Sending Notification Emails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Joining Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Attending Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Conducting Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Presenting Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
About Instant Meetings and Support Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . 601
About MySecureMeeting Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Joining MySecureMeeting Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Enabling and Configuring Secure Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
Permissive Merge Guidelines for Secure Meeting . . . . . . . . . . . . . . . . . . . . . . . . 608
Specifying Authentication Servers that Meeting Creators can Access . . . . . . . . 608
Configuring System-Level Meeting Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
Troubleshooting Secure Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
Known Issues with SecureMeeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
Monitoring Secure Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
Chapter 26
Email Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
About the Email Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Choosing an Email Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Working with a Standards-Based Mail Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
Working with the Microsoft Exchange Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Exchange Server and IMAP Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Exchange Server and POP Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
Exchange Server and Outlook Web Access . . . . . . . . . . . . . . . . . . . . . . . . . . 621
About Lotus Notes and the Lotus Notes Mail Server . . . . . . . . . . . . . . . . . . . . . . 622
Enabling the Email Client at the Role Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Writing the Email Client Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Chapter 27
Network Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
About Network Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Task Summary: Configuring Network Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Network Connect Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Automatically Signing into Network Connect using GINA . . . . . . . . . . . . . . . 631
Using GINA Chaining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Network Connect Credential Provider for Windows Vista and Later . . . . . . 633
Smart Card Credential Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
Launching Network Connect During a Windows Secure Application Manager
Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
Logging In To Windows Through a Secure Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 636
Network Connect Connection Profiles with Support for Multiple DNS
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Network Connect Incompatibility with Other VPN Client Applications . . . . . . . 638
Linux Client Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
Client Side Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
Network Connect Proxy Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
xvi
Copyright © 2011, Juniper Networks, Inc.
Table of Contents
Network Connect Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
Network Connect Multicast Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
Defining Network Connect Role Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
About Network Connect Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
Defining Network Connect Access Control Policies . . . . . . . . . . . . . . . . . . . . . . . 646
Creating Network Connect Connection Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 647
Defining Network Connect Split Tunneling Policies . . . . . . . . . . . . . . . . . . . . . . . 654
Network Connect Resource Policy Configuration Use Case . . . . . . . . . . . . . . . . 656
About Network Connect Bandwidth Management Policies . . . . . . . . . . . . . . . . . 657
User is Mapped to Multiple Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
Writing a Network Connect Bandwidth Management Resource Policy . . . . . . . 660
Specifying IP Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
Network Connect installer Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
Network Connect Installation Process Dependencies . . . . . . . . . . . . . . . . . 662
Network Connect Un-installation Process Dependencies . . . . . . . . . . . . . . 663
Network Connect Launcher (NC Launcher) Overview . . . . . . . . . . . . . . . . . . . . . 665
Launching Network Connect On Other Platforms . . . . . . . . . . . . . . . . . . . . . . . . 667
Troubleshooting Network Connect Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
nc.windows.app.23792 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Version Conflict on Downgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Error When Connecting to a FIPS Appliance . . . . . . . . . . . . . . . . . . . . . . . . . 670
Part 5
System Management
Chapter 28
General System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
General Network Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Internal and External Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Bonding Ports on the SA Series 6000 SSL VPN Appliance . . . . . . . . . . . . . 676
Bonding Ports on the SA Series 6500 SSL VPN Appliance . . . . . . . . . . . . . 676
Configuring the Internal and External Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Internal and External Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
Bonding Ports on the SA Series 6000 SSL VPN Appliance . . . . . . . . . . . . . 678
Bonding Ports on the SA Series 6500 SSL VPN Appliance . . . . . . . . . . . . . 678
Configuring SFP Ports on the SA Series 6000 SSL VPN Appliance . . . . . . . . . . 679
Configuring the Management Port on the SA Series 6000 SSL VPN
Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Using VLANs with the SA Series Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Configuring Virtual Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682
Configuring Static Routes for Network Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
Creating ARP Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
Specifying Host Names for the SA Series Appliance to Resolve Locally . . . . . . . 686
Specifying IP Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Using Central Management Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Modifying Central Management Dashboard Graphs . . . . . . . . . . . . . . . . . . 688
Configuring System Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Reviewing System Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Upgrading or Downgrading the SA Series Appliance . . . . . . . . . . . . . . . . . . . 691
Setting System Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
Copyright © 2011, Juniper Networks, Inc.
xvii
Secure Access Administration Guide
Downloading Application Installers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
SA Series SSL VPN Appliance Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
Entering or Upgrading SA Series SSL VPN Licenses . . . . . . . . . . . . . . . . . . . 695
Configuring License Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
Upgrading License Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Subscription Licenses Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Available Subscription Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
Activating and Deactivating Emergency Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
Setting Security Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
Setting System-Wide Security Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Configuring Lockout Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Configuring NCP and JCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Installing a Juniper Software Service Package . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Configuring Your Management Port Network Settings From the Serial
Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Configuring Your Management Port Network Settings From the Adming
Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
Adding Static Routes to the Management Route Table . . . . . . . . . . . . . . . . . . . . 709
Assigning Certificate to Management Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Controlling Administrator Sign-In Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Signing in Over the Management Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Setting Role-Mapping Rules Using Custom Expressions . . . . . . . . . . . . . . . . . . . . 711
Troubleshooting the Management Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Using the Management Port on a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
Importing Configurations to a System with the Management Port Enabled . . . . 713
Chapter 29
Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
About Using Certificates on the SA Series Appliance . . . . . . . . . . . . . . . . . . . . . . 716
Using Device Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
Importing Certificates Into the SA Series Appliance . . . . . . . . . . . . . . . . . . . . . . . 718
Downloading a Device Certificate From the SA Series Appliance . . . . . . . . . . . . 720
Creating a Certificate Signing Request (CSR) for a New Certificate . . . . . . . . . . . 721
Using Intermediate Server CA Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Importing Intermediate Server CA Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Using Multiple SA Series Device Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Task summary: Enabling Multiple Device Certificates . . . . . . . . . . . . . . . . . . 723
Associating a Certificate With a Virtual Port . . . . . . . . . . . . . . . . . . . . . . . . . 724
Associating Different Certificates with Different Virtual Ports . . . . . . . . . . . . . . . 724
Using a Trusted Client CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Enabling Trusted Client CAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
Automatically Importing a CA Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
Manually Uploading CA Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
Specifying Attributes for the Trusted Client CA Certificate . . . . . . . . . . . . . . . . . . 731
Specifying Client-side Certificate Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
Enabling Client CA Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
Enabling CRLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Specifying CDP Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Enabling OCSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
Enabling OCSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
xviii
Copyright © 2011, Juniper Networks, Inc.
Table of Contents
Using Trusted Server CAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
Uploading Trusted Server CA Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
Renewing a Trusted Server CA Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Viewing Trusted Server CA Certificate Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Using Code-signing Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
Additional Considerations for SUN JVM Users . . . . . . . . . . . . . . . . . . . . . . . 746
Task Summary: Configuring the SA Series Appliance to Sign or Re-Sign Java
Applets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
Importing a Code-Signing Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
About Two-Way SSL Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
Task Summary: Configuring the SA Series Appliance for Two-Way SSL
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Importing the Certificates for Two-Way SSL Handshake . . . . . . . . . . . . . . . . . . . 749
Mapping Resource Policies to the Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750
Mapping an Client Authentication Auto-Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Client Certificate Validation on the External and Virtual Ports . . . . . . . . . . . . . . . 751
Task Summary: Configuring for Client Certificate Validation . . . . . . . . . . . . . . . . 752
Selecting the Ports For Client Certification Validation . . . . . . . . . . . . . . . . . . . . . 752
Chapter 30
System Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
About System Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Specifying Archiving Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
Creating Local Backups of SA Series Appliance Configuration Files . . . . . . . . . . 756
Importing and Exporting SA Series Appliance Configuration Files . . . . . . . . . . . . 758
Importing and Exporting IVS Configuration Settings . . . . . . . . . . . . . . . . . . . . . . 762
Importing and Exporting XML Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . 763
Creating and Modifying XML Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Integrity Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
Mapping the XML Instance to UI Components . . . . . . . . . . . . . . . . . . . . . . . 769
Downloading the Schema File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
Strategies for Working With XML Instances . . . . . . . . . . . . . . . . . . . . . . . . . . 770
Importing and Exporting XML Configuration Data . . . . . . . . . . . . . . . . . . . . . . . . 772
System Restarts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
XML Import/Export Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Importing to a System with the Management Port . . . . . . . . . . . . . . . . . . . . . . . 784
Using Operation Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
General Import Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786
Pushing Configurations from one SA Series Appliance to Another . . . . . . . . . . . 786
Defining the Target SA Series Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788
Pushing the Configuration Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
Archiving Secure Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
Chapter 31
Logging and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
Logging and Monitoring Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
Log File Severity Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
Custom Filter Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
Copyright © 2011, Juniper Networks, Inc.
xix
Secure Access Administration Guide
Dynamic Log Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
Viewing and Deleting User Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798
Configuring the Log Monitoring Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
Monitoring the SA Series Appliance as an SNMP Agent . . . . . . . . . . . . . . . . . . . 802
Viewing System Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808
About Client-Side Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
Enabling Client-Side Logging and Global Options . . . . . . . . . . . . . . . . . . . . 809
Enabling and Viewing Client-Side Log Uploads . . . . . . . . . . . . . . . . . . . . . . . . . . 810
Viewing General Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
Viewing System Capacity Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
Specifying Time Range and Data to Display in Graphs . . . . . . . . . . . . . . . . . 813
Configuring Graph Appearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
Viewing Critical System Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
Downloading the Current Service Package . . . . . . . . . . . . . . . . . . . . . . . . . . 814
Editing the System Date and Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
Monitoring Active Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815
Viewing and Cancelling Scheduled Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816
Adding Real Source IP Addresses to Log Messages . . . . . . . . . . . . . . . . . . . . . . . 817
Chapter 32
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
About Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
Simulating and Tracking Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
Simulating Events That Cause a Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
Tracking Events Using Policy Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
Recording a Trace File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823
Creating Snapshots of the SA Series Appliance System State . . . . . . . . . . . . . . 824
Creating TCP Dump Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
SA Series Appliance Network Connectivity Tools . . . . . . . . . . . . . . . . . . . . . . . . . 826
Address Resolution Protocol (ARP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
NSlookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826
Using UNIX Commands to Test Network Connectivity . . . . . . . . . . . . . . . . . . . . . 827
Running NSLookup to Test Name Server Connectivity . . . . . . . . . . . . . . . . . . . . . 827
Running Debugging Tools Remotely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827
Creating Debugging Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
Monitoring Cluster Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829
Configuring Group Communication Monitoring on a Cluster . . . . . . . . . . . . . . . . 830
Configuring Network Connectivity Monitoring on a Cluster . . . . . . . . . . . . . . . . . 830
Chapter 33
Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
About Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Cluster Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
Example 1: Licenses Distributed Equally Among Nodes . . . . . . . . . . . . . . . . 835
Example 2: Licenses Distributed Unequally Among Nodes . . . . . . . . . . . . . 835
Example 3: Licenses Distributed Unequally Among Nodes (Extreme
Case) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835
xx
Copyright © 2011, Juniper Networks, Inc.
Table of Contents
Upgrading From Previous Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Task Summary: Deploying a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837
Defining and Initializing a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
Joining an Existing Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839
Re-adding a Node to a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Deploying Two Nodes in an Active/Passive Cluster . . . . . . . . . . . . . . . . . . . . . . . 842
Failing Over the VIP to Another Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
Deploying Two or More Units in an Active/Active Cluster . . . . . . . . . . . . . . . . . . 844
Synchronizing the Cluster State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
Specifying Active/Passive, Active/Active, and Other Cluster Settings . . . . . . . . 848
Adding Multiple Cluster Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850
General Cluster Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850
Managing Network Settings for Cluster Nodes . . . . . . . . . . . . . . . . . . . . . . . 850
Upgrading Clustered Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Upgrading the Cluster Service Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Changing the IP Address of a Cluster Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
General Cluster Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
Managing Network Settings for Cluster Nodes . . . . . . . . . . . . . . . . . . . . . . . 852
Upgrading Clustered Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
Upgrading the Cluster Service Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
Deleting a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
Restarting or Rebooting Clustered Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Configuring the External VIP for An Active/Passive Cluster . . . . . . . . . . . . . . . . . 853
Admin Console Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Monitoring Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855
Troubleshooting Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856
“Management IP Address Differs From the Management IP Address” Error
Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
Serial Console Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859
Joining an SA Series Appliance to a Cluster Through Its Serial Console . . . . . . . 859
Disabling a Clustered SA Series Appliance Using Its Serial Console . . . . . . . . . . 860
Chapter 34
Delegating Administrator Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863
About Delegating Administrator Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863
Creating and Configuring Administrator Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 864
Specifying Management Tasks to Delegate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865
Delegating System Management Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865
Delegating User and Role Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866
Delegating User Realm Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866
Delegating Administrative Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866
Delegating Resource Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
Delegating Resource Profile Management . . . . . . . . . . . . . . . . . . . . . . . . . . 867
Delegating Access to IVS Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867
Defining General System Administrator Role Settings . . . . . . . . . . . . . . . . . . . . . 867
Specifying Management Tasks to Delegate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870
Delegating System Management Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870
Delegating User and Role Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
Delegating User Realm Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871
Delegating Administrative Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
Copyright © 2011, Juniper Networks, Inc.
xxi
Secure Access Administration Guide
Delegating Resource Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
Delegating Resource Profile Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
Delegating Access to IVS Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872
Chapter 35
Instant Virtual System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873
Instant Virtual System (IVS) Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874
Deploying an IVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875
Virtualized SA Series Appliance Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
Signing In to the Root System or the IVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
Signing-In Using the Sign-In URL Prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879
Signing-In Over Virtual Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881
Signing-In Over a VLAN Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Navigating to the IVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
IVS Configuration Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Administering the Root System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
Configuring the Root Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
IVS Provisioning Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
Configuring Sign-In Ports for IVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
Virtual Local Area Network (VLAN) on Subscriber IVS . . . . . . . . . . . . . . . . . . . . 889
Configuring VLANs on the Virtualized SA Series Appliance . . . . . . . . . . . . . . . . 890
Adding Static Routes to the VLAN Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . 891
Deleting a VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892
Loading the Certificates Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
Creating a Virtual System (IVS Profile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
IVS Initial Config Via Copy from the Root System or Another IVS . . . . . . . . . . . . 895
Use Cases for IVS Initial Config Via Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . 896
Signing In Directly to the IVS as an IVS Administrator . . . . . . . . . . . . . . . . . . . . . 897
About Role-Based Source IP Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Associating Roles with Source IP Addresses in an IVS . . . . . . . . . . . . . . . . . . . . . 898
Configuring Policy Routing Rules on the IVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
Routing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
Overlapping IP Address Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
Define Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
Clustering a Virtualized SA Series Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901
Accessing a DNS Server on the MSP Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
Accessing a DNS Server on a Subscriber Company intranet . . . . . . . . . . . . . . . . 903
Configuring Network Connect for Use on a Virtualized SA Series Appliance . . . 904
Configuring a Centralized DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
About Authentication Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
Rules Governing Access to Authentication Servers . . . . . . . . . . . . . . . . . . . 909
Configuring Authentication on a RADIUS Server . . . . . . . . . . . . . . . . . . . . . 909
Configuring Authentication on Active Directory . . . . . . . . . . . . . . . . . . . . . . . 910
Delegating Administrative Access to IVS Systems . . . . . . . . . . . . . . . . . . . . . . . . 910
Accessing Standalone Installers on an IVS System . . . . . . . . . . . . . . . . . . . . . . . . 911
Exporting and Importing IVS Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . 911
Using XML Import and XML Export on IVS Systems . . . . . . . . . . . . . . . . . . . . . . . 913
Monitoring Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
Troubleshooting VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
IVS Use Case: Policy Routing Rules Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
xxii
Copyright © 2011, Juniper Networks, Inc.
Table of Contents
Use Case: Configuring a Global Authentication Server for Multiple
Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Use Case: Configuring a DNS/WINS Server IP Address per Subscriber . . . . . . . . 922
Use Case: Configuring Access to Web Applications and Web Browsing for Each
Subscriber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922
Use Case: Configuring File Browsing Access for Each Subscriber . . . . . . . . . . . . 923
Use Case: Setting Up Multiple Subnet IP Addresses for a Subscriber’s
End-Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924
Use Case: Configuring Multiple IVS Systems to Allow Access to Shared
Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Chapter 36
SA Series Appliance and IDP Interoperability . . . . . . . . . . . . . . . . . . . . . . . . 927
About IDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
Licensing: IDP Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
IDP Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
Configuring the SA Series SSL VPN Appliance to Interoperate with IDP . . . . . . 929
Interaction Between the IC Series and IDP . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Configuring IDP Sensor Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Configuring the SA Series SSL VPN Appliance to Interoperate with IDP . . . . . . . 932
Interaction Between the IC Series and IDP . . . . . . . . . . . . . . . . . . . . . . . . . . 933
Defining Automatic Response Sensor Event Policies . . . . . . . . . . . . . . . . . . . . . . 933
Identifying and Managing Quarantined Users Manually . . . . . . . . . . . . . . . . . . . 935
Part 6
System Services
Chapter 37
SA Series Appliance Serial Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939
Using the Serial Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939
Rolling Back to a Previous System State Through the Serial Console . . . . . . . . 940
Resetting an SA Series Device to the Factory Setting Using the Serial
Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
Performing Common Recovery Tasks with the Serial Console . . . . . . . . . . . . . . 942
Chapter 38
Customizable Admin and End-User UIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945
Customizable Admin and End-User UIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945
Customizable End-User Interface Elements Overview . . . . . . . . . . . . . . . . . 946
Chapter 39
SA6000 Series Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947
SA6000 Series Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947
SA6000 Field-Replaceable Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948
Chapter 40
SA4500 and SA6500 Series Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
SA4500 and SA6500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
Standard Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
SA Series 6500 Field-Replaceable Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952
Device Status LED Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953
Ethernet Port LED Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
Replacing the Cooling Fans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
Replacing a Hard Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956
Replacing IOC Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956
Replacing a Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958
Copyright © 2011, Juniper Networks, Inc.
xxiii
Secure Access Administration Guide
Chapter 41
Secure Access FIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
SA FIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
SA FIPS Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
Creating Administrator Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963
Deploying a Cluster in a Secure Access FIPS Environment . . . . . . . . . . . . . . . . . 964
Creating a New Security World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
Recovering an Archived Security World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
Chapter 42
SA4500 and SA6500 FIPS Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
FIPS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
Name and Password Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
Initializing a Keystore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
Reinitializing the Keystore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
Joining a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976
Importing Device Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977
Changing the Security Officer Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977
Changing the Web User Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978
Resetting the HSM Card In Case Of An Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978
Upgrading the HSM Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978
Binary Importing and Exporting of the Keystore . . . . . . . . . . . . . . . . . . . . . . . . . . 979
FIPS Device Status LED Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
Chapter 43
Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
About Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
Enabling System-Level Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
Chapter 44
Multi-Language Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
About Multi-Language Support for the SA Series SSL VPN Appliance . . . . . . . . 987
Encoding Files for Multi-Language Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
Localizing the User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988
Localizing Custom Sign-In and System Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
Chapter 45
Handheld Devices and PDAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
Handheld Devices and PDAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
Task Summary: Configuring the SA Series SSL VPN Appliance for PDAs and
Handhelds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992
Defining Client Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
Enabling WSAM on PDAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995
Enabling ActiveSync For Handheld PDAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
Chapter 46
Using IKEv2 with the SA Series Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . 999
About IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Client Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Supported Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1000
Task Summary: Configuring the SA Series SSL VPN Appliance for IKEv2 . . . . . 1001
Defining the IKEv2 Role Mapping Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002
Enabling the IKEv2 Access Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002
xxiv
Copyright © 2011, Juniper Networks, Inc.
Table of Contents
Chapter 47
Writing Custom Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005
Custom Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005
Elements Used in Custom Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006
Wildcard Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1009
Distinguished Name Variables and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
System Variables and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1010
Using System Variables in Realms, Roles, and Resource Policies . . . . . . . . . . . 1020
Using Multi-Valued Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
Specifying Multi-valued Attributes in a Bookmark Name . . . . . . . . . . . . . . . . . . 1022
Specifying Fetch Attributes in a Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1022
Specifying the homeDirectory Attribute for LDAP . . . . . . . . . . . . . . . . . . . . . . . . 1023
Part 7
Index
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027
Copyright © 2011, Juniper Networks, Inc.
xxv
Secure Access Administration Guide
xxvi
Copyright © 2011, Juniper Networks, Inc.
List of Figures
Part 1
Getting Started
Chapter 2
Introduction to the SA Series Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 1: The SA Series Appliance Working within a LAN . . . . . . . . . . . . . . . . . . . . . 17
Figure 2: Configuration and Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Part 2
Access Management Framework
Chapter 3
General Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figure 3: Security Checks Performed During a User Session . . . . . . . . . . . . . . . . . . 61
Figure 4: Federation IF-MAP Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figure 5: Session-Import and Session-Export Policies . . . . . . . . . . . . . . . . . . . . . 80
Chapter 4
User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Figure 6: Security Checks Performed by the SA Series Appliance to Create a
Session Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Chapter 5
Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Figure 7: Using Roles and Resource Policies to Configure Resources . . . . . . . . . . . 111
Figure 8: Using Resource Profiles to Configure Resources . . . . . . . . . . . . . . . . . . . 112
Chapter 7
Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Figure 9: Resource Policy Evaluation Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Chapter 9
Authentication Realms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Figure 10: Server Catalog > Attributes Tab — Adding an Attribute for LDAP . . . . 220
Figure 11: Server Catalog > Groups Tab — Adding LDAP Groups . . . . . . . . . . . . . . 221
Figure 12: Server Catalog > Groups Tab — Adding Active Directory Groups . . . . . 223
Chapter 11
Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Figure 13: Collecting and Submitting Credentials from Multiple Servers . . . . . . . 241
Figure 14: Artifact Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Figure 15: POST Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Figure 16: Access Control Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Part 3
Endpoint Defense
Chapter 13
Host Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Figure 17: Host Checker Creates a Tunnel from a Client to a Policy Server Behind
the SA Series Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Part 4
Remote Access
Chapter 22
Secure Application Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Copyright © 2011, Juniper Networks, Inc.
xxvii
Secure Access Administration Guide
Figure 18: Java Secure Application Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Figure 19: Java Secure Application Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Figure 20: Java Secure Application Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Figure 21: Java Secure Application Manager and Enhanced MS Exchange
Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Figure 22: Java Secure Application Manager and Enhanced Lotus Notes
Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Chapter 27
Network Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
Figure 23: GINA Installation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
Part 5
System Management
Chapter 28
General System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Figure 24: License Key Generation and Activation . . . . . . . . . . . . . . . . . . . . . . . . 696
Chapter 30
System Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Figure 25: SA Series Object Referential Integrity Constraints . . . . . . . . . . . . . . . . 768
Chapter 33
Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Figure 26: Active/Passive Cluster Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
Figure 27: Active/Active Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
Chapter 35
Instant Virtual System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873
Figure 28: MSP Deployment Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
Figure 29: IVS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
Figure 30: Setting a Static Route in MSP Network DNS or Application Servers . . 905
Chapter 36
SA Series Appliance and IDP Interoperability . . . . . . . . . . . . . . . . . . . . . . . . 927
Figure 31: SA Series Appliance and IDP Topology Scenario 1 . . . . . . . . . . . . . . . . 929
Figure 32: SA Series Appliance and IDP Topology Scenario 2 . . . . . . . . . . . . . . . 929
Part 6
System Services
Chapter 37
SA Series Appliance Serial Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939
Figure 33: SA Series Serial Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940
xxviii
Copyright © 2011, Juniper Networks, Inc.
List of Tables
Front Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii
Table 1: IC Series Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiii
Table 2: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxiv
Part 1
Getting Started
Chapter 2
Introduction to the SA Series Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Table 3: Configurable Parameters for Junos Pulse Connection Sets . . . . . . . . . . . 44
Table 4: Junos Pulse Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Part 2
Access Management Framework
Chapter 4
User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Table 5: View Menu Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Chapter 5
Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Table 6: Resource Profile Types and Configuration Information . . . . . . . . . . . . . . 112
Chapter 7
Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Table 7: DNS Hostname Special Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Table 8: Port Possible Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Chapter 8
Authentication and Directory Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Table 9: Supported Password Management Functions . . . . . . . . . . . . . . . . . . . . 159
Table 10: AD/NT Password Management Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Table 11: Attributes Common to both Start and Stop Messages . . . . . . . . . . . . . . 172
Table 12: Start Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Table 13: Stop Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Table 14: RADIUS Role Mapping Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Table 15: eTrust SiteMinder Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . 195
Table 16: eTrust SiteMinder Advanced Configuration Options . . . . . . . . . . . . . . . 201
Part 3
Endpoint Defense
Chapter 13
Host Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Table 17: Wildcard Characters for Specifying a File Name or Process Name . . . . 296
Table 18: Environment Variables for Specifying a Directory Path on Windows . . 296
Table 19: Environment Variables for Specifying a Directory Path on Macintosh,
Linux and Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Part 4
Remote Access
Chapter 16
Citrix Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Copyright © 2011, Juniper Networks, Inc.
xxix
Secure Access Administration Guide
Table 20: Accessing the Citrix Web Interface Server using Web Resource Profile
Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Chapter 20
Web Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Table 21: DNS hostname special characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Table 22: Port possible values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Table 23: Port Possible Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Table 24: Port Possible Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Table 25: OWA Caching Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Table 26: iNotes Caching Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Table 27: Predefined Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Chapter 22
Secure Application Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Table 28: WSAM Command Line Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Chapter 24
Terminal Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Table 29: Case-Insensitive Terminal Services Session Bookmark Parameter
Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
Chapter 27
Network Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
Table 30: Network Connect Compatibility with Third-Party VPN Clients . . . . . . 638
Table 31: Syntax for IP Address Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Table 32: Privilege Levels and Percent of Maximum Bandwidth . . . . . . . . . . . . . 658
Part 5
System Management
Chapter 30
System Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Table 33: System Behavior When Editing Options . . . . . . . . . . . . . . . . . . . . . . . . 778
Table 34: Legal Operation Attribute Relationships . . . . . . . . . . . . . . . . . . . . . . . . 785
Chapter 31
Logging and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
Table 35: Configuration Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
Chapter 33
Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Table 36: Cluster Status Page Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Table 37: Cluster Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857
Chapter 35
Instant Virtual System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873
Table 38: VLAN1 Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
Table 39: VLAN2 Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
Table 40: VLAN3 Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
Table 41: VLAN4 Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
Table 42: VLAN1 Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
Table 43: VLAN2 route table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Table 44: VLAN3 route table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Table 45: VLAN4 route table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Part 6
System Services
Chapter 40
SA4500 and SA6500 Series Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
Table 46: Device Status LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
xxx
Copyright © 2011, Juniper Networks, Inc.
List of Tables
Table 47: 4-Port Copper Gigabit Ethernet LEDs (available on IC4500 and
IC6500) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
Chapter 42
SA4500 and SA6500 FIPS Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
Table 48: Status LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980
Chapter 47
Writing Custom Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005
Table 49: Custom Expression Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006
Table 50: System Variables and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011
Copyright © 2011, Juniper Networks, Inc.
xxxi
Secure Access Administration Guide
xxxii
Copyright © 2011, Juniper Networks, Inc.
Front Part
•
Related Documentation on page xxxiii
•
Document Conventions on page xxxiv
•
Requesting Technical Support on page xxxiv
Related Documentation
Table 1 on page xxxiii describes documentation for the IC Series Appliance.
All documentation is available at http://www.juniper.net/techpubs/software/uac/
Table 1: IC Series Publications
Book
Description
UAC Interoperability with
the JUNOS Enforcer
Details using the IC Series device with the Junos Enforcer.
UAC Interoperability with
the ScreenOS Enforcer
Details using the IC Series device with the ScreenOS Enforcer.
Layer 2 and the IC Series
RADIUS Server
This guide provides an overview of RADIUS and the IC Series device
RADIUS server.
Implementation details for 802.1X, MAC address authentication,
and several other practical use cases are provided.
UAC Guide to IF-MAP
Federation
Provides a comprehensive overview of IF-MAP and details using
IF-MAP Federation with the UAC solution.
Unified Access Control
Administration Guide
Includes comprehensive information about configuring the Unified
Access Control solution and the Infranet Controller 4500 and 6500
appliances.
Client Side Changes Guide
Lists changes that the Infranet Controller clients and Odyssey
Access Client make to client computers, including installed files
and registry changes.
Custom Sign-in Pages
Solution Guide
Includes guidelines for personalizing the look-and-feel of sign-in
pages.
Deployment Scenarios
Guide
Describes several example network scenarios for deploying the
Unified Access Control solution.
Copyright © 2011, Juniper Networks, Inc.
xxxiii
Secure Access Administration Guide
Table 1: IC Series Publications (continued)
Book
Description
Installation Guide
Describes how to install the Infranet Controller 4500 and 6500
appliances on your network and begin configuration.
Quick Start Guide
Includes an example of configuring the Unified Access Control
solution for a front-end server deployment scenario.
Troubleshooting Guide
Tips for troubleshooting the UAC Solution.
Document Conventions
Table 2 on page xxxiv defines notice icons used in this guide.
Table 2: Notice Icons
Icon
Meaning
Description
Informational note
Indicates important features or instructions.
Caution
Indicates a situation that might result in loss of data or hardware damage.
Warning
Alerts you to the risk of personal injury or death.
Laser warning
Alerts you to the risk of personal injury from a laser.
Requesting Technical Support
Technical product support is available through the Juniper Networks Technical Assistance
Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,
or are covered under warranty, and need post-sales technical support, you can access
our tools and resources online or open a case with JTAC.
xxxiv
•
JTAC policies—For a complete understanding of our JTAC procedures and policies,
review the JTAC User Guide located at
http://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf .
•
Product warranties—For product warranty information, visit
http://www.juniper.net/support/warranty/ .
•
JTAC hours of operation—The JTAC centers have resources available 24 hours a day,
7 days a week, 365 days a year.
Copyright © 2011, Juniper Networks, Inc.
Front Part
Self-Help Online Tools and Resources
For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with the
following features:
•
Find CSC offerings: http://www.juniper.net/customers/support/
•
Search for known bugs: http://www2.juniper.net/kb/
•
Find product documentation: http://www.juniper.net/techpubs/
•
Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/
•
Download the latest versions of software and review release notes:
http://www.juniper.net/customers/csc/software/
•
Search technical bulletins for relevant hardware and software notifications:
https://www.juniper.net/alerts/
•
Join and participate in the Juniper Networks Community Forum:
http://www.juniper.net/company/communities/
•
Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/
To verify service entitlement by product serial number, use our Serial Number Entitlement
(SNE) Tool: https://tools.juniper.net/SerialNumberEntitlementSearch/
Opening a Case with JTAC
You can open a case with JTAC on the Web or by telephone.
•
Use the Case Management tool in the CSC at http://www.juniper.net/cm/ .
•
Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).
For international or direct-dial options in countries without toll-free numbers, see
http://www.juniper.net/support/requesting-support.html .
Copyright © 2011, Juniper Networks, Inc.
xxxv
Secure Access Administration Guide
xxxvi
Copyright © 2011, Juniper Networks, Inc.
PART 1
Getting Started
•
Initial Verification and Key Concepts on page 3
•
Introduction to the SA Series Appliance on page 15
Copyright © 2011, Juniper Networks, Inc.
1
Secure Access Administration Guide
2
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 1
Initial Verification and Key Concepts
•
Verifying User Accessibility on page 3
•
Creating a Test Scenario to Learn SA Series Appliance Concepts and Best
Practices on page 4
•
Defining a User Role on page 5
•
Defining a Resource Profile on page 6
•
Defining an Authentication Server on page 7
•
Defining an Authentication Realm on page 9
•
Defining a Sign-In Policy on page 10
•
Using the Test Scenario on page 12
•
Default Settings for Administrators on page 13
Verifying User Accessibility
You can easily create a user account in the system authentication server for use in verifying
user accessibility to your SA Series Appliance. After creating the account through the
admin console, sign in as the user on the SA Series Appliance user sign-in page.
To verify user accessibility:
1.
From the admin console, choose Authentication > Auth. Servers.
2. Select the System Local link.
3. Select the Users tab.
4. Click New.
5. Type testuser1 as the username and enter a password, and then click Save Changes.
The SA Series Appliance creates the testuser1 account.
6. Use another browser window to enter the machine’s URL to access the user sign-in
page. The URL is in the format: https://a.b.c.d, where a.b.c.d is the machine IP address
you entered in the serial console when you initially configured your SA Series Appliance.
7. Click Yes\ when prompted with the security alert to proceed without a signed
certificate. The user sign-in page appears, indicating that you have successfully
connected to your SA Series Appliance.
Copyright © 2011, Juniper Networks, Inc.
3
Secure Access Administration Guide
8. Enter the username and password you created for the user account and then click
Sign In to access the SA Series Appliance home page for users.
9. Enter the URL to an internal Web server in the Address box and click Browse. The SA
Series Appliance opens the Web page in the same browser window, so to return to
the SA Series Appliance home page, click the center button on the toolbar that appears
on the target Web page.
10. Enter the URL to your external corporate site on the SA Series Appliance home page,
and click Browse. The SA Series Appliance opens the Web page in the same browser
window, so use the button on the toolbar to return to the SA Series Appliance home
page.
11. Click Browsing > Windows Files on the SA Series Appliance home page to browse
through available Windows file shares or Browsing > UNIX/NFS Files to browse through
available UNIX NFS file shares.
Related
Documentation
•
Creating a Test Scenario to Learn SA Series Appliance Concepts and Best Practices
on page 4
•
Defining a User Role on page 5
•
Defining a Resource Profile on page 6
•
Defining an Authentication Server on page 7
•
Defining an Authentication Realm on page 9
•
Defining a Sign-In Policy on page 10
•
Using the Test Scenario on page 12
Creating a Test Scenario to Learn SA Series Appliance Concepts and Best Practices
The SA Series Appliance provides a flexible access management system that makes it
easy to customize a user’s remote access experience through the use of roles, resource
policies, authentication servers, authentication realms, and sign-in policies. To enable
you to quickly begin working with these entities, the SA Series Appliance ships with system
defaults for each. you can create each access management entity by performing the
following tasks:
4
•
Define a user role
•
Define a resource policy
•
Define an authentication server
•
Define an authentication realm
•
Define a sign-in policy
Copyright © 2011, Juniper Networks, Inc.
Chapter 1: Initial Verification and Key Concepts
The SA Series Appliance supports two types of users:
Related
Documentation
•
Administrators—An administrator is a person who may view or modify SA Series
Appliance configuration settings. You create the first administrator account through
the serial console.
•
Users—A user is a person who uses the SA Series Appliance to gain access to corporate
resources as configured by an administrator.
•
Verifying User Accessibility on page 3
•
Defining a User Role on page 5
•
Defining a Resource Profile on page 6
•
Defining an Authentication Server on page 7
•
Defining an Authentication Realm on page 9
•
Defining a Sign-In Policy on page 10
•
Using the Test Scenario on page 12
Defining a User Role
The SA Series Appliance is preconfigured with one user role called “Users.” This predefined
role enables the Web and file browsing access features, enabling any user mapped to
the Users role to access the Internet, corporate Web servers, and any available Windows
and UNIX NFS file servers. You can view this role on the User Roles page.
After you enable an access feature for a role, configure the appropriate corresponding
options that are accessible from the access feature’s configuration tab.
To define a user role:
1.
In the admin console, choose Users > User Roles.
2. Click New Role.
3. Enter Test Role in the Name box and then click Save Changes.
Wait for the SA Series Appliance to display the Test Role page with the General tab
and Overview link selected.
4. Select the Web check box under Access features and then click Save Changes.
5. Select Web > Options.
6. Select the User can type URLs in the IVE browser bar check box, and then click Save
Changes.
After completing these steps, you have defined a user role. When you create resource
profiles, you can apply them to this role. You can also map users to this role through role
mapping rules defined for an authentication realm.
Copyright © 2011, Juniper Networks, Inc.
5
Secure Access Administration Guide
To quickly create a user role that enables Web and file browsing, duplicate the Users
role, and then enable additional access features as desired.
Related
Documentation
•
Verifying User Accessibility on page 3
•
Creating a Test Scenario to Learn SA Series Appliance Concepts and Best Practices
on page 4
•
Defining a Resource Profile on page 6
•
Defining an Authentication Server on page 7
•
Defining an Authentication Realm on page 9
•
Defining a Sign-In Policy on page 10
•
Using the Test Scenario on page 12
Defining a Resource Profile
A resource profile is a set of configuration options that contains all of the resource policies,
role assignments, and end-user bookmarks required to provide access to an individual
resource.
Within a resource profile, a resource policy specifies the resources to which the policy
applies (such as URLs, servers, and files) and whether the SA Series Appliance grants
access to a resource or performs an action. Note that the SA Series Appliance is
preconfigured with two types of resource policies:
•
Web Access—The predefined Web Access resource policy enables all users to access
the Internet and all corporate Web servers through the SA Series Appliance. By default,
this resource policy applies to the Users role.
•
Windows Access—The predefined Windows Access resource policy enables all users
mapped to the Users role to access all corporate Windows file servers. By default, this
resource policy applies to the Users role.
NOTE: Delete the default Web Access and Windows Access resource policies
if you are concerned about users having access to all of your Web and file
content.
To define a resource profile:
1.
In the admin console, choose Users > Resource Profiles > Web.
2. Click New Profile.
The Web Applications Resource Profile page appears.
3. Fill in the following information:
a. In the Type box, keep the default option (Custom).
b. In the Name box, type Test Web Access.
6
Copyright © 2011, Juniper Networks, Inc.
Chapter 1: Initial Verification and Key Concepts
c. In the Base URL box, type http://www.google.com.
d. Under Autopolicy: Web Access Control, select the check box next to the default
policy created by the SA Series Appliance (http://www.google.com:80/*) and
choose Delete.
e. In Resource box, type http://www.google.com, select Deny from the Action list,
and click Add.
f.
Click Save and Continue.
The Test Web Access page appears.
4. Click the Roles tab.
a. Select Test Role in the Available Roles box and click Add to move it to the Selected
Roles box.
b. Click Save Changes.
The SA Series Appliance adds Test Web Access to the Web Application Resource Policies
page and automatically creates a corresponding bookmark that links to google.com.
After completing these steps, you have configured a Web Access resource profile. Even
though the SA Series Appliance comes with a resource policy that enables access to all
Web resources, users mapped to Test Role are still prohibited from accessing
http://www.google.com. These users are denied access because the autopolicy you
created during the resource profile configuration takes precedence over the default Web
access policy that comes with the SA Series Appliance.
Related
Documentation
•
Verifying User Accessibility on page 3
•
Creating a Test Scenario to Learn SA Series Appliance Concepts and Best Practices
on page 4
•
Defining a User Role on page 5
•
Defining an Authentication Server on page 7
•
Defining an Authentication Realm on page 9
•
Defining a Sign-In Policy on page 10
•
Using the Test Scenario on page 12
Defining an Authentication Server
An authentication server is a database that stores user credentials—username and
password—and typically group and attribute information. When a user signs in to an SA
Series Appliance, the user specifies an authentication realm, which is associated with an
authentication server. The SA Series Appliance forwards the user’s credentials to this
authentication server to verify the user’s identity.
Copyright © 2011, Juniper Networks, Inc.
7
Secure Access Administration Guide
The SA Series Appliance supports the most common authentication servers, including
Windows NT Domain, Active Directory, RADIUS, LDAP, NIS, RSA ACE/Server, SAML
Server, and eTrust SiteMinder, and enables you to create one or more local databases
of users who are authenticated by the SA Series Appliance. The SA Series Appliance is
preconfigured with one local authentication server for users called “System Local.” This
predefined local authentication server is an SA Series Appliance database that enables
you to quickly create user accounts for user authentication. This ability provides flexibility
for testing purposes and for providing third-party access by eliminating the need to create
user accounts in an external authentication server.
You can view the default local authentication server on the Authentication Servers page.
NOTE: The SA Series Appliance also supports authorization servers. An
authorization server (or directory server) is a database that stores user
attribute and group information. You can configure an authentication realm
to use a directory server to retrieve user attribute or group information for
use in role mapping rules and resource policies.
To define an authentication server:
1.
In the admin console, choose Authentication > Auth. Servers.
2. Select Local Authentication from the New list and then click New Server.
The New Local Authentication page appears.
3. Enter Test Server in the Name box and then click Save Changes.
Wait for the SA Series Appliance to notify you that the changes are saved, after which
additional configuration tabs appear.
4. Click the Users tab and then click New.
The New Local User page appears.
5. Enter testuser2 in the Username box, enter a password, and then click Save Changes
to create the user’s account in the Test Server authentication server.
After completing these steps, you have created an authentication server that contains
one user account. This user can sign in to an authentication realm that uses the Test
Server authentication server.
The admin console provides last access statistics for each user account on the respective
authentication servers pages, on the Users tab under a set of columns titled Last Sign-in
Statistic. The statistics reported include the last successful sign-in date and time for
each user, the user’s IP address, and the agent or browser type and version.
Related
Documentation
8
•
Verifying User Accessibility on page 3
•
Creating a Test Scenario to Learn SA Series Appliance Concepts and Best Practices
on page 4
•
Defining a User Role on page 5
Copyright © 2011, Juniper Networks, Inc.
Chapter 1: Initial Verification and Key Concepts
•
Defining a Resource Profile on page 6
•
Defining an Authentication Realm on page 9
•
Defining a Sign-In Policy on page 10
•
Using the Test Scenario on page 12
Defining an Authentication Realm
An authentication realm is a grouping of authentication resources, including:
•
An authentication server, which verifies a user’s identity. The SA Series Appliance
forwards credentials submitted on a sign-in page to an authentication server.
•
An authentication policy, which specifies realm security requirements that need to be
met before the SA Series Appliance submits credentials to an authentication server
for verification.
•
A directory server, which is an LDAP server that provides user and group attribute
information to the SA Series Appliance for use in role mapping rules and resource
policies (optional).
•
Role mapping rules, which are conditions a user must meet for the SA Series Appliance
to map a user to one or more roles. These conditions are based on information returned
by the realm's directory server, the person’s username, or certificate attributes.
The SA Series Appliance is preconfigured with one user realm called “Users.” This
predefined realm uses the System Local authentication server, an authentication policy
that requires a minimum password length of four characters, no directory server, and
contains one role mapping rule that maps all users who sign in to the Users realm to the
Users role. The “testuser1” account you created is part of the Users realm, because this
account is created in the System Local authentication server. The “testuser2” account
you created i is not part of the Users realm, because you create the user account in the
new “Test Server” authentication server, which is not used by the Users realm.
You can view the default user authentication realm on the User Authentication Realms
page.
To define an authentication realm:
1.
In the admin console, choose Users > User Realms.
The User Authentication Realms page appears.
2. Click New.
The New Authentication Realm page appears.
3. Enter Test Realm in the Name box.
4. Select Test Server from the Authentication list.
5. Click Save Changes.
Copyright © 2011, Juniper Networks, Inc.
9
Secure Access Administration Guide
Wait for the SA Series Appliance to notify you that the changes are saved and to
display the realm’s configuration tabs.
6. Click the Role Mapping tab if it is not already selected, and then click New Rule.
The Role Mapping Rule page appears.
7. Enter testuser2 in the text box.
8. Under “...then assign these roles”, select Test Role from the Available Roles list and
click Add to move it to the Selected Roles box.
9. Click Save Changes.
After completing these steps, you have finished creating an authentication realm. This
realm uses Test Server to authenticate users and a role mapping rule to map testuser2
to Test Role. Because the Test Web Access resource policy applies to Test Role, any user
mapped to this role cannot access http://www.google.com.
Related
Documentation
•
Verifying User Accessibility on page 3
•
Creating a Test Scenario to Learn SA Series Appliance Concepts and Best Practices
on page 4
•
Defining a User Role on page 5
•
Defining a Resource Profile on page 6
•
Defining an Authentication Server on page 7
•
Defining a Sign-In Policy on page 10
•
Using the Test Scenario on page 12
Defining a Sign-In Policy
A sign-in policy is a system rule that specifies:
•
A URL where a user may sign in to the SA Series Appliance.
•
A sign-in page to display to the user.
•
Whether or not the user needs to type or select an authentication realm to which the
SA Series Appliance submits credentials.
•
The authentication realms where the sign-in policy applies.
All SA Series and SA Series FIPS appliances are preconfigured with one sign-in policy
that applies to users: */. This default user sign-in policy (*/) specifies that when a user
enters the URL to the SA Series Appliance, the SA Series Appliance displays the default
sign-in page for the user and requires the user to select an authentication realm (if more
than one realm exists). The */ sign-in policy is configured to apply to the Users
authentication realm, therefore this sign-in policy does not apply to the authentication
realm you created.
You can view the default user sign-in policy on the Signing In page. If your SA Series
Appliance has the Secure Meeting Upgrade license, the */meeting sign-in policy is also
10
Copyright © 2011, Juniper Networks, Inc.
Chapter 1: Initial Verification and Key Concepts
listed on this page. This policy enables you to customize the sign-in page for secure
meetings.
To define a sign-in policy:
1.
In the admin console, choose Authentication > Signing in > Sign-in Policies.
The Signing In page appears.
2. Click */ under User URLs.
The */ page appears.
3. Enter test after */ in the Sign-in URL box.
4. Under Authentication realm, select the User picks from a list of authentication realms
option button, and then select Test Realm from the Available Realms list and click
Add to move it to the Selected Realms box. (Repeat this process for the Users role if
it is not already in the Selected Realms box.)
5. Click Save Changes.
After completing these steps, you have finished modifying the default users sign-in policy.
Optional Steps
You can perform these following optional steps to define a new sign-in page that is
associated with the */test/ sign-in policy.
1.
Select Authentication > Signing In > Sign In Pages, and then click New Page.
2. Enter Test Sign-in Page in the Name field, type #FF0000 (red) in the Background
color box, and then click Save Changes.
3. Select Authentication > Signing In > Signing In Policies, and then click New URL.
The New Sign-In Policy page appears.
4. Type */test/ in the Sign-in URL box, select Default Sign-in Page from the Sign-in
Page list, and click Save Changes.
5. Select Authentication > Signing In > Sign In Policies, and then click */test/ under
User URLs.
The */test/ page appears.
6. Select Test Sign-in Page from the Sign-in page list and then click Save Changes.
Related
Documentation
•
Verifying User Accessibility on page 3
•
Creating a Test Scenario to Learn SA Series Appliance Concepts and Best Practices
on page 4
•
Defining a User Role on page 5
•
Defining a Resource Profile on page 6
•
Defining an Authentication Server on page 7
•
Defining an Authentication Realm on page 9
Copyright © 2011, Juniper Networks, Inc.
11
Secure Access Administration Guide
•
Using the Test Scenario on page 12
Using the Test Scenario
The test scenario enables you to do the following tasks:
•
Access the user console using the modified default sign-in policy.
•
Sign in as the user created in the Test Server to map to the Test Realm.
•
Test your Web browsing capabilities, which are dependent upon the proper configuration
of Test Role and Test Web Access.
To use the test scenario:
1.
In a browser, enter the machine’s URL followed by /test to access the user sign-in
page. The URL is in the format: https://a.b.c.d/test, where a.b.c.d is the machine IP
address you entered in the serial console during initial configuration.
2. Click Yes when prompted with the security alert to proceed without a signed certificate.
If the user sign-in page appears, you have successfully connected to your SA Series
Appliance.
NOTE: If you performed the optional configuration steps in “Defining a
Sign-In Policy”, the header color is red.
3. Enter the username and password you created for the user account in Test Server,
type Test Realm in the Realm box, and then click Sign In to access the SA Series
Appliance home page for users.
The SA Series Appliance forwards the credentials to Test Realm, which is configured
to use Test Server. Upon successful verification by this authentication server, the SA
Series Appliance processes the role mapping rule defined for Test Realm, which maps
testuser2 to Test Role. Test Role enables Web browsing for users.
4. In the browser Address box, enter the URL to your corporate Web site and click Browse.
The SA Series Appliance opens the Web page in the same browser window, so to
return to the SA Series Appliance home page, click the center icon in the browsing
toolbar that appears on the target Web page.
5. On the SA Series Appliance home page, type www.google.com and click Browse.
The SA Series Appliance displays an error message, because the Test Web Access
resource policy denies access to this site for users mapped to Test Role.
6. Return to the SA Series Appliance home page, click Sign Out, and then return to the
user sign-in page.
7. Enter the credentials for testuser1, specify the Users realm, and then click Sign In.
12
Copyright © 2011, Juniper Networks, Inc.
Chapter 1: Initial Verification and Key Concepts
8. On the SA Series Appliance home page, type www.google.com and click Browse.
The SA Series Appliance opens the Web page in the same browser window.
9. The test scenario demonstrates the basic SA Series Appliance access management
mechanisms. You can create very sophisticated role mapping rules and resource
policies that control user access depending on factors such as a realm’s authentication
policy, a user’s group membership, and other variables. To learn more about SA Series
Appliance access management, we recommend that you take a few minutes to review
the online Help to familiarize yourself with its contents.
When you configure the SA Series Appliance for your enterprise, we recommend that
you perform user access configuration. Before you make your SA Series Appliance
available from external locations, we recommend that you import a signed digital
certificate from a trusted certificate authority (CA).
Related
Documentation
•
Verifying User Accessibility on page 3
•
Creating a Test Scenario to Learn SA Series Appliance Concepts and Best Practices
on page 4
•
Defining a User Role on page 5
•
Defining a Resource Profile on page 6
•
Defining an Authentication Server on page 7
•
Defining an Authentication Realm on page 9
•
Defining a Sign-In Policy on page 10
Default Settings for Administrators
Just like for users, the SA Series Appliance provides default settings that enable you to
quickly configure accounts for administrators. This list summarizes the system default
settings for administrators:
•
Administrator roles—There are two built-in administrator roles.
•
.Administrators — This built-in role permits administrators to manage all aspects of
the SA Series Appliance. The administrator user you create through the serial console
is mapped to this role.
•
.Read-Only Administrators — This built-in role permits users mapped to the role to
view (but not configure) all SA Series Appliance settings. You need to map
administrators to this role if you want to restrict their access.
•
Administrators local authentication server — The Administrators local authentication
server is an SA Series Appliance database that stores administrator accounts. You
create the first administrator account in this server through the serial console. (The SA
Series Appliance adds all administrator accounts created through the serial console
to this server.) You cannot delete this local server.
•
Admin Users authentication realm — The Admin Users authentication realm uses the
default Administrators local authentication server, an authentication policy that requires
Copyright © 2011, Juniper Networks, Inc.
13
Secure Access Administration Guide
a minimum password length of four characters, no directory server, and one role
mapping rule that maps all users who sign in to the Admin Users realm to the
.Administrators role. The administrator account you create through the serial console
is part of the Admin Users realm.
Related
Documentation
14
•
*/admin sign-in policy — The default administrator sign-in policy (*/admin) specifies
that when a user enters the URL to the SA Series Appliance followed by /admin, the
SA Series Appliance displays the default sign-in page for administrators. This policy
also requires the administrator to select an authentication realm (if more than one
realm exists). The */admin sign-in policy is configured to apply to the Admin Users
authentication realm, therefore this sign-in policy applies to the administrator account
you create through the serial console.
•
Defining a User Role on page 5
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 2
Introduction to the SA Series Appliance
•
SA Series Solution Overview on page 16
•
Securing Traffic With SA Series Appliances on page 18
•
Authenticating Users With Existing Servers on page 19
•
Fine-Tuning Access to the SA Series SSL VPN Appliance and the Resources It
Intermediates on page 20
•
Creating a Seamless Integration Between the SA Series SSL VPN Appliance and the
Resources It Intermediates on page 21
•
Protecting Against Infected Computers and Other Security Concerns on page 21
•
Ensuring Redundancy in the SA Series Environment on page 22
•
Making the SA Series Interface Match My Company’s Look-and-Feel on page 22
•
Enabling Users on a Variety of Computers and Devices to Use the SA Series SSL VPN
Appliance on page 23
•
Providing Secure Access for My International Users on page 23
•
Configuring the SA Series SSL VPN Appliance on page 24
•
Network and Security Manager and the Infranet Controller on page 25
•
Configuring the SA Series SSL VPN Appliance for the Initial DMI Connection on page 27
•
Managing Large Binary Data Files on page 29
•
Uploading and Linking Large Binary Data Files With NSM on page 30
•
Importing Custom Sign-In Pages With NSM on page 31
•
Importing Antivirus LiveUpdate Settings With NSM on page 32
•
Importing Endpoint Security Assessment Plug-in (ESAP) Packages With
NSM on page 33
•
Uploading a Third-Party Host Checker Policy With NSM on page 34
•
Linking to a Third-Party Host Checker Policy Shared Object With NSM on page 35
•
Linking to a Secure Virtual Workspace Wallpaper Image Shared Object With
NSM on page 35
•
Importing Hosted Java Applets With NSM on page 36
•
Importing a Custom Citrix Client .cab File With NSM on page 37
•
Junos Pulse Overview on page 37
Copyright © 2011, Juniper Networks, Inc.
15
Secure Access Administration Guide
•
Configuring the Junos Pulse Client for a Role on page 39
•
The Client Installer Package on page 40
•
Junos Pulse Configuration Overview on page 41
•
Client Connection Set Options on page 44
•
Creating a Client Connection Set on page 46
•
Configuring Connection Rules for Location Awareness on page 48
•
Junos Pulse Component Set Options on page 50
•
Creating a Client Component Set on page 51
•
Creating an Installer on page 52
SA Series Solution Overview
The Juniper Networks SA Series SSL VPN Appliances enable you to give employees,
partners, and customers secure and controlled access to your corporate data and
applications including file servers, Web servers, native messaging and e-mail clients,
hosted servers, and more from outside your trusted network using just a Web browser.
The SA Series SSL VPN Appliances provide robust security by intermediating the data
that flows between external users and your company’s internal resources. Users gain
authenticated access to authorized resources through an extranet session hosted by the
appliance. During intermediation, the SA Series SSL VPN Appliance receives secure
requests from the external, authenticated users and then makes requests to the internal
resources on behalf of those users. By intermediating content in this way, the SA Series
SSL VPN Appliance eliminates the need to deploy extranet toolkits in a traditional DMZ
or provision a remote access VPN for employees.
To access the intuitive SA Series home page, your employees, partners, and customers
need only a Web browser that supports SSL and an Internet connection. This page
provides the window from which your users can securely browse Web or file servers, use
HTML-enabled enterprise applications, start the client/server application proxy, begin a
Windows, Citrix, or Telnet/SSH terminal session, access corporate e-mail servers, start
a secured layer 3 tunnel, or schedule or attend a secure online meeting.
NOTE: These capabilities depend upon the Juniper Networks SA Series
product and upgrade options you have purchased
16
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
Figure 1: The SA Series Appliance Working within a LAN
You can configure a Juniper Networks SA Series SSL VPN Appliance in the following
ways:
•
Provide users with secure access to a variety of resources. The SA Series device
intermediates access to multiple types of applications and resources such as
Web-based enterprise applications, Java applications, file shares, terminal hosts, and
other client/server applications such as Microsoft Outlook, Lotus Notes, the Citrix ICA
Client, and pcAnywhere. Additionally, administrators can provision an access method
that allows full Layer 3 connectivity, providing the same level of access that a user
would get if they were on the corporate LAN.
•
Fine-tune user access to the appliance, resource types, or individual resources based
on factors such as group membership, source IP address, certificate attributes, and
endpoint security status. For instance, you can use dual-factor authentication and
client-side digital certificates to authenticate users to the SA Series SSL VPN Appliance
and use LDAP group membership to authorize users to access individual applications.
•
Assess the security status of your users’ computers by checking for endpoint defense
tools such as current antivirus software, firewalls, and security patches. You can then
allow or deny users access to the appliance, resource types, or individual resources
based on the computer’s security status.
The SA Series SSL VPN Appliance acts as a secure, Application Layer gateway
intermediating all requests between the public Internet and internal corporate resources.
All requests that enter the SA Series SSL VPN Appliance are already encrypted by the
end user's browser, using SSL/HTTPS 128-bit or 168-bit encryption—unencrypted requests
are dropped. Because the SA Series SSL VPN Appliance provides a robust security layer
between the public Internet and internal resources, administrators do not need to
constantly manage security policies and patch security vulnerabilities for numerous
different application and Web servers deployed in the public-facing DMZ.
Related
Documentation
•
Securing Traffic With SA Series Appliances on page 18
•
Authenticating Users With Existing Servers on page 19
Copyright © 2011, Juniper Networks, Inc.
17
Secure Access Administration Guide
•
Fine-Tuning Access to the SA Series SSL VPN Appliance and the Resources It
Intermediates on page 20
•
Creating a Seamless Integration Between the SA Series SSL VPN Appliance and the
Resources It Intermediates on page 21
•
Protecting Against Infected Computers and Other Security Concerns on page 21
•
Ensuring Redundancy in the SA Series Environment on page 22
•
Making the SA Series Interface Match My Company’s Look-and-Feel on page 22
•
Enabling Users on a Variety of Computers and Devices to Use the SA Series SSL VPN
Appliance on page 23
•
Providing Secure Access for My International Users on page 23
Securing Traffic With SA Series Appliances
The SA Series appliance enables you to secure access to a wide variety of applications,
servers, and other resources through its remote access mechanisms. Once you have
chosen which resource you want to secure, you can then choose the appropriate access
mechanism.
For instance, if you want to secure access to Microsoft Outlook, you can use the Secure
Application Manager (SAM). The Secure Application Manager intermediates traffic to
client/server applications including Microsoft Outlook, Lotus Notes, and Citrix. Or, if you
want to secure access to your company Intranet, you can use the Web rewriting feature.
This feature uses the SA Series Appliance’s Content Intermediation Engine to intermediate
traffic to Web-based applications and Web pages.
The SA Series SSL VPN Appliance includes remote access mechanisms that intermediate
the following types of traffic:
18
•
Web-based traffic, including Web pages and Web-based applications—Use the Web
rewriting feature to intermediate this type of content. The Web rewriting feature includes
templates that enable you to easily configure access to applications such as Citrix,
OWA, Lotus iNotes, and Sharepoint. In addition, you can use the Web rewriting custom
configuration option to intermediate traffic from a wide variety of additional Web-based
applications and Web pages, including custom-built Web applications.
•
Java applets, including Web applications that use Java applets—Use the hosted Java
applets feature to intermediate this type of content. This feature enables you to host
Java applets and the HTML pages that they reference directly on the SA Series
Appliance rather than maintaining a separate Java server.
•
File traffic, including file servers and directories—Use the file rewriting feature to
intermediate and dynamically “webify” access to file shares. The file rewriting feature
enables you to secure traffic to a variety of Windows and Unix based servers, directories,
and file shares.
•
Client/server applications—Use the Secure Application Manager (SAM) feature to
intermediate this type of content. SAM comes in two varieties (Windows and Java
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
versions, or WSAM and JSAM). The WSAM and JSAM features include templates that
enable you to easily configure access to applications such as Lotus Notes, Microsoft
Outlook, NetBIOS file browsing, and Citrix. In addition, you can use the WSAM and
JSAM custom configuration options to intermediate traffic from a wide variety of
additional client/server applications and destination networks.
Related
Documentation
•
Telnet and SSH terminal emulation sessions—Use the Telnet/SSH feature to
intermediate this type of content. This feature enables you to easily configure access
to a variety of networked devices that utilize terminal sessions including UNIX servers,
networking devices, and other legacy applications.
•
Windows Terminal Servers and Citrix server terminal emulation sessions— Use the
Terminal Services feature to intermediate this type of content. This feature enables
you to easily configure access to Windows Terminal Servers, Citrix MetaFrame Servers,
and Citrix Presentation Servers (formerly known as Nfuse servers). You can also use
this feature to deliver the terminal services clients directly from the SA Series Appliance,
eliminating the need to use another Web server to host the clients.
•
E-mail clients based on the IMAP4, POP3, and SMTP protocols—Use the email client
feature to intermediate this type of content. This feature enables you to easily configure
access to any corporate mail server based on the IMAP4, POP3, and SMTP protocols,
such as Microsoft Exchange Server and Lotus Notes Mail servers.
•
All network traffic—Use the Network Connect feature to create a secure, Layer 3 tunnel
over the SSL connection, allowing access to any type of application available on the
corporate network. This feature enables you to easily connect remote users into your
network by tunneling network traffic over port 443, enabling users full access to all of
your network resources without configuring access to individual servers, applications,
and resources.
•
SA Series Solution Overview on page 16
Authenticating Users With Existing Servers
You can easily configure the SA Series SSL VPN Appliance to use your company’s existing
servers to authenticate your end users—Users do not need to learn a new username and
password to access the SA Series device. The SA Series SSL VPN Appliance supports
integration with LDAP, RADIUS, NIS, Windows NT Domain, Active Directory, eTrust
SiteMinder, SAML, and RSA ACE/Servers.
Or, if you do not want to use one of these standard servers, you can store usernames and
credentials directly on the SA Series SSL VPN Appliance and use the SA Series SSL VPN
Appliance itself as an authentication server. In addition, you can choose to authenticate
users based on attributes contained in authentication assertions generated by SAML
authorities or client-side certificates. Or, if you do not want to require your users to sign
into the SA Series SSL VPN Appliance, you can use the SA Series anonymous
authentication server, which allows users to access the SA Series SSL VPN Appliance
without providing a username or password.
Copyright © 2011, Juniper Networks, Inc.
19
Secure Access Administration Guide
Related
Documentation
•
SA Series Solution Overview on page 16
•
About Authentication and Directory Servers on page 138
Fine-Tuning Access to the SA Series SSL VPN Appliance and the Resources It
Intermediates
In addition to using authentication servers to control access to the SA Series SSL VPN
Appliance, you can control access to the SA Series SSL VPN Appliance and the resources
it intermediates using a variety of additional client-side checks. The SA Series SSL VPN
Appliance enables you to create a multilayered approach to protect the SA Series SSL
VPN Appliance and your resources:
1.
First, you can perform preauthentication checks that control user access to the SA
Series sign-in page. For instance, you might configure the SA Series SSL VPN Appliance
to check whether or not the user’s computer is running a particular version of Norton
Antivirus. If it is not running, you can determine that the user’s computer is unsecure
and disable access to the SA Series sign-in page until the user has updated the
computer’s antivirus software.
2. Once a user has successfully accessed the SA Series sign-in page, you can perform
realm-level checks to determine whether he can access the SA Series end-user home
page. The most common realm-level check is performed by an authentication server.
(The server determines whether the user enters a valid username and password.)
You can perform other types of realm-level checks, however, such as checking that
the user’s IP address is in your network or that the user is using the Web browser type
that you specify.
If a user passes the realm-level checks that you specify, the user can access the SA
Series end-user home page. Otherwise, the SA Series SSL VPN Appliance does not
enable the user to sign in, or the SA Series SSL VPN Appliance displays a “stripped
down” version of the SA Series home page that you create. Generally, this stripped
down version contains significantly less functionality than is available to your standard
users because the user has not passed all of your authentication criteria. The SA Series
SSL VPN Appliance provides extremely flexible policy definitions, enabling you to
dynamically alter end-user resource access based on corporate security policies.
3. After the SA Series SSL VPN Appliance successfully assigns a user to a realm, the
appliance maps the user to a role based on your selection criteria. A role specifies
which access mechanisms a selected group of users can access. It also controls
session and UI options for that group of users. You can use a wide variety of criteria
to map users to roles. For instance, you can map users to different roles based on
endpoint security checks or on attributes obtained from an LDAP server or client-side
certificate.
4. In most cases, a user’s role assignments control which individual resources the user
can access. For instance, you might configure access to your company’s Intranet page
using a Web resource profile and then specify that all members of the Employees role
can access that resource.
20
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
However, you can choose to further fine-tune access to individual resources. For instance,
you may enable members of the Employees role to access your company’s Intranet (as
described earlier), but add a resource policy detailed rule that requires users to meet
additional criteria to access the resource. For example, you may require users to be
members of the Employees role and to sign into the SA Series SSL VPN Appliance during
business hours to access your company Intranet.
Related
Documentation
•
SA Series Solution Overview on page 16
•
Access Management Overview on page 57
Creating a Seamless Integration Between the SA Series SSL VPN Appliance and the
Resources It Intermediates
In a typical SA Series configuration, you could add bookmarks directly to the SA Series
end-user home page. These bookmarks are links to the resources that you configure the
SA Series SSL VPN Appliance to intermediate. Adding these bookmarks enables users
to sign into a single place (the SA Series SSL VPN Appliance) and find a consolidated
list of all of the resources available to them.
Within this typical configuration, you can streamline the integration between the SA
Series SSL VPN Appliance and the intermediated resources by enabling single sign-on
(SSO). SSO is a process that allows preauthenticated SA Series users to access other
applications or resources that are protected by another access management system
without having to re-enter their credentials. During SA Series configuration, you can
enable SSO by specifying user credentials that you want the SA Series SSL VPN Appliance
to pass to the intermediated resources.
Or, if you do not want to centralize user resources on the SA Series end-user home page,
you could create links to the SA Series-intermediated resources from another Web page.
For instance, you can configure bookmarks on the SA Series SSL VPN Appliance, and
then add links to those bookmarks from your company’s Intranet. Your users can then
sign into your company Intranet and click the links there to access the intermediated
resources without going through the SA Series home page. As with standard SA Series
bookmarks, you can enable SSO for these external links.
Related
Documentation
•
SA Series Solution Overview on page 16
•
About Single Sign-On on page 237
Protecting Against Infected Computers and Other Security Concerns
The SA Series SSL VPN Appliance enables you to protect against viruses, attacks, and
other security concerns using the Host Checker feature. Host Checker performs security
checks on the clients that connect to the SA Series SSL VPN Appliance. For instance,
you can use Host Checker to verify that end-user systems contain up-to-date antivirus
software, firewalls, critical software hotfixes, and other applications that protect your
users’ computers. You can then enable or deny users access to the SA Series sign-in
pages, realms, roles, and resources based on the results that Host Checker returns. Or,
Copyright © 2011, Juniper Networks, Inc.
21
Secure Access Administration Guide
you can display remediation instructions to users so they can bring their computers into
compliance
You can also use Host Checker to create a protected workspace on clients running
Windows 2000 or Windows XP. Through Host Checker, you can enable the Secure Virtual
Workspace (SVW) feature to create a protected workspace on the client desktop, ensuring
that any end user signing in to your intranet must perform all interactions within a
completely protected environment. Secure Virtual Workspace encrypts information that
applications write to disk or the registry and then destroys all information pertaining to
itself or the SA Series session when the session is complete.
You can also secure your network from hostile outside intrusion by integrating your SA
Series SSL VPN Appliance with a Juniper Networks Intrusion Detection and Prevention
(IDP) sensor. You can use IDP devices to detect and block most network worms based
on software vulnerabilities, non-file-based Trojan horses, the effects of Spyware, Adware,
and Key Loggers, many types of malware, and zero day attacks through the use of anomaly
detection.
Related
Documentation
•
SA Series Solution Overview on page 16
•
Configuring the SA Series SSL VPN Appliance to Interoperate with IDP on page 929
Ensuring Redundancy in the SA Series Environment
You can ensure redundancy in your SA Series environment using the SA Series SSL VPN
Appliance clustering feature. With this feature, you can deploy two or more appliances
as a cluster, ensuring no user downtime in the rare event of failure and stateful peering
that synchronizes user settings, system settings, and user session data.
These appliances support active/passive or active/active configurations across a LAN
or a WAN. In Active/Passive mode, one SA Series SSL VPN Appliance actively serves
user requests while the other SA Series SSL VPN Appliance runs passively in the
background to synchronize state data. If the active SA Series SSL VPN Appliance goes
offline, the SA Series SSL VPN Appliance automatically starts servicing user requests.
In active/active mode, all the machines in the cluster actively handle user requests sent
by an external load balancer or round-robin DNS. The load balancer hosts the cluster
VIP and routes user requests to an SA Series SSL VPN Appliance defined in its cluster
group based on source-IP routing. If an SA Series SSL VPN Appliance goes offline, the
load balancer adjusts the load on the active SA Series SSL VPN Appliance.
Related
Documentation
•
SA Series Solution Overview on page 16
Making the SA Series Interface Match My Company’s Look-and-Feel
The SA Series SSL VPN Appliance enables you to customize a variety of elements in the
end-user interface. Using these customization features, you can update the look-and-feel
of the SA Series end-user console so it will resemble one of your standard company Web
pages or applications.
22
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
For instance, you can easily customize the headers, background colors, and logos that
the SA Series SSL VPN Appliance displays in the SA Series sign-in page and end-user
console to match your company’s style. You can also easily customize the order in which
the SA Series SSL VPN Appliance displays bookmarks and the help system that the SA
Series SSL VPN Appliance displays to users.
Or, if you do not want to display the SA Series end-user home page to users (either in
standard or customized form), you can choose to redirect users to a different page (such
as your company Intranet) when users first sign into the SA Series SSL VPN Appliance
console. If you choose to use this option, you may want to add links to your SA Series
bookmarks on the new page.
If you want to further customize the SA Series sign-in page, you can use the SA Series
SSL VPN Appliance’s custom sign-in pages feature. Unlike the standard customization
options that you can configure through the SA Series SSL VPN Appliance admin console,
the custom sign-in pages feature does not limit the number of customizations you can
make to your pages. Using this feature, you can use an HTML editor to develop a sign-in
page that exactly matches your specifications.
Related
Documentation
•
SA Series Solution Overview on page 16
•
Creating a Seamless Integration Between the SA Series SSL VPN Appliance and the
Resources It Intermediates on page 21
•
Customizable Admin and End-User UIs on page 945
Enabling Users on a Variety of Computers and Devices to Use the SA Series SSL VPN
Appliance
In addition to allowing users to access the SA Series SSL VPN Appliance from standard
workstations and kiosks running Windows, Macintosh, and Linux operating systems, the
SA Series SSL VPN Appliance also allows end users to access the SA Series SSL VPN
Appliance from connected PDAs, handhelds and smart phones such as i-mode and
Pocket PC. When a user connects from a PDA or handheld device, the SA Series SSL
VPN Appliance determines which SA Series pages and functionality to display based on
settings that you configure.
For more information about specifying which pages the SA Series SSL VPN Appliance
displays to different devices, see the SA Series supported platforms document available
on the SSL VPN OS Software page of the Juniper Networks Customer Support Center.
Related
Documentation
•
SA Series Solution Overview on page 16
•
Handheld Devices and PDAs on page 991
Providing Secure Access for My International Users
The SA Series SSL VPN Appliance supports English (US), French, German, Spanish,
Simplified Chinese, Traditional Chinese, Japanese, and Korean. When your users sign into
the SA Series SSL VPN Appliance, the SA Series SSL VPN Appliance automatically
Copyright © 2011, Juniper Networks, Inc.
23
Secure Access Administration Guide
detects the correct language to display based on the user’s Web browser setting. Or, you
can use end-user localization and custom sign-in pages options to manually specify the
language that you want to display to your end users.
Related
Documentation
•
SA Series Solution Overview on page 16
•
About Multi-Language Support for the SA Series SSL VPN Appliance on page 987
Configuring the SA Series SSL VPN Appliance
To enable users to start using your SA Series SSL VPN Appliance, you must complete
the following basic steps:
1.
Plug in the appliance, connect it to your network, and configure its initial system and
network settings. This quick and easy process is detailed in the SA Series SSL VPN
Appliance Quick Start Guide.
2. After you connect the SA Series SSL VPN Appliance to your network, you need to set
the system date and time, upgrade to the latest service package, and install your
product licenses. When you first sign into the admin console, the SA Series SSL VPN
Appliance displays an initial configuration task guide that quickly walks you through
this process.
3. After you install your product licenses, you need to set up your access management
framework to enable your users to authenticate and access resources. Configuration
steps include:
a. Define an authentication server that verifies the names and passwords of your
users.
b. Create user roles that enable access mechanisms, session options, and UI options
for user groups.
c. Create a user authentication realm that specifies the conditions that users must
meet to sign into the SA Series SSL VPN Appliance.
d. Define a sign-in policy that specifies the URL that users must access to sign into
the SA Series SSL VPN Appliance and the page that they see when they sign in.
e. Create resource profiles that control access to resources, specify which user roles
can access them, and include bookmarks that link to the resources.
The SA Series SSL VPN Appliance includes a task guide in its admin console that
quickly walks you through this process. To access this task guide, click the Guidance
link located in the upper right corner of the admin console. Then, under Recommended
Task Guides, select Base Configuration.
Once you have completed these basic steps, your SA Series SSL VPN Appliance is ready
for use. You can start using it as is, or configure additional advanced features such as
endpoint defense and clustering.
24
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
Related
Documentation
•
Creating a Test Scenario to Learn SA Series Appliance Concepts and Best Practices
on page 4
Network and Security Manager and the Infranet Controller
Network and Security Manager (NSM) is Juniper Networks network management tool
that allows distributed administration of network appliances. You can use the NSM
application to centralize status monitoring, logging, and reporting, and to administer SA
Series configurations.
With NSM you can manage most of the parameters that you can configure through the
SA Series admin console. The configuration screens rendered through NSM are similar
to the SA Series SSL VPN Appliance’s native interface.
NSM incorporates a broad configuration management framework that allows
co-management using other methods. You can import and export XML via the SA Series
SSL VPN Appliance’s admin console interface, or you can manage from the SA Series
SSL VPN Appliance’s admin console.
How the SA Series SSL VPN Appliance and NSM communicate
The SA Series SSL VPN Appliance and the NSM application communicate through the
Device Management Interface (DMI). DMI is a collection of schema-driven protocols that
run on a common transport (TCP). DMI is designed to work with Juniper Networks
platforms to make device management consistent across all administrative realms. The
DMI protocols that are supported include NetConf (for inventory management, XML-based
configuration, text-based configuration, alarm monitoring, and devicespecific commands),
structured syslog, and threat flow for network profiling. DMI supports third-party network
management systems that incorporate the DMI standard, however only one DMI-based
agent per device is supported.
The SA Series SSL VPN Appliance’s configuration is represented as a hierarchical tree
of configuration items. This structure is expressed in XML that can be manipulated with
NetConf. NetConf is a network management protocol that uses XML. DMI uses NetConf’s
generic configuration management capability and applies it to allow remote configuration
of the device.
To allow NSM to manage the SA Series SSL VPN Applianceusing the DMI protocol, NSM
must import the schema and meta-data files from the Juniper Schema Repository, a
publicly-accessible resource that is updated with each device release. In addition to
downloading the SA Series SSL VPN Appliance’s current schema, NSM may also download
upgraded software.
The Schema Repository enables access to XSD and XML files defined for each device,
model and software version.
Before attempting to communicate with NSM, you must first complete the initial
configuration of the SA Series SSL VPN Appliance. Initial configuration includes network
interface settings, DNS settings, licensing, and password administration.
Copyright © 2011, Juniper Networks, Inc.
25
Secure Access Administration Guide
If you have several SA Series SSL VPN Appliances that will be configured in a clustering
environment, the cluster abstraction must first be created in the NSM Cluster Manager.
Then, you can add individual nodes. NSM cannot auto-detect cluster membership.
After you have completed the initial network configuration, you can configure your SA
Series SSL VPN Appliance to communicate with NSM using the appropriate network
information. Once the SA Series SSL VPN Appliance has been configured to communicate
with NSM, the SA Series SSL VPN Appliance contacts NSM and establishes a DMI session
through an initial TCP handshake.
All communications between the SA Series SSL VPN Appliance and NSM occur over
SSH to ensure data integrity.
After the SA Series SSL VPN Appliance initially contacts NSM and a TCP session is
established, interaction between the SA Series SSL VPN Appliance and NSM is driven
from NSM, which issues commands to get hardware, software, and license details of the
SA Series SSL VPN Appliance. NSM connects to the Schema Repository to download
the configuration schema that is particular to the SA Series SSL VPN Appliance.
NSM then issues a command to retrieve configuration information from the SA Series
SSL VPN Appliance. If NSM is contacted by more than one SA Series SSL VPN Appliance
as a member of a cluster, information from only one of the cluster devices is gathered.
NSM attempts to validate the configuration received from the SA Series SSL VPN
Appliance against the schema from Juniper Networks.
Once the SA Series SSL VPN Appliance and NSM are communicating, the SA Series SSL
VPN Appliance delivers syslog and event information to NSM.
After NSM and the SA Series SSL VPN Appliance are connected, you can make any
configuration changes directly on the SA Series SSL VPN Appliance, bypassing NSM.
NSM automatically detects these changes and imports the new configuration data.
Changes to SA Series cluster members will similarly be detected by NSM.
When you make changes to the SA Series configuration through NSM you must push the
changes to the device by performing an Update Device operation.
When you double-click the SA Series SSL VPN Appliance icon in the Device Manager and
select the Config tab, the configuration tree appears in the main display area in the same
orientation as items appears on the SA Series interface.
Available Services and Configuration Options
The following services and options are provided to NSM by the SA Series SSL VPN
Appliance:
26
•
Inventory management service—inventory management service enables management
of the SA Series SSL VPN Appliance software, hardware, and licensing details. Adding
or deleting licenses is not supported, however upgrading/downgrading software is
supported.
•
Status monitoring service—status monitoring service allows SA Series SSL VPN
Appliance’s status to be obtained, including name, domain, OS version, synchronization
status, connection details, and current alarms.
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
•
Logging service—logging service allow the SA Series SSL VPN Appliance logs to be
obtained in a time-generated order. Logging configuration details that are set on the
SA Series SSL VPN Appliance will apply to NSM.
•
XML-based configuration management service—configuration management service
enables NSM to manage the configuration of the SA Series SSL VPN Appliance. NSM
uses the same XML Schema as the SA Series SSL VPN Appliance, so you can
troubleshoot NSM using XML files downloaded from the SA Series SSL VPN Appliance.
The following device configuration items are not supported:
•
Editing licensing information, (though licenses can be viewed)
•
Creating clusters, joining nodes to clusters, or enabling or disabling cluster nodes
•
Packaging log files or debug files for remote analysis
•
Rebooting the SA Series SSL VPN Appliance
DMI Communication with the SA Series SSL VPN Appliance
To configure the SA Series SSL VPN Appliance to communicate with NSM you must
coordinate actions between the SA Series SSL VPN Appliance and NSM administrators.
Items such as IP address, password, HMAC key (a one-time password), and the device
ID must be shared between administrators of both the Secure Access device and NSM.
To connect the SA Series SSL VPN Appliance and NSM you will need to do the following:
Related
Documentation
•
Install and configure the SA Series SSL VPN Appliance.
•
Add the SA Series SSL VPN Appliance as a device in NSM.
•
Configure and activate the DMI agent on the SA Series SSL VPN Appliance.
•
Confirm connectivity and import the SA Series configuration into NSM.
•
Configuring Secure Access for the Initial DMI Connection on page 27
•
Managing Large Binary Data Files on page 29
•
Uploading and Linking Large Binary Data Files With NSM on page 30
Configuring the SA Series SSL VPN Appliance for the Initial DMI Connection
To permit the SA Series SSL VPN Appliance and NSM to make an initial connection, you
must add an NSM administrative user to the SA Series configuration. This section provides
a summary of adding the NSM administrator and configuring the DMI agent to allow the
SA Series SSL VPN Appliance and NSM to communicate. Complete configuration of the
SA Series SSL VPN Appliance for authenticating users is outside the scope of this section.
Copyright © 2011, Juniper Networks, Inc.
27
Secure Access Administration Guide
To initiate a DMI session for communication between the SA Series SSL VPN Appliance
and NSM:
1.
Ensure that basic connection information is configured on the SA Series SSL VPN
Appliance (network address, DNS, password).
2. Ensure that the proper licenses are installed on the SA Series SSL VPN Appliance.
3. (Optional) Select the Administrator authentication server if you want to use that
server for authentication of NSM’s device administrator, and create an admin user to
allow NSM to use these credentials to connect to manage the device.
NOTE: Only password-based authentication servers can be used. one-time
password authentication is not supported.
4. (Optional) Select Administrators > Admin Roles and create a DMI agent administrator
role.
5. (Optional) Select Administrators > Admin Realms and create a new DMI agent admin
realm for the DMI agent of the SA Series Appliance and use role mapping to associate
the DMI agent role and realm.
6. On the NSM interface, select the Domain menu and choose the domain to which the
SA Series SSL VPN Appliance will be added.
NOTE: You must enter a unique NSM admin username and password on
the NSM UI client. This username will be used on the SA Series Appliance
as the username for the administrator acocunt that will be used to manage
the SA Series Appliance. NSM must have a unique account login to avoid
interrupting the communication with the SA Series Appliance. NSM
automatically generates a unique ID which is used for the HMAC key.
NOTE:
• In a clustering environment, each cluster-node must have its own unique
DMI agent and its own device-id and HMAC key, as each cluster node
maintains its own persistent DMI connection to the management
application.
•
The HMAC key and the device id are hashed to identify individual devices
to the application. Juniper recommends that you use a strong password
for the HMAC key value to ensure that the key isn’t guessed.
7. In Device Manager, click the Add icon and select Device to open the Add Device wizard,
and enter the applicable information required to add an SA Series SSL VPN Appliance
to NSM. See Network and Security Manager Administration Guide.
8. After you have added the SA Series SSL VPN Appliance to NSM, select System >
Configuration > DMI Agent on the SA Series admin console.
28
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
9. Under DMI connection, select the:
•
Inbound Enabled check box if you are using an SSH secure shell Command Line
Interface (CLI) to manage the SA Series SSL VPN Appliance. The SA Series SSL
VPN Appliance can also be managed by integrating an SSH-aware netconf that
complies with Juniper Network’s DMI specification.
•
Outbound Enabled check box if you are configuring the SA Series SSL VPN Appliance
to communicate with NSM.
NOTE: When you enable or disable a connection, it takes a few minutes
for the connection state to be updated.
10. Under DMI settings for inbound connections, enter the TCP port in which the SA Series
SSL VPN Appliance should accept connections. This TCP port should not be used by
any other SA Series processes. We recommend you use the default port or a port
number larger than 1024.
11. Under DMI settings for outbound connection, enter the NSM Primary Server IP address
or hostname, Primary Port, Backup Server and Backup Port (if applicable), the Device
ID, and the HMAC Key.
12. Select the Admin realm that you have configured for the DMI agent.
The SA Series SSL VPN Appliance initiates a TCP connection to NSM. After the SA Series
SSL VPN Appliance is identified to NSM through the HMAC key and device ID hash, The
SA Series SSL VPN Appliance and NSM negotiate an SSH tunnel, and NSM requests
authentication to the SA Series SSL VPN Appliance based on the username and password.
If you need to disconnect the device from NSM, you can either disable the DMI agent
from the device, or you can delete the device from the NSM interface. If the DMI connection
is later reestablished, NSM will automatically retrieve any configuration changes, as well
as logs that have accumulated in the interim.
To add an SA Series cluster in NSM, you first add the cluster, then you add each member.
Adding a member is similar to adding a standalone SA Series SSL VPN Appliance. You
must have a cluster object and all of the cluster members defined in NSM to allow NSM
to access the cluster.
Managing Large Binary Data Files
Large binary data files that form a part of the configuration of the SA Series SSL VPN
Appliance are handled differently from the remainder of the configuration in NSM. The
size of some of these binary files could cause configurations to be so large as to overload
resources on the NSM server. Consequently, only the large binary files you specify get
imported into NSM, and those files are configured as shared objects, which avoids
duplication if applied to multiple devices.
With NSM, large binary data files are not imported with the rest of the configuration
during a normal device import operation. Instead, the file is represented in the device
Copyright © 2011, Juniper Networks, Inc.
29
Secure Access Administration Guide
configuration tree by a stub containing an MD5 hash and file length designation. If you
need to manage such a file in NSM, you upload the file separately, and configure it as a
shared object. To include the file as part of the device object in NSM, you must then
establish a link between the node in the device configuration tree and the shared binary
data object. When you establish the link, a pointer to the shared binary data object
replaces the MD5 hash and length.
After you establish the link, an Update Device directive pushes all linked binary data files
to the device along with the rest of the device configuration. No binary data is pushed
for nodes that still contain the MD5 hash and length designators.
If you do not need to manage a large binary data file from NSM, then you do not need to
include it in the device object configuration. For example, suppose you have a hosted
Java applet that resides on a SA Series SSL VPN Appliance, and you have no intention
of updating this applet. In this case, no shared object creation or file upload is necessary.
NSM device objects will contain only the MD5 hash stub for these endpoints. Any delta
configuration operation between NSM and the device will indicate identical configurations
because the MD5 hash in NSM will match the file on the device. For the same reasons,
an Update Device directive will have no effect on the device.
Related
Documentation
•
Uploading and Linking Large Binary Data Files With NSM on page 30
Uploading and Linking Large Binary Data Files With NSM
This topic describes the complete procedure for downloading a large binary data file and
linking that file into the SA Series SSL VPN Appliance configuration tree.
To upload and link a large binary data file:
1.
In the Device Manager, right-click the device icon and select Import Device from the
list to Import the SA Series SSL VPN Appliance configuration.
When the import job is finished, the device object configuration contains the MD5
stubs for each of the large binary data files.
2. Upload each required large binary data file onto the NSM client workstation.
You'll need to get some files from the SA Series SSL VPN Appliance. Other files, such
as ESAP configuration files, should be downloaded form the site of origin. Use the
device Web UI to upload binary files from the SA Series SSL VPN Appliance.
3. To create a shared object in the NSM Object Manager for the binary file:
a. In the Configure panel of the NSM navigation tree, select Object Manager > Binary
data , and then click the Add icon.
30
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
b. In the Binary Data dialog box, enter a name for the object, select a color for the
object icon, add a comment if desired, and select the file you uploaded in step 2.
Click OK.
4. Link the shared object to the corresponding node in the device configuration tree:
a. In the Device Manager, double-click the SA Series SSL VPN Appliance to open the
device editor, and then select the Configuration tab.
b. Navigate to the node in the configuration where you want to load the binary file.
For example, to load an ESAP package, expand Authentication and then select
Endpoint Security. In the Host Checker tab, select Endpoint Security Assessment
Plug-Ins, and then click the Add icon.
c. Select the shared object.
To continue the ESAP example, in the New Endpoint Security Assessment Plug-Ins
dialog box, enter a version number, select a shared binary data object from the
Path to Package list. This list includes all shared binary data objects. Click OK.
If the object you want is not in the list, you can add it to the shared binary data list
by clicking the Add icon. The Binary Data dialog box appears as in step 3.
d. Click OK to save the newly configured links.
Related
Documentation
•
Managing Large Binary Data Files on page 29
Importing Custom Sign-In Pages With NSM
The customized sign-in pages feature is a licensed feature that enables you to use your
own access pages rather than having to modify the sign-in page included with the SA
Series SSL VPN Appliance.
To create a link from a SA Series configuration tree to a shared object containing a custom
sign-in access page:
1.
In the Device Manager, double-click the SA Series SSL VPN Appliance to open the
device editor, and then select the Configuration tab.
2. Expand Authentication.
3. Expand Signing-In.
4. Expand Sign-in Pages.
5. Select Users/Administrator Sign-in Pages, and then click the Add icon in the right
pane.
6. Enter a name for the access page.
7. Select Custom Sign-in Pages.
Copyright © 2011, Juniper Networks, Inc.
31
Secure Access Administration Guide
8. Select a shared binary data object from the Custom Pages Zip File list.
9. Click OK once to save the link, and again to save the configuration.
To create a link from a SA Series configuration tree to a shared object containing a custom
sign-in meeting page:
1.
In the Device Manager, double-click the SA Series SSL VPN Appliance to open the
device editor, and then select the Configuration tab.
2. Expand Authentication.
3. Expand Signing-In.
4. Expand Sign-in Pages.
5. Select Meeting Sign-in Pages, and then click the Add icon in the right pane.
6. Enter a name for the sign-in meeting page.
7. Select Custom Sign-in Page.
8. Select a shared binary data object from the Blob list.
9. Click OK once to save the link, and again to save the configuration.
Related
Documentation
•
Configuring Sign-In pages on page 234
Importing Antivirus LiveUpdate Settings With NSM
Retrieve the latest AV liveupdate file from the Juniper Downloads Web site at
https://download.juniper.net/software/av/uac/epupdate_hist.xml.
Retrieve the latest patch file from the Juniper Download Web site at
https://download.juniper.net/software/hc/patchdata/patchupdate.dat.
To create a link from a SA Series configuration tree to a shared object containing an
antivirus (AV) liveupdate file:
1.
In the Device Manager, double-click the SA Series SSL VPN Appliance to open the
device editor, and then select the Configuration tab.
2. Expand Authentication.
3. Select Endpoint Security.
4. From the Host Checker tab, select Live Update Settings.
5. Select a shared binary data object from the Manually import virus signature list.
6. Click OK to save the configuration.
32
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
To create a link from an SA Series configuration tree to a shared object containing an AV
patch liveupdate file:
1.
In the Device Manager, double-click the SA Series SSL VPN Appliance to open the
device editor, and then select the Configuration tab.
2. Expand Authentication.
3. Select Endpoint Security.
4. From the Host Checker tab, select Live Update Settings.
5. Select a shared binary data object from the Manually import patch management data
list.
6. Click OK to save the configuration.
Related
Documentation
•
Uploading a Third-Party Host Checker Policy With NSM on page 34
•
Host Checker and Trusted Network Computing on page 274
Importing Endpoint Security Assessment Plug-in (ESAP) Packages With NSM
The Endpoint Security Assessment Plug-in (ESAP) on the SA Series SSL VPN Appliance
checks third-party applications on endpoints for compliance with the predefined rules
you configure in a Host Checker policy.
To upload the Endpoint Security Assessment Plug-in from the Juniper Networks Customer
Support Center to your NSM client computer:
1.
Open the page https://www.juniper.net/customers/csc/software/ive/.
2. To access the Customer Support Center, enter a user name and password for a Juniper
Networks Support account.
3. Click the ESAP link.
4. Click the ESAP Download Page link.
5. Navigate to the ESAP release you want.
6. Upload the plug-in zip file to your computer.
To create a link from an SA Series configuration tree to a shared object containing an
ESAP package:
1.
In the Device Manager, double-click the SA Series SSL VPN Appliance to open the
device editor, and then select the Configuration tab.
2. Expand Authentication.
3. Select Endpoint Security.
4. From the Host Checker tab, select Endpoint Security Assessment Plug-Ins, and then
click the Add icon.
Copyright © 2011, Juniper Networks, Inc.
33
Secure Access Administration Guide
5. In the New Endpoint Security Assessment Plug-Ins dialog box, enter an ESAP version
number.
6. Select a shared binary object from the Path to Package list.
7. Click OK once to save the link, and again to save the configuration.
Uploading a Third-Party Host Checker Policy With NSM
For the device to recognize a package definition file, you must:
1.
Name the package definition file MANIFEST.HCIF and include it in a folder named
META-INF.
2. Create a Host Checker policy package by creating a zip archive. The archive should
include the META-INF folder that contains the MANIFEST.HCIF file along with the
interface DLL and any initialization files. For example, a Host Checker policy package
might contain:
META-INF/MANIFEST.HCIF
hcif-myPestPatrol.dll
hcif-myPestPatrol.ini
3. Upload the Host Checker package (or packages) to the NSM shared object. You can
upload multiple policy packages to NSM shared objects, each containing a different
MANIFEST.HCIF file.
NOTE: After you upload a Host Checker policy package to the NSM shared
object, you cannot modify the package contents. Instead, you must modify
the package on your local system and then upload the modified version
to NSM.
4. Implement the policy at the realm, role, or resource policy levels using the options.
If you want to verify that the package itself is installed and running on the client
computer (as opposed to a specific policy in the package passing or failing) you can
use the name you specified when you uploaded the policy package (for example,
myPestPatrol). To enforce a particular policy in the package, use the syntax
package-name.policy-name. For example, to enforce the FileCheck policy in the
myPestPatrol package, use myPestPatrol.FileCheck.
Related
Documentation
34
•
Host Checker and Trusted Network Computing on page 274
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
Linking to a Third-Party Host Checker Policy Shared Object With NSM
To create a link from an SA Series configuration tree to a shared object containing a
third-party host checker policy:
1.
In the Device Manager, double-click the SA Series SSL VPN Appliance to open the
device editor, and then select the Configuration tab.
2. Expand Authentication.
3. Select Endpoint Security.
4. From the Host Checker tab, select the Settings tab, and then click the Add icon in the
Policies box.
5. From the Policy type list, select 3rd Party Policy.
6. Give the policy a name.
7. Select a shared binary data object from the Package list.
8. Click OK to save the configuration.
Related
Documentation
•
Host Checker and Trusted Network Computing on page 274
Linking to a Secure Virtual Workspace Wallpaper Image Shared Object With NSM
To create a link from an SA Series configuration tree to a shared object containing a
secure virtual workspace wallpaper image:
1.
In the Device Manager, double-click the SA Series SSL VPN Appliance to open the
device editor, and then select the Configuration tab.
2. Expand Authentication.
3. Select Endpoint Security.
4. From the Host Checker tab, select the Settings tab, and then click the Add icon in the
Policies box.
5. From the Policy type list, select Secure Virtual Workspace Policy.
6. Select the Options tab.
7. Select a shared binary data object from the Desktop wallpaper image list.
8. Click OK to save the configuration.
Related
Documentation
•
Enabling the Secure Virtual Workspace on page 330
Copyright © 2011, Juniper Networks, Inc.
35
Secure Access Administration Guide
Importing Hosted Java Applets With NSM
You can store Java applets of your choice as shared objects in NSM without using a
separate Web server to host them. You can then use these applets to intermediate traffic
to various types of applications through the SA Series SSL VPN Appliance. For example,
you can upload the 3270 applet, 5250 applet, or Citrix Java applet to shared NSM objects.
These applets enable users to establish sessions to IBM mainframes, AS/400s, and Citrix
MetaFrame servers through terminal emulators. To enable the Citrix Java ICA client
through an SA Series Appliance session, you must upload multiple Citrix .jar and .cab
files or configure a Citrix Terminal Services resource profile to host the Java applets.
You can upload individual .jar and .cab files or .zip, .cab, or .tar archive files to NSM shared
objects. Archive files can contain Java applets and files referenced by the applets. Within
the .zip, .cab, or .tar file, the Java applet must reside at the top level of the archive.
To ensure compatibility with both Sun and Microsoft Java Virtual Machines (JVMs), you
must upload both .jar and .cab files. The Sun JVM uses .jar files, whereas the Microsoft
JVM uses .cab files.
NOTE: When you upload Java applets to NSM, NSM asks you to read a legal
agreement before it finishes installing the applets. Please read this agreement
carefully.it obligates you to take full responsibility for the legality, operation,
and support of the Java applets that you upload.
Uploading Java applets requires signed ActiveX or signed Java applets to be
enabled within the browser to download, install, and launch the client
applications.
To create a link from an SA Series configuration tree to a shared object containing a Java
applet:
1.
In the Device Manager, double-click the SA Series SSL VPN Appliance to open the
device editor, and then select the Configuration tab.
2. Expand Users.
3. Expand Resource Profiles.
4. Select Hosted Java Applets, and then click the Add icon in the right pane.
5. Give the applet and file each a name.
6. Select a shared binary data object from the Applet file to be uploaded list.
7. Click OK once to save the link, and then again to save the configuration.
Related
Documentation
36
•
About Hosted Java Applet Templates on page 347
•
Task Summary: Hosting Java Applets on page 348
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
Importing a Custom Citrix Client .cab File With NSM
The custom Citrix client file enables you to provision the Citrix client from the SA Series
SSL VPN Appliance instead of requiring that it be pre-installed on end-user machines or
downloaded from some other web server.
To create a link from an SA Series SSL VPN Appliance configuration tree to a shared
object containing a Custom Citrix .cab file:
In the Device Manager, double-click the SA Series SSL VPN Appliance to open the
device editor, and then select the Configuration tab.
1.
2. Expand Users.
3. Select User Roles.
4. Select the Global Role Options tab.
5. In the Global Terminal Services Role Options tab, select a shared binary data object
from the Citrix Client CAB File list.
6. Click OK to save the configuration.
Related
Documentation
•
Configuring a Citrix XenDesktop Resource Policy on page 120
•
Creating Resource Profiles Using Citrix Web Applications on page 365
Junos Pulse Overview
Junos Pulse does not replace OAC or NC, but it does support all the connection methods
that you can use with OAC (Layer 2 and Layer 3 connectivity, and wired or wireless
connections). Junos Pulse also supports static and dynamic IPsec and Source IP
enforcement as a UAC client. An 802.1X connection with UAC is supported on Windows
XP SP3, Windows Vista, and Windows 7 by using components of the native Windows
supplicant. Junos Pulse supports SSL transport for SSL VPN tunnels to SA Series devices.
The initial release of Junos Pulse does not offer feature parity with OAC and NC. However,
future releases of the Junos Pulse client will incorporate a subset of existing OAC and
NC functionality.
Junos Pulse provides the same client WAN optimization services as the existing WX Client
software.
Session Migration
One of the primary benefits of Junos Pulse is that users can log in once through a device
on the network, and then to access additional devices without needing reauthentication.
Using Junos Pulse, you can permit users to migrate from location to location without
having the need for reauthentication. For example, a user can connect from home through
an SA Series Appliance, and then arrive at work and connect through an IC Series device
without having to log in again. Session migration also enables users to access different
Copyright © 2011, Juniper Networks, Inc.
37
Secure Access Administration Guide
resources within the network that are protected by Juniper Networks devices without
repeatedly providing credentials. IF-MAP Federation is required to enable session migration
for users.
Location Awareness
The location awareness feature enables you to define connections that are activated
automatically based on the location of the endpoint. Pulse determines the location of
the endpoint by evaluating location awareness rules that you define. Location awareness
rules are based on the client’s IP address and interface. For example, you can define rules
to enable Junos Pulse to automatically establish a secure tunnel to the corporate network
through a SA Series Appliance only when the user is at home, and to establish a UAC
connection when the user is connected to the corporate network over the LAN. You
configure the location awareness feature by defining location awareness rules for
individual connections.
Location awareness rules are available for connections that are defined on the access
device and then distributed to endpoints. A user cannot configure the location awareness
feature by manually creating a connection on the Junos Pulse client.
Security Certificates on Junos Pulse
Users cannot add CA servers or manage the server list. Pulse handles certificates similar
to how a browser handles certificates. If the Pulse dynamic certificate trust option is
enabled for a connection, the user can accept or deny the certificate that is presented if
it is one that is not from a certificate authority that is defined in the endpoint’s certificate
store.
An 802.1X connection enables on further layer of certificate verification. When you define
an 802.1X connection on the access device, you can specify server certificate distinguished
names for each CA.
User Experience
From the user perspective, Junos Pulse presents a clean, uncomplicated interface. The
user can enter credentials, select a realm, save settings, and accept or reject the server
certificate. When you configure the client, you can specify whether or not to permit end
users d to modify settings, such as to add connections.
The client displays the connection status until the connection is made. If a connection
fails as a result of the endpoint failing a Host Checker policy, Host Checker reason strings
and remediation options appear.
Platform Support
The following Juniper Networks devices support Junos Pulse Release 1.0:
38
•
Unified Access Control 4.0 or later
•
SA Series Appliance 7.0 or later
•
WX Series JWOS 6.1 or later
•
SRX Series 9.5
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
The Junos Pulse client is supported on Windows XP SP3 32, Windows Vista SP1/2 32
and 64, and Windows 7.
NOTE: Although the ability to configure and deploy Junos Pulse client
software from an SRX Series device is not yet available, endpoints can use
Junos Pulse client software to connect to SRX Series devices that are running
Junos OS Release 9.5. You can create connections that use the connection
type “Firewall” and deploy these connections from supported access devices.
Downloading Junos Pulse to Endpoints with Security Software Installed
If endpoint security software is installed, some settings might not allow ActiveX controls
to launch, which disables the browser-based Junos Pulse installation method. For
example, with Kaspersky 2010, users might need to remove the browser manually from
the My Security Zone in the Kaspersky client to allow the installation to run.
Related
Documentation
•
Junos Pulse Configuration Overview on page 41
•
Client Connection Set Options on page 44
•
Creating a Client Connection Set on page 46
•
Configuring a Role for Junos Pulse on page 39
Configuring the Junos Pulse Client for a Role
After you have specified the connections and components that you want to distribute
with the client, you can deploy the client to endpoints. Either assign users to a role to
receive the download, or create a custom installer package and distribute to users. See
“The Client Installer Package” on page 40.
To configure the Junos Pulse client for endpoints through a role assignment:
1.
Select Users > User Roles > New User Role in the admin console, or select an existing
role.
2. For a new role, enter a name.
3. Click Save Changes. The Role configuration options appear.
4. Select the Agent tab.
5. Select the Install Junos Pulse option button.
6. Click Save Changes. A new Junos Pulse settings tab appears.
7. (Optional) Select a component set that you have created, use the Default component
set, or select none. If you select none, you must create an installer package and
distribute to users.
8. Select Users > User Realms > Select Realm > Role Mapping > New Rule to configure
role mapping rules that map Junos Pulse users to the role(s) you configured.
Copyright © 2011, Juniper Networks, Inc.
39
Secure Access Administration Guide
To configure the Junos Pulse client for endpoints through a role assignment on an SA
Series Appliance:
1.
Select Users > User Roles > New User Role in the admin console, or select an existing
role.
2. For a new role, enter a name.
3. Click Save Changes. The Roles configuration page appears.
4. From the General Overview tab, select the option button for Junos Pulse.
5. Click the Options hyperlink.
6. Select Junos Pulse Settings.
7. (Optional) Select a component set that you have created, use the Default component
set, or select none. If you select none, you must create an installer package and
distribute to users.
8. Select Users > User Realms > Select Realm > Role Mapping > New Rule to configure
role mapping rules that map Junos Pulse users to the role(s) you configured.
Related
Documentation
•
Client Connection Set Options on page 44
•
Creating a Client Connection Set on page 46
•
Creating a Client Component Set on page 51
•
The Client Installer Package on page 40
The Client Installer Package
After you have created a client connection set and included the settings within a client
component set, you can create an installer package if you do not want to automatically
download the client when users are assigned a role. To do this, you download and install
a preconfiguration utility to the PC that you use to manage the IC Series device. The utility
is used to bundle your settings and components into an installer that can be distributed
to users.
When the Juniper Networks application jnprmkpreconfig program is installed, you can
use the application to create the actual client installer. When you create the install
package, a gzipped tar (.tgz) file is assembled and delivered to the PC. The
jnprmkpreconfig program launches and loads the downloaded package, named
preconfig.jnprpreconfig. The jnprmkpreconfig program extracts the file and produces an
MSI installer. You are prompted to supply a filename for the installer. You can then
distribute the MSI installer to users.
Note that you can create configuration updates by following these procedures and
choosing No components in the preconfigured client. In this case, the client is updated,
but no new components are applied to the configuration.
Related
Documentation
40
•
Creating an Installer on page 52
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
Junos Pulse Configuration Overview
One method of provisioning Junos Pulse for users is assigning user roles. You can allow
users to automatically download the client by selecting Junos Pulse as the agent option
for a role. The download occurs when the user connects to the Web portal for the access
device. You can gradually transition users to the new client by configuring a new role that
includes the Junos Pulse download, and then you can migrate users to the new role in a
controlled deployment.
To provision a custom Junos Pulse package for users, you first configure a Junos Pulse
connection set, which includes one or more connections. Each connection includes all
the settings that an endpoint needs to connect to a particular access device. Then you
create a Junos Pulse component set, which allows you to choose the Junos Pulse
components to download to endpoints. You can select a previously created client
connection set profile to associate with the client component set.
To assign a role, you either create a new role or select an existing role. Then you choose
a client component set for that role. When users provide valid credentials at the URL you
provide, the Junos Pulse client is automatically downloaded.
Another method of enabling users to install the Junos Pulse client is by creating an installer
package from the main Junos Pulse Components page and then distributing the installer
to endpoints through SMS.
Figure 2 on page 41 illustrates the process for deploying the client to users.
Figure 2: Configuration and Installation Overview
Be sure to instruct users to disable or uninstall OAC before installing Junos Pulse. Junos
Pulse and OAC can coexist on the same endpoint, but they must not run simultaneously.
Users can disable OAC from the Windows Task Manager.
Copyright © 2011, Juniper Networks, Inc.
41
Secure Access Administration Guide
Junos Pulse Components
Junos Pulse components are discrete software packages that provide the software
services and features of Junos Pulse that are deployed to the endpoint. A component
set is a bundle of selected components. The components you select affect the size of
the installation package. It can also affect the time it takes for a client to establish an
connection to a new device. For example, you deploy Junos Pulse to an endpoint using
an installation package that includes only the components required for a connection to
an IC Series device. If a client that is using that package later connects to an SRX Series
Firewall, the device must download the Firewall connection and all of the components
required for a firewall connection to the client.
Junos Pulse is designed to be lightweight, so you can choose to download only the
components that are required for individual connections. For example, if a connection
does not require IPsec, the components for IPsec do not have to be downloaded.
Individual components are downloaded on demand by endpoints as they encounter
different devices that require different components.
When an endpoint attempts to connect to an IC Series device or SA Series Appliance,
the connection set determines how the connection should be made.
Example components include connectivity options for 802.1X access, WX functionality,
and IC Series device IPsec.
Junos Pulse Client Connections
You can define the connections and connection methods that are stored on a user’s
endpoint. You configure client settings on the IC Series device or SA Series Appliance,
and then distribute the connection options to users through the client installation or
connection. The client settings are text files that reside on the client computer.
Each time the client accesses a different device, the client settings that are configured
for that device may overwrite the files from any previous connections.
You configure client settings when you configure a client connection set.
Client settings include the following types of persistent data:
•
Connections—A connection contains a connection-policy that controls when the
connection is made. For example, you can configure the client to connect automatically
at user login or manually when the user initiates the connection. Connections are not
user-specific. There is only one set of connections per client computer. All users of the
same client computer share the same set of connections.
•
Connection Set Options—Connection Set options are independent of connections.
Connection Set options govern the operation of the Junos Pulse client as a whole. They
control whether or not the client is provisioned with specific features that are used
each time a connection is made. You can enable or disable the following options:
42
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
•
Allow user connections—Enables the user to manually define new connections
instead of relying on connections provided from a server.
•
Dynamic certificate trust—Controls whether users may accept to trust unknown
certificates.
•
Dynamic connections—Allows a client to add a new connection when it connects
to a new supported access device.
•
Wireless suppression—Automatically suppresses wireless operations on the client
computer when it connects to a wired connection, for example, when a laptop is
inserted into a docking station.
Junos Pulse also retains learned user settings, which include information about the user
like passwords, realms, and role assignments. Learned user settings are not configured
by administrators. These settings are retained securely on the endpoint, evolving as the
user connects through different devices and methods. Learned user settings are utilized
by the Junos Pulse client to remember values entered by users. A user can enable a Save
Setting check box to have Pulse remember responses to login prompts.
The Junos Pulse client can save the following settings:
•
Certificate acceptance
•
Certificate selection
•
Realm
•
Username and password
•
Proxy username/password
•
Secondary username/password
•
Role
NOTE: When a user opts to save settings, that information is used for each
subsequent connection without prompting. If a setting changes, for example,
if a user changes their password, the saved setting will be invalid and the
connection attempt will fail. In this case, the user must use the Junos Pulse
client’s Forget Saved Settings feature. The Forget Saved Settings feature
clears all user saved settings and then Junos Pulse will prompt the user for
required information on connection attempts.
Default Configuration
The IC Series device and SA Series Appliance include a default client connection set and
client component set. You can provision Junos Pulse with the default values to users
without actively creating new connection sets or component sets. The default settings
for the client permit dynamic connections, installs only the components required for the
connection, and permit an automatic connection to the IC Series device or SA Series
Appliance to which the endpoint connects.
Copyright © 2011, Juniper Networks, Inc.
43
Secure Access Administration Guide
Related
Documentation
•
Junos Pulse Overview on page 37
•
Client Connection Set Options on page 44
•
Creating a Client Connection Set on page 46
•
Creating a Client Component Set on page 51
•
Configuring a Role for Junos Pulse on page 39
Client Connection Set Options
A client connection set contains general network access options, and allows you to
configure specific connection policies for client access to any access device that supports
Junos Pulse. Table 3 on page 44 details the available options for a connection set.
Table 3: Configurable Parameters for Junos Pulse Connection Sets
Options:
Allow saving logon information—Controls whether the Save Settings check
box is available in logon credential dialog boxes in the Junos Pulse client. If
you clear this check box, the Junos Pulse client will always require users to
provide their logon credentials. If you enable this check box, users have the
option of saving their credentials.
Allow user connections—Controls whether connections can be added by the
end user on the client.
Dynamic certificate trust—Determines whether or not users can opt to trust
unknown certificates. If you enable this check box, a user can ignore warnings
about invalid certificates and connect to the target device.
Dynamic connections—Allows new connections to be added automatically
to a Junos Pulse client when it encounters new supported access devices
through the web browser.
Wireless suppression—Disables wireless access when a wired connection is
available.
NOTE: If you enable wireless suppression, be sure to also configure a
connection that enables the client to connect through a wired connection.
When you create a connection for a connection set, you choose a connection type. The following
lists the options available for each connection type:
802.1X options:
Adapter type—Specifies the type of adapter to use for authentication: wired
or wireless.
44
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
Table 3: Configurable Parameters for Junos Pulse Connection
Sets (continued)
Outer username—Enables users to appear to log in anonymously while passing
the actual login name (called the inner identity) through an encrypted tunnel.
As a result, the user’s credentials are secure from eavesdropping and the user’s
inner identity is protected. As a general rule enter anonymous, which is the
default value. In some cases, you may need to add additional text. For example,
if the outer identity is used to route the user’s authentication to the proper
server, you may be required to use a format such as anonymous@acme.com.
If you leave the box blank, the client passes the user’s login name (inner
identity) as the outer identity.
Scan list—If you selected wireless as the adapter type, the scan list box is
available to specify the SSIDs to connect to in priority order.
Trusted Server List for 802.1X Connection:
Server certificate DN—Specify the server certificate distinguished name (DN)
and its signing certificate authority (CA). An empty DN field allows a client to
accept any server certificate signed by the selected CA.
IC or SA options:
Allow user to override connection policy—Allows a user to override the
connection policy by manually connecting or disconnecting.
This server—Specifies whether you want the endpoint to connect to this
device.
URL—Allows you to specify a URL for a different device as the default
connection. You would specify a different server’s URL if you were creating
connections for other access devices in your network.
Firewall options (for Dynamic VPN)
Allow user to override connection policy—Allows users to override the
connection policy by manually connecting or disconnecting.
URL—Specifies the location of the firewall.
WX options:
Allow user to override connection policy—Allows a user to override the
connection policy by manually connecting or disconnecting.
Community string—The Junos Pulse client and the WX endpoint can form an
adjacency for WAN optimization only if they belong to the same community
as identified by the community string. When you create a WX connection, be
sure the community string for the connection matches the community string
defined on the WX device.
If you create an IC or SA or a Firewall connection you can also specify how the connection is
established, including the rules that control the location awareness feature. Connections can be
established using the following options:
Copyright © 2011, Juniper Networks, Inc.
45
Secure Access Administration Guide
Table 3: Configurable Parameters for Junos Pulse Connection
Sets (continued)
Manually by the user—When the endpoint is started, the Junos Pulse client
software is started, but no connection is attempted. The user must use the
Junos Pulse client suer interface to select a connection.
Automatically after user logs on—When the endpoint is started and the user
has logged on to the endpoint, the Junos Pulse client software connects
automatically.
NOTE: All connections on an endpoint that are configured to start
automatically will attempt to connect to their target networks at startup time.
To avoid multiple connections, you should configure location awareness rules.
According to location awareness rules—Location awareness rules enable
an endpoint to connect conditionally. For example, the endpoint would connect
to an IC Series device if it is connected to the company intranet or connect to
an SA Series Appliance if it is in a remote location.
A Pulse connection uses the IP address of a specified interface on the endpoint
to determine its network location. Each location awareness rule includes the
following settings:
Related
Documentation
•
Name—A descriptive name, for example, “corporate-DNS.” A name can
include letters, numbers, hyphens, and underscores.
•
Action—The method the connection uses to discover the IP address. Choose
one of the following:
•
DNS Server—Allows the endpoint to connect if the endpoint’s DNS server
on the specified interface is set to one of the specified values. Use the
Condition box to specify IP addresses or address ranges.
•
Resolve Address—Allows the endpoint to connect if the hostname
specified in the DNS Name box can be resolved by the DNS server for
the specified interface. If one or more address ranges are specified in the
address range box, the address must resolve to one of the ranges to
satisfy the expression.
•
Endpoint Address—Allows the endpoint to connect if the IP address of
the specified interface is within a range specified in the IP address range
box.
•
Creating a Client Connection Set on page 46
•
Creating a Client Component Set on page 51
•
Junos Pulse Overview on page 37
Creating a Client Connection Set
To create a client configuration:
1.
From the admin console, select Users > Junos Pulse > Connections.
2. Click the New button.
3. Enter a name and optional description for this connection set.
46
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
NOTE: You must enter a name, otherwise you cannot create a connection
set.
4. Click Save Changes.
5. From the main Junos Pulse Connections page, select the connection set.
6. Under Options, select or clear the check box for each of the following items.
•
Allow saving logon information
•
Allow user connections
•
Dynamic certificate trust
•
Dynamic connections
•
Wireless suppression
See Table 3 on page 44 for more information.
7. Under connections, define a new connection by clicking New.
8. Enter a name and an optional description for this connection.
9. Select a Type for the connection. The Type identifies the device type for the
connections and can be any of the following:
•
802.1X
•
IC or SA
•
Firewall
•
WX
10. If you select 802.1X from the type list enter a value or select or clear the following
check boxes:
•
Adapter type
•
Outer username—Enter the outer username.
•
Scan list—Enter the SSIDs to connect to in your order of priority.
11. Click Save Changes.
12. If you select IC or SA after Options, select or clear the check box for each of the
following items:
•
Allow user to override connection policy
•
Connect automatically
Copyright © 2011, Juniper Networks, Inc.
47
Secure Access Administration Guide
•
This Server—This connection will use the URL of the server where you are creating
the connection.
•
URL—If you did not enable the check box for This Server, you must specify the URL
of the server for the connection.
13. If you select Firewall, enter an IP address in the Address box.
14. From the Options list, select or clear the following check boxes:
•
Allow user to override connection policy
•
Connect automatically
•
URL—enter the network address for the firewall device.
15. (Optional) You can enable location awareness by creating location awareness rules.
Location awareness can force a connection to a particular interface. See “Configuring
Connection Rules for Location Awareness” on page 48.
16. If you select WX, select the Connect Automatically check box to permit the client to
automatically connect to WX in the network.
17. After you have created the client connection set, create a client component set profile,
and select this connection set.
Related
Documentation
•
Client Connection Set Options on page 44
•
Junos Pulse Component Set Options on page 50
•
Creating a Client Component Set on page 51
•
Configuring Connection Rules for Location Awareness on page 48
Configuring Connection Rules for Location Awareness
Junos Pulse can automatically launch a remote access or a local access session depending
on location. For example, when an endpoint starts in a remote location, Junos Pulse can
automatically select a remote access connection. If the user starts the computer in a
LAN environment, Junos Pulse uses a stored connection configuration to access an IC
Series UAC device. Junos Pulse uses location awareness rules to determine the location
of the endpoint and then select the appropriate connection.
The criteria listed below can be qualified with an interface. The possible interface values
are physical, Junos Pulse, or any. You can specify the following criteria for establishing a
network connection:
•
DNS server(s)—Connect if the DNS server of a network adapter on the endpoint is set
to a certain value or set of values.
•
DNS host(s)—Connect if the configured hostname or set of hostnames is (or is not)
resolvable to a particular IP address.
•
IP Address(es)—Connect if a network adapter on the endpoint has an IP address that
falls within a range or a set of ranges.
48
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
NOTE: Location awareness rules apply to IC or SA, and Firewall connection
types. The location awareness rules configuration options are not available
for 802.1X connections.
To establish a network connection using location awareness rules:
1.
Open or create a Junos Pulse connection, and then click New under Location
Awareness Rules.
2. Enter a name for this rule.
3. Select DNS Server, Resolve address, or Endpoint address from the Action list.
4. Under Condition, enter IP address(es).
5. The On Interface option specifies how a connection should be attempted when it
matches the specified IP address or address range. Choose one of the following:
•
Physical—Use the physical interfaces on the endpoint.
•
Junos Pulse—Use the virtual interface that Junos Pulse creates when it establishes
a WAN connection.
•
Any—Use any interface.
For example, to configure location awareness rules to automatically initiate a
connection to an IC Series device or an SA Series Appliance depending on whether
the user is remote or in the office, you would configure two location awareness rules:
•
The connection for the IC Series device would specify an IC or SA connection type
and the URL of a corporate IC Series device. A connection rule would specify that
when the client attempted to connect to the physical address of that IC Series
device, a connection would be established.
•
The connection for the IC Series device would specify an IC or SA connection type
and the URL of a corporate network. A connection rule would specify that when the
client attempted to connect to a specified IP address (the corporate DNS server)
the client would connect to the DNS server associated with the specific SA Series
Appliance.
6. Click Save Changes.
The connection rule appears on the connection policy page. You can create multiple
location awareness rules for a connection policy.
a. Select the appropriate Connection Rule(s) check box(es) that you want to apply.
b. Under Require, select the All of the above rules, Any of the above rules, or Custom
option button.
Copyright © 2011, Juniper Networks, Inc.
49
Secure Access Administration Guide
c. If you select Custom, enter custom expressions to express custom rules for this
connection policy. See the Unified Access Control Administration Guide for
instructions on using custom expressions.
7. Click Save Changes.
Related
Documentation
•
Creating a Client Connection Set on page 46
Junos Pulse Component Set Options
A Junos Pulse component includes specific software components that provide Junos
Pulse connectivity and services.
Component set options include the following choices:
•
All components—Includes the components listed in Table 4 on page 50. The Enhanced
Endpoint Security (EES) component, which is available only if you have purchased an
EES license, is included only if the user’s assigned role requires it. You should choose
the All components option only when you want client endpoints to be able to connect
to all supported access devices and to be able use WAN acceleration (WX). When you
include the WX component, the disk space requirement for the Junos Pulse client
installation increases to 300 MB.
•
No components—You should select this option to create an installer that only updates
existing Pulse client installations, for example, to add a new connection. Do not use
this option if you are creating an installer to add Pulse to endpoints that do not already
have Pulse installed.
•
Minimal components—Includes only the components needed to support the selected
connections. For example, if the connection set you create includes a connection to
an IC device, the component set will include only the components required to connect
to IC devices. Minimal components is the default choice. It provides all needed
components while also limiting the size of the Junos Pulse installation file.
Table 4: Junos Pulse Components
50
Core functions
Allows the client to download a minimal component set and install
on endpoints.
802.1X access
Includes the required components for 802.1X connections. The client
interacts with the native wired and wireless 802.1X supplicant on the
client PC.
IC or SA access
Provides basic functionality that allows Junos Pulse to interoperate
with IC or SA Series devices.
Firewall access
Provides basic functionality that allows Junos Pulse to operate as a
dynamic VPN client with Juniper Networks J Series firewalls.
WX functionality
Facilitates using the client with WX Series devices for WAN
acceleration.
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
Table 4: Junos Pulse Components (continued)
Related
Documentation
Host Checker
Includes the Trusted Network Computing (TNC) client that allows IC
or SA connections to run and enforce Host Checker policies. This
component provides support for all existing host checks on Windows
machines.
Enhanced Endpoint
Security
Allows IC and SA to use the integrated Enhanced Endpoint Security
anti-malware software.
IC IPsec
Allows the client to use IPsec as a communication method with the
IC Series device when a Juniper Networks security device is employed.
SSL-VPN
Facilitates SSL connections with the SA Series SSL VPN Appliance.
•
Creating a Client Component Set on page 51
•
Configuring a Role for Junos Pulse on page 39
•
The Client Installer Package on page 40
Creating a Client Component Set
To create a client component set:
1.
From the admin console, select Users > Junos Pulse > Components.
2. Click New to create a new component set.
3. If you have not yet created a client connection set, select Users > Junos Pulse >
Connections and create a new connection set. Alternately, you can use the default
client configuration, which permits dynamic connections, supports the outer username
anonymous, and allows the client to automatically connect to an IC or SA Series
Appliance.
4. Specify a Name for the client component set.
5. (Optional) Enter a Description for this client component set.
6. Select a connection set that you have created, or use the default connection set.
7. For Junos Pulse client components, select one of the following option buttons:
•
All components—The installer contains all Junos Pulse components, supporting
all access methods and all features
•
No components—The preconfigured installer is a configuration update only, and
works on endpoints that already have the Junos Pulse client installed.
•
Minimal components—The configuration is analyzed, and only the access methods
needed to support the connections in the configuration (along with Junos Pulse
core components) are included in the installer. Additional components such as
IPsec or Host Checker are downloaded as needed at runtime and are not part of
the installer.
Copyright © 2011, Juniper Networks, Inc.
51
Secure Access Administration Guide
8. Click Save Changes.
9. After you have created a component set, distribute the client to users through one of
the following methods:
a. Return to the main Junos Pulse Client Components page to download and install
the preconfiguration utility and create an installer package.
b. Distribute to users through a role.
When users access the role, the installer automatically downloads to the endpoint.
The installer components and connections are applied to the endpoint client.
If client connections associated with the component set for a role is changed even
though the list of components has not, the existing configuration on the endpoint
is replaced, either right away if the endpoint is currently connected, or the next time
the endpoint connects.
If a user is assigned to multiple roles, and the roles include different component
sets, the first role in an endpoint’s list of roles is the role that determines which
client (component set) is deployed.
Related
Documentation
•
Client Connection Set Options on page 44
•
Creating a Client Connection Set on page 46
•
Junos Pulse Component Set Options on page 50
•
The Client Installer Package on page 40
•
Configuring a Role for Junos Pulse on page 39
Creating an Installer
To create an installer for distribution to endpoints:
1.
Create a client component set with a custom connection set.
2. In the admin console, select Junos Pulse > Components.
3. Click the download and install pre-configuration utility link. You are prompted to
save the application preconfigurationBuilder.x86.exe.
4. Click save to download the application to your PC.
5. On your PC, double-click the application to install.
6. From the Junos Pulse > Components page on the IC Series device, select the check
box for the preconfiguration installer that you want to create.
7. Click Create Install Package. You are prompted to save the preconfiguration.
8. Save the preconfiguration to your PC.
52
Copyright © 2011, Juniper Networks, Inc.
Chapter 2: Introduction to the SA Series Appliance
9. On your PC, open the application Juniper Networks > Preconfiguration Builder >
Juniper Networks Preconfiguration Builder. You are prompted to select a Juniper
preconfiguration File.
10. Select the preconfiguration that you downloaded. The Preconfiguration Utility creates
an MSI that you can distribute to users.
Related
Documentation
•
The Client Installer Package on page 40
Copyright © 2011, Juniper Networks, Inc.
53
Secure Access Administration Guide
54
Copyright © 2011, Juniper Networks, Inc.
PART 2
Access Management Framework
•
General Access Management on page 57
•
User Roles on page 89
•
Resource Profiles on page 109
•
Virtual Desktop Resource Profiles on page 119
•
Resource Policies on page 127
•
Authentication and Directory Servers on page 137
•
Authentication Realms on page 213
•
Sign-In Policies on page 225
•
Single Sign-On on page 237
•
Synchronizing User Records on page 263
Copyright © 2011, Juniper Networks, Inc.
55
Secure Access Administration Guide
56
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 3
General Access Management
•
Access Management Overview on page 57
•
Policies, Rules & Restrictions, and Conditions Overview on page 58
•
Policies, Rules & Restrictions, and Conditions Evaluation on page 60
•
Dynamic Policy Evaluation on page 63
•
Specifying Source IP Access Restrictions on page 65
•
Specifying Browser Access Restrictions on page 67
•
Specifying Certificate Access Restrictions on page 69
•
Specifying Password Access Restrictions on page 70
•
Specifying Session Limits on page 71
•
IF-MAP Federation Overview on page 72
•
IF-MAP Federation Details on page 74
•
Task Summary: Configuring IF-MAP Federation on page 77
•
Configuring IF-MAP Server Settings on page 77
•
Configuring the IF-MAP Federation Client on page 78
•
IF--MAP Federation Network Timing Considerations on page 78
•
Session-Export and Session-Import Policies on page 79
•
Configuring Session-Export Policies on page 81
•
Session-Import Policies on page 83
•
Troubleshooting the IF-MAP Federation Network on page 84
•
Viewing Active Users on the IF-MAP Client on page 84
•
Trusted Server List on page 85
Access Management Overview
The SA Series Appliance enables you to secure your company resources using
authentication realms, user roles, and resource policies. These three levels of accessibility
allow you to control access from a very broad level (controlling who may sign into the
SA Series Appliance) down to a very granular level (controlling which authenticated
users may access a particular URL or file). You can specify security requirements that
users must meet to sign in to the SA Series Appliance, to gain access to features, and
Copyright © 2011, Juniper Networks, Inc.
57
Secure Access Administration Guide
even to access specific URLs, files, and other server resources. The SA Series Appliance
enforces the policies, rules and restrictions, and conditions that you configure to prevent
users from connecting to or downloading unauthorized resources and content.
To permit endpoints that are not directly connected to a Juniper Networks Security Device
to access resources behind the firewall, you can configure a Unified Access Control to
provision shared user sessions from any number of different SA appliances and Infranet
Controllers. IF-MAP Federation allows users to access resources protected by any number
of Juniper Networks Firewalls (Infranet Enforcers) without requiring additional
authentication.
The SA Series Appliance access management framework is available on all SA Series
products. The access management features, including realms, roles, resource policies,
and servers, are the base of the platform on which all SA Series products are built.
Related
Documentation
•
User Roles Overview on page 89
•
Authentication Realm Overview on page 213
Policies, Rules & Restrictions, and Conditions Overview
The SA Series Appliance enables you to secure your company resources using
authentication realms, user roles, and resource policies. These three levels of accessibility
allow you to control access from a very broad level (controlling who may sign into the
SA Series Appliance) down to a very granular level (controlling which authenticated
users may access a particular URL or file).
Accessing Authentication Realms
Resource accessibility begins with the authentication realm. An authentication realm is
a grouping of authentication resources, including:
•
An authentication server—verifies that the user is who he claims to be. The SA Series
Appliance forwards credentials that a user submits on a sign-in page to an
authentication server.
•
An authentication policy—specifies realm security requirements that need to be met
before the SA Series Appliance submits a user's credentials to an authentication server
for verification.
•
A directory server—an LDAP server that provides user and group information to the
SA Series Appliance that the SA Series Appliance uses to map users to one or more
user roles.
•
Role mapping rules—conditions a user must meet for the SA Series Appliance to map
the user to one or more user roles. These conditions are based on either user information
returned by the realm's directory server or the user's username.
You can associate one or more authentication realms with an SA Series Appliance sign-in
page. When more than one realm exists for a sign-in page, a user must specify a realm
before submitting her credentials. When the user submits her credentials, the SA Series
Appliance checks the authentication policy defined for the chosen realm. The user must
58
Copyright © 2011, Juniper Networks, Inc.
Chapter 3: General Access Management
meet the security requirements you define for a realm's authentication policy or else the
SA Series Appliance does not forward the user's credentials to the authentication server.
At the realm level, you can specify security requirements based on various elements such
as the user's source IP address or the possession of a client-side certificate. If the user
meets the requirements specified by the realm's authentication policy, the SA Series
Appliance forwards the user's credentials to the appropriate authentication server. If this
server successfully authenticates the user, then the SA Series Appliance evaluates the
role mapping rules defined for the realm to determine which roles to assign to the user.
Accessing User Roles
A role is a defined entity that specifies SA Series Appliance session properties for users
who are mapped to the role. These session properties include information such as session
time-outs and enabled access features. A role's configuration serves as the second level
of resource access control. Not only does a role specify the access mechanisms available
to a user, but you can also specify restrictions with which users must comply before they
are mapped to a role. The user must meet
At the role level, you can specify security requirements based on elements such as the
user's source IP address and possession of a client-side certificate. If the user meets the
requirements specified either by a role mapping rule or a role's restrictions, then the SA
Series Appliance maps the user to the role. When a user makes a request to the backend
resources available to the role, the SA Series Appliance evaluates the corresponding
access feature resource policies.
Note that you may specify security requirements for a role in two places—in the role
mapping rules of an authentication realm (using custom expressions) or by defining
restrictions in the role definition. The SA Series Appliance evaluates the requirements
specified in both areas to make sure the user complies before it maps the user to a role.
Accessing Resource Policies
A resource policy is a set of resource names (such as URLs, host names, and IP
address/netmask combinations) to which you grant or deny access or other
resource-specific actions, such as rewriting and caching. A resource policy serves as the
third level of resource access control. While a role may grant access to certain types of
access features and resources (such as bookmarks and applications), whether or not a
user can access a specific resource is controlled by resource policies. These policies may
even specify conditions that, if met, either deny or grant user access to a server share or
file. These conditions may be based on security requirements that you specify. The user
must meet these security requirements or else the SA Series Appliance does not process
the user's request.
At the resource level, you can specify security requirements based elements such as the
user's source IP address or possession of a client-side certificate. If the user meets the
requirements specified by a resource policy's conditions, then the SA Series Appliance
either denies or grants access to the requested resource. You may enable Web access
at the role level, for example, and a user mapped to the role may make a Web request.
You may also configure a Web resource policy to deny requests to a particular URL or
path when Host Checker finds an unacceptable file on the user's machine. In this scenario,
Copyright © 2011, Juniper Networks, Inc.
59
Secure Access Administration Guide
the SA Series Appliance checks to see if Host Checker is running and indicates that the
user's machine complies with the required Host Checker policy. If the user's machine
complies, meaning the unacceptable file is not found, then the SA Series Appliance grants
the user access to the requested Web resource.
Note that you can create separate resource policies or you can create automatic resource
policies (called autopolicies) during resource profile configuration (recommended).
Related
Documentation
•
Policies, Rules & Restrictions, and Conditions Evaluation on page 60
•
Dynamic Policy Evaluation on page 63
Policies, Rules & Restrictions, and Conditions Evaluation
The following diagram illustrates the access management security checks that the SA
Series SSL VPN Appliance performs when a user tries to access resources through the
SA Series SSL VPN Appliance. A detailed description of each step follows after the
diagram.
60
Copyright © 2011, Juniper Networks, Inc.
Chapter 3: General Access Management
Figure 3: Security Checks Performed During a User Session
1.
The user enters the URL of the SA Series end-user console (such as
http://employees.yourcompany.com/marketing) in a Web browser.
2. The SA Series SSL VPN Appliance evaluates its sign-in policies (starting with the
administrator URLs and continuing to user URLs) until it matches the hostname
entered by the user.
3. The SA Series SSL VPN Appliance evaluates pre-authentication restrictions and
determines if the user’s system passes host checks and other requirements. If the
pre-authentication checks fail, the SA Series SSL VPN Appliance denies the user
access. If the checks pass, the SA Series SSL VPN Appliance prompts the user to enter
the username and password for the realms whose preauthentication checks
succeeded. (If required by the realm, the SA Series SSL VPN Appliance prompts the
user to enter two sets of credentials.) If more than one realm exists, the user must
enter a realm or choose one from a list.
4. The SA Series SSL VPN Appliance evaluates the post-authentication restrictions and
determines whether the user’s password conforms to specified limits and requirements.
Copyright © 2011, Juniper Networks, Inc.
61
Secure Access Administration Guide
If the postauthentication checks fail, the SA Series SSL VPN Appliance denies the
user access. If the checks pass, the SA Series SSL VPN Appliance passes the user’s
credentials to the realm’s authentication server.
5. The SA Series SSL VPN Appliance forwards the user’s username and password to
the authentication server, which returns success or failure. (A RADIUS or SiteMinder
authentication server also returns attributes for the SA Series SSL VPN Appliance to
use in role mapping.) If the authentication server returns failure, Secure Access denies
the user access. If the server returns success, the SA Series SSL VPN Appliance stores
the user’s credentials. If the realm has a separate LDAP authorization server, the SA
Series SSL VPN Appliance also queries the LDAP server for attribute and group
information and saves the information returned by LDAP. If the realm includes a
secondary authentication server, the SA Series SSL VPN Appliance repeats this process
with the secondary server.
6. The SA Series SSL VPN Appliance evaluates the realm’s role mapping rules and
determines the roles for which the user is eligible. The SA Series SSL VPN Appliance
determines eligibility using information from the LDAP or RADIUS server or the user’s
username.
7. The SA Series SSL VPN Appliance evaluates the restrictions of the eligible roles,
enabling the user to access those roles whose restrictions the user’s computer meets.
Restrictions may include source IP, browser type, client-side certificate, Host Checker,
and Cache Cleaner.
8. The SA Series SSL VPN Appliance creates a “session role,” determining the user’s
session permissions. If you enable permissive merging, the SA Series SSL VPN
Appliance determines session permissions by merging all valid roles and granting the
allowed resources from each valid role. If you disable merging, the SA Series SSL VPN
Appliance assigns the user to the first role to which he is mapped.
9. When the user requests a resource, the SA Series SSL VPN Appliance checks whether
the corresponding access feature is enabled for the session user role. If not, the SA
Series SSL VPN Appliance denies the user access. If the access feature is enabled,
the evaluates resource policies.
10. The SA Series SSL VPN Appliance evaluates resource profiles and policies related to
the user’s request, sequentially processing each until it finds the profile or policy whose
resource list and designated roles match the user’s request. The SA Series SSL VPN
Appliance denies user access to the resource if specified by the profile or policy.
Otherwise, the SA Series SSL VPN Appliance intermediates the user request if the
profile or policy enables access.
11. The SA Series SSL VPN Appliance intermediates the user request, forwarding the
user’s request and credentials (if necessary) to the appropriate server. Then, the SA
Series SSL VPN Appliance forwards the the server’s response to the user.
12. The user accesses the requested resource or application server. The user session ends
when the user signs out or his session times out due to time limits or inactivity. The
SA Series SSL VPN Appliance may also force the user out if the session if you enable
dynamic policy evaluation and the user fails a policy.
62
Copyright © 2011, Juniper Networks, Inc.
Chapter 3: General Access Management
NOTE: If you enable dynamic policy evaluation, the SA Series SSL VPN
Appliance performs additional checks beyond the ones mentioned here.
Related
Documentation
•
Dynamic Policy Evaluation on page 63
Dynamic Policy Evaluation
Dynamic policy evaluation allows you to automatically or manually refresh the assigned
roles of users by evaluating a realm’s authentication policy, role mappings, role restrictions,
and resource policies. When the SA Series SSL VPN Appliance performs a dynamic
evaluation, it checks whether the client’s status has changed. (For instance, the client’s
Host Checker status may have changed. Or, if the user is roaming, the computer’s IP
address may have changed.) If the status has changed, the SA Series SSL VPN Appliance
enables or denies the user access to the dependent realms, roles, or resource policies
accordingly.
The SA Series SSL VPN Appliance does not check for changes in user attributes from a
RADIUS, LDAP, or SiteMinder server when performing dynamic policy evaluation. Instead,
the SA Series SSL VPN Appliance re-evaluates rules and policies based on the original
user attributes that it obtained when the user signed into the SA Series SSL VPN
Appliance.
Understanding Dynamic Policy Evaluation
During dynamic policy evaluation, the SA Series SSL VPN Appliance evaluates the
following types of resource policies:
•
Windows Secure Application Manager
•
Java Secure Application Manager
•
Network Connect
•
Telnet/SSH
•
Terminal Services (Windows and Citrix)
•
Java Access
•
Code signing (for Java applets)
NOTE: Because the SA Series SSL VPN Appliance evaluates Web and Files
resource policies whenever the user makes a request for a resource, dynamic
policy evaluation is unnecessary for Web and Files. The SA Series SSL VPN
Appliance does not use dynamic policy evaluation for Meetings resource
policies and Email Client resource policies.
If the SA Series SSL VPN Appliance determines after a dynamic policy evaluation that a
user no longer meets the security requirements of a policy or role, the SA Series SSL VPN
Copyright © 2011, Juniper Networks, Inc.
63
Secure Access Administration Guide
Appliance terminates the connection immediately with the user. The user may see the
closing of a TCP or application connection, or the termination of a user session for Network
Connect, Secure Application Manager, Terminal or Telnet/SSH. The user must take the
necessary steps to meet the security requirements of the policy or role, and then sign
into the SA Series SSL VPN Appliance again.
The SA Series SSL VPN Appliance logs information about policy evaluation and changes
in roles or access in the Event log.
Understanding Standard Policy Evaluation
If you do not use dynamic policy evaluation, the SA Series SSL VPN Appliance evaluates
policies and roles only when the following events occur:
•
When the user first tries to access the SA Series sign-in page, the SA Series SSL VPN
Appliance evaluates the Host Checker policies (if any) for a realm.
•
Immediately after the user’s initial authentication, the SA Series SSL VPN Appliance
evaluates the user’s realm restrictions in the authentication policy, role mapping rules,
and role restrictions.
•
When the user makes a request for a resource, the SA Series SSL VPN Appliance
evaluates resource access policies to determine if the associated role is allowed to
access the resource.
•
When the Host Checker status of the user’s machine changes, the SA Series SSL VPN
Appliance evaluates the Host Checker policies (if any) for the role.
If you do not use dynamic policy evaluation and you make changes to an authentication
policy, role mapping rules, role restrictions, or resource policies, the SA Series SSL VPN
Appliance enforces those changes only when the events described above occur.
If you use dynamic policy evaluation, the SA Series SSL VPN Appliance enforces changes
when the events described above occur, and it also enforces changes at the times you
specify.
Enabling Dynamic Policy Evaluation
You can use dynamic policy evaluation in the following ways:
•
Evaluate all signed-in users in a realm—You can automatically or manually refresh
the roles of all currently signed-in users of a realm by using the General tab of the
Administrators > Admin Realms > Select Realm or Users > User Realms > Select Realm
page. You can trigger the SA Series SSL VPN Appliance to perform a dynamic policy
evaluation at the realm level based on:
•
64
An automatic timer—You can specify a refresh interval that determines how often
the SA Series SSL VPN Appliance performs an automatic policy evaluation of all
currently signed-in realm users, such as every 30 minutes. When using the refresh
interval, you can also fine-tune the SA Series SSL VPN Appliance performance by
specifying whether or not you want to refresh roles and resource policies as well as
the authentication policy, role mapping rules, and role restrictions.
Copyright © 2011, Juniper Networks, Inc.
Chapter 3: General Access Management
•
Related
Documentation
On-demand—At any time, you can manually evaluate the authentication policy, role
mapping rules, role restrictions, and resource policies of all currently signed-in realm
users. This technique is especially useful if you make changes to an authentication
policy, role mapping rules, role restrictions, or resource policies and you want to
immediately refresh the roles of a realm’s users.
•
Evaluate all signed-in users in all realms—At any time, you can manually refresh the
roles of all currently signed-in users in all realms by using settings in the System >
Status >Active Users page.
•
Evaluate individual users—You can automatically refresh the roles of individual users
by enabling dynamic policy evaluation for Host Checker on the Authentication >
Endpoint Security > Host Checker page. Host Checker can trigger the SA Series SSL
VPN Appliance to evaluate resource policies whenever a user’s Host Checker status
changes. (If you do not enable dynamic policy evaluation for Host Checker, the SA
Series SSL VPN Appliance does not evaluate resource policies but it does evaluate the
authentication policy, role mapping rules, and role restrictions whenever a user’s Host
Checker status changes.)
•
Monitoring Active Users on page 815
Specifying Source IP Access Restrictions
Use a source IP restriction at the role or the realm level to control from which IP addresses
users can access an SA Series sign-in page, be mapped to a role, or access a resource.
Use a source IP restriction to control from which IP addresses users can access an SA
Series sign-in page, be mapped to a role, or access a resource.
You can restrict resource access by source IP:
•
When administrators or users try to sign in to an SA Series SSL VPN Appliance—The
user must sign in from a machine whose IP address/netmask combination meets the
specified source IP requirements for the selected authentication realm. If the user's
machine does not have the IP address/netmask combination required by the realm,
the SA Series SSL VPN Appliance does not forward the user's credentials to the
authentication server and the user is denied access to the SA Series SSL VPN Appliance.
You can allow or deny access to any specific IP address/netmask combination. For
example, you can deny access to all users on a wireless network (10.64.4.100), and
allow access to all other network users (0.0.0.0).
•
When administrators or users are mapped to a role—The authenticated user must
be signed in from a machine whose IP address/netmask combination meets the
specified Source IP requirements for each role to which the SA Series SSL VPN
Appliance may map the user. If the user's machine does not have the IP
address/netmask combination required by a role, then the SA Series SSL VPN Appliance
does not map the user to that role.
•
When users request a resource—The authenticated, authorized user must make a
resource request from a machine whose IP address/netmask combination meets the
Copyright © 2011, Juniper Networks, Inc.
65
Secure Access Administration Guide
specified Source IP requirements for the resource policy corresponding to the user's
request. If the user's machine does not have the required IP address/netmask
combination required by the resource, then the SA Series SSL VPN Appliance does not
allow the user to access the resource.
Specifying Source IP Restrictions
To specify source IP restrictions:
1.
Select the level at which you want to implement IP restrictions:
•
•
•
Realm level—select:
•
Administrators > Admin Realms > SelectRealm> Authentication Policy > Source
IP
•
Users > User Realms > SelectRealm> Authentication Policy > Source IP
Role level—Select:
•
Administrators > Admin Roles > Select Role> General > Restrictions > Source
IP
•
Users > User Roles > Select Role > General > Restrictions > Source IP
Resource policy level—Select:
•
Users > Resource Policies > Select Resource > Select Policy > Detailed Rules
> Select|CreateRule > Condition Field
2. Choose one of the following options:
•
Allow users to sign in from any IP address—Enables users to sign into the SA Series
SSL VPN Appliance from any IP address in order to satisfy the access management
requirement.
•
Enable administrators to sign in on the external port—Enables administrators to
sign in to the SA Series SSL VPN Appliance from the external interface. You must
enable the external port before setting this option.
•
Allow or deny users from the following IP addresses—Specifies whether to allow
or deny users access to the SA Series SSL VPN Appliance from all of the listed IP
addresses, based on their settings. To specify access from an IP address:
a. Enter the IP address and netmask.
b. Select either Allow to allow users to sign in from the specified IP address, or Deny
to prevent users from signing in from the specified IP address.
c. Click Add.
d. If you add multiple IP addresses, move the highest priority restrictions to the top
of the list by selecting the check box next to the IP address, and then clicking the
up arrow button. For example, to deny access to all users on a wireless network
(10.64.4.100) and allow access to all other network users (0.0.0.0), move the
66
Copyright © 2011, Juniper Networks, Inc.
Chapter 3: General Access Management
wireless network address (10.64.4.100) to the top of the list and move the (0.0.0.0)
network below the wireless network.
3. Click Save Changes to save your settings.
Related
Documentation
•
Role Restrictions on page 94
•
Creating an Authentication Realm on page 214
•
Specifying Browser Access Restrictions on page 67
•
Specifying Certificate Access Restrictions on page 69
•
Specifying Password Access Restrictions on page 70
•
About Host Checker Restrictions on page 311
Specifying Browser Access Restrictions
Use a browser restriction to control from which Web browsers users can access an SA
Series sign-in page or be mapped to a role. If a user tries to sign in to the SA Series SSL
VPN Appliance using an unsupported browser, the sign-in attempt fails and a message
displays stating that an unsupported browser is being used. This feature also enables
you to ensure that users sign in to the Secure Access device from browsers that are
compatible with corporate applications or are approved by corporate security policies.
You can restrict SA Series SSL VPN Appliance and resource access by browser-type:
•
When administrators or users try to sign in to the SA Series SSL VPN Appliance—The
user must sign in from a browser whose user-agent string meets the specified
user-agent string pattern requirements for the selected authentication realm. If the
realm “allows” the browser's user-agent string, then the SA Series SSL VPN Appliance
submits the user's credentials to the authentication server. If the realm “denies” the
browser's user-agent string, then the SA Series SSL VPN Appliance does not submit
the user's credentials to the authentication server.
•
When administrators or users are mapped to a role—The authenticated user must
be signed in from a browser whose user-agent string meets the specified user-agent
string pattern requirements for each role to which the SA Series SSL VPN Appliance
may map the user. If the user-agent string does not meet the “allowed” or “denied”
requirements for a role, then the SA Series SSL VPN Appliance does not map the user
to that role.
•
When users request a resource—The authenticated, authorized user must make a
resource request from a browser whose user-agent string meets the specified “allowed”
or “denied” requirements for the resource policy corresponding to the user's request.
If the user-agent string does not meet the “allowed” or “denied” requirements for a
resource, then the SA Series Appliance does not allow the user to access the resource.
The browser restrictions feature is not intended as a strict access control since browser
user-agent strings can be changed by a technical user. It serves as an advisory access
control for normal usage scenarios.
Copyright © 2011, Juniper Networks, Inc.
67
Secure Access Administration Guide
To specify browser restrictions:
1.
Select the level at which you want to implement browser restrictions:
•
•
Realm level—Navigate to:
•
Administrators > Admin Realms > Select Realm > Authentication Policy >
Browser
•
Users > User Realms > Select Realm > Authentication Policy > Browser
Role level—Navigate to:
•
Administrators > Admin Realms > Select Realm > Role Mapping > Select|Create
Rule > Custom Expressions
•
Administrators > Admin Roles > Select Role > General > Restrictions > Browser
•
Users > User Realms > Select Realm > Role Mapping > Select|Create Rule >
Custom Expression
•
Users > User Roles > Select Role > General > Restrictions > Browser
2. Choose one of the following options:
•
Allow all users matching any user-agent string sent by the browser— Allows users
to access the SA Series SSL VPN Appliance or resources using any of the supported
Web browsers.
•
Only allow users matching the following User-agent policy—Allows you to define
browser access control rules. To create a rule:
a. For the User-agent string pattern, enter a string in the format
*<browser_string>*
where start (*) is an optional character used to match any character and
<browser_string> is a case-sensitive pattern that must match a substring in the
user-agent header sent by the browser. Note that you cannot include escape
characters (\) in browser restrictions.
b. Select either:
•
Allow to allow users to use a browser that has a user-agent header containing
the <browser_string> substring.
•
Deny to prevent users from using a browser that has a user-agent header
containing the <browser_string> substring.
c. iii. Click Add.
3. Click Save Changes to save your settings.
Rules are applied in order, so the first matched rule applies.
Literal characters in rules are case sensitive, and spaces are allowed as literal characters.
68
Copyright © 2011, Juniper Networks, Inc.
Chapter 3: General Access Management
For example, the string *Netscape* matches any user-agent string that contains the
substring Netscape.
The following rule set grants resource access only when users are signed in using Internet
Explorer 5.5x or Internet Explorer 6.x. This example takes into account some major non-IE
browsers that send the 'MSIE' substring in their user-agent headers:
*Opera*Deny
*AOL*Deny
*MSIE 5.5*Allow
*MSIE 6.*Allow
* Deny
Specifying Certificate Access Restrictions
When you install a client-side certificate on the SA Series SSL VPN Appliance through
the System > Configuration > Certificates > Trusted Client CAs page of the admin console,
you can restrict SA Series SSL VPN Appliance and resource access by requiring client-side
certificates:
•
When administrators or users try to sign in to the SA Series SSL VPN Appliance—The
user must sign in from a machine that possesses the specified client-side certificate
(from the proper certificate authority (CA) and possessing any optionally specified
field/value pair requirements). If the user's machine does not possess the certificate
information required by the realm, the user can access the sign-in page, but once the
SA Series SSL VPN Appliance determines that the user's browser does not possess
the certificate, the SA Series SSL VPN Appliance does not submit the user's credentials
to the authentication server and the user cannot access features on the SA Series SSL
VPN Appliance.
To implement certificate restrictions at the realm level, navigate to:
•
•
•
Administrators > Admin Realms > SelectRealm > Authentication Policy > Certificate
•
Users > User Realms > SelectRealm > Authentication Policy > Certificate
When administrators or users are mapped to a role—The authenticated user must
be signed in from a machine that meets the specified client-side certificate requirements
(proper certificate authority (CA) and optionally specified field/value pair requirements)
for each role to which the SA Series SSL VPN Appliance may map the user. If the user's
machine does not possess the certificate information required by a role, then the SA
Series SSL VPN Appliance does not map the user to that role.
•
Administrators > Admin Roles > SelectRole > General > Restrictions > Certificate
•
Users > User Realms > Select Realm Role Mapping > Select|CreateRule >
CustomExpression
•
Users > User Roles > SelectRole > General > Restrictions > Certificate
When users request a resource—The authenticated, authorized user must make a
resource request from a machine that meets the specified client-side certificate
Copyright © 2011, Juniper Networks, Inc.
69
Secure Access Administration Guide
requirements (proper certificate authority (CA) and optionally specified field/value
pair requirements) for the resource policy corresponding to the user's request. If the
user's machine does not possess the certificate information required by a resource,
then the SA Series SSL VPN Appliance does not allow the user to access the resource.
Users > Resource Policies> SelectResource > SelectPolicy > Detailed
RulesSelect|CreateRule > ConditionField
•
Related
Documentation
•
Dynamic Policy Evaluation on page 63
Specifying Password Access Restrictions
You can restrict SA Series SSL VPN Appliance and resource access by password-length
when administrators or users try to sign in to the SA Series SSL VPN Appliance. The user
must enter a password whose length meets the minimum password-length requirement
specified for the realm. Note that local user and administrator records are stored in the
SA Series authentication server. This server requires that passwords are a minimum
length of 6 characters, regardless of the value you specify for the realm's authentication
policy.
To specify password restrictions:
1.
Select an administrator or user realm for which you want to implement password
restrictions.
Navigate to:
•
Administrators > Admin Realms > Select Realm > Authentication Policy >
Password
•
Users > User Realms > Select Realm > Authentication Policy > Password
2. Choose one of the following options:
•
Allow all users (passwords of any length) — Does not apply password length
restrictions to users signing in to the SA Series SSL VPN Appliance.
•
Only allow users that have passwords of a minimum length — Requires the user
to enter a password with a minimum length of the number specified.
3. Select Enable Password Management if you want to enable password management.
You must also configure password management on the SA Series authentication
server configuration page (local authentication server) or through an LDAP server.
For more information about password management,
4. If you have enabled a secondary authentication server, specify password length
restrictions using the restrictions above as a guideline.
5. Click Save Changes to save your settings.
By default, the SA Series SSL VPN Appliance requires that user passwords entered on
the sign-in page be a minimum of four characters. The authentication server used to
validate a user’s credentials may require a different minimum length. The SA Series local
70
Copyright © 2011, Juniper Networks, Inc.
Chapter 3: General Access Management
authentication database, for example, requires user passwords to be a minimum length
of six characters.
Related
Documentation
•
Dynamic Policy Evaluation on page 63
Specifying Session Limits
In addition to the access management options you may specify for an authentication
policy, you may also specify a limit for concurrent users. A user who enters a URL to one
of this realm’s sign-in pages must meet any access management and concurrent user
requirements specified for the authentication policy before the SA Series SSL VPN
Appliance presents the sign-in page to the user.
Setting the minimum or maximum setting limit amount allows you to configure realms
that are more likely to be available when the SA Series SSL VPN Appliance is nearing the
amount of licensed users.
Valid numbers for the minimum amount of sessions are between 0 and the license limit.
A default of 0 means there are no limits. All of the realms minimum limits can add up to
the license limit but cannot exceed it. You cannot modify an existing realm’s minimum
limit or add a new realm’s minimum limit that exceeds the license limit. The maximum
limit can be equal to or greater than the minimum limit for a particular realm. Value 0 for
maximum limit means no user can log in to the realm.
You can also limit the number of concurrent users per session. A user can have multiple
sessions. For example, if a user logs in from two machines in the same realm, an additional
session is created.
To limit the number of simultaneous sessions:
1.
Select an administrator or user realm for which you want to implement limits
restrictions.
•
Administrators > Admin Realms >SelectRealmAuthentication Policy > Limits
•
Users > User Realms > SelectRealm > Authentication Policy > Limits
2. To limit the number of concurrent users on the realm, select Limit the number of
concurrent users and then specify limit values for these options:
•
Guaranteed minimum—You can specify any number of users between zero (0)
and the maximum number of concurrent users defined for the realm, or you can set
the number up to the maximum allowed by your license if there is no realm
maximum.
•
Maximum (optional)—You can specify any number of concurrent users from the
minimum number you specified up to the maximum number of licensed users. If
you enter a zero (0) into the Maximum field, no users are allowed to login to the
realm.
3. Click Save Changes.
Copyright © 2011, Juniper Networks, Inc.
71
Secure Access Administration Guide
Related
Documentation
•
Dynamic Policy Evaluation on page 63
IF-MAP Federation Overview
You can configure a Juniper Networks Unified Access Control (UAC) Infranet Controller
to store user session information for other Infranet Controllers and SA appliances.
Federation allows users to authenticate to a single SA appliance or Infranet Controller,
and then access resources that are protected by any number of Juniper Networks firewall
devices known as Infranet Enforcers that are controlled by different Infranet Controllers.
Federation enhances network performance. If a user is required to login to multiple SA
appliances or Infranet Controllers during the course of a day to access different resources,
each device must perform authentication and Host-Checking, often with periodic Host
Checker updates throughout the day. The overhead can lead to decreased performance
not only on the devices, but also on the network and the endpoint. Imported IF-MAP
sessions eliminate redundant logins and Host Checks.
Federation on the SA Series Appliance uses the standard IF-MAP (Interface for Metadata
Access Point) protocol to share session information and other data between connected
devices over distributed networks. IF-MAP is a protocol defined by the Trusted Network
Connect Working Group (TNC-WG) as a standard interface between different network
elements and devices. Federation is accomplished using an IFMAP server and IF-MAP
clients.
It is important as an administrator to understand the fundamental underlying
communication method for data transmission in a Federation network over IF-MAP.
Policies that you configure on the SA appliance permit this communication.
In a federated network, the IF-MAP server functions as the repository, or data store for
IF-MAP clients to use for publishing information regarding activity on the network. For
example, SA appliance IF-MAP clients can publish information about sessions on the
network, and Juniper Networks IDP devices can communicate information about potential
threats to the IF-MAP client for publishing. IF-MAP clients can search for information
about sessions or threats, and an IF-MAP client can establish a subscription so the IF-MAP
server notifies the client when other clients publish new or changed information. In
addition, IF-MAP clients can purge data that is no longer valid. All transactions are initiated
by the IF-MAP client. “IFMAP Overview” on page 68 shows a simple IF-MAP transaction.
Not all of the steps for IF-MAP Federation are shown.
IF-MAP Federation is not supported for non-root IVSes on the SA Appliance.
IF-MAP Federation is available on all SA appliances with version 6.4 or greater. No licensing
is required.
1.
The endpoint authenticates through the IF-MAP client (an SA appliance). The IFMAP
client publishes session information to the IF-MAP server.
2. The endpoint attempts to access protected resources that are behind the Infranet
Enforcer.
72
Copyright © 2011, Juniper Networks, Inc.
Chapter 3: General Access Management
3. The Infranet Enforcer notifies the Infranet Controller (also an IF-MAP client). The
IF-MAP client searches for session information on the IF-MAP server.
4. The Infranet Controller subscribes to session information about the endpoint’s IP
address.
5. The Infranet Controller notifies the Infranet Enforcer that session information exists
for the IP address attempting to access resources, and the Infranet Enforcer provisions
an auth table entry.
6. Access is granted to the protected resources. If any session information about the
user changes, the authenticating IF-MAP client publishes the new information. Having
subscribed to the user’s session information, the Infranet Controller will be aware of
any changes and provision access in accordance with the changed session information.
For details about configuring the SA appliance to work in an IF-MAP Federated network
with the Infranet Controller, see the Unified Access Control Administrator’s Guide.
IF-MAP Federation Workflow
Configuring an IF-MAP federated network requires coordination between administrators
of the different devices that will be in the federated network.
This document describes IF-MAP deployments that include only Juniper Networks devices:
Infranet Controllers, SA appliances, Infranet Enforcer firewalls, and Juniper Networks
IDP. For implementations that incorporate third-party components, contact Juniper
Networks Technical Support.
The mix of devices in the federated network is important when planning the network.
Will your network consist of only Infranet Controllers, or will you incorporate SA
appliances? Do the devices in your network have similar role mapping policies, or is each
device different?
Determine and understand your goals for the federated network. The big picture guides
your implementation as it becomes more complex. Juniper Networks recommends that
you begin slowly. For example, start with a single role on each device, and then build the
network incrementally.
In the simplest model, you can use the default policies. Using this model, you can quickly
establish a federated network, and session information will automatically be shared
among distributed devices in the network. This simple model should be adequate for
most implementations in which the devices in the federated network have identical or
very similar role mapping policies.
If your configuration requires more complex policies, you will need to perform a number
of tasks to achieve your intended results. The following guidelines will help you plan your
workflow:
•
Ensure that communications between IF-MAP servers and IF-MAP clients is established
•
Determine the resources that will be shared among the different devices
•
Define who can access specific resources
Copyright © 2011, Juniper Networks, Inc.
73
Secure Access Administration Guide
Related
Documentation
•
Distribute resources and users into roles
•
Establish a naming convention that is shared and implemented between all
administrators and devices
•
Create Session-Export and Session-Import policies that reflect the role designations
that you have configured on the devices
•
IF-MAP Federation Details on page 74
•
Task Summary: Configuring IF-MAP Federation on page 77
IF-MAP Federation Details
You can configure the SA appliance as an IF-MAP client for an IF-MAP server. You
configure an Infranet Controller as an IF-MAP server. Any endpoint sessions with an IP
address created on an IF-MAP server are automatically published to that IF-MAP server.
You can create source IP policies for endpoints that authenticate to an SA appliance to
permit access to resources behind Infranet Enforcers (ScreenOS Enforcers and JUNOS
Enforcers). Session-Export policies that you configure on the IF-MAP clients allow the
clients to publish endpoint user data to the IF-MAP server. SA appliances that are IF-MAP
clients can subscribe to the information on an IF-MAP server.
When a user accesses an SA appliance that is configured as an IF-MAP client, the client
publishes basic session information, including the IP address, user name and roles, to
the IF-MAP server. The server stores the information as metadata. Other IFMAP clients
in the network can poll the server for metadata when session information is needed as
a result of an endpoint attempting to access protected resources behind an Infranet
Enforcer.
When an authenticated user from an SA appliance that is configured as an IF-MAP client
attempts to access resources that are protected by an Infranet Enforcer for an Infranet
Controller that is also configured as an IF-MAP client, the Infranet Controller automatically
provisions an auth table entry for the user on the Infranet Enforcer to allow access without
requiring the user to authenticate to the Infranet Controller.
The Infranet Enforcer as an IF-MAP client subscribes to session information and other
data for the endpoint based on the originating IP address. The authenticating SA appliance
(the original IF-MAP client) publishes any changes in session parameters to the IF-MAP
server. Since the Infranet Controller that is protecting the accessed resources subscribes
to the metadata on the Federation server, session information is always current.
The Infranet Enforcer allows or denies traffic based on the resource access policies that
are configured on the Infranet Controller to which it is connected.
You configure server settings on the Infranet Controller that will be the IF-MAP server.
You configure client settings on each of the SA appliances and Infranet Controllers and
that will be connected in the network.
74
Copyright © 2011, Juniper Networks, Inc.
Chapter 3: General Access Management
In addition to the server and client settings, you configure Session-Export policies on SA
appliances and Infranet Controllers that are IF-MAP clients You configure and
Session-Import policies on Infranet Controller IF-MAP clients that are connected to
Infranet Enforcers.
IF-MAP allows servers and clients to publish, search, poll, and subscribe to data within
a network of IF-MAP servers and clients. All of the data from the IVEs and SA appliances
in the network that is published to the IF-MAP server uses the IF-MAP protocol.
Session-Export and Session-Import polices that you configure on the SA appliance and
Infranet Controller allow the devices to utilize the IF-MAP protocol to share session
information.
Session-Export policies specify how to translate an endpoint’s session on the SA Series
Appliance or the SA Series Appliance into IF-MAP data. To translate session information
into IF-MAP data, you enter detailed user information. The SA Series Appliance evaluates
the Export policies to determine a session’s IF-MAP roles, capabilities, identities, and
device attributes and publishes the data to the IF-MAP server.
The Session-Import policies that you configure on the SA Series Appliance specify how
the device should derive a username and a set of roles based on IF-MAP data that it
receives from the IF-MAP server from other SA Series Appliances. Import policies are
similar to Role Mapping policies on a realm. You must be precise when configuring Export
and Import policies, otherwise roles cannot be assigned properly.
The following figure depicts a scenario in which there are two Infranet Controllers
configured as IF-MAP clients, one SA Series Appliance configured as a IF-MAP client,
and another Infranet Controller configured as the IF-MAP server. Endpoints that
authenticate through any of the IF-MAP clients can access protected resources behind
the enforcement point attached to Infranet Controller 1.
Copyright © 2011, Juniper Networks, Inc.
75
Secure Access Administration Guide
Figure 4: Federation IF-MAP Topology
The interaction between the endpoints, the clients and the server is as follows:
•
An endpoint authenticates through the SA appliance depicted in the figure and starts
Network Connect or Junos Pulse.
•
The SA appliance provisions an IP address for the endpoint to use on the internal
network. Once the endpoint’s IP address on the internal network is known, the SA
appliance derives IF-MAP data from the endpoint’s session.
•
The SA appliance IF-MAP client publishes the session information as IF-MAP data to
the IF-MAP server using Session-Export policies.
•
When the user attempts to access resources behind the enforcement point, access is
blocked since the Infranet Enforcer has no information about the endpoint. The Infranet
Enforcer sends out a dynamic discovery message that includes the endpoint’s source
IP address.
•
Infranet Controller 1 uses the IP address to retrieve session data from the IF-MAP server.
•
The Infranet Controller uses Session-Import policies to retrieve session data from the
IF-MAP server.
The endpoint authenticating to the SA appliance must be running Network Connect.
Imported user sessions do not count against the maximum user count for either platform,
as each user is counted on the SA appliance from which they authenticated.
For details on configuring an IF-MAP Federation network see the Unified Access Control
Administrator’s Guide.
76
Copyright © 2011, Juniper Networks, Inc.
Chapter 3: General Access Management
IF-MAP Logging
IF-MAP related events are logged on both the IF-MAP server and the IF-MAP client.
Task Summary: Configuring IF-MAP Federation
The tasks listed in this topic are performed by an Infranet Controller administrator, in
conjunction with an administrator for the SA Series SSL VPN Appliance. On the SA Series
SSL VPN Appliance, you configure Session-Export policies and you configure IF-MAP
client settings. For details on configuring an IF-MAP Federation network see the Unified
Access Control Administrator’s Guide.
To use IF-MAP Federation, perform the following tasks on the Infranet Controller and SA
Series SSL VPN Appliance:
1.
Enable dynamic auth table provisioning on any connected Infranet Enforcers that you
want to use with Federation.
2. On the Infranet Controller, configure IF-MAP server settings to permit the server to
communicate with IF-MAP clients.
3. Configure IF-MAP client settings to permit clients to communicate with the IFMAP
server.
4. On the Infranet Controller and SA appliance, coordinate Session-Import policies,
Session-Export policies, roles, and resource access policies between all of the clients
in the Federated network.
5. Configure Session-Export policies on SA Series Appliances to define how sessions
are translated into IF-MAP data.
6. Configure Session-Import policies on SA Series Appliances that correspond with
Export policies to translate IF-MAP data into SA Series Appliance roles.
7. On the Infranet Controller, configure Source IP policies for SA appliance users who
will use Source IP to access the network.
Related
Documentation
•
Configuring IF-MAP Server Settings on page 77
•
Configuring the IF-MAP Federation Client on page 78
•
Session-Export and Session-Import Policies on page 79
•
Troubleshooting the IF-MAP Federation Network on page 84
Configuring IF-MAP Server Settings
You must add all IF-MAP Clients to the SA Series Appliance IF-MAP server. To add clients,
you must specify the IP address and the security mechanism and credentials for the
client.
For details on configuring an IF-MAP Server see the Unified Access Control Administrator’s
Guide.
Copyright © 2011, Juniper Networks, Inc.
77
Secure Access Administration Guide
Related
Documentation
•
Troubleshooting the IF-MAP Federation Network on page 84
Configuring the IF-MAP Federation Client
You must identify the IF-MAP server to each SA appliance IF-MAP client. To add the
server, you specify the IF-MAP URL of the server and how to authenticate to the server.
Match the URL and security settings to equal those on the IF-MAP server(s) to which the
IF-MAP client will connect.
To configure IF-MAP client settings on the SA appliances that will be IF-MAP clients:
1.
From the admin console select System > IF-MAP Federation > Overview.
2. Select the Enable IF-MAP Client option button.
3. Type the Server URL for IF-MAP Web service on the IF-MAP server. Append the server
URL with /dana-ws/soap/dsifmap for all Juniper Networks IF-MAP servers.
4. Select the Client Authentication Method: Basic or Certificate.
a. If you select Basic, enter a Username and Password. This is the same as the
information that was entered on the IF-MAP server.
b. If you select Certificate, select the Device Certificate to use.
c. Ensure that the certificate of the CA that signed the IF-MAP server certificate is
added from the System > Configuration > Certificates > Trusted Server CA page.
The IF-MAP client validates the IF-MAP server certificate: if validation fails, the
connection fails. Ensure that the hostname in the IF-MAP URL on the client machine
matches the hostname of the server certificate on the IFMAP server, and that the
CA that signed the server certificate is configured as a trusted server CA on the
IF-MAP client.
5. Click Save Changes.
Related
Documentation
•
Configuring IF-MAP Server Settings on page 77
IF--MAP Federation Network Timing Considerations
It is important that the time on all IF-MAP servers is correct, as timeout issues are critical
to ensure that IF-MAP provides complete and timely information. The IFMAP Federation
is designed to fail secure. If any component in the network does not receive timely
information, the IF-MAP metadata will be purged from the data stores.
The components are designed to fail-secure. If complete and timely information can not
be provided, a user’s session will be deleted. For example, if the chain of connections
between an IF-MAP client that publishes a session and a client that grants access to a
resource breaks, the client that granted access will remove the session. The fail-secure
time limit is three minutes.
78
Copyright © 2011, Juniper Networks, Inc.
Chapter 3: General Access Management
The timeout limit for IF-MAP is three minutes and applies to the following events:
Related
Documentation
•
An IF-MAP server (or cluster) loses contact with one of its IF-MAP clients
•
An IF-MAP server (or cluster) loses contact with one of its IF-MAP clients
•
An IF-MAP server (cluster) loses contact with one of the other IF-MAP server (clusters)
in the IF-MAP federation
•
A Juniper IF-MAP client loses contact with its IF-MAP server (cluster) for too long
•
Configuring IF-MAP Server Settings on page 77
•
Configuring the IF-MAP Federation Client on page 78
•
Session-Export and Session-Import Policies on page 79
•
Troubleshooting the IF-MAP Federation Network on page 84
Session-Export and Session-Import Policies
You configure Session-Export policies on all of the SA appliances and Infranet Controllers
in the Federation network that are IF-MAP clients. These policies allow IF-MAP clients
to translate outgoing session information into IF-MAP data and incoming IF-MAP data
into session information. These translations enable sessions to be shared between SA
appliances and Infranet Controllers even if the devices sharing sessions have different
role configurations.
To accurately configure Session-Export and Session-Import policies you need a minimal
understanding of IF-MAP identifiers and IF-MAP metadata. An identifier is a unique value
required for all metadata operations. Each instance of metadata is associated with an
identifier. Examples of identifiers include access-request, identity, IP address, and MAC
address. Examples of metadata include capability, role, and device-attribute.
IF-MAP recognizes two metadata types that are similar to roles on the SA Series
Appliance: IF-MAP roles and IF-MAP capabilities. An IF-MAP role is an attribute assigned
to a user in the organization. When IF-MAP metadata is published to the IF-MAP server,
this information could be one way to identify individuals on the network. This is somewhat
different from the concept of roles on the SA appliance. An IF-MAP capability is closer
to the concept of a role on the SA appliance. An IFMAP capability is a collection of
privileges assigned as a result of an access request. This is more analogous to an SA
appliance role since they are derived through role mapping in an authentication realm.
The data that is published to the IF-MAP server about a user session is derived by applying
the Session-Export policies to the user session. The Session-Import policies are applied
to the data from the IF-MAP server to assign a set of roles to the user.
When an endpoint attempts to access protected resources associated with an SA Series
Appliance, the device queries the IF-MAP server for data. The Infranet Controller uses
Session- Import policies to derive roles and a user name from the IF-MAP data. For
example, you could configure a Session-Import policy that looks for a specific Host
Checker policy (you specify the Host Checker policy in the Session-Import policy). If the
Copyright © 2011, Juniper Networks, Inc.
79
Secure Access Administration Guide
Infranet Controller finds a match (in this case the Host Checker device attribute ), the
user can be assigned a role specified in the Session-Import policy.
All of the administrators who are configuring devices in the IF-MAP Federation network
must agree on a set of capabilities, roles and device attributes and their meanings to be
used with IF-MAP. Then, each administrator configures their device to map between
local sessions and IF-MAP data. The following figure illustrates a coordinated IF-MAP
Federated network configuration with policies that permit an example user to access
protected resources.
Figure 5: Session-Import and Session-Export Policies
To further your understanding of Session-Import and Session-Export policies, please
note the following Juniper Networks IF-MAP conventions:
80
•
An SA Series Appliance maps to the identical IF-MAP username.
•
A role on an SA Series Appliance is paired with an IF-MAP capability.
•
Capabilities can have the same name as the roles they are paired with, or a different
name.
•
When different IF-MAP clients have different but equivalent role names (e.g. Legal and
Law, both referring to members of the corporate legal department) a single IF-MAP
capability must be chosen.
•
Not every role needs to be paired with an IF-MAP capability: roles can be local to an
SA Series Appliance.
Copyright © 2011, Juniper Networks, Inc.
Chapter 3: General Access Management
•
After you decide on pairings between IF-MAP capabilities and the roles on the SA Series
Appliance, you create a session export policy for each pairing. On an Infranet Controller
that controls Infranet Enforcers, you create a session import policy.
•
The only parameters for the policies are the SA appliance roles and the IF-MAP
capability; everything else is fixed.
Default Session-Export and Session-Import Policy Action
By default, Session-Import and Session-Export IF-MAP policies are configured to allow
IF-MAP capabilities (the equivalent of SA Series Appliance roles) to be published to the
IF-MAP server and retrieved from the IF-MAP server, provided there are matching roles
on each IF-MAP client. You can open new Session-Import and Session-Export policies
on each device, and then name and close the policies. Any matching roles that the IF-MAP
clients in the federated network have can be used to access resources.
Advanced Session-Export and Session-Import Policies
By default, advanced policy actions are not visible unless you click the advanced options
links on the Session-Export and Session-Import policy pages. In default mode, you
configure Session-Export and Session-Import policies using IF-MAP capabilities and SA
Series Appliance roles.
Device attributes, IF-MAP roles and identities can be accessed through the advanced
options links. IF-MAP capabilities and SA Series Appliance roles should provide the
functionality that most SA Series Appliance IF-MAP Federation requires.
Related
Documentation
•
Configuring Session-Export Policies on page 81
•
Session-Import Policies on page 83
Configuring Session-Export Policies
Session-Export policies determine how users are identified on the IF-MAP server when
their session is published via IF-MAP: the policy sets the IF-MAP identifiers. You define
attributes for users that will be used to determine role matching on different Infranet
Controllers. For example, you might configure a Session-Export policy to specify that any
users that belong to the “engineering” role should be identified with the “engineering”
IF-MAP capability on the IF-MAP server. That identity will be included in the session
information to which other IF-MAP clients subscribe. You configure corresponding
Session-Import Policies on Infranet Controllers to identify which roles the user should
be assigned.
You configure Session-Export policies based on Infranet Controller or SA Appliance roles,
and users belonging to those roles can access resources on an Infranet Enforcer only if
the role can be successfully matched with a role on the target Infranet Controller. You
configure Session-Export policies on all Infranet Controllers and SA appliances for which
you have users that will be allowed to access resources behind an Infranet Enforcer in
the network.
Copyright © 2011, Juniper Networks, Inc.
81
Secure Access Administration Guide
When a user for whom Session-Export policies has been configured successfully
authenticates to the network, the Session-Export policies are used to translate the user
session into IF-MAP data which is then sent to the IF-MAP server. When the user attempts
to access a resource that is protected by an Infranet Enforcer, the target Infranet Controller
then attempts to translate the IF-MAP data for the user into a user name and roles using
the Session-Import policies that are configured on the second Infranet Controller device.
Administrative Domains In Session-Export Policies
In a Layer 2 environment, session information on the IF-MAP server includes a MAC
address. If an export policy specifies an Administrative Domain, the domain is associated
with the MAC address published to the IF-MAP server (the administrative domain is also
associated with the identity published to the IF-MAP server).
A DHCP server assigns an IP address to the endpoint after authentication. An IFMAP
enabled DHCP server publishes an ip-mac link to IF-MAP, associating the endpoint’s IP
address with its IF-MAP session information.
Including administrative domains in MAC addresses allows the ip-mac link to be created
based on the administrative domain.
If your IF-MAP Federated network spans different administrative domains, you should
configure separate Session-Export policies for each domain to prevent MAC address
spoofing. Each administrative domain should have an associated DHCP server and unique
Session-Export policies.
Other aspects of the Session-Export policies within the IF-MAP Federated network can
overlap.
To configure a Session-Export policy:
1.
From the admin console select System > IF-MAP > Session-Export Policies.
2. Click New to create a new policy.
3. Type a Policy Name, and optionally a Description.
4. Optionally, add Available Rolesto the Selected Rolescolumn to determine the roles
for which this policy should apply. If you do not add any roles, the policy applies to all
sessions. However, if you have non-interactive devices such as printers that do not
need access, you may want to manually add roles and exclude those roles with
non-interactive devices.
5. Under Policy Actions, Select Set IF-MAP Capabilities and choose the applicable roles.
82
•
Copy Matching Roles—Selecting this action copies all of the user roles that match
the roles specified in the Roles section of this policy into the IF-MAP capabilities
data.
•
Copy all Roles—Selecting this action copies all of the roles from the user session
to the IF-MAP cabilities data.
•
Set capabilities specified below—Enter capabilities, one per line.
Copyright © 2011, Juniper Networks, Inc.
Chapter 3: General Access Management
6. Select Stop processing policies when this policy matches to specify that when this
policy is matched, no more Session-Export policies should be applied.
7. Select Save Changes, or continue to configure Advanced Actions.
To configure advanced options (generally not required for Infranet Controller and SA
Appliance IF-MAP Federation):
1.
Select the View Advanced Actions link. Additional options appear on the page.
2. Set IF-MAP Identity—If this action is chosen, enter the Identity and select an Identity
Type from the menu. Identity is normally specified as <NAME>, which assigns the
user’s login name. Any combination of literal text and context variables may be
specified. If you choose other for Identity Type, enter a unique Identity Type in the text
box.
3. Optionally type the Administrative Domain for the Session-Export policy. This optional
field is applied to identity and MAC address data. One example for using this field is
in a large network environment with several domains in which a username could be
duplicated. By entering the domain, you ensure that the correct user is identified.
4. Set IF-MAP Roles—If this action is selected, select the applicable roles.
•
Copy Matching Roles—Selecting this action copies all of the user roles that match
the roles specified in the Roles section of this policy into the IF-MAP capabilities
data.
•
Copy all Roles—Selecting this action copies all of the roles from the user session
to the IF-MAP cabilities data.
•
Set capabilities specified below—Enter capabilities, one per line.
5. Set IF-MAP Device Attributes—Device attributes represent a passed Host Checker
policy on the Infranet Controller or SA appliance.
•
Copy Host Checker policy names—The name of each Host Checker policy that
passed for the session is copied to a device attribute.
•
Set Device Attributes—Type Device Attributes, one per line, into the text box.
6. Select Save Changes to save this advanced Session-Export policy.
You must create corresponding Session-Import policies that allow IF-MAP client Infranet
Controllers that are connected to an Infranet Enforcer in front of protected resources to
collect IF-MAP data from the IF-MAP server.
Related
Documentation
•
Session-Export and Session-Import Policies on page 79
•
Troubleshooting the IF-MAP Federation Network on page 84
Session-Import Policies
The Session-Export policies that you create allow IF-MAP data that represents a session
to be stored on the IF-MAP server. Session-Import policies specify how the Infranet
Controller derives a set of roles and a username from the IF-MAP data in the IF-MAP
Copyright © 2011, Juniper Networks, Inc.
83
Secure Access Administration Guide
server. Session-Import policies establish rules for importing user sessions from an SA
appliance. Import policies allow you to match authenticated users with corresponding
roles on the target device. For example, you might configure an Import policy to specify
that when IF-MAP data for a session includes the “Contractor” capability, the imported
session should have the “limited” role. Session-Import policies allow the Infranet Controller
to properly assign roles based on information that the IF-MAP server provides.
You configure Session-Import policies on IF-MAP client IVEs that are connected to an
Infranet Enforcer in front of protected resources. For information about configuring
Session-Import policies, see the Unified Access Control Administrator’s Guide.
Related
Documentation
•
Troubleshooting the IF-MAP Federation Network on page 84
Troubleshooting the IF-MAP Federation Network
Diagnostic tools on the Infranet Controller and SA appliance can assist you with
troubleshooting a federated network.
IF-MAP Client User Messages—On the IF-MAP client, logs information that is published
and removed from the IF-MAP server.
•
Enable IF-MAP Client User Messages from Log/Monitoring > User Access > Settings
on the Infranet Controller and SA appliance IF-MAP client.
IF-MAP Server Trace—On the IF-MAP server, logs the XML for all IF-MAP requests and
responses.
•
Enable the IF-MAP Server Trace from Log/Monitoring > Events > Settings on the
IF-MAP server.
IF-MAP Server Trace should only be enabled for troubleshooting purposes, as running
this diagnostic incurs a large performance impact.
Related
Documentation
•
Viewing Active Users on the IF-MAP Client on page 84
Viewing Active Users on the IF-MAP Client
On an IF-MAP client, you can view all of the sessions from other Infranet Controllers or
SA appliances that currently access the client (the imported sessions). Session
information that can be viewed includes the username, roles, the user’s endpoint IP
address, and the IP address of the Infranet Controller or SA appliance that authenticated
the user. You can select and remove sessions either temporarily or permanently. A
temporarily removed session can be restored in response to a request for continued
access. A permanently removed session cannot be restored.
To view, de-activate, or activate current sessions on an IF-MAP client:
1.
Select System > IF-MAP > Active Users from the IF-MAP client admin console.
2. Select Imported or Exported.
84
Copyright © 2011, Juniper Networks, Inc.
Chapter 3: General Access Management
3. Select Activate or De-activate.
Related
Documentation
•
Troubleshooting the IF-MAP Federation Network on page 84
Trusted Server List
The SA Series SSL VPN Appliance uses two mechanisms to install and launch client
software from a web browser:
•
ActiveX controls (available only for Windows/IE)
•
Java applets
With both mechanisms, the user is prompted to trust ActiveX controls and Java applets
they have not run before. Inherent problems with these types of mechanisms are:
•
When the user trusts an ActiveX control that control is trusted forever.
•
When trusting a Java applet, users are trusting all code that is signed by the exact same
code signing certificate.
To address the above, administrators can create a text file (called a whitelist) that
contains a list of trusted SA Series SSL VPN Appliances, fully qualified domain names
or IP addresses, one per line. Administrators can configure two types of whitelists:
•
Admin whitelist—The admin whitelist file can be modified only by the endpoint
administrator. The administrator must use SMS or other mechanism to copy the admin
whitelist file to the end-user's system. Admin whitelist files are located in:
%ProgramFiles%\Juniper Networks\Whitelist.txt (Windows)
/usr/local/juniper/whitelist.txt (Macintosh and Linux)
•
User whitelist—Users can themselves make the decision to trust a SA Series SSL VPN
Appliance. When the user makes a decision to trust an SA Series SSL VPN Appliance,
the SA Series SSL VPN Appliance gets added to the user whitelist. User whitelist files
are located in:
%AppData%\Juniper Networks\Whitelist.txt (Windows)
/~/Library/Application Support/Juniper Networks/whitelist.txt (Macintosh)
/~/.juniper_networks/whitelist.txt (Linux)
NOTE: The trusted server list feature is for applications launched from a
browser window. It does not apply to applications launched from the
command-line or other means.
Administrator and User Configuration
The following is a snippet of a whitelist file:
Copyright © 2011, Juniper Networks, Inc.
85
Secure Access Administration Guide
qa.juniper.net
dev1.juniper.net
66.129.224.48
NOTE: Whitelist files are not deleted when the SA Series SSL VPN Appliance
software is removed.
There are two modes of enforcement:
•
Allow Admin List Only—When software launches from an SA Series SSL VPN Appliance
that is not in the administrator whitelist, the launch fails and the user receives the error
message “You are not allowed to launch software downloaded from <server>. Contact
your system administrator for assistance.” If the SA Series SSL VPN Appliance is in the
administrator whitelist, the launch proceeds as requested.
•
Prompt—When software launches from an SA Series SSL VPN Appliance that is not
in the administrator whitelist or the user whitelist, the user is prompted if they want to
launch the software with the message "Do you want to download, install and/or
execute software from the following server". If the user declines, the launch fails. If the
user accepts, the launch proceeds. The user also has the option to automatically add
the SA Series SSL VPN Appliance to the user whitelist file by selecting one of the
following options from the message window:
•
Always —Add the server to the user whitelist file and download, install or launch the
software
•
Yes—Download, install or launch the software but don’t add the server to the user
whitelist file
•
No—Don’t download, install or launch software and don’t add the server to the user
whitelist file
If the first line of the whitelist file contains “AllowAdminListOnly” (case insensitive) then
Allow Admin List Only enforcement mode is used. Otherwise, prompt mode enforcement
is used.
A snippet of a whitelist file using Allow Admin List Only enforcement is shown here:
AllowAdminListOnly
qa.juniper.net
dev1.juniper.net
66.129.224.48
NOTE: Prompt enforcement is the default mode when you upgrade your SA
Series software to the latest revision.
To add clusters to the whitelist file:
•
86
For Active/Passive clusters enter the VIP in the whitelist.
Copyright © 2011, Juniper Networks, Inc.
Chapter 3: General Access Management
•
For Active/Active clusters enter the load balancer hostname in the whitelist.
White List Flow Chart
The following steps outline the process for determining whether to launch the software
1.
If the URL of the page initiating the launch does not begin with https, abort the launch
and notify the user.
2. Else if the admin whitelist exists,
•
If the origin site is listed in the whitelist, proceed with the launch.
•
If the origin site is not in the whitelist and the whitelist starts with
“AllowAdminListOnly”, abort the launch and notify the user.
3. Else if the user whitelist exists,
•
If the origin site is in the user whitelist, proceed with the launch.
4. Prompt the user if they trust the origin site.
5. If the user agrees to trust the origin:
•
If they select Always then add the server to user whitelist file.
•
Proceed with the launch.
6. Abort the launch.
Related
Documentation
•
Uploading Java Applets to Secure Access on page 348
Copyright © 2011, Juniper Networks, Inc.
87
Secure Access Administration Guide
88
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 4
User Roles
•
User Roles Overview on page 89
•
Configuring General Role Options on page 93
•
Role Restrictions on page 94
•
Specifying Role-Based Source IP Aliases on page 95
•
Specifying Role Session Options on page 96
•
Customizing the SA Series SSL VPN Appliance Welcome Page on page 98
•
Defining Default Options for User Roles on page 103
•
Customizing Messages on page 104
•
Customizing UI Views for User Roles on page 105
User Roles Overview
A user role is an entity that defines user session parameters (session settings and options),
personalization settings (user interface customization and bookmarks), and enabled
access features (Web, file, application, Telnet/SSH, Terminal Services, network, meeting,
and e-mail access). A user role does not specify resource access control or other
resource-based options for an individual request. For example, a user role may define
whether or not a user can perform Web browsing. However, the individual Web resources
that a user may access are defined by the Web resource policies that you configure
separately.
The supports two types of user roles:
•
Administrators—An administrator role specifies SA management functions and session
properties for administrators who map to the role. You can customize an administrator
role by selecting the SA feature sets and user roles that members of the administrator
role are allowed to view and manage. You can create and configure administrator roles
through the Delegated Admin Roles page. Click Administrators > Admin Roles in the
admin console.
•
Users—A user role is an entity that defines user session parameters, personalization
settings, and enabled access features. You can customize a user role by enabling
specific SA access features, defining Web, application, and session bookmarks, and
configuring session settings for the enabled access features. You can create and
Copyright © 2011, Juniper Networks, Inc.
89
Secure Access Administration Guide
configure user roles through the Roles page. Click Users > User Roles in the admin
console.
User roles are an integral part of the SA access management framework, and therefore
are available on all SA Series products. However, you can only access features through
a user role if you are licensed for the feature. For instance, if you are using an SA-700
appliance and have not purchased a Core Clientless Access upgrade license, you cannot
enable Web rewriting for a user role.
User Role Evaluation
The SA’s role mapping engine determines a user’s session role, or combined permissions
valid for a user session, as illustrated in the following figure. A detailed description of
each step follows the diagram.
Figure 6: Security Checks Performed by the SA Series Appliance to Create
a Session Role
90
Copyright © 2011, Juniper Networks, Inc.
Chapter 4: User Roles
The SA performs the following security checks to create a session role:
1.
The SA begins rule evaluation with the first rule on the Role Mapping tab of the
authentication realm to which the user successfully signs in. During the evaluation,
the SA determines if the user meets the rule conditions. If so, then:
•
The SA adds the corresponding roles to a list of “eligible roles” available to the user.
•
The SA considers whether or not the “stop on match” feature is configured. If so,
then the engine jumps to step 5.
2. The SA evaluates the next rule on the authentication realm’s Role Mapping tab
according to the process in Step 1 and repeats this process for each subsequent rule.
When the SA evaluates all role mapping rules, it compiles a comprehensive list of
eligible roles.
3. The SA evaluates the definition for each role in the eligibility list to determine if the
user complies with any role restrictions. The SA then uses this information to compile
a list of valid roles, whose requirements the user also meets.
If the list of valid roles contains only one role, then the SA assigns the user to that role.
Otherwise, the SA continues the evaluation process.
4. The SA evaluates the setting specified on the Role Mapping tab for users who are
assigned to more than one role:
•
Merge settings for all assigned roles—If you choose this option, then the SA
performs a permissive merge of all the valid user roles to determine the overall (net)
session role for a user session.
•
User must select from among assigned roles—If you choose this option, then the
SA presents a list of eligible roles to an authenticated user. The user must select a
role from the list, and the assigns the user to that role for the duration of the user
session.
•
User must select the sets of merged roles assigned by each rule—If you choose
this option, the SA presents a list of eligible rules to an authenticated user (that is,
rules whose conditions the user has met). The user must select a rule from the list,
and the SA performs a permiss merge of all the roles that map to that rule.
NOTE: If you use automatic (time-based) dynamic policy evaluation or you
perform a manual policy evaluation, the SA repeats the role evaluation
process described in this section.
Permissive Merge Guidelines
A permissive merge is a merge of two or more roles that combines enabled features and
settings following these guidelines:
Copyright © 2011, Juniper Networks, Inc.
91
Secure Access Administration Guide
•
Any enabled access feature in one role takes precedence over the same feature set
disabled in another role. For example, if a user maps to two roles, one of which disables
Secure Meeting while the other role enables Secure Meeting, the SA allows the user
to use Secure Meeting for that session.
•
In the case of Secure Application Manager, the SA enables the version corresponding
to the first role that enables this feature. Furthermore, the SA merges the settings from
all the roles that correspond to the selected version.
•
In the case of user interface options, the SA applies the settings that correspond to
the user’s first role.
•
In the case of session timeouts, the SA applies the greatest value from all of the roles
to the user’s session.
•
If more than one role enables the Roaming Session feature, the SA merges the netmasks
to formulate a greater netmask for the session.
•
When merging two roles that a user is mapped to—one in which bookmarks open in a
new window and one in which bookmarks open in the same window—the merged role
opens bookmarks in the same window.
•
When merging two roles in which the first role disables the browsing toolbar and the
second role enables either the framed or standard toolbar, the merged role uses the
settings from the second role and displays the specified browsing toolbar.
•
The merged role uses the highest value listed for the HTTP Connection Timeout. Click
Users > User Roles > Select Role > Web > Options then click View advanced options.
Configuration of User Roles
To create a user role:
1.
In the admin console, choose Users > User Roles.
2. Click New Role and then enter a name and optionally a description. This name appears
in the list of Roles on the Roles page.
Once you have created a role, you can click the role’s name to begin configuring it using
the instructions in the following sections.
92
Copyright © 2011, Juniper Networks, Inc.
Chapter 4: User Roles
NOTE: When you delete a role, the personal bookmarks, SAM settings, and
other settings may not be removed. Therefore, if you add a new role with the
same name, any users added to that new role may acquire the old bookmarks
and settings. In general, the SA Series Appliance enforces referential integrity
rules and does not allow you to delete any objects if they are referenced
elsewhere. For example, if a role is used in any of the realm's role mapping
rules, then the SA Series Appliance rejects the deletion of the role unless you
modify or delete the mapping rules.
When you create individual user accounts, you must add the users through
the appropriate authentication server (not the role). Or for instructions on
how to create users on third-party servers, see the documentation that comes
with that product.
Related
Documentation
•
Policies, Rules & Restrictions, and Conditions Overview on page 58
•
Configuring General Role Options on page 93
Configuring General Role Options
Click Overview at the top of the General tab to edit a role’s name and description, toggle
session and user interface options on and off, and enable access features. When you
enable an access feature, make sure to create corresponding resource policies.
To manage general role settings and options:
1.
In the admin console, click Users > User Roles > Role Name > General > Overview.
2. Revise the name and description and then click Save Changes (optional).
3. Under Options, check the role-specific options that you want to enable for the role.
The SA Series Appliance uses default settings for newly created roles or when you do
not select role-specific options.
Role-specific options include:
•
VLAN/Source IP—Select this option to apply the role settings configured on the
General > VLAN/Source IP page.
•
Session Options—Select this option to apply the role settings in the General >
Session Options page to the role.
•
UI Options—Select this option to apply the role settings in the General > UI Options
page to the role.
4. Under Access features, check the features you want to enable for the role. Options
include:
Copyright © 2011, Juniper Networks, Inc.
93
Secure Access Administration Guide
•
Web—intermediate Web URLs through the Content Intermediation Engine.
•
Files (Windows or UNIX/NFS version)—resource profile that controls access to
resources on Windows server shares or Unix servers.
•
Secure Application Manager (Windows version or Java version)—provides secure,
application-level remote access to enterprise servers from client applications.
•
Telnet/SSH—connect to internal server hosts in the clear using Telnet protocols
or to communicate over an encrypted Secure Shell (SSH) session through a
Web-based terminal session emulation.
•
Terminal Services—enable terminal emulation sessions on a Windows terminal
server, Citrix NFuse server, or Citrix Metaframe server.
•
Meetings—securely schedule and hold online meetings between both SA Series
users and non-SA Series users.
•
Email Client—enables users to use standards-based email clients to access
corporate email securely from remote locations without the need for any additional
software, such as a VPN client.
•
Network Connect—provides secure, SSL-based network-level remote access to
all enterprise application resources using the SA Series SSL VPN Appliance.
5. Click Save Changes to apply the settings to the role.
Related
Documentation
•
Role Restrictions on page 94
•
Specifying Role Session Options on page 96
Role Restrictions
Click Restrictions at the top of the General tab to specify access management options
for the role. The SA Series Appliance considers these restrictions when determining
whether or not to map a user to the role. The SA Series Appliance does not map users
to this role unless they meet the specified restrictions.
You may configure any number of access management options for the role. If a user does
not conform to all of the restrictions, the SA Series Appliance does not map the user to
the role.
To specify access management options for the role:
1.
In the admin console, click Users > User Roles > Role Name > General > Restrictions.
2. Click the tab corresponding to the option you want to configure for the role, and then
configure it.
Related
Documentation
94
•
Specifying Source IP Access Restrictions on page 65
•
Specifying Browser Access Restrictions on page 67
Copyright © 2011, Juniper Networks, Inc.
Chapter 4: User Roles
•
Specifying Certificate Access Restrictions on page 69
Specifying Role-Based Source IP Aliases
Click VLAN/Source IP at the top of the General to define role-based source IP aliases. If
you want to direct traffic to specific sites based on roles, you can define a source IP alias
for each role. You use these aliases to configure virtual ports you define for the internal
interface source IP address. A back-end device can then direct end user traffic based on
these aliases, as long as you configure the back-end device, such as a firewall, to expect
the aliases in place of the internal interface source IP address. This capability enables
you to direct various end users to defined sites based on their roles, even though all of
the end user traffic has the same internal interface source IP address.
NOTE: You must define virtual ports to take advantage of the role-based
source IP aliases.
To specify a source IP alias for the role:
1.
In the admin console, click Users > User Roles > Role Name > General > VLAN/Source
IP.
2. Select the VLAN you want to use from the VLAN list, if you have defined VLAN ports
on your system.
If you have not defined VLAN ports, the option defaults to the Internal Port IP address.
If you have provisioned IVS systems, and you have defined VLAN ports and you want
any of those VLAN ports to appear in the VLAN list, then you must include the VLAN
ports in the Selected VLANs text box on the Root IVS configuration page.
3. Select a source IP address from the list.
4. Click Save Changes to apply the settings to the role.
NOTE: If an end user is mapped to multiple roles and the SA Series Appliance
merges roles, the SA Series Appliance associates the source IP address
configured for the first role in the list with the merged role.
You can specify the same source IP address for multiple roles. You cannot
specify multiple source IP addresses for one role.
Related
Documentation
•
Configuring Virtual Ports on page 682
•
Configuring the Internal and External Ports on page 676
Copyright © 2011, Juniper Networks, Inc.
95
Secure Access Administration Guide
Specifying Role Session Options
Use the Session tab to specify session time limits, roaming capabilities, session and
password persistency, request follow-through options, and idle timeout application
activity. Select the Session Options check box on the Overview tab to enable these
settings for the role.
To specify general session options:
1.
In the admin console, click User > User Roles > RoleName > General > Session
Options.
2. Under Session lifetime:
•
For Idle Timeout specify the number of minutes a non-administrative user session
may remain idle before ending. The minimum is five minutes. The default idle session
limit is 10 minutes, which means that if a user’s session is inactive for 10 minutes,
the SA Series SSL VPN Appliance ends the user session and logs the event in the
system log (unless you enable session timeout warnings described later).
•
For Max. Session Length specify the number of minutes an active nonadministrative
user session may remain open before ending. The minimum is six minutes. The
default time limit for a user session is 60 minutes, after which the SA Series SSL
VPN Appliance ends the user session and logs the event in the system log. During
an end user session, prior to the expiration of the maximum session length, the SA
Series SSL VPN Appliance prompts the user to reenter authentication credentials,
which avoids the problem of terminating the user session without warning.
•
For Reminder Time specify when the SA Series SSL VPN Appliance should prompt
non-administrative users, warning them of an impending session or idle timeout.
Specify the number of minutes before the timeout is reached.
NOTE: We recommend the difference between Idle Timeout and Reminder
Time be greater than two minutes. This ensures that the reminder pop-up
window appears at the correct time.
If you are using Secure Meeting, you can configure meeting session limits
by clicking Users > Resource Policies > Meetings in the admin console.
3. Under Enable session timeout warning:
•
Select Enabled to notify non-administrative users when they are about to reach a
session or idle timeout limit.
These warnings prompt users to take the appropriate action when they are close
to exceeding their session limits or idle timeouts, helping them save any in-progress
form data that would otherwise be lost. Users approaching the idle timeout limit
are prompted to reactivate their session. Users approaching the session time limit
are prompted to save data.
96
Copyright © 2011, Juniper Networks, Inc.
Chapter 4: User Roles
For example, an SA Series user may unknowingly reach the idle timeout set for his
role while using an e-mail client configured to work with the SA Series SSL VPN
Appliance, because the SA Series SSL VPN Appliance does not receive data while
the user composes e-mail. If the session timeout warning is enabled, however, the
SA Series SSL VPN Appliance prompts the user to reactivate his SA Series session
before the session times out and forces the user’s SA Series session to end. This
warning gives the user the opportunity to save his partially composed e-mail.
•
Select Display sign-in page on max session time out to display a new browser
sign-in page to the end user when their session times out. This option only appears
when you choose to enable the session timeout warning.
NOTE: If you do not select the Enable session timeout warning option,
the SA Series Appliance only displays expiration messages to users—it
does not give them the option to extend their sessions. Instead, users
need to access the SA Series Appliance sign-in page and authenticate
into a new session.
The Enable session timeout warning option only applies to expiration
messages displayed by the end user's browser, not by other clients such
as WSAM or Network Connect.
4. Under Roaming session:
•
Select Enabled to enable roaming user sessions for users mapped to this role. A
roaming user session works across source IP addresses, which allows mobile users
(laptop users) with dynamic IP addresses to sign in to the SA Series SSL VPN
Appliance from one location and continue working from another. Disable this feature
to prevent users from accessing a previously established session from a new source
IP address. This helps protect against an attack spoofing a user’s session, provided
the hacker was able to obtain a valid user's session cookie.
•
Select Limit to subnet to limit the roaming session to the local subnet specified in
the Netmask box. Users may sign in from one IP address and continue using their
sessions with another IP address as long as the new IP address is within the same
subnet.
•
Select Disabled to disable roaming user sessions for users mapped to this role.
Users who sign in from one IP address may not continue an active SA Series session
from another IP address; user sessions are tied to the initial source IP address.
5. Under Persistent session, select Enabled to write the SA Series session cookie to the
client hard disk so that the user’s SA Series credentials are saved for the duration of
the SA Series session.
By default, the SA Series session cookie is flushed from the browser’s memory when
the browser is closed. The SA Series session length is determined by both the idle
timeout value and maximum session length value that you specify for the role. The
SA Series session does not terminate when a user closes the browser; an SA Series
session only terminates when a user signs out of the SA Series SSL VPN Appliance.
Copyright © 2011, Juniper Networks, Inc.
97
Secure Access Administration Guide
NOTE: If you enable the Persistent session option and a user closes the
browser window without signing out, any user may open another instance
of the same browser to access the SA Series SSL VPN Appliance without
submitting valid credentials, posing a potential security risk. We
recommend that you enable this feature only for roles whose members
need access to applications that require SA Series credentials and that
you make sure these users understand the importance of signing out of
the SA Series SSL VPN Appliance when they are finished.
6. Under Persistent password caching, select Enabled to allow cached passwords to
persist across sessions for a role.
The SA Series SSL VPN Appliance supports the NT LAN Manager (NTLM)
authentication protocol and HTTP Basic Authentication and supports servers that
are set up to accept both NTLM and anonymous sign-in. The SA Series SSL VPN
Appliance caches NTLM and HTTP Basic Authentication passwords provided by users
so that the users are not repeatedly prompted to enter the same credentials used to
sign in to the SA Series Appliance server or another resource in the NT domain. By
default, the SA Series SSL VPN Appliance flushes cached passwords when a user
signs out. A user can delete cached passwords through the Advanced Preferences
page. After the end user logs in to the SA Series SSL VPN Appliance, click Preferences
and then click the Advanced tab.
7. Under Browser request follow-through, select Enabled to allow the SA Series SSL
VPN Appliance to complete a user request made after an expired user session after
the user reauthenticates.
8. Under Idle timeout application activity, select Enabled to ignore activities initiated by
Web applications (such as polling for e-mails) when determining whether a session
is active. If you disable this option, periodic pinging or other application activity may
prevent an idle timeout.
9. Under Upload Logs, select the Enable Upload Logs option to allow the user to transmit
(upload) client logs to the SA Series SSL VPN Appliance.
NOTE: Use the System > Log/Monitoring > Client Logs > Settings page
to completely enable client-side logs for the user.
10. Click Save Changes to apply the settings to the role.
Related
Documentation
•
Secure Meeting Overview on page 593
•
Customizing the SA Series SSL VPN Appliance Welcome Page
Click UI Options at the top of the General tab to specify customized settings for the SA
Series SSL VPN Appliance welcome page and the browsing toolbar for users mapped
98
Copyright © 2011, Juniper Networks, Inc.
Chapter 4: User Roles
to this role. The SA Series SSL VPN Appliance welcome page (or home page) is the Web
interface presented to authenticated SA Series users. Click Overview at the top of the
General tab, and then select the UI Options checkbox to enable custom settings for the
role; otherwise, the SA Series SSL VPN Appliance uses the default settings.
Personalization settings include the sign-in page, page header, page footer, and whether
or not to display the browsing toolbar. If the user maps to more than one role, then the
SA Series SSL VPN Appliance displays the user interface corresponding to the first role
to which a user is mapped.
To customize the SA Series SSL VPN Appliance welcome page for role users:
1.
Click Users > User Roles > RoleName > General > UI Options.
2. Under Header, specify a custom logo and alternate background color for the header
area of the SA Series SSL VPN Appliance welcome page (optional):
•
Click Browse and locate your custom image file. The new logo appears in the Current
appearance box only after you save your changes.
NOTE: You can only specify a JPEG or GIF file for a custom logo image.
Other graphics formats are not displayed properly in the JSAM status
window on some OS platforms.
•
Type the hexidecimal number for the background color or click the Color Palette
icon and pick the desired color. The Current appearance box updates immediately.
3. Under Sub-headers, select new background and text colors (optional):
•
Type the hexidecimal number for the Background color or click the Color Palette
icon and pick the desired color. The Current appearance box updates immediately.
•
Type the hexidecimal number for the Text color or click the Color Palette icon and
pick the desired color. The Current appearance box updates immediately.
4. Under Start page, specify the start page that you want users to see after they sign in
and when they click the Home icon on the toolbar:
•
Bookmarks page—Select this option to display the standard SA Series Appliance
Bookmarks page.
•
Meetings page—Select this option to display the standard SA Series Appliance
meetings page.
•
Custom page—Select this option to display a custom start page and then specify
the URL to the page. The SA Series SSL VPN Appliance rewrites the URL and creates
an access control rule to allow users access to the URL. (Note that users can also
enter the custom URL in the SA Series Browse field on the toolbar.) The SA Series
Copyright © 2011, Juniper Networks, Inc.
99
Secure Access Administration Guide
SSL VPN Appliance evaluates the access control rule after all other policies, which
means another policy could deny access to the URL.
•
Also allow access to directories below this url—Select this option to allow users
access to subdirectories of the custom-page URL. For example, if you specify
http://www.domain.com/, users can also access http://www.domain.com/dept/.
5. Under Bookmarks Panel Arrangement, arrange the panels as you want to display
them on the user's bookmarks page:
a. To select the name of a panel, click in the Left Column or Right Column list.
b. To position a panel above or below the other panels, click Move Up or Move Down.
c. To move a panel to the other side of the user's bookmarks page, click Move > or <
Move.
NOTE: The SA Series SSL VPN Appliance displays all panels under
Bookmarks Panel Arrangement for all licensed features regardless of
whether or not you enable the corresponding feature for the role.
The maximum number of combined bookmarks a role can have is
approximately 500. If a role has more than 500 bookmarks, some
operations (for example, delete role, duplicate role) may not work
correctly. The workaround is to split a role with a large number of
bookmarks into multiple roles.
6. Under Help Page, select options to control the Help page that appears when users
click the Help button on the toolbar:
100
•
Disable help link—Select this option to prevent users from displaying Help by
removing the Help button from the toolbar.
•
Standard help page—Select this option to display the standard SA Series end-user
Help.
•
Custom help page—Select this option to display a custom Help page. Specify the
URL to the custom help page, and then provide an optional width and height for
the help page’s window. The SA Series SSL VPN Appliance rewrites the URL and
creates an access control rule to allow users access to the URL. (Note that users
can also enter the custom URL in the SA Series Appliance Browse field on the
toolbar.) The SA Series SSL VPN Appliance evaluates the access control rule after
all other policies, which means another policy could deny access to the URL. (Note
that when you choose this option, the SA Series SSL VPN Appliance disables the
Tips link next to the Browse field.)
•
Also allow access to directories below this url—Select this option to allow users
access to subdirectories of the custom help page URL. For example, if you specify
http://www.domain.com/help, users can also access
http://www.domain.com/help/pdf/.
Copyright © 2011, Juniper Networks, Inc.
Chapter 4: User Roles
7. Under User Toolbar, select options for the toolbar on the SA Series Bookmarks page
and other secure gateway pages on the SA Series SSL VPN Appliance:
•
Home—Select this option to display the Home icon on the SA Series Bookmarks
page and other secure gateway pages on the SA Series SSL VPN Appliance.
•
Preferences—Select this option to display the Preferences button.
•
Session Counter—Select this option to display a time value on the user toolbar that
indicates the maximum remaining time allowed in the user’s current session. Note
that a period of user inactivity could also end the current session before this
maximum time expires.
•
Client Application Sessions—Select this option to display the Client Apps button
on the user toolbar. Users can click this button to display the Client Application
Sessions page where they can start client applications such as Network Connect
or Secure Application Manager. If you do not select this option, the SA Series SSL
VPN Appliance displays the Client Application Sessions panel on the SA Series
Bookmarks page.
8. Under Browsing toolbar, select options for the toolbar that users see when browsing
pages not located on the SA Series SSL VPN Appliance, such as external Web sites:
•
Show the browsing toolbar—Select this option to display the browsing toolbar.
•
Toolbar type—Select the type of browsing toolbar you want to display:
•
Standard—This toolbar can be moved to the top left or top right side of the
browser window. Users can also collapse and expand the toolbar. When collapsed,
the toolbar displays the custom logo only. The toolbar’s default state is expanded
and on the top right side of the browser window.
•
Framed—This toolbar remains fixed in a framed header section at the top of the
page.
NOTE: We recommend that you do not use the top variable when
working with a frame set because after the SA Series Appliance
intermediates the page, top might reference a different frame than
you intend. This change might make the framed toolbar disappear or
could cause your intermediated application to work erratically or
incorrectly. See the Content Intermediation Engine Best Practices Guide
located on the Juniper Networks website.
•
Toolbar logo and Toolbar logo (mobile)—Specify a custom logo (such as your
company’s logo) that you want to display on the standard and framed toolbars by
browsing to the image file (optional). When the user clicks the logo, the page you
specify for the Logo links to option appears. The current logo for the browsing toolbar
appears next to these options.
•
Logo links to— Select an option to link the browsing toolbar logo to a page that
appears when users click the logo:
Copyright © 2011, Juniper Networks, Inc.
101
Secure Access Administration Guide
•
•
Bookmarks page—Links the logo to the SA Series Appliance Bookmarks page.
•
“Start Page” settings—Links the logo to the custom start page you specified under
the Start Page section.
•
Custom URL—Links the logo to the URL you enter in the associated text box
(optional). This resource must be accessible to the SA Series SSL VPN Appliance.
The SA Series SSL VPN Appliance rewrites the URL and creates an access control
rule to allow users access to the URL. (Note that users can also enter the custom
URL in the SA Series Browse field on the toolbar.) The SA Series SSL VPN
Appliance evaluates the access control rule after all other policies, which means
another policy could deny access to the URL.
•
Also allow access to directories below this url—Select this option to allow users
access to subdirectories of the custom URL.
Specify the items you want to display in the browsing toolbar:
•
Enable "Home" link—Select this option to display the Home Page button, which
is linked to the SA Series Bookmarks page.
•
Enable "Add Bookmark" link—Select this option to display the Bookmark this
Page button.
•
Enable "Bookmark Favorites" link—Select this option to display the Bookmark
Favorites button. When the user clicks this button, the SA Series SSL VPN
Appliance displays a list of the bookmarks that the user specified as favorites on
the Add Web Bookmark page of the secure gateway.
•
Display Session Counter— Select this option to display a time value on the
browsing toolbar that indicates the maximum remaining time allowed in the user’s
current session. Note that a period of user inactivity could also end the current
session before this maximum time expires.
•
Enable "Help" link—Select this option to display the Help button, which is linked
to the Help page you specify for under Help page.
NOTE: If you click Users > User Roles > Role Name> Web > Options
and clear the User can add bookmarks check box, then the SA Series
SSL VPN Appliance does not display the Bookmark this Page and
Bookmark Favorites buttons on the browsing toolbar even if you select
the Enable "Add Bookmark" link and Enable "Bookmark Favorites"
link options.
•
Use Iframe in Toolbar—Select this option if you are having problems with using
iframes with JavaScript rewriting and with the Firefox web browser. This option
resolves interoperability problems with the above.
9. Under Personalized greeting, specify a greeting and notification message on the SA
Series Bookmarks page (optional):
102
Copyright © 2011, Juniper Networks, Inc.
Chapter 4: User Roles
•
Enabled—Select this option to display the personalized greeting. The SA Series SSL
VPN Appliance displays the username if the full name is not configured.
•
Show notification message—Select this option and enter a message in the
associated text box (optional). The message appears at the top of the SA Series
Appliance Bookmarks page after you save changes and the user refreshes that
page. You may format text and add links using the following HTML tags: <i>, <b>,
<br>, <font> and <a href>. However, the SA Series SSL VPN Appliance does not
rewrite links on the sign-in page (because the user has not yet authenticated), so
you should only point to external sites. Links to sites behind a firewall will fail. You
may also use SA Series system variables and attributes in this field.
NOTE: The length of the personalized greeting cannot exceed 12K, or
12288 characters.
If you use unsupported HTML tags in your custom message, the SA
Series Appliance may display the end user’s home page incorrectly.
10. Under Other, specify whether or not you want the copyright notice and label shown
in the footer (optional). This setting applies only to those users whose license permits
disabling the copyright notice. For more information about this feature, call Juniper
Networks Support.
11. Click Save Changes. The changes take effect immediately, but current user browser
sessions may need to be refreshed to see the changes.
12. Click Restore Factory Defaults to reset all user-interface options back to factory
defaults (optional).
Related
Documentation
•
Specifying Role Session Options on page 96
Defining Default Options for User Roles
You can define default options for all user roles, just as you can for delegated administrator
roles. The default options include, but are not limited to:
•
Session Options
•
Session lifetime—Define the idle timeout, maximum session length, and reminder
time in minutes.
•
Enable session timeout warning—Determine whether to display warning and login
page.
•
Roaming Session—Define level of mobility access.
•
Persistent Session—Define state across browser instances.
•
Persistent password caching—Define password state across sessions.
Copyright © 2011, Juniper Networks, Inc.
103
Secure Access Administration Guide
•
•
Browser request follow-through—Define response to browser session expiration.
•
Idle timeout application activity—Define SA Series Appliance response to application
session activity.
UI Options
•
Header—Define the logo and background color.
•
Sub-headers—Define the background and text color.
•
Start page—Define which page appears after the user logs in.
•
Bookmarks Panel Arrangement—Define the panels that appear on the user’s
bookmark page.
•
Help Page—Display standard or custom help.
•
User Toolbar—Define the links that appear on a user’s home page.
•
Browsing toolbar—Define the links that appear when a user is browsing an external
website.
•
Personalized Greeting—Display user’s name and notification message on the user’s
welcome page.
•
Bookmarks Panel Arrangement Other—Show copyright notice.
Defining Default Options for User Roles
To define the default options for all user roles:
1.
Select Users > User Roles.
2. Click Default Options.
3. Modify settings in the Session Options, UI Options, and Custom Messages tabs.
4. Click Save Changes. These become the new defaults for all new user roles.
If you do not want user roles to see the copyright notice, you can also clear the Show
copyright notice and “Secured by Juniper Networks” label in footers check box for user
roles, in general. That way, all subsequent roles you create do not allow the notice to
appear on the end user UI.
Related
Documentation
•
Configuring General Role Options on page 93
•
Role Restrictions on page 94
Customizing Messages
You can customize three basic messages that may be displayed to your end users when
they sign in to the SA Series SSL VPN Appliance. You can change the message text, and
you can add internationalized versions of the messages in Chinese (Simplified), Chinese
(Traditional), French, German, Japanese, Korean, and Spanish, in addition to English.
104
Copyright © 2011, Juniper Networks, Inc.
Chapter 4: User Roles
To customize messages:
1.
Select Users > User Roles.
2. Click Default Options.
3. Select the Custom Messagestab.
4. Select the language to use from the menu.
5. Enter your text in the Custom Message box, below the default message you want to
override.
6. Click Save Changes.
7. Repeat the process to create messages in additional languages.
Related
Documentation
•
About Multi-Language Support for the SA Series SSL VPN Appliance on page 987
•
Localizing the User Interface on page 988
•
Localizing Custom Sign-In and System Pages on page 989
Customizing UI Views for User Roles
You can use customization options on the Roles page to quickly view the settings that
are associated with a specific role or set of roles. For instance, you can view all of the
user roles and any Web bookmarks that you have associated with them. Additionally,
you can use these customized views to easily link to the bookmarks and other
configuration settings associated with a role.
To view a sub-set of data on the Roles page:
1.
Click Users > User Roles.
2. Select an option from the View list at the top of the page. The following table describes
these options.
3. Select one of the following options from the For list:
•
All roles—Displays the selected bookmarks for all user roles.
•
Selected roles—Displays the selected bookmarks for the user roles you choose. If
you select this option, select one or more of the check boxes in the Role list.
4. Click Update.
Table 5: View Menu Options
Option
Description
Enabled Settings
Displays a graph outlining the remote access mechanisms and general options that you
have enabled for the specified roles. Also displays links (the check marks) that you can use
to access the corresponding remote access and general option configuration pages.
Copyright © 2011, Juniper Networks, Inc.
105
Secure Access Administration Guide
Table 5: View Menu Options (continued)
Restrictions
Displays Host Checker and Cache Cleaner restrictions that you have enabled for the specified
roles. Also displays links you can use to access the corresponding Host Checker and Cache
Cleaner configuration pages.
Meetings
Displays Secure Meeting settings that you have configured for the specified roles. Also
displays links you can use to access the corresponding Secure Meeting configuration pages.
Network Connect
Displays Network Connect settings that you have configured for the specified roles. Also
displays links you can use to access the corresponding Network Connect configuration
pages.
Role Mapping Rule & Realms
Displays the assigned authentication realms, role mapping rule conditions, and permissive
merge settings for the specified roles.Also displays links you can use to access the
corresponding realm and role mapping configuration pages.
Bookmarks: All
Displays the names and types of all of the bookmarks that you have enabled for the specified
roles. Also displays links you can use to access the corresponding bookmark configuration
pages. (Note that if you created a bookmark through a resource profile, the link appears in
the Resource column. Otherwise, the link appears in the Bookmark column.)
Bookmarks: Web
Displays the Web bookmarks that you have enabled for the specified roles. Also displays
links you can use to access the corresponding bookmark configuration pages. (Note that
if you created a bookmark through a resource profile, the link appears in the Resource
column. Otherwise, the link appears in the Web Bookmark column.)
Bookmarks: Files (Windows)
Displays the Windows File bookmarks that you have enabled for the specified roles. Also
displays links you can use to access the corresponding bookmark configuration pages.
(Note that if you created a bookmark through a resource profile, the link appears in the
Resource column. Otherwise, the link appears in the Windows File Bookmark column.)
Bookmarks: Files (UNIX)
Displays the UNIX/NFS File bookmarks that you have enabled for the specified roles. Also
displays links you can use to access the corresponding bookmark configuration pages.
(Note that if you created a bookmark through a resource profile, the link appears in the
Resource column. Otherwise, the link appears in the UNIX File Bookmark column.)
Bookmarks: Telnet
Displays the Telnet/SSH bookmarks that you have enabled for the specified roles. Also
displays links you can use to access the corresponding bookmark configuration pages.
(Note that if you created a bookmark through a resource profile, the link appears in the
Resource column. Otherwise, the link appears in the Telnet/SSH Session column.)
Bookmarks: Terminal Services
Displays the Terminal Services bookmarks that you have enabled for the specified roles.
Also displays links you can use to access the corresponding bookmark configuration pages.
(Note that if you created a bookmark through a resource profile, the link appears in the
Resource column. Otherwise, the link appears in the Terminal Services Session column.)
ACL Resource Policies: All
Displays the resource policies that are associated with the specified roles. Includes the
type, name, description, action, and resources for each policy. Also displays links you can
use to access the corresponding policy configuration pages.
ACL Resource Policies: Web
Displays the Web resource policies that are associated with the specified roles. Includes
the type, name, description, action, and resources for each policy. Also displays links you
can use to access the corresponding policy configuration pages.
106
Copyright © 2011, Juniper Networks, Inc.
Chapter 4: User Roles
Table 5: View Menu Options (continued)
ACL Resource Policies: Files
(Windows)
Displays the Windows file resource policies that are associated with the specified roles.
Includes the type, name, description, action, and resources for each policy. Also displays
links you can use to access the corresponding policy configuration pages.
ACL Resource Policies: Files
(UNIX)
Displays the UNIX file resource policies that are associated with the specified roles. Includes
the type, name, description, action, and resources for each policy. Also displays links you
can use to access the corresponding policy configuration pages.
ACL Resource Policies: SAM
Displays the JSAM and WSAM resource policies that are associated with the specified roles.
Includes the type, name, description, action, and resources for each policy. Also displays
links you can use to access the corresponding policy configuration pages.
ACL Resource Policies: Telnet
Displays the Telnet/SSH resource policies that are associated with the specified roles.
Includes the type, name, description, action, and resources for each policy. Also displays
links you can use to access the corresponding policy configuration pages.
ACL Resource Policies: Terminal
Services
Displays the Terminal Services resource policies that are associated with the specified
roles. Includes the type, name, description, action, and resources for each policy. Also
displays links you can use to access the corresponding policy configuration pages.
ACL Resource Policies: Network
Connect
Displays the Network Connect resource policies that are associated with the specified roles.
Includes the type, name, description, action, and resources for each policy. Also displays
links you can use to access the corresponding policy configuration pages.
Resource Profiles: All
Displays the resource profiles that are associated with the specified roles. Includes the type,
name, bookmarks, and supporting policies for each profile. Also displays links you can use
to access the corresponding resource profile configuration pages.
Resource Profiles: Web
Applications
Displays the Web application resource profiles that are associated with the specified roles.
Includes the name, bookmarks, and supporting policies for each profile. Also displays links
you can use to access the corresponding resource profile configuration pages.
Resource Profiles: Web Hosted
Java Applets
Displays the hosted Java applet resource profiles that are associated with the specified
roles. Includes the name, bookmarks, and supporting policies for each profile. Also displays
links you can use to access the corresponding resource profile configuration pages.
Resource Profiles: Files
(Windows)
Displays the Windows file resource profiles that are associated with the specified roles.
Includes the name, bookmarks, and supporting policies for each profile. Also displays links
you can use to access the corresponding resource profile configuration pages.
Resource Profiles: Files (UNIX)
Displays the UNIX file resource profiles that are associated with the specified roles. Includes
the name, bookmarks, and supporting policies for each profile. Also displays links you can
use to access the corresponding resource profile configuration pages.
Resource Profiles: SAM Client
Applications
Displays the JSAM and WSAM application resource profiles that are associated with the
specified roles. Includes the name, bookmarks, and supporting policies for each profile.
Also displays links you can use to access the corresponding resource profile configuration
pages.
Resource Profiles: SAM WSAM
destinations
Displays the WSAM destination resource profiles that are associated with the specified
roles. Includes the name, bookmarks, and supporting policies for each profile. Also displays
links you can use to access the corresponding resource profile configuration pages.
Copyright © 2011, Juniper Networks, Inc.
107
Secure Access Administration Guide
Table 5: View Menu Options (continued)
Resource Profiles: Telnet/SSH
Displays the Telnet/SSH resource profiles that are associated with the specified roles.
Includes the name, bookmarks, and supporting policies for each profile. Also displays links
you can use to access the corresponding resource profile configuration pages.
Resource Profiles: Terminal
Services
Displays the Terminal Services resource profiles that are associated with the specified
roles. Includes the name, bookmarks, and supporting policies for each profile. Also displays
links you can use to access the corresponding resource profile configuration pages.
108
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 5
Resource Profiles
•
Resource Profiles on page 109
•
Resource Profile Components on page 110
•
Defining Resource Profile Resources on page 112
•
Defining Resource Profile Autopolicies on page 114
•
Defining Resource Profile Roles on page 115
•
Defining Resource Profile Bookmarks on page 116
•
Resource Profile Templates on page 117
Resource Profiles
A resource profile contains all of the resource policies, role assignments, and enduser
bookmarks required to provide access to an individual resource. Resource profiles simplify
resource configuration by consolidating the relevant settings for an individual resource
into a single page within the admin console.
The SA Series SSL VPN Appliance comes with two types of resource profiles:
•
Standard resource profiles enable you to configure settings for a variety of resource
types, such as Web sites, client/server applications, directory servers, and terminal
servers. When you use this method, you choose a profile type that corresponds to your
individual resource and then provide details about the resource.
•
Resource profile templates enable you to configure settings for specific applications.
When you use this method, you choose a specific application (such as the Citrix NFuse
version 4.0). Then, the SA Series SSL VPN Appliance pre-populates a variety of values
for you based on your chosen application and prompts you to configure additional
settings as necessary.
Resource profiles are an integral part of the SA Series access management framework,
and therefore are available on all SA Series products. However, you can only access
resource profile types that correspond to your licensed features. For instance, if you are
using an SA700 Series appliance and have not purchased a Core Clientless Access
upgrade license, you cannot create Web resource profiles.
To create resource profiles, you:
•
Create user roles through the Users > User Roles page of the admin console.
Copyright © 2011, Juniper Networks, Inc.
109
Secure Access Administration Guide
Related
Documentation
•
Create resource profiles through the Users > Resource Profiles page of the admin
console. When creating the resource profile, specify the resource, create autopolicies,
associate the profile with user roles, and create bookmarks as necessary.
•
Resource Profile Components on page 110
•
Resource Profile Templates on page 117
Resource Profile Components
Resource profiles contain the following components:
•
Resources—When you are defining a resource profile, you must specify the individual
resource that you want to configure (such as your company Intranet site or a Lotus
Notes application). All other major settings within the profile branch from this resource.
You can configure a variety of resource types, including Web sites, client/server
applications, directory servers, and terminal servers.
•
Autopolicies—When you are defining a resource profile, you generally create
autopolicies that establish the access requirements and other settings for the specified
resource. The most common type of autopolicy enables access to the primary resource
defined in the profile. Other policy types (such as compression and caching autopolicies)
“fine-tune” how the SA Series Appliance handles the data that it passes to and from
the specified resource.
•
Roles—When you are defining a resource profile, you generally associate the profile
with user roles. The specified roles then inherit the autopolicies and (optionally) the
bookmarks defined in the resource profile.
•
Bookmarks—When you are defining a resource profile, you may optionally create a
bookmark that links to the profile’s primary resource (such as your company intranet’s
main page). You can also create additional bookmarks that link to various sites within
the resource’s domain (such as the Sales and Marketing intranet pages). The SA Series
SSL VPN Appliance displays these bookmarks to users who are assigned to the user
roles that you specify.
The following diagrams illustrate how resource profiles simplify the configuration of
individual resources.
The following diagram shows how to configure resources using roles and resource policies.
Note that to enable a bookmark for multiple user roles, you must manually re-create the
bookmark and enable the appropriate access mechanism for each role. You must also
use a variety of pages in the administrator console to create associated resource policies
enabling access to the resource and other configuration options.
110
Copyright © 2011, Juniper Networks, Inc.
Chapter 5: Resource Profiles
Figure 7: Using Roles and Resource Policies to Configure Resources
The following diagram shows how to configure resources using resource profiles. Note
that you can create a bookmark, associate it with multiple user roles, and create the
associated autopolicies enabling access to the resource and other configuration options
through a single section in the administrator console. Also note that the SA Series SSL
VPN Appliance automatically enables the appropriate access mechanism to the roles
to which you assign the bookmark.
Copyright © 2011, Juniper Networks, Inc.
111
Secure Access Administration Guide
Figure 8: Using Resource Profiles to Configure Resources
Related
Documentation
•
Defining a Resource Profile on page 6
•
Defining Resource Profile Autopolicies on page 114
•
Defining Resource Profile Roles on page 115
•
Defining Resource Profile Bookmarks on page 116
Defining Resource Profile Resources
When you are defining a resource profile, you must specify the individual resource that
you want to configure. Type type of profile that you choose is dependent on the type of
resource you want to configure.
Table 6: Resource Profile Types and Configuration Information
Use this type of resource profile
To configure this type of resource
Web application/pages
URLs to Web applications, Web servers, and Web pages; Java applets that
are stored on third party servers.
Host Java applet
Java applets that you upload directly to the SA Series SSL VPN Appliance.
File browsing
Windows and UNIX/NFS servers, shares, and file paths
SAM client application
Client/server applications
WSAM destination
Destination networks or servers
112
Copyright © 2011, Juniper Networks, Inc.
Chapter 5: Resource Profiles
Table 6: Resource Profile Types and Configuration Information (continued)
Telnet/SSH
Telnet or SSH servers
Terminal Services
Windows and Citrix terminal servers
NOTE: You cannot configure applications through Network Connect using
resource profiles. Instead, you must use roles and resource policies.
When defining resources, you can use SA Series Appliance variables, such as <user> to
dynamically link users to the correct resources. For instance, you can specify the following
Web resource in order to direct users to their own individual intranet pages:
http://yourcompany.intranet/<user>
If the resource field of two different resource profiles are identical and both resource
profiles are mapped to the same role, a user might view a resource policy from one profile
and a resource policy from the other resource profile. For example, consider the following:
Resource Profile #1:
Resource Profile Name: Intranet
Resource Profile resource: http://intranet.company.com
Resource Profile Web ACL: http://intranet.company.com/sales/*
Mapped to Role: Sales
Resource Profile #2:
Resource Profile Name: Intranet for Sales
Resource Profile resource: http://intranet.company.com
Resource Profile Web ACL: http://intranet.company.com/sales/docs/*
The end-user that maps into the Sales role might see a bookmark name Intranet for
Sales but the Web ACL enforcement will be http://intranet.company.com/sales/*.
This type of configuration is not supported.
Related
Documentation
•
Defining a Resource Profile on page 6
•
Defining Resource Profile Autopolicies on page 114
•
Defining Resource Profile Roles on page 115
•
Defining Resource Profile Bookmarks on page 116
Copyright © 2011, Juniper Networks, Inc.
113
Secure Access Administration Guide
Defining Resource Profile Autopolicies
When you are defining a resource profile, you generally create autopolicies that establish
the access requirements and other settings for the specified resource. The most common
type of autopolicy enables access to the primary resource defined in the profile. Other
policy types (such as compression and caching autopolicies) “fine-tune” how the SA
Series SSL VPN Appliance handles the data that it passes to and from the specified
resource.
When creating resource profiles, the SA Series SSL VPN Appliance only displays those
autopolicies that are relevant to the resource profile type. For instance, you may choose
to enable access to a client/server application through a WSAM resource profile. When
you do, the SA Series SSL VPN Appliance displays autopolicies that you can use to enable
access to the specified application’s server. On the other hand, the SA Series SSL VPN
Appliance does not display Java access control autopolicies, since Java settings do not
apply to WSAM.
NOTE: When defining access policies, you must explicitly list each hostname
address. The policy checking system does not append or use the default
domain or search domains in the SA Series network settings.
Additionally, the SA Series SSL VPN Appliance consolidates all of the relevant autopolicy
options in a single page of the user interface, enabling you to understand all of the
configuration possibilities and requirements for any given resource type.
114
Copyright © 2011, Juniper Networks, Inc.
Chapter 5: Resource Profiles
NOTE: Access control autopolicies are generally based on the primary
resource that you define in the resource profile. If you change the profile’s
primary resource, however, the SA Series SSL VPN Appliance does not
necessarily update the corresponding autopolicies. You should re-evaluate
your autopolicies after changing the profile’s primary resource.
For administrators who are accustomed to using a pre-5.3 version of the SA
Series product, note that autopolicies are resource policies. The SA Series
SSL VPN Appliance allows you to sort and order autopolicies along with
standard resource policies in the Users > Resource Policies pages of the
admin console. However, the SA Series SSL VPN Appliance does not allow
you to access more detailed configuration options for autopolicies through
this section of the admin console. Instead, if you want to change the
configuration of an autopolicy, you must access it through the appropriate
resource profile.
For administrators who are accustomed to using a pre-5.3 version of the SA
Series product, note that you can also automatically create resource policies
by enabling the Auto-allow option at the role level. However, note that we
recommend that you use autopolicies instead, since they directly correspond
to the resource you are configuring rather than all resources of a particular
type. (You may also choose to enable the Auto-allow option for a role-level
feature and create autopolicies for resources of the same type. When you
do, the SA Series SSL VPN Appliance creates policies for both and displays
them in the appropriate resource policies page of the admin console.)
Related
Documentation
•
Defining a Resource Profile on page 6
•
Defining Resource Profile Autopolicies on page 114
•
Defining Resource Profile Roles on page 115
•
Defining Resource Profile Bookmarks on page 116
Defining Resource Profile Roles
Within a resource profile, you can assign user roles to the profile. For instance, you might
create a resource profile specifying that members of the “Customers” role can access
your company’s Support Center, while members of the “Evaluators” role cannot. When
you assign user roles to a resource profile, the roles inherit all of the autopolicies and
bookmarks defined in the resource profile.
Since the resource profile framework does not include options for creating roles, you
must create user roles before you can assign them to resource profiles. However, the
resource profile framework does include some user role configuration options. For instance,
if you assign a user role to a Web resource profile, but you have not enabled Web rewriting
for the role, the SA Series SSL VPN Appliance automatically enables it for you.
Copyright © 2011, Juniper Networks, Inc.
115
Secure Access Administration Guide
NOTE: Note that you can assign roles to a resource profile through the SA
Series role framework as well as the resource profile framework.
Related
Documentation
•
Defining a Resource Profile on page 6
•
Defining Resource Profile Autopolicies on page 114
•
Defining Resource Profile Bookmarks on page 116
Defining Resource Profile Bookmarks
When you create a resource profile, the SA Series SSL VPN Appliance generally creates
a bookmark that links to the profile’s primary resource (such as your company intranet’s
main page). Optionally, you may also create additional bookmarks that link to various
sites within the primary resource’s domain (such as the Sales and Marketing intranet
pages). When you create these bookmarks, you can assign them to user roles, thereby
controlling which bookmarks users see when they sign into the SA Series end-user console.
NOTE: WSAM and JSAM resource profiles do not include bookmarks, since
the SA Series SSL VPN Appliance cannot launch the applications specified
in the resource profiles.
For example, you may create a resource profile that controls access to your company
intranet. Within the profile, you may specify:
•
Resource profile name: Your Intranet
•
Primary resource: http://intranet.com
•
Web access control autopolicy: Allow access to http://intranet.com:80/*
•
Roles: Sales, Engineering
When you create this policy, the SA Series SSL VPN Appliance automatically creates a
bookmark called “Your Intranet” enabling access to http://intranet.com and displays the
bookmark to members of the Sales and Engineering roles.
You may then choose to create the following additional bookmarks to associate with
the resource profile:
116
•
“Sales Intranet” bookmark: Creates a link to the http://intranet.com/sales page and
displays the link to members of the Sales role.
•
“Engineering Intranet” bookmark: Creates a link to the http://intranet.com/engineering
page and displays the link to members of the Engineering role.
Copyright © 2011, Juniper Networks, Inc.
Chapter 5: Resource Profiles
NOTE: When configuring bookmarks, note that:
Related
Documentation
•
You can only assign bookmarks to roles that you have already associated
with the resource profile—not all of the roles defined on the SA Series SSL
VPN Appliance. To change the list of roles associated with the resource
profile, use settings in its Roles tab.
•
Bookmarks simply control which links the SA Series SSL VPN Appliance
displays to users—not which resources the users can access. For instance,
in the example used above, a member of the Sales role would not see a
link to the Engineering Intranet page, but he could access it by entering
http://intranet.com/engineering his Web browser’s address bar. Similarly,
if you delete a bookmark, users can still access the resource defined in the
profile.
•
The SA Series SSL VPN Appliance allows you to create multiple bookmarks
to the same resource. If you assign duplicate bookmarks to the same user
role, however, the SA Series SSL VPN Appliance only displays one of them
to the users.
•
Bookmarks link to the primary resource that you define in the resource
profile (or a sub-directory of the primary resource). If you change the
profile’s primary resource, the SA Series SSL VPN Appliance updates the
corresponding bookmarks accordingly.
•
Defining a Resource Profile on page 6
•
Defining Resource Profile Autopolicies on page 114
•
Defining Resource Profile Roles on page 115
Resource Profile Templates
Resource profile templates enable you to configure settings for specific applications.
When you use this method, you choose a specific application (such as the Citrix NFuse
version 4.0). Then, the SA Series Appliance pre-populates a variety of values for you
based on your chosen application and prompts you to configure additional settings as
necessary.
Currently, the SA Series Appliance includes templates for the following third-party
applications:
•
Citrix
•
Lotus Notes
•
Microsoft Outlook
•
Microsoft Sharepoint
•
NetBIOS file browsing
Copyright © 2011, Juniper Networks, Inc.
117
Secure Access Administration Guide
Related
Documentation
118
•
About Citrix Templates on page 361
•
Creating Resource Profiles Using the Lotus iNotes Template on page 371
•
Standard Application Support: MS Outlook on page 512
•
Creating Resource Profiles Using the Microsoft Sharepoint Template on page 379
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 6
Virtual Desktop Resource Profiles
•
Virtual Desktop Resource Profile Overview on page 119
•
Configuring a Citrix XenDesktop Resource Policy on page 120
•
Configuring a VMware View Manager Resource Profile on page 121
•
Defining Bookmarks for a Virtual Desktop Profile on page 122
•
Configuring the Client Delivery on page 123
•
Connecting to the Servers on page 124
Virtual Desktop Resource Profile Overview
In addition to standard resource profiles and resource profile templates, you can configure
virtual desktops as resource profiles.
As with the other resource profiles, a virtual desktop profile contains all of the role
assignments and end-user bookmarks required to provide access to an individual resource.
Unlike other resource profile types, there is no resource policy to configure for virtual
desktops due to the dynamic nature of virtual desktops. The IP address and port of the
system is not known until the end-user launches a session so dynamic ACLs are used.
Icons in the Virtual Desktops section on the end-user’s home page represent desktops
defined by the administrator. Clicking the icon launches the session using the Virtual
Desktop Infrastructure (VDI) architecture.
A few of the main features of virtual desktop resource profiles are:
Related
Documentation
•
SSO so that the user can sign on without having to enter their credentials
•
Dynamic ACLs
•
Client delivery mechanism for end-users who do not have the client already installed
on their system
•
Connection logging
•
Configuring a Citrix XenDesktop Resource Policy on page 120
•
Configuring a VMware View Manager Resource Profile on page 121
•
Defining Bookmarks for a Virtual Desktop Profile on page 122
Copyright © 2011, Juniper Networks, Inc.
119
Secure Access Administration Guide
•
Configuring the Client Delivery on page 123
•
Connecting to the Servers on page 124
Configuring a Citrix XenDesktop Resource Policy
The Citrix XenDesktop manages a pool of virtual desktops hosted on virtual machines
and provides the connection management to those desktops. A list of XenDesktops is
displayed to the end-user as bookmarks. When a desktop is selected, the Citrix client is
launched and the user can access that desktop.
To configure a Citrix XenDesktop profile:
1.
Select Users > Resource Profiles > Virtual Desktops.
2. Click New Profile.
3. Select Citrix XenDesktop from the Type drop-down list.
4. Enter a name and description (optional) to identify this profile.
5. Enter the name or IP address and port of the connection broker using the format
ip:port. For example,
10.10.1.10:80
xml.example.com:80
You can enter more than one IP address. Place each address on a separate line.
6. Select the Use SSL for connecting to the Servercheckbox if SSL is required to connect
to the server.
7. Enter the username to connect to the connection broker or use the <USERNAME>
session variable.
8. Enter the password:
•
To use a variable password to connect to the connection broker, select Variable
Password and enter the variable in the form of <PASSWORD> or
<PASSWORD@SEcAuthServer>.
•
Select Password to use a static password to connect to the connection broker and
enter the user credential’s password.
9. Enter the domain where the connection broker is located.
10. Select Enable Java support to specify a Java applet to use to associate with the
resource profile. The SA Series Appliance uses this applet to intermediate traffic or
falls back to this applet when ActiveX is not available on the user’s system.
11. Click Save and Continue.
12. Select the roles to which this profile applies and click Add.
The Enabled Settings table under Users > User Roles also displays which roles have
virtual desktops enabled.
120
Copyright © 2011, Juniper Networks, Inc.
Chapter 6: Virtual Desktop Resource Profiles
13. Click Save Changes.
14. (Optional.) In the Bookmarks tab, modify the default bookmark created by the SA
Series SSL VPN Appliance and/or create new ones.
Related
Documentation
•
Virtual Desktop Resource Profile Overview on page 119
•
Configuring a VMware View Manager Resource Profile on page 121
•
Defining Bookmarks for a Virtual Desktop Profile on page 122
•
Configuring the Client Delivery on page 123
•
Connecting to the Servers on page 124
Configuring a VMware View Manager Resource Profile
VMware View Manager, formerly VMware VDI, lets you run virtual desktops in a datacenter
that provide end-users a single view of all their applications and data in a personalized
environment regardless of the device or location they log in from.
To configure a VMware View Manager profile:
1.
Select Users > Resource Profiles > Virtual Desktops.
2. Click New Profile.
3. Select VMware View Manager from the Type drop-down list.
4. Enter a name and description (optional) to identify this profile.
5. Enter the name or IP address and port of the connection broker using the format
ip:port. For example,
10.10.1.10:80
xml.example.com:80
You can enter more than one IP address. Place each address on a separate line.
6. Select the Use SSL for connecting to the Servercheckbox if SSL is required to connect
to the server.
7. Enter the username to connect to the connection broker or use the <USERNAME>
session variable.
8. Enter the password:
•
To use a variable password to connect to the connection broker, select Variable
Password and enter the variable in the form of <PASSWORD> or
<PASSWORD@SEcAuthServer>.
•
Select Password to use a static password to connect to the connection broker and
enter the user credential’s password.
9. Enter the domain where the View Manager server is located.
10. Click Save and Continue.
Copyright © 2011, Juniper Networks, Inc.
121
Secure Access Administration Guide
11. Select the roles to which this profile applies and click Add.
The Enabled Settings table under Users > User Roles also displays which roles have
virtual desktops enabled.
12. Click Save Changes.
13. (Optional.) In the Bookmarks tab, modify the default bookmark created by the SA
Series SSL VPN Appliance and/or create new ones.
Related
Documentation
•
Virtual Desktop Resource Profile Overview on page 119
•
Configuring a Citrix XenDesktop Resource Policy on page 120
•
Defining Bookmarks for a Virtual Desktop Profile on page 122
•
Configuring the Client Delivery on page 123
•
Connecting to the Servers on page 124
Defining Bookmarks for a Virtual Desktop Profile
When you create a virtual desktop resource profile, the SA Series Appliance automatically
creates a bookmark that links to the server that you specified in the resource profile. The
SA Series Appliance allows you to modify this bookmark as well as create additional
bookmarks to the same server.
These bookmarks are listed in the role bookmark pages (Users > User Roles > Role_Name
> Virtual Desktop > Sessions) but you cannot add, modify or delete the bookmarks from
the role bookmarks page. Bookmarks can only be added as part of the resource file.
To configure resource profile bookmarks for virtual desktop profiles:
1.
Select Users > Resource Profiles > Virtual Desktop.
2. Click the name of the virtual desktop profile.
3. Click the Bookmark tab to modify an existing session bookmark. Or, click New
Bookmark to create an additional session bookmark.
4. (Optional.) Change the name and description of the session bookmark. (By default,
the SA Series SSL VPN Appliance populates and names the session bookmark using
the resource profile name.)
5. Specify whether all desktops or to a selected subset of desktops are available to the
user.
The desktop list is retrieved from the connection broker using the credentials defined
in the profile resource page.
6. Enter the credentials used to log in to the actual VMware or XenDesktop machine.
The SA Series SSL VPN Appliance passes these credentials to the server so that users
can sign on without having to manually enter their credentials.
7. Specify how the window should appear to the user during a session by configuring
options in the Settings area of the bookmark configuration page.
122
Copyright © 2011, Juniper Networks, Inc.
Chapter 6: Virtual Desktop Resource Profiles
(XenDesktop) Under Preferred Client, you can select Automatic Detection, Citrix Client
or Java. If you select Automatic Detection, the SA Series Appliance checks to see if
Citrix Client is present. If it is not present, the end-user is given the choice to download
the Citrix Client or to use the alternate client, Java ICA Client.
8. Allow users to access local resources such as printers and drives through the terminal
session by configuring options in the Connect Devices area of the bookmark
configuration page.
(VMware) Enable MMR—Redirect certain multimedia codecs running on the remote
desktop to the local client for rendering of full-motion video and audio.
(VMware) Allow Desktop Reset—Allow users to reset their desktop without
administrative assistance. For example, if the desktop hangs, there is currently no way
for the user to perform a hard reboot of the desktop. This option allows the users to
restart their own virtual desktops thereby reducing the dependency on the
administrator or helpdesk.
9. Specify how the terminal emulation window should appear to the user during a terminal
session by configuring options in the Desktop Settings area.
10. Specify the roles to which you want to display the session bookmarks if you are
configuring the session bookmark through the resource profile pages, under Roles:
•
ALL selected roles—Displays the session bookmark to all of the roles associated
with the resource profile.
•
Subset of selected roles—Displays the session bookmark to a subset of the roles
associated with the resource profile. Then select roles from the ALL Selected Roles
list and click Add to move them to the Subset of selected roles list.
11. Click Save Changes.
Related
Documentation
•
Defining Display Options for the Windows Terminal Services Session on page 557
•
Virtual Desktop Resource Profile Overview on page 119
•
Configuring a Citrix XenDesktop Resource Policy on page 120
•
Configuring a VMware View Manager Resource Profile on page 121
•
Configuring the Client Delivery on page 123
•
Connecting to the Servers on page 124
Configuring the Client Delivery
You can use the Virtual Desktop Configuration page to define the client delivery
mechanism for end-users who do not have the client. The process is similar for both
XenDesktop and VMware View Manager.
Copyright © 2011, Juniper Networks, Inc.
123
Secure Access Administration Guide
1.
Choose System > Configuration> Virtual Desktop.
2. Select Download from the IVE to download the client file from the SA Series SSL
VPN Appliance. Click Browse to locate the client file (.msi, .exe or .cab) and enter the
version number.
3. Select Download from a URL to download the client file from the Internet. If desired,
enter a new URL to override the default.
4. Check the Access the URL through the Secure Gateway checkbox if end-users can
not directly access the specified web page. Selecting this option allows users to use
the secure gateway to access the URL.
5. Under Server Connection Timeout, enter the number of seconds to wait for the server
to respond before timing out.
Related
Documentation
•
Virtual Desktop Resource Profile Overview on page 119
•
Connecting to the Servers on page 124
Connecting to the Servers
When an end-user clicks a desktop icon, The SA Series SSL VPN Appliance passes
credentials to the server based on the desktop profile.
For XenDesktop, the SA Series SSL VPN Appliance authenticates to the Citrix DDC server
using credentials defined in the desktop profile. If successful, the list of available desktops
is returned by the DDC server and is represented as bookmarks to the end-user. When
an enduser clicks a XenDesktop icon, the SA Series SSL VPN Appliance retrieves the ICA
from the XenDesktop server and presents a desktop session to the user.
When an end-user clicks a VMware View Manager icon, the SA Series SSL VPN Appliance
authenticates to the View Manager using credentials defined in the desktop profile. If
authentication is successful, a JSESSIONID cookie is returned by the View Manager, the
SA Series SSL VPN Appliance creates a tunnel using the cookie for the duration of the
session.
If the desktop is unavailable, the client will continue to try to connect until the desktop
is available or until a predefined timeout period occurs. An error message lets the user
know the status, either that SA Series SSL VPN Appliance is retrying the connection or
that the desktop is unavailable. Similarly if the desktop is already in use by another
enduser, an error message is presented to the user.
User logs are updated to show which VM machines are assigned to each user. Username,
realm, VM IP, port, connection type, pool and connection broker are logged with each
message.
The Active Virtual Desktops Sessions page (System > Status > Virtual Desktop Sessions)
lists the active connections, including the connection broker, the VM machine assigned
to the user and the connection type.
124
Copyright © 2011, Juniper Networks, Inc.
Chapter 6: Virtual Desktop Resource Profiles
Related
Documentation
•
Virtual Desktop Resource Profile Overview on page 119
•
Configuring the Client Delivery on page 123
Copyright © 2011, Juniper Networks, Inc.
125
Secure Access Administration Guide
126
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 7
Resource Policies
•
Resource Policies on page 127
•
Resource Policy Components on page 128
•
Specifying Resources for a Resource Policy on page 129
•
Resource Policy Evaluation on page 131
•
Creating Detailed Rules for Resource Policies on page 133
•
Writing a Detailed Rule for Resource Policies on page 134
•
Customizing Resource Policy UI Views on page 136
Resource Policies
A resource policy is a system rule that specifies resources and actions for a particular
access feature. A resource is either a server or file that can be accessed through an SA
Series SSL VPN Appliance, and an action is to “allow” or “deny” a resource or to perform
or not perform a function. Each access feature has one or more types of policies, which
determine the SA Series SSL VPN Appliance’s response to a user request or how to enable
an access feature (in the case of Email Client). You may also define detailed rules for a
resource policy, which enable you to evaluate additional requirements for specific user
requests.
You can create the following types of resource policies through the Resource Policies
pages of the SA Series SSL VPN Appliance:
•
Web Resource Policies—The Web resource policies specify the Web resources to
which users may or may not browse. They also contain additional specifications such
as header caching requirements, servers to which java applets can connect, code-signing
certificates that the SA Series Appliance should use to sign java applets, resources
that the SA Series Appliance should and should not rewrite, applications for which the
SA Series Appliance performs minimal intermediation, and single sign-on options.
•
File Resource Policies—The file resource policies specify the Windows, UNIX, and NFS
file resources to which users may or may not browse. hey also contain additional
specifications such as file resources for which users need to provide additional
credentials.
Copyright © 2011, Juniper Networks, Inc.
127
Secure Access Administration Guide
•
Secure Application Manager Resource Policies—The Secure Application Manager
resource policies allow or deny access to applications configured to use JSAM or WSAM
to make socket connections.
•
Telnet/SSH Resource Policies—The Telnet/SSH resource policies allow or deny
access to the specified servers.
•
Terminal Services Policies—The Terminal Services resource policies allow or deny
access to the specified Windows servers or Citrix Metaframe servers.
•
Network Connect Resource Policies—The Network Connect resource policies allow
or deny access to the specified servers and specify IP address pools.
•
Secure Email Client Resource Policies—The Secure Email Client access resource
policy allows you to enable or disable email client support. To allow end-users to open
and save email attachments of different document types in OWA and iNotes, select
the OWA or iNotes type when defining a Web Application Resource Profile.
NOTE: You can also create resource policies as part of the resource profile
configuration process. In this case, the resource policies are called “advanced
policies.”
Resource policies are an integral part of the SA Series access management framework,
and therefore are available on all SA Series products. However, you can only access
resource policy types that correspond to your licensed features. For instance, if you are
using an SA700 Series appliance and have not purchased a Core Clientless Access
upgrade license, you cannot create Web resource policy.
Related
Documentation
•
Resource Policy Components on page 128
•
Resource Policy Evaluation on page 131
•
Creating Detailed Rules for Resource Policies on page 133
•
Customizing Resource Policy UI Views on page 136
Resource Policy Components
A resource policy contains the following information:
128
•
Resources—A collection of resource names (URLs, host names, or IP address/netmask
combinations) that specifies the resources to which the policy applies. You can specify
a resource using a wildcard prefix to match host names. The default resource for a
policy is star (*), meaning that the policy applies to all related resources.
•
Roles—An optional list of user roles to which this policy applies. The default setting is
to apply the policy to all roles.
•
Action—The action for the SA Series SSL VPN Appliance to take when a user requests
the resource corresponding to the Resource list. An action may specify to allow or deny
Copyright © 2011, Juniper Networks, Inc.
Chapter 7: Resource Policies
a resource or to perform or not perform an action, such as to rewrite Web content or
allow Java socket connections.
•
Detailed Rules—An optional list of elements that specifies resource details (such as
a specific URL, directory path, file, or file type) to which you want to apply a different
action or for which you want to evaluate conditions before applying the action. You
can define one or more rules and specify the order in which the SA Series SSL VPN
Appliance evaluates them.
Specifying Resources for a Resource Policy
The SA Series platform’s engine that evaluates resource policies requires that the
resources listed in a policy’s Resources list follow a canonical format. This section
describes the canonical formats available for specifying Web, file, and server resources.
When a user tries to access a specific resource, an SA Series SSL VPN Appliance compares
the requested resource to the resources specified in the corresponding policies, starting
with the first policy in a policy list. When the engine matches a requested resource to a
resource specified in a policy’s Resources list, it then evaluates further policy constraints
and returns the appropriate action to the appliance (no further policies are evaluated).
If no policy applies, then the appliance evaluates the auto-allow bookmarks (if defined);
otherwise the default action for the policy is returned.
NOTE: You may not see the auto-allow option, if you are using a new
installation, if you use resource profiles rather than resource policies, or if an
administrator has hidden the option.
General Notes About the Canonical Formats
Please note the following when using canonical formats:
•
If a path component ends with forward-slash_star (/*), then it matches the leaf node
and everything below. If the path component ends with forwardslash_ percent (/%),
then it matches the leaf node and everything one-level below only. For example:
/intranet/*matches:
/intranet
/intranet/home.html
/intranet/elee/public/index.html
/intranet/% matches:
/intranet
/intranet/home.html
but NOT /intranet/elee/public/index.html
•
A resource’s host name and IP address are passed to the policy engine at the same
time. If a server in a policy’s Resources list is specified as an IP address, then the
evaluation is based on the IP address. Otherwise, the engine tries to match the two
host names—it does not perform a reverse-DNS-lookup to determine the IP.
Copyright © 2011, Juniper Networks, Inc.
129
Secure Access Administration Guide
NOTE: You cannot specify a host name for a Network Connect resource
policy. You can only specify an IP address.
•
If a host name is not fully qualified in the hosts file, such as “juniper” instead of
“intranet.juniper.net”, and you are accessing a host name using the short name, then
the engine performs the resource matching against the short name. If, however, the
short name is not in the hosts file and the host name resolution is done by DNS (by
adding the domains listed in the Networks configuration page), then the fully qualified
domain name (FQDN) is used for resource matching. In other words, for web resource
policies a DNS lookup of the short name is performed. The result of the DNS lookup is
a FQDN; the engine matches the FQDN with the ones entered in the UI.
Specifying Server Resources
When specifying server resources for Telnet/SSH, Terminal Services, or Network Connect
resource policies, note the following guidelines.
The canonical format is [protocol://] host [:ports]
The components are:
•
Protocol (optional)—Possible case-insensitive values:
•
tcp
•
udp
•
icmp
If the protocol is missing, then all protocols are assumed. If a protocol is specified, then
the delimiter “://” is required. No special characters are allowed.
NOTE: Available only to Network Connect policies. For other access feature
resource policies, such as Secure Application Manager and Telnet/SSH, it
is invalid to specify this component.
•
Host (required)—Possible values:
•
IP address/Netmask—The IP address needs to be in the format: a.b.c.d
The netmask may be in one of two formats:
•
Prefix: High order bits
•
IP: a.b.c.d
For example: 10.11.149.2/24 or 10.11.149.2/255.255.255.0
No special characters are allowed.
•
DNS Hostname—For example: www.juniper.com
Special characters allowed include:
130
Copyright © 2011, Juniper Networks, Inc.
Chapter 7: Resource Policies
Table 7: DNS Hostname Special Characters
*
Matches ALL characters
%
Matches any character except dot (.)
?
Matches exactly one character
NOTE: You cannot specify a host name for a Network Connect resource
policy. You can only specify an IP address.
•
Ports (optional)—Possible values:
Table 8: Port Possible Values
*
Matches ALL ports; no other special characters are allowed
port[,port]*
A comma-delimited list of single ports. Valid port numbers are [1- 65535]. Do not enter a space
between port numbers. You can specify up to 15 ports.
[port1]-[port2]
A range of ports, from port1 to port2, inclusive.
NOTE: You may mix port lists and port ranges, such as:
80,443,8080-8090, except for in Network Connect where mixing of port
lists and port ranges is not supported.
If the port is missing, then the default port 80 is assigned for http, 443 for https. For
Network Connect, if the port is missing then the default port http is *. If a port is
specified, then the delimiter “:” is required. For example:
<username>.danastreet.net:5901-5910
tcp://10.10.149.149:22,23
tcp://10.11.0.10:80
udp://10.11.0.10:*
Resource Policy Evaluation
When an SA Series SSL VPN Appliance receives a user request, it evaluates the resource
policies corresponding to the type of request. When it processes the policy that
corresponds to the requested resource, it applies the specified action to the request. This
action is defined on the policy’s General tab or Detailed Rules tab. For example, if a user
requests a Web page, the SA Series SSL VPN Appliance knows to use the Web resource
policies. In the case of Web requests, the SA Series SSL VPN Appliance always starts
with the Web Rewriting policies (Selective Rewriting and Pass through Proxy) to determine
whether or not to handle the request. If none of these policies applies (or none is defined),
the SA Series SSL VPN Appliance then evaluates the Web Access policies until it finds
one that pertains to the requested resource.
Copyright © 2011, Juniper Networks, Inc.
131
Secure Access Administration Guide
The SA Series SSL VPN Appliance evaluates a set of resource policies for an access
feature from the top down, meaning that it starts with the policy numbered one and then
continues down the policy list until it finds a matching policy. If you defined detailed rules
for the matching policy, the SA Series SSL VPN Appliance evaluates the rules from the
top down, starting with the rule numbered one and stopping when it finds a matching
resource in the rule’s Resource list. The following diagram illustrates the general steps
of policy evaluation:
Figure 9: Resource Policy Evaluation Steps
Details regarding each evaluation step:
1.
The SA Series SSL VPN Appliance receives a user request and evaluates the user’s
session role to determine if the corresponding access feature is enabled. A user’s
“session role” is based on either the role or roles to which the user is assigned during
the authentication process. The access features enabled for a user are determined
by an authentication realm’s role mapping configuration.
2. The SA Series SSL VPN Appliance determines which policies match the request. The
SA Series SSL VPN Appliance evaluates the resource policies related to the user
request, sequentially processing each policy until finding the one whose resource list
and designated roles match the request. (If you configure the SA Series SSL VPN
Appliance using resource profiles, the SA Series SSL VPN Appliance evaluates the
advanced policies that you configure as part of the resource profile.)
The Web and file access features have more than one type of policy, so the SA Series
SSL VPN Appliance first determines the type of request (such as to a Web page, Java
applet, or UNIX file) and then evaluates the policies related to the request. In the case
of the Web access feature, the Rewriting policies are evaluated first for every Web
request. The remaining five access features—Secure Application Manager, Secure
Terminal Access, and Secure Email Client—have only one resource policy.
132
Copyright © 2011, Juniper Networks, Inc.
Chapter 7: Resource Policies
3. The SA Series SSL VPN Appliance evaluates and executes the rules specified in the
matching policies. You can configure policy rules to do two things:
•
Specify resources to which an action applies at a more granular level. For example,
if you specify a Web server in the main policy settings for a Web Access resource
policy, you can define a detailed rule that specifies a particular path on this server
and then change the action for this path.
•
Require the user to meet specific conditions written as boolean expressions or
custom expressions in order to apply the action.
4. The SA Series SSL VPN Appliance stops processing resource policies as soon as the
requested resource is found in a policy’s Resource list or detailed rule.
NOTE: If you use automatic (time-based) dynamic policy evaluation or you
perform a manual policy evaluation, the SA Series SSL VPN Appliance repeats
the resource evaluation process described in this section.
Related
Documentation
•
User Roles Overview on page 89
•
Creating Detailed Rules for Resource Policies on page 133
•
Dynamic Policy Evaluation on page 63
Creating Detailed Rules for Resource Policies
The Web, file, Secure Application Manager, Telnet/SSH, and Network Connect access
features enable you to specify resource policies for individual Web, file, application, and
telnet servers. The Email Client access features have one policy that applies globally.
For this policies, you specify server settings that are used for every role that enables these
access features. For all other access features, you can specify any number of resource
polices, and for each, you can define one or more detailed rules.
A detailed rule is a an extension of a resource policy that may specify:
•
Additional resource information—such as a specific path, directory, file, or file type—for
resources listed on the General tab. Note that you may also specify the same resource
list (as on the General tab) for a detailed rule if the only purpose of the detailed rule
is to apply conditions to a user request.
•
An action different from that specified on the General tab (although the options are
the same).
•
Conditions that must be true in order for the detailed rule to apply.
In many cases, the base resource policy—that is, the information specified on the General
tab of a resource policy—provides sufficient access control for a resource:
If a user belonging to the (defined_roles) tries to access the (defined_resources), DO the
specified (resource_action).
Copyright © 2011, Juniper Networks, Inc.
133
Secure Access Administration Guide
You may want to define one or more detailed rules for a policy when you want perform
an action based on a combination of other information, which can include:
•
A resource’s properties, such as its header, content-type, or file type.
•
A user’s properties, such as the user’s username and roles to which the user maps.
•
A session’s properties, such as the user’s source IP or browser type, whether the user
is running Host Checker or Cache Cleaner, the time of day, and certificate attributes.
Detailed rules add flexibility to resource access control by enabling you to leverage existing
resource and permission information to specify different requirements for different users
to whom the base resource policy applies.
Related
Documentation
•
Writing a Detailed Rule for Resource Policies on page 134
Writing a Detailed Rule for Resource Policies
Detailed rules add flexibility to resource access control by enabling you to leverage existing
resource and permission information to specify different requirements for different users
to whom the base resource policy applies.
To write a detailed rule for a resource policy:
1.
On the New Policy page for a resource policy, enter the required resource and role
information.
2. In the Action section, select Use Detailed Rules and then click Save Changes.
3. On the Detailed Rules tab, click New Rule.
4. On the Detailed Rule page:
•
In the Action section, specify:
•
Disable SSO—The SA Series SSL VPN Appliance disables automatic SSO
authentication for this user role and, instead, prompts the user for sign-in
credentials.
•
BasicBasic—This option specifies that the SA Series SSL VPN Appliance use the
Basic Authentication Intermediation method to control SSO behavior.
Enable Intermediation—Select the credentials to use. If this pull-down menu is
blank, no basic authentication SSO settings are defined in the SSO General tab.
Disable Intermediation—When you select this option, the SA Series SSL VPN
Appliance does not intermediate the challenge/response sequence.
134
Copyright © 2011, Juniper Networks, Inc.
Chapter 7: Resource Policies
NOTE: The SA Series SSL VPN Appliance always intermediates
requests to Web proxies that require basic authentication, even if you
select Disable Intermediation.
Although you are given an option to disable basic authentication
intermediation, we do not recommend this option, as it is a very
insecure authentication method and, in some cases, can transmit user
credentials over the network in clear (unencrypted) text.
•
NTLM—This option specifies that the SA Series SSL VPN Appliance use the
Microsoft NTLM Intermediation method to control SSO behavior.
Select the credentials to use. If this pull-down menu is blank, no NTLM SSO
settings are defined in the SSO General tab.
Select the Fallback to NTLM V1 option to try both NTLM V1 and NTLM V2. If you
do not select this option, the SA Series SSL VPN Appliance falls back only to
NTLM V2. An intermediation page appear if SSO fails.
•
Kerberos—This option specifies that the SA Series SSL VPN Appliance use the
Kerberos Intermediation method to control SSO behavior.
Select the credentials to use. If this pull-down menu is blank, no kerberos SSO
settings are defined in the SSO General tab.
Select the Fallback to NTLM V2 option to fallback only to NTLM V2 if kerberos
fails. If you do not select this option, a Kerberos intermediation page appears if
Kerberos SSO fails.
•
Constrained Delegation—This option specifies that the SA Series SSL VPN
Appliance use the constrained delegation intermediation method to control SSO
behavior.
Select the credentials to use. If this pull-down menu is blank, no constrained
delegation SSO settings are defined in the SSO General tab.
Select the Fallback to Kerberos option fallback to Kerberos if constrained
delegation fails. If you select this option, an intermediation page appears if
constrained delegation fails. If you do not select this option and constrained
delegation fails, an error page appears.
•
In the Resources section, specify any of the following (required):
•
The same or a partial list of the resources specified on the General tab.
•
A specific path or file on the server(s) specified on the General tab, using wildcards
when appropriate. For information about how to use wildcards within a Resources
list, see the documentation for the corresponding resource policy.
•
A file type, preceded by a path if appropriate or just specify */*.file_extension to
indicate files with the specified extension within any path on the server(s) specified
on the General tab.
Copyright © 2011, Juniper Networks, Inc.
135
Secure Access Administration Guide
•
In the Conditions section, specify one or more expressions to evaluate in order to
perform the action (optional):
•
Boolean expressions: Using system variables, write one or more boolean
expressions using the NOT, OR, or AND operators.
•
Custom expressions: Using the custom expression syntax, write one or more
custom expressions.
NOTE: You can use the <USER> substitution variable in ACLs for web
pages, telnet, files, and SAM. You cannot use the variable in Network
Connect ACLs.
When specifying a time condition, the specified time range cannot
cross midnight. The workaround is to break the time range into two
conditions.
•
Click Save Changes.
5. On the Detailed Rules tab, order the rules according to how you want the SA Series
SSL VPN Appliance to evaluate them. Keep in mind that once the SA Series SSL VPN
Appliance matches the resource requested by the user to a resource in a rule’s Resource
list, it performs the specified action and stops processing rules (and other resource
policies).
Related
Documentation
•
Writing the Basic, NTLM and Kerberos Resources on page 418
•
Using System Variables in Realms, Roles, and Resource Policies on page 1020
•
Elements Used in Custom Expressions on page 1006
Customizing Resource Policy UI Views
You can limit which resource policies the SA Series SSL VPN Appliance displays on any
given resource policy page based on user roles. For instance, you can configure the Users
> Resource Policies > Web page of the admin console to only display those resource
policies that are assigned to the “Sales” user role.
To control which resource policies the SA Series SSL VPN Appliance displays:
1.
Navigate to Users > Resource Policies >Policy Type.
2. From the Show all policies that apply to list, select All Roles or an individual role.
3. Click Update. The SA Series SSL VPN Appliance displays resource policies that are
assigned to the selected roles.
136
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 8
Authentication and Directory Servers
•
About Authentication and Directory Servers on page 138
•
Task Summary: Configuring Authentication Servers on page 139
•
About Anonymous Servers on page 140
•
Defining an Anonymous Server Instance on page 141
•
Using an RSA ACE/Server on page 142
•
Defining an ACE/Server Instance on page 143
•
Using Active Directory or NT Domains on page 145
•
Defining an Active Directory or Windows NT Domain Server Instance on page 146
•
Multi-Domain User Authentication on page 147
•
Using the Kerberos Debugging Tool on page 149
•
Active Directory and NT Group Lookup Support on page 150
•
Certificate Server on page 151
•
Configuring a Certificate Server Instance on page 152
•
Using an LDAP Server on page 153
•
Defining an LDAP Server Instance on page 153
•
Configuring LDAP Search Attributes for Meeting Creators on page 156
•
Enabling LDAP Password Management on page 156
•
Using a Local Authentication Server on page 161
•
Defining a Local Authentication Server Instance on page 162
•
Creating User Accounts on a Local Authentication Server on page 164
•
Configuring an NIS Server Instance on page 166
•
Configuring a RADIUS Server Instance on page 166
•
Defining an SA Series RADIUS Server Instance on page 168
•
Enabling RADIUS Accounting on page 171
•
General RADIUS Notes on page 182
•
eTrust SiteMinder Overview on page 183
•
Configuring SiteMinder to Work with the SA Series SSL VPN Appliance on page 187
•
Configuring the SiteMinder Agent on page 188
Copyright © 2011, Juniper Networks, Inc.
137
Secure Access Administration Guide
•
Creating a SiteMinder Authentication Scheme for the SA Series SSL VPN
Appliance on page 189
•
Creating a SiteMinder Domain for the SA Series SSL VPN Appliance on page 191
•
Creating a SiteMinder Realm for the SA Series SSL VPN Appliance on page 191
•
Creating a Rule/Response Pair to Pass Usernames to the SA Series SSL VPN
Appliance on page 192
•
Configuring the SA Series SSL VPN Appliance to Work with SiteMinder on page 193
•
Using SiteMinder User Attributes for Secure Access Role Mapping on page 202
•
Defining a SiteMinder Realm for Automatic Sign-In on page 203
•
Debugging SiteMinder and Secure Access Issues on page 204
•
Configuring a SAML Server Instance on page 205
•
Understanding Assertions on page 207
•
Creating a new SAML Server Instance on page 210
•
Configuring the SAML Server Instance to Use an Artifact Profile on page 210
•
Configuring the SAML Server Instance to Use the POST Profile on page 211
About Authentication and Directory Servers
An authentication server is a database that stores user credentials—username and
password—and typically group information. When a user signs in to the SA appliance,
the user specifies an authentication realm, which is associated with an authentication
server. If the user meets the realm’s authentication policy, the SA forwards the user’s
credentials to the associated authentication server. The authentication server’s job is to
verify that the user exists and is who she claims to be. After verifying the user, the
authentication server sends approval to the SA and, if the realm also uses the server as
a directory/attribute server, the user’s group information or other user attribute
information. The SA then evaluates the realm’s role mapping rules to determine to which
user roles the user may be mapped.
The SA appliance supports the most common authentication servers, including Windows
NT Domain, Active Directory, RADIUS, LDAP, NIS, RSA ACE/Server, and eTrust SiteMinder,
and enables you to create one or more local databases of users who are authenticated
by the SA.
A directory server is a database that stores user and typically group information. You can
configure an authentication realm to use a directory server to retrieve user or group
information for use in role mapping rules and resource policies. Currently, the SA supports
LDAP servers for this purpose, which means you can use an LDAP server for both
authentication and authorization. You simply need to define one server instance, and
then the LDAP server’s instance name appears in both the Authentication and
Directory/Attribute drop-down lists on a realm’s General tab. You can use the same
server for any number of realms.
In addition to LDAP, you can use a RADIUS or SiteMinder server for retrieving user attributes
that can be used in role mapping rules. Unlike an LDAP server instance, however, a RADIUS
or SiteMinder server instance name does not appear in a realm’s Directory/Attribute
138
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
drop-down list. To use a RADIUS or SiteMinder server to retrieve user information, you
simply choose its instance name in the Authentication list and then choose Same as
Above in the Directory/Attribute list. Then, you configure role mapping rules to use
attributes from the RADIUS or SiteMinder server, which the SA provides in an attribute
list on the Role Mapping Rule page after you select Rule based on User attribute.
Authentication servers are an integral part of the SA access management framework,
and therefore available on all SA Series products. Note, however, that the eTrust
Siteminder server is not available on the SA700 Series appliance.
Related
Documentation
•
Task Summary: Configuring Authentication Servers on page 139
Task Summary: Configuring Authentication Servers
To specify an authentication server that a realm may use, you must first configure a server
instance on the Authentication > Auth. Servers page. When you save the server’s settings,
the server name (the name assigned to the instance) appears on the realm’s General
tab in the Authentication drop-down list. If the server is a(n):
•
LDAP or Active Directory server—The instance name also appears in the
Directory/Attribute drop-down list on the realm’s General tab. You may use the same
LDAP or Active Directory server for both authentication and authorization for a realm,
as well as use these servers for authorization for any number of realms that use different
authentication servers.
•
RADIUS server—The instance name also appears in the Accounting dropdown list on
the realm’s General tab. You may use the same RADIUS server for both authentication
and accounting for a realm, as well as use these servers for accounting for any number
of realms that use different authentication servers.
Use the Auth. Servers page to define authentication server instances. Authentication
servers authenticate user credentials and authorization servers provide user information
that the SA Series SSL VPN Appliance uses to determine user privileges within the system.
For example, you can specify a certificate server instance to authenticate users based
on their client-side certificate attributes and then create an LDAP server instance to
authorize the users based on values contained within a CRL (certificate revocation list).
To configure authentication servers:
1.
Set up your authentication/authorization server using instructions from the provider.
2. Create an instance of the server starting at the Authentication > Authentication >
Auth. Servers page in the admin console.
Copyright © 2011, Juniper Networks, Inc.
139
Secure Access Administration Guide
NOTE:
• An authentication server must be able to contact the SA Series SSL
VPN Appliance. If an authentication server such as RSA ACE/Server
does not use IP addresses for the agent hosts, the authentication server
must be able to resolve the SA Series host name, either through a DNS
entry or an entry in the authentication server’s host file.
•
You can only create one eTrust Siteminder server instance per the SA
Series SSL VPN Appliance.
•
If you authenticate your Active Directory server with:
•
•
NTLM protocol—Choose Active Directory/Windows NT Domain.
•
LDAP protocol—Choose LDAP Server.
If you are creating a local authentication server instance to authenticate
user administrators, you must select Local Authentication.
a. Select a server type from the New drop-down list.
b. Click New Server.
c. Depending on which server you selected, specify settings for the individual server
instance.
3. Create an authentication realm using settings in the Users > User Realms or
Administrators > Admin Realms page of the admin console.
4. Local authentication servers only: Add users to the server using settings in the
Authentication > Auth. Servers > Select Local Server > Users page of the admin
console.
5. Password management only: set up password management options.
Related
Documentation
•
About Authentication and Directory Servers on page 138
About Anonymous Servers
The anonymous server feature allows users to access the SA Series SSL VPN Appliance
without providing a username or password. Instead, when a user enters the URL of a
sign-in page that is configured to authenticate against an anonymous server, the SA
Series SSL VPN Appliance bypasses the standard sign-in page, and immediately displays
the welcome page to the user.
You may choose to use anonymous authentication if you think that the resources on the
SA Series SSL VPN Appliance do not require extreme security, or if you think that other
security measures provided through the SA Series SSL VPN Appliance are sufficient. For
example, you may create a user role with limited access to internal resources, and then
authenticate that role with a policy that only requires users to sign in from an IP address
140
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
that resides within your internal network. This method presumes that if a user can access
your internal network, s/he is qualified to view the limited resources provided through
the user role.
Anonymous Server Restrictions
When defining and monitoring an anonymous server instance, note that:
Related
Documentation
•
You can only add one anonymous server configuration.
•
You cannot authenticate administrators using an anonymous server.
•
During configuration, you must choose the anonymous server as both the authentication
server and the directory/attribute server in the Users > User Realms > General tab.
•
When creating role mapping rules through the Users > User Realms > Role Mapping
tab, the SA Series SSL VPN Appliance does not allow you to create mapping rules that
apply to specific users (such as “Joe”), since the anonymous server does not collect
username information. You can only create role mapping rules based on a default
username (*), certificate attributes, or custom expressions.
•
For security reasons, you may want to limit the number of users who sign in through
an anonymous server at any given time. To do this, use the option on the Users > User
Realms > [Realm] > Authentication Policy > Limits tab (where [Realm] is the realm
that is configured to use the anonymous server to authenticate users).
•
You cannot view and delete the sessions of anonymous users through a Users tab (as
you can with other authentication servers), because the SA Series SSL VPN Appliance
cannot display individual session data without collecting usernames.
•
Task Summary: Configuring Authentication Servers on page 139
•
Defining an Anonymous Server Instance on page 141
Defining an Anonymous Server Instance
To define an anonymous server:
1.
In the admin console, select Authentication > Auth. Servers.
2. Do one of the following:
•
To create a new server instance on the SA Series SSL VPN Appliance, select
Anonymous Server from the New list, and then click New Server.
•
To update an existing server instance, click the appropriate link in the
Authentication/Authorization Servers list.
3. Specify a name to identify the server instance.
4. Click Save Changes.
5. Specify which realms should use the server to authorize users.
Copyright © 2011, Juniper Networks, Inc.
141
Secure Access Administration Guide
Related
Documentation
•
About Anonymous Servers on page 140
•
Task Summary: Configuring Authentication Servers on page 139
Using an RSA ACE/Server
When authenticating users with an RSA ACE/Server, users may sign in using two methods:
•
Using a hardware token and the standard SA Series sign-in page—The user browses
to the standard SA Series sign-in page, then enters the username and password
(consisting of the concatenation of the PIN and the RSA SecurID hardware token’s
current value). The SA Series SSL VPN Appliance then forwards the user’s credentials
to ACE/Server.
•
Using a software token and the custom SoftID SA Series sign-in page—The user
browses to the SoftID custom sign-in page. Then, using the SoftID plug-in, the user
enters the username and PIN. The SoftID plug-in generates a pass phrase by
concatenating the user’s PIN and token and passes the pass phrase to the SA Series
SSL VPN Appliance. For information about enabling the SoftID custom sign-in pages,
see the Custom Sign-In Pages Solution Guide.
If the ACE/Server positively authenticates the user, the user gains access to the SA Series
SSL VPN Appliance. Otherwise, the ACE/Server:
•
Denies the user access to the system if the user’s credentials were not recognized.
•
Prompts the user to generate a new PIN (New PIN mode) if the user is signing in to the
SA Series SSL VPN Appliance for the first time. Users see different prompts depending
on the method they use to sign in. If the user signs in using the SoftID plug-in, they see
the RSA prompts for creating a new pin; otherwise the user sees the SA Series SSL
VPN Appliance prompts.
•
Prompts the user to enter the next token (Next Token mode) if the token entered by
the user is out of sync with the token expected by ACE/Server. Next Token mode is
transparent to users signing in using a SoftID token. The RSA SecurID software passes
the token through the SA Series SSL VPN Appliance to ACE/Server without user
interaction.
•
Redirects the user to the standard SA Series sign-in page (SoftID only) if the user tries
to sign-in to the RSA SecurID Authentication page on a computer that does not have
the SecurID software installed.
When a user enters the New PIN or Next Token mode, they have three minutes to enter
the required information before the SA Series SSL VPN Appliance cancels the transaction
and notifies the user to re-enter their credentials.
The SA Series SSL VPN Appliance can handle a maximum of 200 ACE/Server transactions
at any given time. A transaction only lasts as long as is required to authenticate against
the ACE/Server. For example, when a user signs into the SA Series SSL VPN Appliance,
the ACE/Server transaction is initiated when the user submits the request for
authentication and ends once the ACE/Server has finished processing the request. The
142
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
user may then keep their SA Series session open, even though her ACE/Server transaction
is closed.
The SA Series SSL VPN Appliance supports the following ACE/Server features: New PIN
mode, Next Token mode, DES/SDI encryption, AES encryption, slave ACE/Server support,
name locking, and clustering. The SA Series SSL VPN Appliance also supports the New
PIN and Next Token modes of RSA SecurID through the RADIUS protocol.
Due to UNIX limitations of the ACE/Server library, you may define only one ACE/Server
configuration.
The SA Series SSL VPN Appliance does not support customizing the load balancing
algorithm.
Related
Documentation
•
Defining an ACE/Server Instance on page 143
•
Task Summary: Configuring Authentication Servers on page 139
Defining an ACE/Server Instance
To define an ACE/Server:
1.
Generate an ACE/Agent configuration file (sdconf.rec) for the SA Series SSL VPN
Appliance on the ACE server as follows:
a. Start the ACE/Server Configuration Management application and click Agent Host.
b. Click Add Agent Host.
c. For Name, enter a name for the SA Series agent.
d. For Network Address, enter the IP address of the SA Series SSL VPN Appliance.
e. Enter a Site configured on your ACE server.
f.
For Agent Type, select Communication Server.
g. For Encryption Type, select DES.
h. Verify that Sent Node Secret is not selected (when creating a new agent).
The first time that the ACE server successfully authenticates a request sent by the
SecSA Series SSL VPN Applianceice, the ACE server selects Sent Node Secret. If
you later want the ACE server to send a new Node Secret to the SA Series SSL
VPN Appliance on the next authentication request, do the following:
i.
Click the Sent Node Secret check box to uncheck it.
ii. Sign in to the admin console and choose Authentication > Auth. Servers.
Copyright © 2011, Juniper Networks, Inc.
143
Secure Access Administration Guide
iii. Click the name of the ACE server in the Authentication/Authorization Servers
list. If this is the initial configuration of the server, see instructions for creating
the ACE server instance that follow this procedure..
iv. Under Node Verification File, select the appropriate check box and click Delete.
These steps ensure that the SA Series SSL VPN Appliance and ACE server are
in sync. Likewise, if you delete the verification file from the SA Series SSL VPN
Appliance, you should uncheck the Sent Node Secret check box on the ACE
server.
If you use RSA ACE/Server authentication and change the SA Series SSL VPN
Appliance IP address, you must delete the node verification file on the Secure
Access for ACE/Sever authentication to work. Also, deselect the Sent Node
Verification setting on the ACE/Server for the SA Series SSL VPN Appliance.
i.
Click Assign Acting Servers and select your ACE server.
j.
Click Generate Config File. When you add the ACE server to the SA Series SSL
VPN Appliance, you will import this configuration file.
2. In the admin console choose Authentication > Auth. Servers.
3. Do one of the following:
•
To create a new server instance on the SA Series SSL VPN Appliance, select ACE
Server from the New list, and then click New Server.
•
To update an existing server instance, click the appropriate link in the
Authentication/Authorization Servers list.
4. Specify a name to identify the server instance.
5. Specify a default port in the ACE Port field. Note that the SA Series SSL VPN Appliance
only uses this setting if no port is specified in the sdconf.rec file.
6. Import the RSA ACE/Agent configuration file. Make sure to update this file on the SA
Series SSL VPN Appliance anytime you make changes to the source file. Likewise, if
you delete the instance file from the SA Series SSL VPN Appliance, go to the ACE
Server Configuration Management application,
7. Click Save Changes. If you are creating the server instance for the first time, the
Settings and Users tabs appear.
8. Specify which realms should use the server to authenticate and authorize
administrators and users.
You can monitor and delete the sessions of users who are currently signed in through the
server through the System > Status > Active Users page.
Related
Documentation
144
•
Task Summary: Configuring Authentication Servers on page 139
•
Using an RSA ACE/Server on page 142
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Using Active Directory or NT Domains
When authenticating users with an NT Primary Domain Controller (PDC) or Active
Directory, users sign in to the SA Series SSL VPN Appliance using the same username
and password they use to access their Windows desktops. The SA Series SSL VPN
Appliance supports Windows NT authentication and Active Directory using NTLM or
Kerberos authentication.
If you configure a native Active Directory server, you may retrieve group information from
the server for use in a realm’s role mapping rules. In this case, you specify the Active
Directory server as the realm’s authentication server, and then you create a role mapping
rule based on group membership. The SA Series SSL VPN Appliance displays all groups
from the configured domain controller and its trusted domains.
The SA Series SSL VPN Appliance provides separate check boxes for each of the primary
authentication protocols: Kerberos, NTLMv2, and NTLMv1, allowing you to select or ignore
each of these protocols independent of one another. This more granular control of the
authentication process avoids unnecessarily raising the failed login count policy in Active
Directory and lets you fine-tune the protocols based on your system requirements.
NOTE:
Copyright © 2011, Juniper Networks, Inc.
•
The SA Series SSL VPN Appliance honors trust relationships in Active
Directory and Windows NT environments.
•
When sending user credentials to an Active Directory authentication server,
the SA Series SSL VPN Appliance uses whichever authentication
protocol(s) you specify on the New Active Directory/Windows NT page.
The SA Series SSL VPN Appliance defaults to the authentication protocols
in order. In other words, if you have selected the check boxes for Kerberos
and NTLMv2, the SA Series SSL VPN Appliance sends the credentials to
Kerberos. If Kerberos succeeds, the SA Series SSL VPN Appliance does not
send the credentials to NTLMv2. If Kerberos is not supported or fails, the
SA Series SSL VPN Appliance uses NTLMv2 as the next protocol in order.
The configuration sets up a cascading effect if you choose to use it by
setting multiple check boxes.
•
The SA Series SSL VPN Appliance supports Domain Local Groups, Domain
Global Groups, and Universal Groups defined in the Active Directory forest.
•
The SA Series SSL VPN Appliance allows only Active Directory security
groups, not distribution groups. Security groups allow you to use one type
of group for not only assigning rights and permissions, but also as a
distribution list for email.
•
If multiple Active Directory servers are configured on the SA Series SSL
VPN Appliance, each of the servers must be associated with a different
and unique machine account name. The same machine account name
should not be used for all servers.
145
Secure Access Administration Guide
Related
Documentation
•
Defining an Active Directory or Windows NT Domain Server Instance on page 146
•
About Basic, NTLM and Kerberos Resources on page 416
Defining an Active Directory or Windows NT Domain Server Instance
To define an Active Directory or Windows NT Domain server:
1.
In the admin console, choose Authentication > Auth. Servers.
2. Do one of the following:
•
To create a new server instance on the SA Series SSL VPN Appliance, select Active
Directory/ Windows NT from the New list and then click New Server.
•
3. To update an existing server instance, click the appropriate link in the
Authentication/Authorization Servers list.
4. Specify a name to identify the server instance.
5. Specify the name or IP address for the primary domain controller or Active Directory
server.
6. Specify the IP address of your back-up domain controller or Active Directory server.
(optional)
7. Enter the domain name of the Active Directory or Windows NT domain. For example,
if the Active Directory domain name is us.amr.asgqa.net and you want to authenticate
users who belong to the US domain, enter US in the domain field.
8. If you want to specify a computer name, enter it into the Computer Name field. The
computer name field is where you specify the name that the SA Series SSL VPN
Appliance uses to join the specified Active Directory domain as a computer. Otherwise,
leave the default identifier which uniquely identifies your system.
You may note that the computer name is pre-filled with an entry in the format of
vcNNNNHHHHHHHH, where, in an IVS system, the NNNN is the IVS ID (assuming you
have an IVS license) and the HHHHHHHH is a hex representation of the IP address of
the SA Series Appliance. A unique name, either the one provided by default or one of
your own choosing, you can more easily identify your systems in the Active Directory.
In a non-IVS system, the first six characters of the name will be ‘vc0000’ because
there is no IVS ID to display. For example, the name could be something like
‘vc0000a1018dF2’ for a non-IVS system.
In a clustered environment with the same AD authentication server, this name is also
unique among all cluster nodes, and the SA Series Appliance displays all of the
identifiers for all attached cluster nodes.
9. Select the Allow domain to be specified as part of username check box to allow
users to sign in by entering a domain name in the Username field in the format:
domain\username
146
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
10. Select the Allow trusted domains check box to get group information from all trusted
domains within a forest.
11. Select the Domain Controller is a Windows 2008 server check box if the backend
domain controller is a Windows 2008 server. The Windows 2008 server has several
enhancements to the Active Directory Server, which is now called Active Directory
Domain Services.
12. For Admin Username and Admin Password, enter an administrator username and
password for the AD or NT server. Make sure the administrator you specify is a domain
administrator in the same domain as the AD or NT server. Do not include a domain
name with the server administrator username in the Admin Username field.
13. Under Authentication Protocol, specify which protocol the SA Series SSL VPN
Appliance should use during authentication.
14. Under Kerberos Realm Name:
•
Select Use LDAP to get Kerberos realm name if you want the SA Series SSL VPN
Appliance to retrieve the Kerberos realm name from the Active Directory server
using the specified administrator credentials.
•
Enter the Kerberos realm name in the Specify Kerberos realm name field if you know
the realm name.
15. Click Test Configuration to verify the Active Directory server configuration settings,
such as do the specified domain exists, are the specified controllers Active Directory
domain controllers, does the selected authentication protocol work, and so forth.
(optional)
16. Click Save Changes. If you are creating the server instance for the first time, the
Settings and Users tabs appear. After you save changes, the SA Series SSL VPN
Appliance masks the administrator password using five asterisk characters, regardless
of the password length.
You can monitor and delete the sessions of users who are currently signed in through the
server through the System > Status > Active Users page.
The admin console provides last access statistics for each user account on various Users
tabs throughout the console, under a set of columns titled Last Sign-in Statistic. The
statistics reported include the last successful sign-in date and time for each user, the
user’s IP address, and the agent or browser type and version.
Related
Documentation
•
About Basic, NTLM and Kerberos Resources on page 416
•
Using Active Directory or NT Domains on page 145
Multi-Domain User Authentication
The SA Series SSL VPN Appliance allows for multi-domain Active Directory and Windows
NT authentication. The SA Series SSL VPN Appliance authenticates users in the domain
you configure on the Authentication > Auth. Servers > New Active Directory / Windows
Copyright © 2011, Juniper Networks, Inc.
147
Secure Access Administration Guide
NT page, users in child domains, and users in all domains trusted by the configured
domain.
After you specify the address of a domain controller and a default domain in the SA
Series Active Directory server configuration, users in the default domain authenticate to
the SA Series SSL VPN Appliance using either just their username, or using the default
domain plus username in the format defaultdomain\username.
When you enable trusted domain authentication, users in trusted or child domains
authenticate to the SA Series SSL VPN Appliance using the name of the trusted or child
domain plus the username in the format trusteddomain\username. Note that enabling
trusted domain authentication adds to the server’s response time.
Windows 2000 and Windows 2003 Multi-Domain Authentication
The SA Series SSL VPN Appliance supports Kerberos-based Active Directory
authentication with Windows 2000 and Windows 2003 domain controllers. When a user
logs in to the SA Series SSL VPN Appliance, the SA Series SSL VPN Appliance performs
Kerberos authentication and attempts to fetch the Kerberos realm name for the domain
controller, as well as all child and trusted realms, using LDAP calls.
You can alternately specify the Kerberos realm name when configuring an Active Directory
authentication server, but we do not recommend this method for two reasons:
•
You cannot specify more than one realm name. The SA Series SSL VPN Appliance
cannot then authenticate against child or trusted realms of the realm you specify.
•
If you misspell the realm name, the SA Series SSL VPN Appliance cannot authenticate
users against the proper realm.
Windows NT4 Multi-Domain Authentication
The SA Series SSL VPN Appliance does not support Kerberos-based authentication in
Windows NT4 domain controllers. Instead of Kerberos authentication, the SA Series SSL
VPN Appliance uses NTLM authentication.
NOTE:
•
For user authentication, the SA Series SSL VPN Appliance joins the default
domain controller server using the machine name in the format Secure
Access-IPaddress.
•
If the DNS configuration on the Windows NT4 domain controller changes,
make sure that the SA Series SSL VPN Appliance can still resolve names
(child and trusted domains) using either WINS, DNS, or the Hosts file, that
were able to resolve the names prior to the configuration change.
NT User Normalization
To support multi-domain authentication, the SA Series SSL VPN Appliance uses
“normalized” NT credentials when contacting an Active Directory or NT4 domain controller
148
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
for authentication. Normalized NT credentials include both the domain name and the
username: domain\username. Regardless of how the user signs in to the SA Series SSL
VPN Appliance, either using just a username or using the domain\username format, the
SA Series SSL VPN Appliance always treats the username in the domain\username
format.
When a user attempts to authenticate using only their username, the SA Series SSL VPN
Appliance always normalizes their NT credentials as defaultdomain\username.
Authentication succeeds only if the user is a member of the default domain.
For a user who signs to the SA Series SSL VPN Appliance using the domain\username
format, the SA Series SSL VPN Appliance always attempts to authenticate the user as
members of the domain the user specifies. Authentication succeeds only if the
user-specified domain is a trusted or child domain of the default domain. If the user
specifies an invalid or untrusted domain, authentication fails.
Two variables, <NTUser> and <NTDomain>, allow you to individually refer to domain
and NT username values. The SA Series SSL VPN Appliance populates these two variables
with the domain and NT username information.
When using pre-existing role mapping rules or writing a new role mapping rule for Active
Directory authentication where USER = someusername, the SA Series SSL VPN Appliance
treats this rule semantically as NTUser = someusername AND NTDomain = defaultdomain.
This allows the SA Series SSL VPN Appliance to work seamlessly with preexisting role
mapping rules.
Related
Documentation
•
Using Active Directory or NT Domains on page 145
•
Defining an Active Directory or Windows NT Domain Server Instance on page 146
Using the Kerberos Debugging Tool
Use the Maintenance > Troubleshooting > Tools Kerberos window in the admin console
to inspect the Kerberos ticket cache, probe the Kerberos infrastructure, and so forth. For
example, Juniper Networks Technical Support may ask you to use this window to help
debug Kerberos-related problems. You can also perform a quick check on Kerberos
before setting up the Kerberos realms, credentials and policies.
The Kerberos window provides you with the following options:
•
Clear All Tickets—Removes all tickets associated with the specified SA Series username
and realm. This action ensures that an active ticket does not remain on a computer
when other users might have access to it.You must specify an account. You can not
clear all tickets for all users.
•
Probe Kerberos DNS Setup—Checks the DNS infrastructure for validity of the Kerberos
realms and defined credentials. You must supply the Kerberos realm and site.
•
Verify Credential—Verifies the Kerberos ticket is valid. For example, if you use Kerberos
to verify the username and password provided by the user, this option verifies the
Copyright © 2011, Juniper Networks, Inc.
149
Secure Access Administration Guide
credentials it obtains to make sure they belong to a trusted KDB site. The Server Realm
and Server KDC fields are optional.
Related
Documentation
•
Verify Constrained Delegation Credential—Verifies the Constrained Delegation ticket
is valid. The Server Realm and Server KDC fields are reserved for future use. Any data
entered in these fields are ignored.
•
About Basic, NTLM and Kerberos Resources on page 416
Active Directory and NT Group Lookup Support
The SA Series SSL VPN Appliance supports user group lookup in Domain Local, Domain
Global, and Universal groups in the Active Directory forest, and Domain Local, and Domain
Global groups for NT4 servers.
For the NT/AD group lookup to work, the SA Series SSL VPN Appliance first tries to join
the domain using the default computer name. For this operation to succeed, you must
specify valid domain administrator credentials in the Active Directory server configuration
on the SA Series SSL VPN Appliance.
Active Directory Lookup Requirements
The SA Series SSL VPN Appliance supports user group lookup in Domain Local, Domain
Global, and Universal groups in the default domain, child domains, and all trusted domains.
The SA Series SSL VPN Appliance obtains group membership using one of three methods
that have different capabilities:
•
Group information in User’s Security Context—Returns information about a user’s
Domain Global groups.
•
Group information obtained using LDAP search calls—Returns information about the
user’s Domain Global groups, and information about the user’s Universal groups if the
SA Series SSL VPN Appliance queries the Global Catalog Server.
•
Group information using native RPC calls—Returns information about the user’s
Domain Local Group.
With respect to role mapping rules, the SA Series SSL VPN Appliance attempts group
lookup in the following order:
150
•
The SA Series SSL VPN Appliance checks for all Domain Global groups using the user’s
security context.
•
If the SA Series SSL VPN Appliance has not found that the user is a member of some
of the groups referenced in the role mapping rules, the SA Series SSL VPN Appliance
performs an LDAP query to determine the user’s group membership.
•
If the SA Series SSL VPN Appliance has not found that the user is a member of some
of the groups referenced in the role mapping rules, the SA Series SSL VPN Appliance
performs an RPC lookup to determine the user’s Domain Local group membership.
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
NT4 Group Lookup Requirements
The SA Series SSL VPN Appliance supports group lookup in the Domain Local and Domain
Global groups created in the default domain, as well as all child, and other trusted
domains. The SA Series SSL VPN Appliance obtains Domain Global group information
from the user’s security context, and Domain Local information using RPC calls. The SA
Series SSL VPN Appliance uses no LDAP-based search calls in the NT4 environment.
Related
Documentation
•
Using Active Directory or NT Domains on page 145
Certificate Server
The certificate server feature allows users to authenticate based on attributes contained
in client-side certificates. You may use certificate server by itself or in conjunction with
another server to authenticate users and map them to roles.
For example, you may choose to authenticate users solely based on their certificate
attributes. If the SA determines that the user’s certificate is valid, it signs the user in based
on the certificate attributes you specify and does not prompt the user to enter a username
or password.
Or, you may choose to authenticate users by passing their client-side certificate attributes
to a second authentication server (such as LDAP). In this scenario, the certificate server
first determines if the user’s certificate is valid. Then, the SA Series Appliance can use
realm-level role-mapping rules to compare the certificate attributes with the user’s LDAP
attributes. If it cannot find the proper match, the SA Series Appliance can deny or limit
the user’s access based on your specifications.
NOTE: When using client-side certificates, we strongly recommend that you
train your end-users to close their Web browsers after signing out of the SA
Series Appliance. If they do not, other users may be able to use their open
browser sessions to access certificate-protected resources on the SA Series
Appliance without re-authenticating. (After loading a client-side certificate,
both Internet Explorer and Netscape cache the certificate’s credentials and
private key. The browsers keep this information cached until the user closes
the browser (or in some cases, until the user reboots the workstation). For
details, see: http://support.microsoft.com/?kbid=290345.) To remind users
to close their browsers, you may modify the sign out message in the
Authentication > Authentication > Signing In Pages tab.
Related
Documentation
•
Configuring User Sign In Policies on page 228
•
Configuring a Certificate Server Instance on page 152
•
Task Summary: Configuring Authentication Servers on page 139
Copyright © 2011, Juniper Networks, Inc.
151
Secure Access Administration Guide
Configuring a Certificate Server Instance
When defining a certificate server on the SA, you must perform the following steps:
1.
Use settings in the System > Configuration > Certificates > CA Certificates tab to
import the CA certificate used to sign the client-side certificates.
2. Create a certificate server instance:
a. Navigate to Authentication > Auth. Servers.
b. Select Certificate Server from the New list, and then click New Server.
c. Specify a name to identify the server instance.
d. In the User Name Template field, specify how the SA should construct a username.
You may use any combination of certificate variables contained in angle brackets
and plain text.
NOTE: If you choose a certificate attribute with more than one value,
the SA uses the first matched value. For example, if you
enter<certDN.OU> and the user has two values for the attribute
(ou=management, ou=sales), the SA uses the “management” value.
To use all values, add the SEP attribute to the variable. For example,
if you enter <certDN.OUT SEP=”:”> the SA uses “management:sales”.
e. Click Save Changes. If you are creating the server instance for the first time, the
Settings and Users tabs appear.
3. If you want to verify certificate attributes against an LDAP server, use settings in the
Authentication > Auth. Servers page to create an LDAP server instance. Note that you
must use the Finding user entries section in the LDAP configuration page to retrieve
the user-specific attributes that you want verify through the certificate.
4. Use settings in the Users > User Realms > RealmName > General tab or Administrators
> Admin Realms > RealmName > General tab to specify which realms should use the
certificate server to authenticate users. (You may also use settings in these tabs to
specify realms that should use an LDAP server to verify certificate attributes.)
5. Use settings in the Authentication > Authentication > Signing In Policies page to
associate the realms configured in the previous step with individual sign-in URLs.
Related
Documentation
152
•
Specifying Client-side Certificate Restrictions on page 733
•
Certificate Server on page 151
•
Using System Variables in Realms, Roles, and Resource Policies on page 1020
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Using an LDAP Server
The SA Series SSL VPN Appliance supports two LDAP-specific authentication options:
•
Unencrypted—in which the SA Series SSL VPN Appliance sends the username and
password to the LDAP Directory Service in clear, simple text.
•
LDAPS—in which the SA Series SSL VPN Appliance encrypts the data in the LDAP
authentication session using Secure Socket Layer (SSL) protocol before sending it to
the LDAP Directory Service.
The SA Series SSL VPN Appliance performs substantial input validation for the following
items:
Related
Documentation
•
LDAP Server—The SA Series SSL VPN Appliance provides a warning if the server is
not reachable.
•
LDAP Port—The SA Series SSL VPN Appliance provides a warning if the LDAP server
is not reachable.
•
Administrator credentials—The SA Series SSL VPN Appliance generates an error if
the verification of admin credentials fails.
•
Base DN for users—The SA Series SSL VPN Appliance generates an error if the
base-level search on the Base DN value fails.
•
Base DN for groups—The SA Series SSL VPN Appliance generates an error if the
baselevel search on the Base DN value fails.
•
Task Summary: Configuring Authentication Servers on page 139
•
Defining an LDAP Server Instance on page 153
•
Enabling LDAP Password Management on page 156
Defining an LDAP Server Instance
To define an LDAP server instance:
1.
In the admin console, select Authentication > Auth. Servers.
2. Do one of the following:
•
To create a new server instance on the SA Series SSL VPN Appliance, select LDAP
Server from the New list and then click New Server.
•
To update an existing server instance, click the appropriate link in the
Authentication/Authorization Servers list.
3. Specify a name to identify the server instance.
4. Specify the name or IP address of the LDAP server that the SA Series SSL VPN
Appliance uses to validate your users.
Copyright © 2011, Juniper Networks, Inc.
153
Secure Access Administration Guide
5. Specify the port on which the LDAP server listens. This port is typically 389 when using
an unencrypted connection and 636 when using SSL.
6. Specify parameters for backup LDAP servers (optional). The SA Series SSL VPN
Appliance uses the specified servers for failover processing; each authentication
request is first routed to the primary LDAP server and then to the specified backup
server(s) if the primary server is unreachable.
NOTE: Backup LDAP servers must be the same version as the primary
LDAP server. Also, we recommend that you specify the IP address of a
backup LDAP server instead of its host name, which may accelerate failover
processing by eliminating the need to resolve the host name to an IP
address.
7. Specify the type of LDAP server that you want to authenticate users against.
8. Specify whether or not the connection between the SA Series SSL VPN Appliance
and LDAP Directory Service should be unencrypted, use SSL (LDAPs), or should use
TLS.
9. Specify how long you want the SA Series SSL VPN Appliance to wait for a connection
to the primary LDAP server first, and then each backup LDAP server in turn.
10. Specify how long you want the SA Series SSL VPN Appliance to wait for search results
from a connected LDAP server.
11. Click Test Connection to verify the connection between the SA Series SSL VPN
Appliance and the specified LDAP server(s). (optional)
12. Select the Authentication required? check box if the SA Series SSL VPN Appliance
needs to authenticate against the LDAP directory to perform a search or to change
passwords using the password management feature. Then, enter an administrator
DN and password.
For example: <CN=Administrator,CN=Users,DC=eng,DC=Juniper,DC=com>
13. Under Finding user entries, specify a:
•
Base DN at which to begin searching for user entries. For example:
<DC=eng,DC=Juniper,DC=com>
14. Filter if you want to fine-tune the search. For example:
<samAccountname=<username> or <cn=<username>>
•
Include <username> in the filter to use the username entered on the sign-in page
for the search.
•
Specify a filter that returns 0 or 1 user DNs per user; the SA Series SSL VPN Appliance
uses the first DN returned if more than 1 DN is returned.
15. The SA Series SSL VPN Appliance supports both static and dynamic groups. (Note
that the SA Series SSL VPN Appliance only supports dynamic groups with LDAP
servers.) To enable group lookup, you need to specify how the SA Series SSL VPN
154
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Appliance searches the LDAP server for a group. Under Determining group membership,
specify a:
•
Base DN at which to begin searching for user groups.
•
Filter if you want to fine-tune the search for a user group.
•
Member Attribute to identify all the members of a static group. For example:
<member >
<uniquemember (iPlanet-specific)>
•
Reverse group search to start the search from the member instead of the group.
This option is available only for Active Directory server types.
•
Query Attribute to specify an LDAP query that returns the members of a dynamic
group. For example:
<memberURL>
•
Nested Group Level to specify how many levels within a group to search for the
user. Note that the higher the number, the longer the query time, so we recommend
that you specify to perform the search no more than 2 levels deep.
•
Nested Group Search to search by:
•
Nested groups in the LDAP Server Catalog. This option is faster because it can
search within the implicit boundaries of the nested group.
•
Search all nested groups. With this option, the SA Series SSL VPN Appliance
searches the Server Catalog first. If the SA Series SSL VPN Appliance finds no
match in the catalog, then it queries LDAP to determine if a group member is a
sub-group.
NOTE: Because the SA Series SSL VPN Appliance looks in the Server
Catalog to determine if a member of a parent group is a user object or
group object, you must add both the parent and all child (nested) groups
to the Server Catalog.
16. Under Bind Options, select:
•
Simple bind to send a user’s credentials in the clear (no encryption) to the LDAP
Directory Service.
•
StartTLS bind to encrypt a user’s credentials using the Transport Layer Security
(TLS) protocol before the SA Series SSL VPN Appliance sends the data to the LDAP
Directory Service.
17. Click Save Changes. If you are creating the server instance for the first time, the
Settings and Users tabs appear.
18. Specify which realms should use the server to authenticate and authorize
administrators and users.
Copyright © 2011, Juniper Networks, Inc.
155
Secure Access Administration Guide
NOTE: The SA Series SSL VPN Appliance supports referral chasing if enabled
on your LDAP server.
Related
Documentation
•
Using the LDAP Server Catalog on page 219
•
Using an LDAP Server on page 153
•
Task Summary: Configuring Authentication Servers on page 139
Configuring LDAP Search Attributes for Meeting Creators
Use options in the Meetings tab to specify individual LDAP attributes that a meeting
creator may use to search for SA Series users when scheduling a meeting.
To configure Secure Meeting search attributes:
1.
In the admin console, choose Authentication > Auth. Servers.
2. Choose the Meetings tab.
3. In the User Name field, enter the username attribute for this server. For example, enter
SamAccountName for an Active Directory server or uid for an iPlanet server.
4. In the Email Address field, enter the email attribute for this server.
5. In the Display Name, Attributes field, enter any additional LDAP attributes whose
contents you want to allow meeting creators to view (optional). (For example, to help
the meeting creator easily distinguish between multiple invitees with the same name,
you may want to expose an attribute that identifies the departments of individual
users.) Enter the additional attributes one per line using the format:
DisplayName,AttributeName. You may enter up to 10 attributes.
6. Click Save Changes.
Related
Documentation
•
Secure Meeting Overview on page 593
Enabling LDAP Password Management
The SA Series password management feature enables users who authenticate through
an LDAP server to manage their passwords through the SA Series SSL VPN Appliance
using the policies defined on the LDAP server. For example, if a user tries to sign in to the
SA Series SSL VPN Appliance with an LDAP password that is about to expire, the SA
Series SSL VPN Appliance catches the expired password notification, presents it to the
user through the SA Series interface, and then passes the user’s response back to the
LDAP server without requiring the user to sign in to the LDAP server separately.
Users, administrators, and help desk administrators who work in environments where
passwords have set expiration times may find the password management feature very
helpful. When users are not properly informed that their passwords are about to expire,
156
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
they can change them themselves through the SA Series SSL VPN Appliance rather than
calling the Help Desk.
The password management feature enables users to change their passwords when
prompted or at will. For example, during the sign-in process, the SA Series Appliance
may inform the user that his password is expired or about to expire. If expired, the SA
Series Appliance prompts the user to change his password. If the password has not
expired, the SA Series Appliance may allow the user to sign in to the SA Series Appliance
using his existing password. After he has signed in, he may change his password from
the Preferences page.
Once enabled, the SA Series Appliance performs a series of queries to determine user
account information, such as when the user’s password was last set, if his account is
expired, and so forth. The SA Series Appliance does this by using its internal LDAP or
Samba client. Many servers, such as Microsoft Active Directory or Sun iPlanet, offer an
Administrative Console to configure account and password options.
The SA Series Appliance enforces password policies by reading password attributes from
the LDAP server. Therefore, for password management to work correctly, password policy
attributes on backend server need to be configured properly.
•
For Active Directory, password policy attributes can be configured in the user entry
container level or any organization level above the user container. If these attributes
are configured at multiple levels, the level closest to the user node takes precedence.
•
The SA Series SSL VPN Appliance does not support customized password policies.
•
The password management feature is not supported on the Active Directory Global
Catalog because password policy attributes are not fully populated on the Active
Directory Global Catalog.
The SA Series SSL VPN Appliance relies on the backend server to pinpoint the cause of
error when a password change operation fails. However, while LDAP servers may report
errors accurately to human operators, they do not always do so when communicating
programmatically to systems like the SA Series SSL VPN Appliance. Therefore, reported
errors may at times be generic or cryptic.
Enabling LDAP Password Management
To enable password management, you must first create an instance of thet LDAP server.
Next, you associated the LDAP server with the applicable realms. Fnally, you select the
enable password management feature at the realm level.
Supported LDAP Directories and Servers
The SA Series SSL VPN Appliance supports password management with the following
LDAP directories:
•
Microsoft Active Directory/Windows NT
•
Sun iPlanet
•
Novell eDirectory
Copyright © 2011, Juniper Networks, Inc.
157
Secure Access Administration Guide
LDAP-based Password Management does not work on generic LDAP servers like
OpenLDAP.
Additionally, the SA Series SSL VPN Appliance supports password management with
the following Windows servers:
•
Microsoft Active Directory
•
Microsoft Active Directory 2003
•
Windows NT 4.0
The following sections list specific issues related to individual server types.
Microsoft Active Directory
158
•
Changes on the Active Directory domain security policy may take 5 minutes or more
to propagate among Active Directory domain controllers. Additionally, this information
does not propagate to the domain controller on which it was originally configured for
the same time period. This is a limitation of Active Directory.
•
When changing passwords in Active Directory using LDAP, the SA Series SSL VPN
Appliance automatically switches to LDAPS, even if LDAPS is not the configured LDAP
method. To support LDAPS on the Active Directory server, you must install a valid SSL
certificate into the server’s personal certificate store. Note that the certificate must be
signed by a trusted CA and the CN in the certificate’s Subject field must contain the
exact host name of the Active Directory server, for example: adsrv1.company.com. To
install the certificate, select the Certificates Snap-In in the Microsoft Management
Console (MMC).
•
The Account Expires option in the User Account Properties tab only changes when the
account expires, not when the password expires. Microsoft Active Directory calculates
the password expiration using the Maximum Password Age and Password Last Set
values retrieved from the User Policy and Domain Security Policy LDAP objects.
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Sun iPlanet
•
When you select the User must change password after reset option on the iPlanet
server, you must also reset the user’s password before this function takes effect. This
is a limitation of iPlanet.
General
•
The SA Series SSL VPN Appliance only displays a warning about password expiry if
the password is scheduled to expire in 14 days or less. The SA Series SSL VPN Appliance
displays the message during each SA Series sign in attempt. The warning message
contains the remaining number of days, hours, and minutes that the user has to change
his password before it expires on the server. The default value is 14 days; however, you
may change it through the Administrators|Users > Admin Realms|User Realms>
Authorization > Password configuration page of the admin console.
Supported LDAP Password Management Functions
•
The following matrix describes the password management functions supported by
Juniper Networks, their corresponding function names in the individual LDAP directories,
and any additional relevant details. These functions must be set through the LDAP
server itself before the SA Series SSL VPN Appliance can pass the corresponding
messages, functions, and restrictions to end-users. When authenticating against a
generic LDAP server, such as IBM Secure Directory, the SA Series SSL VPN Appliance
only supports authentication and allowing users to change their passwords.
Table 9: Supported Password Management Functions
Function
Active Directory
iPlanet
Novell eDirectory
Authenticate user
unicodePwd
userPassword
userPassword
Allow user to change
password if enabled
Server tells us in bind
response (uses
ntSecurityDescriptor)
If passwordChange == ON
If passwordAllowChange
== TRUE
Log out user after
password change
Yes
Yes
Yes
Force password
change at next login
If pwdLastSet == 0
If passwordMustChange ==
ON
If pwdMustChange ==
TRUE
Password expired
notification
userAccountControl==
0x80000
If Bind Response includes
OID
2.16.840.1.113730.3.4.4 ==
0
Check date/time value in
Copyright © 2011, Juniper Networks, Inc.
159
Secure Access Administration Guide
Table 9: Supported Password Management Functions (continued)
Function
Active Directory
iPlanet
Novell eDirectory
Password expiration
notification (in X
days/hours)
if pwdLastSet - now() <
maxPwdAge - 14 days
If Bind Response includes
control OID
2.16.840.1.113730.3.4.5
(contains date/time)
(the SA Series SSL VPN
Appliance displays warning
if less than 14 days)
If now() passwordExpirationTime<
14 days
(the SA Series SSL VPN
Appliance displays warning
if less than 14 days)
( is read from domain
attributes)
(the SA Series SSL VPN
Appliance displays warning
if less than 14 days)
Disallow
authentication if
"account
disabled/locked
userAccountControl== 0x2
(Disabled)
accountExpires
userAccountControl ==
0x10 (Locked)
lockoutTime
Bind ErrorCode: 53
"Account Inactivated"
Bind Error Code: 19 "Exceed
Password Retry Limit"
Bind ErrorCode: 53
"Account Expired"
Bind ErrorCode: 53 "Login
Lockout"
Honor "password
history"
Server tells us in bind
response
Server tells us in bind
response
Server tells us in bind
response
Enforce "minimum
password length"
If set, the SA Series SSL
VPN Appliance displays
message telling user
minPwdLength
If set, the SA Series SSL
VPN Appliance displays
message telling user
passwordMinLength
If set, the SA Series SSL
VPN Appliance displays
message telling user
passwordMinimumLength
Disallow user from
changing password
too soon
If pwdLastSet - now() <
minPwdAge, then we
disallow
If passwordMinAge > 0,
then if now() is earlier than
passwordAllowChangeTime,
then we disallow
Server tells us in bind
response
Honor "password
complexity"
If pwdProperties == 0x1,
then enabled. Complexity
means the new password
does not contain
username, first or last
name, and must contain
characters from 3 of the
following 4 categories:
English uppercase, English
lowercase, Digits, and
Non-alphabetic characters
(ex. !, $, %)
Server tells us in bind
response
Server tells us in bind
response
160
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
AD/NT Password Management Matrix
•
The following matrix describes the Password Management functions supported by
Juniper Networks.
Table 10: AD/NT Password Management Matrix
Function
Active Directory
Active Directory 2003
Windows NT
Authenticate user
Yes
Yes
Yes
Allow user to change password if licensed and
if enabled
Yes
Yes
Yes
Log out user after password change
Yes
Yes
Yes
Force password change at next login
Yes
Yes
Yes
Password expired notification
Yes
Yes
Yes
Account disabled
Yes
Yes
Yes
Account expired
Yes
Yes
Yes
Yes
Yes
Yes
Troubleshooting LDAP Password Management on the SA Series Appliance
When troubleshooting, please provide any pertinent SA Series logs, server logs,
configuration information, and a TCP trace from the SA Series SSL VPN Appliance. If you
are using LDAPS, please switch to the “Unencrypted” LDAP option in the SA Series LDAP
server configuration while taking the LDAP TCP traces.
Related
Documentation
•
Using an LDAP Server on page 153
•
Defining an LDAP Server Instance on page 153
Using a Local Authentication Server
The SA enables you to create one or more local databases of users who are authenticated
by the SA. You might want to create local user records for users who are normally verified
by an external authentication server that you plan to disable or if you want to create a
group of temporary users. Note that all administrator accounts are stored as local records,
but you can choose to authenticate administrators using an external server.
When defining a new local authentication server instance, you need to give the server a
unique name and configure password options and password management. These
password options enable you to control the password length, character composition,
and uniqueness. If desired, you can enable users to change their passwords and to force
users to change passwords after a specified number of days. You can also prompt the
user to change the password within a certain number of days of its expiration date.
Copyright © 2011, Juniper Networks, Inc.
161
Secure Access Administration Guide
Related
Documentation
•
Task Summary: Configuring Authentication Servers on page 139
•
Defining a Local Authentication Server Instance on page 162
Defining a Local Authentication Server Instance
To define a local authentication server instance:
1.
In the admin console, choose Authentication > Auth. Servers.
2. Do one of the following:
•
To create a new server instance on an SA Series SSL VPN Appliance, select Local
Authentication from the New list and then click New Server.
•
To update an existing server instance, click the appropriate link in the
Authentication/Authorization Servers list.
3. Specify a name to identify the new server instance or edit the current name for an
existing server.
4. Specify password options:
a. Under Password options, set the minimum character length for passwords.
b. Set the maximum character length for passwords (optional). The maximum length
cannot be less than the minimum length. There is no maximum limit to the length.
NOTE:
• If the maximum length set on the authentication server is shorter
than the maximum length specified in the SA Series SSL VPN
Appliance, you may receive an error if you enter a password that is
longer than that specified on the authentication server. The admin
console allows you to enter passwords of any length, but your
authentication server maximum determines the validity of the
password length.
•
If you want all passwords to be the same character length, set both
the minimum and maximum lengths to the same value.
c. Enable the Password must have at least_digits check box and specify the number
of digits required in a password (optional). Do not require more digits than the
value of the Maximum length option.
d. Enable the Password must have at least_letters check box and specify the number
of letters required in a password (optional). Do not require more letters than the
value of the Maximum length option. If you enable the previous option, the combined
total of the two options cannot exceed that of the value specified in the Maximum
length option.
162
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
e. Enable the Password must have mix of UPPERCASE and lowercase letters check
box if you want all passwords to contain a mixture of upper- and lowercase letters
(optional).
NOTE: Require passwords to contain at least two letters if you also
require a mix of upper- and lowercase letters.
f.
Enable the Password must be different from username check box if the password
cannot equal the username (optional).
g. Enable the New passwords must be different from previous password check box
if a new password cannot equal the previous password (optional).
h. If you have configured open protocol sets for authentication, select the Password
stored as clear text checkbox. IKEv2 EAP authentication works with local
authentication servers only if this option is selected.
NOTE: Be aware of the security implications of storing passwords as
clear text.
5. Specify password management options:
a. Under Password management, enable the Allow users to change their passwords
check box if you want users to be able to change their passwords (optional).
b. Enable the Force password change after _ days check box and specify the number
of days after which a password expires (optional).
NOTE: The default is 64 days, but you can set this value to any number
you desire.
c. Enable the Prompt users to change their password _ days before current password
expires check box and provide the number of days before password expiration to
prompt the user (optional).
NOTE: The default value is 14 days, but you can set the value to any
number up to the number placed in the previous option.
6. If you are creating an account for a user administrator (user admin), refer to the section
for configuring user admins.
7. Click Save Changes. If you are creating the server instance for the first time, the Users
tab and Admin users tabs appear.
After you set password options and password management options, you also need to
specify which realms should use the server to authenticate and authorize administrators
Copyright © 2011, Juniper Networks, Inc.
163
Secure Access Administration Guide
and users. Use the Enable Password Management option on the Administrators|Users
> Admin Realms|User Realms > Realm > Authentication Policy > Password page to
specify whether or not the realm inherits password management settings from the local
authentication server instance.
Related
Documentation
•
Using a Local Authentication Server on page 161
•
Defining a Local Authentication Server Instance on page 162
•
Specifying Password Access Restrictions on page 70
Creating User Accounts on a Local Authentication Server
When you create a local authentication server instance, you need to define local user
records for that database. A local user record consists of a username, the user’s full name,
and the user’s password. You may want to create local user records for users who are
normally verified by an external authentication server that you plan to disable or if you
want to quickly create a group of temporary users.
To create local user records for a local authentication server:
1.
In the admin console, choose Authentication > Auth. Servers.
2. Click the SA Series local authentication server to which you want to add a user account.
3. Select the Users tab and click New.
4. Enter a Username and the user’s Full Name.
•
Do not include “~~” in a username.
•
If you want to change a username after creating the account, you must create an
entirely new account.
5. Enter the Password and Confirm Password. Make sure that the password you enter
conforms to the password options specified for the associated local authentication
server instance.
6. Optionally, specify Expiration Days or Expiration Hours if this is a temporary account.
You can later add additional time to extend the expiration date.
7. Select One-time use (disable account after the next successful sign-in) if you want
to limit the user to one login. After one successful login, the user’s login state is set to
Disabled and the user receives an error message when attempting subsequent sign
ins. However, you can manually reset this option in the admin console to allow the
same user to login again. If you leave this option unchecked, it means that you are
creating a permanent user.
8. Select Enabled if not already selected. This option is used by the administrator to
selectively enable or disable any user (one time or permanent). Selected by default.
If the One-time use option is checked, this option changes to Disabled after the user
logs in successfully. If a permanent or one-time user is logged in and you disable this
option, the user is immediately logged out of the system and receives an error message.
164
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
9. Select Require user to change password at next sign in if you want to force the user
to change their password at the next login.
NOTE: If you force the user to change passwords, you must also enable
the Allow users to change their passwords option. Use options on the
Administrators|Users > Admin Realms|User Realms > [Realm] >
Authentication Policy > Password page to specify which realms should
inherit the server's password management capabilities.
10. Click Save Changes. The user record is added to the SA Series database.
NOTE: The admin console provides last access statistics for each user
account on various Users tabs throughout the console, under a set of
columns titled Last Signin Statistic. The statistics reported include the
last successful sign-in date and time for each user, the user’s IP address,
and the agent or browser type and version.
Managing User Accounts
To manage a local user account:
1.
In the admin console, choose Authentication > Auth. Servers.
2. Click the appropriate server link in the Authentication/Authorization Servers list.
3. Select the Users tab.
4. Perform any of the following tasks:
•
Enter a username in the Show users named field and click Update to search for a
specific user.
Alternatively, you can use an asterisk (*) as a wildcard, where * represents any
number of zero or more characters. For example, if you want to search for all
usernames that contain the letters jo, enter *jo* in the Show users named field. The
search is case-sensitive. To display the entire list of accounts again, either enter *
or delete the field’s contents and click Update.
Related
Documentation
•
Enter a number in the Show N users field and click Update to control the number
of users displayed on the page.
•
Click the check box next to individual users and click Delete to terminate their SA
Series sessions.
•
Using a Local Authentication Server on page 161
•
Defining a Local Authentication Server Instance on page 162
Copyright © 2011, Juniper Networks, Inc.
165
Secure Access Administration Guide
Configuring an NIS Server Instance
When authenticating users with a UNIX/NIS server, the SA Series SSL VPN Appliance
verifies that the username and password entered through the sign-in page correspond
to a valid user ID and password pair in the NIS server. Note that the username submitted
to the SA Series SSL VPN Appliance cannot contain two consecutive tilde symbols (~~).
NOTE: You can only use NIS authentication with the SA Series SSL VPN
Appliance if your passwords are stored on the NIS server using Crypt or MD5
formats. Also note that you can only add one NIS server configuration to the
SA Series SSL VPN Appliance, but you can use that configuration to
authenticate any number of realms.
To define an NIS server instance:
1.
In the admin console, choose Authentication > Auth. Servers.
2. Do one of the following:
•
To create a new server instance on the SA Series SSL VPN Appliance, select NIS
Server from the New list, and then click New Server.
•
To update an existing server instance, click the appropriate link in the
Authentication/Authorization Servers list.
3. Specify a name to identify the server instance.
4. Specify the name or IP address of the NIS server.
5. Specify the domain name for the NIS server.
6. Click Save Changes. If you are creating the server instance for the first time, the
Settings and Users tabs appear.
7. Specify which realms should use the server to authenticate and authorize
administrators and users.
Related
Documentation
•
Task Summary: Configuring Authentication Servers on page 139
•
Defining Authentication Access Policies on page 215
Configuring a RADIUS Server Instance
A Remote Authentication Dial-In User Service (RADIUS) server is a type of server that
allows you to centralize authentication and accounting for users. When using an external
RADIUS server to authenticate SA users, you need to configure it to recognize the SA as
a client and specify a shared secret for the RADIUS server to use to authenticate the
client request.
166
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
The SA also supports RADIUS proxy. You can configure your external RADIUS server as
an inner or outer proxy target. When you specify RADIUS proxy, some fields in the RADIUS
server configuration page are not applicable.
The SA supports the standard RADIUS authentication schemes, including:
•
Access-Request
•
Access-Accept
•
Access-Reject
•
Access-Challenge
The SA also supports the RSA ACE/Server using the RADIUS protocol and a SecurID
token (available from Security Dynamics). If you use SecurID to authenticate users, users
must supply their user ID and the concatenation of a PIN and the token value.
When defining a RADIUS server, the SA gives administrators the ability to use either
hard-coded (default) challenge expressions that support Defender 4.0 and some RADIUS
server implementations (such as Steel-Belted RADIUS and RSA RADIUS) or to enter
custom challenge expressions that allow the SA to work with many different RADIUS
implementations and new versions of the RADIUS server, such as Defender 5.0. The SA
looks for the response in the Access-Challenge packet from the server and issues an
appropriate Next Token, New Pin, or Generic Passcode challenge to the user.
User Experience for RADIUS Users
The user experience varies depending on whether you are using a RADIUS server like
Steel-Belted RADIUS, PassGo Defender RADIUS server or CASQUE authentication.
If you are using a PassGo Defender RADIUS Server, the user sign-in process is:
•
The user signs in to the SA with a username and password. The SA forwards these
credentials to Defender.
•
Defender sends a unique challenge string to the SA and the SA displays this challenge
string to the user.
•
The user enters the challenge string in a Defender token and the token generates a
response string.
•
The user enters the response string on the SA and clicks Sign In.
Using CASQUE Authentication
CASQUE authentication uses a token-based challenge/response authentication
mechanism employing a CASQUE player installed on the client system. Once configured
with CASQUE authentication, the RADIUS server issues a challenge with a response
matching the custom challenge expression (:([0-9a-zA-Z/+=]+):). The SA then generates
an intermediate page that automatically launches the CASQUE player installed on the
user’s system.
Copyright © 2011, Juniper Networks, Inc.
167
Secure Access Administration Guide
NOTE: If the CASQUE player does not launch automatically, click the Launch
CASQUE Player link.
Users must then use their CASQUE Optical Responder tokens to generate the
corresponding passcode, enter the passcode in the Response field, and click Sign In.
Related
Documentation
•
Task Summary: Configuring Authentication Servers on page 139
•
Enabling RADIUS Accounting on page 171
Defining an SA Series RADIUS Server Instance
To configure a connection to the RADIUS server on an SA Series SSL VPN Appliance:
1.
In the admin console, choose Authentication > Auth. Servers.
2. Do one of the following:
•
To create a new server instance on an SA Series SSL VPN Appliance, select RADIUS
Server from the New list, and then click New Server.
•
To update an existing server instance, click the appropriate link in the
Authentication/Authorization Servers list.
3. At the top of the Radius Server page, specify a name to identify the server instance.
4. In the NAS-Identifier field, enter the name that identifies the SA Series Network Access
Server (NAS) client that communicates with the RADIUS server. If you leave this field
empty, the SA Series SSL VPN Appliance uses the value specified in the Hostname
field of the System > Network > Overview page of the admin console. If no value is
specified in Hostname field, the SA Series SSL VPN Appliance uses the value “Juniper
Secure Access.”
5. Specify the name or IP address in the RADIUS server text box.
6. Enter the authentication port value for the RADIUS server. Typically this port is 1812,
but some legacy servers might use 1645.
7. Enter a string for the shared secret. You also need to enter this string when configuring
the RADIUS server to recognize the SA Series SSL VPN Appliance as a client.
8. Enter the accounting port value for the RADIUS server. Typically this port is 1813, but
some legacy servers might use 1646.
9. Enter the NAS IP Address. This allows you to control the NAS IP address value passed
to RADIUS requests. If you leave this field empty, then the SA Series SSL VPN
Appliance’s internal IP address will be passed to RADIUS requests. If you configure
the NAS IP address, then the value will be passed, regardless of which cluster node
sends the requests.
10. Enter the interval of time for the SA Series SSL VPN Appliance to wait for a response
from the RADIUS server before timing out the connection.
168
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
11. Enter the number of times for the SA Series SSL VPN Appliance to try to make a
connection after the first attempt fails.
12. Select the Users authenticate using tokens or one-time passwords option if you do
not want to submit the password entered by the user to other SSO-enabled
applications. You should generally select this option if the users submit one-time use
passwords to the SA Series SSL VPN Appliance.
13. In the Backup Server section, enter a secondary RADIUS server for the SA Series SSL
VPN Appliance to use if the primary server—the one defined in this instance—is
unreachable. For the secondary server, enter the server:
a. Name or IP address
b. Authentication port
c. Shared secret
d. Accounting port
14. If you want to track SA Series user activity using this instance of the RADIUS server,
enter the following information in the Radius Accounting section:
a. In the User-Name field, specify the user information that the SA Series SSL VPN
Appliance should send to the RADIUS accounting server. Applicable variables
include those that are set at the time after the user signs in and maps to a role.
The default variables for this field are:
•
<username> logs the user’s SA Series username to the accounting server.
•
<REALM> logs the user’s SA Series realm to the accounting server.
•
<ROLE> logs the user’s SA Series role to the accounting server. If the user is
assigned to more than one role, the SA Series SSL VPN Appliance
comma-separates them.
b. Add an Interim Update Level (in minutes). The interim update level enables you
to accomplish more precise billing for long-lived session clients and in case of a
network failure.
15. Select the Use NC assigned IP Address for FRAMED-IP-ADDRESS attribute value
in Radius Accounting checkbox to use the IP address returned from the SA Series
SSL VPN Appliance for the Framed-IP-Address attribute.
Two IP addresses are recorded: one prior to authenticating with the SA Series SSL
VPN Appliance, and one returned by Network Connect after authentication. Select
this option to use the Network Connect IP address for the Framed-IP-Address attribute
instead of the pre-authenticated (original) IP address.
16. (optional) Click New Radius Rule to add a custom challenge rule that determines the
action to take for an incoming packet.
When a user enters his or her username and password, the initial authorization request
is sent to the server. The server may respond with a Challenge or Reject packet. In the
Add Custom Radius Challenge Rule window, you select the packet type (Challenge
Copyright © 2011, Juniper Networks, Inc.
169
Secure Access Administration Guide
or Reject) and then specify what action to take. For example, you can show a login
page with a specific error message to the user, or automatically send an
ACCESS-REQUEST packet back to the server.
To create a custom challenge rule:
a. Select the incoming packet type:
•
Access Challenge—sent by the RADIUS server requesting more information in
order to allow access
•
Access Reject—sent by the RADIUS server rejecting access
b. Specify an expression to evaluate, based on the Radius attribute, and click Add. If
you specify more than one expression, the expressions are “ANDed” together. To
remove an expression, click the delete icon next to the expression.
c. Choose the action to take by selecting one of the following radio buttons:
•
show NEW PIN page—user must enter a new PIN for his/her token
•
show NEXT TOKEN page—user must enter the next tokencode
•
show GENERIC LOGIN page—display an additional page to the user in response
to an Access Challenge sent by the server. Sometimes a Radius server returns a
Challenge packet and requires the user to enter additional information to continue
the login process. For example, a server receives the initial username and
password and sends an SMS message to the user’s mobile phone with a one-time
password (OTP). The user enters the OTP in the generic login page.
•
show user login page with error—display the standard login page with an
embedded error message. This option lets you bypass the standard message
string sent by the SA Series Appliance and display a custom error message to
the user. Enter your custom message in the Error Message text box. There is no
maximum character limit for this message.
•
send ACCESS REQUEST with additional attributes—send an ACCESS-REQUEST
packet with the specified attribute/value pair(s). Select an attribute, enter its
value and click Add. To delete an attribute, click the delete icon next to the
attribute/value pair.
You must set User-Password to <PASSWORD> otherwise an “Invalid username
or password” message appears.
d. Click Save Changes to save your edits, then click Close to close this window.
Your custom rules appear in the table under the Custom Radius Authentication
Rule section. To delete a rule, select the checkbox next to the rule and click Delete.
17. Click Save Changes. If you are creating the server instance for the first time, the
Settings and Users tabs appear.
18. Specify which realms should use the server to authenticate, authorize, or account for
administrators and users.
170
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Configuring the RADIUS Server to Recognize the SA Series SSL VPN Appliance
You need to configure the RADIUS server to recognize the SA Series SSL VPN Appliance
by specifying:
Related
Documentation
•
The host name given to the SA Series SSL VPN Appliance.
•
The network IP address of the SA Series SSL VPN Appliance.
•
The SA Series client type—if applicable. If this option is available, select Single
Transaction Server or its equivalent.
•
The type of encryption to use for authenticating client communication. This choice
should correspond to the client type.
•
The shared secret you entered in the admin console for the RADIUS server on the
Authentication > Auth. Servers > Radius Server page.
•
Configuring a RADIUS Server Instance on page 166
•
Enabling RADIUS Accounting on page 171
•
System Variables and Examples on page 1010
Enabling RADIUS Accounting
You can configure the SA Series SSL VPN Appliance to send session start and stop
messages to a RADIUS accounting server. The SA Series SSL VPN Appliance recognizes
two categories of sessions—user-sessions and sub-sessions. A user session may contain
multiple sub-sessions. The SA Series SSL VPN Appliance recognizes the following types
of sub-sessions:
•
JSAM
•
WSAM
•
Network Connect
The SA Series SSL VPN Appliance sends a user-session start message after the user
successfully signs in and the SA Series SSL VPN Appliance maps him to a role. The SA
Series SSL VPN Appliance sends a sub-session start message when the sub-session
becomes active; for example, after launching JSAM. The SA Series SSL VPN Appliance
sends a sub-session stop message when there is an explicit request from the user to
terminate a sub-session, or if the user-session terminates.
Whenever a user session terminates, the SA Series SSL VPN Appliance sends a
user-session stop message to the accounting server. A user session terminates whenever
the user:
•
Manually signs out of the SA Series SSL VPN Appliance
•
Times out of the SA Series SSL VPN Appliance either due to inactivity or because of
exceeding the maximum session length
Copyright © 2011, Juniper Networks, Inc.
171
Secure Access Administration Guide
•
Is denied access due to Host Checker or Cache Cleaner role-level restrictions
•
Is manually forced out of the SA Series SSL VPN Appliance by an administrator or due
to dynamic policy evaluation.
The SA Series SSL VPN Appliance also sends stop messages for all active sub-sessions.
The stop-messages for the sub-sessions precede the stop-messages for the user-session.
NOTE: If users are signed into an SA Series cluster, the RADIUS accounting
messages may show the users signing in to one node and signing out of
another.
The following three tables describe the attributes that are common to start and stop
messages, attributes that are unique to start messages, and attributes that are unique
to stop messages.
Table 11: Attributes Common to both Start and Stop Messages
172
Attribute
Description
User-Name (1)
String that the SA Series administrator specifies during RADIUS
server configuration
NAS-IP-Address (4)
SA Series SSL VPN Appliance’s IP address
NAS-Port (5)
The SA Series SSL VPN Appliance sets this attribute to 0 if the user
signed in using an internal port, or 1 if an external port.
Framed-IP-Address (8)
User’s source IP address
NAS-Identifier (32)
Configured name for the SA Series client under the RADIUS server
configuration
Acct-Status-Type (40)
The SA Series SSL VPN Appliance sets this attribute to 1 for a start
message, or 2 for a stop message in a user-session or a sub-session
Acct-Session-Id (44)
Unique accounting ID that matches start and stop messages
corresponding to a user-session or to a sub-session.
Acct-Multi-Session-Id (50)
Unique accounting ID that you can use to link together multiple
related sessions. Each linked session must have a unique
Acct-Session-Id and the same Acct-Multi-Session-Id.
Acct-Link-Count (51)
The count of links in a multi-link session at the time the SA Series
SSL VPN Appliance generates the accounting record
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 12: Start Attributes
Attribute
Description
Acct-Authentic (45)
The SA Series SSL VPN Appliance sets this attribute to:
•
RADIUS—if the user authenticated to a RADIUS server
•
Local—if the user authenticated to an Local Authentication Server
•
Remote—for anything else
Table 13: Stop Attributes
Attribute
Description
Acct-Session-Time (46)
Duration of the user-session or the sub-session
Acct-Terminate-Cause
(49)
The SA Series SSL VPN Appliance uses one of the following values
to specify the event that caused the termination of a user session
or a sub-session:
Acct-Terminate-Cause
(49)
Acct-Terminate-Cause
(49)
•
User Request (1) – User manually signs out
•
Idle Timeout (4) – User Idle time out
•
Session Timeout (5) – User Max Session Timeout
•
Admin Reset (6) – User Forced Out from Active Users page
The SA Series SSL VPN Appliance uses one of the following values
to specify the event that caused the termination of a user session
or a sub-session:
•
User Request (1) – User manually signs out
•
Idle Timeout (4) – User Idle time out
•
Session Timeout (5) – User Max Session Timeout
•
Admin Reset (6) – User Forced Out from Active Users page
The SA Series SSL VPN Appliance uses one of the following values
to specify the event that caused the termination of a user session
or a sub-session:
•
User Request (1) – User manually signs out
•
Idle Timeout (4) – User Idle time out
•
Session Timeout (5) – User Max Session Timeout
•
Admin Reset (6) – User Forced Out from Active Users page
Acct-Input-Octets
Octet-based count of JSAM/WSAM/NC session level when session
was terminated and of user session level when the session was
terminated and the interim update time arrived. From the SA Series
SSL VPN Appliance to the client.
Acct-Output-Octets
Octet-based count of JSAM/WSAM/NC session level when session
was terminated and of user session level when the session was
terminated and the interim update time arrived. From client to the
SA Series SSL VPN Appliance.
Copyright © 2011, Juniper Networks, Inc.
173
Secure Access Administration Guide
To distinguish between a user-session and the sub-sessions it contains, examine the
Acct-Session-Id and the Acct-Multi-Session-Id. In a user-session, both of these attributes
are the same. In a sub-session, the Acct-Multi-Session-Id is the same as the one for the
parent user-session, and the SA Series SSL VPN Appliance indicates the sub-session by
using one of the following suffixes in the Acct-Session-Id:
•
“JSAM” for JSAM sessions
•
“WSAM” for WSAM sessions
•
“NC” for Network Connect sessions
Supported RADIUS Attributes
The following RADIUS attributes are supported in RADIUS role mapping. For more
information, see the full descriptions (from which these descriptions were derived) at
the FreeRADIUS website located at http://www.freeradius.org/rfc/attributes.html.
Table 14: RADIUS Role Mapping Attributes
174
Attribute
Description
ARAP-Challenge-Response
Sent in an Access-Accept packet with Framed-Protocol
of ARAP, and contains the response to the dial-in
client's challenge.
ARAP-Features
Sent in an Access-Accept packet with FramedProtocol of ARAP. Includes password information that
the NAS must send to the user in an ARAP feature flags
packet.
ARAP-Password
Present in an Access-Request packet containing a
Framed-Protocol of ARAP. Only one of User-Password,
CHAP-Password, or ARAP-Password must be included
in an Access-Request, or one or more EAP-Messages.
ARAP-Security
Identifies the ARAP Security Module to be used in an
Access-Challenge packet.
ARAP-Security-Data
Contains a security module challenge or response, and
is in Access-Challenge and Access-Request packets.
ARAP-Zone-Access
Indicates how to use the ARAP zone list for the user.
Access-Accept
Provides specific configuration information necessary
to begin delivery of service to the user.
Access-Challenge
To send the user a challenge requiring a response, the
RADIUS server must respond to the Access-Request
by transmitting a packet with the Code field set to 11
(Access-Challenge).
Access-Reject
If any value of the received Attributes is not acceptable,
then the RADIUS server must transmit a packet with
the Code field set to 3 (Access-Reject).
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 14: RADIUS Role Mapping Attributes (continued)
Attribute
Description
Access-Request
Conveys information specifying user access to a
specific NAS, and any special services requested for
that user.
Accounting-Request
Conveys information used to provide accounting for a
service provided to a user.
Accounting-Response
Acknowledges that the Accounting-Request has been
received and recorded successfully.
Acct-Authentic
Indicates how the user was authenticated, whether by
RADIUS, the NAS itself, or another remote
authentication protocol.
Acct-Delay-Time
Indicates how many seconds the client has been trying
to send this record.
Acct-Input-Gigawords
Indicates how many times the Acct-Input-Octets
counter has wrapped around 2^32 over the course of
this service being provided.
Acct-Input-Octets
Indicates how many octets have been received from
the port during the current session.
Acct-Input-Packets
Indicates how many packets have been received from
the port during the session provided to a Framed User
Acct-Interim-Interval
Indicates the number of seconds between each interim
update in seconds for this specific session.
Acct-Link-Count
The count of links known to have been in a given
multilink session at the time the accounting record is
generated.
Acct-Multi-Session-Id
A unique Accounting ID to make it easy to link together
multiple related sessions in a log file.
Acct-Output-Gigawords
Indicates how many times the Acct-Output-Octets
counter has wrapped around 2^32 during the current
session.
Acct-Output-Octets
Indicates how many octets have been sent to the port
during this session.
Acct-Output-Packets
Indicates how many packets have been sent to the
port during this session to a Framed User.
Acct-Session-Id
A unique Accounting ID to make it easy to match start
and stop records in a log file.
Copyright © 2011, Juniper Networks, Inc.
175
Secure Access Administration Guide
Table 14: RADIUS Role Mapping Attributes (continued)
176
Attribute
Description
Acct-Session-Time
Indicates how many seconds the user has received
service.
Acct-Status-Type
Indicates whether this Accounting-Request marks the
beginning of the user service (Start) or the end (Stop).
Acct-Terminate-Cause
Indicates how the session was terminated.
Acct-Tunnel-Connection
Indicates the identifier assigned to the tunnel session.
Acct-Tunnel-Packets-Lost
Indicates the number of packets lost on a given link.
CHAP-Challenge
Contains the CHAP Challenge sent by the NAS to a
PPP Challenge-Handshake Authentication Protocol
(CHAP) user.
CHAP-Password
The response value provided by a PPP
Challenge-Handshake Authentication Protocol (CHAP)
user in response to the challenge.
Callback-Id
The name of a location to be called, to be interpreted
by the NAS.
Callback-Number
The dialing string to be used for callback.
Called-Station-Id
Allows the NAS to send the phone number that the
user called, using Dialed Number Identification (DNIS)
or similar technology.
Calling-Station-Id
Allows the NAS to send the phone number that the
call came from, using Automatic Number Identification
(ANI) or similar technology.
Class
Sent by the server to the client in an Access-Accept
and then sent unmodified by the client to the
accounting server as part of the Accounting-Request
packet, if accounting is supported.
Configuration-Token
For use in large distributed authentication networks
based on proxy.
Connect-Info
Sent from the NAS to indicate the nature of the user's
connection.
EAP-Message
Encapsulates Extended Access Protocol [3] packets
to allow the NAS to authenticate dial-in users by means
of EAP without having to understand the EAP protocol.
Filter-Id
The name of the filter list for this user.
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 14: RADIUS Role Mapping Attributes (continued)
Attribute
Description
Framed-AppleTalk-Link
The AppleTalk network number used for the serial link
to the user, which is another AppleTalk router.
Framed-AppleTalk-Network
The AppleTalk Network number which the NAS can
probe to allocate an AppleTalk node for the user.
Framed-AppleTalk-Zone
The AppleTalk Default Zone to be used for this user.
Framed-Compression
A compression protocol to be used for the link.
Framed-IP-Address
The address to be configured for the user.
Framed-IP-Netmask
The IP netmask to be configured for the user when the
user is a router to a network.
Framed-IPX-Network
The IPX Network number to be configured for the user.
Framed-MTU
The Maximum Transmission Unit to be configured for
the user, when it is not negotiated by some other
means (such as PPP).
Framed-Pool
The name of an assigned address pool used to assign
an address for the user.
Framed-Protocol
The framing to be used for framed access.
Framed-Route
Routing information to be configured for the user on
the NAS.
Framed-Routing
The routing method for the user, when the user is a
router to a network.
Idle-Timeout
Sets the maximum number of consecutive seconds of
idle connection allowed to the user before termination
of the session or prompt.
Keep-Alives
Use SNMP instead of keep-alives.
Login-IP-Host
Indicates the system with which to connect the user,
when the Login-Service Attribute is included.
Login-LAT-Group
Contains a string identifying the LAT group codes that
this user is authorized to use.
Login-LAT-Node
Indicates the Node with which the user is to be
automatically connected by LAT.
Login-LAT-Port
Indicates the Port with which the user is to be
connected by LAT.
Copyright © 2011, Juniper Networks, Inc.
177
Secure Access Administration Guide
Table 14: RADIUS Role Mapping Attributes (continued)
178
Attribute
Description
Login-LAT-Service
Indicates the system with which the user is to be
connected by LAT.
Login-Service
Indicates the service to use to connect the user to the
login host.
Login-TCP-Port
Indicates the TCP port with which the user is to be
connected, when the Login-Service Attribute is also
present.
MS-ARAP-Challenge
Only present in an Access-Request packet containing
a Framed-Protocol Attribute with the value 3 (ARAP).
MS-ARAP-Password-Change-Reason
Indicates the reason for a server-initiated password
change.
MS-Acct-Auth-Type
Represents the method used to authenticate the
dial-up user.
MS-Acct-EAP-Type
Represents the Extensible Authentication Protocol
(EAP) [15] type used to authenticate the dial-up user.
MS-BAP-Usage
Describes whether the use of BAP is allowed,
disallowed or required on new multilink calls.
MS-CHAP-CPW-1
Allows the user to change password if it has expired.
MS-CHAP-CPW-2
Allows the user to change password if it has expired.
MS-CHAP-Challenge
Contains the challenge sent by a NAS to a Microsoft
Challenge-Handshake Authentication Protocol
(MS-CHAP) user.
MS-CHAP-Domain
Indicates the Windows NT domain in which the user
was authenticated.
MS-CHAP-Error
Contains error data related to the preceding MS-CHAP
exchange.
MS-CHAP-LM-Enc-PW
Contains the new Windows NT password encrypted
with the old LAN Manager password hash.
MS-CHAP-MPPE-Keys
Contains two session keys for use by the Microsoft
Point-to-Point Encryption Protocol (MPPE).
MS-CHAP-NT-Enc-PW
Contains the new Windows NT password encrypted
with the old Windows NT password hash.
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 14: RADIUS Role Mapping Attributes (continued)
Attribute
Description
MS-CHAP-Response
Contains the response value provided by a PPP
Microsoft Challenge-Handshake Authentication
Protocol (MS-CHAP) user in response to the challenge.
MS-CHAP2-CPW
Allows the user to change password if it has expired.
MS-CHAP2-Response
Contains the response value provided by an MSCHAP-V2 peer in response to the challenge.
MS-CHAP2-Success
Contains a 42-octet authenticator response string.
MS-Filter
Used to transmit traffic filters.
MS-Link-Drop-Time-Limit
Indicates the length of time (in seconds) that a link
must be underutilized before it is dropped.
MS-Link-Utilization-Threshold
Represents the percentage of available bandwidth
utilization below which the link must fall before the link
is eligible for termination.
MS-MPPE-Encryption-Policy
Signifies whether the use of encryption is allowed or
required.
MS-MPPE-Encryption-Types
Signifies the types of encryption available for use with
MPPE.
MS-MPPE-Recv-Key
Contains a session key for use by the Microsoft
Point-to-Point Encryption Protocol (MPPE).
MS-MPPE-Send-Key
Contains a session key for use by the Microsoft
Point-to-Point Encryption Protocol (MPPE).
MS-New-ARAP-Password
Transmits the new ARAP password during an ARAP
password change operation.
MS-Old-ARAP-Password
Transmits the old ARAP password during an ARAP
password change operation.
MS-Primary-DNS-Server
Indicates the address of the primary Domain Name
Server (DNS) [16, 17] server to be used by the PPP peer.
MS-Primary-NBNS-Server
Indicates the address of the primary NetBIOS Name
Server (NBNS) [18] server to be used by the PPP peer.
MS-RAS-Vendor
Indicates the manufacturer of the RADIUS client
machine.
MS-RAS-Version
Indicates the version of the RADIUS client software.
Copyright © 2011, Juniper Networks, Inc.
179
Secure Access Administration Guide
Table 14: RADIUS Role Mapping Attributes (continued)
180
Attribute
Description
MS-Secondary-DNS-Server
Indicates the address of the secondary DNS server to
be used by the PPP peer.
MS-Secondary-NBNS-Server
Indicates the address of the secondary DNS server to
be used by the PPP peer.
NAS-IP-Address
Indicates the identifying IP Address of the NAS that is
requesting authentication of the user, and must be
unique to the NAS within the scope of the RADIUS
server.
NAS-Identifier
Contains a string identifying the NAS originating the
Access-Request.
NAS-Port
Indicates the physical port number of the NAS that is
authenticating the user.
NAS-Port-Id
Contains a text string that identifies the port of the NAS
that is authenticating the user.
NAS-Port-Type
Indicates the type of the physical port of the NAS that
is authenticating the user.
Password-Retry
Indicates how many authentication attempts a user is
allowed to attempt before being disconnected.
Port-Limit
Sets the maximum number of ports to be provided to
the user by the NAS.
Prompt
Indicates to the NAS whether it should echo the user's
response as it is entered, or not echo it.
Proxy-State
A proxy server can send this attribute to another server
when forwarding an Access-Request. The attribute
must be returned unmodified in the Access-Accept,
Access-Reject or Access-Challenge.
Reply-Message
Text that can be displayed to the user.
Service-Type
The type of service the user has requested, or the type
of service to be provided.
Session-Timeout
Sets the maximum number of seconds of service to be
provided to the user before termination of the session
or prompt.
State
A packet must have only zero or one State Attribute.
Usage of the State Attribute is implementation
dependent.
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 14: RADIUS Role Mapping Attributes (continued)
Attribute
Description
Telephone-number
Using the Calling-Station-Id and Called-Station-Id
RADIUS attributes, authorization and subsequent
tunnel attributes can be based on the phone number
originating the call, or the number being called.
Termination-Action
The action the NAS should take when the specified
service is completed.
Tunnel-Assignment-ID
Indicates to the tunnel initiator the particular tunnel to
which a session is to be assigned.
Tunnel-Client-Auth-ID
Specifies the name used by the tunnel initiator during
the authentication phase of tunnel establishment.
Tunnel-Client-Endpoint
Contains the address of the initiator end of the tunnel.
Tunnel-Link-Reject
Marks the rejection of the establishment of a new link
in an existing tunnel.
Tunnel-Link-Start
Marks the creation of a tunnel link.
Tunnel-Link-Stop
Marks the destruction of a tunnel link.
Tunnel-Medium-Type
The transport medium to use when creating a tunnel
for those protocols (such as L2TP) that can operate
over multiple transports.
Tunnel-Medium-Type
The transport medium to use when creating a tunnel
for those protocols (such as L2TP) that can operate
over multiple transports.
Tunnel-Password
A password to be used to authenticate to a remote
server.
Tunnel-Preference
If the RADIUS server returns more than one set of
tunneling attributes to the tunnel initiator, you should
include this attribute in each set to indicate the relative
preference assigned to each tunnel.
Tunnel-Private-Group-ID
The group ID for a particular tunneled session.
Tunnel-Reject
Marks the rejection of the establishment of a tunnel
with another node.
Tunnel-Server-Auth-ID
Specifies the name used by the tunnel terminator
during the authentication phase of tunnel
establishment.
Tunnel-Server-Endpoint
The address of the server end of the tunnel.
Copyright © 2011, Juniper Networks, Inc.
181
Secure Access Administration Guide
Table 14: RADIUS Role Mapping Attributes (continued)
Related
Documentation
•
Attribute
Description
Tunnel-Start
Marks the establishment of a tunnel with another node.
Tunnel-Stop
Marks the destruction of a tunnel to or from another
node.
Tunnel-Type
The tunneling protocol(s) to be used (in the case of a
tunnel initiator) or the tunneling protocol in use (in the
case of a tunnel terminator).
User-Name
The name of the user to be authenticated.
User-Password
The password of the user to be authenticated, or the
user's input following an Access-Challenge.
Configuring a RADIUS Server Instance on page 166
General RADIUS Notes
Please note the following issues.
Understanding Clustering Issues
Accounting messages are sent to the RADIUS server by each cluster node without
consolidation. RADIUS accounting on the Infranet Controller follows these assumptions:
•
If the cluster is active/passive, all users are connected to one node at a time.
•
If the cluster is active/active and does not use a balancer, users are connected to
different nodes but are static.
•
If the cluster is active/active and uses a balancer, the balancer usually enforces a
persistent source IP. In this case, users are always connected to the same node.
The Infranet Controller does not support load balancing for RADIUS.
Understanding the Interim Update Feature
If you want a server to receive interim accounting messages, you can statically configure
an interim value on the client, in which case, the locally-configured value overrides any
value that might be included in the RADIUS Access-Accept message.
The octet count reported in the accounting messages is the cumulative total since the
beginning of the user session.
The interim update byte count is only supported based on a user session, not on SAM or
NC sessions.
The minimum interim update interval is 15 minutes. The data statistics (bytes in and
bytes out) for RADIUS Accounting may not be sent for a J-SAM/W-SAM/NC session if
182
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
the session is less than five minutes long and the applications keep the connections open
all the time.
Related
Documentation
•
Configuring a RADIUS Server Instance on page 166
eTrust SiteMinder Overview
When you configure the SA Series SSL VPN Appliance to authenticate users with an
eTrust SiteMinder policy server, the SA Series SSL VPN Appliance passes the user’s
credentials to SiteMinder during authentication. Once SiteMinder receives the credentials,
it may use standard username and password authentication, ACE SecurID tokens, or
clientside certificates to authenticate the credentials.
The SA Series SSL VPN Appliance also passes a protected resource URL to SiteMinder
during authentication in order to determine which SiteMinder realm it should use to
authenticate the user. When the SA Series SSL VPN Appliance passes the protected
resource URL, SiteMinder authorizes the user’s URL against the realm that is associated
with the resource and allows the user to seamlessly access any resources whose
protection levels are equal to or less than the resource the SA Series SSL VPN Appliance
passed.
The SA Series SSL VPN Appliance enables single sign-on (SSO) from Secure Access to
SiteMinder-protected resources using SMSESSION cookies. A SMSESSION cookie is a
security token that encapsulates SiteMinder session information. Depending on your
configuration, either the SiteMinder Web agent or the SA Series SSL VPN Appliance
creates a SMSESSION cookie and then posts the cookie to the following locations so
the user does not have to re-authenticate if he wants to access additional resources:
•
The IVE: If the user tries to access a SiteMinder resource from within his SA Series
session (for example, from the SA Series SSL VPN Appliance file browsing page), the
SA Series SSL VPN Appliance passes its cached SMSESSION cookie to the Web agent
for authentication.
•
The user’s Web browser: If the user tries to access a SiteMinder resource from outside
of his SA Series session (for example, when using a protected resource on a standard
agent), SiteMinder uses the cached SMSESSION cookie stored in the user’s Web
browser to authenticate/authorize the user.
If you enable the Automatic Sign-In option the SA Series SSL VPN Appliance can use an
SMSESSION cookie generated by another agent to enable single sign-on from a SiteMinder
resource to the SA Series SSL VPN Appliance. When a user accesses the SA Series sign-in
page with an SMSESSION cookie, the SA Series SSL VPN Appliance verifies the
SMSESSION cookie. Upon successful verification, the SA Series SSL VPN Appliance
establishes an SA Series session for the user. You can use the following authentication
mechanisms when you enable automatic sign-in through the SA Series SSL VPN
Appliance:
•
Custom agent: The SA Series SSL VPN Appliance authenticates the user against the
policy server and generates a SMSESSION cookie. When you select this option, you
can enable SSO on other SiteMinder agents that use the same policy server. To enable
Copyright © 2011, Juniper Networks, Inc.
183
Secure Access Administration Guide
SSO on these agents, update each of them to accept third party cookies If you select
this option and the user enters his SA Series session with an SMSESSION cookie, The
SA Series SSL VPN Appliance attempts automatic sign-in when the user enters the
SA Series session.
184
•
HTML form post: The SA Series SSL VPN Appliance posts credentials to a standard
Web agent that you have already configured. The Web agent then creates SMSESSION
cookies. If you select this option, you cannot use SecurID New Pin and Next Token
modes or client-side certificate authentication. If you select this option and the user
enters his SA Series session with an SMSESSION cookie, the SA Series SSL VPN
Appliance attempts automatic sign-in when the user enters the SA Series session.
•
Delegated authentication: The SA Series SSL VPN Appliance delegates authentication
to a standard agent. If this option is enabled, the SA Series SSL VPN Appliance tries
to determine the FCC URL associated with the protected resource. The SA Series SSL
VPN Appliance then redirects the user to the FCC URL with the SA Series sign-in URL
as the TARGET. Upon successful authentication, the user is redirected back to the SA
Series SSL VPN Appliance with an SMSESSION cookie and the SA Series SSL VPN
Appliance does an automatic sign-in for the user.
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
NOTE:
Copyright © 2011, Juniper Networks, Inc.
•
At the time of this printing, Juniper Networks supports eTrust SiteMinder
server version 6.0 and version 5.5 with standard agent versions 6 and
5QMR5. If you run older agents than the supported agents, you may
experience cookie validation problems, including crossed log entries and
intermittent user timeouts.
•
You can choose which eTrust SiteMinder server version you want to support
when you create a server instance. You can choose version 5.5, which
supports both versions 5.5 and 6.0, or you can choose version 6.0, which
supports only version 6.0. There is no difference in the SiteMinder
authentication server functionality based on which version you select. This
option only controls the version of the Netegrity SDK to use. We recommend
you match the compatibility mode with the version of the Policy Server.
•
When you use SiteMinder to authenticate, the primary and backup policy
servers must run the same SiteMinder server software version. A mixed
deployment (where the primary server runs a different server software
version than the backup) is not supported.
•
SiteMinder does not store the IP address in the SMSESSION cookie, and
therefore cannot pass it to the SA Series SSL VPN Appliance.
•
SiteMinder sends the SMSESSION cookie to the SA Series SSL VPN
Appliance as a persistent cookie. To maximize security, the SA Series SSL
VPN Appliance resets the persistent cookie as a session cookie once
authentication is complete.
•
When you use SiteMinder to authenticate, the SA Series SSL VPN Appliance
disregards any SA Series session and idle timeouts and uses session and
idle timeouts set through the SiteMinder realm instead.
•
When you use SiteMinder to authenticate, users must access the SA Series
SSL VPN Appliance using a fully-qualified domain name. This is because
the SiteMinder SMSESSION cookie is only sent for the domain for which it
is configured. If users access the SA Series SSL VPN Appliance using an IP
address, they may receive an authentication failure and will be prompted
to authenticate again.
•
The SA Series SSL VPN Appliance logs any SiteMinder error codes on the
System > Log/Monitoring > User Access page. For information on the
SiteMinder error codes, see the SiteMinder documentation.
185
Secure Access Administration Guide
Authentication Using Various Authentication Schemes
Within SiteMinder, an authentication scheme is a way to collect user credentials and
determine the identity of a user. You may create different authentication schemes and
associate different protection levels with each. For example, you may create two
schemes—one that authenticates users based solely on the users’ client-side certificates
and provides them a low protection level, and a second that uses ACE SecurID token
authentication and provides users a higher protection level. The SA Series SSL VPN
Appliance works with the following types of SiteMinder authentication schemes:
•
Basic username and password authentication—The user’s name and password are
passed to the SiteMinder policy server. The policy server may then authenticate them
itself or pass it to another server for authentication.
•
ACE SecurID token authentication—The SiteMinder policy server authenticates users
based on a username and password generated by an ACE SecurID token.
•
Client-side certificate authentication—The SiteMinder policy server authenticates
users based on their client-side certificate credentials. If you choose this authentication
method, the Web browser displays a list of client certificates from which users can
select.
NOTE:
•
If you choose to authenticate users with this method, you must import the
client certificate into the SA Series SSL VPN Appliance through the System
> Certificates > Trusted Client CAs tab.
•
If you do not want to display the standard SA Series sign in page to users,
you may change it using the customizable sign-in pages feature. For more
information, see the Custom Sign-In Pages Solution Guide.
•
SiteMinder client-side certificate authentication is separate from SA Series
client-side certificate authentication. If you choose both, the SA Series SSL
VPN Appliance first authenticates using the SA Series configuration
parameters. If this succeeds, it then passes certificate values to SiteMinder
for authentication.
Determining the Username
With the availability of different authentication schemes and sign-in points, the SA Series
SSL VPN Appliance may obtain a username from various sources, such as a policy server
header, certificate attribute, or from the SA Series sign-in page. Listed below are the
various methods a user may employ to access the SA Series SSL VPN Appliance and
how the SA Series SSL VPN Appliance determines the username for each. When a user:
•
186
Signs in through the standard SA Series sign-in page— The SA Series SSL VPN
Appliance first checks the username that the policy server returned in its OnAuthAccept
response header. If SiteMinder does not define a username, the SA Series SSL VPN
Appliance uses the name that the user entered during sign-in. Otherwise, if neither
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
SiteMinder nor the user provide a username because the user authenticates using a
client certificate, the SA Series SSL VPN Appliance uses the UserDN value set by the
policy server.
•
Automatically signs in to the SA Series SSL VPN Appliance using SiteMinder
credentials—The SA Series SSL VPN Appliance first checks the username that the
policy server returned in its OnAuthAccept response header. If SiteMinder does not
define a username, the SA Series SSL VPN Appliance checks the SMSESSION cookie.
Otherwise, if SiteMinder does not populate the response header or SMSESSION cookie
with a username, the SA Series SSL VPN Appliance checks the UserDN value in the
SMSESSION cookie.
Once the SA Series SSL VPN Appliance determines which username to use, it saves it in
its session cache and references it when a user wants to access additional resources.
To consistently return the correct username to the SA Series SSL VPN Appliance, you
should configure the OnAuthAccept response on the SiteMinder policy server.
Related
Documentation
•
Configuring Secure Access to Work with SiteMinder on page 193
•
Creating a Rule/Response Pair to Pass Usernames to the SA Series SSL VPN Appliance
on page 192
•
Creating a SiteMinder Realm for the SA Series SSL VPN Appliance on page 191
•
Creating a SiteMinder Domain for the SA Series SSL VPN Appliance on page 191
•
Creating a SiteMinder Authentication Scheme for the SA Series SSL VPN Appliance
on page 189
•
Configuring the SiteMinder Agent on page 188
•
Configuring SiteMinder to Work with the SA Series SSL VPN Appliance on page 187
Configuring SiteMinder to Work with the SA Series SSL VPN Appliance
The following steps are required to configure a SiteMinder policy server to work with the
SA Series SSL VPN Appliance. These are not complete SiteMinder configuration
instructions—they are only intended to help you make SiteMinder work with the SA Series
SSL VPN Appliance. For in-depth SiteMinder configuration information, refer to the
documentation provided with your SiteMinder policy server.
•
Configure the SiteMinder Agent.
•
Create a SiteMinder authentication scheme for the SA Series SSL VPN Appliance.
•
Create a SiteMinder domain for the SA Series SSL VPN Appliance.
•
Create a SiteMinder realm for the SA Series SSL VPN Appliance.
•
Create a Rule/Response pair to pass usernames to the SA Series SSL VPN Appliance.
•
Create a SiteMinder Policy under the domain.
Copyright © 2011, Juniper Networks, Inc.
187
Secure Access Administration Guide
Related
Documentation
•
eTrust SiteMinder Overview on page 183
•
Configuring the SiteMinder Agent on page 188
•
Creating a SiteMinder Authentication Scheme for the SA Series SSL VPN Appliance
on page 189
•
Creating a SiteMinder Domain for the SA Series SSL VPN Appliance on page 191
•
Creating a SiteMinder Realm for the SA Series SSL VPN Appliance on page 191
•
Creating a Rule/Response Pair to Pass Usernames to the SA Series SSL VPN Appliance
on page 192
•
Configuring Secure Access to Work with SiteMinder on page 193
Configuring the SiteMinder Agent
A SiteMinder agent filters user requests to enforce access controls. For instance, when
a user requests a protected resource, the agent prompts the user for credentials based
on an authentication scheme, and sends the credentials to a SiteMinder policy server. A
Web agent is simply an agent that works with a Web server. When configuring SiteMinder
to work with the SA Series SSL VPN Appliance, you must configure the SA Series SSL
VPN Applianceas a Web agent in most cases.
NOTE:
If you select the Delegate authentication to a standard agent option, you
must set the following options in the agent configuration object of the
standard Web agent host the FCC URL:
•
<EncryptAgentName=no>
•
<FCCCompatMode=no>
To configure the SA Series SSL VPN Applianceas a Web agent on the SiteMinder policy
server:
1.
In the SiteMinder Administration interface, choose the System tab.
2. Right-click on Agents and choose Create Agent.
3. Enter a name for the Web agent and (optionally) a description. Note that you need
to enter this name when creating a SiteMinder realm.
4. You must select the Support 5.x agents option for compatibility with the SA Series
SSL VPN Appliance.
5. Under Agent Type, select SiteMinder and then select Web Agent from the drop-down
list. You must select this setting for compatibility with the SA Series SSL VPN
Appliance.
6. Under IP Address or Host Name, enter the name or IP address of the SA Series SSL
VPN Appliance.
188
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
7. In the Shared Secret field, enter and confirm a secret for the Web agent. Note that
you need to enter this secret when configuring the SA Series SSL VPN Appliance.
8. Click OK.
Related
Documentation
•
eTrust SiteMinder Overview on page 183
•
Configuring SiteMinder to Work with the SA Series SSL VPN Appliance on page 187
•
Creating a SiteMinder Authentication Scheme for the SA Series SSL VPN Appliance
on page 189
•
Creating a SiteMinder Domain for the SA Series SSL VPN Appliance on page 191
•
Creating a SiteMinder Realm for the SA Series SSL VPN Appliance on page 191
•
Creating a Rule/Response Pair to Pass Usernames to the SA Series SSL VPN Appliance
on page 192
•
Configuring Secure Access to Work with SiteMinder on page 193
Creating a SiteMinder Authentication Scheme for the SA Series SSL VPN Appliance
Within SiteMinder, an authentication scheme provides a way to collect credentials and
determine the identity of a user.
To configure a SiteMinder authentication scheme for the SA Series SSL VPN Appliance:
1.
In the SiteMinder Administration interface, choose the System tab.
2. Right-click on Authentication Schemes and choose Create Authentication Scheme.
3. Enter a name for the scheme and (optionally) a description. Note that you need to
enter this name when configuring the SiteMinder realm.
4. Under Authentication Scheme Type, select one of the following options:
•
Basic Template
•
HTML Form Template
•
SecurID HTML Form Template (If you are using SecurID authentication, you must
choose SecurID HTML Form Template (instead of SecurID Template). Choosing
this option enables the Policy Server to send ACE sign-in failure codes to the SA
Series SSL VPN Appliance).
•
X509 Client Cert Template
•
X509 Client Cert and Basic Authentication
Copyright © 2011, Juniper Networks, Inc.
189
Secure Access Administration Guide
NOTE:
• The SA Series SSL VPN Applianceonly supports the authentication
scheme types listed here.
•
You must select HTML Form Template if you want the SA Series
Appliance to handle re-authentication.
•
If you select X509 Client Cert Template or X509 Client Cert and Basic
Authentication, you must import the certificate into the SA Series SSL
VPN Appliance through the System > Certificates > Trusted Client CAs
tab.
5. Enter a protection level for the scheme. Note that this protection level carries over to
the SiteMinder realm that you associate with this scheme.
6. Select the Password Policies Enabled for this Authentication Scheme if you want
to reauthenticate users who request resources with a higher protection level than they
are authorized to access.
7. In the Scheme Setup tab, enter the options required by your authentication scheme
type.
If you want the SA Series SSL VPN Appliance to re-authenticate users who request
resources with a higher protection level than they are authorized to access, you must
enter the following settings:
•
Under Server Name, enter the SA Series SSL VPN Appliance host name (for example,
sales.yourcompany.net).
•
Select the Use SSL Connection checkbox.
•
Under Target, enter the SA Series Appliance sign-in URL defined in this step’s first
bullet plus the parameter “ive=1” (for example, /highproturl?ive=1). (The SA Series
SSL VPN Appliance must have a sign-in policy that uses */highproturl as the sign-in
URL and only uses the corresponding SiteMinder authentication realm.)
NOTE: When you save changes, ive=1 disappears from the target. This
is OK. The policy server includes ive=1 in the full authentication scheme
URL that it sends to the SA Series SSL VPN Appliance, as you can see
in the in the Parameter field of the Advanced tab.
•
De-select the Allow Form Authentication Scheme to Save Credentials checkbox.
•
Leave Additional Attribute List empty.
8. Click OK.
If you change a SiteMinder authentication scheme on the policy server, you must flush
the cache using the Flush Cache option on the Advanced tab.
190
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Related
Documentation
•
Configuring Secure Access to Work with SiteMinder on page 193
•
Creating a Rule/Response Pair to Pass Usernames to the SA Series SSL VPN Appliance
on page 192
•
Creating a SiteMinder Realm for the SA Series SSL VPN Appliance on page 191
•
Creating a SiteMinder Domain for the SA Series SSL VPN Appliance on page 191
•
Configuring the SiteMinder Agent on page 188
•
Configuring SiteMinder to Work with the SA Series SSL VPN Appliance on page 187
•
eTrust SiteMinder Overview on page 183
Creating a SiteMinder Domain for the SA Series SSL VPN Appliance
Within SiteMinder, a policy domain is a logical grouping of resources associated with one
or more user directories. Policy domains contain realms, responses, and policies. When
configuring the SA Series SSL VPN Appliance to work with SiteMinder, you must give SA
Series users access to a SiteMinder resource within a realm, and then group the realm
into a domain.
To configure a SiteMinder domain for the SA Series SSL VPN Appliance:
1.
Choose the System tab, right-click on Domains and choose Create Domain, or click
on Domains and choose an existing SiteMinder domain.
2. Add a realm to the domain.
Related
Documentation
•
Configuring SiteMinder to Work with the SA Series SSL VPN Appliance on page 187
•
Creating a SiteMinder Realm for the SA Series SSL VPN Appliance on page 191
Creating a SiteMinder Realm for the SA Series SSL VPN Appliance
Within SiteMinder, a realm is a cluster of resources within a policy domain grouped
together according to security requirements. When configuring SiteMinder to work with
the SA Series SSL VPN Appliance, you must define realms to determine which resources
SA Series users may access.
Within SiteMinder, a realm is a cluster of resources within a policy domain grouped
together according to security requirements. When configuring SiteMinder to work with
the SA Series SSL VPN Appliance, you must define realms to determine which resources
SA Series users may access.
1.
In the SiteMinder Administration interface, select the Domains tab.
2. Expand the domain that you created for the SA Series SSL VPN Appliance.
3. Right-click on Realms and choose Create Realm.
4. Enter a name and (optionally) description for the realm.
Copyright © 2011, Juniper Networks, Inc.
191
Secure Access Administration Guide
5. In the Agent field, select the Web agent that you created for the SA Series SSL VPN
Appliance.
6. In the Resource Filter field, enter a protected resource. This resource inherits the
protection level specified in the corresponding authentication scheme. For the default
protection level, enter /ive-authentication. Note that you need to enter this resource
when configuring the SA Series SSL VPN Appliance. Or, if you use sign-in policies with
nondefault URLs such as */nete or */cert, you must have corresponding resource
filters in the SiteMinder configuration.
7. From the Authentication Schemes list, select the scheme that you created for the
SA Series SSL VPN Appliance.
8. Click OK.
Related
Documentation
•
Configuring SiteMinder to Work with the SA Series SSL VPN Appliance on page 187
•
Creating a SiteMinder Domain for the SA Series SSL VPN Appliance on page 191
Creating a Rule/Response Pair to Pass Usernames to the SA Series SSL VPN Appliance
Within SiteMinder, you can use rules to trigger responses when authentication or
authorization events take place. A response passes DN attributes, static text, or
customized active responses from the SiteMinder policy server to a SiteMinder agent.
When you configure SiteMinder to work with the SA Series SSL VPN Appliance, you must
create a rule that fires when a user successfully authenticates. Then, you must create a
corresponding response that passes the user’s username to the SA Series Web agent.
To create a new rule:
1.
In the SiteMinder Administration interface, choose the Domains tab.
2. Expand the domain that you created for the SA Series SSL VPN Appliance, and then
expand Realms.
3. Right-click on the realm that you created for the SA Series SSL VPN Appliance, and
choose Create Rule under Realm.
4. Enter a name and (optionally) description for the rule.
5. Under Action, choose Authentication Events and then select OnAuthAccept from
the drop-down list.
6. Select Enabled.
7. Click OK.
To create a new response:
1.
In the SiteMinder Administration interface, choose the Domains tab.
2. Expand the domain that you created for the SA Series SSL VPN Appliance.
3. Right-click on Responses and select Create Response.
4. Enter a name and (optionally) a description for the response.
192
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
5. Select SiteMinder and then select the SA Series Web agent.
6. Click Create.
7. From the Attribute list, select WebAgent-HTTP-Header-Variable.
8. Under Attribute Kind, select Static.
9. Under Variable Name, enter IVEUSERNAME.
10. Under Variable Value, enter a user name.
11. Click OK.
Related
Documentation
•
Configuring SiteMinder to Work with the SA Series SSL VPN Appliance on page 187
•
Configuring the SiteMinder Agent on page 188
Configuring the SA Series SSL VPN Appliance to Work with SiteMinder
This section includes instructions for configuring the SA Series SSL VPN Appliance to
work with a SiteMinder policy server.
Configuring the SA Series SSL VPN Appliance to Work with Multiple Authentication
Schemes
To configure the SA Series SSL VPN Appliance to work with multiple SiteMinder
authentication schemes, you must:
1.
Configure the authentication schemes on the SiteMinder policy server.
2. Create one SA Series instance of the SiteMinder policy server for all SiteMinder
authentication schemes you want to use.
3. Specify which SA Series realm should use the SA Series instance of the SiteMinder
policy server to authenticate and authorize administrators and users.
4. For each protected resource on the SiteMinder policy server, create a SA Sereis sign-in
policy. In the Authentication > Authentication > Signing In Policies > New Sign-In
Policy page:
•
Specify a SA Series sign-in URL that matches the SiteMinder protected resource
URL on the policy server. Make the path portion of the URL match the SiteMinder
resource filter in the SiteMinder realm configuration. For example, you can specify
*/ACE/ as an SA Series sign-in URL to match a SiteMinder URL of XYZ/ACE, where
XYZ is the name of a realm.
•
Select the SA Series realm that you specified should use the SiteMinder policy
server.
The user signs into the SA Series SSL VPN Appliance using one of the SA Series sign-in
URLs. The SA Series SSL VPN Appliance sends the protected resource URL to SiteMinder,
and based on the resource, SiteMinder determines which type of scheme to use to
authenticate the user. The SA Series SSL VPN Appliance collects the credentials that
Copyright © 2011, Juniper Networks, Inc.
193
Secure Access Administration Guide
the authentication scheme requires, and then passes them to SiteMinder for
authentication.
Configuring the SA Series SSL VPN Appliance to Grant Users Different Protected
Resources
To configure the SA Series SSL VPN Appliance to grant users access to various SiteMinder
protected resources (and by association, different protection levels), you must:
1.
Define which resources the SiteMinder server should protect. Each of these resources
inherits a protection level from a corresponding SiteMinder authentication scheme.
2. Create one SA Series instance of the SiteMinder policy server for all protected resources
and corresponding protection levels that you want to allow.
3. Specify which SA Series realm should use the SA Series instance of the SiteMinder
policy server.
4. For each resource on the SiteMinder policy server, create an SA Series sign-in policy
for each realm-level resource filter. In the configuration page for the sign-in policy,
specify:
•
An SA Series sign-in URL that matches the protected resource URL on the policy
server. Make the path portion of the URL match the SiteMinder resource filter. For
example, you may define the following URLs:
https://employees.yourcompany.com/sales
https://employees.yourcompany.com/engineering
When users sign into the first URL, they can access the “sales” protected resource,
and when they sign into the second URL, they can access the “engineering” protected
resource.
To define a default resource (ive-authentication), enter * in the path portion of the
URL.
•
Select the SA Series realm that you specified should use the SiteMinder policy
server.
During production, the user signs into the SA Series SSL VPN Appliance using one of the
URLs. The SA Series SSL VPN Appliance extracts the protected resource from the URL
and authenticates the user against the appropriate realm.
Defining an eTrust SiteMinder Server Instance
Within the SA Series SSL VPN Appliance, a SiteMinder instance is a set of configuration
settings that defines how the SA Series SSL VPN Appliance interacts with the SiteMinder
policy server. After defining the SiteMinder server instance, specify which SA Series
realm(s) should use the SA Series instance of the SiteMinder policy server to authenticate
and authorize administrators and users.
194
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
To define an eTrust SiteMinder server instance:
1.
In the admin console, choose Authentication > Auth. Servers.
2. Do one of the following:
•
To create a new server instance on the SA Series SSL VPN Appliance, select
SiteMinder Server from the New list, and then click New Server.
•
To update an existing server instance, click the appropriate link in the
Authentication/Authorization Servers list.
3. Configure the server using the settings described in Table 15 on page 195.
4. To add SiteMinder user attributes to the SiteMinder server instance:
a. Click Server Catalog to display the server catalog.
b. Enter the SiteMinder user attribute cookie name in the Attribute field in the server
catalog and then click Add Attribute.
c. When you are finished adding cookie names, click OK. The SA Series SSL VPN
Appliance displays the names of the SiteMinder user attribute cookies in the
Attribute list on the Role Mapping Rule page.
5. Click Save Changes.
6. Set advanced SiteMinder configuration options (optional) using the settings described
in Table 15 on page 195.
Table 15: eTrust SiteMinder Configuration Options
Option
Description
Name
Enter a name to identify the server instance.
Policy Server
Enter the name or IP address of the SiteMinder policy server that you
want to use to authenticate users.
Backup Server(s),
Failover Mode
Enter a comma-delimited list of backup policy servers (optional). Then,
choose a failover mode:
•
Select Yes to have the SA Series SSL VPN Appliance use the main
policy server unless it fails.
•
Select No to have the SA Series SSL VPN Appliance load balance
among all the specified policy servers.
Agent Name,
Secret
Enter the shared secret and agent name.. Note that these are
case-sensitive.
Compatible with
Choose a SiteMinder server version. Version 5.5 supports versions 5.5
and 6.0. Version 6.0 supports only version 6.0 of the SiteMinder server
API. The default value is 5.5 policy servers.
Copyright © 2011, Juniper Networks, Inc.
195
Secure Access Administration Guide
Table 15: eTrust SiteMinder Configuration Options (continued)
Option
Description
On logout, redirect
to
Specify a URL to which users are redirected when they sign out of the
SA Series SSL VPN Appliance(optional). If you leave this field empty,
users see the default SA Series sign-in page.
Note: The On logout, redirect to field is included in the product release
for backwards-compatibility, but is scheduled for discontinuance. If you
want to redirect users to a different sign-in page when they sign out, we
strongly recommend that you use the customizable sign-in pages feature
instead. For more information, see the Custom Sign-In Pages Solution
Guide .
Protected Resource
Specify a default protected resource. If you do not create sign-in policies
for SiteMinder, the SA Series SSL VPN Appliance uses this default URL
to set the user’s protection level for the session. The SA Series SSL VPN
Appliance also uses this default URL if you select the Automatic Sign-In
option. If your users are signing in to the “*” URL (default SA Series sign-in
page), enter any URL (“/Secure Access-authentication” is the default)
to set the protection level to the default SA Series value. If you do create
sign-in policies for SiteMinder, the SA Series SSL VPN Appliance uses
those sign-in policies instead of this default URL.
Note: You must enter a forward slash (/) at the beginning of the resource
(for example, “/ive-authentication” ).
Resource Action
(Read-only) For new SiteMinder server instances, the SA Series SSL VPN
Appliance sets the resource action to GET. If your SiteMinder instance
is upgraded from a 3.x instance, the SA Series SSL VPN Appliance uses
the resource action (for example, GET, POST, or PUT) that you previously
chose. Note that to change an existing resource action to GET, you must
delete the old SiteMinder server instance and then create a new instance
that uses GET.
SMSESSION cookie settings
Cookie Domain
Enter the cookie domain of the SA Series SSL VPN Appliance. (A cookie
domain is a domain in which the user’s cookies are active—the SA Series
SSL VPN Appliance sends cookies to the user’s browser in this domain.)
Note:
•
Multiple domains should use a leading period and be
comma-separated. For example: .sales.myorg.com,
.marketing.myorg.com
•
Domain names are case-sensitive.
•
You cannot use wildcard characters.
For example, if you define “.juniper.net” , the user must access the SA
Series SSL VPN Appliance as “http://ive.juniper.net” in order to ensure
that his SMSESSION cookie is sent back to the SA Series SSL VPN
Appliance.
Protocol
196
(Read-only) Indicates that the SA Series SSL VPN Appliance uses HTTPS
protocol to send cookies to the user’s Web browser.
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 15: eTrust SiteMinder Configuration Options (continued)
Option
Description
IVE Cookie
DomainIC Cookie
Domain
Enter the Internet domain(s) to which the SA Series SSL VPN Appliance
sends the SMSESSION cookie using the same guidelines outlined for the
Cookie Domain field. (An SA Series cookie domain enables single sign-on
across multiple cookie domains. It allows a user’s information to carry
with him when he navigates from one domain to another.) If you have
configured a cookie provider to enable single sign-on across multiple
cookie domains, enter the domain of the cookie provider. Otherwise,
enter the domain(s) of the Web agents for which single sign-on is desired.
For example: .juniper.net
Protocol
Choose HTTPS to send cookies securely if other Web agents are set up
to accept secure cookies, or HTTP to send cookies non-securely.
SiteMinder authentication settings
Automatic Sign-In
Select the Automatic Sign-In option to automatically sign in users who
have a valid SMSESSION cookie in to the SA Series SSL VPN Appliance.
Then, select the authentication realm to which the users are mapped. If
you select this option, note that:
•
If the protection level associated with a user’s SMSESSION cookie is
different from the protection level of the SA Series realm, the SA Series
SSL VPN Appliance uses the protection level associated with the
cookie.
•
In order to enable single sign-on from another Web agent to the SA
Series SSL VPN Appliance, the SA Series SSL VPN Appliance needs
to validate an existing SMSESSION cookie created by a standard Web
agent.
•
The SA Series SSL VPN Appliance supports the following realm and
role limitations with the Automatic Sign-in feature: Host Checker,
Cache Cleaner, IP address, browser, and concurrent user limit checks.
Certificate and password restrictions are not supported since they are
not applicable to automatically signed-in users.
•
The SA Series SSL VPN Appliance does not support the Automatic
Sign in feature for administrator roles. This feature is only available
for end-users.
When you select the Automatic Sign-In option, you must also
configure the following sub-options:
•
To assign user roles, use this authentication realm
Select an authentication realm for automatically signed-in users. The
SA Series SSL VPN Appliance maps the user to a role based on the
role mapping rules defined in the selected realm.
Copyright © 2011, Juniper Networks, Inc.
197
Secure Access Administration Guide
Table 15: eTrust SiteMinder Configuration Options (continued)
Option
Description
•
If Automatic Sign In fails, redirect to
Enter an alternative URL for users who sign into the SA Series SSL
VPN Appliance through the Automatic Sign-In mechanism. The SA
Series SSL VPN Appliance redirects users to the specified URL if the
SA Series SSL VPN Appliance fails to authenticate and no redirect
response is received from the SiteMinder policy server. If you leave this
field empty, users are prompted to sign back in to the SA Series SSL
VPN Appliance.
Note:
•
Users who sign in through the SA Series SSL VPN Appliance sign-in
page are always redirected back to the SA Series SSL VPN Appliance
sign-in page if authentication fails.
•
If you are using the customizable UI (Custom Pages) option explained
in the Custom Sign-In Pages Solution Guide . note that the SA Series
SSL VPN Appliance redirects to welcome.cgi in two different cases.
You must account for both of these special cases in your custom page:
Session and idle timeouts: /dana-na/auth/welcome.cgi?p=timed-out
Failed cookie validation: /dana-na/auth/welcome.cgi?p=failed
If you are using an authorization-only access policy, you must enter an
alternative URL in this field regardless of whether you select the
Automatic Sign In option. Users are redirected to this URL when
SMSESSION cookie validation fails or if no SMSESSION cookie exists.
Authenticate using
custom agent
198
Choose this option if you want to authenticate using the SA Series custom
Web agent. Note that if you select this option, you must also:
•
Update all of your standard Web agents to the appropriate Siteminder
Agent Quarterly Maintenance Release (QMR) in order to accept the
cookies created by the SA Series SSL VPN Appliance. If you are running
SiteMinder version 5 Web agents, use the QMR5 hot fix. The SA Series
SSL VPN Appliance is compatible with version 5.x and later SiteMinder
agents. Older versions of SiteMinder agents are susceptible to cookie
validation failures.
•
Set the Accept Third Party Cookie attribute (AcceptTPCookie) to yes
in the Web agent’s configuration file (webagent.conf) or to 1 in the
Windows Registry for the IIS Web server. The location of the attribute
depends on the SiteMinder version and Web server you are using. For
more information, please refer to the documentation provided with
your SiteMinder server.
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 15: eTrust SiteMinder Configuration Options (continued)
Option
Description
Authenticate using
HTML form post
Choose this option if you want to post user credentials to a standard
Web agent that you have already configured rather than contacting the
SiteMinder policy server directly. If you select this option, the Web agent
contacts the policy server to determine the appropriate sign-in page to
display to the user. In order to configure the SA Series SSL VPN Appliance
to “act like a browser” that posts credentials to the standard Web agent,
you must enter the information defined below. The easiest way to find
this information is to:
1.
Open a Web browser and enter the URL of the standard web agent
that you want to use. For example, http://webagent.juniper.net
2. Note the URL of the SiteMinder sign-in page that appears. For
example:
http://webagent.juniper.net/siteminderagent/forms/login.fcc?TYPE=33554433&R
EALMOID=06-2525fa65-5a7f-11d5-9ee00003471b786c&GUID=&SMAUTHREASO
N=0&TARGET=$SM$http%3a%2f%2fw
ebagent%2ejuniper%2enet%2fportal%2 findex%2ejsp
3. Extract information from the URL to enter in the fields that follow.
Note:
4. You cannot use SecurID New Pin and Next Token modes, client-side
certificate authentication, or SNMP traps with the Authenticate using
HTML form post option.
5. The Authorize While Authenticating option is not applicable with
the HTML form post option.
6. You can authenticate users using this option, but if you want to
authorize them as well, you must select Authenticate using custom
agent.
When you select the Authenticate using HTML form post option,
you must also configure the following sub-options:
•
Target
URL on the external, eTrust-enabled Web server. In the Web agent
sign-in page URL, the target appears after &TARGET=$SM$. For
example, in the URL shown in Authenticate Using HTML Form Post,
the target is:
http%3a%2f%2fwebagent%2ejuniper%2enet%2fportal%2findex%2ejsp
After converting special characters (%3a=colon, %2f=backslash,
%2e=period), the final target is:
http://webagent.juniper.net/portal/index.jsp
•
Protocol
Protocol for communication between the SA Series SSL VPN Appliance
and the specified Web agent. Use HTTP for non-secure communication
or HTTPS for secure communication. In the Web agent sign-in page
URL, the protocol appears first. For example, in the URL shown in
Authenticate Using HTML Form Post, the protocol is HTTP.
Copyright © 2011, Juniper Networks, Inc.
199
Secure Access Administration Guide
Table 15: eTrust SiteMinder Configuration Options (continued)
Option
Description
•
Web Agent
Name of the Web agent from which the SA Series SSL VPN Appliance
is to obtain SMSESSION cookies. An IP address is not allowed for this
field. (Specifying the IP address as the Web agent prevents some
browsers from accepting cookies.) In the Web agent sign-in page URL,
the Web agent appears after the protocol. For example, in the URL
shown above in Authenticate Using HTML Form Post, the Web agent
is: webagent.juniper.net
•
Port
Port 80 for HTTP or port 443 for HTTPS.
•
Path
Path of the Web agent’s sign-in page. Note that the path must start
with a backslash (/) character. In the Web agent sign-in page URL,
the path appears after the Web agent. For example, in the URL shown
in Authenticate Using HTML Form Post, the path is:
/siteminderagent/forms/login.fcc
•
Parameters
Post parameters to be sent when a user signs in. Common SiteMinder
variables that you can use include _ _USER_ _,
_ _PASS_ _, and _ _TARGET_ _. These variables are replaced by the
username and password entered by the user on the Web agent’s
sign-in page and by the value specified in the Target field. These are
the default parameters for login.fcc—if you have made customizations,
you may need to change these parameters.
Delegate
authentication to a
standard agent
Choose this option if you want to delegate authentication to a standard
agent. When the user accesses the SA Series SSL VPN Appliance sign-in
page, the SA Series SSL VPN Appliance determines the FCC URL
associated with the protected resource’s authentication scheme. The
SA Series SSL VPN Appliance redirects the user to that URL, setting the
SA Series SSL VPN Appliance sign-in URL as the target. After successfully
authenticating with the standard agent, an SMSESSION cookie is set in
the user’s browser and he is redirected back to the SA Series SSL VPN
Appliance. The SA Series SSL VPN Appliance then automatically signs
in the user and establishes an SA Series session.
NOTE:
200
•
You must enable the Automatic Sign-In option in order to use this
feature.
•
If you enable this option and a user already has a valid SMSESSION
cookie when he tries to access a resource, the SA Series SSL VPN
Appliance tries to automatically sign in using the existing SMSESSION
cookie. If the cookie is invalid, the SA Series SSL VPN Appliance clears
the SMSESSION cookie and corresponding SA Series cookies and
presents the user with a “timeout” page. The SA Series SSL VPN
Appliance successfully delegates authentication when the user clicks
the “sign back in” option.
•
If you select this option, your authentication scheme must have an
associated FCC URL.
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 16: eTrust SiteMinder Advanced Configuration Options
Option
Description
Poll Interval
Enter the interval at which the SA Series SSL VPN Appliance polls the
Siteminder policy server to check for a new key.
Max. Connections
Controls the maximum number of simultaneous connections that the
SA Series SSL VPN Appliance is allowed to make to the policy server.
The default setting is 20.
Max. Requests/
Connection
Controls the maximum number of requests that the policy server
connection handles before the SA Series SSL VPN Appliance ends the
connection. If necessary, tune to increase performance. The default
setting is 1000.
Idle Timeout
Controls the maximum number of minutes a connection to the policy
server may remain idle (the connection is not handling requests) before
the SA Series SSL VPN Appliance ends the connection. The default
setting of “none” indicates no time limit.
Authorize while
Authenticating
Specifies that the SA Series SSL VPN Appliance should look up user
attributes on the policy server immediately after authentication to
determine if the user is truly authenticated. For example, if your eTrust
server authenticates users based on an LDAP server setting, you can
select this option to indicate that the SA Series SSL VPN Appliance
should authenticate users through the eTrust server and then authorize
them through the LDAP server before granting them access. If the user
fails authentication or authorization, he is redirected to the page
configured on the policy server.
Note:
Enable Session
Grace Period,
Validate cookie
every N seconds
Copyright © 2011, Juniper Networks, Inc.
•
If you do not select this option and you have authorization options
setup through the Policy Users > Exclude tab of the policy server
configuration utility, a user whom you have denied access may
successfully authenticate into the SA Series SSL VPN Appliance. Not
until the user tries to access a protected resource does the SA Series
SSL VPN Appliance check his authorization rights and deny him access.
•
The SA Series SSL VPN Appliance sends the same resource to the
policy server for authorization as for authentication.
•
This option is not supported with the Authenticate using HTML form
post option or the Automatic sign-in .
You can eliminate the overhead of verifying a user’s SMSESSION cookie
each time the user requests the same resource by indicating that the SA
Series SSL VPN Appliance should consider the cookie valid for a certain
period of time. During that period, the SA Series SSL VPN Appliance
assumes that its cached cookie is valid rather than re-validating it against
the policy server. If you do not select this option, the SA Series SSL VPN
Appliance checks the user’s SMSESSION cookie on each request. Note
that the value entered here does not affect session or idle timeout
checking.
201
Secure Access Administration Guide
Table 16: eTrust SiteMinder Advanced Configuration Options (continued)
Option
Description
Ignore Query Data
By default, when a user requests a resource, the SA Series SSL VPN
Appliance sends the entire URL for that resource to the policy server
(including the query parameter, if present). For example, the SA Series
SSL VPN Appliance may send the following URL to the policy server:
http://foo/bar?param=value. (Query data appears after the ? character
in the URL. Within this URL, param=value represents the query
parameter.)
The SA Series SSL VPN Appliance then caches the result of the
authorization request for 10 minutes, including the query parameter. If
the user then requests the same resource that is specified in the cached
URL, the request fails since the query portion of the cached URL does
not match the new request. Secure Access then has to re-contact the
policy server to make a request that includes the new query parameter.
If you select the Ignore Query Data option, Secure Access does not cache
the query parameter in its URLs. Therefore, if a user requests the same
resource as is specified in the cached URL, the request should not fail.
For example, if you enable the Ignore Query Data option, both of the
following URLs are considered the same resource:
http://foo/bar?param=value1
http://foo/bar?param=value2
Enabling this option may improve performance.
Related
Documentation
Accounting Port
The value entered in this field must match the accounting port value
entered through the Policy Server Management Console. By default, this
field matches the policy server’s default setting of 44441.
Authentication Port
The value entered in this field must match the authentication port value
entered through the Policy Server Management Console. By default, this
field matches the policy server’s default setting of 44442.
Authorization Port
The value entered in this field must match the authorization port value
entered through the Policy Server Management Console. By default, this
field matches the policy server’s default setting of 44443.
Flush Cache
Use to delete the Secure Access resource cache, which caches resource
authorization information for 10 minutes.
•
Creating a SiteMinder Authentication Scheme for the SA Series SSL VPN Appliance
on page 189
•
Configuring User Sign In Policies on page 228
Using SiteMinder User Attributes for Secure Access Role Mapping
After you create user attributes on a SiteMinder policy server, you can use them in role
mapping rules for a realm that uses the SiteMinder policy server.
202
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
To use SiteMinder user attributes for Secure Access role mapping:
1.
In the admin console, choose Administrators > Admin Realms or Users > User Realms.
2. On the General tab of the Authentication Realms page for the Secure Access realm
that uses the SiteMinder policy server, choose Same as Above from the
Directory/Attribute list.
NOTE: If you choose LDAP from the Directory/Attribute list instead of
Same as Above, you can use both SiteMinder and LDAP attributes in role
mapping rules.
3. On the Secure Access Role Mapping tab, create a rule based on Secure Access user
attributes that references a SiteMinder user attribute cookie.
For example, to reference a SiteMinder user attribute cookie named department, add
department to the list of Secure Access user attributes on the Secure Access Role
Mapping tab. Then specify a value for the SiteMinder user attribute cookie, such as
sales.
You can also use the following syntax to reference a SiteMinder user attribute cookie
in a custom expression for a role mapping rule:
userAttr.<cookie-name>
For example:
<userAttr.department = ("sales" and "eng")>
Related
Documentation
•
Using SiteMinder User Attributes for Secure Access Role Mapping on page 202
•
Creating an Authentication Realm on page 214
•
Role Mapping Rules on page 216
Defining a SiteMinder Realm for Automatic Sign-In
SiteMinder Automatic Sign In requires a realm whose authentication server is the
SiteMinder server. If you perform an upgrade and you have already defined the Automatic
Sign In realm that does not specify the SiteMinder server for authentication, and you have
configured the SiteMinder server:
•
The realms do not appear in the SiteMinder realm list under SiteMinder authentication
settings in the admin console.
•
The upgrade process creates a new realm called eTrust-Auto-Login-Realm which is
based on your existing realm, but which configures the SiteMinder server as its
authentication server.
Copyright © 2011, Juniper Networks, Inc.
203
Secure Access Administration Guide
To configure the SiteMinder realm on a new installation:
1.
Select Authentication > Auth. Servers.
2. Choose SiteMinder from the New list and click New Server.
3. Specify the settings you want.
4. Click Save Changes.
5. Configure the realm, and select the SiteMinder server as the authentication server.
6. Select Authentication > Auth. Servers.
7. Choose the SiteMinder server you defined previously.
8. Under SiteMinder authentication settings, select the Automatic Sign In check box.
9. Choose the realm you just configured from the user authentication realm list.
10. Click Save Changes.
NOTE: The user authentication realm list on the SiteMinder server page only
displays realms that are configured for SiteMinder. If you have not configured
any SiteMinder realms, the drop down menu is empty.
Related
Documentation
•
Configuring SiteMinder to Work with the SA Series SSL VPN Appliance on page 187
•
Debugging SiteMinder and Secure Access Issues on page 204
Debugging SiteMinder and Secure Access Issues
204
Problem
At some point, you may encounter problems configuring the eTrust SiteMinder server
interactions with Secure Access. You can use a number of debugging tools to identify
and resolve problems:
Solution
•
Review the Secure Access log file. Secure Access tracks failures of cookie validation,
authorizing requests, and key rollovers.
•
Review the Policy Server Authentication log files.
•
Review the Standard Web Agent log file if you have selected the Authentication using
HTLM Form POST option.
•
Confirm that Secure Access contains the proper suffix that you defined in the Cookie
Domain field. If Secure Access is not properly addressed, the browser may not forward
the correct SMSESSION cookie to Secure Access and you may not be able to sign in.
You must enter the Secure Access’s FQDN on the browser, not the Secure Access IP
address, otherwise, your login fails.
•
Confirm that the Secure Access system time is synchronized with the SiteMinder server’s
system time. If the two system times are too divergent, the timeout settings may not
function correctly, rejecting your attempts to sign in.
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Related
Documentation
•
In the SiteMinder server, confirm that you have defined the proper Session Timeout
options max timeout and idle in the Siteminder Realm dialog.
•
If you sign in to Secure Access and browse to a eTrust-protected Web agent, then
reach the eTrust sign-in page instead of the single sign on (SSO) page, check the
Secure Access Cookie Domain value to confirm that the domain matches the domain
of the eTrust-protected Web agent. Review the setting for the Send Cookie Securely
option. If Send Cookie Securely is set to yes, SSO works only with secure https:// sites.
If Send Cookie Securely is set to no, SSO works with both http:// and https:// sites.
•
Configuring SiteMinder to Work with the SA Series SSL VPN Appliance on page 187
Configuring a SAML Server Instance
Secure Access accepts authentication assertions generated by a SAML authority using
either an artifact profile or a POST profile. This feature allows a user to sign in to a source
site or portal without going through Secure Access first. and then to access Secure Access
with single sign-on (SSO) through the SAML consumer service.
As a result, the user who authenticates elsewhere is able to access resources behind
Secure Access without signing in again.
Using the Artifact Profile and POST Profile
The two supported profiles provide different methods of accomplishing the same task.
The end-user’s goal is to sign in to all desired resources once, without experiencing
multiple sign-in pages for different resources or applications. Although the end-user
wants transparency, you, the administrator, want to ensure complete security across the
resources on your system, regardless of the servers or sites represented.
The artifact profile requires that you construct an automated request-response HTTP
message that the browser can retrieve based on an HTTP GET request.
The POST profile requires that you construct an HTML form that can contain the SAML
assertion, and which can be submitted by an end-user action or a script action, using an
HTTP POST method.
Using the Artifact Profile Scenario
The SAML server generally supports the following artifact profile scenario:
1.
The user accesses a source site via a browser. The source site might be a corporate
portal using a non-Secure Access authentication access management system.
2. The source site challenges the user for username and password.
3. The user provides username and password, which the source site authenticates
through a call to an LDAP directory or other authentication server.
4. The user then clicks on a link on the source site, which points to a resource on a server
that is protected behind the Secure Access device.
Copyright © 2011, Juniper Networks, Inc.
205
Secure Access Administration Guide
5. The link redirects the user to the Intersite Transfer Service URL on the source site. The
source site pulls an authentication assertion message from its cache and encloses it
in a SOAP message. The source site constructs a SAML artifact (a Base64 string) that
it returns to the browser in a URI along with the destination and assertion address.
6. The destination site queries the authenticated assertion from the source site, based
on the artifact it receives from the source site.
7. If the elapsed time falls within the allowable clock skew time, Secure Access accepts
the assertion as a valid authentication, and the user meets any other Secure Access
policy restrictions, Secure Access grants the user access to the requested resource.
The main tasks you are required to fulfill to support Secure Access as the relying party
with the artifact profile include:
•
•
Implement the assertion consumer service, which:
•
Receives the redirect URL containing the artifact
•
Generates and sends the SAML request
•
Receives and processes the SAML response
Integrate the assertion consumer service with the existing Secure Access process,
which:
•
Maps the SAML assertion to a local user
•
Creates a Secure Access user session
•
Performs local authorization
•
Serves the resource or denies access
Using the POST Profile Scenario
The SAML server generally supports the POST profile scenario, as follows:
1.
The end-user accesses the source Web site, hereafter known as the source site.
2. The source site verifies whether or not the user has a current session.
3. If not, the source site prompts the user to enter user credentials.
4. The user supplies credentials, for example, username and password.
5. If the authentication is successful, the source site authentication server creates a
session for the user and displays the appropriate welcome page of the portal
application.
6. The user then selects a menu option or link that points to a resource or application
on a destination Web site.
7. The portal application directs the request to the local inter-site transfer service, which
can be hosted on the source site. The request contains the URL of the resource on the
destination site, in other words, the TARGET URL.
206
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
8. The inter-site transfer service sends an HTML form back to the browser. The HTML
FORM contains a SAML response, within which is a SAML assertion. The response
must be digitally signed. Typically the HTML FORM will contain an input or submit
action that will result in an HTTP POST. This can be a user-clickable Submit button
or a script that initiates the HTTP POST programmatically.
9. The browser, either due to a user action or by way of an auto-submit action, sends an
HTTP POST containing the SAML response to the destination Web site’s assertion
consumer service.
10. The replying party's assertion consumer (in this case, on the destination Web site)
validates the digital signature on the SAML Response.
11. If valid, the assertion consumer sends a redirect to the browser, causing the browser
to access the TARGET resource.
12. Secure Access, on the destination site, verifies that the user is authorized to access
the destination site and the TARGET resource.
13. TIf the user is authorized to access the destination site and the TARGET resource,
Secure Access returns the TARGET resource to the browser.
The main tasks you are required to fulfill to support Secure Access as the relying party
with the POST profile include:
Related
Documentation
•
Implement the assertion consumer service, which receives and processes the POST
form
•
Integrate the assertion consumer service with the existing Secure Access process,
which:
•
•
Maps the SAML assertion to a local user
•
Creates a Secure Access user session
•
Performs local authorization
•
Serves the resource or denies access
Understanding Assertions on page 207
Understanding Assertions
Each party in the request-response communication must adhere to certain requirements.
The requirements provide a predictable infrastructure so that the assertions and artifacts
can be processed correctly.
•
The artifact is a Base64-encoded string of 40 bytes. An artifact acts as a token that
references an assertion on the source site, so the artifact holder—Secure Access—can
authenticate a user who has signed in to the source site and who now wants to access
a resource protected by Secure Access. The source site sends the artifact to Secure
Access in a redirect, after the user attempts to access a resource protected by Secure
Access. The artifact contains:
Copyright © 2011, Juniper Networks, Inc.
207
Secure Access Administration Guide
•
•
TypeCode—2-byte hex code of 0x0001 that identifies the artifact type.
•
SourceID—20-byte encrypted string that determines the source site identity and
location. Secure Access maintains a table of SourceID values and the URL for the
corresponding SAML responder. Secure Access and the source site communicate
this information in a back channel. On receiving the SAML artifact, Secure Access
determines whether or not the SourceID belongs to a known source site, and, if it
does, obtains the site location before sending a SAML request. The source site
generates the SourceID by computing the SHA-1 hash of the source site’s own URL.
•
AssertionHandle—20-byte random value that identifies an assertion stored or
generated by the source site. At least 8 bytes of this value should be obtained from
a cryptographically secure RNG or PRNG.
The inter-site transfer service is the identity provider URL on the source site (not Secure
Access). Your specification of this URL in the admin console enables Secure Access
to construct an authentication request to the source site, which holds the user’s
credentials in cache. The request is similar to the following example:
GET http://<inter-site transfer host name and
path>?TARGET=<Target>...<HTTP-Version><other HTTP 1.0 or 1.1 components>
In the preceding sample, <inter-site transfer host name and path> consists of the host
name, port number, and path components of the inter-site transfer URL at the source
and where Target=<Target> specifies the requested target resource at the destination
(Secure Access protected) site. This request might look like:
GET http://10.56.1.123:8002/xferSvc?TARGET=http://www.dest.com/sales.htm
•
The inter-site transfer service redirects the user’s browser to the assertion consumer
service at the destination site—in this case, Secure Access. The HTTP response from
the source site inter-site transfer service must be in the following format:
<HTTP-Version> 302 <Reason Phrase>
<other headers>
Location: http://<assertion consumer host name and path>?<SAML
searchpart><other HTTP 1.0 or 1.1 components>
In the preceding sample, <assertion consumer host name and path> provides the host
name, port number, and path components of an assertion consumer URL at the
destination site and where <SAML searchpart>= …TARGET=<Target>
…SAMLart=<SAML artifact>… consists of one target description, which must be included
in the <SAML searchpart> component. At least one SAML artifact must be included
in the SAML <SAML searchpart> component. The asserting party can include multiple
SAML artifacts.
NOTE: You can use status code 302 to indicate that the requested resource
resides temporarily under a different URI.
If <SAML searchpart> contains more than one artifact, all of the artifacts
must share the same SourceID.
208
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
The redirect might look like:
HTTP/1.1 302 Found
Location:
http://www.ive.com:5802/artifact?TARGET=/www.ive.com/&SAMLart=artifact
•
The user's browser accesses the assertion consumer service, with a SAML artifact
representing the user's authentication information attached to the URL.
The HTTP request must appear as follows:
GET http://<assertion consumer host name and path>?<SAML searchpart>
<HTTP-Version><other HTTP 1.0 or 1.1 request components>
In the preceding sample, <assertion consumer host name and path> provides the host
name, port number, and path components of an assertion consumer URL at the
destination site.
<SAML searchpart>= …TARGET=<Taret>…SAMLart=<SAML artifact> …
A single target description MUST be included in the <SAML searchpart> component.
At least one SAML artifact MUST be included in the <SAML searchpart> component;
multiple SAML artifacts MAY be included. If more than one artifact is carried within
<SAML searchpart>, all the artifacts MUST have the same SourceID.
You should not expose the assertion consumer URL unless over SSL 3.0 or TLS 1.0.
Otherwise, transmitted artifacts might be available in plain text to an attacker.
•
The issuer value is typically the URL of the source site. You can specify the <ISSUER>
variable which will return the issuer value from the assertion.
•
The user name template is a reference to the SAML name identifier element, which
allows the asserting party to provide a format for the user name. The SAML specification
allows for values in the following formats:
•
Unspecified—indicates that interpretation of the content is left up to the individual
implementations. In this case, you can use the variable assertionName.
•
Email Address—indicates that content is in the form of an email address. In this case,
you can use the variable assertionName.
•
X.509 Subject Name—indicates that the content is in the form of an X.509 subject
name. In this case, you can use the variable assertionNameDN.<RDN>.
•
Windows Domain Qualified Name—indicates that the content is a string in the form
of DomainName\Username.
You should define the user name template to accept the type of user name your SAML
assertion contains.
•
To prevent eavesdropping on the SAML artifact, source and destination sites should
synchronize their clocks as closely as possible. Secure Access provides an Allowed
Clock Skew attribute that dictates the maximum time difference allowed between
Secure Access and the source site. Secure Access rejects any assertions whose timing
exceeds the allowed clock skew.
Copyright © 2011, Juniper Networks, Inc.
209
Secure Access Administration Guide
Related
Documentation
•
Configuring a SAML Server Instance on page 205
•
Creating a new SAML Server Instance on page 210
Creating a new SAML Server Instance
To create a new SAML server instance, and configure the common elements:
1.
In the admin console, choose Authentication > Auth. Servers.
2. Select SAML Server from the New list, and then click New Server.
3. Specify a name to identify the server instance.
4. Under Settings, specify the Source Site Inter-Site Transfer Service URL.
5. Specify the issuer value for the source site. Typically the URI or hostname of the issuer
of the assertion.
6. Specify the user name template, which is a mapping string from the SAML assertion
to a Secure Access user realm. For example, enter <assertionNameDN.CN> which
derives the username from the CN value in the assertion.
7. Specify the Allowed Clock Skew value, in minutes. This value determines the maximum
allowed difference in time between the SA Series Appliance clock and the source site
clock.
8. define the configuration for either the artifact profile or for the POST profile.
Related
Documentation
•
Configuring a SAML Server Instance on page 205
•
Configuring the SAML Server Instance to Use an Artifact Profile on page 210
•
Configuring the SAML Server Instance to Use the POST Profile on page 211
Configuring the SAML Server Instance to Use an Artifact Profile
To configure the SAML Server to use an artifact profile:
1.
On the New SAML Server page, enter the Source ID. The source ID is the 20-byte
identifier that Secure Access uses to recognize an assertion from a given source site.
2. Enter the Source SOAP Responder Service URL. You should specify this URL in the
form of an HTTPS: protocol.
3. Choose the type of SOAP Client Authentication.
•
If you choose HTTP Basic, you must then enter the username and password, and
confirm the password.
•
If you choose SSL Client Certificate, choose a Secure Access certificate from the
drop down menu.
4. Click Save Changes. If you are creating the server instance for the first time, the
Settings and Users tabs appear.
210
Copyright © 2011, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
The Settings tab allows you to modify any of the settings pertaining to the SAML Server
instance and the artifact profile. The Users tab lists valid users of the server.
Related
Documentation
•
Creating a new SAML Server Instance on page 210
•
Configuring a SAML Server Instance on page 205
Configuring the SAML Server Instance to Use the POST Profile
To configure the SAML Server to use a POST profile:
1.
On the New SAML Server page, select the Post option.
2. Enter the name of, or browse to locate, the Response Signing Certificate. This is the
PEM-formatted signing certificate, which is loaded for the SAML response signature
verification.
The certificate you select should be the same certificate used for signing the SAML
response at the source site. The source site may send this certificate along with the
SAML response, depending on the source site configuration. By default, the system
performs signature verification of the SAML response first on the locally configured
certificate. If a certificate is not configured locally in the SAML authentication server,
then the system performs the signature verification on the certificate included in the
SAML response from the source site.
3. Select the Enable Signing Certificate status checking option if you want the SA Series
Appliance to be able to check the validity of the signing certificate configured in the
SAML authentication server POST profile. It is possible that the certificate has already
expired is has been revoked.
4. If you already have a certificate loaded and want to use another, locate the certificate,
then click Delete. You can then install another certificate.
5. Click Save Changes. If you are creating the server instance for the first time, the
Settings and Users tabs appear.
The Settings tab allows you to modify any of the settings pertaining to the SAML
Server instance and the artifact profile. The Users tab lists valid users of the server.
Related
Documentation
•
Creating a new SAML Server Instance on page 210
•
Configuring a SAML Server Instance on page 205
Copyright © 2011, Juniper Networks, Inc.
211
Secure Access Administration Guide
212
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 9
Authentication Realms
•
Authentication Realm Overview on page 213
•
Creating an Authentication Realm on page 214
•
Defining Authentication Access Policies on page 215
•
Role Mapping Rules on page 216
•
Specifying Role Mapping Rules for an Authentication Realm on page 217
•
Using the LDAP Server Catalog on page 219
•
Customizing User Realm UI Views on page 223
Authentication Realm Overview
An authentication realm specifies the conditions that users must meet in order to sign
into the SA Series Appliance. A realm consists of a grouping of authentication resources,
including:
•
An authentication server — verifies that the user is who he claims to be. The SA forwards
credentials that a user submits on a sign-in page to an authentication server.
•
A directory server—an LDAP server that provides user and group information to the SA
that the SA uses to map users to one or more user roles.
•
An authentication policy—specifies realm security requirements that need to be met
before the SA submits a user's credentials to an authentication server for verification.
•
Role mapping rules—conditions a user must meet in order for the SA to map the user
to one or more user roles. These conditions are based on either user information returned
by the realm's directory server or the user's username.
Authentication realms are an integral part of the SA access management framework,
and therefore are available on all Secure Access products. Note, however that custom
expressions are not available on the SA 700 appliance and are only available on all other
Secure Access products by special license. Therefore, when creating a realm, not all
administrators can create advanced role-mapping rules using custom expressions.
Related
Documentation
•
About Sign-In Policies on page 225
•
Defining Authentication Access Policies on page 215
•
Creating an Authentication Realm on page 214
Copyright © 2011, Juniper Networks, Inc.
213
Secure Access Administration Guide
Creating an Authentication Realm
To create an authentication realm:
1.
In the admin console, choose Administrators > Admin Realms or Users > User Realms.
2. On the respective Authentication Realms page, click New. Or, select a realm and click
Duplicate to base your realm on an existing realm.
3. Enter a name to label this realm and (optionally) a description.
4. If you are copying an existing realm, click Duplicate. Then, if you want to modify any
of its settings, click the realm’s name to enter into edit mode.
5. Select When editing, start on the Role Mapping page if you want the Role Mapping
tab to be selected when you open the realm for editing.
6. Under Servers, specify:
•
An authentication server to use for authenticating users who sign in to this realm.
•
A directory/attribute server to use for retrieving user attribute and group information
for role mapping rules and resource policies. (optional)
•
A RADIUS accounting server to use to track when a user signs in and out of the
Infranet Controller (optional).
7. If you want to submit secondary user credentials to an SSO-enabled resource or
enable two-factor authentication to access the Secure Access device, select Additional
authentication server. Then:
a. Select the name of the secondary authentication server. Note that you cannot
choose an anonymous server, certificate server, or eTrust SiteMinder server.
b. Select Username is specified by user on sign-in page if you want to prompt the
user to manually submit his username to the secondary server during the Secure
Access sign-in process. Otherwise, if you want to automatically submit a username
to the secondary server, enter static text or a valid variable in the predefined as
field. By default, Secure Access submits the <username> session variable, which
holds the same username used to sign in to the primary authentication server.
c. Select Password is specified by user on sign-in page if you want to prompt the
user to manually submit his password to the secondary server during the Secure
Access sign-in process. Otherwise, if you want to automatically submit a password
to the secondary server, enter static text or a valid variable in the predefined as
field.
d. Select End session if authentication against this server fails if you want to control
access to Secure Access based on the successful authentication of the user’s
214
Copyright © 2011, Juniper Networks, Inc.
Chapter 9: Authentication Realms
secondary credentials. If selected, authentication fails if the user’s secondary
credentials fails.
8. If you want to use dynamic policy evaluation for this realm select Dynamic policy
evaluation to enable an automatic timer for dynamic policy evaluation of this realm’s
authentication policy, role mapping rules, and role restrictions. Then:
a. Use the Refresh interval option to specify how often you want the Infranet Controller
to perform an automatic policy evaluation of all currently signedin realm users.
Specify the number of minutes (5 to 1440).
b. Select Refresh roles to also refresh the roles of all users in this realm. (This option
does not control the scope of the Refresh Now button.)
c. Select Refresh resource policies to also refresh the resource policies (not including
Meeting and Email Client) for all users in this realm. (This option does not control
the scope of the Refresh Now button.)
d. Click Refresh Now to manually evaluate the realm’s authentication policy, role
mapping rules, role restrictions, user roles, and resource policies of all currently
signed-in realm users. Use this button if you make changes to an authentication
policy, role mapping rules, role restrictions, or resource policies and you want to
immediately refresh the roles of this realm’s users.
9. Click Save Changes to create the realm on the Secure Access device. The General,
Authentication Policy, and Role Mapping tabs for the authentication realm appear.
10. Perform the next configuration steps:
a. Configure one or more role mapping rules.
b. Configure an authentication policy for the realm.
Related
Documentation
•
Defining Authentication Access Policies on page 215
•
Configuring User Sign In Policies on page 228
•
Dynamic Policy Evaluation on page 63
Defining Authentication Access Policies
An authentication policy is a set of rules that controls one aspect of access
management—whether or not to present a realm’s sign-in page to a user. An
authentication policy is part of an authentication realm’s configuration, specifying rules
for Secure Access to consider before presenting a sign-in page to a user. If a user meets
the requirements specified by the realm's authentication policy, then Secure Access
presents the corresponding sign-in page to the user and then forwards the user's
credentials to the appropriate authentication server. If this server successfully
authenticates the user, then Secure Access moves on to the role evaluation process.
Copyright © 2011, Juniper Networks, Inc.
215
Secure Access Administration Guide
To specify authentication realm access policies:
In the admin console, choose Administrators > Admin Realms or Users > User Realms.
1.
2. On the respective Authentication Realms page, click Specifying RADIUS Request
Attributes a realm and then click the Authentication Policy tab.
3. On the Authentication Policy page, configure one or more of the access management
options described in the Related Topics section.
Related
Documentation
•
Specifying Source IP Access Restrictions on page 65
•
Specifying Password Access Restrictions on page 70
•
Specifying Certificate Access Restrictions on page 69
•
Specifying Browser Access Restrictions on page 67
•
Specifying Session Limits on page 71
Role Mapping Rules
Role mapping rules are conditions a user must meet in order for Secure Access to map
the user to one or more user roles. These conditions are based on either user information
returned by the realm's directory server or the user's username. You must specify role
mapping directives in the following format: <If the specified condition is|is not true, then
map the user to the selected roles>.
You create a role mapping rule on Role Mapping tab of an authentication realm. When
you click New Rule on this tab, the Role Mapping Rule page appears with an inline editor
for defining the rule. This editor leads you through the three steps of creating a rule:
•
•
•
216
Specify the type of condition on which to base the rule. Options include:
•
Username
•
User attribute
•
Certificate or certificate attribute
•
Group membership
•
Custom expressions
Specify the condition to evaluate, which consists of:
•
One or more usernames, user attributes, certificate attributes, groups (LDAP), or
expressions depending on the type of condition you selected.
•
Tto what the value(s) should equate, which may include a list of usernames, user
attribute values from a RADIUS or LDAP server, client-side certificate values (static
or compared to LDAP attributes), LDAP groups, or pre-defined custom expressions.
Specify the roles to assign to the authenticated user.
Copyright © 2011, Juniper Networks, Inc.
Chapter 9: Authentication Realms
Secure Access compiles a list of eligible roles to which a user may be mapped, which are
roles specified by the role mapping rules to which the user conforms. Next, Secure Access
evaluates the definition for each role to determine if the user complies with any role
restrictions. Secure Access uses this information to compile a list of valid roles, which
are roles for which the user meets any additional requirements. Finally, Secure Access
either performs a permissive merge of the valid roles or presents a list of valid roles to
the user, depending on the configuration specified on the realm’s Role Mapping tab.
Related
Documentation
•
User Roles Overview on page 89
Specifying Role Mapping Rules for an Authentication Realm
When creating a new rule that uses LDAP or SiteMinder user attributes, LDAP group
information, or custom expressions, you must use the server catalog.
To specify role mapping rules for an authentication realm:
1.
In the admin console, choose Administrators > Admin Realms or Users > User Realms.
2. On the respective Authentication Realms page, select a realm and then click the Role
Mapping tab.
3. Click New Ruleto access the Role Mapping Rule page. This page provides an inline
editor for defining the rule.
4. In the Rule based on list, choose one of the following:
•
Username—Username is the Secure Access username entered on the sign-in page.
Choose this option if you want to map users to roles based on their Secure Access
usernames. This type of rule is available for all realms.
•
User attribute—User attribute is a user attribute from a RADIUS, LDAP, or SiteMinder
server. Choose this option if you want to map users to roles based on an attribute
from the corresponding server. This type of rule is available only for realms that use
a RADIUS server for the authentication server, or that use an LDAP or SiteMinder
server for either the authentication server or directory server. After choosing the
User attribute option, click Update to display the Attribute list and the Attributes
button. Click the Attributes button to display the server catalog.
•
•
To add SiteMinder user attributes, enter the SiteMinder user attribute cookie
name in the Attribute field in the server catalog, and then click Add Attribute.
When you are finished adding cookie names, click OK. Secure Access displays
the names of the SiteMinder user attribute cookies in the Attribute list on the Role
Mapping Rule page.
•
For information on how to use the server catalog to add LDAP user attributes.
Certificate or Certificate attribute—Certificate or Certificate attribute is an attribute
supported by the users’ client-side certificate. Choose this option if you want to
map users to roles based on certificate attributes. The Certificate option is available
for all realms; the Certificate attribute option is available only for realms that use
Copyright © 2011, Juniper Networks, Inc.
217
Secure Access Administration Guide
LDAP for the authentication or directory server. After choosing this option, click
Update to display the Attribute text box.
•
Group membership—Group membership is group information from an LDAP or
native Active Directory server that you add to the server catalog Groups tab. Choose
this option if you want to map users to roles based on either LDAP or Active Directory
group information. This type of rule is available only for realms that use an LDAP
server for either the authentication server or directory server or that use an Active
Directory server for authentication. (Note that you cannot specify an Active Directory
server as an authorization server for a realm.)
•
Custom Expressions—Custom Expressions is one or more custom expressions that
you define in the server catalog. Choose this option if you want to map users to roles
based on custom expressions. This type of rule is available for all realms. After
choosing this option, click Update to display the Expressions lists. Click the
Expressions button to display the Expressions tab of the server catalog.
NOTE: If you add more than one custom expression to the same rule,
Secure Access creates an “OR” rule for the expressions. For example,
you might add the following expressions to a single rule:
•
Expression 1: cacheCleanerStatus = 1
•
Expression 2: loginTime = (8:00AM TO 5:00PM)
Based on these expressions, a user would match this rule if Cache
Cleaner was running on his system OR if he signed into the Secure Access
device between 8:00 and 5:00.
5. Under Rule, specify the condition to evaluate, which corresponds to the type of rule
you select and consists of:
a. Specifying one or more usernames, SiteMinder user attribute cookie names, RADIUS
or LDAP user attributes, certificate attributes, LDAP groups, or custom expressions.
b. Specifying to what the value(s) should equate, which may include a list of Secure
Access usernames, user attribute values from a RADIUS, SiteMinder, or LDAP server,
client-side certificate values (static or LDAP attribute values), LDAP groups, or
custom expressions.
For example, you can choose a SiteMinder user attribute cookie named department
from the Attribute list, choose is from the operator list, and then enter "sales" and
"eng" in the text box.
Or, you can enter a custom expression rule that references the SiteMinder user
attribute cookie named department:
218
Copyright © 2011, Juniper Networks, Inc.
Chapter 9: Authentication Realms
<userAttr.department = ("sales" and "eng")>
6. Under ...then assign these roles:
a. Specify the roles to assign to the authenticated user by adding roles to the Selected
Roles list.
b. Check Stop processing rules when this rule matchesif you want Secure Access
to stop evaluating role mapping rules if the user meets the conditions specified for
this rule.
7. Click Save Changesto create the rule on the Role Mapping tab. When you are finished
creating rules:
Make sure to order role mapping rules in the order in which you want Secure Access to
evaluate them. This task is particularly important when you want to stop processing role
mapping rules upon a match.
Related
Documentation
•
Role Mapping Rules on page 216
•
Policies, Rules & Restrictions, and Conditions Overview on page 58
Using the LDAP Server Catalog
The LDAP server catalog is a secondary window through which you specify additional
LDAP information for Secure Access to use when mapping users to roles, including:
•
Attributes—The Server Catalog Attributes tab shows a list of common LDAP attributes,
such as cn, uid, uniquemember, and memberof. This tab is accessible only when
accessing the Server Catalog of an LDAP server. You can use this tab to manage an
LDAP server’s attributes by adding custom values to and deleting values from its Secure
Access server catalog. Note that Secure Access maintains a local copy of the LDAP
server’s values; attributes are not added to or deleted from your LDAP server’s dictionary.
•
Groups—The Server Catalog Groups tab provides a mechanism to easily retrieve group
information from an LDAP server and add it to the server’s Secure Access server catalog.
You specify the BaseDN of your groups and optionally a filter to begin the search. If
you do not know the exact container of your groups, you can specify the domain root
as the BaseDN, such as dc=juniper, dc=com.The search page returns a list of groups
from your server, from which you can choose groups to enter into the Groups list.
NOTE: The BaseDN value specified in the LDAP server’s configuration page
under "Finding user entries" is the default BaseDN value. The Filter value
defaults to (cn=*).
You can also use the Groups tab to specify groups. You must specify the Fully Qualified
Distinguished Name (FQDN) of a group, such as cn=GoodManagers, ou=HQ, ou=Juniper,
o=com, c=US, but you can assign a label for this group that appears in the Groups list.
Note that this tab is accessible only when accessing the Server Catalog of an LDAP
server.
Copyright © 2011, Juniper Networks, Inc.
219
Secure Access Administration Guide
•
Expressions—The Server Catalog Expressions tab provides a mechanism to write
custom expressions for the role mapping rule.
To display the LDAP server catalog:
•
After choosing the User attribute option on the Role Mapping Rule page, click Update
to display the Attribute list and the Attributes button.
•
Click the Attributes button to display the LDAP server catalog. (You can also click
Groups after choosing the Group membership option, or click Expressions after choosing
the Custom Expressions option.)
Figure 10: Server Catalog > Attributes Tab — Adding an Attribute for LDAP
220
Copyright © 2011, Juniper Networks, Inc.
Chapter 9: Authentication Realms
Figure 11: Server Catalog > Groups Tab — Adding LDAP Groups
Copyright © 2011, Juniper Networks, Inc.
221
Secure Access Administration Guide
222
Copyright © 2011, Juniper Networks, Inc.
Chapter 9: Authentication Realms
Figure 12: Server Catalog > Groups Tab — Adding Active Directory Groups
Related
Documentation
•
Specifying Role Mapping Rules for an Authentication Realm on page 217
•
Custom Expressions on page 1005
Customizing User Realm UI Views
You can use customization options on the User Authentication Realms page to quickly
view the settings that are associated with a specific realm or set of realms. For instance,
you can view the role-mapping rules that you have associated with all your user realms.
Copyright © 2011, Juniper Networks, Inc.
223
Secure Access Administration Guide
Additionally, you can use these customized views to easily link to the authentication
policies, servers, role-mapping rules, and roles associated with a user realms.
To view a sub-set of data on the User Authentication Realms page:
1.
Select one of the following options from the View menu:
•
Overview—Displays the authentication servers and dynamic policy evaluation
settings that you have set for the specified user realms. You may also use this setting
to link to the specified server configuration pages.
•
Authentication Policy—Displays Host Checker and Cache Cleaner restrictions that
you have enabled for the specified user realms. You may also use this setting to link
to the specified Host Checker and Cache Cleaner configuration pages.
•
Role Mapping—Displays rule conditions and corresponding role assignments that
you have enabled for the specified user realms. You may also use this setting to link
to the specified rule conditions and role assignments configuration pages.
•
Servers—Displays authentication server names and corresponding types that you
have enabled for the specified user realms. You may also use this setting to link to
the specified server configuration pages.
•
Roles—Displays role assignments and corresponding permissive merge settings
that you have enabled for the specified user realms.
2. Select one of the following options from the for list:
•
All realms—Displays the selected settings for all user realms.
•
Selected realms—Displays the selected settings for the user realms you choose. If
you select this option, select one or more of the check boxes in the Authentication
Realm list.
3. Click Update.
224
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 10
Sign-In Policies
•
About Sign-In Policies on page 225
•
Task Summary: Configuring Sign In Pages on page 228
•
About Configuring Sign In Policies on page 228
•
Configuring User Sign In Policies on page 228
•
Defining authorization-only access policies on page 231
•
Defining Meeting Sign-In Policies on page 233
•
Configuring Sign-In pages on page 234
About Sign-In Policies
Sign-in policies define the URLs that users and administrators use to access the SA and
the sign-in pages that they see. The SA has two types of sign-in policies—one for users
and one for administrators. When configuring sign-in policies, you associate realms,
sign-in pages, and URLs.
For example, in order to allow all users to sign in to the SA, you must add all user
authentication realms to the user sign-in policy. You may also choose to modify the
standard URL that the end-users use to access the SA and the sign-in page that they
see. Or, if you have the proper license, you can create multiple user sign-in policies,
enabling different users to sign into different URLs and pages.
Additionally, appliances equipped with a Secure Meeting license come with a meeting
URL. You can use this URL to control the sign-in page that users see when they sign into
a meeting on the SA appliance. If you have the proper license, you may also create
additional meeting sign-in pages, enabling different Secure Meeting users to sign into
different URLs and pages.
You can create multiple sign-in policies, associating different sign-in pages with different
URLs. When configuring a sign-in policy, you must associate it with a realm or realms.
Then, only members of the specified authentication realm(s) may sign in using the URL
defined in the policy. Within the sign-in policy, you may also define different sign-in pages
to associate with different URLs.
Copyright © 2011, Juniper Networks, Inc.
225
Secure Access Administration Guide
For example, you can create sign-in policies that specify:
•
Members of the “Partners” realm can sign in to the SA using the URLs:
partner1.yourcompany.com and partner2.yourcompany.com. Users who sign into the
first URL see the “partners1” sign-in page; users who sign into the second URL see the
“partners2” sign-in page.
•
Members of the “Local” and “Remote” realms can sign into the SA using the URL:
employees.yourcompany.com. When they do, they see the “Employees” sign-in page.
•
Members of the “Admin Users” realm can sign into the SA using the URL:
access.yourcompany.com/super. When they do, they see the “Administrators” sign-in
page.
When defining sign-in policies, you may use different host names (such as
partners.yourcompany.com and employees.yourcompany.com) or different paths
(such as yourcompany.com/partners and yourcompany.com/employees) to
differentiate between URLs.
NOTE: If a user attempts to sign in while there is another active user session
with the same sign-in credentials, the SA displays a warning page showing
the IP address of the existing session and two buttons: Continue and Cancel.
By clicking the Cancel button, the user terminates the current sign-in process
and redirects the user back to the Sign-in page. By clicking the Continue
button, the SA creates the new user session and terminates the existing
session.
226
Copyright © 2011, Juniper Networks, Inc.
Chapter 10: Sign-In Policies
NOTE: When enabling multiple sign-in URLs, note that in some cases the SA
must use cookies on the user’s machine to determine which sign-in URL and
corresponding sign-in page to display to the user. The SA creates these
cookies when the user signs into the SA. (When a user signs into the SA, the
SA responds with a cookie that includes the sign-in domain of the URL. The
SA then attaches this cookie to every SA request the user makes.) Generally,
these cookies ensure that the SA displays the correct sign-in URL and page
to the user. For example, if a user signs into the SA using the URL
http://yourcompany.net/employees and then her session times out, the SA
uses the cookie to determine that it must display the
http://yourcompany.net/employees sign-in URL and corresponding page
to the user when she requests another SA resource.
However, in isolated cases, the cookie on the user’s machine may not match
the resource she is trying to access. The user may sign into one URL and then
try to access a resource that is protected by a different URL. In this case, the
SA displays the sign-in URL and corresponding sign-in page that the user
signed into most recently. For example, a user may sign into the SA using the
sign-in URL http://yourcompany.net/employees. Then she may try to access
an SA resource using a link on an external server, such as
https://yourcompany.net/partners/dana/term/winlaunchterm.cgi?host=<termsrvIP>.
Or, she may try to open a bookmark that she created during a different session,
such as
https://yourcompany.net/partners/,DanaInfo=.awxyBmszGr3xt1r5O3v.,SSO=U+.
In these cases, the SA would display the http://yourcompany.net/employees
sign-in URL and page to the user, rather than the sign-in URL or page that is
associated with the external link or saved bookmark that she is trying to
access.
Sign-in policies and pages are an integral part of the SA access management framework,
and therefore are available on all Secure Access products. However, note that the
following advanced sign-in features are not available on the SA 700:
Related
Documentation
•
The ability to create multiple sign-in policies.
•
The ability to create sign-in pages for Secure Meeting users.
•
The ability to create and upload custom sign-in pages to the SA.
•
Task Summary: Configuring Sign In Pages on page 228
•
Defining Meeting Sign-In Policies on page 233
•
Configuring User Sign In Policies on page 228
Copyright © 2011, Juniper Networks, Inc.
227
Secure Access Administration Guide
Task Summary: Configuring Sign In Pages
To configure sign-in policies, you must:
1.
Create an authentication realm through the Administrators > Admin Realms or the
Users > User Realms page of the admin console.
2. (Optional) Modify an existing sign-in page or create a new one using options in the
Authentication > Signing In > Sign-in Pages page of the admin console.
3. (Optional) Modify an existing sign-in page or create a new one using options in the
Authentication > Signing In > Sign-in Pages page of the admin console.
4. Specify a sign-in policy that associates a realm, sign-in URL, and sign-in page using
settings in the Authentication > Signing In > Sign-in Policies page of the admin console.
5. If you differentiate between URLs using host names, you must associate each host
name with its own certificate or upload a wildcard certificate into Secure Access using
options in the System > Configuration > Certificates > Device Certificates page.
Related
Documentation
•
About Configuring Sign In Policies on page 228
•
Configuring User Sign In Policies on page 228
•
Defining Meeting Sign-In Policies on page 233
About Configuring Sign In Policies
User sign-in policies also determine the realm(s) that users and administrators can
access.
Depending on whether a sign-in policy is for endpoints (users) or administrators, the
configuration options are different. For users, different authentication protocol sets can
be configured, and realm selection is based on the authentication method that is
associated with the realm.
Related
Documentation
•
Configuring User Sign In Policies on page 228
•
Defining Meeting Sign-In Policies on page 233
•
Configuring User Sign In Policies on page 228
Configuring User Sign In Policies
To create or configure user sign-in policies:
1.
In the admin console, select Authentication > Signing In > Sign-in Policies.
2. To create a new sign-in policy, click New URL. Or, to edit an existing policy, click a URL
in the Administrator URLs or User URLs column.
228
Copyright © 2011, Juniper Networks, Inc.
Chapter 10: Sign-In Policies
3. Select Users or Administrators to specify which type of user can sign into Secure
Access using the access policy.
4. In the Sign-in URL field, enter the URL that you want to associate with the policy. Use
the format <host>/<path> where <host> is the host name of the Secure Access
device, and <path> is any string you want users to enter. For example:
partner1.yourcompany.com/outside. To specify multiple hosts, use the * wildcard
character.
To specify that all administrator URLs should use the sign-in page, enter */admin.
NOTE: You may only use wildcard characters (*) in the beginning of the
host name portion of the URL. Secure Access does not recognize wildcards
in the URL path.
5. (optional) Enter a Description for the policy.
6. From the Sign-in Page list, select the sign-in page that you want to associate with the
policy. You may select the default page that comes with Secure Access, a variation
of the standard sign-in page, or a custom page that you create using the customizable
UI feature.
7. (User URLs only) In the Meeting URL field, select the meeting URL that you want to
associate with this sign-in policy. Secure Access applies the specified meeting URL
to any meeting created by a user who signs into this user URL.
8. Under Authentication realm, specify which realm(s) map to the policy, and how users
and administrators should pick from amongst realms. If you select:
•
User types the realm name—Secure Access maps the sign-in policy to all
authentication realms, but does not provide a list of realms from which the user or
administrator can choose. Instead, the user or administrator must manually enter
his realm name into the sign-in page.
•
User picks from a list of authentication realms—Secure Access only maps the sign-in
policy to the authentication realms that you choose. Secure Access presents this
list of realms to the user or administrator when he signs-in to Secure Access and
allows him to choose a realm from the list. (Note that Secure Access does not
display a drop-down list of authentication realms if the URL is only mapped to one
realm. Instead, it automatically uses the realm you specify.)
NOTE: If you allow the user to pick from multiple realms and one of
those realms uses an anonymous authentication server, Secure Access
does not display that realm in the drop-down realm list. To effectively
map your sign-in policy to an anonymous realm, you must add only that
realm to the Authentication realm list.
9. Click Save Changes.
Enabling and Disabling Sign-In Policies
Copyright © 2011, Juniper Networks, Inc.
229
Secure Access Administration Guide
To enable and disable sign-in policies:
1.
In the admin console, choose Authentication > Signing In > Sign-in Policies.
2. To enable or disable:
•
An individual policy—Select the check box next to the policy that you want to
change, and then click Enable or Disable.
•
All user and meeting policies—Select or deselect the Restrict access to
administrators only check box at the top of the page.
3. Click Save Changes.
Specifying the Order in Which Sign-In Policies are Evaluated
Secure Access evaluates sign-in policies in the same order that you list them on the
Sign-in Policies page. When it finds a URL that matches exactly, it stops evaluating and
presents the appropriate sign-in page to the administrator or user. For example, you may
define two administrator sign-in policies with two different URLs:
•
The first policy uses the URL */admin and maps to the default administrator sign-in
page.
•
The second policy uses the URL yourcompany.com/admin and maps to a custom
administrator sign-in page.
If you list the policies in this order on the Sign-in Policies page, Secure Access never
evaluates or uses the second policy because the first URL encompasses the second.
Even if an administrator signs in using the yourcompany.com/admin URL, Secure Access
displays the default administrator sign-in page. If you list the policies in the opposite
order, however, Secure Access displays the custom administrator sign-in page to those
administrators who access Secure Access using the yourcompany.com/admin URL.
Note that Secure Access only accepts wildcard characters in the host name section of
the URL and matches URLs based on the exact path. For example, you may define two
administrator sign-in policies with two different URL paths:
•
The first policy uses the URL */marketing and maps to a custom sign-in page for the
entire Marketing Department.
•
The second policy uses the URL */marketing/joe and maps to a custom sign-in page
designed exclusively for Joe in the Marketing Department.
If you list the policies in this order on the Sign-in Policies page, Secure Access displays
Joe’s custom sign-in page to him when he uses the yourcompany.com/marketing/joe
URL to access Secure Access. He does not see the Marketing sign-in page, even though
it is listed and evaluated first, because the path portion of his URL does not exactly match
the URL defined in the first policy.
To change the order in which administrator sign-in policies are evaluated:
1.
In the admin console, choose Authentication > Signing In > Sign-in Policies.
2. Select a sign-in policy in the Administrator URLs , User URLs or Meeting URLs list.
230
Copyright © 2011, Juniper Networks, Inc.
Chapter 10: Sign-In Policies
3. Click the up and down arrows to change the selected policy’s placement in the list.
4. Click Save Changes.
Related
Documentation
•
About Configuring Sign In Policies on page 228
Defining authorization-only access policies
Authorization-only access is similar to a reverse proxy. Typically, a reverse proxy is a proxy
server that is installed in front of webservers. All connections coming from the Internet
addressed to one of the webservers are routed through the proxy server, which may either
deal with the request itself or pass the request wholly or partially to the main webserver.
Up to 1000 concurrent connections is supported on an SA 6500.
With an authorization-only access, you select a user role. Secure Access then acts as
reverse proxy server and performs authorization against the Netegrity SiteMinder server
for each request.
For example, the authorization-only access feature satisfies the following business needs:
•
If you have a third-party AAA policy management server (like Netegrity), Secure Access
acts as an authorization-only agent.
•
If your user sessions are managed by a third-part session management system, there
is no need to duplicate the user session management in Secure Access.
With authorization-only access, there is no SSO from Secure Access. SSO is controlled
by your third-party AAA infrastructure.
NOTE: Before defining this policy, you must first configure your Netegrity
server and define your hostnames in the Network Configuration page.
You must also specify settings in the SiteMinder authorization settings section
of the SiteMinder authentication server page. Users are redirected to the URL
specified in the If Automatic Sign In fails, redirect to field when the
SMSESSION cookie validation fails or if no SMSESSION cookie exists. Users
are redirected to the URL specified in the If authorization fails, redirect to field
when an access denied error occurs.
To create or configure authorization-only access policies:
1.
In the admin console, choose Authentication > Signing In > Sign-in Policies.
2. To create a new authorization only access policy, click New URL and select
authorization only access. Or, to edit an existing policy, click a URL in the Virtual
Hostname column.
3. In the Virtual Hostname field, enter the name that maps to Secure Access’s IP address.
The name must be unique among all virtual hostnames used in pass-through proxy’s
Copyright © 2011, Juniper Networks, Inc.
231
Secure Access Administration Guide
hostname mode. The hostname is used to access backend application entered in the
Backend URL field. Do not include the protocol (for example, http:) in this field.
For example, if the virtual hostname is myapp.ivehostname.com, and the backend
URL is http://www.xyz.com:8080/, a request to https://myapp.ivehostname.com/test1
via Secure Access is converted to a request to http://www.xyz.com:8080/test1. The
response of the converted request is sent to the original requesting web browser.
4. In the Backend URL field, enter the URL for the remote server. You must specify the
protocol, hostname and port of the server. For example,
http://www.mydomain.com:8080/*.
When requests match the hostname in the Virtual Hostname field, the request is
transformed to the URL specified in the Backend URL field. The client is directed to
the backend URL unaware of the redirect.
5. (optional) Enter a Description for this policy.
6. Select the server name or No Authorization from the Authorization Server drop down
menu. If you select a server, ensure that the front-end server provides the SMSESSION
cookie otherwise you will receive an error.
7. Select a user role from the Role Option drop down menu.
Only the following user role options are applicable for authorization-only access.
•
Allow browsing un-trusted SSL websites (Users > User Roles > RoleName > Web
> Options > View advanced options)
•
HTTP Connection Timeout (Users > User Roles > RoleName > Web > Options >
View advanced options)
•
Source IP restrictions (Users > User Roles > RoleName > General > Restrictions)
•
Browser restrictions (Users > User Roles > RoleName > General > Restrictions)
Ensure the user role you select has an associated Web Access policy.
8. Select the Allow ActiveSync Traffic only option to perform a basic of validation of
the HTTP header to ensure the request is consistent with ActiveSync protocol. If you
select this option only ActiveSync protocol requests can be processed. If validation
fails, a message is created in the user’s event log. If you do not select this option, both
ActiveSync and non-ActiveSync requests are processed.
9. Click Save Changes to save your edits.
The System Status Overview page displays the number of current active concurrent
connections and a histogram of the active concurrent connections (Authorization Only
Access Active Connections plot in the Concurrent SSL Connections graph).
Related
Documentation
232
•
eTrust SiteMinder Overview on page 183
•
Specifying Web Browsing Options on page 410
•
Specifying Browser Access Restrictions on page 67
Copyright © 2011, Juniper Networks, Inc.
Chapter 10: Sign-In Policies
Defining Meeting Sign-In Policies
To create or configure meeting sign-in policies:
1.
In the admin console, choose Authentication > Authentication > Signing In Policies.
2. To create a new sign-in policy, click New URL. Or, to edit an existing policy, click a URL
in the Meeting URLs column.
3. Select Meeting.
4. In the Sign-in URL field, enter the URL that you want to associate with the meeting
policy. Use the format <host>/<path> where <host> is the host name of the Secure
Access device, and <path> is any string you want users to enter. For example:
Partner1.YourCompany.com/OnlineConference. When creating the meeting URL, note
that:
•
You cannot modify the URL of the default meeting URL (*/meeting) that comes
with the product.
•
If you want to enable users to sign into meetings using all of the host names defined
in the associated user URL, use the * wildcard character in your meeting URL
definition. For example, you might associate the following hosts with your user URL:
•
YourInternalServer.YourCompany.net
•
YourExternalServer.YourCompany.com
Then, if you create an */OnlineConference meeting URL definition and associate it
with the user URL, users can access the meeting sign-in page using either of the
following URLs:
•
•
http://YourInternalServer.YourCompany.net/OnlineConference
•
http://YourExternalServer.YourCompany.com/OnlineConference
If you create a meeting URL that includes the * wildcard character and enable email
notifications, Secure Access constructs the meeting URL in the notification email
using the host name specified by the user when signing into Secure Access. For
instance, a user might sign into Secure Access using the following URL from the
previous example:
http://YourInternalServer.YourCompany.net
Then, if the user creates a meeting, Secure Access specifies the following sign-in
URL for that meeting in the email notification:
http://YourInternalServer.YourCompany.net/OnlineConference
Note that since the email link references an internal server, out-of-network users
cannot access the meeting.
•
If you only want to enable users to sign into meetings using a sub-set of the host
names defined in the associated user URL, or if you want to require users to use a
completely different URL to sign into meetings, do not include the * wildcard
Copyright © 2011, Juniper Networks, Inc.
233
Secure Access Administration Guide
character in your meeting URL definition. Instead, create a unique and specific
meeting URL definition.
For instance, you can create the following meeting URL definition and associate it
with the user URL from the previous example in order to specify that all meetings
contain links to the external server only:
YourExternalServer.YourCompany.com/OnlineConference
5. (optional) Enter a Description for the policy.
6. From the Sign-in Page list, select the sign-in page(s) that you want to appear to users
who access meetings using this policy. You may select the default pages that come
with Secure Access, a variation of the standard sign-in pages, or customized pages
that you create using the customizable UI feature.
7. Click Save Changes.
Related
Documentation
•
Configuring Sign-In pages on page 234
Configuring Sign-In pages
A sign-in page defines the customized properties in the end-user’s welcome page such
as the welcome text, help text, logo, header, and footer. The SA allows you to create two
types of sign-in pages to present to users and administrators:
•
Standard sign-in pages—Standard sign-in pages are produced by Juniper and are
included with all versions of the SA. You can modify standard sign-in pages through
the Authentication > Signing In > Sign-in Pages tab of the admin console.
•
Customized sign-in pages—Customized sign-in pages are THTML pages that you
produce using the Template Toolkit and upload to the SA in the form of an archived
ZIP file. The customized sign-in pages feature enables you to use your own pages rather
than having to modify the sign-in page included with the SA.
For more information on customized sign-in pages, see the Custom Sign-In Pages Solution
Guide.
Configuring Standard Sign-In Pages
Standard sign-in pages that come with the SA include:
•
Default Sign-In Page—the SA displays this page to users when they sign into the SA.
•
Meeting Sign-In Page—the SA displays this page to users when they sign into a meeting.
This page is only available if you install a Secure Meeting license on the SA.
You can modify the default sign-in page that the SA displays to users when they sign
into the SA. You can also create new standard signin pages that contain custom text,
logo, colors, and error message text using settings in the Authentication > Signing In >
Sign-in Pages tab of the admin console.
234
Copyright © 2011, Juniper Networks, Inc.
Chapter 10: Sign-In Policies
To create or modify a standard sign-in page:
1.
In the admin console, select Authentication > Signing In > Sign-in Pages.
2. If you are:
•
Creating a new page—Click New Page.
•
Modifying an existing page—Select the link corresponding to the page you want
to modify.
3. (New pages only) Under Page Type, specify whether this is an administrator/user
access page or a meeting page.
4. Enter a name to identify the page.
5. In the Custom text section, revise the default text used for the various screen labels
as desired. When adding text to the Instructions field, note that you may format text
and add links using the following HTML tags: <i>, <b>, <br>, <font>, and <ahref>.
However, the SA does not rewrite links on the sign-in page (since the user has not yet
authenticated), so you should only point to external sites. Links to sites behind a
firewall will fail.
If you use unsupported HTML tags in your custom message, the SA may display the
end-user’s SA home page incorrectly.
6. In the Header appearance section, specify a custom logo image file for the header
and a different header color.
7. In the Custom error messages section, revise the default text that is displayed to users
if they encounter certificate errors.
You can include <<host>>, <<port>>, <<protocol>>, and <<request>> variables and
user attribute variables, such as <<userAttr.cn>> in the custom error messages. Note
that these variables must follow the format <variable> to distinguish them from HTML
tags which have the format <tag>.
8. To provide custom help or additional instructions for your users, select Show Help
button, enter a label to display on the button, and specify an HTML file to upload to
the SA. Note that the SA does not display images and other content referenced in this
HTML page. (Not available for the Secure Meeting sign-in page.)
9. Click Save Changes. The changes take effect immediately, but users with active
sessions might need to refresh their Web browsers.
Click Restore Factory Defaults to reset the sign-in page, SA user home page, and admin
console appearance.
Copyright © 2011, Juniper Networks, Inc.
235
Secure Access Administration Guide
236
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 11
Single Sign-On
•
About Single Sign-On on page 237
•
Task Summary: Configuring Multiple Authentication Servers on page 239
•
Task Summary: Enabling SSO to Resources Protected by Basic
Authentication on page 239
•
Task Summary: Enabling SSO to Resources Protected by NTLM on page 240
•
Multiple Sign-In Credentials Execution on page 241
•
Configuring SAML on page 246
•
Configuring SAML SSO Profiles on page 249
•
Creating a Single Sign-On POST Profile on page 253
•
Creating a SAM Access Control Resource Policy on page 256
•
Creating a Trust Relationship Between SAML-Enabled Systems on page 259
About Single Sign-On
Single sign-on (SSO) is a process that allows pre-authenticated Secure Access users to
access other applications or resources that are protected by another access management
system without having to re-enter their credentials.
Secure Access provides several integration mechanisms that allow you to configure SSO
connections from the Secure Access to other servers, applications, and resources. SSO
mechanisms include:
•
Remote SSO—Secure Access provides loose integration with any application that uses
a static POST action within an HTML form to sign in users. You can configure Secure
Access to post Secure Access credentials, LDAP attributes, and certificate attributes
to a Web-enabled application, as well as set cookies and headers, allowing users to
access the application without re-authenticating.
•
SAML—Secure Access provides loose integration with selected access management
systems that use the Security Assertion Markup Language (SAML) to communicate
with other systems. You can enable users to sign in to Secure Access and then sign in
to and access resources protected by the access management system without
re-authenticating. You can also enable users to sign in to another access management
system and then access resources protected by Secure Access, without
re-authenticating.
Copyright © 2011, Juniper Networks, Inc.
237
Secure Access Administration Guide
•
Basic authentication and NTLM intermediation to Intranet sites—Secure Access allows
you to automatically submit Secure Access user credentials to other Web sites and
proxies within the same Intranet zone. When you enable basic authentication
intermediation through the Users > Resource Profiles > Web Applications/Pages page
of the admin console, Secure Access submits the cached credentials to Intranet Web
sites whose host names end in the DNS suffix configured in the System > Network >
Overview page. To maximize security, you may also configure Secure Access to use
base-64 encoding to protect the cached credentials.
•
Active Directory server—Secure Access allows you to automatically submit Active
Directory SSO credentials to other Web sites and Windows file shares within the same
Intranet zone that are protected by native NTLM authentication. When you enable this
option, Secure Access submits cached credentials to NTLM-protected Web sites whose
host names end in the DNS suffix configured in the System > Network > Overview page
of the admin console.
•
eTrust SiteMinder policy server—When you authenticate Secure Access users using a
eTrust SiteMinder policy server, you can enable them access to SiteMinder protected
resources without re-authenticating (provided they are authorized with the correct
protection level). Additionally, you can re-authenticate users through Secure Access
if they request resources for which their current protection level is inadequate and you
can enable users to sign into the policy server first and then access Secure Access
without re-authenticating.
•
Terminal Sessions—When you enable the Terminal Services feature for a role, you
allow users to connect to applications that are running on a Windows terminal server
or Citrix MetaFrame server without re-authenticating. You may also pass a username
to the Telnet/SSH server.
•
Email clients—When you enable the Email Client feature for a role and then create a
corresponding resource policy, you allow users to access standards-based email such
as Outlook Express, Netscape Communicator, or Qualcomm’s Eudora without
re-authenticating.
Secure Access determines which credentials to submit to the SSO-enabled server,
application, or resource based on the mechanism you use to connect. Most mechanisms
allow you to collect user credentials for up to two authentication servers in the Secure
Access sign-in page and then submit those credentials during SSO.
The remaining mechanisms (SAML, eTrust SiteMinder, and the Email Client) use unique
methods for enabling SSO from Secure Access to the supported application.
About Multiple Sign-In Credentials
When configuring an authentication realm, you can enable up to two authentication
servers for the realm. Enabling two authentication servers allows you to require two
different sets of credentials—one for Secure Access and another for your SSO-enabled
resource—without requiring the user to enter the second set of credentials when accessing
the resource. It also allows you to require two-factor authentication in order to access
Secure Access.
238
Copyright © 2011, Juniper Networks, Inc.
Chapter 11: Single Sign-On
Related
Documentation
•
Remote SSO Overview on page 387
•
Configuring SAML on page 246
•
Defining a Single Sign-On Autopolicy on page 395
•
Defining an Active Directory or Windows NT Domain Server Instance on page 146
•
eTrust SiteMinder Overview on page 183
•
About Terminal services on page 544
•
About the Email Client on page 617
•
Multiple Sign-In Credentials Execution on page 241
Task Summary: Configuring Multiple Authentication Servers
To enable multiple authentication servers:
1.
Create authentication server instances through the Authentication > Auth. Servers
page of the admin console.
2. Associate the authentication servers with a realm using settings in the following pages
of the admin console:
•
Users > User Realms > Select Realm> General
•
Administrators > Admin Realms > Select Realm > General
3. (Optional) Specify password length restrictions for the secondary authentication
server using settings in the following pages of the admin console:
Related
Documentation
•
Users > User Realms > Select Realm > Authentication Policy > Password
•
Administrators > Admin Realms > Select Realm > Authentication Policy > Password
•
Authentication Realm Overview on page 213
•
Specifying Password Access Restrictions on page 70
Task Summary: Enabling SSO to Resources Protected by Basic Authentication
To enable single sign-on to Web servers and Web proxies that are protected by basic
authentication, you must:
1.
Specify a Secure Access host name that ends with the same prefix as your protected
resource using settings in the System > Network > Overview page of the admin console.
(Secure Access checks the host names to ensure that it is only enabling SSO to sites
within the same Intranet.)
2. Enable users to access Web resources, specify the sites to which you want Secure
Access to submit credentials, create autopolicies that enable basic authentication
intermediation single sign-on, and create bookmarks to the selected resources using
Copyright © 2011, Juniper Networks, Inc.
239
Secure Access Administration Guide
settings in the Users > Resource Profiles > Web Application/Pages > [Profile] page
of the admin console.
3. If you want users to access Web servers through a proxy, configure Secure Access to
recognize the appropriate servers and proxies using settings in the following pages of
the admin console:
Related
Documentation
•
•
Use settings in Users > Resource Policies > Web > Web proxy > Servers page to
specify which Web servers you want to protect with the proxy.
•
Use settings in the Users > Resource Policies > Web > Web proxy > Policies page
to specify which proxies you want to use and which servers (above) you want the
proxies to protect. You may specify individual resources on the server or the entire
server.
Task Summary: Enabling SSO to Resources Protected by NTLM on page 240
Task Summary: Enabling SSO to Resources Protected by NTLM
NOTE: Secure Access supports web proxies that perform NTLM
authentication. However, the following case is not supported: a proxy exists
between Secure Access and the back-end server and the back-end server
performs the NTLM authentication.
To enable single sign-on to Web servers, Windows file servers, and Web proxies that are
protected by NTLM, you must:
1.
Specify a Secure Access host name that ends with the same suffix as your protected
resource using settings in the System > Network > Overview page of the admin console.
(Secure Access checks the host names to ensure that it is only enabling SSO to sites
within the same Intranet.)
2. Enable users to access the appropriate type of resource (Web or file), specify the sites
or servers to which you want the SA Series Appliance to submit credentials, create
autopolicies that enable NTLM single sign-on, and create bookmarks to the selected
resources using settings in the following pages of the admin console:
•
Users > Resource Profiles > Web Application/Pages > [Profile]
•
Users > Resource Profiles > File Browsing Resource Profiles> [Profile]
3. If you want users to access Web servers through a proxy, configure Secure Access to
recognize the appropriate servers and proxies using settings in the following pages of
the admin console:
a. Use settings in Users > Resource Policies > Web > Web proxy > Servers page to
specify which Web servers you want to protect with the proxy.
b. Use settings in the Users > Resource Policies > Web > Web proxy > Policies page
to specify which proxies you want to use and which servers (above) you want the
240
Copyright © 2011, Juniper Networks, Inc.
Chapter 11: Single Sign-On
proxies to protect. You may specify individual resources on the server or the entire
server.
Related
Documentation
•
Task Summary: Enabling SSO to Resources Protected by Basic Authentication on
page 239
Multiple Sign-In Credentials Execution
The following diagram illustrates the process that Secure Access uses to collect and
authenticate multiple user credentials and submit them to SSO-enabled resources. Each
of the steps in the diagram are described in further detail in the sections that follow.
Figure 13: Collecting and Submitting Credentials from Multiple Servers
Step 1: Secure Access Collects the User’s Primary Credentials
When the user signs in to Secure Access, Secure Access prompts him to enter his primary
server credentials. Secure Access saves these credentials to submit to the SSO resource
later, if necessary. Note that Secure Access saves the credentials exactly as the user
Copyright © 2011, Juniper Networks, Inc.
241
Secure Access Administration Guide
enters them—it does not pre-pend or append them with additional information such as
the user’s domain.
Step 2: Secure Access Collects or Generates the User’s Secondary Credentials
You may configure Secure Access to either manually collect or automatically generate
the user’s secondary set of credentials. If you configure Secure Access to:
•
Manually collect the user’s secondary credentials—The user must enter his secondary
credentials directly after entering his primary credentials.
•
Automatically generate the user’s credentials—Secure Access submits the values you
specified in the administration console during setup. By default, Secure Access uses
the <username> and <password> variables, which hold the username and passwod
entered by the user for the primary authentication server.
For example, you may configure an LDAP server as your primary authentication server
and an Active Directory server as your secondary authentication server. Then, you may
configure Secure Access to infer the user’s Active Directory username but require the
user to manually enter his Active Directory password. When Secure Access infers the
Active Directory username, it simply takes the name entered for the LDAP server (for
example, JDoe@LDAPServer) and resubmits it to the Active Directory (for example,
JDoe@ActiveDirectoryServer).
Step 3: Secure Access Authenticates the Primary Credentials
After Secure Access collects all required credentials, it authenticates the user’s first set
of credentials against the primary authentication server. Then:
•
If the credentials successfully authenticate, Secure Access stores them in the
<username> and <password> session variables and continues on to authenticate the
secondary credentials.
NOTE: If you authenticate against a RADIUS server that accepts dynamic,
time-sensitive passwords, you may choose to not store user passwords
using the Secure Access session variable.
•
If the credentials do not successfully authenticate, Secure Access denies the user
access to the Secure Access appliance.
Step 4: Secure Access Authenticates the Secondary Credentials
After authenticating the primary credentials, Secure Access authenticates the secondary
credentials. Then:
•
242
If the credentials successfully authenticate, Secure Access stores them in the
<username[2]> and <password[2]> session variables and allows the user access to
Secure Access. You may also access these variables using the syntax
<username@SecondaryServer> and <password@SecondaryServer>.
Copyright © 2011, Juniper Networks, Inc.
Chapter 11: Single Sign-On
NOTE: If you authenticate against a RADIUS server that accepts dynamic,
time-sensitive passwords, you may choose to not store user passwords
using the Secure Access session variable.
•
If the credentials do not successfully authenticate, Secure Access does not save them.
Depending on how you configure your authentication realm, Secure Access may allow
or deny the user access to Secure Access if his secondary credentials do not successfully
authenticate.
You can detect that secondary authentication failed by creating a custom expression
that checks for an empty user@secondaryAuth variable. You may want to do this so
that you can assign users to roles based on successful authentication. For example,
the following expression assigns users to the “MoreAccess” role if they successfully
authenticate against the “ACE server” secondary authentication server:
user@{ACE Server} != "" then assign role MoreAccess
Note “Ace server” is shown in curly braces since the authentication server’s name
contains spaces.
Step 5: Secure Access Submits Credentials to an SSO-Enabled Resource
After the user successfully signs in to Secure Access, he may try to access an SSO-enabled
resource using a pre-configured bookmark or other access mechanism. Then, depending
on which type of resource the user is trying to access, Secure Access submits different
credentials. If the user is trying to access a:
•
Web SSO, Terminal Services, or Telnet/SSH resource—Secure Access submits the
credentials that you specify through the admin console, such as <username> (which
submits the user’s primary credentials to the resource) or <username[2]> (which
submits the user’s secondary credentials to the resource). Or, if the user has entered
a different username and password through the end user console, Secure Access
submits the user-specified credentials.
NOTE: Secure Access does not support submitting ACE server, certificate
server, or anonymous server credentials to a Web SSO, terminal services,
or Telnet/SSH resource. If you configure Secure Access to submit
credentials from one of these types of primary authentication servers,
Secure Access submits credentials from the user’s secondary authentication
server instead. If these credentials fail, Secure Access prompts the user to
manually enter his username and password.
•
Resource protected by a Web server, Windows server, or Web proxy that is using NTLM
authentication—Secure Access submits credentials to the backend server or proxy
that is protecting the Web or file resource. Note that you cannot disable NTLM
authentication through Secure Access—If a user tries to access a resource that is
protected by NTLM, Secure Access automatically intermediates the authentication
challenge and submits credentials in the following order:
Copyright © 2011, Juniper Networks, Inc.
243
Secure Access Administration Guide
•
244
•
(Windows file resources only) Administrator-specified credentials—If you create a
resource profile that specifies credentials for a Windows file resource and the user
then accesses the specified resource, Secure Access submits the specified credentials.
•
Cached credentials—If Secure Access does not submit administrator-specified
credentials or the credentials fail, Secure Access determines whether it has stored
credentials for the specified user and resource in its cache. (See below for information
about when Secure Access caches credentials.) If available, Secure Access submits
its stored credentials.
•
Primary credentials—If Secure Access does not submit cached credentials or the
credentials fail, Secure Access submits the user’s primary Secure Access credentials
provided that following conditions are true:
•
The resource is in the same Intranet zone as Secure Access (that is, the resource’s
host name ends in the DNS suffix configured in the System > Network > Overview
page of the admin console).
•
(Web proxies only) You have configured Secure Access to recognize the Web
proxy through settings in the Users > Resource Policies > Web > Web Proxy pages
of the admin console.
•
The credentials are not ACE credentials.
•
(RADIUS credentials only) You specify in the RADIUS configuration page that the
RADIUS server does not accept one-time passwords.
•
Secondary credentials—If the primary credentials fail, Secure Access determines
whether it has secondary credentials for the user. If available, Secure Access submits
the user’s secondary Secure Access credentials provided that the conditions described
for primary credentials are true.
•
Last-entered credentials—If Secure Access does not submit secondary credentials
or if the credentials fail, Secure Access determines whether it has stored credentials
for the specified user and a different resource in its cache. (See below for information
about when Secure Access caches credentials.) If available, Secure Access submits
its stored credentials provided the conditions described for primary credentials are
true.
•
User-specified credentials (prompt)—If Secure Access does not submit last-entered
credentials or if the credentials fail, Secure Access prompts the user to manually
enter his credentials in the intermediate sign-in page. If the user selects the
“Remember password?” checkbox, Secure Access caches the user-specified
credentials and, if necessary, resubmits them when the user tries to access the same
resource again. Note that when Secure Access caches these credentials, it remembers
the specific user and resource, even after the user signs out of Secure Access.
Resource protected by a Web server or Web proxy using basic authentication—Secure
Access submits credentials in the following order to the backend server or proxy that
is protecting the Web resource:
Copyright © 2011, Juniper Networks, Inc.
Chapter 11: Single Sign-On
•
Cached credentials—If Secure Access does not submit administrator-specified
credentials or the credentials fail, Secure Access determines whether it has stored
credentials for the specified user and resource in its cache. If available, Secure Access
submits its stored credentials.
•
Primary credentials—If Secure Access does not submit cached credentials or the
credentials fail, Secure Access submits the user’s primary Secure Access credentials
provided that following conditions are true:
•
The resource is in the same Intranet zone as Secure Access (that is, the resource’s
host name ends in the DNS suffix configured in the System > Network > Overview
page of the admin console).
•
(Web proxies only) You have configured Secure Access to recognize the Web
proxy through settings in the Users > Resource Policies > Web > Web Proxy pages
of the admin console.
•
The credentials are not ACE credentials.
•
(RADIUS credentials only) You specify in the RADIUS configuration page that the
RADIUS server does not accept one-time passwords.
•
Secondary credentials—If the primary credentials fail, Secure Access determines
whether it has secondary credentials for the user. If available, Secure Access submits
the user’s secondary Secure Access credentials provided that the conditions described
for primary credentials are true.
•
Last-entered credentials—If Secure Access does not submit secondary credentials
or if the credentials fail, Secure Access determines whether it has stored credentials
for the specified user and a different resource in its cache. If available, Secure Access
submits its stored credentials provided the conditions described for primary
credentials are true.
•
User-specified credentials (prompt)—If Secure Access does not submit last-entered
credentials or if the credentials fail, Secure Access prompts the user to manually
enter his credentials in the intermediate sign-in page. If the user selects the
“Remember password?” checkbox, Secure Access caches the user-specified
credentials and, if necessary, resubmits them when the user tries to access the same
resource again. Note that when Secure Access caches these credentials, it remembers
the specific user and resource, even after the user signs out of Secure Access.
Copyright © 2011, Juniper Networks, Inc.
245
Secure Access Administration Guide
NOTE: Secure Access does not support the multiple credential
authentication mechanism described in this section with the Email client
and SAML SSO mechanisms.
You cannot define an anonymous server, certificate server, or eTrust
SiteMinder server as a secondary authentication server.
If you define an eTrust SiteMinder server as your primary authentication
server, you cannot define a secondary authentication server.
Secure Access supports basic authentication and NTLM
challenge/response scheme for HTTP when accessing web applications,
but does not support HTTP-based cross-platform authentication via the
negotiate protocol.
Related
Documentation
•
Configuring a RADIUS Server Instance on page 166
Configuring SAML
The SA Series Appliance enables you to pass user and session state information between
the SA Series Appliance and another trusted access management system that supports
the Secure Access Markup Language (SAML). SAML provides a mechanism for two
disparate systems to create and exchange authentication and authorization information
using an XML framework, minimizing the need for users to re-enter their credentials when
accessing multiple applications or domains. The SA Series Appliance supports SAML
version 1.1.
SAML exchanges are dependent upon a trusted relationship between two systems or
domains. In the exchanges, one system acts as a SAML authority (also called an asserting
party or SAML responder) that asserts information about the user. The other system acts
as a relying party (also called a SAML receiver) that relies on the statement (also called
an assertion) provided by the SAML authority. If it chooses to trust the SAML authority,
the relying party authenticates or authorizes the user based on the information provided
by the SAML authority.
The SA Series Appliance supports two SAML use case scenarios:
•
The SA Series Appliance as the SAML authority—The user signs into a resource by way
of the SA Series Appliance first, and all other systems are SAML receivers, relying on
the SA Series Appliance for authentication and authorization of the user. Under this
scenario, the SA Series Appliance can use either an artifact profile or a POST profile.
•
The SA Series Appliance as the SAML receiver—The user signs into another system on
the network first, and the SA Series Appliance is the SAML receiver, relying on the other
system for authentication and authorization of the user.
For example, in the first scenario, an authenticated SA Series Appliance user named John
Smith may try to access a resource protected by an access management system. When
246
Copyright © 2011, Juniper Networks, Inc.
Chapter 11: Single Sign-On
he does, the SA Series Appliance acts as a SAML authority and declares “This user is
John Smith. He was authenticated using a password mechanism.” The access
management system (the relying party) receives this statement and chooses to trust
the SA Series Appliance (and therefore trust that the SA Series Appliance has properly
identified the user). The access management system may still choose to deny the user
access to the requested resource (for instance, because John Smith has insufficient
access privileges on the system), while trusting the information sent by the SA Series
Appliance.
In the second scenario, John Smith signs in to his company portal and is authenticated
using an LDAP server sitting behind the company’s firewall. On the company’s secure
portal, John Smith clicks a link to a resource protected by the SA Series Appliance. The
following process occurs:
1.
The link redirects John Smith to an Intersite Transfer Service on the company portal,
which constructs an artifact URL. The artifact URL contains a reference to a SAML
assertion stored in the company portal’s cache.
2. The portal sends the URL to the SA Series Appliance, which can decide whether or
not to link to the reference.
3. If the SA Series Appliance links to the reference, the portal sends a SOAP message
containing the SAML assertion (an XML message containing the user’s credentials)
to the SA Series Appliance, which can then decide whether or not to allow the user
access to the requested resource.
4. If the SA Series Appliance allows the user access, the SA Series Appliance presents
to the user the requested resource.
5. If the SA Series Appliance rejects the SAML assertion, or the user credentials, the SA
Series Appliance responds to the user with an error message.
When configuring the SA Series Appliance, you can use SAML for:
•
Single sign-on (SSO) authentication—In a SAML SSO transaction, an authenticated
user is seamlessly signed into another system without re-submitting his credentials.
In this type of transaction, the SA Series Appliance can be either the SAML authority
or the SAML receiver. When acting as the SAML authority, the SA Series Appliance
makes an authentication statement, which declares the user’s username and how he
was authenticated. If the relying party (called an assertion consumer service in SAML
SSO transactions) chooses to trust the SA Series Appliance, the user is seamlessly
signed into the assertion consumer service using the username contained in the
statement.
When acting as the SAML receiver, the SA Series Appliance requests credential
confirmation from the SAML authority, which is the other access management system,
such as LDAP or another authentication server. The SAML authority sends an assertion
by way of a SOAP message. The assertion is a set of XML statements that the SA
Series Appliance must interpret, based on criteria that the SA Series Appliance
administrator has specified in a SAML server instance definition. If the SA Series
Appliance chooses to trust the asserting party, the SA Series Appliance allows the user
to sign in seamlessly using the credentials contained in the SAML assertion.
Copyright © 2011, Juniper Networks, Inc.
247
Secure Access Administration Guide
•
Access control authorization—In a SAML access control transaction, the SA Series
Appliance asks an access management system whether the user has access. In this
type of transaction, the SA Series Appliance is the relying party (also called a policy
enforcement point in access control transactions). It consumes and enforces an
authorization decision statement provided by the access management system (SAML
authority), which declares what the user is allowed to access. If the SAML authority
(also called a policy decision point in access control transactions) declares that the
SA Series Appliance user has sufficient access privileges, the user may access the
requested resource
NOTE: The SA Series Appliance does not support attribute statements,
which declare specific details about the user (such as “John Smith is a
member of the gold group”).
The SA Series Appliance does not generate authorization decision
statements—it only consumes them.
In addition to providing users access to a URL based on the authorization
decision statement returned by a SAML authority, the SA Series Appliance
also allows you to define users’ access rights to a URL using SA Series
Appliance-only mechanisms (Users > Resource Profiles > Web
Applications/Pages tab). If you define access controls through the SA
Series Appliance as well as through a SAML authority, both sources must
grant access to a URL in order for a user to access it. For example, you may
configure an SA Series Appliance access policy that denies members of
the “Users” role access to www.google.com, but configure another SAML
policy that bases a user’s access rights on an attribute in an access
management system. Even if the access management system permits
users access to www.google.com, users are still denied access based on
the SA Series Appliance access policy.
When asked if a user may access a resource, access management systems
that support SAML may return a response of permit, deny, or indeterminate.
If the SA Series Appliance receives an indeterminate response, it denies
the user access.
The session timeouts on the SA Series Appliance and your access
management system may not coordinate with one another. If a user’s
access management system session cookie times out before his SA Series
Appliance cookie (DSIDcookie) times out, then single sign-on between the
two systems is lost. The user is forced to sign in again when he times out
of the access management system.
Related
Documentation
248
•
Configuring SAML SSO Profiles on page 249
Copyright © 2011, Juniper Networks, Inc.
Chapter 11: Single Sign-On
Configuring SAML SSO Profiles
When enabling SSO transactions to a trusted access management system, you must
indicate whether the access management system should “pull” user information from
Secure Access or whether Secure Access should “push” it to the access management
system. You indicate which communication method the two systems should use by
selecting a profile during configuration. A profile is a method that two trusted sites use
to transfer a SAML statement. When configuring Secure Access, you may choose to use
an artifact or POST profile.
When you choose to communicate using the artifact profile (also called Browser/Artifact
profile) the trusted access management server “pulls” authentication information from
Secure Access.
Figure 14: Artifact Profile
Secure Access and an assertion consumer service (ACS) use the following process to
pass information:
1.
The user tries to access a resource—A user is signed into Secure Access and tries to
access a protected resource on a Web server.
2. Secure Access sends an HTTP or HTTPS GET request to the ACS—Secure Access
intercepts the request and checks whether it has already performed the necessary
SSO operation to honor the request. If not, Secure Access creates an authentication
statement and passes an HTTP query variable called an artifact to the assertion
consumer service.
An artifact profile is a base-64 encoded string that contains the source ID of the source
site (that is, a 20-byte string that references Secure Access) and a randomly-generated
string that acts as a handle to the authentication statement. (Note that a handle
expires 5 minutes after the artifact is sent, so if the assertion consumer service responds
after 5 minutes, Secure Access does not send a statement. Also note that Secure
Access discards a handle after its first use to prevent the handle from being used
twice.)
3. The ACS sends a SAML request to Secure Access—The assertion consumer service
uses the source ID sent in the previous step to determine the location of Secure Access.
Then, the assertion consumer service sends a statement request wrapped in a SOAP
message to the following address on Secure Access:
Copyright © 2011, Juniper Networks, Inc.
249
Secure Access Administration Guide
https://<<ivehostname>/danaws/saml.ws
The request includes the statement handle passed in the previous step.
NOTE: Secure Access only supports type 0x0001 artifacts. This type of
artifact passes a reference to the source site’s location (that is, the source
ID of the Secure Access appliance), rather than sending the location itself.
To handle type 0x0001 artifacts, the assertion consumer service must
maintain a table that maps source IDs to the locations of partner source
sites.
4. Secure Access sends an authentication statement to the ACS—Secure Access uses
the statement handle in the request to find the correct statement in the Secure Access
cache and then sends the appropriate authentication statement back to the to the
assertion consumer service. The unsigned statement contains the user's identity and
the mechanism he used to sign into Secure Access.
5. The ACS sends a cookie to Secure Access—The assertion consumer service accepts
the statement and then it sends a cookie back to Secure Access that enables the
user’s session.
6. Secure Access sends the cookie to the Web server—Secure Access caches the cookie
to handle future requests. Then Secure Access sends the cookie in an HTTP request
to the Web server whose domain name matches the domain in the cookie. The Web
server honors the session without prompting the user for credentials.
NOTE: If you configure Secure Access to use artifact profiles, you must
install Secure Access’s Web server certificate on the assertion consumer
service.
To write a SAML SSO artifact profile resource policy:
1.
In the admin console, select Users > Resource Policies > Web.
2. If your administrator view is not already configured to show SAML policies, make the
following modifications:
a. Click the Customize button in the upper right corner of the page.
b. Select the SSO checkbox.
c. Select the SAML checkbox below the SSO checkbox.
d. Click OK.
3. Select the SSO > SAML tab.
4. Click New Policy.
5. On the New Policy page, enter:
a. A name to label this policy.
250
Copyright © 2011, Juniper Networks, Inc.
Chapter 11: Single Sign-On
b. A description of the policy (optional).
6. In the Resources section, specify the resources to which this policy applies.
7. In the Roles section, specify:
•
Policy applies to ALL roles—To apply this policy to all users.
•
Policy applies to SELECTED roles—To apply this policy only to users who are
mapped to roles in the Selected roles list. Make sure to add roles to this list from
the Available roles list.
•
Policy applies to all roles OTHER THAN those selected below—To apply this policy
to all users except for those who map to the roles in the Selected roles list. Make
sure to add roles to this list from the Available roles list.
8. In the Action section, specify:
•
Use the SAML SSO defined below—Secure Access performs a single-sign on (SSO)
request to the specified URL using the data specified in the SAML SSO details
section. Secure Access makes the SSO request when a user tries to access to a
SAML resource specified in the Resources list.
•
Do NOT use SAML—Secure Access does not perform a SSO request.
•
Use Detailed Rules—To specify one or more detailed rules for this policy.
9. In the SAML SSO Details section, specify:
•
SAML Assertion Consumer Service URL—Enter the URL that Secure Access should
use to contact the assertion consumer service (that is, the access management
server). For example,
https://<hostname>:<port>/dana-na/auth/saml-consumer.cgi. (Note that Secure
Access also uses this field to determine the SAML recipient for its assertions.)
NOTE: If you enter a URL that begins with HTTPS, you must install the
assertion consumer service’s root CA on Secure Access.
•
Profile—Select Artifact to indicate that the assertion consumer service should “pull”
information from Secure Access during SSO transactions.
•
Source ID—Enter the source ID for Secure Access. If you enter a:
•
Plain text string—Secure Access converts, pads, or truncates it to a 20-byte string.
•
Base-64 encoded string—Secure Access decodes it and ensures that it is 20 bytes.
If your access management system requires base-64 encoded source IDs, you can
create a 20 byte string and then use a tool such as OpenSSL to base-64 encode it.
NOTE: Secure Access identifier (that is, the source ID) must map to the
following URL on the assertion consumer service:
https://<ivehostname>/dana-ws/saml.ws
Copyright © 2011, Juniper Networks, Inc.
251
Secure Access Administration Guide
•
Issuer—Enter a unique string that Secure Access can use to identify itself when it
generates assertions (typically its host name).
NOTE: You must configure the assertion consumer service to recognize
Secure Access’s unique string.
10. In the User Identity section, specify how Secure Access and the assertion consumer
service should identify the user:
•
•
Subject Name Type—Specify which method Secure Access and assertion consumer
service should use to identify the user:
•
DN—Send the username in the format of a DN (distinguished name) attribute.
•
Email Address—Send the username in the format of an email address.
•
Windows—Send the username in the format of a Windows domain qualified
username.
•
Other—Send the username in another format agreed upon by Secure Access and
the assertion consumer service.
Subject Name—Use variables to specify the username that Secure Access should
pass to the assertion consumer service. Or, enter static text.
NOTE: You must send a username or attribute that the assertion
consumer service will recognize.
11. In the Web Service Authentication section, specify the authentication method that
Secure Access should use to authenticate the assertion consumer service:
•
None—Do not authenticate the assertion consumer service.
•
Username—Authenticate the assertion consumer service using a username and
password. Enter the username and password that the assertion consumer service
must send Secure Access.
•
Certificate Attribute—Authenticate the assertion consumer service using certificate
attributes. Enter the attributes that the assertion consumer service must send Secure
Access (one attribute per line). For example, cn=sales. You must use values that
match the values contained in the assertion consumer service’s certificate.
NOTE: If you select this option, you must install the assertion consumer
service’s root CA on Secure Access.
12. Cookie Domain—Enter a comma-separated list of domains to which we send the
SSO cookie.
252
Copyright © 2011, Juniper Networks, Inc.
Chapter 11: Single Sign-On
13. Click Save Changes.
14. On the SAML SSO Policies page, order the policies according to how you want Secure
Access to evaluate them. Keep in mind that once Secure Access matches the resource
requested by the user to a resource in a policy’s (or a detailed rule’s) Resource list, it
performs the specified action and stops processing policies.
Related
Documentation
•
About Using Certificates on the SA Series Appliance on page 716
Creating a Single Sign-On POST Profile
When you choose to communicate using a POST profile (also called Browser/POST
profile), Secure Access “pushes” authentication data to the access management system
using an HTTP POST command over an SSL 3.0 connection.
Figure 15: POST Profile
Secure Access and an access management (AM) system use the following process to
pass information:
1.
The user tries to access a resource—A user is signed into Secure Access and tries to
access a protected resource on a Web server.
2. Secure Access posts a statement—Secure Access intercepts the request and checks
whether it has already performed the necessary SSO operation to honor the request.
If not, Secure Access creates an authentication statement, digitally signs it, and posts
it directly to the access management server. Since the statement is signed, the access
management server must trust the certificate authority that was used to issue the
certificate. Note that you must configure which certificate Secure Access uses to sign
the statement.
3. The AM establishes a session—If the user has the proper permissions, the access
management server sends a cookie back to Secure Access that enables the user’s
session.
4. Secure Access sends the cookie to the Web server—Secure Access caches the cookie
to handle future requests. Then Secure Access sends the cookie in an HTTP request
to the Web server whose domain name matches the domain in the cookie. The Web
server honors the session without prompting the user for credentials.
Copyright © 2011, Juniper Networks, Inc.
253
Secure Access Administration Guide
NOTE: If you configure Secure Access to use POST profiles, you must
install the assertion consumer service’s root CA on Secure Access and
determine which method the assertion consumer service uses to trust the
certificate.
To write a SAML SSO POST profile resource policy:
1.
In the admin console, navigate to Users > Resource Policies > Web.
2. If your administrator view is not already configured to show SAML policies, make the
following modifications:
a. Click the Customize button in the upper right corner of the page.
b. Select the SSO checkbox.
c. Select the SAML checkbox below the SSO checkbox.
d. Click OK.
3. Select the SSO > SAML tab.
4. Click New Policy.
5. On the SAML SSO Policy page, enter:
•
A name to label this policy.
•
A description of the policy (optional).
6. In the Resources section, specify the resources to which this policy applies.
7. In the Roles section, specify:
•
Policy applies to ALL roles—To apply this policy to all users.
•
Policy applies to SELECTED roles—To apply this policy only to users who are
mapped to roles in the Selected roles list. Make sure to add roles to this list from
the Available roles list.
•
Policy applies to all roles OTHER THAN those selected below—To apply this policy
to all users except for those who map to the roles in the Selected roles list. Make
sure to add roles to this list from the Available roles list.
8. In the Action section, specify:
254
•
Use the SAML SSO defined below—Secure Access performs a single-sign on (SSO)
request to the specified URL using the data specified in the SAML SSO details
section. Secure Access makes the SSO request when a user tries to access to a
SAML resource specified in the Resources list.
•
Do NOT use SAML—Secure Access does not perform a SSO request.
•
Use Detailed Rules—To specify one or more detailed rules for this policy.
Copyright © 2011, Juniper Networks, Inc.
Chapter 11: Single Sign-On
9. In the SAML SSO Details section, specify:
•
SAML Assertion Consumer Service URL—Enter the URL that Secure Access should
use to contact the assertion consumer service (that is, the access management
server). For example, https://hostname/acs.
•
Profile—Select POST to indicate that Secure Access should “push” information to
the assertion consumer service during SSO transactions.
•
Issuer—Enter a unique string that Secure Access can use to identify itself when it
generates assertions (typically its host name).
NOTE: You must configure the assertion consumer service to recognize
Secure Access’s unique string.
•
Signing Certificate—Specify which certificate Secure Access should use to sign its
assertions.
10. In the User Identity section, specify how Secure Access and the assertion consumer
service should identify the user:
•
•
Subject Name Type—Specify which method Secure Access and assertion consumer
service should use to identify the user:
•
DNDN—Send the username in the format of a DN (distinguished name) attribute.
•
Email Address—Send the username in the format of an email address.
•
Windows—Send the username in the format of a Windows domain qualified
username.
•
Other—Send the username in another format agreed upon by Secure Access and
the assertion consumer service.
Subject Name—Use variables to specify the username that Secure Access should
pass to the assertion consumer service. Or, enter static text.
NOTE: You must send a username or attribute that the assertion
consumer service will recognize.
•
Cookie Domain—Enter a comma-separated list of domains to which we send the
SSO cookie.
11. Click Save Changes.
12. On the SAML SSO Policies page, order the policies according to how you want Secure
Access to evaluate them. Keep in mind that once Secure Access matches the resource
requested by the user to a resource in a policy’s (or a detailed rule’s) Resource list, it
performs the specified action and stops processing policies.
Copyright © 2011, Juniper Networks, Inc.
255
Secure Access Administration Guide
Related
Documentation
•
About Using Certificates on the SA Series Appliance on page 716
•
Writing a Web Proxy Resource Policy on page 448
Creating a SAM Access Control Resource Policy
When enabling access control transactions to a trusted access management system,
Secure Access and trusted access management system exchange information using the
method shown below.
Figure 16: Access Control Policies
Secure Access and an access management (AM) system use the following process to
pass information:
1.
The user tries to access a resource—A user is signed into Secure Access and tries to
access a protected resource on a Web server.
2. Secure Access posts an authorization decision query—If Secure Access has already
made an authorization request and it is still valid, Secure Access uses that request.
(The authorization request is valid for the period of time specified in the admin
console.) If it does not have a valid authorization request, Secure Access posts an
authorization decision query to the access management system. The query contains
the user’s identity and the resource that the access management system needs to
authorize.
3. The AM posts an authorization decision statement—The access management system
sends an HTTPS POST containing a SOAP message that contains the authorization
decision statement. The authorization decision statement contains a result of permit,
deny, or indeterminate.
4. Secure Access sends the request to the Web browser—If the authorization decision
statement returns a result of permit, Secure Access allows the user access. If not,
Secure Access presents an error page to the user telling him that he does not have
the proper access permissions.
NOTE: If you configure Secure Access to use access control transactions,
you must install the SAML Web service’s root CA on Secure Access.
256
Copyright © 2011, Juniper Networks, Inc.
Chapter 11: Single Sign-On
To write a SAML Access Control resource policy:
1.
In the admin console, select Users > Resource Policies > Web.
2. If your administrator view is not already configured to show SAML policies, make the
following modifications:
a. Click the Customize button in the upper right corner of the page.
b. Select the SAML ACL checkbox below the Access checkbox.
c. Click OK.
3. Select the Access > SAML ACL tab.
4. On the SAML Access Control Policies page, click New Policy.
5. On the New Policy page, enter:
a. A name to label this policy.
b. A description of the policy (optional).
6. In the Resources section, specify the resources to which this policy applies.
7. In the Roles section, specify:
•
Policy applies to ALL roles—To apply this policy to all users.
•
Policy applies to SELECTED roles—To apply this policy only to users who are mapped
to roles in the Selected roles list. Make sure to add roles to this list from the Available
roles list.
•
Policy applies to all roles OTHER THAN those selected below—To apply this policy
to all users except for those who map to the roles in the Selected roles list. Make
sure to add roles to this list from the Available roles list.
8. In the Action section, specify:
•
Use the SAML Access Control checks defined below—Secure Access performs an
access control check to the specified URL using the data specified in the SAML
Access Control Details section.
•
Do not use SAML Access—Secure Access does not perform an access control check.
•
Use Detailed Rules—To specify one or more detailed rules for this policy.
9. In the SAML Access Control Details section, specify:
•
SAML Web Service URL—Enter the URL of the access management system’s SAML
server. For example, https://hostname/ws.
•
Issuer—Enter the host name of the issuer, which in most cases is the host name of
the access management system.
NOTE: You must enter unique string that the SAML Web service uses
to identify itself in authorization assertions.
Copyright © 2011, Juniper Networks, Inc.
257
Secure Access Administration Guide
10. In the User Identity section, specify how Secure Access and the SAML Web service
should identify the user:
•
•
Subject Name Type—Specify which method Secure Access and SAML Web service
should use to identify the user:
•
DN—Send the username in the format of a DN (distinguished name) attribute.
•
Email Address—Send the username in the format of an email address.
•
Windows—Send the username in the format of a Windows domain qualified
username.
•
Other—Send the username in another format agreed upon by Secure Access and
the SAML Web service.
Subject Name—Use variables to specify the username that Secure Access should
pass to the SAML Web service. Or, enter static text.
NOTE: You must send a username or attribute that the SAML Web
service will recognize.
11. In the Web Service Authentication section, specify the authentication method that
the SAML Web service should use to authenticate Secure Access:
•
None—Do not authenticate Secure Access.
•
Username—Authenticate Secure Access using a username and password. Enter
the username and password that Secure Access must send the Web service.
•
Certificate Attribute—Authenticate Secure Access using a certificate signed by a
trusted certificate authority. If you have more than one certificate installed on Secure
Access, use the drop-down list to select which certificate to send to the Web service.
NOTE: If you select this option, you must install the Secure Access Web
server’s certificate on the access management system’s Web server
and determine which method the SAML Web service uses to trust the
certificate.
12. In the Options section, specify:
258
•
Maximum Cache Time—You can eliminate the overhead of generating an
authorization decision each time the user request the same URL by indicating that
Secure Access must cache the access management system’s authorization
responses. Enter the amount of time Secure Access should cache the responses
(in seconds).
•
Ignore Query Data—By default, when a user requests a resource, Secure Access
sends the entire URL for that resource (including the query parameter) to the SAML
Web service and caches the URL. You can specify that Secure Access should remove
Copyright © 2011, Juniper Networks, Inc.
Chapter 11: Single Sign-On
the query string from the URL before requesting authorization or caching the
authorization response.
13. Click Save Changes.
14. On the SAML Access Control Policies page, order the policies according to how you
want Secure Access to evaluate them. Keep in mind that once Secure Access matches
the resource requested by the user to a resource in a policy’s (or a detailed rule’s)
Resource list, it performs the specified action and stops processing policies.
Related
Documentation
•
About Using Certificates on the SA Series Appliance on page 716
•
Writing a Web Proxy Resource Policy on page 448
Creating a Trust Relationship Between SAML-Enabled Systems
In order to ensure that SAML-enabled systems are only passing information between
trusted sources, you must create a trust relationship between the applications that are
sending and receiving information.
Configuring Trusted Application URLs
In a trust relationship, you must provide the SAML-enabled systems with the URLs they
need to contact each other. In some transactions, only the system that initiates the
transaction (Secure Access) needs to know the URL of the other system. (Secure Access
uses the URL to initiate the transaction.) In other transactions (SSO transactions using
artifact profiles), you need to configure each system with the URL of the other.
Listed below are the different transaction types and the URLs you must configure for
each:
•
SSO transactions: Artifact profile—On Secure Access, you must enter the URL of the
assertion consumer service. For example: https://hostname/acs
You must also enter the following URL for Secure Access on the assertion consumer
service: https://<SecureAccessHostname>/dana-ws/saml.ws
•
SSO transactions: POST profile—On Secure Access, you must enter the URL of the
assertion consumer service. For example: https://hostname/acs
•
Access control transactions—On Secure Access, you must enter the URL of the SAML
Web service. For example: https://hostname/ws
Configuring an Issuer
Before accepting a statement from another system, a SAML-enabled entity must trust
the issuer of the statement. You can control which issuers a system trusts by specifying
the unique strings of the trusted issuers during the system’s configuration. (When sending
a statement, an issuer identifies itself by including its unique string in the statement.
SAML-enabled applications generally use host names to identify issuers, but the SAML
standard allows applications to use any string.) If you do not configure a system to
recognize an issuer’s unique string, the system will not accept that issuer’s statements.
Copyright © 2011, Juniper Networks, Inc.
259
Secure Access Administration Guide
Listed below are the different transaction types and the issuers you must configure for
each:
•
SSO transactions—You must specify a unique string on Secure Access (typically its
host name) that it can use to identify itself and then configure the access management
system to recognize that string.
•
Access control transactions—You must specify a unique string on the access
management system (typically its host name) that it can use to identify itself and then
configure Secure Access to recognize that string.
Configuring Certificates
Within SSL transactions, the server must present a certificate to the client, and then the
client must verify (at minimum) that it trusts the certificate authority who issued the
server’s certificate before accepting the information. You can configure all of Secure
Access’s SAML transactions to use SSL (HTTPS).
Configuring SSO Transactions: Artifact Profile
Artifact profile transactions involve numerous communications back and forth between
Secure Access and access management system. The methods you use to pass data and
authenticate the two systems affect which certificates you must install and configure.
Listed below are the different artifact profile configuration options that require special
certificate configurations:
•
All artifact profile transactions—Regardless of your artifact profile configuration, you
must install the certificate of the CA that signed the Secure Access Web server’s
certificate on the access management system. (Secure Access requires the access
management system to use an SSL connection when requesting an authentication
statement. In an SSL connection, the initiator must trust the system to which it is
connecting. By installing the CA certificate on the access management system, you
ensure that the access management system will trust the CA that issued Secure Access’
certificate.)
•
Sending artifacts over an SSL connection (HTTPS GET requests)—If you choose to
send artifacts to the access management system using an SSL connection, you must
install the access management system’s root CA certificate on Secure Access. (In an
SSL connection, the initiator must trust the system to which it is connecting. By installing
the access management system’s CA certificate on Secure Access, you ensure that
Secure Access will trust the CA that issued the access management system’s
certificate.) You can install the root CA from the System > Configuration > Certificates
> Trusted Client CAs page in the admin console. If you do not want to send artifacts
over an SSL connection, you do not need to install any additional certificates.
To enable SSL-based communications from Secure Access to the access management
system, enter a URL that begins with HTTPS in the SAML Assertion Consumer Service
URL field during Secure Access configuration. You may also need to enable SSL on
the access management system.
•
260
Transactions using certificate authentication—If you choose to authenticate the access
management system using a certificate, you must:
Copyright © 2011, Juniper Networks, Inc.
Chapter 11: Single Sign-On
•
Install the access management system’s root CA certificate on Secure Access. You
can install the root CA from the System > Configuration > Certificates > Trusted
Client CAs page in the admin console.
•
Specify which certificate values Secure Access should use to validate the access
management system. You must use values that match the values contained in the
access management server’s certificate.
If you do not choose to authenticate the access management system, or if you choose
to use username/password authentication, you do not need to install any additional
certificates.
Configuring SSO Transactions: POST Profile
In a POST profile transaction, Secure Access sends signed authentication statements
to the access management system. Generally, it sends them over an SSL connection
(recommended), but in some configurations, Secure Access may send statements via
a standard HTTP connection. Listed below are the different POST profile configuration
options that require special certificate configurations:
•
All POST profile transactions—Regardless of your POST profile configuration, you must
specify which certificate Secure Access should use to sign its statements. You can
choose a certificate in the Users > Resource Policies > Web > SSO SAML > [Policy] >
General page in the admin console. Then, you must install Secure Access’s device
certificate on the access management system. You can download Secure Access’s
certificate from the System > Configuration > Certificates > Device Certificates >
[Certificate] > Certificate Details page.
•
Sending POST data over an SSL connection (HTTPS)—If you choose to send
statements to the access management system using an SSL connection, you must
install the access management system’s root CA certificate on Secure Access. (In an
SSL connection, the initiator must trust the system to which it is connecting. By installing
the access management system’s certificate on Secure Access, you ensure that Secure
Access will trust the CA that issued the access management system’s certificate.) You
can install the root CA from the System > Configuration > Certificates > Trusted Client
CAs page in the admin console. If you do not want to post statements over an SSL
connection, you do not need to install any additional certificates.
To enable SSL-based communications from Secure Access to the access management
system, enter a URL that begins with HTTPS in the SAML Assertion Consumer Service
URL field during Secure Access configuration. You may also need to enable SSL on the
access management system.
Configuring Access Control Transactions
In an access control transaction, Secure Access posts an authorization decision query
to the access management system. To ensure that the access management system
responds to the query, you must determine which certificate options are required by your
configuration. Listed below are the different access control configuration options that
require special certificate configurations:
Copyright © 2011, Juniper Networks, Inc.
261
Secure Access Administration Guide
•
Sending authorization data over an SSL connection—If you choose to connect to the
access management system using an SSL connection, you must install the access
management system’s root CA on Secure Access. (In an SSL connection, the initiator
must trust the system to which it is connecting. By installing the access management
system’s certificate on Secure Access, you ensure that Secure Access will trust the CA
that issued the access management system’s certificate.) You can install the root CA
from the System > Configuration > Certificates > Trusted Client CAs page in the admin
console.
•
Transactions using certificate authentication—If you choose to use certificate
authentication, you must configure the access management system to trust the CA
that issued Secure Access’ certificate. Optionally, you may also choose to accept the
certificate based on the following additional options:
•
Upload Secure Access certificate’s public key to the access management system.
•
Validate Secure Access using specific certificate attributes.
These options require that you specify which certificate Secure Access should pass to
the access management system. You can choose a certificate in the Users > Resource
Policies > Web > SAML ACL > [Policy] > General page in the admin console.
To determine how to configure your access management system to validate Secure
Access’ certificate, see your access management system’s documentation. If your
access management system does not require certificate authentication, or if it uses
username/password authentication, you do not need to configure Secure Access to
pass the access management server a certificate. If you do not specify a trust method,
your access management system may accept authorization requests from any system.
Configuring User Identity
In a trust relationship, the two entities must agree on a way to identify users. You may
choose to share a username across systems, select an LDAP or certificate user attribute
to share across systems, or hard-code a user ID. (For example, you may choose to set
the Subject Name field to “guest” to easily allow access across systems.)
To ensure that the two systems are passing common information about users, you must
specify which information Secure Access should pass using options in the User Identity
section of the Users > Resource Policies > Web > SAML SSO > [Policy] > General page
and the Users > Resource Policies > Web > SAML ACL > [Policy] > General page of the
admin console. Choose a username or attribute that the access management system
will recognize.
Related
Documentation
262
•
Using a Trusted Client CA on page 725
•
Configuring SAML on page 246
•
Configuring SAML SSO Profiles on page 249
•
Creating a Trust Relationship Between SAML-Enabled Systems on page 259
•
Configuring General Role Options on page 93
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 12
Synchronizing User Records
•
About User Record Synchronization on page 263
•
Enabling User Record Synchronization on page 265
•
Configuring the User Record Synchronization Authentication Server on page 266
•
Configuring the User Record Synchronization Server on page 266
•
Configuring the User Record Synchronization Client on page 267
•
Configuring the User Record Synchronization Database on page 268
About User Record Synchronization
The user record synchronization feature promotes a more consistent user experience by
allowing users to retain their bookmarks and individual preferences regardless of which
Secure Access they log in to.
User record synchronization relies on client-server pairings. The client is the Secure Access
appliance that users log in to start their remote access. Each client is associated with
one primary server and one backup server to store user record data. Clients can be
individual appliances or a node within a cluster.
A server in this instance is the Secure Access appliance that stores the user data records.
Each server can be configured to replicate its user record data to one or more peer servers.
Servers are identified by a user-defined logical name. The same logical name can be
assigned to more than one authentication server to let you associate authentication
servers of different types to the same user. For example, SA1 is an ACE authentication
server with user1 who creates a bookmark to www.juniper.net. SA2 is an Active Directory
authentication server with the same user1. For the www.juniper.net bookmark to be
transferred from SA1/ACE/user1 to SA2/AD/user1 you would assign the logical name
“Logical1” to both the ACE server on SA1 and the Active Directory server on SA2.
NOTE: Cluster VIPs can not be used as the IP for synchronizing between
clients and peers servers.
As long as the logical name is the same, the authentication servers can be different types
and different server names and still be associated with a common user. The username
must be the same for user record data to be synchronized across the servers. The logical
Copyright © 2011, Juniper Networks, Inc.
263
Secure Access Administration Guide
authentication server (LAS) and username combination is what uniquely identifies a user
record.
The following user records are synchronized between the client and server:
•
Bookmarks
•
Web
•
File
•
Terminal Services
•
JSAM
•
Preferences
•
Persistent cookies
•
Cached passwords
User session data is not synchronized. Persistent cookies, if changed, are synchronized
when the user session terminates. All other modifications to the user records are
synchronized immediately. User records are stored in cache on the client node prior to
being pushed to the servers.
When a user logs in to a client, their data is pulled from the associated server. The pull
is performed in the background and does not delay the login process. Users using browsers
that do not support JavaScript must manually refresh the index page for updated
bookmarks and preferences to appear. For browsers that support JavaScript, users may
see a spinning progress indicator and their home page will refresh automatically with
updated bookmarks and preferences.
Clients and servers need not be installed with the same Secure Access software version
as long as they are using version 6.5 or later.
NOTE: User record synchronization uses port 17425. This port number is not
configurable. If you are deploying across a firewall, configure your firewall to
allow traffic on this port.
To set up user record synchronization, you perform the following tasks:
1.
Enable user record synchronization for each participating client and server, identify
which ones are the client and which ones are the server and assign a node name to
each client and server.
2. Create a shared secret which is used to authenticate the client with the server and
the server to its peer servers.
3. On each server, define which clients and peers are allowed to communicate with the
server.
4. On each client, define the servers that handle records for each LAS server.
264
Copyright © 2011, Juniper Networks, Inc.
Chapter 12: Synchronizing User Records
When enabling this feature, you have several options to initialize the user record database.
You can:
•
populate the database using user records located in the cache of the client systems.
•
populate the database use user records located in the cache of the server systems.
•
don’t pre-populate the database but populate it as users log in and out of the client
system.
If you choose the last option, users may not be able to view their saved bookmarks and
preferences until the next time they log in, depending on which client they log in to.
NOTE: User records may not synchronize if the time clocks on the Secure
Access appliances are not in sync. We recommend that you use the same
NTP server for each node participating in user record synchronization to keep
Secure Access times accurately adjusted.
Related
Documentation
•
Enabling User Record Synchronization on page 265
•
Configuring the User Record Synchronization Authentication Server on page 266
•
Configuring the User Record Synchronization Server on page 266
•
Configuring the User Record Synchronization Client on page 267
•
Configuring the User Record Synchronization Database on page 268
Enabling User Record Synchronization
The first step in enabling user record synchronizing is to define the node name and the
shared secret used to authenticate between the clients and the servers:
1.
Select System > Configuration > User Record Synchronization > General.
2. Select the Enable User Record Synchronization checkbox.
3. Enter a unique node name. This name is used when associating a client with a server
and is different from the logical name assigned to a server. This node name is also
not the same as the cluster node name.
4. Enter the shared secret and confirm it.
The shared secret is the password used to authenticate the client with its servers and
the primary server with its peer servers. Use the same shared secret for all clients and
servers participating in user record synchronization.
5. Select whether this node is client only or if this node acts as both a client and server.
6. Click Save Changes.
Copyright © 2011, Juniper Networks, Inc.
265
Secure Access Administration Guide
NOTE: If you need to make any changes in this window at a later time, you
must deselect the Enable User Record Synchronization checkbox and click
Save Changes. Make your edits, select the Enable User Record Synchronization
checkbox and save your changes.
Once you enter a name and shared secret, you can not clear these fields.
Related
Documentation
•
Configuring the User Record Synchronization Authentication Server on page 266
•
Configuring the User Record Synchronization Server on page 266
•
Configuring the User Record Synchronization Client on page 267
•
Configuring the User Record Synchronization Database on page 268
Configuring the User Record Synchronization Authentication Server
To set up the authentication server you must define it’s logical name:
1.
Select Authentication > Auth Servers.
2. Click the name of the authentication server you want assign a LAS name.
By assigning the authentication server a LAS name, all users that authenticate using
the authentication server are associated with this LAS. In this instance, we are referring
to the client nodes, not the user record synchronization server nodes.
3. Select the User Record Synchronization checkbox.
4. Enter a logical name to identify this server.
This allows you to share user record data across authentication servers on different
Secure Access gateways. By assigning a LAS name to an authentication server, you
are implicitly assigning it to all users that authenticate with that auth server. The
combination of the user’s login name and their LAS name uniquely identifies the user's
user record across all user record synchronization servers.
5. Click Save Changes.
Related
Documentation
•
Configuring the User Record Synchronization Authentication Server on page 266
•
Configuring the User Record Synchronization Client on page 267
•
Configuring the User Record Synchronization Database on page 268
Configuring the User Record Synchronization Server
To set up the user record synchronization server you must define it’s peer nodes (optional)
and the clients that can access this server.
1.
266
Select System > Configuration > User Record Synchronization > This Server.
Copyright © 2011, Juniper Networks, Inc.
Chapter 12: Synchronizing User Records
2. Enter the peer server’s node name and IP address, then click Add. To specify more
than one peer server, enter each server’s node name and IP address individually and
click Add. There is no limit on the number of peer servers you can add.
Data is replicated from the primary or backup server to its peer servers. If the primary
is not available, user data is sent to the backup. User data is then replicated to the
peer servers.
3. For each client you want synchronized with this server, enter the client’s name and IP
address and click Add.
Once added, peer servers will have a colored icon next to their name indicating their
connection status. Node status is provided to client nodes and LAS mapping servers as
well.
Color
Description
Green
Connected
Yellow
Connecting
Gray
Not connected
Related
Documentation
•
Configuring the User Record Synchronization Authentication Server on page 266
•
Configuring the User Record Synchronization Client on page 267
•
Configuring the User Record Synchronization Database on page 268
Configuring the User Record Synchronization Client
To set up the client, you select the primary and backup server you want this client to
synchronize with:
1.
Select System > Configuration > User Record Synchronization > This Client.
2. Select the LAS name you want to synchronize and enter the primary IP of the user
record server that will server the user records. If you prefer to synchronize with any
available server, select Any LAS.
3. Enter the primary and optionally a backup server’s IP address and then click Add.
Even if you select Any LAS, you must enter a primary server IP address.
Once added, the primary and backup servers have a colored icon next to their name
indicating their connection status.
Related
Documentation
•
Configuring the User Record Synchronization Authentication Server on page 266
•
Configuring the User Record Synchronization Server on page 266
•
Configuring the User Record Synchronization Database on page 268
Copyright © 2011, Juniper Networks, Inc.
267
Secure Access Administration Guide
Configuring the User Record Synchronization Database
With the Database tab, you can delete inactive records from the client cache, retrieve
statistics about the database, export and import the data and remove user data from
the server’s database.
To configure the database:
1.
Select System > Configuration > User Record Synchronization > Database.
2. Select Auto-delete inactive synchronized user records from the Cache to remove
inactive user records from the cache. This option does not remove user records from
the user record database.
When this option is selected, Secure Access performs a check every 15 minutes and
deletes user records that meet all of the following criteria:
•
There are no active user sessions associated with the user record.
•
The user record does not have any custom settings or the latest version of the user
record has been synchronized with the user record database.
•
The authentication server associated with the user record database does not have
type “local”. For example, the “System Local” auth server that is part of the default
configuration of Secure Access has a “local” type, so any user records associated
with that auth server will not be auto-deleted. However, user records associated
with external authentication servers like Radius or LDAP may be deleted, depending
on the two prior criteria.
3. Select Auto-delete user records from the local synchronization database that have
been idle for X days to permanently remove user records from the database located
on the server. Enter the number of days user records must be inactive before being
deleted.
In this instance, “inactive” means that no client as pulled the user record or pushed
any modifications to the user record in X days.
4. Click Retrieve Statistics to display the number of records in the database. You can
not edit or view records in the database.
5. Under Export, you export user records to a file. The user records can be exported from
the user record database, or from the cache. The exported file can be used to
pre-populate the user record database on another node.
268
•
Enter the LAS name of the user records you want to export. If you leave this field
blank, all user records are exported. If you enter a LAS name, only user records with
the entered LAS name are exported.
•
To encrypt the exported data, select the Encrypt the exported data with password
checkbox and enter the password.
•
Click Export to export the user records from the specified source (cache or
database). You will be prompted where to save the file.
Copyright © 2011, Juniper Networks, Inc.
Chapter 12: Synchronizing User Records
6. Under Import, you import user records into the synchronization database. The user
records can be imported from a file or from the cache. Use the Import operation to
pre-populate the user record database with user records exported from another node,
or with user records from the cache.
•
Click Browse to locate the exported file and enter the password if the exported file
was encrypted with a password.
•
Select the Override Logical Auth Servers in imported user records with checkbox
to replace the LAS name in each imported user record with the LAS name entered.
For example, you change the LAS name, use this option to update the user records
with the new name.
•
Click Import.
7. Under Delete, specify which user records to permanently remove from the user record
database. The options you select apply only to the user record database associated
with this server.
Related
Documentation
•
Select User record with login name and Logical Auth Server to remove a specific
record. The login name and LAS name together uniquely identify a user record.
Select this option to remove that record (if it exists).
•
Select User records with Logical Auth Server to delete all user records with the
specified LAS name.
•
Select All user records to permanently remove user records from the database on
this node.
•
Click Delete.
•
Configuring the User Record Synchronization Authentication Server on page 266
•
Configuring the User Record Synchronization Server on page 266
•
Configuring the User Record Synchronization Client on page 267
Copyright © 2011, Juniper Networks, Inc.
269
Secure Access Administration Guide
270
Copyright © 2011, Juniper Networks, Inc.
PART 3
Endpoint Defense
•
Host Checker on page 273
•
Cache Cleaner on page 339
Copyright © 2011, Juniper Networks, Inc.
271
Secure Access Administration Guide
272
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 13
Host Checker
•
Host Checker and Trusted Network Computing on page 274
•
Task Summary: Configuring Host Checker on page 275
•
Creating Global Host Checker Policies on page 277
•
Enabling Enhanced Endpoint Security Functionality on page 278
•
Enabling Connection Control Host Checker Policies (Windows Only) on page 280
•
Creating and Configuring New Client-side Host Checker Policies on page 281
•
Checking for Third-Party Applications Using Predefined Rules (Windows
Only) on page 282
•
Configuring a Predefined Antivirus Rule with Remediation Options on page 284
•
Configuring a Predefined Firewall Rule with Remediation Options (Windows
Only) on page 286
•
Configuring a Pre-defined AntiSpyware Rule (Windows Only) on page 287
•
Configuring Virus Signature Version Monitoring and Patch Assessment Data
Monitoring on page 288
•
Specifying Customized Requirements Using Custom Rules on page 290
•
Using a Wildcard or Environment Variable in a Host Checker Rule on page 295
•
Configuring Patch Assessment Policies on page 297
•
Configuring Patch Assessment Rules on page 299
•
Using Third-party Integrity Measurement Verifiers on page 301
•
Configuring a Remote IMV Server on page 302
•
Implementing the Third-Party IMV Policy on page 308
•
Implementing Host Checker Policies on page 309
•
About Host Checker Restrictions on page 311
•
Remediating Host Checker Policies on page 313
•
Configuring General Host Checker Remediation on page 315
•
Upgrading the Endpoint Security Assessment Plug-In on page 317
•
Defining Host Checker Pre-Authentication Access Tunnels on page 319
•
Specifying Host Checker Pre-Authentication Access Tunnel Definitions on page 320
•
Specifying General Host Checker Options on page 323
Copyright © 2011, Juniper Networks, Inc.
273
Secure Access Administration Guide
•
Specifying Host Checker Installation Options on page 324
•
Using Host Checker with the GINA Automatic Sign-In Function on page 326
•
Installing Host Checker Automatically or Manually on page 327
•
Using Host Checker Logs on page 328
•
Configuring Host Checker for Windows Mobile on page 328
•
Using Proxy Exceptions on page 329
•
Enabling the Secure Virtual Workspace on page 330
•
Defining Secure Virtual Workspace Permissions on page 332
•
Defining a Secure Virtual Workspace Application Policy on page 334
•
Defining a Secure Virtual Workspace Security Policy on page 335
•
Defining Secure Virtual Workspace Environment Options on page 336
•
Defining Secure Virtual Workspace Remediation Policy on page 337
Host Checker and Trusted Network Computing
Host checker is a client-side agent that performs endpoint health and security checks
for hosts that attempt to connect to the SA.
The Trusted Computing Group (TCG) is a not-for-profit organization formed in 2003 to
develop, define, and promote open standards for hardware-enabled trusted computing
and security technologies across multiple platforms, peripherals, and devices. The TCG
has over 100 members that include component vendors, software developers, systems
vendors, and network companies.
Trusted Network Connect (TNC) is a subgroup of the TCG that created an architecture
and set of standards for verifying endpoint integrity and policy compliance during or after
a network access request. Many of the TCG members participated in the definition and
specification of the TNC’s architecture. The TNC defined several standard interfaces that
enable components from different vendors to securely operate together. The TNC
architecture is designed to build on established standards and technologies, such as 802
1X, RADIUS, IPsec, EAP, and TLS/SSL. For more information about TNC, see
www.trustedcomputinggroup.org.
Using technology based on the TNC architecture and standards, the Host Checker
component of the Unified Access Control solution provides a comprehensive approach
to assess the trust worthiness of endpoints.
You can use Host Checker to perform endpoint checks on hosts before allowing them
to connect to the SA and access protected resources. Host Checker can check for third
party applications, files, process, ports, registry keys, and custom DLLs on hosts. Based
on the results of the checks, it can then deny or allow access to protected resources. For
example, you may choose to check for virus detection software before allowing a user
access to any of the SA realms, launch the software on the user’s system if necessary,
map the user to roles based on individual policies defined in your own DLL, and then
further restrict access to individual resources based on the existence of spyware detection
software. When a user’s computer does not meet the requirements you specify, you can
274
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
display remediation instructions to users so they can bring their computers into
compliance.
Host Checker supports TNC-based integrity measurement collectors (IMCs) and integrity
measurement verifiers (IMVs). IMCs are software modules that run on the host and collect
information such as antivirus, antispyware, patch management, firewall, and other
configuration and security information about the host. IMVs are software modules that
run on the SA and verify a particular aspect of an host’s integrity. Each IMV on the SA
works with the corresponding IMC on the host to verify that the host meets the
requirements of the integrity measurement custom rule(s) that you configure. IMCs
frequently scan the client machine for changes in security status. Some IMCs can detect
a change in status (for example, if the user turns off virus checking) and then trigger a
new check to make sure the modified system complies with the requirements of the Host
Checker policy. You can configure Host Checker to monitor third-party IMCs installed on
client computers by using third-party IMVs that are installed on a remote IMV server.
You can invoke Host Checker at the role level, or the realm level to specify access
requirements for endpoints attempting to authenticate.
All Host Checker rules are implemented through IMCs and IMVs based on the TNC open
architecture. IMCs are software modules that Host Checker runs on the client machine.
IMCs are responsible for collecting information, such as antivirus, antispyware, patch
management, firewall, and other configuration and security information for a client
machine.
IMVs are software modules running on the SA that are responsible for verifying a particular
aspect of an endpoint’s integrity.
The SA and Host Checker manage the flow of information between the corresponding
pairs of IMVs and IMCs. Each IMV on the SA works with the corresponding IMC on the
client machine to verify that the client meets the Host Checker rules.
You can also configure Host Checker to monitor third-party IMCs installed on client
computers by using third-party IMVs that are installed on a remote IMV server.
Related
Documentation
•
Creating Global Host Checker Policies on page 277
•
Task Summary: Configuring Host Checker on page 275
Task Summary: Configuring Host Checker
NOTE: Ensure that user endpoints have signed ActiveX components or signed
Java applets enabled within their browsers to permit Host Checker to
download, install, and launch.
Copyright © 2011, Juniper Networks, Inc.
275
Secure Access Administration Guide
To configure a Host Checker policy, perform these tasks:
1.
Create and enable Host Checker policies through the Authentication > Endpoint
Security > Host Checker page of the admin console.
a. In the admin console, select Authentication > Endpoint Security > Host Checker.
b. Under Policies, click New.
c. Enter a name in the Policy Name field and then click Continue. (Users see this
name on the Host Checker remediation page if you enable custom instructions for
this policy.)
d. Create one or more rules to associate with the policy.
2. Configure additional system-level options on the Authentication > Endpoint Security
> Host Checker page of the admin console as necessary:
•
If you want to display remediation information to users if they fail to meet the
requirements of a Host Checker policy, configure remediation options through the
Authentication > Endpoint Security > Host Checker page of the admin console.
•
For Windows clients, determine whether you need to use a pre-authentication
access tunnel between the clients and policy server(s) or resources. If necessary,
create a manifest.hcif file with the tunnel definition and upload it through the
Authentication > Endpoint Security > Host Checker page of the admin console.
•
To change default Host Checker settings, configure settings through the
Authentication > Endpoint Security > Host Checker page of the admin console.
3. Determine the level you that you want to enforce Host Checker policies:
•
To enforce Host Checker policies when the user initially accesses Secure Access,
implement the policy at the realm level by selecting the policy at the Users > User
Realms > Select Realm > Authentication Policy > Host Checker page of the admin
console.
•
To allow or deny users access to specific roles based on compliance with Host
Checker policies, implement the policies at the role level by using the Users > User
Roles > Select Role > General > Restrictions > Host Checker page of the admin
console.
•
To map users to roles based on their compliance with Host Checker policies, use
custom expressions in the Users > User Realms > Select Realm > Role Mapping
page of the admin console.
•
To allow or deny users access to individual resources based on their compliance
with Host Checker policies, use conditions in the Users > Resource Policies > Select
Resource > Select Policy > Detailed Rules > Select|Create Rule page of the admin
console.
4. Specify how users can access the Host Checker client-side agent that enforces the
policies you define:
276
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
•
To enable automatic installation of the Host Checker client-side agent on all
platforms, use the Administrators > Admin Realms > Select Realm > Authentication
Policy > Host Checker page or the Users > User Realms > Select Realm >
Authentication Policy > Host Checker page of the admin console.
•
To download the Host Checker installer and manually install it on your Windows
users’ systems, use the Maintenance > System > Installers page of the admin
console.
5. Determine whether you want to create client-side logs. If you enable client-side logging
through the System > Log/Monitoring > Client Logs page of the admin console, the
Secure Access appliance creates log files on your users’ systems and writes to the file
whenever Host Checker runs.
If more than one valid Secure Access session exists from the same system, and Host
Checker is used in those sessions, all of the valid sessions are terminated if a user signs
out from any of the sessions. To prevent this, turn off Host Checker for those sessions
that do not need Host Checker.
Related
Documentation
•
Junos Pulse Overview on page 37
•
Creating Global Host Checker Policies on page 277
Creating Global Host Checker Policies
To use Host Checker as a policy enforcement tool for managing endpoints, you create
Host Checker policies through the Authentication > Endpoint Security > Host Checker page
of the admin console, and then implement the policies at the realm, role, and resource
policy levels.
Secure Access provides many options that you can use to enable, create, and configure
Host Checker policies:
•
Pre-defined policies (prevent in-network attacks or downloads malware detection
software)—Secure Access comes equipped with two types of pre-defined client-side
Host Checker policies that you simply need to enable, not create or configure, in order
to use them. The Connection Control policy prevents attacks on Windows client
computers from other infected computers on the same network. The EES policies
download malware protection software to client computers before users sign into
Secure Access. Note that these policies only work on Windows systems.
•
Pre-defined rules (check for third party applications)—Host Checker contains a wide
array of pre-defined rules that check for antivirus software, firewalls, malware, spyware,
and specific operating systems from a variety of industry leaders. You can enable one
or more of these rules within a Host Checker client-side policy to ensure that the
integrated third party applications that you specify are running on your users’ computers.
•
Custom rules (check for additional requirements)—In addition to Predefined rules,
you can create custom rules within a Host Checker policy to define requirements that
user endpoints must meet. Using custom rules, you can:
Copyright © 2011, Juniper Networks, Inc.
277
Secure Access Administration Guide
Related
Documentation
•
Configure Host Checker to check for custom third party DLLs that perform customized
client-side checks.
•
Verify that certain ports are open or closed on the user’s computer.
•
Confirm that certain processes are or are not running on the user’s computer.
•
Check that certain files are or are not present on the client machine.
•
Evaluate the age and content of required files through MD5 checksums.
•
Confirm that registry keys are set on the client machine (Windows only).
•
Check the NetBIOS name, MAC addresses, or certificate of the client machine
(Windows only).
•
Assess the client operating system and application service packs to ensure they are
up to date (Windows only).
•
Perform application and version checks to ensure that endpoints are running the
correct software (Windows only).
•
Custom integrated applications (implement through server API)—For Windows
clients, you can upload a third-party J.E.D.I. DLL to Secure Access.
•
Within a single policy, you can create different Host Checker requirements for Windows,
Macintosh and Linux, checking for different files, processes, and products on each
operating system. You can also can combine any number of host check types within
a single policy and check for alternative sets of rules.
•
Configuring a Remote IMV Server on page 302
•
Implementing Host Checker Policies on page 309
Enabling Enhanced Endpoint Security Functionality
Host Checker includes integrated antispyware functionality that can detect and remediate
Windows endpoints. Enhanced Endpoint Security (EES) ensures that the following
malware, spyware, viruses, or worms are not present on endpoints that attempt to connect
to Secure Access, and you can restrict or quarantine these endpoints depending on your
Host Checker policy configuration.
278
•
Adware
•
Dialers
•
Hijack
•
Spy Cookie
•
Commercial System Monitor
•
System Monitor (detects spyware, keyloggers, screenscrapers and any malware that
monitors the system)
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
•
Trojan Downloader
•
Trojan Phisher
•
Trojan Horse
•
Worm
EES can scan processes that are loaded in memory on endpoints and provide real-time
file system write and execution shield to automatically remediate machines that are not
in compliance. As part of the remediation status, EES reports any threats that are detected
but not remediated. In some cases the end user may be directed to reboot the machine
to achieve compliance.
EES uses a signature database that is automatically downloaded to endpoints from Web
Root Spy Sweeper servers on the Internet. The signature database is not hosted on Secure
Access.
Endpoints must have access to the Internet for EES to successfully run, as live signature
updates must be permitted to download. Additionally, if you configure default remediation
roles you should ensure that endpoints that are directed to remediation roles can access
*.webroot.com.
You can configure the age of the database on Secure Access to determine the acceptable
age of the signature database. The age of the database is the threshold used to determine
if a user can access resources by passing a Host Checker policy. For example, if signatures
are five days old, and you configure the age as six days, the user is allowed to access
resources. If you configure the age as four days, the user fails the Host Checker policy. If
a user passes the initial EES Host Checker policy, signature updates are performed
regularly, so endpoints should generally have the most current updates.
If Internet connectivity is not available to an endpoint prior to connecting to Secure Access
and you have chosen to implement the option to check for signature age, the policy will
not pass if the signatures are too old. For example, if a user has not accessed the endpoint
for several days and the signatures are not up to date, the endpoint cannot authenticate
to Secure Access. In this case, you can create a default remediation role that allows
limited access to the Internet for signature updates at *.webroot.com.
EES antispyware functionality is available on Windows platforms (including Vista) with
Network Connect.
You configure EES on the Endpoint Security > Host Checker main page to ensure that
multiple policies are not created, and that the same policy is used across all realms and
roles for which you have enabled it. When you create a realm or a role, you can enable
EES restrictions in addition to any other Host Checker policies.
NOTE: The trial package of 25 AED users has been replaced by the trial pack
of 2 EES users. Trial packs are intended for proof-of-concept and trial tests.
They are not intended for production use. A lab license key does not add or
subtract any EES capacity.
Copyright © 2011, Juniper Networks, Inc.
279
Secure Access Administration Guide
User Experience
For endpoints that do not have Network Connect or Junos Pulse already installed, the
EES plugin initializes before the EES policy can be evaluated. An informational page
displays on the user’s endpoint to communicate the assessment status.
A significant amount of data is downloaded (approximately 5 MB for the installer and
approximately 12 MB for the signatures) followed by the memory scan.
After installation, signatures are updated and the memory scan is performed to establish
that no spyware is loaded in memory. If it is determined that the endpoint does not have
active spyware in memory, the policy passes.
The initial installation and scan on endpoints takes some time. You should warn end
users to wait for the operation to complete.
Any threat detected is automatically remediated by Host Checker and not reported. If
threats cannot be remediated, the endpoint reports back to the server. Roles and user
sessions can be adjusted based on endpoint compliance. A number of user strings
automatically notify the end user of compliance status.
To enable and use EES antispyware:
1.
In the admin console, select Authentication > Endpoint Security > Host Checker.
2. Under Options, select the Advanced Endpoint Protection: Malware Protection tab.
3. Select the Enable Advanced Endpoint Protection: Malware Protection check box.
4. Set the age of the signature definitions database by selecting the Signature definitions
should not be older than check box. Enter the frequency in days (3 - 30). This function
does not change the frequency of updates. This number determines the maximum
permissible age of signatures.
5. Click Save Changes.
When you create or configure realm or role Host Checker restrictions, you can select
Enhanced Endpoint Security: Malware Protection to apply to that role or realm.
Related
Documentation
•
About Host Checker Restrictions on page 311
Enabling Connection Control Host Checker Policies (Windows Only)
The pre-defined connection control Host Checker policy prevents attacks on Windows
client computers from other infected computers on the same physical network.
280
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
NOTE: The Host Checker connection control policy is not supported on
Windows Vista or Windows 7.
The Host Checker connection control policy blocks all incoming TCP, UDP
and ICMP connections. This policy allows all outgoing TCP and Network
Connect traffic, as well as all connections to DNS servers, WINS servers,
DHCP servers, proxy servers, and Secure Access.
NOTE: Users must have administrator privileges in order for Host Checker
to enforce the connection control policy on the client computer.
To enable the pre-defined Host Checker connection control policy:
1.
In the admin console, choose Authentication > Endpoint Security > Host Checker.
2. Under Options, select the Create Host Checker Connection Control Policy checkbox.
3. Click Save Changes. Secure Access enables the Host Checker connection control
policy.
NOTE: Note that you cannot modify this policy—only enable or disable it.
Also note that since you cannot modify this policy, Secure Access does
not display it in the Policies section of the Authentication > Endpoint
Security > Host Checker page with other configurable policies.
4. Implement the Host Checker connection control policy at the realm, role, or resource
policy levels.
You must evaluate or enforce the connection control policy at the realm level to make
the policy effective on client computers.
Related
Documentation
•
About Host Checker Restrictions on page 311
Creating and Configuring New Client-side Host Checker Policies
You can create a variety of policies through the Host Checker client that check for antivirus
software, firewalls, malware, spyware, and specific operating systems from a wide variety
of industry leaders. You can also create checks for custom third-party DLLs, ports,
processes, files, registry keys and the NetBIOS name, MAC addresses, or certificate of
the client machine.
When creating the policies, you must define the policy name, and either enable pre-defined
rules, or create custom rules that run the specified checks. Optionally, you can specify
how Host Checker should evaluate multiple rules within a single policy.
Copyright © 2011, Juniper Networks, Inc.
281
Secure Access Administration Guide
To create a standard client-side policy:
1.
In the admin console, choose Authentication > Endpoint Security > Host Checker.
2. Under Policies, click New.
3. Enter a name in the Policy Name field and then click Continue. (Users see this name
on the Host Checker remediation page if you enable custom instructions for this policy.)
4. Create one or more rules to associate with the policy.
5. Specify how Host Checker should evaluate multiple rules within the policy.
6. (Recommended) Specify remediation options for users whose computers do not
meet the requirements specified in the policy. (If you do not create remediation
instructions and the policy fails, your users will not know why they cannot access their
resources.)
7. Implement the policy at the realm, role, or resource policy levels.
Related
Documentation
•
Checking for Third-Party Applications Using Predefined Rules (Windows Only) on
page 282
•
Specifying Customized Requirements Using Custom Rules on page 290
•
Configuring General Host Checker Remediation on page 315
•
About Host Checker Restrictions on page 311
Checking for Third-Party Applications Using Predefined Rules (Windows Only)
Host Checker comes pre-equipped with a vast array of pre-defined rules that check for
antivirus software, firewalls, malware, spyware, and specific operating systems from a
wide variety of industry leaders. You can enable one or more of these rules within a Host
Checker client-side policy to ensure that the integrated third party applications that you
specify are running on your users’ computers in accordance with your specifications. For
firewall and antivirus rules, you can specify remediation actions to automatically bring
the endpoint into compliance.
To view the currently supported applications, go to Authentication > Endpoint Security
> Host Checker and create a new policy. You can choose predefined rule types from the
Select Rule Type drop down list box to see a list of the supported applications within
that category. The lists of applications can be quite extensive and are updated at each
support release, so it is useful to check the list periodically.
The following predefined rule types are available:
282
•
Predefined: AntiVirus—Select this option to create a rule that checks for the antivirus
software that you specify, and to specify remediation options.
•
Predefined: Firewall—Select this option to create a rule that checks for the firewall
software that you specify, and to specify remediation options.
•
Predefined: Malware—Select this option to create a rule that checks for the malware
protection software that you specify.
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
•
Predefined: AntiSpyware—Select this option to create a rule that checks for the
anti-spyware protection software that you specify.
•
Predefined: OS Checks—Select this option to create a rule that checks for the Windows
operating systems and minimum service pack versions that you specify. (Any service
pack whose version is greater than or equal to the version you specify satisfies the
policy.)
NOTE: If the underlying TNCC service is killed or stopped, the endpoint can
remain on the network, potentially out of compliance, until the next Host
Checker policy refresh.
This section details Predefined Malware and Predefined OS check. Predefined Antivirus,
Firewall and Malware checks are defined in sections that follow.
To create a Host Checker rule using Predefined Malware or Predefined OS Check rules:
1.
In the admin console, select Authentication > Endpoint Security > Host Checker.
2. Create a new policy or click on an existing policy in the Policies section of the page.
3. Under Rule Settings, choose one of the following options and click Add:
•
Predefined Malware
•
Predefined OS Checks
The predefined rule page opens.
4. In the Rule Name field, enter an identifier for the rule.
5. Under Criteria, select the specific malware or operating systems that you want to
check for and click Add. (When checking for an operating system, you may also specify
a service pack version.)
NOTE: When you select more than one type of software within a
pre-defined rule, Host Checker considers the rule satisfied if any of the
selected software applications are present on the user’s machine.
6. Under Optional, select Monitor this rule for change in result to continuously monitor
the policy compliance of endpoints. If this check box is selected, and a change in
compliance status on an endpoint that has successfully logged in occurs, Secure
Access initiates a new handshake to re-evaluate realm or role assignments.
7. Click Save Changes.
8. Optionally add additional rules to the policy, specify how Host Checker should evaluate
multiple rules within the policy, and define remediation options.
Related
Documentation
•
Creating and Configuring New Client-side Host Checker Policies on page 281
Copyright © 2011, Juniper Networks, Inc.
283
Secure Access Administration Guide
•
Configuring a Predefined Firewall Rule with Remediation Options (Windows Only) on
page 286
•
Configuring a Predefined Antivirus Rule with Remediation Options on page 284
•
Implementing Host Checker Policies on page 309
Configuring a Predefined Antivirus Rule with Remediation Options
You can configure antivirus remediation actions with Host Checker. You can specify a
requirement for the age (in days) of the last successful virus scan, and you can specify
that virus signatures installed on client machines should not be older than a specified
number of updates.
You can also monitor policies to ensure that logged-in endpoints maintain compliance
status, and remediate the endpoint to another role or realm depending on the current
status.
If a client attempts to log in, and the client machine does not meet the requirements you
specify, Host Checker can attempt to correct the deficiencies to allow the client to
successfully log in. With Host Checker antivirus remediation, you can prompt the endpoint
to download the latest virus signature files, turn on antivirus protection, and initiate an
antivirus scan.
All of the remediation options are not supported for all antivirus software vendors’
products. All available vendors and products that are supported are displayed when you
select the Require any supported product option button.
Alternately, you can select the Require specific products/vendors option button and
select either the Require any supported product from a specific vendor or Require specific
products check boxes, then add an available type to Selected Types. The remediation
options appear, and you can determine which remediation options are available for
specific products or vendors
To configure a Predefined Antivirus rule:
1.
In the admin console, select Authentication > Endpoint Security > Host Checker.
2. Create a new policy or click on an existing policy in the Policies section of the page.
3. Under Rule Settings, choose Predefined: Antivirus and click Add.
4. Enter the Rule Name for this antivirus rule.
5. To determine if your software vendor’s product is supported for the System Scan
check, click these Antivirus products. A new window will open with a list of all of the
products that support the feature.
6. Select or clear the check box next to Successful System Scan must have been
performed in the last _ days, and enter the number of days in the field.
If you select this check box, a new option appears. If the remediation action to start
an antivirus scan has been successfully begun, you can override the previous check.
284
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
7. Select or clear the check box next to Consider this rule as passed if ‘Full System
Scan’ was started successfully as remediation.
8. Select or clear the check box next to Virus definition files should not be older than
_ updates. Enter a number between 1 and 10. If you enter 1, the client must have the
latest update. You must import the virus signature list for the supported vendor.
9. Select your antivirus vendor(s) and product(s) by using either the Require any
supported product or Require specific products/vendors option buttons.
Require any supported product allows you to check for any product (rather than
requiring you to select every product separately). This option button reveals a list of
products in the remediation section to allow you to enable remediation options which
are product specific.
Require specific products/vendors allows you to define compliance by allowing any
product by a specific vendor (for example, any Symantec product).
Require specific products provides functionality that allows you to select individual
products to define compliance.
After you select your vendor(s) and product(s), remediation options will appear on
the page.
For each of the following remediation actions:
•
Download latest virus definition files—obtains the latest available file for the
specified vendor from the vendor’s website
•
Turn on Real Time Protection—launches the virus scanning mechanism for the
specified vendor
•
Start Antivirus Scan—performs a real-time virus scan for the specified vendor
the check box is active (clickable) if the action is supported for your product.
If your antivirus product is not supported, you can click the remediation column
headers to determine what vendors and products are supported.
10. If your product is supported, select the check box for any or all of the remediation
actions that you want to apply.
11. Under Optional, select Monitor this rule for change in result to continuously monitor
the policy compliance of endpoints. If this check box is selected, and a change in
compliance status on an endpoint that has successfully logged in occurs, Secure
Access initiates a new handshake to re-evaluate realm or role assignments.
12. Click Save Changes to save the antivirus rule and enforce antivirus remediation.
13. Optionally add additional rules to the policy, specify how Host Checker should evaluate
multiple rules within the policy, and define remediation options.
Related
Documentation
•
Configuring Virus Signature Version Monitoring and Patch Assessment Data Monitoring
on page 288
•
Creating and Configuring New Client-side Host Checker Policies on page 281
Copyright © 2011, Juniper Networks, Inc.
285
Secure Access Administration Guide
•
Implementing Host Checker Policies on page 309
Configuring a Predefined Firewall Rule with Remediation Options (Windows Only)
You can configure firewall remediation actions with Host Checker after you create a Host
Checker firewall rule that requires the endpoint to have a specific firewall installed and
running prior to connecting to the network.
After you enforce the Host Checker rule with firewall remediation actions, if an endpoint
attempts to log in without the required firewall running, Host Checker can attempt to
enable the firewall on the client machine.
The remediation option is not supported for all firewall products. All available products
are displayed by using the Require any supported product or Require specific
products/vendors option buttons.
To configure a Host Checker Predefined Firewall rule:
1.
In the admin console, choose Authentication > Endpoint Security > Host Checker.
2. Create a new policy or click an existing policy in the Policies section of the page.
3. Under Rule Settings, choose Predefined: Firewall and click Add.
4. Enter a Rule Name for the firewall rule.
5. Select your firewall vendor(s) and product(s) by using either the Require any
supported product or Require specific products/vendors option buttons.
Require any supported product allows you to check for any product (rather than
requiring you to select every product separately). This option button reveals a list of
products in the remediation section to allow you to enable remediation options which
are product specific.
When you add an available product to Selected Products, the remediation option
appears, and you can determine if the remediation option is available for your selected
firewall.
Require specific products/vendors allows you to define compliance by allowing any
product by a specific vendor (for example, any Symantec product).
Require specific products provides functionality that allows you to select individual
products to define compliance.
After you select your vendor(s) and product(s), the remediation options will appear
on the page. The Turn on Firewall check box is active (clickable) if the action is
supported for your product.
6. If your firewall is supported, select the check box to Turn on Firewall.
7. Under Optional, select Monitor this rule for change in result to continuously monitor
the policy compliance of endpoints. If this check box is selected, and a change in
compliance status on an endpoint that has successfully logged in occurs, Secure
Access initiates a new handshake to re-evaluate realm or role assignments.
286
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
8. Click Save Changes to save the firewall rule and enforce firewall remediation.
9. Optionally add additional rules to the policy, specify how Host Checker should evaluate
multiple rules within the policy, and define remediation options.
Related
Documentation
•
Creating and Configuring New Client-side Host Checker Policies on page 281
•
Implementing Host Checker Policies on page 309
Configuring a Pre-defined AntiSpyware Rule (Windows Only)
You can configure Host Checker to check for installed antispyware on endpoints.
After you enforce the Host Checker rule, if an endpoint attempts to log in without the
required spyware, the Host Checker rule will fail.
The option is not supported for all spyware products. All available products are displayed
by using the Require any supported product or Require specific products/vendors option
buttons.
To configure a Host Checker Predefined Spyware rule:
1.
In the admin console, select Authentication > Endpoint Security > Host Checker.
2. Create a new policy or click an existing policy in the Policies section of the page.
3. Under Rule Settings, choose Predefined: AntiSpyware and click Add.
4. Enter a Rule Name for the firewall rule.
5. Select one of the following options:
•
Select the Require any supported product option button to check for any product
(rather than requiring you to select every product separately).
•
Select the Require specific products/vendors option button to specify the spyware
that you want to check for.
•
Choose either the Require any supported product from a specific vendor or
Require specific products to specify spyware.
•
Add antispyware from Available Products to Selected Products.
6. Under Optional, select Monitor this rule for change in result to continuously monitor
the policy compliance of endpoints. If this check box is selected, and a change in
compliance status on an endpoint that has successfully logged in occurs, Secure
Access initiates a new handshake to re-evaluate realm or role assignments.
7. Click Save Changes.
8. Optionally add additional rules to the policy, specify how Host Checker should evaluate
multiple rules within the policy, and define remediation options.
Related
Documentation
•
Creating and Configuring New Client-side Host Checker Policies on page 281
Copyright © 2011, Juniper Networks, Inc.
287
Secure Access Administration Guide
•
Implementing Host Checker Policies on page 309
Configuring Virus Signature Version Monitoring and Patch Assessment Data Monitoring
You can configure Host Checker to monitor and verify that the virus signatures, operating
systems, software versions, and patches installed on client computers are up to date,
and remediate those endpoints that do not meet the specified criteria. Host Checker
uses the current virus signatures and patch assessment versions from the vendor(s) you
specify for pre-defined rules in a Host Checker policy.
You can automatically import the current Virus signature version monitoring or Patch
Management Info Monitoring lists from the Juniper Networks staging site at a specified
interval, or you can download the files from Juniper and use your own staging server.
You can also configure a proxy server as a staging site between Secure Access and the
Juniper site. To use a proxy server, you enter the servers network address, port and
authentication credentials, if applicable.
To access the Juniper Networks staging site for updates, you must enter the credentials
for your Juniper Networks Support account.
To configure Secure Access to automatically import the current virus signature version
monitoring and patch management version monitoring list(s) from the Juniper staging
site:
1.
Choose Authentication > Endpoint Security > Host Checker.
2. Click Virus signature version monitoring, or Patch Management Info Monitoring.
3. Select Auto-update virus signatures list or Auto-update Patch Management data.
4. For Download path, leave the existing URL(s) of the staging site(s) where the current
list(s) are stored. The default URLs are the paths to the Juniper Networks staging site:
https://download.juniper.net/software/av/uac/epupdate_hist.xml
(for auto-update virus signatures list)
https://download.juniper.net/software/hc/patchdata/patchupdate.dat
(for auto-update patch management)
5. For Download interval, specify how often you want Secure Access to automatically
import the current list(s).
6. For Username and Password, enter your Juniper Networks Support credentials.
7. Click Save Changes.
To manually import the current virus signature version monitoring and patch management
version monitoring list(s):
1.
Choose Authentication > Endpoint Security > Host Checker.
2. Click Virus signature version monitoring, or Patch Management Info Monitoring.
288
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
3. Download the list(s) from the Juniper staging site to a network server or local drive
on your computer by entering the Juniper URLs in a browser window.
https://download.juniper.net/software/av/uac/epupdate_hist.xml
https://download.juniper.net/software/hc/patchdata/patchupdate.dat
4. Under Manually import virus signatures list, click Browse, select the list, and then click
OK.
5. Click Save Changes.
NOTE: If you use your own staging site for storing the current list(s), you must
upload the trusted root certificate of the CA that signed the staging’s server
certificate to Secure Access.
To use a proxy server as the auto-update server:
1.
Choose Authentication > Endpoint Security > Host Checker.
2. Click Virus signature version monitoring, or Patch Management Info Monitoring.
3. Select Auto-update virus signatures list or Auto-update Patch Management data.
4. For Download path, leave the existing URL(s) of the staging site(s) where the current
list(s) are stored. The default URLs are the paths to the Juniper Networks staging site:
https://download.juniper.net/software/av/uac/epupdate_hist.xml
(for auto-update virus signatures list)
https://download.juniper.net/software/hc/patchdata/patchupdate.dat
(for auto-update patch management)
5. For Download interval, specify how often you want Secure Access to automatically
import the current list(s).
6. For Username and Password, enter your Juniper Networks Support credentials.
7. Select the check box for Use Proxy Server.
8. Enter the IP Address of your proxy server.
9. Enter the Port that the Juniper Networks Support site will use to communicate with
your proxy server.
10. If your proxy server is password protected, type the Username and Password of the
proxy server.
11. Click Save Changes.
Related
Documentation
•
Uploading Trusted Server CA Certificates on page 743
•
Implementing Host Checker Policies on page 309
Copyright © 2011, Juniper Networks, Inc.
289
Secure Access Administration Guide
Specifying Customized Requirements Using Custom Rules
In addition to the predefined policies and rules that come with Secure Access, you can
create custom rules within a Host Checker policy to define requirements that your users’
computers must meet. Using custom rules, you can:
•
Configure remote integrity measurement verifiers (IMVs) to perform customized
client-side checks.
•
Configure Host Checker to check for custom DLLs that perform customized client-side
checks.
•
Verify that certain ports are open or closed on the user’s computer.
•
Confirm that certain processes are or are not running on the user’s computer.
•
Check that certain files are or are not present on the client machine.
•
Evaluate the age and content of required files through MD5 checksums.
•
Confirm that registry keys are set on the client machine.
•
Confirm the NETBIOS name of the client machine.
•
Confirm the MAC addresses of the client machine.
•
Check the validity of the machine certificate that is installed on the user's computer.
NOTE: You can only check for registry keys, third-party DLLs, NETBIOS names,
MAC addresses, and machine certificates on Windows computers.
To create a client-side Host Checker policy:
1.
In the admin console, select Authentication > Endpoint Security > Host Checker.
2. Create a new policy or click an existing policy in the Policies section of the page.
3. Click the tab that corresponds to the operating system for which you want to specify
Host Checker options—Windows, Mac, Linux or Solaris. In the same policy, you can
specify different Host Checker requirements on each operating system. For example,
you can create one policy that checks for different files or processes on each operating
system.
NOTE: You must explicitly create policies for each operating system you
want to allow. For example, if you create a Windows Host Checker policy,
but don't create one for Mac or Linux, users who sign into Secure Access
from a Mac or Linux machine will not comply with the Host Checker policy
and therefore will not be able to access the realm, role, or resource on
which you enforce Host Checker.
4. Under Rule Settings, choose the options in the following sections and click Add. The
Add Custom Rule page for the rule type appears.
290
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
•
Custom: Remote IMV—Use this rule type to configure integrity measurement
software that a client must run to verify a particular aspect of the client’s integrity,
such as the client’s operating system, patch level, or virus protection.
•
3rd Party NHC Check (Windows only)—Use this rule type to specify the location
of a custom DLL. Host Checker calls the DLL to perform customized client-side
checks. If the DLL returns a success value to Host Checker, then Secure Access
considers the rule met. In the 3rd Party NHC Check configuration page:
a. Enter a name and vendor for the 3rd Party NHC Check rule
b. Enter the location of the DLL on client machines (path and file name).
c. Click Save Changes.
The 3rd Party NHC Check feature is primarily provided for backwards
compatibility. We recommend that you use IMCs and IMVs instead
•
Ports—Use this rule type to control the network connections that a client can
generate during a session. This rule type ensures that certain ports are open or
closed on the client machine before the user can access Secure Access. In the Ports
configuration page:
a. Enter a name for the port rule.
b. Enter a comma delimited list (without spaces) of ports or port ranges, such as:
1234,11000-11999,1235.
c. Select Required to require that these ports are open on the client machine or
Deny to require that they are closed.
d. Under Optional, select Monitor this rule for change in result to continuously
monitor the policy compliance of endpoints. If this check box is selected, and a
change in compliance status on an endpoint that has successfully logged in
occurs, Secure Access initiates a new handshake to re-evaluate realm or role
assignments.
e. Click Save Changes.
•
Process—Use this rule type to control the software that a client may run during a
session. This rule type ensures that certain processes are running or not running on
the client machine before the user can access resources protected by Secure Access.
In the Processes configuration page:
a. Enter a name for the process rule.
b. Enter the name of a process (executable file), such as: good-app.exe.
NOTE: For Linux, Macintosh and Solaris systems, the process that
is being detected must be started using an absolute path.
You can use a wildcard character to specify the process name.
Copyright © 2011, Juniper Networks, Inc.
291
Secure Access Administration Guide
For example: good*.exe
c. Select Required to require that this process is running or Deny to require that
this process is not running.
d. Specify the MD5 checksum value of each executable file to which you want the
policy to apply (optional). For example, an executable may have different MD5
checksum values on a desktop, laptop, or different operating systems. On a
system with OpenSSL installed—many Macintosh, Linux and Solaris systems
have OpenSSL installed by default—you can determine the MD5 checksum by
using this command: openssl md5 <processFilePath>
e. Click Save Changes.
•
File—Use this rule type to ensure that certain files are present or not present on the
client machine before the user can access Secure Access. You may also use file
checks to evaluate the age and content (through MD5 checksums) of required files
and allow or deny access accordingly. In the Files configuration page:
a. Enter a name for the file rule.
b. Enter the name of a file (any file type), such as: c:\temp\bad-file.txt or
/temp/bad-file.txt.
You can use a wildcard character to specify the file name. For example:
*.txt
You can also use an environment variable to specify the directory path to the
file. (You cannot use a wildcard character in the directory path.) Enclose the
variable between the <% and %> characters. For example:
<%windir%>\bad-file.txt
c. Select Required to require that this file is present on the client machine or Deny
to require that this file is not present.
d. Specify the minimum version of the file (optional). For example, if you require
notepad.exe to be present on the client, you can enter 5.0 in the field. Host
Checker accepts version 5.0 and above, of notepad.exe.
e. Specify the maximum age (File modified less than n days) (in days) for a file
(optional). If the file is older than the specified number of days, then the client
does not meet the attribute check requirement.
NOTE: You can use the maximum age option to check the age of
virus signatures. Make sure you specify the path to a file in the File
Name field whose timestamp indicates when virus signatures were
last updated, such as a virus signature database or log file that
updates each time the database updates. For example, if you use
TrendMicro, you may specify:
C:\Program Files\Trend Micro\OfficeScan Client\TmUpdate.ini.
292
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
f.
Specify the MD5 checksum value of each file to which you want the policy to
apply (optional). On Macintosh, Linux and Solaris, you can determine the MD5
checksum by using this command: openssl md5<filePath>
g. Select Monitor this rule for change in result to continuously monitor the policy
compliance of endpoints. If this check box is selected, and a change in compliance
status on an endpoint that has successfully logged in occurs, Secure Access
initiates a new handshake to re-evaluate realm or role assignments.
h. Click Save Changes.
•
Registry Setting (Windows only)—Use this rule type to control the corporate PC
images, system configurations, and software settings that a client must have to
access Secure Access. This rule type ensures that certain registry keys are set on
the client machine before the user can access Secure Access. You may also use
registry checks to evaluate the age of required files and allow or deny access
accordingly. In the Registry Settings configuration page:
a. Enter a name for the registry setting rule.
b. Select a root key from the drop-down list.
c. Enter the path to the application folder for the registry subkey.
d. Enter the name of the key’s value that you want to require (optional). This name
appears in the Name column of the Registry Editor.
e. Select the key value’s type (String, Binary, or DWORD) from the dropdown list
(optional). This type appears in the Type column of the Registry Editor.
f.
Specify the required registry key value (optional). This information appears in
the Data column of the Registry Editor.
If the key value represents an application version, select Minimum version to
allow the specified version or newer versions of the application. For example,
you can use this option to specify version information for an antivirus application
to make sure that the client antivirus software is current. Secure Access uses
lexical sorting to determine if the client contains the specified version or higher.
For example:
3.3.3 is newer than 3.3
4.0 is newer than 3.3
4.0a is newer than 4.0b
4.1 is newer than 3.3.1
NOTE: If you specify only the key and subkey, Host Checker simply
verifies the existence of the subkey folder in the registry.
g. Under Optional, select Monitor this rule for change in result to continuously
monitor the policy compliance of endpoints. If this check box is selected, and a
Copyright © 2011, Juniper Networks, Inc.
293
Secure Access Administration Guide
change in compliance status on an endpoint that has successfully logged in
occurs, Secure Access initiates a new handshake to re-evaluate realm or role
assignments.
You can configure registry setting remediation actions with Host Checker. If a
client attempts to login, and the client machine does not meet the requirements
you specify, Host Checker can attempt to correct the discrepancies to allow the
client to login.
h. Select the check box for Set Registry value specified in criteria.
i.
•
Click Save Changes.
NetBIOS (Windows only, does not include Windows Mobile)—Use this rule type
to check the NetBIOS name of the client machine before the user can access Secure
Access. In the NetBIOS configuration page:
a. Enter a name for the NetBIOS rule.
b. Enter a comma-delimited list (without spaces) of NetBIOS names. The name
can be up to 15 characters in length. You can use wildcard characters in the name
and it is not case-sensitive. For example, md*, m*xp and *xp all match MDXP.
c. Select Required to require that NETBIOS name of the client machine match one
of the names you specify, or Deny to require that the name does not match any
name.
d. Click Save Changes.
•
MAC Address (Windows only)—Use this rule type to check the MAC addresses of
the client machine before the user can access Secure Access. In the MAC Address
configuration page:
a. Enter a name for the MAC address rule.
b. Enter a comma-delimited list (without spaces) of MAC addresses in the form
XX:XX:XX:XX:XX:XX where the X’s are hexadecimal numbers. For example:
00:0e:1b:04:40:29
You can use a * wildcard character to represent a two-character section of the
address. For example, you can use a * to represent the “04”, “40”, and “29”
sections of the previous example address:
00:0e:1b:*:*:*
But you cannot use a * to represent a single character. For example, the * in the
following address is not allowed:
00:0e:1b:04:40:*9
c. Select Required to require that a MAC address of the client machine matches
any of the addresses you specify, or Deny to require that the all addresses do
not match. A client machine will have at least one MAC address for each network
connection, such as Ethernet, wireless, and VPN. This rule’s requirement is met
294
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
if there is a match between any of the addresses you specify and any MAC address
on the client machine.
d. Click Save Changes.
NOTE: Since the MAC address is changeable on some network cards,
this check may not guarantee that a client machine meets the
requirements of your Host Checker policy.
•
Machine Certificate (Windows only)—Use this rule type to check that the client
machine is permitted access by validating the machine certificate stored on the
client machine. In the Machine Certificate configuration page:
a. Enter a name for the machine certificate rule.
b. From the Select Issuer Certificate list, select the certificate that you want to
retrieve from the user’s machine and validate. Or, select Any Certificate to skip
the issuer check and only validate the machine certificate based on the optional
criteria that you specify below.
c. From the Optional fields (Certificate field and Expected value), specify any
additional criteria that Host Checker should use when verifying the machine
certificate.
d. Click Save Changes.
NOTE: If more than one certificate is installed on the client machine
that matches the specified criteria, The Host Checker client passes
the first certificate it finds to Secure Access for validation.
5. Optionally add additional rules to the policy, specify how Host Checker should evaluate
multiple rules within the policy, and define remediation options.
Related
Documentation
•
Implementing Host Checker Policies on page 309
•
Task Summary: Configuring Host Checker on page 275
•
Using a Wildcard or Environment Variable in a Host Checker Rule on page 295
Using a Wildcard or Environment Variable in a Host Checker Rule
You can use the following wildcards to specify a file name in a Custom File rule or a
process name in a Custom Process rule:
Copyright © 2011, Juniper Networks, Inc.
295
Secure Access Administration Guide
Table 17: Wildcard Characters for Specifying a File Name or Process Name
Wildcard Character
Description
Example
*
Matches any character
*.txt
?
Matches exactly one character
app-?.exe
In a Custom File rule for Windows, you can use the following environment variables to
specify the directory path to a file:
Table 18: Environment Variables for Specifying a Directory Path on
Windows
Environment variable
Example Windows Value
<%APPDATA%>
C:\Documents and Settings\jdoe\Application Data
<%windir%>
C:\WINDOWS
<%ProgramFiles%>
C:\Program Files
<%CommonProgramFiles%>
C:\Program Files\Common Files
<%USERPROFILE%>
C:\Documents and Settings\jdoe
<%HOMEDRIVE%>
C:
<%Temp%>
C:\Documents and Settings \<user name>\Local
Settings\Temp
In a Custom File rule for Macintosh, Linux and Solaris, you can use the following
environment variables to specify the directory path to a file:
Table 19: Environment Variables for Specifying a Directory Path on
Macintosh, Linux and Solaris
296
Environment variable
Example Macintosh Value
Example Linux and Solaris
Values
<%java.home%>
/System/Library/Frameworks/JavaVM.framework/
Versions/1.4.2/Home
/local/local/java/j2sdk1.4.1_02/
jre
<%java.io.tmpdir%>
/tmp
/tmp
<%user.dir%>
/Users/admin
/home-shared/cknouse
<%user.home%>
/Users/admin
/home/cknouse
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
NOTE: Although environment variables are formatted in the same way as
Toolkit Template directives, they are not interchangeable and you should
not confuse them.
Related
Documentation
•
Specifying Customized Requirements Using Custom Rules on page 290
•
Implementing Host Checker Policies on page 309
Configuring Patch Assessment Policies
You can configure Host Checker policies that check for Windows endpoint’s operating
system service pack, software version, or desktop application patch version compliance.
Host Checker uses a list of the most current patch versions from the vendor for predefined
rules in the Host Checker policy.
You obtain the most current patch version information from a staging site at Juniper
Networks. You can manually download and import the current list into the SA, or you
can automatically import the current list from the Juniper Networks staging site or your
own staging site at the specified interval.
Checks can be based on one or more specified products or on specific patches, though
not in the same policy. For example, you could check for Internet Explorer version 7 with
one policy, and Patch MSOO-039: SSL Certificate Validation Vulnerabilities with a second
policy. Then, apply both policies to endpoints at the role or realm level to ensure that the
user has the latest browser version with a specific patch. Additionally, you can specify
the severity level of patches that you wish to ignore for Microsoft products; for example,
you could choose to ignore low or moderate threats.
The SA can send remediation instructions (e.g. a message describing what patches or
software are non-compliant, and a link to where the endpoint can obtain the patch). The
SA does not auto-remediate in the event of a non-compliant endpoint. However, you
can choose to send the items to the client for manual remediation of managed machines.
When an endpoint first connects to the SA, the latest versions of the data files and libraries
of the IMC are downloaded to the host computer. The initial check takes 10- 20 seconds
to run, depending on the link speed. If outdated, these files are automatically updated
at subsequent checks. If this is the first time the endpoint has connected to an SA with
the patch assessment policy, and the connection is a Layer 2 connection, the IMC required
to run the Patch Assessment check cannot download. In this case, you should configure
a remediation role which displays instructions to direct the user to retry with a Layer 3
connection or contact the administrator.
Note that in non-English installations, the English version of local patches is displayed.
Using a System Management Server
For Windows clients, you can use a System Management Server (SMS) to provide a
method for automatic updates to non-compliant software.
Copyright © 2011, Juniper Networks, Inc.
297
Secure Access Administration Guide
Endpoints configured with SMS for software management typically poll the server for
updates every fifteen minutes or longer. In a worst-case scenario, clients that are not in
compliance with existing Host Checker software requirements may have to wait until
the next update interval to login.
Using the SMS remediation feature, you can force the client to initiate the software update
immediately after the patch assessment check.
If a user attempts to log in, and the endpoint does not have a required software version
for compliance with a Host Checker patch assessment policy, Host Checker immediately
notifies the client to poll the server for an immediate update. The client receives
notification that an SMS update has started.
To have the SMS update the client when notified, set the advertisement time on the SMS
to As soon as possible.
•
The SA patch assessment policy specifies the required software.
•
When an endpoint attempts to authenticate, Host Checker evaluates the client and
sends the results back to the SA.
•
The SA evaluates the results and sends reason strings and remediation information
to the client, including a message that directs the client to poll the server for software
advertisements immediately.
•
The SMS client queries the SMS server for software advertisements.
•
The server identifies what patches should be advertised to the client (this is configured
on the server, Host Checker does not interact with the server).
•
The SMS client receives the advertisement and applies the required patch(es).
You assign clients to a particular group or collection on the server, then the SMS can
advertise patches for that collection. You can configure roles on the SA that correspond
to collections, and SMS can send the appropriate patches for a particular role.
You must have the SMS client installed and configured correctly on endpoints, and the
SMS server must be reachable. In a Layer 2 network, Host Checker is performed before
the endpoint is connected to the network. Host Checker can obtain the IP address of the
SMS server configured for the client. If the endpoint is out of compliance and remediation
is necessary, Host Checker pings the server IP address every 15 seconds until the server
can be notified to update the client.
It is important as an administrator to inform users of the expected behavior if this feature
is enabled, as there is no notification to the user until SMS sends back the advertisement.
Related
Documentation
298
•
Configuring Patch Assessment Rules on page 299
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
Configuring Patch Assessment Rules
To configure a patch assessment custom rule:
1.
In the admin console, select Authentication > Endpoint Security > Host Checker.
2. Create a new policy or click on an existing policy in the Policies section of the page.
3. Click the Windows tab.
4. Under Rule Settings, choose Custom: Patch assessment.
5. Click Add under Rule Settings. The Add Custom Rule:Patch assessment page appears.
6. Enter a name for the integrity measurement rule.
NOTE: If a selection that is not applicable is included in a policy, i.e. the
endpoint does not have the targeted software, the rule will be ignored and
the check for that particular selection will pass.
7. Select either Scan for specific products or Scan for specific patches.
If you select Scan for specific products you must further select either All Products or
Specific Products.
If you select All Products, Host Checker checks for all of the exposed patches on the
endpoint.
To configure a policy based on specific products:
a. Choose the All Products option button.
b. Optionally, select specific patches that you wish to ignore for all products by clicking
the Add button under Ignore following patches.
c. Click Save Changes.
d. Optionally, for Microsoft products, clear the check boxes to determine the severity
level of the patches that you wish to ignore. For example, if you wanted to check
for only critical patches for the selections, clear the check boxes for Important,
Moderate, Low, and Unspecified.
e. Click Save Changes.
If you select Specific Products, two new dialogs open. You can select from an extensive
listing of products and versions, and you can choose to ignore specific patches.
For example, if you add Internet Explorer 6 to the Selected Products list, you can
choose to ignore any patches that you do not consider critical for the product. You
Copyright © 2011, Juniper Networks, Inc.
299
Secure Access Administration Guide
can further fine-tune the severity level of specific patches to be ignored by clearing
the severity check boxes for Microsoft products.
To configure a policy based on specific products:
a. Choose the Specific Products option button.
b. Select software from the Available products window and add to the Selected
products window.
c. Click Save Changes.
d. Optionally, select specific patches that you wish to ignore for the chosen products
by clicking the Add button under Ignore following patches.
When you click the Add button, a new dialog opens, displaying all of the available
patches for the software you have selected.
e. Select specific patches that you wish to ignore from the Available patches window
and add to the Selected patches window.
f.
Click the Add button under Add.
When you click the Add button, the Ignore following patches window is populated
with the patches you have chosen.
g. Optionally, for Microsoft products, clear the check boxes to determine the severity
level of the patches that you wish to ignore. For example, if you wanted to check
for only critical patches for the selections, clear the check boxes for Important,
Moderate, Low, and Unspecified.
NOTE: The severity level check boxes only apply to Microsoft products.
For other vendors, such as Adobe, the Unspecified check box determines
whether or not the check will be run.
h. Click Save Changes.
The Scan for specific patches option allows you to choose from a list of all available
patches.
To configure a policy based on patches:
a. Choose the Scan for specific patches option button.
When you select the Scan for specific patches option a new dialog opens, allowing
you to add specific patches.
b. Click the Add button.
c. Select specific patches that you wish to check for from the Available patches
window and add to Selected patches.
300
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
d. Click the Add button.
e. Click Save Changes.
8. Click Save Changes.
9. To direct the SA to notify the SMS server to update the client in the event of a failed
Patch Assessment rule, select Enable SMS patch update. SMS remediation will be
triggered each time Host Checker detects that an endpoint is not compliant.
10. Click Save Changes.
You can display remediation information for users based on which patch/version
needs to be updated. For example, you can configure a reason string to display
information about a patch that is missing and specify a link to take the user to the
web page to get the patch.
11. To display remediation information to users, select the Send Reason Strings option
under Remediation on the main Host Checker Policy page.
Related
Documentation
•
Configuring Patch Assessment Policies on page 297
•
Implementing Host Checker Policies on page 309
Using Third-party Integrity Measurement Verifiers
The Trusted Network Connect (TNC) standard enables the enforcement of security
requirements for endpoints connecting to networks. The client-side components of the
TNC are the IMCs and the TNC-client (TNCC). The TNCC compiles the IMC measurements
and sends them to the server. At the server, there is a corresponding set of components:
the TNC-server (TNCS) and the IMVs. The TNCS manages the messages between the
IMVs and the IMCs and sends the recommendations, based on the IMVs, to the policy
engine. This type of rule is available for Host Checker policies on all platforms.
Secure Access and Host Checker comply with the standards produced by the TNC. For
more information about the TNC, IMVs and IMCs, see www.trustedcomputinggroup.org.
You can configure Host Checker to monitor third-party TNC-compliant IMCs installed
on client computers. To do so, you must:
1.
Run the Third-party Integrity Measurement Verifier (IMV) Server installer on the system
designated as the remote IMV server. Install the third-party IMVs and create the server
certificates.
2. Specify the remote IMV server so that Secure Access can communicate with it.
3. Implement the Host Checker policy.
Related
Documentation
•
Configuring a Remote IMV Server on page 302
•
Implementing the Third-Party IMV Policy on page 308
Copyright © 2011, Juniper Networks, Inc.
301
Secure Access Administration Guide
Configuring a Remote IMV Server
NOTE:
•
In an Active/Passive cluster, the Active/Passive nodes' individual IP
addresses must be added to the RIMV as the Secure Access IP addresses.
•
The successful addition of remote IMV server is not logged in the event log.
•
When Host Checker fails, custom instructions are not displayed. There is
no user access log on Secure Access about Host Checker failure.
During this step, you install third-party IMVs. Third-party IMVs are installed on the remote
IMV server, not on Secure Access.
During this step, you also obtain a server certificate for the remote IMV server. You import
the trusted root CA certificate of the CA that generated the server certificate onto Secure
Access. Secure Access then authenticates with the remote IMV server through the
certificate. If you do not have a certificate authority, install and use OpenSSL to generate
a CA certificate.
To install, configure, and implement the server software:
1.
In the admin console of Secure Access, choose Maintenance > System > Installers
and download the Third-party Integrity Measurement Verifier (IMV) Server installer.
2. Run the installer on the system designated as the remote IMV server.
3. Install the third-party IMVs on the remote IMV server and the corresponding IMCs on
the client systems.
4. Generate a server certificate from a certificate authority for the remote IMV server.
The server’s certificate Subject CN value must contain the actual host name or IP
address of the remote IMV server.
The server certificate and the private key must be combined into a single PKCS#12
file and encrypted with a password.
If you do not have a certificate authority, you can use the following steps to create a
CA and then create a server certificate for the remote IMV server.
NOTE: Install the full version of OpenSSL. The "light" version of OpenSSL
will not work.
Follow the steps below to set up OpenSSL:
a. Download and install OpenSSL from this site:
http://www.slproweb.com/products/Win32OpenSSL.html
b. At the Windows command prompt, type the following commands:
302
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
cd \openssl
md certs
cd certs
md demoCA
md demoCA\newcerts
edit demoCA\index.txt
c. Press the ALT-F keys and then the S key to save the file.
d. Press the ALT-F keys and then the X key to exit the editor.
e. At the Windows command prompt, type the following commands:
edit demoCA\serial
f.
Type the following in the document window: 01
g. Press the ALT-F keys and then the S key to save the file.
h. Press the ALT-F keys and then the X key to exit the editor.
i.
At the Windows command prompt, type the following commands:
Copyright © 2011, Juniper Networks, Inc.
303
Secure Access Administration Guide
set path=c:\openssl\bin;%path%
Follow the steps below to create a CA key:
a. To create a CA key, type the following command at the Windows command prompt
in the c:\openssl\certs directory:
openssl genrsa -out ca.key 1024
The following output should appear:
Loading 'screen' into random state - done
Generating RSA private key, 1024 bit long modulus
........++++++
.++++++
e is 65537 (0x10001
Follow the steps below to create a CA Certificate:
a. Type the following command at the Windows command prompt in the
c:\openssl\certs directory:
openssl req -new -x509 -days 365 -key ca.key -out
demoCA/cacert.pem
b. Enter the appropriate Distinguished Name (DN) information for the CA certificate.
You can leave some fields blank by entering a period.
For example:
Country Name: US
State or Province Name: CA
Locality Name: Sunnyvale
Organization Name: XYZ
Org. Unit Name: IT
Common Name: ic.xyz.com
Email Address: user@xyz.com
c. To set up the CA, type the following command at the Windows command prompt
in the directory c:\openssl\certs:
copy ca.key demoCA
notepad demoCA.cnf
304
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
d. When prompted to create a new file, press the yes button.
e. Type the following lines in the document, pressing the Enter key at the end of each
line.
[ca]
default_ca = demoCA
[demoCA]
dir = ./demoCA
database = $dir/index.txt
new_certs_dir = $dir/newcerts
certificate = $dir/cacert.pem
serial = $dir/serial
private_key = $dir/ca.key
default_days = 365
default_md = md5
policy = policy_any
email_in_dn = no
name_opt = ca_default
name_opt = ca_default
copy_extensions = none
[ policy_any ]
countryName = supplied
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
Copyright © 2011, Juniper Networks, Inc.
305
Secure Access Administration Guide
f.
Save the file and close notepad.
g. Type the following command to generate an RSA private key for the remote IMV
server:
openssl genrsa –out rimvs_key.pem 1024
h. Type the following command to generate a CSR for the remote IMV server:
openssl req –new –key rimvs_key.pem –out rimvs_csr.pem
i.
Type the following lines:
Country Name:
State or Province Name:
Locality Name:
Organization Name:
Organizational Unit Name:
Common Name: [IPAddress]
Email Address:
A challenge password:
An optional company name:
You may enter any value you like for most fields, but the Common Name field must
contain the IP address of the machine running the remote IMV server. This machine
should have a static IP address.
j.
Type the following command to generate a certificate for the remote IMV server:
openssl ca –config demoCA.cnf –in rimvs_csr.pem –out rimvs_cert.pem
k. Type ‘y’ twice when prompted to generate the certificate. This certificate is valid
for 365 days by default. If you want a different certificate lifetime, change the
default_days parameter in the demoCA.cnf file, or use the – days parameter to the
openssl ca command to specify a different lifetime.
l.
Type the following command to place the remote IMV server key and certificate
in a PKCS#12 file (substitute your password):
openssl pkcs12 –export –in rimvs_cert.pem –inkey rimvs_key.pem –passout
pass:<password>-out rimvs_p12.pem
5. On the remote IMV server, choose Programs > Juniper Networks > Remote IMV Server
> Remote IMV Server Configurator from the Start menu.
6. Under Client Info, click Add.
7. Configure the port to service SOAP requests from Secure Access.
306
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
8. Enter the client’s IP address, the number of addresses to use, and the shared secret
used by both Secure Access and the remote IMV server.
9. Change logging settings if you choose (log is generated in the install directory).
10. Browse and find the PKCS#12 file you generated in the filesystem.
11. Specify the password associated with the certificate.
12. In the admin console of Secure Access, use the System > Configuration > Certificates
> Trusted Server CAs tab to import the trusted root CA certificate of the CA that
issued the certificate for the remote IMV server.
If you used OpenSSL to generate the Remote IMV Server’s server certificate is:
demoCA\cacert.pem.
If you did not use OpenSSL to generate this certificate, ensure that the file you import
has the CA certificate (not the root certificate).
13. Click Import Trusted Server CA and browse for the server certificate used on the
remote IMV server.
14. Add the new remote IMV server:
To specify the remote IMV server so that Secure Access can communicate with it:
a. In the admin console, choose Authentication > Endpoint Security > Host Checker.
b. Under Remote IMV, click New Server.
c. In the New Server page:
i.
Create a label for the server using the Name and (optional) Description fields.
ii. In the Hostname field, enter either the IP address or host name as defined in
the server certificate.
iii. In the Port field, enter the unique port number Secure Access uses to
communicate with the remote IMV server. Ensure that no other service is using
this port number.
The default port number is the same as the default https port number. If you
are running a web server on the same system as the Remote IMV Server, enter
a new port number in the Port field.
iv. In the Shared Secret field, enter the same shared secret used in the client
information entry on the remote IMV server.
v. Click Save Changes.
d. Under Remote IMV, click New IMV to specify the third-party IMV.
e. In the New IMV page:
i.
Create a label for the IMV using the Name and (optional) Description fields.
ii. In the IMV Name field, enter the name of the IMV. This name must match the
“human readable name” in the IMV’s well-known registry key on the remote
Copyright © 2011, Juniper Networks, Inc.
307
Secure Access Administration Guide
IMV server. For more information about human readable names and the
well-known registry key, see www.trustedcomputinggroup.org.
iii. From the Primary Server pop-up menu, select the remote IMV server where this
IMV is installed.
iv. (Optional) From the Secondary Server pop-up menu, select the secondary
remote IMV server where this IMV is installed. The secondary server acts as a
failover in case the primary server becomes unavailable.
Secure Access continues to try to re-establish connection to the primary remote
IMV Server, and uses the primary Remote IMV Server on subsequent handshakes
once it becomes available.
v. Click Save Changes.
f.
Related
Documentation
Click Save Changes.
•
Implementing the Third-Party IMV Policy on page 308
•
Using Third-party Integrity Measurement Verifiers on page 301
Implementing the Third-Party IMV Policy
To use Host Checker as a policy enforcement tool for managing endpoints, you must
create global Host Checker policies at the system level through the Authentication >
Endpoint Security > Host Checker page of the admin console, and then implement the
policies at the realm and role levels.
NOTE: The Custom: Remote IMV option does not appear until you add the
Remote IMV New Server and New IMV on the main Host Checker page.
To implement the third-party IMV policy:
1.
In the admin console, select Authentication > Endpoint Security > Host Checker.
2. Under Policies, click New.
3. Enter a name in the Policy Name field and then click Continue. (Users see this name
on the Host Checker remediation page if you enable custom instructions for this policy.)
4. Under Rule Settings, choose Custom: Remote IMV and click Add.
5. In the Add Custom Rule: Remote IMV page:
a. In the Rule Name field, enter an identifier for the rule.
b. Under Criteria, select the third-party IMV to be associated with this rule.
c. Click Save Changes.
6. Specify how Host Checker should evaluate multiple rules within the policy.
308
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
7. (Recommended) Specify remediation options for users whose computers do not
meet the requirements specified in the policy
8. Click Save Changes.
9. Implement the policy at the realm or role level.
Related
Documentation
•
Using Third-party Integrity Measurement Verifiers on page 301
•
Configuring a Remote IMV Server on page 302
•
Implementing Host Checker Policies on page 309
Implementing Host Checker Policies
After you create global policies through the Authentication > Endpoint Security > Host
Checker page of the admin console, you can restrict Secure Access and resource access
by requiring Host Checker in a:
•
Realm authentication policy—When administrators or users try to sign in to Secure
Access or launch a Virtual Workspace session, Secure Access evaluates the specified
realm’s authentication policy to determine if the pre-authentication requirements
include Host Checker. You can configure a realm authentication policy to download
Host Checker, launch Host Checker and enforce Host Checker policies specified for
the realm, or not require Host Checker. The user must sign in using a computer that
adheres to the Host Checker requirements specified for the realm. If the user’s computer
does not meet the requirements, then Secure Access denies access to the user unless
you configure remediation actions to help the user bring his computer into compliance.
You can configure realm-level restrictions through the Administrators > Admin Realms
> SelectRealm > Authentication Policy > Host Checker page or the Users > User Realms
> SelectRealm > Authentication Policy > Host Checker page of the admin console.
•
Role—When Secure Access determines the list of eligible roles to which it can map an
administrator or user, it evaluates each role’s restrictions to determine if the role requires
that the user’s computer adheres to certain Host Checker policies. If it does and the
user's computer does not follow the specified Host Checker policies, then Secure
Access does not map the user to that role unless you configure remediation actions
to help the user bring his computer into compliance. You can configure role-mapping
using settings in the Users > User Realms > SelectRealm > Role Mapping page. You
can configure role-level restrictions through the Administrators > Admin Roles >
SelectRole > General > Restrictions > Host Checker page of the admin console or the
Users > User Roles> SelectRole > General > Restrictions > Host Checker page. If you
have enabled Advanced Endpoint Defense Malware Protection, you can select to
implement this feature for any role.
•
Resource policy—When a user requests a resource, Secure Access evaluates the
resource policy’s detailed rules to determine if the resource requires that the user’s
computer adheres to certain Host Checker policies. Secure Access denies access to
the resource if the user's computer does not follow the specified Host Checker policies
unless you configure remediation actions to help the user bring his computer into
compliance. To implement Host Checker restrictions at the resource policy level, use
Copyright © 2011, Juniper Networks, Inc.
309
Secure Access Administration Guide
settings in the Users > Resource Policies > SelectResource > SelectPolicy > Detailed
Rules page.
You may specify that Secure Access evaluate your Host Checker policies only when the
user first tries to access the realm, role, or resource that references the Host Checker
policy. Or, you may specify that Secure Access periodically re-evaluate the policies
throughout the user’s session. If you choose to periodically evaluate Host Checker policies,
Secure Access dynamically maps users to roles and allows users access to new resources
based on the most recent evaluation.
Executing Host Checker Policies
When the user tries to access Secure Access, Host Checker evaluates its policies in the
following order:
1.
Initial evaluation—When a user first tries to access the Secure Access sign-in page,
Host Checker performs an initial evaluation. Using the rules you specify in your policies,
Host Checker verifies that the client meets your endpoint requirements and returns
its results to Secure Access. Host Checker performs an initial evaluation regardless
of whether you have implemented Host Checker policies at the realm, role, or resource
policy level.
If the user navigates away from the Secure Access sign-in page after Host Checker
starts running but before signing in to Secure Access, Host Checker continues to run
on the user’s machine until the Host Checker process times out.
If Secure Access does not receive a result from Host Checker for any reason (including
because the user manually terminated Host Checker), Secure Access displays an error
and directs the user back to the sign-in page.
Otherwise, if the Host Checker process returns a result, Secure Access goes on to
evaluate the realm level policies.
2. Realm-level policies—Secure Access uses the results from Host Checker’s initial
evaluation to determine which realms the user may access. Then, Secure Access
displays or hides realms from the, only allowing the user to sign into those realms that
you enable for the sign-in page, and if the Host Checker requirements for each realm
are met. If the user cannot meet the Host Checker conditions required by any of the
available realms, Secure Access does not display the sign-in page. Instead, it displays
an error stating the user has no access unless you have configured remediation actions
to help the user bring the endpoint into compliance.
Note that Host Checker only performs realm-level checks when the user first signs
into the Secure Access. If the state of the user’s system changes during his session,
Secure Access does not remove him from the current realm or allow him access to a
new realm based on his new system state.
3. Role-level policies—After the user signs into a realm, Secure Access evaluates
role-level policies and maps the user to the role or roles if he meets the Host Checker
requirements for those role(s). Then, Secure Access displays the Secure Access
homepage to the user and enables those options that the mapped role(s) allow.
If Host Checker returns a different status during a periodic evaluation, Secure Access
dynamically remaps the user to roles based on the new results. If the user loses rights
310
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
to all available roles during one of the periodic evaluations, Secure Access disconnects
the user’s session unless you have configured remediation actions to help the user
bring the endpoint into compliance.
4. Resource-level policies—After Secure Access allows the user to access the homepage,
the user may try to access a resource that is controlled by a resource policy. When he
does, Secure Access determines whether or not to perform the action specified in the
resource policy based on the last status returned by Host Checker.
If Host Checker returns a different status during a periodic evaluation, the new status
only impacts new resources that the user tries to access. For example, if the user
successfully initiates a Network Connect session and then fails his next resource-level
host check, he may continue to access the open Network Connect session. Secure
Access only denies him access if he tries to open a new Network Connect session.
Secure Access checks the last status returned by Host Checker whenever the user
tries to access a new Web resource or open a new Secure Application Manager,
Network Connect, or Secure Terminal Access session.
With either a success or fail result, Host Checker remains on the client. Windows users
may manually uninstall the agent by running uninstall.exe in the directory where Host
Checker is installed. If you enable client-side logging through the System > Log/Monitoring
> Client Logs page, this directory also contains a log file, which Secure Access rewrites
each time Host Checker runs.
If you enable dynamic policy evaluation for Host Checker, Secure Access evaluates
resource policies implemented at the realm level whenever a user’s Host Checker status
changes. If you do not enable dynamic policy evaluation for Host Checker, Secure Access
does not evaluate resource policies but it does evaluate the authentication policy, role
mapping rules, and role restrictions whenever a user’s Host Checker status changes.
Related
Documentation
•
About Host Checker Restrictions on page 311
•
Specifying General Host Checker Options on page 323
•
Role Restrictions on page 94
•
Defining Authentication Access Policies on page 215
About Host Checker Restrictions
To specify Host Checker restrictions:
1.
Navigate to: Authentication > Endpoint Security > Host Checker and specify global
options for Host Checker to apply to any user for whom Host Checker is required in
an authentication policy, a role mapping rule, or a resource policy.
2. If you want to implement Host Checker at the realm level:
a. Navigate to:
•
Administrators > Admin Realms > Select Realm > General > Restrictions >
Host Checker.
•
Users > User Realms > Select Realm > General > Restrictions > Host Checker.
Copyright © 2011, Juniper Networks, Inc.
311
Secure Access Administration Guide
b. Choose one of the following options for either all available policies or for individual
policies listed in the Available Policies column:
•
Evaluate Policies—Evaluates without enforcing the policy on the client and
allows user-access. This option does not require Host Checker to be installed
during the evaluation process; however, Host Checker is installed once the user
signs in to Secure Access.
•
Require and Enforce—Requires and enforces the policy on the client in order for
the user to log in to the specified realm. Requires that Host Checker is running
the specified Host Checker policies in order for the user to meet the access
requirement. Requires Secure Access to download Host Checker to the client
machine. If you choose this option for a realm’s authentication policy, then Secure
Access downloads Host Checker to the client machine after the user is
authenticated and before the user is mapped to any roles in the system. Selecting
this option automatically enables the Evaluate Policies option.
c. Select the Allow access to realm if any ONE of the selected “Require and Enforce”
policies is passed check box if you do not want to require users to meet all of the
requirements in all of the selected policies. Instead, the user can access the realm
if he meets the requirements of any one of the selected Host Checker policies. Note
that Cache Cleaner policies are not part of the “requirement” decision process.
Users can access the realm as long as they meet the other requirements regardless
of whether they meed the Cache Cleaner policy.
3. If you want to implement Host Checker at the role level:
a. Navigate to:
•
Administrators > Admin Roles > Select Role > General > Restrictions > Host
Checker.
•
Users > User Roles > Select Role > General > Restrictions > Host Checker.
b. Choose one of the following options:
312
•
Allow all users — Does not require Host Checker to be installed in order for the
user to meet the access requirement.
•
Allow only users whose workstations meet the requirements specified by
these Host Checker policies — Requires that Host Checker is running the specified
Host Checker policies in order for the user to meet the access requirement.
•
Select the Allow access to role if any ONE of the selected “Require and Enforce”
policies is passed check box if you do not want to require users to meet all of
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
the requirements in all of the selected policies. Instead, the user can access the
role if he meets the requirements of any one of the selected Host Checker policies.
4. If you want to create role-mapping rules based on a user’s Host Checker status:
a. Navigate to: Users > User Realms > Select Realm >Role Mapping.
b. Click New Rule, select Custom Expressions from the Rule based on list, and click
Update. Or, to update an existing rule, select it from the When users meet these
conditions list.
c. Click Expressions.
d. Write a custom expression for the role mapping rule to evaluate Host Checker’s
status using the hostCheckerPolicy variable. For help writing the custom
expressions, use tips in the Expressions Dictionary.
e. In the ...then assign these roles section, select the roles that Secure Access should
map users to when they meet the requirements specified in the custom expression
and click Add.
f.
Select the Stop processing rules when this rule matches if you want Secure Access
to stop evaluating role mapping rules if the user successfully meets the
requirements defined in this rule.
5. If you want to implement Host Checker at the resource policy level:
a. Navigate to: Users > Resource Policies > Select Resource > Select Policy >
Detailed Rules.
b. Click New Rule or select an existing rule from the Detailed Rules list.
c. Write a custom expression for the detailed rule to evaluate Host Checker’s status
using the hostCheckerPolicy variable.
These options allow you to control which version of an application or service runs on
client machines.
Remediating Host Checker Policies
You can specify general remediation actions that you want Host Checker to take if an
endpoint does not meet the requirements of a policy. For example, you can display a
remediation page to the user that contains specific instructions and links to resources
to help the user bring their endpoint into compliance with Host Checker policy
requirements.
You can also choose to include a message to users (called a reason string) that is returned
by Host Checker or an integrity measurement verifier (IMV) and explains why the client
machine does not meet the Host Checker policy requirements.
For example, the user may see a remediation page that contains the following custom
instructions, a link to resources, and reason strings:
Copyright © 2011, Juniper Networks, Inc.
313
Secure Access Administration Guide
Your computer's security is unsatisfactory.
Your computer does not meet the following security requirements. Please follow the
instructions below to fix these problems. When you are done click Try Again. If you choose
to Continue without fixing these problems, you may not have access to all of your intranet
servers.
1. Symantec
Instructions: You do not have the latest signature files. Click here to download the latest
signature files. Reasons: The AntiVirus Product Version is too low.
The age of the Virus Definitions is not acceptable.
For each Host Checker policy, you can configure two types of remediation actions:
•
User-driven—Using custom instructions, you can inform the user about the failed policy
and how to make his computer conform. The user must take action to successfully
re-evaluate the failed policy. For instance, you can create a custom page that is linked
to a policy server or Web page and enables the user to bring his computer into
compliance.
•
Automatic (system-driven)—You can configure Host Checker to automatically
remediate the user’s computer. For example, when the initial policy fails, you can kill
processes, delete files, or allow automatic remediation by an IMV. On Windows, you
can also call the HCIF_Module.Remediate () API function as part of a third-party J.E.D.I.
DLL. Host Checker does not inform users when performing automatic actions. (You
could, however, include information in your custom instructions about the automatic
actions.)
General Host Checker Remediation User Experience
Users may see the remediation page in the following situations:
•
Before the user signs in:
•
If you enable custom instructions for a policy that fails, Secure Access displays the
remediation page to the user. The user has two choices:
•
Take the appropriate actions to make the endpoint conform to the policy and then
click the Try Again button on the remediation page. Host Checker checks the user’s
computer again for compliance with the policy.
•
Leave the endpoint in its current state and click the Continue button to sign in to
Secure Access. The user cannot access the realm, role, or resource that requires
compliance with the failed policy.
If you do not configure Secure Access with at least one realm that allows access
without enforcing a Host Checker policy, the user must bring the endpoint into
compliance before signing into Secure Access.
•
314
If you do not enable custom instructions for a policy that fails, Host Checker does
not display the remediation page to the user. Instead, Secure Access displays the
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
sign-in page but does not allow the user to access any realms, roles, or resources
that have a failed Host Checker policy.
•
After the user signs in:
•
(Windows only) During a session, if a user’s Windows computer becomes
non-compliant with the requirements of a Host Checker policy, an icon appears in
the system tray along with a pop-up message that informs the user of the
non-compliance. The user can then click the pop-up message to display the
remediation page.
•
(Macintosh or Linux) During a session, if a user’s Macintosh or Linux computer
becomes non-compliant with the requirements of a Host Checker policy, Secure
Access displays the remediation page to inform the user of the non-compliance.
NOTE: If the user hides the remediation page by setting a user preference,
he may only continue using the secure gateway if you configure other
realms and roles that do not enforce a Host Checker policy.
Related
Documentation
•
Configuring General Host Checker Remediation on page 315
•
Configuring a Predefined Antivirus Rule with Remediation Options on page 284
•
Configuring a Predefined Firewall Rule with Remediation Options (Windows Only) on
page 286
•
Specifying Customized Requirements Using Custom Rules on page 290
Configuring General Host Checker Remediation
To specify remediation actions for a Host Checker policy:
1.
In the admin console, select Authentication > Endpoint Security > Host Checker.
2. Create or enable Host Checker policies.
3. Specify the remediation actions that you want Host Checker to perform if a user’s
computer does not meet the requirements of the current policy:
Copyright © 2011, Juniper Networks, Inc.
315
Secure Access Administration Guide
•
Enable Custom Instructions—Enter the instructions you want to display to the user
on the Host Checker remediation page. You can use the following HTML tags to
format text and add links to resources such as policy servers or web sites: <i>, <b>,
<br>, <font>, and <a href>. For example:
You do not have the latest signature files.
<a href=”www.company.com”>Click here to download the latest signature files.</a>
NOTE: For Windows clients, if you include in the instructions a link to a
Secure Access-protected policy server, define a pre-authentication
access tunnel.
•
Enable Custom Actions—You can select one or more alternate policies that you
want Host Checker to evaluate if the user’s computer does not meet the current
policy requirements. The alternate policy must be either a third-party policy that
uses a J.E.D.I. package or a Secure Virtual Workspace policy. For example, you can
use a J.E.D.I. package to launch an application if the user’s computer does not meet
the current policy requirements. Select the alternate policy in the HC Policies list
and then click Add.
•
Remediate—(Third party DLLs only) You can select this option to perform
remediation actions specified by means of the Remediate () API function in a
third-party J.E.D.I. DLL.
NOTE: The Remediate feature is primarily provided for backwards
compatibility. We recommend that you use IMCs and IMVs instead.
•
Kill Processes—On each line, enter the name of one or more processes you want
to kill if the user’s computer does not meet the policy requirements. You can include
an optional MD5 checksum for the process. (You cannot use wildcards in the process
name.) For example:
keylogger.exe
MD5: 6A7DFAF12C3183B56C44E89B12DBEF56
•
Delete Files—Enter the names of files you want to delete if the user’s computer
does not meet the policy requirements. (You cannot use wildcards in the file name.)
Enter one file name per line. For example:
c:\temp\bad-file.txt
/temp/bad-file.txt
•
316
Send reason strings—Select this option to display a message to users (called a
reason string) that is returned by Host Checker or integrity measurement verifier
(IMV) and explains why the client machine does not meet the Host Checker policy
requirements. This option applies to predefined rules, custom rules, and to third-party
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
IMVs that use extensions in the Juniper Networks TNC SDK. For example, an antivirus
IMV might display the following reason string:
The AntiVirus Product Version is too low. The age of the Virus Definitions is not
acceptable.
NOTE: By sending reason strings, you are disclosing to users what the
IMV is checking on the client machine.
4. Click Save Changes.
Related
Documentation
•
Remediating Host Checker Policies on page 313
Upgrading the Endpoint Security Assessment Plug-In
The Endpoint Security Assessment Plug-in (ESAP) on Secure Access checks third-party
applications on endpoints for compliance with the pre-defined rules you configure in a
Host Checker policy. This plug-in is included in the Secure Access system software
package.
Juniper Networks frequently adds enhancements, bug fixes, and support for new
third-party applications to the plug-in. New plug-in releases are available independently
and more frequently than new releases of the Secure Access system software package.
If necessary, you can upgrade the plug-in on Secure Access independently of upgrading
the Secure Access system software package.
You can upload up to four versions of the plug-in to Secure Access, but Secure Access
uses only one version at a time (called the active version). If necessary, you can rollback
to a previously active version of the plug-in.
To upgrade the Endpoint Security Assessment Plug-in:
1.
Download the Endpoint Security Assessment Plug-in from the Juniper Networks
Customer Support Center to your computer:
a. Open the following page:
https://www.juniper.net/customers/csc/software/ive/
b. To access the Customer Support Center, enter a user name and password for a
Juniper Networks Support account.
c. Click the ESAP link.
d. Click the ESAP Download Page link.
e. Navigate to the ESAP release you want.
f.
Download the plug-in zip file to your computer.
2. Select Authentication > Endpoint Security > Host Checker.
Copyright © 2011, Juniper Networks, Inc.
317
Secure Access Administration Guide
3. At the bottom of the Host Checker page under Manage Endpoint Security Assessment
Plug-In Versions:
a. If you have previously uploaded four versions of the component software, you must
delete one of the versions before you can upload another one. Select the version
you want to delete and click Delete.
b. If you want Secure Access to actively begin using the new component software
immediately after you upload it, select the Set as active after upload option.
c. Click Browse, select the plug-in file you want to upload to Secure Access, and click
OK.
d. Click Upload. While Secure Access uploads and decrypts the plugin .zip file, the
message “Loading...” appears in the plug-in list under Manage Endpoint Security
Assessment Plug-In Versions. If Secure Access is a member of a cluster, Secure
Access displays the message “Loading...” while the plug-in is transferred to the
other cluster nodes. After the plug-in is installed, the date and time of the plug-in
installation appears in the plug-in list.
e. If you did not select the Set as active after upload option, activate the plug-in you
want to use by selecting the version in the plug-in list and clicking Activate.
318
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
NOTE:
Related
Documentation
•
•
If you attempt to activate a version of the plug-in that does not support all
of the pre-defined rules already configured in all Host Checker policies,
Secure Access does not allow activation of that plug-in version. For
example, if a Host Checker policy is configured to use a pre-defined rule to
check for a version of antivirus software, and you attempt to activate a
plug-in version that does not support that particular version of the antivirus
software, Secure Access does not allow you to activate that plug-in version.
To view the list of supported products for a particular plug-in version, click
the plug-in’s version number under Manage Endpoint Security Assessment
Plug-In Versions.
•
You can rollback to an older plug-in version after upgrading to a later version
by selecting the older version as the active version. But, if you modified any
Host Checker policies after upgrading to the later version, the rollback may
not succeed. Rollback is guaranteed to succeed only if the policies did not
change.
•
If you upgrade the Secure Access system software to a newer version, or
you import a user configuration file, the currently active plug-in version
does not change. If you want to use a different plug-in version after
upgrading or importing a user configuration file, you must manually activate
that plug-in version.
•
If Secure Access already has four versions of the plug-in installed when
you upgrade the Secure Access system software to a newer version, Secure
Access automatically deletes the oldest plug-in version and installs, but
does not activate, the plug-in included with the new Secure Access system
software.
Implementing Host Checker Policies on page 309
Defining Host Checker Pre-Authentication Access Tunnels
If your policies require Host Checker rules or third-party J.E.D.I. DLLs to access a policy
server (or other resource) to check compliance before users are authenticated, you can
use one of the following methods to make the resource available to the Host Checker
Windows clients:
•
Deploy the policy server in a DMZ where Host Checker rules or third-party J.E.D.I.
DLLs can access the server directly instead of going through Secure Access—This
deployment is the simplest solution because you do not have to define a Host Checker
pre-authentication access tunnel through Secure Access between clients and the
policy server.
•
Deploy the policy server in a protected zone behind Secure Access (Windows
only)—This deployment requires you to define a pre-authentication access tunnel. A
pre-authentication access tunnel enables Host Checker rules or third-party J.E.D.I. DLLs
Copyright © 2011, Juniper Networks, Inc.
319
Secure Access Administration Guide
to access the Secure Access-protected policy server or resource before Secure Access
authenticates users. To define a pre-authentication access tunnel, you associate a
loopback address (or host name) and port on the client with an IP address and port
on the policy server. You add one or more tunnel definitions to a MANIFEST.HCIF file,
which you then upload to Secure Access. You can upload multiple MANIFEST.HCIF
files to Secure Access. For all third-party policies enabled on a realm, Host Checker
creates tunnels for all of the tunnel definitions in all of the MANIFEST.HCIF files,
assuming the definitions are unique.
While running on a Windows client, Host Checker listens for a connection on each loopback
address and port you specify in the tunnel definitions. The connections can originate from
the integrated Host Checker rules and from client-side or server-side J.E.D.I. DLLs. Host
Checker uses the pre-authentication access tunnel(s) to forward the connections through
Secure Access to the policy server(s) or other resource.
Figure 17: Host Checker Creates a Tunnel from a Client to a Policy Server
Behind the SA Series Appliance
NOTE: Host Checker pre-authentication access tunnels are supported on
Windows only.
Related
Documentation
•
Specifying Host Checker Pre-Authentication Access Tunnel Definitions on page 320
Specifying Host Checker Pre-Authentication Access Tunnel Definitions
For Windows clients, you can define a pre-authentication access tunnel that enables
Host Checker methods or third-party J.E.D.I. DLLs to access a Secure Access-protected
policy server (or other resource) before users are authenticated.
A definition for a Host Checker pre-authentication access tunnel configures access to
one policy server or other resource. Each tunnel definition consists of a pair of IP addresses
and ports: one loopback IP address and port on the client, and one IP address and port
on the policy server.
You specify one or more tunnel definition(s) in a Host Checker policy package definition
file. The package definition file, which must be named MANIFEST.HCIF, defines the name
of an interface DLL, the Host Checker policies defined in the DLL, and the
320
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
pre-authentication access tunnel definitions. Note that if you do not include policies in
your package, Host Checker simply enforces that the package has run on the client. If
you do declare policies through this file, they become available through the admin console
where you can implement them at the realm, role, and resource policy levels.
Within the MANIFEST.HCIF file, you must include one definition per line, with a blank line
between each definition, using the following format:
HCIF-Main: <DLLName>
HCIF-Policy: <PolicyName>
HCIF-IVE-Tunnel: <client-loopback>:port <policy-server>:port
where:
<DLLName> is the name of the interface DLL, such as myPestPatrol.dll. Even if you are
not using an interface DLL, you must include a dummy DLL as a placeholder file that has
this exact name.
<PolicyName> is the name of a policy defined in the DLL, such as myFileCheck. You can
define multiple policies by using the HCIF-Policy statement for each policy. If you are not
using an interface DLL, you can use any policy name as a placeholder.
The syntax of a Host Checker tunnel definition is:
HCIF-IVE-Tunnel: <client-loopback>:port <policy-server>:port
where:
<client-loopback> is a loopback address that begins with 127. and takes any of the
following forms:
•
An IP address and port that takes the form of 127.*.*.*:port. To avoid conflicts with
JSAM, do not use 127.0.0.1 with port 80, but you can use 127.0.0.1 with other ports. For
example: 127.0.0.1:3220
•
A host name that resolves to a loopback address that begins with 127. You can use a
local hosts file on each client computer or a DNS server to resolve the loopback address.
•
A host name that does not resolve to a loopback address, or resolves to a non-loopback
address. In these cases, Host Checker allocates a loopback address and updates the
local hosts file on the client with the mapping. Note that the user must have
administrator privileges in order for Host Checker to modify the local hosts file. If the
user does not have administrator privileges, Host Checker cannot update the hosts file
and cannot open the pre-authentication access tunnel. In that case, Host Checker logs
an error.
<policy-server> is the IP address or host name of the back-end policy server. Secure
Access resolves the host name you specify.
For example, in the following tunnel definition, 127.0.0.1:3220 is the client loopback
address and port, and mysygate.company.com:5500 is the policy server host name and
port:
HCIF-IVE-Tunnel: 127.0.0.1:3220 mysygate.company.com:5500
Copyright © 2011, Juniper Networks, Inc.
321
Secure Access Administration Guide
Or you can use a host name for the client, as in this example:
HCIF-IVE-Tunnel: mysygate.company.com:3220 mysygate.company.com:5500
Keep the following in mind when specifying tunnel definitions:
•
You must add a blank line between each line in the MANIFEST.HCIF file, and you can
use a semi-colon at the beginning of a line to indicate a comment. For example:
HCIF-Main: myPestPatrol.dll
HCIF-Policy: myFileCheck
HCIF-Policy: myPortCheck
; Tunnel definitions
HCIF-IVE-Tunnel: 127.0.0.1:3220 mysygate.company.com:5500
HCIF-IVE-Tunnel: 127.1.1.1:3220 mysygate2.company.com:5500
HCIF-IVE-Tunnel: mysygate.company.com:3220 mysygate3.company.com:5500
•
Host Checker pre-authentication access tunnels are supported on Windows only.
•
If <client-loopback> is a non-loopback address, then Host Checker cannot open the
pre-authentication access tunnel and logs an error instead.
•
If you use a loopback address other than 127.0.0.1 (such as 127.0.0.2 and above), clients
who are using Windows XP Service Pack 2 must install the XP SP2 Hot Fix. See:
http://support.microsoft.com/default.aspx?scid=kb;en-us;884020
NOTE: If you are deploying a client-side or server-side third-party DLL, keep
the following in mind:
Related
Documentation
322
•
•
Unzip the server-side third-party DLL package and add the tunnel
definitions to the MANIFEST.HCIF file that contain the policies for the
third-party DLL. (The DLL must use the same <client-loopback> address
and port or host name that you specify in the MANIFEST.HCIF file.)
•
Since a pre-authentication access tunnel is open only while Host Checker
is running, a third-party DLL can access its Secure Access protected
policy server only while Host Checker is running.
•
If a third-party DLL uses HTTPS to connect to its policy server via a host
name that resolves properly to the loopback address, no server certificate
warnings appear. However, if the third-party DLL connects explicitly via
a loopback address, then server certificate warnings do appear because
the host name in the certificate does not match the loopback address.
(The developer of the third-party DLL can configure the DLL to ignore
these warnings.)
Defining Host Checker Pre-Authentication Access Tunnels on page 319
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
Specifying General Host Checker Options
You can specify global options for Host Checker that apply to any user for whom Host
Checker is required in an authentication policy, a role mapping rule, or a resource policy.
To specify general Host Checker options:
1.
In the admin console, choose Authentication > Endpoint Security > Host Checker.
2. Under Options:
•
In the Perform check every X minutes field, specify the interval at which you want
Host Checker to perform policy evaluation on a client machine. If the client machine
fails to meet the requirements of the Host Checker policies required by a role or
resource policy, then Secure Access denies the associated user requests.
For example, you may require that a user runs a specific third-party antivirus
application in order to map to Role A, which enables network connections from an
external location. If the user’s client machine is running the required antivirus
application when the user signs in to Secure Access, then the user maps to Role A
and is granted all access features enabled for Role A. If the antivirus application
stops running during the user session, however, the next time Host Checker runs,
the user fails to meet the security requirements for Role A and therefore loses all
access privileges for Role A.
When an end-user logs into a Realm, Host Checker performs an initial policy check,
regardless of whether or not the policy is enforced at the Realm, Role, and/or
Resource level. The initial policy check establishes a start time. Host Checker
evaluates policies at the frequency set by the Perform check every X minutes option
starting the clock at the initial policy check. Although the frequency setting is set
globally for all Host Checker policy checking, it is not synchronized for all end-user
clients connected to Secure Access. Each client performs its own initial policy check
and starts its own X minute countdown. If you configure the authentication policy
within a realm where Host Checker enforces policies (versus installing), the
enforcement occurs only during the pre-authentication phase. After an end-user
signs in and for the duration of the user’s session, any subsequent Host Checker
policy checks have no impact on realm access, meaning that there is no concept
of removing an end-user session from a realm once an end-user successfully
authenticates into that realm.
If you configure a role restriction where Host Checker enforces policies, the
enforcement occurs just after authentication during role mapping. Role restrictions
are enforced periodically during the end-user session at an interval specified using
the Host Checker frequency setting. If the end-user successfully passes the Host
Checker evaluation during role mapping but later fails X minutes after login, that
specific user loses rights to that role. If the end-user loses rights to all available roles
due to Host Checker policy evaluation, the end-user session is disconnected.
If you configure a resource-based policy rule where Host Checker enforces policies,
the enforcement occurs when the end-user attempts to access the
resource/backend server. For web resources, the Host Checker evaluation occurs
at each request. For SAM and STA resources, the Host Checker evaluation occurs
Copyright © 2011, Juniper Networks, Inc.
323
Secure Access Administration Guide
when Secure Access activates the connection to the backend application/server.
For Network Connect access, the Host Checker evaluation occurs when Secure
Access initiates Network Connect. Existing connections of applications running by
way of SAM, Telnet/SSH connection, and Network Connect connections are not
affected by further Host Checker evaluations. Only new Web requests, new
applications across SAM, new instances of STA, and launching Network Connect
are affected. The Host Checker evaluation is based on the most recent policy check
that occurred X minutes ago. Example, if you configure the frequency setting to
Perform check every five minutes and the end-user attempts to access a protected
resource or attempts to launch Network Connect four minutes after the last check,
then the policy evaluation is based on the state of the client machine four minutes
ago, not at the moment the end-user attempted to access the resource.
NOTE: If you enter a value of zero, Host Checker only runs on the client
machine when the user first signs into Secure Access.
•
•
For the Client-side process, login inactivity timeout option, specify an interval to
control timing out in the following situations:
•
If the user navigates away from the Secure Access sign-in page after Host Checker
starts running but before signing in to Secure Access, Host Checker continues to
run on the user’s machine for the interval you specify.
•
If the user is downloading Host Checker over a slow connection, increase the
interval to allow enough time for the download to complete.
Select Perform dynamic policy reevaluation to automatically refresh the roles of
individual users by enabling dynamic policy evaluation for Host Checker. Host
Checker can trigger Secure Access to evaluate resource policies whenever a user’s
Host Checker status changes. (If you do not select this option, Secure Access does
not evaluate resource policies but it does evaluate the authentication policy, role
mapping rules, and role restrictions whenever a user’s Host Checker status changes.)
3. Click Save Changes.
Related
Documentation
•
About Host Checker Restrictions on page 311
Specifying Host Checker Installation Options
If you implement any policy at the realm, role, or resource policy level that requires Host
Checker, you must provide a mechanism by which Secure Access or the user can install
Host Checker on the client machine. Otherwise, when Secure Access evaluates the Host
Checker policy, the user’s machine fails because the Host Checker client is not available
to return a success status.
324
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
You can use two methods to install Host Checker on a user’s system:
•
Secure Access automatically installs Host Checker—Enable automatic installation
through the Users/Administrators > User Realms/Administrator Realms > [Realm] >
Authentication Policy > Host Checker page of the admin console. When you do, Secure
Access evaluates the realm-level option when the user accesses the Secure Access
sign-in page and then determines if the current version of Host Checker is installed on
the user’s machine. If Host Checker is not installed, Secure Access attempts to install
it using either an ActiveX or a Java delivery method.
When a Windows user signs in to Secure Access, Secure Access attempts to install an
ActiveX control on the user’s system. If Secure Access successfully installs the ActiveX
control, the control manages the installation of the Host Checker program.
If Secure Access cannot install the ActiveX control because ActiveX is turned off on
the user’s system, Secure Access attempts to install Host Checker using Java. For Linux
hosts, Secure Access always uses the Java delivery method. The Java delivery method
requires only user privileges, but Java must be enabled on the user’s system. For the
Firefox browser on Linux, the Java runtime and plug-in must be installed.
NOTE: Due to some anomalies with Microsoft JVM, Host Checker may not
install and an error box appears. If this occurs, click Try Again. The
subsequent installation should succeed.
If Secure Access cannot use the Java delivery method because Java is disabled on the
user’s system, Secure Access displays a no-access error message.
NOTE: If Microsoft Vista is running on the user’s system, the user must click
the setup link that appears during the installation process to continue
installing the setup client and Host Checker. On all other Microsoft operating
systems, the setup client and Host Checker install automatically.
•
The user or administrator manually installs Host Checker (Windows only)—Download
the Host Checker installer from the Maintenance > System > Installers page of the
admin console and use it to manually install Host Checker on the user’s system.
NOTE: To install Host Checker, users must have appropriate privileges, as
described in the Client-side Changes Guide on the Juniper Networks
Customer Support Center. If the user does not have these privileges, use
the Juniper Installer Service available from the Maintenance > System >
Installers page of the admin console to bypass this requirement.
Removing the Juniper ActiveX Control
Copyright © 2011, Juniper Networks, Inc.
325
Secure Access Administration Guide
If Microsoft Windows XP is running on the user’s system and you want to remove the
Juniper set-up ActiveX control:
1.
Open Internet Explorer.
2. Click the Tools button and then click Internet Options.
3. Click Settings, then View Objects.
4. Select JuniperSetupSP1 and press Delete.
If Microsoft Vista is running on the user’s system and you want to remove the Juniper
set-up ActiveX control:
1.
Open Internet Explorer.
2. Click the Tools button and then click Manage Add-ons.
3. In the Show list, click Downloaded ActiveX controls to display all ActiveX controls.
4. Click JuniperSetupClient and then click Delete.
Related
Documentation
•
Installing Host Checker Automatically or Manually on page 327
Using Host Checker with the GINA Automatic Sign-In Function
Using Host Checker in conjunction with the Windows Graphical Identification and
Authorization (GINA) sign-in function for Network Connect requires that you pay particular
attention to the type, level, and number of items to verify on the client before granting
or rejecting access to Secure Access. Since the GINA sign-in function takes place before
Windows has completely launched on the client, and therefore, before the user profile
on Windows is created, we recommend you adopt the following practices when creating
Host Checker policies you plan to use for Windows clients featuring the GINA sign-in
function:
•
You can check system-level processes at both realm enforce and realm evaluate. You
can check user-level processes only at realm evaluate.
•
If you have user-level processes at realm evaluate, create a separate Network Connect
role featuring only system-level policy checks that can be performed before Windows
has completely launched on the client. Ensure that this role allows connectivity to the
Windows Domain infrastructure in your secure network to support drive mapping,
software updates, and group policies, for example. Mapping your users to this role
allows the GINA authentication to complete. This role is in addition to the final role
that you want the user to be mapped.
•
Host Checker must be installed for the domain user that Network Connect GINA uses
for connection. Otherwise, this domain user can’t use GINA to login if Host Checker is
required.
NOTE: Multiple sessions of Host Checker with GINA on the same computer
is not supported.
326
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
Related
Documentation
•
About Network Connect on page 626
Installing Host Checker Automatically or Manually
To automatically install Host Checker on client computers:
1.
In the admin console, choose Authentication > Endpoint Security > Host Checker.
2. Under Options, select Auto-upgrade Host Checker if you want Secure Access to
automatically download the Host Checker application to a client computer when the
version of Host Checker on Secure Access is newer than the version installed on the
client. Here is a summary of what happens when the Auto-upgrade Host Checker
option is selected or not selected:
•
If Host Checker is not installed on the client computer, Host Checker is installed
automatically regardless of whether the Auto-upgrade Host Checker option is
selected or not selected.
•
If the Auto-upgrade Host Checker option is selected and a previous version of Host
Checker is installed, Host Checker is upgraded on the client automatically.
•
If the Auto-upgrade Host Checker option is not selected and a previous version of
Host Checker is installed, Host Checker is not upgraded the client automatically.
If you select the Auto-upgrade Host Checker option, note the following:
•
On Windows, the user must have administrator privileges in order for Secure
Access to automatically install the Host Checker application on the client. For
more information, see the Client-side Changes Guide on the Juniper Networks
Customer Support Center.
•
If a user uninstalls Host Checker and then signs in to Secure Access for which the
Auto-upgrade Host Checker option is not enabled, the user no longer has access
to Host Checker.
3. Click Save Changes.
The Maintenance > System > Installers page of the admin console provides several
applications and a service for download. You can download an application or service as
a Windows executable file, which enables you to:
Related
Documentation
•
Distribute the file to client machines using software distribution tools. This option
enables you to install an application or service on client machines whose users do not
have Administrator privileges, which are required to install the application or service.
•
Post the executable in a secure repository so that users with the proper administrator
right may download and install the appropriate version.
•
Download and execute a script that automatically retrieves the proper version of the
installer from an FTP server.
•
Specifying Host Checker Installation Options on page 324
Copyright © 2011, Juniper Networks, Inc.
327
Secure Access Administration Guide
Using Host Checker Logs
Use the System > Log/Monitoring > Client Logs > Settings tab to enable client-side
logging for the Host Checker. When you enable this option, Secure Access writes a
client-side log to any client that uses Host Checker. Secure Access appends to the log
file each time the feature is invoked during subsequent user sessions. This feature is
useful when working with the support team to debug problems with the respective
feature.
Since these settings are global, Secure Access writes a log file to all clients that use the
feature for which you enable client-side logging. Also, Secure Access does not remove
client-side logs. Users need to manually delete log files from their clients. For information
about where Secure Access installs log files, see the Client-side Changes Guide on the
Juniper Networks Customer Support Center.
To specify global client-side logging settings:
1.
In the admin console, choose System > Log/Monitoring > Client Log > Settings.
2. Select the desired features for which Secure Access writes client-side logs.
3. Click Save Changes to save these settings globally.
Related
Documentation
•
Implementing Host Checker Policies on page 309
Configuring Host Checker for Windows Mobile
You can configure Host Checker to enforce policies for handheld devices, such as PDAs
and smart phones, that run the Windows Mobile operating system.
NOTE: Currently only Windows Mobile versions 5 and 6 are supported.
Host Checker rules include checks for ports, processes, files, registry key settings, operating
system version, and certificates on the handheld device. You can also load and use
installed third-party IMCs to perform vendor-specific checks. Once the policy is created,
Host Checker deploys automatically when the user connects to the SA Series Appliance
gateway.
Host Checker does not require any configuration on the handheld device itself. When the
server determines the device is out of compliance, Host Checker displays a notification
icon in the system tray. Clicking this icon opens a browser page that contains reasons for
the compliance failure and remediation instructions.
Host Checker remains on the handheld device and does not need to be downloaded each
time the user connects to the gateway. When the gateway upgrades to a newer version
of Host Checker, the handheld device automatically updates the next time the user
connects to the gateway. To remove Host Checker from the handheld device, use the
Remove Programs applet in the Settings panel of the device.
328
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
Host Checker policies for Windows Mobile are configured through the Authentication >
Endpoint Security > Host Checker page of the admin console.
Requiring Junos Pulse Mobile Security for SA Series Gateway Access
Junos Pulse Mobile Security is an optional licensed feature of the Pulse mobile device
app. An SA administrator can configure the SA Series gateway to perform a host check
and require that Pulse Mobile Security be activated on mobile devices before granting
access to the device through the SA Series gateway.
NOTE: The Pulse Mobile security check feature is available on SA Series
software Release 7.0 Release 2 or higher.
To require Pulse Mobile Security software on the device:
1.
On the SA Series gateway admin console, select Users > User Realms.
2. Select the realm you created for mobile devices. If necessary, create a new one now.
3. On the Authentication Policy tab, select Host Checker.
4. Select the Enable Mobile Security Check check box, and then click Save Changes.
The Mobile Security Check is now applied to all realm users. If you have created more
than one realm for mobile device access, enable this check box on each realm.
When you select the Enable Mobile Security Check check box, Junos Pulse connects
to the SA Series gateway only when the following criteria is met:
•
Security Suite feature is enabled on Junos Pulse.
•
There is no un-quarantined virus on the device.
Mobile device users must perform the following tasks:
Related
Documentation
•
Download and install the Pulse client software app for the particular device type. The
Pulse Mobile Security client software is bundled with the VPN app.
•
Start Pulse Mobile Security by tapping the Pulse icon.
•
If the device is not registered, respond to the prompts for registration information,
including a license key.
•
Implementing Host Checker Policies on page 309
•
Specifying Customized Requirements Using Custom Rules on page 290
Using Proxy Exceptions
IVE clients parse Internet Explorer’s static proxy exception list. We support most
exceptions that Internet Explorer supports with the following limitations:
Copyright © 2011, Juniper Networks, Inc.
329
Secure Access Administration Guide
•
For IP address exception, we support n.*.*.*, n.n.*.*, n.n.n.*. For example, 10.*.*.*,
10.10.*.*, 10.10.10.*, or 10.10.10.10. We do not support 10* or 10.*.10.* even though
Internet Explorer may support them.
•
For string expression, we support specific strings such as my.company.net,or a wild
card at front of the string, for example, *.my.company.net or *.company.net. We do
not support *.company.*, *.company*, *.company. *.com, *.net *.com and so forth.
Enabling the Secure Virtual Workspace
The Secure Virtual Workspace guarantees the integrity of Secure Access session data
on a client machine running Windows 2000 or Windows XP by creating a protected
workspace on the client desktop. By enabling the Secure Virtual Workspace, you ensure
that any end-user signing in to your intranet must perform all interactions within a
completely protected environment. If the user’s applications and interactions result in
data being written to disk or to the registry, the Secure Virtual Workspace encrypts that
information. When the Secure Access session is complete, the Secure Virtual Workspace
destroys all information pertaining to itself or to the session, by default. However, you
can configure the state of this type of information to suit your particular needs. For
example, you might decide to allow data to persist across Secure Virtual Workspace
sessions.
Secure Access follows the DoD 5220.M cleaning and sanitization standard for securely
deleting Secure Virtual Workspace data that is stored on the hard disk.
The Secure Virtual Workspace:
•
Removes workspace data and resources when the session ends.
•
Ensures that no browser Helper Objects latch onto an Internet Explorer process before
launching IE.
•
Prohibits desktop search products from intercepting Web traffic and indexing the
contents.
•
Enters all of its configuration and run-time operations in Secure Access logs.
Secure Access hosts the Secure Virtual Workspace binary, which the client system
downloads from Secure Access whenever a user connects. The Secure Virtual Workspace
creates a virtual file system and a virtual registry on the client.
You define and configure the applications that are allowed to run within the Secure Virtual
Workspace. For example, you can configure the following types of application
configurations:
330
•
Restrict launching of Internet Explorer and Outlook to the Secure Virtual Workspace.
•
Restrict application installations and executions within a Secure Virtual Workspace
session. This ensures that even the application binaries are completely removed from
the client machine after the session ends.
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
NOTE: Secure Virtual Workspace does not work when IBM Sametime 7.5
is running in the default desktop. IBM Sametime 7.5 automatically switches
users to the default desktop from the virtual workspace.
For Windows Vista and later, certain processes, like regedit, require elevated
privileges. SVW does not currently allow the running of elevated privilege
processes.
Secure Access implementation of the Secure Virtual Workspace:
•
Does not require the client desktop user to have administrator privileges to download
and run the Secure Virtual Workspace.
•
Supports the use of the Secure Virtual Workspace in conjunction with Host Checker,
which will automatically launch in the secure workspace, when initiated.
•
Provides the Secure Virtual Workspace as a J.E.D.I. module, to allow you to create
Secure Virtual Workspace policies at the user role or realm level.
Secure Virtual Workspace Restrictions and Defaults
The Secure Virtual Workspace imposes certain restrictions on its use, and establishes
defaults, which you may be able to modify.
•
SVW does not support Cache Cleaner.
•
By default, a platform-specific browser is allowed to run in the SVW, unless explicitly
restricted by the administrator.
•
Secure Access does not allow software applications that update the HKLM registry
entries on installation to operate within the SVW.
•
Secure Access does not support the standard JSAM applications Outlook and Netbios
file browsing through SVW, since these applications require registry key changes.
However, Secure Access does support the Citrix and Lotus Notes JSAM standard
applications through SVW.
•
By default, Secure Access does not allow access to external storage or printing devices
by some applications running in the SVW. You can enable access to these devices on
a role or realm basis, if needed.
•
By default, end-users are unable to access network shares, unless you configure access
to network shares in the SVW policy.
•
If your end-users use firewalls or other applications that run in the kernel space, they
may experience problems when trying to download the Secure Access client
components in SVW. Low-level administrative applications may display message
boxes requiring user interaction. If you set the option to allow switching to the default
or real desktop, the user may be able to dismiss the message boxes. If the switching
option is disabled, users may be unable to fix the problem.
•
The Secure Virtual Workspace does not support 16-bit applications.
Copyright © 2011, Juniper Networks, Inc.
331
Secure Access Administration Guide
•
Some Windows keyboard shortcuts may not work properly inside an SVW session.
•
To display the Windows Task Manager while in SVW, you cannot use the standard
keyboard shortcut Ctrl+Alt+Del. You must right-click on the Windows taskbar (typically
on the bottom of the screen, unless you have moved it) to display a popup menu, from
which you can select Task Manager.
•
If you set the Host Checker status update interval to a value of zero (0), Host Checker
will perform the status check once and then quit. If Host Checker quits, SVW also quits.
As a result, the end-user is unable to initiate an SVW session. Set the Host Checker
status update interval to a non-zero value.
•
SVW only scans for file system drives when the user first starts his session. If the user
starts a session and then adds a drive (such as a USB drive), he will not be able to
access the drive during that session.
•
The Logoff On Connect feature is not supported within SVW.
Configuring the Secure Virtual Workspace
You configure the Secure Virtual Workspace within the context of a Host Checker policy
and all Secure Virtual Workspace policies you define appear in a list at Authentication >
Endpoint Security > Secure Virtual Workspace.
Because the Secure Virtual Workspace session data is stored on the end-user’s real
desktop, you should implement the persistence feature only if each of your end-users
always uses the same client machine.
NOTE: No provision has been made to ensure that you cannot configure a
sign-in URL mapping to more than one realm configured with an SVW policy.
If you configure multiple mappings to more than one realm, the results are
unpredictable. You must explicitly configure the secure virtual desktop to
allow only one SVW policy to be evaluated at the user end.
Related
Documentation
•
Defining Secure Virtual Workspace Permissions on page 332
•
Defining a Secure Virtual Workspace Application Policy on page 334
•
Defining a Secure Virtual Workspace Security Policy on page 335
•
Defining Secure Virtual Workspace Environment Options on page 336
•
Defining Secure Virtual Workspace Remediation Policy on page 337
Defining Secure Virtual Workspace Permissions
You can specify which devices and resources the end-user can access when using the
Secure Virtual Workspace.
332
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
To define a new Secure Virtual Workspace permissions policy:
1.
In the admin console, choose Authentication > Endpoint Security > Secure Virtual
Workspace.
2. ClickNew Secure Virtual Workspace Policy .
3. Enter a name for the policy.
4. Under Permissions, check the appropriate checkboxes for the items to which you want
to grant permissions:
•
Printers—Select to allow end-user access to network printers.
•
Restricted View of Files—When Restricted View is set, only the directories Documents
and Settings, Program Files, and the Windows system folders on the system drive
(typically c:) are available within SVW.
NOTE: If you set the Restricted View of Files option, and your end-users
configure partitioned drives, they will be unable to access any
applications or files residing on any drive other than the system (c:)
drive. If you allow your end-users to partition drives, you should not use
the Restricted View.
•
Removable Drives—Select to allow end-user access to removable drives on the
end-user’s client machine.
If an end-user installs a USB removable storage device he may experience the two
following behaviors, depending also on how you set this option:
•
If the user connects the USB device before initiating an SVW session, the device
will appear to be a fixed hard drive and the user will not be able to read or write
to the device during an SVW session, even when you have set the Removable
Drives option.
•
If the user connects the USB device after initiating an SVW session, the device
appears to be removable media and the user can access it, if you have set the
Removable Drives option when configuring SVW.
•
Network Share Access—Select to allow end-user access to network share drives.
•
Switch to Real Desktop—Select to allow end-user to toggle between the Secure
Virtual Workspace and the end-user’s client desktop.
•
Desktop Persistence—Select to allow end-users to maintain a Secure Virtual
Workspace across client sessions on NTFS file systems only.
Copyright © 2011, Juniper Networks, Inc.
333
Secure Access Administration Guide
NOTE: Desktop persistence and switching are not supported on FAT16
or FAT32 file systems.
If you select this option, note that multiple users using the same
password to encrypt their SVW workspace on the same host could gain
access to the persistent data storage protected by that static password.
We recommend that your users employ strong password when securing
their SVW persistent data store on multi-user systems.
•
Virtual File Execution—Select to allow virtualized file applications to run within a
Secure Virtual Workspace environment. By default, downloading an executable
within Secure Virtual Workspace encrypts that executable and prevents it from
being run. Selecting this option allows executables to be downloaded without
encrypting them.
5. Continue to define the policy or click Save Changes.
Related
Documentation
•
Enabling the Secure Virtual Workspace on page 330
Defining a Secure Virtual Workspace Application Policy
You can specify which applications the end-user can install or run when using the Secure
Virtual Workspace.
To define a new Secure Virtual Workspace application policy:
1.
In the admin console, choose Authentication > Endpoint Security > Secure Virtual
Workspace.
2. Click New Secure Virtual Workspace Policy or click the hyperlinked name of an existing
Secure Virtual Workspace policy.
3. Enter a name for the policy.
4. Under Applications, select the checkboxes for the types of applications you want to
enable:
334
•
Control panel—Select to allow the end-user to access the Windows control panel
while in the Secure Virtual Workspace.
•
Run menu—Select to allow the end-user to access the Windows run menu while in
the Secure Virtual Workspace.
•
Registry editor—Select to allow the end-user to access the Windows registry editor
(regedt32.exe) while in the Secure Virtual Workspace.
•
Task manager—Select to allow the end-user to access the Windows Task Manager
(taskmgr.exe) and system processes while in the Secure Virtual Workspace.
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
•
Command window—Select to allow the end-user to access the Windows Command
window (cmd.exe) and execute commands while in the Secure Virtual Workspace.
•
Custom applications—You can identify custom applications that the end-user is
allowed to run while in the Secure Virtual Workspace. For example, you might include
in-house applications, non-default browsers, and other types of applications. Enter
one application, including the .exe extension per line in the multiline text box. You
can also use the * wildcard for an entire class of applications, and you can include
an optional MD5 hash value following the executable name and a comma,
telnet.exe,0414ea8.
•
Applications to deny—You can identify applications you want to restrict from
end-user use while in the Secure Virtual Workspace. Enter one application, including
the extension for each executable per line in the multiline text box.
NOTE: Any custom application that is not listed in the Custom
applications field is denied by default.
If you add the same application to the Custom applications text box
and to the Applications to deny text box, the deny action takes
precedence and users will be denied access to the application SVW
sessions. Be aware that this can happen if you use wildcards to specify
applications in both lists. For example, if you specify *plore.exe in the
allow list and iex*.exe in the deny list, then iexplore.exe will be denied.
5. Continue to define the policy or click Save Changes.
After you define one or more Virtual Workspace policies, you must enable them as Realm
authentication policies at the user level.
Related
Documentation
•
Implementing Host Checker Policies on page 309
•
Defining a Secure Virtual Workspace Security Policy on page 335
•
Defining Secure Virtual Workspace Remediation Policy on page 337
Defining a Secure Virtual Workspace Security Policy
You can specify encryption levels and can control the use of 3rd-party extensions in
Internet Explorer and Outlook.
To specify security options for a new Secure Virtual Workspace policy:
1.
In the admin console, choose Authentication > Endpoint Security > Secure Virtual
Workspace.
2. Click New Secure Virtual Workspace Policy or click the hyperlinked name of an existing
Secure Virtual Workspace policy.
3. Enter a name for the policy.
Copyright © 2011, Juniper Networks, Inc.
335
Secure Access Administration Guide
4. Specify the type of AES encryption key the SA Series Appliance uses to enable the
Secure Virtual Workspace on the client. The available options are 128, 192, and 256-bit
encryption keys.
5. Identify the IE or Outlook extensions you want to allow by including each allowable
DLL on a separate line in the IE/Outlook extensions to allow text box. Any extension
that is not listed is denied, by default.
These extensions are small applications that are passed into and out of the Secure
Virtual Workspace session.
6. Continue to define the policy or click Save Changes.
Related
Documentation
•
Defining a Secure Virtual Workspace Application Policy on page 334
•
Defining Secure Virtual Workspace Remediation Policy on page 337
Defining Secure Virtual Workspace Environment Options
To specify environment options for a new Secure Virtual Workspace policy:
1.
In the admin console, choose Authentication > Endpoint Security > Secure Virtual
Workspace.
2. Click New Secure Virtual Workspace Policy or click the hyperlinked name of an existing
Secure Virtual Workspace policy.
3. Enter a name for the policy.
4. Under Options, specify:
•
The maximum length of time (in minutes) a client’s Secure Virtual Workspace
session can remain idle before the connection to Secure Access times out.
•
The desktop wallpaper image (Optional).
•
The desktop background color (Optional).
•
The sign-in URL to use to access the SVW.
The available URLs include the default User sign-in URL and any URLs you have
defined in Authentication > Signing in > Sign-in Policies. The first time SVW puts
the user into the virtual workspace and initiates a browser, it takes the user to Secure
Access using a sign-in URL. By default, this sign-in URL is the same one that the
user has entered to start their Secure Access session. You can configure a different
sign-in URL through this option.
NOTE: Secure Access does not support host names that contain a
wildcard, such as *.host.com/[path].
336
Copyright © 2011, Juniper Networks, Inc.
Chapter 13: Host Checker
•
The string to display in the toolbar title. By default, “SVW Title” is displayed.
•
To allow users to hide the toolbar, select the Autohide Toolbar option. When users
choose to hide the toolbar (by clicking the thumbtack icon in the toolbar), they must
scroll to the top of their desktop in order to make the toolbar reappear.
5. Continue to define the policy or click Save Changes.
Related
Documentation
•
Enabling the Secure Virtual Workspace on page 330
Defining Secure Virtual Workspace Remediation Policy
To specify remediation options for a new Secure Virtual Workspace policy:
1.
In the admin console, choose Authentication > Endpoint Security > Secure Virtual
Workspace.
2. Click New Secure Virtual Workspace Policy or click the hyperlinked name of an existing
Secure Virtual Workspace policy.
3. Enter a name for the policy.
4. Under Remediation, select remediation options for users whose computers do not
meet the requirements specified in the policy.
NOTE: If you do not create remediation instructions and the policy fails,
your users will not know why they cannot launch the Secure Virtual
Workspace or access local resources.
•
Enable Custom Instructions—Select to expand text box in which you can enter
custom instructions, using either text or HTML, that will be presented to end-users
when the Secure Virtual Workspace encounters a remediation problem.
•
Enable Custom Actions—You can select one or more alternate policies that you
want Host Checker to evaluate if the user’s computer does not meet the current
policy requirements. The alternate policy must be either a third-party policy that
uses a J.E.D.I. package or another Secure Virtual Workspace policy. For example,
you can use a J.E.D.I. package to launch an application if the user’s computer does
not meet the current policy requirements. Select the alternate policy in the HC
Policies list and then click Add.
•
Kill Processes—Select to open text box in which you enter application processes
and MD5 hash values for the processes you want killed. For example:
Application.exe
MD5: 6A7DFAF12C3183B56C44E89B12DBEF56
MD5: 9S3AJ912CC3183B56C44E89B12DI2AC9
Copyright © 2011, Juniper Networks, Inc.
337
Secure Access Administration Guide
•
Delete Files—Select to open text box in which you can enter file names, one per
line, of files you want deleted.
•
Send reason strings—Select to send remediation information.
5. Click Save Changes.
Related
Documentation
338
•
Configuring General Host Checker Remediation on page 315
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 14
Cache Cleaner
•
About Cache Cleaner on page 339
•
Setting Global Cache Cleaner Options on page 339
•
Implementing Cache Cleaner Options on page 342
•
Specifying Cache Cleaner Restrictions on page 343
•
About Cache Cleaner Logs on page 344
About Cache Cleaner
Cache Cleaner is a Host Checker policy that removes residual data, such as temporary
files or application caches, left on a user’s machine after a Secure Access session. For
example, when a user signs in to Secure Access from an Internet kiosk and opens a
Microsoft Word document using a browser plug-in, Cache Cleaner can remove the
temporary copy of the Word file stored in the browser cache (Windows folder) when the
session terminates. By removing the copy, Cache Cleaner prevents other kiosk users from
finding and opening the Word document after the Secure Access user concludes the
session.
Cache Cleaner can also prevent Web browsers from permanently storing the usernames,
passwords, and Web addresses that users enter in Web forms. By preventing browsers
from improperly caching this information, Cache Cleaner keeps confidential user
information from being stored on untrusted systems.
NOTE: Cache cleaner does not currently support Secure Virtual Workspace
(SVW).
Related
Documentation
•
Setting Global Cache Cleaner Options on page 339
•
Implementing Cache Cleaner Options on page 342
Setting Global Cache Cleaner Options
When you enable Cache Cleaner, it clears all content downloaded through Secure Access’
Content Intermediation Engine from a user’s system. In addition, you can use settings in
Copyright © 2011, Juniper Networks, Inc.
339
Secure Access Administration Guide
the Authentication > Endpoint Security > Cache Cleaner page of the admin console to
clear content from the following places:
•
Specified hosts and domains—If you enable WSAM or JSAM, you may want to configure
Cache Cleaner to clear additional hosts and domains. When users browse the Internet
outside Secure Access using WSAM or JSAM, Internet files appear in their temporary
Internet file folder. To delete these files using Cache Cleaner, you must specify the
appropriate hostname (for example, www.yahoo.com).
•
Specified files and folders—If you enable your users to access client-server applications
on their local systems, you may want to configure Cache Cleaner to clear the temporary
files and folders that the applications create on the users’ systems.
NOTE: If you configure Cache Cleaner to remove files from a directory,
Cache Cleaner clears all files, including those that the user has explicitly
saved to the directory and files that were in the directory prior to the Secure
Access session.
Only one Cache Cleaner policy is allowed. You can neither delete the default Cache
Cleaner policy (named “Cache Cleaner Policy”) nor create a new one.
To specify global Cache Cleaner options:
1.
Select Authentication > Endpoint Security > Cache Cleaner in the admin console.
2. Under Options:
a. Specify how often Cache Cleaner runs in the Cleaner Frequency field. Valid values
range from 1 to 60 minutes. Each time Cache Cleaner runs, it clears all content
downloaded through the Secure Access Content Intermediation Engine plus the
browser cache, files, and folders you specify under the Browser Cache and Files
and Folders sections.
b. Select the Disable AutoComplete of web addresses check box to prevent the
browser from using cached values to automatically fill in Web addresses during
the user’s Secure Access session. When you select this option, Secure Access
sets the following Windows registry value to 0 during the user’s Secure Access
session:
HKEY_CURRENT_USER\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\
AutoComplete.
Then, at the end of the session, Secure Access restores the registry value to its
original setting.
c. Select the Disable AutoComplete of usernames and passwords check box to
prevent Internet Explorer from automatically filling in user credentials in Web
forms using cached values. Selecting this option also disables the “Save
Password?” prompt on Windows systems. When you select this option, Secure
Access sets the following Windows registry values to 0:
•
340
HKEY_CURRENT_USER\Software\Microsoft\Internet
Explorer\Main\FormSuggest Passwords
Copyright © 2011, Juniper Networks, Inc.
Chapter 14: Cache Cleaner
•
HKEY_CURRENT_USER\Software\Microsoft\Internet
Explorer\Main\FormSuggest Passwords\FormSuggest PW Ask
•
HKEY_CURRENT_USER\SOFTWARE\Microsoft\
Windows\CurrentVersion\Internet Settings\ DisablePasswordCaching
d. Select the Flush all existing AutoComplete Passwords check box to clear any
cached passwords that Internet Explorer has cached on the user’s system. When
you select this option, Secure Access sets the following Windows registry value
to 0:
HKEY_CURRENT_USER \Software\\Microsoft\\Internet Explorer\\
IntelliForms\\SPW
Then, select one of the following options:
•
Select the For IVE session only option button to specify that Secure Access
should restore the user’s cached passwords at the end of his Secure Access
session.
•
Select the Permanently option button to permanently delete the user’s cached
passwords.
e. Select the Empty Recycle Bin and Recent Documents list check box to empty
the recycle bin and clear the recent documents list. The entire contents are
removed, not just the files related to the user’s sessions.
3. Under Browser Cache, enter one or more hostnames or domains (wildcards are
permitted). When a user session ends, Cache Cleaner removes any content in the
browser cache that originates from these servers. Cache Cleaner also removes this
content when it runs at the specified cleaner frequency interval. Note that Secure
Access does not resolve hostnames, so enter all possible representations of a server,
such as its hostname, FQDN, and IP address.
4. Under Files and Folders:
a. Specify either:
•
The name of a file that you want Cache Cleaner to remove.
•
The complete directory path to a folder whose contents you want Cache
Cleaner to remove. If you specify a directory, select Clear Subfolders to also
clear the contents of any subdirectories within this directory.
b. Select the Clear folders only at the end of session check box if you want Cache
Cleaner to clear directory contents only at the end of the user session. Otherwise,
Cache Cleaner also clears files and folders at the specified cleaner frequency
interval
Copyright © 2011, Juniper Networks, Inc.
341
Secure Access Administration Guide
NOTE: When specifying files and folders to clear, note the following:
Cache Cleaner uses a cookie called DSPREAUTH to send the client’s
status to Secure Access. If you delete this cookie from the user’s
client, Cache Cleaner does not work properly. To avoid problems, do
not specify Internet Explorer directories such as <userhome>\Local
Settings\Temporary Internet Files\* under File or folder path. Note
that Cache Cleaner still clears all of the Internet Explorer cache
downloaded from the Secure Access host and the other hosts
specified in the Hostnames box, regardless of what directories you
specify under Files and Folders.
For the Firefox browser, Cache Cleaner clears only those directories
you specify under Files and Folders.
5. Click Save Changes to save these settings globally.
If more than one valid Secure Access session exists from the same system and
Cache Cleaner is used in those sessions, all sessions are terminated when a user
signs out from one of the sessions. To prevent this, turn off Cache Cleaner for those
sessions that do not need Cache Cleaner.
NOTE: If multiple administrators or end users to a single Secure Access
are signed in from the same client system and at least one of them
deploys Cache Cleaner, unexpected results may occur. For example,
Cache Cleaner might shut down, role privileges might be lost, and forced
disconnections might occur.
Related
Documentation
•
Implementing Cache Cleaner Options on page 342
Implementing Cache Cleaner Options
After you specify which hosts, domains, files, and folders to clear using settings in the
Authentication > Endpoint Security > Cache Cleaner page of the admin console, you can
restrict Secure Access and resource access by requiring Cache Cleaner in the following
options:
•
342
Realm authentication policy—When users try to sign in to Secure Access, Secure Access
evaluates the specified realm’s authentication policy to determine if the
pre-authentication requirements include Cache Cleaner. You can configure a realm
authentication policy to evaluate whether to require and enforce the Cache Cleaner
policy in order for the user to log in to the specified realm. If the user’s computer does
not meet the requirements, then the user is denied access to Secure Access. As a
post-authentication requirement, you can evaluate without enforcing the Cache Cleaner
policy on the client and allow user access. You configure realm-level restrictions through
Copyright © 2011, Juniper Networks, Inc.
Chapter 14: Cache Cleaner
the Users > User Realms > Realm> Authentication Policy > Host Checker page of the
admin console.
•
Role—When Secure Access determines the list of eligible roles to which it can map an
administrator or user, it evaluates each role’s restrictions to determine if the role requires
Cache Cleaner to run on the user's workstation. If it does and the user's machine is not
already running Cache Cleaner, then Secure Access does not map the user to that role.
You can control which roles Secure Access maps a user to by using settings in Users
> User Realms > Realm > Role Mapping. Select or create a rule and then select Custom
Expressions. You can configure role-level restrictions through the Users > User Roles
> Role > General > Restrictions > Host Checker page of the admin console.
•
Resource policy—When a user requests a resource, Secure Access evaluates the
resource policy’s detailed rules to determine whether or not Cache Cleaner needs to
be installed or running on the user's workstation. Secure Access denies access to the
resource if the user's machine does not meet the Cache Cleaner requirement. You can
implement Cache Cleaner restrictions at the resource policy level through the Condition
Field box of the Rules window. Select Users > Resource Policies > Resource > Policy >
Detailed Rules and set hostCheckeryPolicy = ‘Cache Cleaner policy’.
You may specify that Secure Access evaluate your Cache Cleaner policies only when the
user first tries to access the realm, role, or resource that references the Cache Cleaner
policy. Or, you can use settings in the Authentication > Endpoint Security > Cache Cleaner
tab to specify that Secure Access periodically re-evaluate the policies throughout the
user’s session. If you choose to periodically evaluate Cache Cleaner policies, Secure
Access dynamically maps users to roles and allows users access to new resources based
on the most recent evaluation.
When the user tries to access Secure Access, Host Checker evaluates its policies (Cache
Cleaner is a Host Checker policy) in the following order:
Related
Documentation
•
Initial evaluation
•
Realm-level policies
•
Role-level policies
•
Resource-level policies
•
Setting Global Cache Cleaner Options on page 339
Specifying Cache Cleaner Restrictions
To specify Cache Cleaner restrictions:
1.
Select Authentication > Endpoint Security > Cache Cleaner and specify global
options for Cache Cleaner to apply to any user for whom Cache Cleaner is required in
an authentication policy, a role mapping rule, or a resource policy.
2. Implement Cache Cleaner at the realm level and role level as you would with Host
Checker.
Copyright © 2011, Juniper Networks, Inc.
343
Secure Access Administration Guide
3. Create role-mapping rules based on a user’s Cache Cleaner status as you would with
Host Checker.
4. To implement Cache Cleaner at the resource policy level:
a. Select Users > Resource Policies > Select Resource > Select Policy > Detailed
Rules.
b. Click New Rule or select an existing rule from the Detailed Rules list.
c. Create a custom expression in a detailed rule that sets hostCheckeryPolicy = ‘Cache
Cleaner policy’.
Related
Documentation
•
About Host Checker Restrictions on page 311
•
Custom Expressions on page 1005
About Cache Cleaner Logs
Since Cache Cleaner is a Host Checker policy, it is included in the Host Checker logs. Use
the System > Log/Monitoring > Client Logs > Settings tab to enable client-side logging
for Host Checker. When you enable this option, Secure Access writes a client-side log to
any client that uses Host Checker. Secure Access appends to the log file each time the
feature is invoked during subsequent user sessions. This feature is useful when working
with the support team to debug problems with the respective feature.
344
Copyright © 2011, Juniper Networks, Inc.
PART 4
Remote Access
•
Hosted Java Applets Templates on page 347
•
Citrix Templates on page 361
•
Lotus iNotes Templates on page 371
•
Microsoft OWA Templates on page 375
•
Microsoft Sharepoint Templates on page 379
•
Web Rewriting on page 381
•
File Rewriting on page 455
•
Secure Application Manager on page 477
•
Telnet/SSH on page 533
•
Terminal Services on page 543
•
Secure Meeting on page 593
•
Email Client on page 617
•
Network Connect on page 625
Copyright © 2011, Juniper Networks, Inc.
345
Secure Access Administration Guide
346
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 15
Hosted Java Applets Templates
•
About Hosted Java Applet Templates on page 347
•
Task Summary: Hosting Java Applets on page 348
•
Uploading Java Applets to Secure Access on page 348
•
Signing Uploaded Java Applets on page 349
•
Creating HTML Pages That Reference Uploaded Java Applets on page 350
•
Accessing Java Applet Bookmarks on page 350
•
Creating a Hosted Java Applet Resource Profile on page 351
•
Configuring Hosted Java Applet Resource Profile Bookmarks on page 352
•
Creating Hosted Java Applets Bookmarks Through the User Roles Page on page 354
•
Required Attributes for Uploaded Java Applets on page 355
•
Required Parameters for Uploaded Java Applets on page 356
•
Use case: Creating a Citrix JICA 9.5 Java Applet Bookmark on page 357
About Hosted Java Applet Templates
The Secure Access Java applet upload feature enables you to store the Java applets of
your choice directly on Secure Access without employing a separate Web server to host
them. When you use this feature, you simply upload the applets to Secure Access (along
with additional files that the applets reference) and create a simple Web page through
Secure Access that references the files. Then, Secure Access intermediates the Web
page and Java applet content using its Content Intermediation Engine.
For example, you might want to use Secure Access to intermediate traffic between an
IBM AS/400 system on your network and individual 5250 terminal emulators on your
users’ computers. To configure Secure Access to intermediate this traffic, obtain the
5250 terminal emulator’s Java applet. Then you can upload this applet to Secure Access
and create a simple Web page that references the applet. After you create the Web page
through Secure Access, Secure Access creates a corresponding bookmark that users can
access through their home pages.
Secure Access enables you to host Java applets using Web resource profile templates
(described in these topics) as well as through Terminal Services resource profiles.
Copyright © 2011, Juniper Networks, Inc.
347
Secure Access Administration Guide
The hosted Java applets feature is a standard feature on all Secure Access appliances
except the SA 700. If you are using an SA-700 appliance, you must install a Core Clientless
Access upgrade license to access the hosted Java applets feature.
Related
Documentation
•
Task Summary: Hosting Java Applets on page 348
Task Summary: Hosting Java Applets
The SA Series Appliance Java applet upload feature enables you to store the Java applets
of your choice directly on the SA Series Appliance without employing a separate Web
server to host them.
To host Java applets on the SA Series Appliance:
1.
Specify which applets you want to upload, create SA Series Appliance bookmarks
that reference the uploaded applets, and specify which roles can access the bookmarks
using settings in the Users > Resource Profiles > Web page of the admin console.
2. (Optional.) To sign your Java applets, Select System > Configuration > Certificates >
Code-Signing Certificates in the admin console to upload the Java certificate to the
SA Series Appliance. If you choose to skip this step, the user sees an untrusted
certificate warning each time he accesses the corresponding bookmark.
3. (Optional.) To improve the performance of your Java applications:
a. Select Enable Java instrumentation caching on the Maintenance > System >
Options page of the admin console. This option can improve the performance of
downloading Java applications.
b. After you finish configuring the SA Series Appliance, cache your Java applet and
access it as an end user. This action eliminates the performance hit that occurs
through the intermediation engine when the first end user accesses the applet.
Related
Documentation
•
Using Code-signing Certificates on page 745
•
Uploading Java Applets to Secure Access on page 348
•
Signing Uploaded Java Applets on page 349
•
Creating HTML Pages That Reference Uploaded Java Applets on page 350
Uploading Java Applets to Secure Access
You can use Java applets to intermediate traffic to various types of applications through
Secure Access. For example, you can upload the 3270 applet, 5250 applet, or Citrix Java
applet to Secure Access. These applets enable users to establish sessions to IBM
mainframes, AS/400s, and Citrix MetaFrame servers through terminal emulators. (Note
that to enable the Citrix Java ICA client through a Secure Access session, you must upload
multiple Citrix .jar and .cab files to Secure Access.
348
Copyright © 2011, Juniper Networks, Inc.
Chapter 15: Hosted Java Applets Templates
Secure Access enables you to upload individual .jar and .cab files or .zip, .cab, or .tar
archive files. Archive files can contain Java applets and files referenced by the applets.
Within the .zip, .cab, or .tar file, the Java applet must reside at the top level of the archive.
You can upload any number of files to Secure Access as long as their combined size does
not exceed 100 MB.
To ensure compatibility with both Sun and Microsoft Java Virtual Machines (JVMs), you
must upload both .jar and .cab files to Secure Access. (The Sun JVM uses .jar files, whereas
the Microsoft JVM uses .cab files.)
NOTE: When you upload Java applets to Secure Access, Secure Access asks
you to read a legal agreement before it finishes installing the applets. Read
this agreement carefully—it obligates you to take full responsibility for the
legality, operation, and support of the Java applets that you upload.
You can only upload 100 MB of Java applets to Secure Access. Secure Access
displays the size of each applet that you upload to Secure Access on the Java
Applets page so you can determine, if necessary, which applets you want to
delete.
Uploading Java applets requires signed ActiveX or signed Java applets to be
enabled within the browser to download, install, and launch the client
applications.
Related
Documentation
•
Task Summary: Hosting Java Applets on page 348
Signing Uploaded Java Applets
Unlike other Java applets that users can access through Secure Access, you do not have
to create a separate code-signing policy for the Java applets that you upload to Secure
Access. Secure Access automatically signs (or re-signs) them using the appropriate
code-signing certificate. A code-signing certificate (also called an applet certificate) is
a type of server-side certificate that re-signs Java applets intermediated by Secure Access.
Secure Access automatically signs (or resigns) your hosted Java applets with the
code-signing certificate that you install through the System > Configuration > Certificates
> Code-signing Certificates page of the admin console. If you do not install a code-signing
certificate on Secure Access, Secure Access uses its self-signed applet certificate to sign
or re-sign the applets. In this case, users see an “untrusted certificate issuer” warning
whenever they access the Java applets through Secure Access.
NOTE: Secure Access re-instruments and re-signs your uploaded Java applets
whenever you change (that is, import, renew, or delete) the corresponding
code-signing certificate on Secure Access.
Copyright © 2011, Juniper Networks, Inc.
349
Secure Access Administration Guide
Related
Documentation
•
Task Summary: Hosting Java Applets on page 348
Creating HTML Pages That Reference Uploaded Java Applets
When uploading a Java applet to Secure Access, you must create a simple Web page
that references the applet. Users can access this Web page through a bookmark on their
Secure Access home pages or from external Web servers.
The Web page must contain a simple HTML page definition that references the uploaded
Java applet. The Web page can also contain any additional HTML and JavaScript that
you choose. Secure Access can generate some of the Web page for you, including the
HTML page definition and the references to your Java applet. (Note, however, that Secure
Access is not aware of all the applet-specific parameters that are required by your
applet—you must find and fill these parameters in yourself.) When Secure Access
generates this HTML, it creates placeholders for any undefined values and prompts you
to fill in the necessary values.
You can create these Web pages through Java applet upload resource profiles.
Related
Documentation
•
Task Summary: Hosting Java Applets on page 348
•
Accessing Java Applet Bookmarks on page 350
Accessing Java Applet Bookmarks
Users can access the applets you upload to Secure Access using two methods:
•
Bookmarks on the Secure Access end-user console—When you create a Web page
that references your uploaded Java applets, Secure Access creates a corresponding
link to the Web page and displays that link in the Bookmarks section of the Secure
Access end-user console. Users who map to the appropriate role can simply click the
link to access the Java applet.
•
Links on external Web servers—Users can link to the Java applet bookmarks from an
external Web server by simply using the correct URLs. When the user enters a
bookmark’s URL (or clicks an external link that contains the URL), Secure Access
prompts the user to enter his Secure Access username and password. If he properly
authenticates, Secure Access allows him to access the bookmark. You can construct
the URL to the Java applet bookmark using the syntax described in either of the following
lines:
https://IVE_hostname/dana/home/launchwebapplet.cgi?bmname=bookmark Name
https://IVE_hostname/dana/home/launchwebapplet.cgi?id=<resourceID>&bmname=bookmarkName
You can determine the ID for a Java applet bookmark by accessing it through the Secure
Access home page and then extracting the ID from the Web browser’s address bar.
350
Copyright © 2011, Juniper Networks, Inc.
Chapter 15: Hosted Java Applets Templates
NOTE: Although Secure Access enables you to create multiple bookmarks
with the same name, we strongly recommend that you use a unique name
for each. If multiple bookmarks have the same name and a user accesses
one of these bookmarks using a URL that includes the bmname parameter,
Secure Access randomly picks which of the identically named bookmarks to
display to the user. Also note that the bmname parameter is case-sensitive.
If you create links on external servers to Java applet bookmarks on Secure
Access and you are using multiple customized sign-in URLs, some restrictions
occur.
Related
Documentation
•
Configuring Hosted Java Applet Resource Profile Bookmarks on page 352
•
Creating Hosted Java Applets Bookmarks Through the User Roles Page on page 354
Creating a Hosted Java Applet Resource Profile
To create a hosted Java applet resource profile:
1.
Select Users > Resource Profiles > Web in the admin console.
2. Click New Profile.
3. Select Hosted Java Applet from the Type list.
4. Enter a unique name and optionally a description for the resource profile.
5. Select the Java applet that you want to associate with the resource profile from the
Applet to use list. Or, if the applet that you want to use is not currently available in
the list, click Edit Applet. Then:
a. Click New Applet to add an applet to this list. Or, select an existing applet and click
Replace (to replace an existing applet with a new applet) or Delete (to remove an
applet from Secure Access)
NOTE: If you replace an existing archive, make sure that the new applet
archive contains all of the necessary files for the applet to successfully
launch and run. If the associated HTML for the applet refers to files
that do not exist in the new archive, then the applet will not function
correctly.
Secure Access only allows you to delete applets that are not currently
in use by a Web or Terminal Services resource profile.
b. Enter a name to identify the applet in the Name box (for new and replaced applets
only).
Copyright © 2011, Juniper Networks, Inc.
351
Secure Access Administration Guide
c. Browse to the applet that you want to upload to Secure Access. You can upload
applets (.jar or .cab files) or archives (.zip, .jar, and .tar files) that contain applets
and all of the resources that the applets need (for new and replaced applets only).
d. Select the Uncompress jar/cab file check box if the file that you selected is an
archive that contains the applet (New and replaced applets only).
e. Click OK and then click Close Window.
NOTE: When you select an applet in the Java Applets dialog box, you
are loading third-party software onto the Juniper product. By clicking
OK, you are agreeing to the following terms on behalf of yourself (as
purchaser of the equipment) or the organization that purchased the
Juniper product, as applicable.
By loading third party software onto the Juniper Networks product, you
are responsible for obtaining all rights necessary for using, copying,
and/or distributing such software in or with the Juniper Networks
product. Juniper is not responsible for any liability arising from use of
such third party software and will not provide support for such software.
The use of third party software may interfere with the proper operation
of the Juniper Networks product and/or Juniper Networks software,
and may void any warranty for the Juniper Networks product and/or
Juniper Networks software.
6. Use settings in the Autopolicy: Java Access Control section to enable access if your
Java applets need to make socket connections.
7. Click Save and Continue.
8. Select the roles to which the resource profile applies In the Roles tab and click Add.
The selected roles inherit the autopolicies and bookmarks created by the resource
profile. If it is not already enabled, Secure Access also automatically enables the Web
option in the Users > User Roles > Select_Role > General > Overview page of the
admin console and the Allow Java Applets option Users > User Roles > Select_Role
> Web > Options page of the admin console for all of the roles you select.
9. Click Save Changes.
10. Create bookmarks in the Bookmarks tab.
Related
Documentation
•
Configuring Hosted Java Applet Resource Profile Bookmarks on page 352
Configuring Hosted Java Applet Resource Profile Bookmarks
You must create bookmarks to your hosted Java applets to enable end users to access
the applets.
352
Copyright © 2011, Juniper Networks, Inc.
Chapter 15: Hosted Java Applets Templates
To configure hosted Java applet resource profile bookmarks:
1.
Select Users > Resource Profiles > Web >Select Resource Profile> Bookmarks in the
admin console.
2. Click the appropriate link in the Bookmark column if you want to modify an existing
bookmark. Or, click New Bookmark to create an additional bookmark.
NOTE: Although it is generally easiest to create a resource profile session
bookmark through the resource profile configuration page, you can choose
to create one through the user roles page as well if you have already
created a resource profile.
3. Enter a name and optionally a description for the bookmark. This information displays
on the Secure Access home page. (By default, Secure Access names the bookmark
the same name as the corresponding resource profile.)
NOTE: We strongly recommend that you use a unique name for each
bookmark to make it clear to users which link they are accessing.
4. Click Generate HTML to create an HTML page definition that includes references to
your Java applets. Then, fill in any required attributes and parameters.
If you are using HTML generated by Secure Access, make sure to search the HTML
code for “__PLEASE_SPECIFY__” and update the code as necessary.
You can also add more HTML or JavaScript to this Web page definition. Secure Access
rewrites all of the code that you enter in this field
NOTE: Make sure to enter unique HTML in this field. If you create two
bookmarks with the same HTML code, Secure Access deletes one of the
bookmarks in the end-user view. You will still be able to see both
bookmarks, however, in the administrator console.
5. List those attributes in the Multi-Valued User Attributes box if your HTML code contains
attributes that may expand to multiple values (such as userAttr.hostname or
userAttr.ports), . When the user signs into Secure Access, Secure Access evaluates
these attributes and creates separate bookmarks as necessary based on each of the
individual values. If you use an attribute that expands to multiple values, but do not
enter that attribute in this box, Secure Access creates a single bookmark based on
the attribute’s first value.
6. Under Display options, click Bookmark opens new window to enable Secure Access
to automatically open the Web resource in a new browser window. Note that this
functionality applies only to role bookmarks and not bookmarks created by users.
Next, select the following options if you want to hide UI elements from the user:
•
Do not display the browser address bar—Select this option to remove the address
bar from the browser window. This feature forces all Web traffic through Secure
Copyright © 2011, Juniper Networks, Inc.
353
Secure Access Administration Guide
Access by precluding users in the specified role from typing a new URL in the address
bar, which circumvents Secure Access.
•
Do not display the browser toolbar—Select this option to remove the menu and
toolbar from the browser. This feature removes all menus, browsing buttons, and
bookmarks from the browser window so that the user browses only through Secure
Access.
7. Under Roles, specify the roles to which you want to display the bookmark if you are
configuring the bookmark through the resource profile pages:
•
ALL selected roles—Select this option to display the bookmark to all of the roles
associated with the resource profile.
•
Subset of selected roles—Select this option to display the bookmark to a subset of
the roles associated with the resource profile. Then select roles from the ALL
Selected Roles list and click Add to move them to the Subset of selected roles list.
8. Click Save Changes.
Related
Documentation
•
Defining Resource Profile Bookmarks on page 116
•
Creating Hosted Java Applets Bookmarks Through the User Roles Page on page 354
•
Creating HTML Pages That Reference Uploaded Java Applets on page 350
•
Required Attributes for Uploaded Java Applets on page 355
•
Required Parameters for Uploaded Java Applets on page 356
Creating Hosted Java Applets Bookmarks Through the User Roles Page
It is generally easiest to create a hosted Java applets bookmark through the resource
profile configuration pages, as explained in previous topic. However, you can choose to
create a resource profile session bookmark through the user roles page using the following
instructions:
1.
Select Users > Roles > Select_Role > Web > Bookmarks in the admin console.
2. Click New Bookmark.
3. Select Pick a Web Resource Profile from the Type list. (Secure Access does not
display this option if you have not already created a hosted Java applet resource
profile.)
4. Select an existing resource profile.
5. Click OK. (If you have not already associated the selected role with the resource profile,
Secure Access automatically makes the association for you. Secure Access also
enables any access control policies for the role that are required by the resource
profile.)
6. If this role is not already associated with the selected resource profile, Secure Access
displays an informational message. If you see this message, click Save Changes to
354
Copyright © 2011, Juniper Networks, Inc.
Chapter 15: Hosted Java Applets Templates
add this role to the resource profile’s list of roles and to update the profile’s autopolicies
as required. Then, repeat the previous steps to create the bookmark.
7. Configure the bookmark settings.
NOTE: When you create a resource profile bookmark through the user
roles page (instead of the standard resource profiles page), Secure Access
only associates the generated bookmark with the selected role. Secure
Access does not assign the bookmark to all of the roles associated with
the selected resource profile.
Related
Documentation
•
Accessing Java Applet Bookmarks on page 350
•
Configuring Hosted Java Applet Resource Profile Bookmarks on page 352
Required Attributes for Uploaded Java Applets
When you create a Java applets bookmark through Secure Access, you must define the
following attributes and their corresponding values. If you use the Generate HTML feature,
Secure Access populates some of this information for you and adds PLEASE_SPECIFY
to those attributes whose values you must specify. When specifying attributes and their
corresponding values, use the attribute=”value” format.
NOTE: Secure Access generates parameters that it knows are required. Note,
however, that Secure Access is not aware of all the applet-specific parameters
that are required by your applet—you must find and fill in these parameters
yourself.
Attributes that are required by Secure Access include:
•
code—Indicates which class file to invoke in your Java applet. Use this value to point
to your Java applet’s main function. Example:
applet code="com.citrix.JICA"
•
codebase—Indicates where the Web browser can fetch the applet. Use the
<<CODEBASE>> variable, which points to the location on Secure Access where Secure
Access stores the Java applet. When entering a path to a file, note that <<CODEBASE>>
includes a trailing slash, which means the following example works:
<img src="<<CODEBASE>>path/to/file">
This example does not work:
<img src="<<CODEBASE>>/path/to/file">
•
archive—Indicates which archive file (that is, .jar, .cab, or .zip file) the Web browser
should fetch. Example:
archive="JICAEngN.jar"
Copyright © 2011, Juniper Networks, Inc.
355
Secure Access Administration Guide
In addition to the required attributes listed earlier, you may also use the following optional
attributes when creating a Java applet bookmark:
•
name—Specifies a label for the Java applet. Example:
name="CitrixJICA"
•
host—Specifies, for terminal sessions, the server to which Secure Access should connect.
•
port—Specifies, for terminal sessions, the port to which Secure Access should connect.
•
width and height—Indicates the size of the Java applet window. Example:
width="640" height="480"
•
align—Indicates the Java applet window’s alignment within the browser window.
Example:
align="top"
NOTE: When defining attributes and their corresponding values, note the
following:
•
We strongly recommend that you not include useslibrarycabbase parameter
in the HTML, because it causes the cab file to be permanently installed on
the user’s machine. If you later change a cab file on Secure Access, all users
will have to manually delete the cab files on their machines to get the new
version from Secure Access.
•
We do not support applet tags that are constructed through the
document.write function because the dynamic HTML interferes with the
Secure Access parser.
•
We do not support relative links to URLs, documents, or images in your
HTML. If you do, the links will break when the user tries to access them
from the Secure Access end-user console. Instead, you should include
absolute links. If you are linking to a document or image included in your
zip file, use the <<CODEBASE>> variable to indicate that Secure Access
can find the file in zip archive uploaded to Secure Access. For example:
<img src="<<CODEBASE>>yourcompany_logo.gif" alt="YourCompany">
Related
Documentation
•
Required Parameters for Uploaded Java Applets on page 356
Required Parameters for Uploaded Java Applets
When you create a Java applets bookmark through Secure Access, you must specify
parameters and values that Secure Access should pass to the Java applet. These
parameters are completely applet-specific. When specifying parameters and their
corresponding values, use the following format:
<param name=”parameterName” value=”valueName”>
356
Copyright © 2011, Juniper Networks, Inc.
Chapter 15: Hosted Java Applets Templates
Where all of the text is literal except parameterName and valueName.
You can use Secure Access variables to pass values to the Java applet by enclosing the
variable names in double-brackets. For example, you might choose to pass the
<<username>> and <<password>> values to the Java applet.
NOTE: When using the Java applet upload feature, if you include the
<password> token within the generated HTML, it appears as cleartext if you
view the source in the browser window that launches the applet. This behavior
cannot be changed because Secure Access does not control how the Java
applet processes the password. We strongly discourage the use of the
<password> token in the HTML code.
If you find a Web page that contains an applet that you want to use, go to the
demonstration site and view the source on the page that runs the Java applet. Within
the source, look at the applet tag. Pick out the code attribute in the source and determine
if it contains any special parameters that you need to pass to the browser. In most cases,
you should be able to copy and paste the code attribute and its corresponding parameters
directly into the HTML field for your Secure Access bookmark. Note, however, that if a
parameter references a resource on the local Web server, you cannot copy and paste
the reference into the Secure Access bookmark because Secure Access does not have
access to the other Web server’s local resources. When copying and pasting parameters
from another source, always check the values of the parameters.
Related
Documentation
•
Required Attributes for Uploaded Java Applets on page 355
Use case: Creating a Citrix JICA 9.5 Java Applet Bookmark
This topic discusses how to enable access to a Citrix Metaframe server through Secure
Access using the 9.5 Java version of the Citrix ICA client (JICA).
NOTE: In addition to the method described here, you can also use Terminal
Services resource profiles to host the Java versions of Citrix ICA clients on
Secure Access.
Secure Access supports several mechanisms for intermediating traffic
between a Citrix server and client, including the Terminal Services, JSAM,
WSAM, Network Connect, and hosted Java applets features.
To enable the Citrix JICA 9.5 client using the Java applet upload feature:
1.
Import code-signing certificates.
2. Download JICAcomponents.zip from the citrix.com downloads page.
Copyright © 2011, Juniper Networks, Inc.
357
Secure Access Administration Guide
3. Create a hosted Java applet resource profile through the Users > Resource Profiles >
Web page of the admin console. When defining the resource profile:
a. Upload the archived Citrix container file to Secure Access.
b. When uploading the applet, select the Uncompress jar/cab file check box because
the container file contains multiple jar and cab files.
c. Specify any Metaframe servers to which these applets may connect.
d. Assign the resource profile to the appropriate roles.
4. Generate the Web page for the bookmark in the resource profile’s Bookmarks tab.
Secure Access automatically inserts all of the .jar files into the corresponding Web
page. (JICA 95 supports only Sun JVM, so no cab files are present.) Then, specify
parameters for the Citrix client using the following examples as a guide. (Note that
the bookmark in the following example can contain references to the jar and cab files
that are in the zip file.
JICA 9.5 Applet Example
<html>
<head>
<title>jica95 Applet</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<!-Notes:
1) << CODEBASE >> is a system value that will get replaced at the time the applet is
launched. Please do not modify this value.
2) Please modify the remaining values as needed.
3) Please make sure all attribute names/values are enclosed in double quotes.
-->
<body>
<applet code="com.citrix.JICA"
codebase="<< CODEBASE >>"
archv
ie="JICA-browseNa
j.Jr,ICA-cdmNa
j.Jr,ICA-cp
li boardNa
j.Jr,ICA-confg
i Na
j.Jr,ICA-coreNa
j.Jr,ICA-prn
i terNa
j.Jr,ICA-seame
lssNa
j.Jr,ICA-sc
iaNa
j.Jr,ICA-zc
lNa
j.Jr,ICAEngNa
j.c
r,ryptoN
ja
j.s
r,slNa
j.Jr,ICA-audo
i Na
j. r"
width="640" height="480"
name="jica95" align="top">
<param name="code" value="com.citrix.JICA">
<param name="codebase" value="<< CODEBASE >>">
<param name="archive"
value="JICA-browseNa
j.Jr,ICA-cdmNa
j.Jr,ICA-cp
li boardNa
j.Jr,ICA-confg
i Na
j.Jr,ICA-coreNa
j.Jr,ICA-prn
i terNa
j.Jr,ICA-seame
lssNa
j.Jr,ICA-sc
iaNa
j.Jr,ICA-zc
lNa
j.Jr,ICAEngNa
j.c
r,ryptoN
ja
j.s
r,slNa
j.Jr,ICA-audo
i Na
j.r">
<param name="cabbase" value="">
<param name="name" value="jica95">
<param name="width" value="640">
<param name="height" value="480">
<param name="align" value="top">
<!-Please specify additional params here after the comment.
<param name="paramname" value="paramvalue">
-->
358
Copyright © 2011, Juniper Networks, Inc.
Chapter 15: Hosted Java Applets Templates
<param name="Address" value="__PLEASE_SPECIFY__">
<param name="Username" value="<< user >>">
<param name="password" value="<< password >>">
<param name="EncryptionLevel" value="1">
<param name="BrowserProtocol" value="HTTPonTCP">
</applet>
</body>
</html>
JICA 8.x Applet Example
The following sample includes generated HTML code for the 8.x JICA client, which
supported both Sun and MS JVMs:
<html>
<head>
<title>CitrixJICA Applet.</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<!-Notes:
1) << CODEBASE >> is a system value that will get
replaced at the time the applet is launched.
Please do not modify this value.
2) Please modify the remaining values as needed.
3) Please make sure all attribute names/values are
enclosed in double quotes.
-->
<body>
<applet code="com.citrix.JICA"
codebase="<< CODEBASE >>"
archive="JICAEngN.jar,JICA-sicaN.jar,cryptojN.jar,JICA-configN.jar,JICA-coreN.jar"
width="640" height="480"
name="CitrixJICA" align="top">
<param name="code" value="com.citrix.JICA">
<param name="codebase" value="<< CODEBASE >>">
<param name="archive"
value="JICAEngN.jar,JICA-sicaN.jar,cryptojN.jar,JICA-configN.jar,JICA-coreN.jar">
<param name="cabbase"
value="cryptojM.cab,JICA-configM.cab,JICAEngM.cab,JICA-sicaM.cab,JICA-coreM.cab">
<param name="name" value="CitrixJICA">
<param name="width" value="640">
<param name="height" value="480">
<param name="align" value="top">
<!-Please specify additional params here after the comment.
<param name="paramname" value="paramvalue">
-->
<param name="Address" value="__PLEASE_SPECIFY__">
<param name="Username" value="<< user >>">
<param name="password" value="<< password >>">
<param name="EncryptionLevel" value="1">
<param name="BrowserProtocol" value="HTTPonTCP">
</applet>
Copyright © 2011, Juniper Networks, Inc.
359
Secure Access Administration Guide
</body>
</html>
Related
Documentation
360
•
Accessing Java Applet Bookmarks on page 350
•
Configuring Hosted Java Applet Resource Profile Bookmarks on page 352
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 16
Citrix Templates
•
About Citrix Templates on page 361
•
Comparing Secure Access Access Mechanisms for Configuring Citrix on page 362
•
Creating Resource Profiles Using Citrix Web Applications on page 365
About Citrix Templates
Secure Access supports several mechanisms for intermediating traffic between a Citrix
server and client, including the Juniper Networks Citrix Terminal Services proxy, JSAM,
WSAM, Network Connect, and the hosted Java applets feature.
The Citrix Web template enables you to easily configure access to a Citrix server using
the Juniper Networks Citrix Terminal Services proxy, JSAM, or WSAM. The Citrix Web
template is a resource profile that controls access to Citrix applications and configures
Citrix settings as necessary. Citrix Web templates significantly reduce your configuration
time by consolidating configuration settings into one place and by prepopulating a variety
of resource policy settings for you depending on the type of Citrix setup you select. You
should use the Citrix Web template if you have the Citrix Web Interface already installed
in your environment or if you are using a Web server to host your ICA files.
Because of their highly simplified configurations, templates are the ideal Citrix
configuration method if you want to deliver ActiveX or Java applets from a third-party
Web server through Secure Access.
Citrix Web templates simplify your configuration by automatically detecting whether the
Citrix Web client or the Citrix Java applet is being used and employing the appropriate
Secure Access access mechanism accordingly. For instance, if you have configured the
Citrix Web Interface to deliver a Java client, Secure Access automatically uses its Java
rewriting engine to tunnel traffic. If you have configured the Citrix Web Interface to deliver
an ActiveX client, Secure Access uses its Citrix Terminal Services feature, JSAM, or WSAM
(depending on the option you select) to tunnel traffic.
We strongly recommend using Citrix templates instead of the traditional role and resource
policy configuration options available through Secure Access.
Copyright © 2011, Juniper Networks, Inc.
361
Secure Access Administration Guide
NOTE: Juniper Networks does not support saving a Citrix application shortcut
to the desktop through Secure Access when the loopback IP address is running
on the client. Double-clicking this shortcut returns an error as it does not use
WSAM or JSAM.
Related
Documentation
•
About Hosted Java Applet Templates on page 347
•
Creating WSAM Client Application Resource Profiles on page 481
•
Creating a JSAM Application Resource Profile on page 521
•
Creating Resource Profiles Using Citrix Web Applications on page 365
Comparing Secure Access Access Mechanisms for Configuring Citrix
Secure Access supports several mechanisms for intermediating traffic between a Citrix
server and client, including the Citrix Terminal Services proxy, JSAM, WSAM, Network
Connect, and the hosted Java applets feature.
The following table describes key differences when accessing a Citrix Metaframe Server
thought a Citrix Web Interface server. The descriptions in this table focus on configuring
Citrix Terminal Services, JSAM, and WSAM through Web resource profile templates
(Select Users > Resource Profiles > Web, click New Profile and select Citrix Web
interface/JICA from the Type list.)
NOTE: If you want to configure access to a Citrix Metaframe server though
a Citrix Web Interface server, you must use Web resource profile templates.
If you want to configure access to a Citrix Metaframe server without using a
Citrix Web Interface server, you must use a standard Citrix Terminal Services
or WSAM resource profile or role.
362
Copyright © 2011, Juniper Networks, Inc.
Chapter 16: Citrix Templates
Table 20: Accessing the Citrix Web Interface Server using Web Resource Profile Templates
Requirement
Terminal Services
JSAM
WSAM
User
experience
1.
1.
1.
The user clicks a Citrix Web
Interface bookmark in the Web
Bookmarks section of the Secure
Access end user console.
2. The user is taken to the Citrix Web
Interface (WI) sign-in page
(assuming you do not configure
FORM POST SSO).
3. Once the user signs into the WI
portal (either manually or
automatically through SSO), he is
taken to the Citrix WI portal page,
which contains the list of published
applications in icon form.
4. When the user clicks the published
application, the Juniper Networks
Citrix Terminal Services (CTS)
proxy launches and the ICA traffic
is tunneled through the Juniper
Networks CTS proxy.
The user launches JSAM.
The user launches WSAM.
2. The user clicks a Citrix Web
Interface bookmark in the
Web Bookmarks section of the
Secure Access end user
console.
2. The user clicks a Citrix Web
Interface bookmark in the
Web Bookmarks section of
the Secure Access end user
console.
3. The user is taken to the Citrix
Web Interface (WI) sign-in
page (assuming you do not
configure FORM POST SSO).
3. The user is taken to the
Citrix Web Interface (WI)
sign-in page (assuming you
do not configure FORM
POST SSO).
4. Once the user signs into the
WI portal (either manually or
automatically through SSO),
he is taken to the Citrix WI
portal page, which contains
the list of published
applications in icon form.
5. When the user clicks the
published application, the ICA
traffic is tunneled through
JSAM.
4. Once the user signs into the
WI portal (either manually
or automatically through
SSO), he is taken to the
Citrix WI portal page, which
contains the list of published
applications in icon form.
5. When the user clicks the
published application, the
ICA traffic is tunneled
through WSAM.
Accessing
published
applications
from Mac or
Linux
Not supported on Mac and Linux.
Supported on Mac and Linux.
Not supported on Mac and
Linux.
Configuring
ports
Secure Access automatically monitors
all traffic on port 1494 if session
reliability is turned off on the server.
Secure Access monitors port 2598 if
session reliability is turned on. You do
not need to specify which ports to
monitor or which applications to
intermediate.
You must specify which ports
Secure Access monitors. This
enables you to access published
applications that use ports other
than 1494.
You do not need to specify
which ports to monitor or which
applications to intermediate.
WSAM works in app mode and
monitors all traffic coming from
certain Citrix executables.
Administrator
privileges
If a Citrix Web client is not installed on
the user’s desktop, administrator
privileges are required.
If a Citrix Web client is not
installed on the user’s desktop,
administrator privileges are
required.
Requires administrator
privileges to install WSAM.
Modifying host
file
This is a limitation of the installation of
the Citrix client. To install and run the
Juniper Networks Citrix Terminal
Services proxy client, administrator
privileges are not required.
This is a limitation of the
installation of the Citrix client. To
run JSAM, administrator privileges
are not required.
Does not require modification of the
etc/hosts file.
Does not require modification of
the etc/hosts file.
Copyright © 2011, Juniper Networks, Inc.
Does not require modification
of the etc/hosts file.
363
Secure Access Administration Guide
The following table describes key differences when accessing a Citrix Metaframe Server
without using a Citrix Web Interface server. The descriptions in this table focus on
configuring Citrix Terminal Services, JSAM, and WSAM through standard resource profiles
(Select Users > Resource Profiles > SAM or Terminal Services.)
Requirement
Terminal Services
JSAM
WSAM
User
experience
The user launches the published
application by clicking the
bookmark or icon in the Terminal
Services section of the Secure
Access end user console.
1.
1.
2. The user launches the published
application using standard
methods such as the Windows
Start menu or a desktop icon.
2. The user launches the
published application using
standard methods such as
the Windows Start menu or
a desktop icon.
Accessing
published
applications
from Mac or
Linux
Macintosh and Linux users cannot
access published applications from
a Citrix Metaframe server.
Macintosh and Linux users can
access published applications from
a Citrix Metaframe server.
Macintosh and Linux users
cannot access published
applications from a Citrix
Metaframe server.
Admin
configuration
You can specify which ports Secure
Access intermediates. Or, if you do
not configure this information,
Secure Access automatically
monitors ports 1494 and 2598.
You cannot configure Citrix as a
standard application. Instead, you
need to create a custom JSAM
application, provide the server names
of all Metaframe servers, and specify
which ports Secure Access monitors.
This enables you to use applications
such as Citrix Secure Gateways
(CSGs) and published applications
that use ports other than 1494.
You must specify which ports
and applications Secure Access
monitors. This enables you to
use applications such as Citrix
Secure Gateways (CSGs) and
published applications that use
ports other than 1494.
Administrator
privileges
If a Citrix Web client is not installed
on the user’s desktop, administrator
privileges are required.
Requires administrator privileges to
run JSAM because etc/hosts file
modifications are required.
Requires administrator privileges
to install WSAM.
Requires modification of the
etc/hosts file.
Does not require modification of
the etc/hosts file.
JSAM auto-launches when the
user signs into Secure Access or
the user launches JSAM
manually.
WSAM auto-launches when
the user signs into Secure
Access or the user launches
WSAM manually.
This is a limitation of the
installation of the Citrix client. To
install and run the Juniper Networks
Citrix Terminal Services proxy
client, administrator privileges are
not required.
Modifying host
file
Does not require modification of
the etc/hosts file.
Related
Documentation
364
•
About Citrix Templates on page 361
•
Creating Resource Profiles Using Citrix Web Applications on page 365
Copyright © 2011, Juniper Networks, Inc.
Chapter 16: Citrix Templates
Creating Resource Profiles Using Citrix Web Applications
The Citrix Web template enables you to easily configure Citrix access using the Juniper
Networks Citrix Terminal Services proxy, JSAM, or WSAM.
To create a resource profile using the Citrix template:
1.
Select Users > Resource Profiles > Web in the admin console.
2. Click New Profile.
3. Select Citrix Web Interface/JICA from the Type list.
4. Enter a unique name and optionally a description for the Citrix resource profile.
5. Enter the URL of the Web server that hosts your ICA files in the Web Interface (NFuse)
URL field. Use the format: [protocol://]host[:port][/path]. For instance, enter the
URL of an NFuse server, the Web interface for a Citrix Metaframe Presentation Server,
or a Web server from which Secure Access can download Citrix Java applets or Citrix
cab files. (Secure Access uses the specified URL to define the default bookmark for
the Citrix resource profile.) You may enter a directory URL or a file URL.
6. Specify which type of Citrix implementation you are using in your environment by
selecting one of the following options:
•
Java ICA Client with Web Interface (NFuse)—Select this option if you have deployed
the Citrix Web Interface for MPS (that is, NFuse) to deliver Java ICA clients.
•
Java ICA Client without Web Interface (NFuse)—Select this option if you have
deployed a generic Web server to deliver Java ICA clients.
•
Non-Java ICA Client with Web Interface (NFuse)—Select this option if you have
deployed the Citrix Web Interface for MPS (that is, NFuse) to use any of the different
clients (Java, ActiveX, local).
•
Non-Java ICA Client without Web Interface (NFuse)—(Read only) If you have
deployed a non-Java ICA client without the Citrix Web Interface for MPS (that is,
NFuse), you cannot create a Citrix resource profile through this template. Instead,
click the client application profile link beneath this option. The link brings you to the
Client Application Profiles page, where you can create a SAM resource profile.
7. From the Web Interface (NFuse) version list, select which Citrix version you are using.
(Secure Access uses this value to pre-populate the Forms POST SSO values in your
single sign-on autopolicy.
8. Specify the Metaframe Servers to which you want to control access in the MetaFrame
servers area. Then click Add. When specifying servers, you can enter wildcards or IP
ranges.
Secure Access uses the values that you enter to automatically create a corresponding
resource policy that enables access to the necessary resources:
•
If you select either Java ICA Client with or without Web Interface, Secure Access
creates a corresponding Java ACL resource policy that enables Java applets to
connect to the specified Metaframe servers.
Copyright © 2011, Juniper Networks, Inc.
365
Secure Access Administration Guide
•
If you select Non-Java ICA Client with Web Interface, and then you select ICA client
connects over WSAM or JSAM, Secure Access creates a corresponding SAM
resource policy that enables users to access the specified Metaframe servers.
•
If you select Non-Java ICA Client with Web Interface, and then you select ICA client
connects over CTS, Secure Access creates corresponding Terminal Services and
Java resource policies that enable users to access the specified Metaframe servers.
9. (Java ICA clients only.) If you deployed Citrix using a Java ICA Client, select the Sign
applets with uploaded code-signing certificate(s) check box to re-sign the specified
resources using the certificate uploaded through the System > Configuration >
Certificates > Code-signing Certificates page of the admin console.
When you select this option, Secure Access uses all of the “allow” values that you
enter in the resource profile’s Web access control autopolicy to automatically create
a corresponding code-signing resource policy. Within this policy, Secure Access uses
the specified Web resources to create a list of trusted servers.
10. (Non-Java ICA clients only) If you have deployed Citrix using a non-Java ICA Client
with a Web interface, you must use the Juniper Networks Citrix Terminal Services
proxy, Secure Application Manager, or Network Connect to secure traffic to your
Metaframe servers instead of the Content Intermediation Engine.
To secure traffic through the Juniper Citrix Terminal Services proxy or the Secure
Application Manager, select one of the following options in the ICA Client Access
section:
•
ICA client connects over CTS Client—Select this option to secure your Citrix traffic
through the Secure Access Citrix Terminal Services client (if your users are using
Active X clients) or Java rewriting engine (if your users are using Java clients). (When
you select this option, Secure Access automatically enables the Terminal Services
option on the Users > User Roles > Select_Role > General > Overview page of the
admin console.)
NOTE: If you are using a third-party Web server such as your company’s
Intranet server to deliver the ICA file, make sure the Content-Type of
the HTTP Response header is application/x-ica. Only then does Secure
Access automatically intermediate the ICA file and launch its Citrix
Terminal Services client to tunnel the traffic.
NOTE: If you select this option, we recommend that you disable Citrix
client downloads through the Citrix Web Interface. Otherwise, users
could inadvertently start two different windows downloading two
versions of the Citrix client simultaneously–one through Secure Access
(which automatically attempts to download the Citrix client if one is
not present on the user’s computer) and one through the Citrix Web
Interface.
366
Copyright © 2011, Juniper Networks, Inc.
Chapter 16: Citrix Templates
•
ICA client connects over WSAM—Select this option to secure traffic using WSAM.
(When you select this option, Secure Access automatically enables the Secure
Application Manager option on the Users > User Roles > Select_Role > General >
Overview page of the admin console.)
•
ICA client connects over JSAM—Select this option to secure traffic using JSAM.
Then, configure the following options:
•
Number of Servers/Applications—Enter the lesser of the following two numbers:
maximum number of Citrix servers in your environment or the maximum number
of published applications that a user can open simultaneously. For instance, if
your environment contains one server and five published applications, enter 1 in
this field. Or, if your environment contains 20 servers and 10 published applications,
enter 10 in this field. The maximum value this field accepts is 99.
•
Citrix Ports—Specify the ports on which the Metaframe servers listen.
When you select the ICA client connects over JSAM option, Secure Access
automatically enables the Secure Application Manager option on the Users >
User Roles > Select_Role > General > Overview page of the admin console.
NOTE: You cannot enable WSAM and JSAM for the same role. Therefore,
if you try to create a Citrix resource profile that uses one of these access
mechanisms (for instance, JSAM) and another profile associated with
role already uses the other access mechanism (for instance, WSAM),
Secure Access does not enable the new access mechanism (JSAM) for
the role. Also note that you can only use WSAM or JSAM to configure
access to one Citrix application per user role.
11. (Non-Java ICA Client with Web Interface only.) If you want to allow users to access
local resources such as printers and drives through their Citrix Web Interface sessions,
select the Configure access to local resources check box. Then, select from the
following options:
•
Select Connect printers if you want to enable the user to print information from
the terminal server to his local printer.
•
Select Connect drives if you want to enable the user to copy information from the
terminal server to his local client directories.
•
Select Connect COM Ports if you want to enable communication between the
terminal server and devices on the user’s serial ports.
Copyright © 2011, Juniper Networks, Inc.
367
Secure Access Administration Guide
NOTE: To control access to local resources exclusively through your
Citrix Metaframe server settings, clear the Configure access to local
resources check box. When you clear the option, the Metaframe server
settings take effect. Or, if you want to selectively override Citrix
Metaframe server settings for the bookmark, select the Configure access
to local resources check box and then specify the local resources to
which you want to enable or disable access. Note that if you enable
access to a local resource through Secure Access, however, you still
must enable access to it through the Metaframe server as well.
When you enable local resources through the terminal server, each user
can only access his own local resources. For instance, user 1 cannot see
user 2’s local directories.
12. Select the Autopolicy: Web Access Control check box to create a policy that allows
or denies users access to the resource specified in the Web Interface (NFuse) URL
field. (By default, Secure Access automatically creates a policy for you that enables
access to the resource and all of its subdirectories.)
13. If you selected one of the Web interface options above, update the SSO policy created
by the Citrix template. Select the Autopolicy: Single Sign-on check box. (Single
sign-on autopolicies configure Secure Access to automatically pass Secure Access
data such as usernames and passwords to the Citrix application. Secure Access
automatically adds the most commonly used values to the single sign-on autopolicy
based on the Citrix implementation you choose.)
When you select single sign-on, the WIClientInfo and WINGSession cookies are
prepopulated automatically in addition to the POST Resource and URL.
Or, if you selected the non-Web interface option, you may optionally create your own
single sign-on autopolicy.
14. Click Save and Continue.
15. Select the roles in the Roles tab to which the Citrix resource profile applies and click
Add.
The selected roles inherit the autopolicies and bookmarks created by the Citrix resource
profile. If it is not already enabled, Secure Access also automatically enables the Web
option in the Users > User Roles > Select_Role > General > Overview page of the admin
console and the Allow Java Applets option in the Users > User Roles > Select_Role >
Web > Options page of the admin console for all of the roles you select.
16. Click Save Changes.
17. (Optional.) In the Bookmarks tab, modify the default bookmark created by Secure
Access and/or create new ones.
By default, Secure Access creates a bookmark to the Web interface (NFuse) URL
defined in the Web Interface (NFuse) URL field and displays it to all users assigned
to the role specified in the Roles tab.
368
Copyright © 2011, Juniper Networks, Inc.
Chapter 16: Citrix Templates
Related
Documentation
•
About Citrix Templates on page 361
•
Creating WSAM Client Application Resource Profiles on page 481
•
Creating a JSAM Application Resource Profile on page 521
Copyright © 2011, Juniper Networks, Inc.
369
Secure Access Administration Guide
370
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 17
Lotus iNotes Templates
•
Creating Resource Profiles Using the Lotus iNotes Template on page 371
Creating Resource Profiles Using the Lotus iNotes Template
A Lotus iNotes template is a resource profile that controls access to the Web application
and configures iNotes settings as necessary. Lotus iNotes templates significantly reduce
your configuration time by consolidating settings into one place and by prepopulating a
variety of resource policy settings for you depending on the type of setup you select.
Secure Access supports intermediating traffic to Lotus iNotes through a Web rewriting
resource profile template, JSAM, WSAM, and Network Connect. This topic describes how
to configure access using the Web rewriting template. The prepopulated values vary
depending on the version of iNotes you select and are based on the most common
deployment of the servers.
To create a resource profile using the Lotus iNotes template:
1.
Select Users > Resource Profiles > Web in the admin console.
2. Click New Profile.
3. Select the Lotus Notes version from the Type list.
4. Enter a unique name and optionally a description for the Lotus Notes resource profile.
5. Enter the URL of the Lotus iNotes resource to which you want to control access in the
Base URL box. Use the format: [protocol://]host[:port][/path]. Secure Access uses
the specified URL to define the default bookmark for the Lotus iNotes resource profile.
You may enter a directory URL or a file URL.
6. Under iNotes setting, select Allow caching on client to let Web browsers store non-user
data, such as Javascript and CSS files, on a user’s machine. Select Minimize caching
on client to allow Secure Access to send a cache-control:no-store header or a
cache-control:no-cache header based on the user’s Web browser and content type.
This is the same as smart caching.
The Allow caching on client option caches content that the backend iNotes server
typically caches. This caching option improves performance by using the cached
content instead of retrieving the content from the server the next time the page
displays. The Minimize caching on client option provides security by sending a
cache-control:no-store header or a cache-control:no-cache header to either not store
Copyright © 2011, Juniper Networks, Inc.
371
Secure Access Administration Guide
content or to re-validate the cached content each time it is requested. With both
caching option, you can choose to either allow or prevent the uploading or downloading
of attachments.
7. Select the Prevent download of attachments check box to prohibit users from
downloading attachments to their systems. Select the Prevent upload of attachments
check box (available only for Lotus iNotes 6.5 and Lotus iNotes 7) to prevent users
from transmitting (uploading) attachments to Secure Access.
8. Select the Autopolicy: Web Access Control check box to create a policy that allows
or denies users access to the Web resource (and all of its subdirectories) listed in the
Resource field.
a. In the Resource box, specify the Web server or HTML page to which you want to
control access using the format: [protocol://]host[:port][/path].
b. From the Action list, select Allow to enable access to the specified resource or
Deny to block access to the specified resource.
c. Click Add.
9. Select the Autopolicy: Caching check box to specify the resources to which this policy
applies in the Resource box.
NOTE: The correct caching resource policy must be configured to allow
end users to open and save e-mail attachments of different document
types in iNotes. For example, if the caching policy is set to Smart, end users
cannot save .htm or .html attachments to disk.
10. Select the Autopolicy: Web Compression check box to create a policy that specify
which types of Web data Secure Access should and should not compress.
a. In the Resources field, specify the resources to which this policy applies.
b. Select one of the following options from the Action list:
•
Compress—Secure Access compresses the supported content types from the
specified resource.
•
Do not compress—Secure Access does not compress the supported content
types from the specified resource.
c. Click Add.
11. Select the Autopolicy: Single Sign-On check box to pass Secure Access data such
as the username and password to the Lotus iNotes application.
12. Click Save and Continue.
13. Select the roles to which the Lotus iNotes resource profile applies in the Roles tab
and click Add.
The selected roles inherit the autopolicies and bookmarks created by the Lotus iNotes
resource profile. If it is not already enabled, Secure Access also automatically enables
372
Copyright © 2011, Juniper Networks, Inc.
Chapter 17: Lotus iNotes Templates
the Web option in the Users > User Roles > Select Role > General > Overview page of
the admin console.
14. Click Save Changes.
15. (Optional.) In the Bookmarks tab, modify the default bookmark created by Secure
Access and/or create new ones
Related
Documentation
•
About Hosted Java Applet Templates on page 347
•
Creating WSAM Client Application Resource Profiles on page 481
•
Creating a JSAM Application Resource Profile on page 521
•
Creating Resource Profiles Using Citrix Web Applications on page 365
Copyright © 2011, Juniper Networks, Inc.
373
Secure Access Administration Guide
374
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 18
Microsoft OWA Templates
•
Creating Resource Profiles Using the Microsoft OWA Template on page 375
Creating Resource Profiles Using the Microsoft OWA Template
A Microsoft Outlook Web Access (OWA) template is a resource profile that controls
access to the application and configures OWA settings as necessary. OWA templates
significantly reduce your configuration time by consolidating configuration settings into
one place and by prepopulating a variety of resource policy settings for you depending
on the type of setup you select.
Secure Access supports intermediating traffic to Microsoft OWA through a Web rewriting
resource profile template, JSAM, WSAM, and Network Connect. This topic describes how
to configure access using the Web rewriting template. The prepopulated values vary
depending on the version of OWA you select and are based on the most common
deployment of the servers.
To create a resource profile using the Microsoft OWA template:
1.
Select Users > Resource Profiles > Web Applications/Pages in the admin console.
2. Click New Profile.
3. Select Microsoft OWA 2000, Microsoft OWA 2003 or Microsoft OWA 2007 from
the Type list.
4. Enter a unique name and optionally a description for the Citrix resource profile.
5. Enter the URL of the OWA resource to which you want to control access In the Base
URL box. Use the format: [protocol://]host[:port][/path]. Secure Access uses the
specified URL to define the default bookmark for the OWA resource profile. You may
enter a directory URL or a file URL.
Copyright © 2011, Juniper Networks, Inc.
375
Secure Access Administration Guide
6. Under OWA settings select the following options,
a. (OWA 2000 and OWA 2003.) Select Allow caching on client to let Web browsers
store non-user data, such as Javascript and CSS files, on a user’s machine.
The Allow caching on client option caches content the backend OWA server
typically caches. This caching option improves performance by using the cached
content instead of retrieving the content from the server the next time the page
displays.
b. (OWA 2000 and OWA 2003.) Select Minimize caching on client to allow Secure
Access to send a cache-control:no-store header or a cache-control:no-cache
header (do not store content or revalidate the cached content each time it is
requested) based on the user’s Web browser and content type. This is the same
as smart caching.
c. (OWA 2007.) Select Managed Device to cache files. If you configure a Form post
SSO, the trusted parameter is set to 4. This indicates the end user’s device is private.
d. (OWA 2007.) Select Unmanaged Device to not cache files. If you configure a Form
post SSO, the trusted parameter is set to 0. This indicates the end user’s device is
public.
NOTE: If it is necessary to download an attachment, the file is cached
even though you select Unmanaged Device.
e. Select Prevent download of attachments to prohibit users from downloading
attachments to their systems.
f.
Select Prevent upload of attachments to prevent users from transmitting
(uploading) attachments to Secure Access.
7. Under Autopolicy: Web Access Control, create a policy that allows or denies users
access to the Web resource (and all of its subdirectories) listed in the Resource field.
a. Specify the Web server or HTML page to which you want to control access in the
Resource field. Use the format: [protocol://]host[:port][/path].
b. Select Allow to enable access to the specified resource or Deny to block access
to the specified resource from the Action list.
c. Click Add.
8. Under Autopolicy: Caching, specify the resources to which this policy applies in the
Resource box.
NOTE: The correct caching resource policy must be configured to allow
end users to open and save e-mail attachments of different document
types in OWA. For example, if the caching policy is set to Smart, end users
cannot save .htm or .html attachments to disk.
376
Copyright © 2011, Juniper Networks, Inc.
Chapter 18: Microsoft OWA Templates
9. Under Autopolicy: Web Compression, create a policy that specifies which types of
Web data Secure Access should and should not compress.
a. Specify the resources to which this policy applies in the Resources box.
b. Select one of the following options from the Action list:
•
Compress—Secure Access compresses the supported content types from the
specified resource.
•
Do not compress—Secure Access does not compress the supported content
types from the specified resource.
c. Click Add.
10. Select the Autopolicy: Single Sign-On check box to pass Secure Access data such
as the username and password to the OWA application.
11. Click Save and Continue.
12. Select the roles to which the resource profile applies in the Roles tab and click Add.
The selected roles inherit the autopolicies and bookmarks created by the Microsoft
OWA resource profile. If it is not already enabled, Secure Access also automatically
enables the Web option in the Users > User Roles > Select _Role > General > Overview
page of the admin console.
13. Click Save Changes.
14. (Optional.) Modify the default bookmark created by Secure Access in the Bookmarks
tab, and/or create new ones.
Related
Documentation
•
About Hosted Java Applet Templates on page 347
•
Creating WSAM Client Application Resource Profiles on page 481
•
Creating a JSAM Application Resource Profile on page 521
•
Creating Resource Profiles Using Citrix Web Applications on page 365
Copyright © 2011, Juniper Networks, Inc.
377
Secure Access Administration Guide
378
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 19
Microsoft Sharepoint Templates
•
Creating Resource Profiles Using the Microsoft Sharepoint Template on page 379
Creating Resource Profiles Using the Microsoft Sharepoint Template
A Microsoft Sharepoint template is a resource profile that controls access to the
application and configures Sharepoint settings as necessary. Microsoft Sharepoint
templates significantly reduce your configuration time by consolidating configuration
settings into one place and by pre-populating a variety of resource policy settings for you
depending on the type of setup you select.
Secure Access supports intermediating traffic to Microsoft Sharepoint through a Web
rewriting resource profile template, JSAM, WSAM, and Network Connect. This topic
describes how to configure access using the Web rewriting template.
NOTE: In the current release, we support sending contact information from
Sharepoint to your Outlook client through the Content Intermediation Engine
(Web rewriting feature). Transferring the contact information to the backend
Exchange server requires WSAM, JSAM, or Network Connect. To import
contact information into the Sharepoint server from your Outlook client, first
export your contacts and then upload them to the Sharepoint server.
To create a resource profile using the Microsoft Sharepoint template:
1.
Select Users > Resource Profiles > Web in the admin console.
2. Click New Profile.
3. Select Microsoft Sharepoint from the Type list.
4. Enter a unique name and optionally a description for the Sharepoint resource profile.
5. Enter the URL of the Sharepoint resource to which you want to control access in the
Base URL field. Use the format: [protocol://]host[:port][/path]. Secure Access uses
the specified URL to define the default bookmark for the Sharepoint resource profile.
You may enter a directory URL or a file URL.
Copyright © 2011, Juniper Networks, Inc.
379
Secure Access Administration Guide
6. Under Sharepoint Settings, select Allow in-line editing of documents within explorer
view to allow users to modify files displayed in the explorer view.
a. Enter the URL to the Explorer View page, and then click Add. Do not enter a value
that resolves to non-Explorer View URLs (such as http://*:*). Doing so might cause
Explorer View to not launch.
b. Order the resources in your list, if appropriate, by selecting the check box next to
an item and then using the up and down arrows to move it to the correct place in
the list.
c. Enter the number of minutes a persistent cookie resides on a user’s computer
before it expires in the Persistent cookie timeout box.
NOTE: Do not confuse this timeout option with Max. Session Length,
which determines the number of minutes an active nonadministrative
user session may remain open before ending.
7. Under Autopolicy: Web Access Control, create a policy that allows or denies users
access to the Web resource (and all of its subdirectories) listed in the Resource box.
a. Specify the Web server or HTML page to which you want to control access in the
Resource box. Use the format: [protocol://]host[:port][/path].
b. Select Allow to enable access to the specified resource or Deny to block access
to the specified resource from the Action list.
c. Click Add.
8. (Optional.) Click Show ALL autopolicy types to create additional autopolicies that
fine-tune access to the resource. Then, create the autopolicies.
9. Click Save and Continue.
10. Select the roles to which the resource profile applies in the Roles tab, and click Add.
The selected roles inherit the autopolicies and bookmarks created by the Microsoft
Sharepoint resource profile. If it is not already enabled, Secure Access also
automatically enables the Web option in the Users > User Roles > Select Role >
General > Overview page of the admin console.
11. Click Save Changes.
12. (Optional.) Modify the default bookmark created by Secure Access in the Bookmarks
tab or create new ones.
Related
Documentation
380
•
About Hosted Java Applet Templates on page 347
•
Creating WSAM Client Application Resource Profiles on page 481
•
Creating a JSAM Application Resource Profile on page 521
•
Creating Resource Profiles Using Citrix Web Applications on page 365
Copyright © 2011, Juniper Networks, Inc.
CHAPTER 20
Web Rewriting
•
Web Rewriting on page 382
•
Task summary: Configuring the Web Rewriting Feature on page 384
•
Web Rewriting on page 385
•
Remote SSO Overview on page 387
•
Passthrough Proxy Overview on page 388
•
Task Summary: Configuring Passthrough Proxy on page 389
•
Examples of Using Passthrough Proxy on page 390
•
Creating a Custom Web Application Resource Profile on page 391
•
Defining a Web Access Control Autopolicy on page 394
•
Defining a Single Sign-On Autopolicy on page 395
•
Defining a Caching Autopolicy on page 398
•
Defining a Java Access Control Autopolicy on page 400
•
Defining a Rewriting Autopolicy on page 401
•
Defining a Web Compression Autopolicy on page 405
•
Defining Web Resource Profile Bookmarks on page 406
•
Specifying Web Browsing Options on page 410
•
Resource Policy Overview on page 413
•
Writing a Web Access Resource Policy on page 415
•
Defining Single Sign-On Policies on page 416
•
About Basic, NTLM and Kerberos Resources on page 416
•
Writing the Basic, NTLM and Kerberos Resources on page 418
•
Writing a Basic Authentication, NTLM or Kerberos Intermediation Resource
Policy on page 421
•
Writing a Remote SSO Form POST Resource Policy on page 424
•
Writing a Remote SSO Headers/Cookies Resource Policy on page 426
•
Writing a Web Caching Resource Policy on page 428
•
About OWA and Lotus Notes Caching Resource Policies on page 430
•
Specifying General Caching Options on page 431
Copyright © 2011, Juniper Networks, Inc.
381
Secure Access Administration Guide
•
Writing a Java Access Control Resource Policy on page 432
•
Writing a Java Code Signing Resource Policy on page 433
•
Creating a Selective Rewriting Resource Policy on page 434
•
Creating a Passthrough Proxy Resource Policy on page 437
•
Creating a Custom Header Resource Policy on page 439
•
Creating an ActiveX Parameter Resource Policy on page 440
•
Restoring the Default SA Series Appliance ActiveX Resource Policies on page 442
•
Writing a Web Compression Resource Policy on page 447
•
Defining an OWA Compression Resource Policy on page 448
•
Writing a Web Proxy Resource Policy on page 448
•
Specifying Web Proxy Servers on page 449
•
Writing An HTTP 1.1 Protocol Resource Policy on page 450
•
Creating a Cross Domain Access Policy on page 451
•
Defining Resource Policies: General Options on page 453
•
Managing Resource Policies: Customizing UI Views on page 453
Web Rewriting
The SA Series Appliance Web rewriting feature enables you to intermediate Web URLs
through the Content Intermediation Engine. You can intermediate URLs on the World
Wide Web or on your corporate Intranet.
When you intermediate standard Web content through the SA Series Appliance, you can
create supplemental policies that “fine-tune” the access requirements and processing
instructions for the intermediated content. You can create these supplemental policies
through resource profiles (recommended) or resource policies.
Standard Web rewriting policy types include:
382
•
Web access control—Web access policies control which Web resources users can
access in order to connect to the Internet, intranet, or extranet.
•
Single sign-on—Single sign-on policies enable you to automatically pass user credentials
to a Web application. You can configure single sign-on policies to intercept basic
authentication and NTLM challenges or post the credentials and headers that you
specify to the Web application.
•
Caching—Caching policies control which Web content the SA Series Appliance caches
on a user’s machine.
•
Java—Java policies control to which servers and ports Java applets can connect. These
policies also specify trusted servers for which the SA Series Appliance resigns content.
•
Rewriting—Rewriting policies specify resources that the SA Series Appliance should
not intermediate, minimally intermediation, or only intermediate selectively.
•
Web compression—Web compression policies specify which types of Web data the
SA Series Appliance should and should not compress.
Copyright © 2011, Juniper Networks, Inc.
Chapter 20: Web Rewriting
•
Web proxy—(Resource policies only) Web proxy resource policies specify Web proxy
servers for which the SA Series Appliance should intermediate content. Note that the
SA Series Appliance intermediates both forward and backwards proxies, but only
enables single sign-on to trusted proxies.
•
Launch JSAM—(Resource policies only) Launch JSAM policies specify URLs for which
the SA Series Appliance automatically launches J-SAM on the client. This feature is
useful if you enable applications that require J-SAM but do not want to require users
to run J-SAM unnecessarily.
•
Protocol—(Resource policies only) Protocol resource policies enable or disable HTTP
1.1 protocol support on the SA Series Appliance. .
•
Options— (Resource policies only) You can enable IP based matching for hostnames
as well as case-sensitive matching for path and query strings in Web resources through
resource policy options.
Web rewriting is a standard feature on all Secure Access appliances except the SA700
Series Appliance. If you are using an SA700 Series Appliance, you must install a Core
Clientless Access upgrade license in order to access baseline Web rewriting features.
Note, however, that the following advanced Web rewriting features are not available on
the SA700 Series Appliance, even if you have the Core Clientless Access upgrade license:
Related
Documentation
•
Remote SSO
•
WSAM & JSAM rewriting policies (available through Web application resource profiles)
•
Non-Java ICA rewriting options (available through Citrix templates)
•
Task summary: Configuring the Web Rewriting Feature on page 384
•
Writing a Web Access Resource Policy on page 415
•
Defining a Single Sign-On Autopolicy on page 395
•
Defining a Caching Autopolicy on page 398
•
Writing a Java Access Control Resource Policy on page 432
•
Defining a Rewriting Autopolicy on page 401
•
Defining a Web Compression Autopolicy on page 405
•
Writing a Web Proxy Resource Policy on page 448
•
Automatically Launching JSAM on page 528
•
Writing An HTTP 1.1 Protocol Resource Policy on page 450
•
Defining Resource Policies: General Options on page 453
Copyright © 2011, Juniper Networks, Inc.
383
Secure Access Administration Guide
Task summary: Configuring the Web Rewriting Feature
NOTE: When intermediating content through the content intermediation
engine, we recommend that the GMT time on both the SA Series Appliance
and the backend web application server be the same. This prevents any
premature expiration of cookies if the SA Series Appliance time is later than
the web application server time.
To configure the Web rewriting feature:
1.
Create resource profiles that enable access to Web sites, create supporting autopolicies
(such as single sign-on and Java access control policies) as necessary, include
bookmarks that link to the Web sites, and assign the policies and bookmarks to user
roles using settings in the Web Applications Resource Profiles page (Users > Resource
Profiles > Web) of the admin console.
We recommend that you use resource profiles to configure Web rewriting (as described
above). However, if you do not want to use resource profiles, you can configure Web
rewriting using role and resource policy settings in the following pages of the admin
console instead:
a. Create resource policies that enable access to Web sites using settings in the Users
> Resource Policies> Web > Web ACL page of the admin console.
b. As necessary, create supporting resource policies (such as single sign-on and Java
access control policies) using settings in the Users > Resource Policies> Select
Policy Type pages of the admin console.
c. Determine which user roles may access the Web sites that you want to intermediate,
and then enable Web access for those roles through the Users > User Roles >
Select Role > General > Overview page of the admin console.
d. Create bookmarks to your Web sites using settings in the Users > User Roles >
Select Role > Web > Bookmarks page of the admin console.
e. As necessary, enable Web general options that correspond to the types of Web
content you are intermediating (such as Java) using settings in the Users > User
Roles > Select Role > Web > Options page of the admin console.
2. After enabling access to Web applications or sites using Web rewriting resource profiles
or roles and resource policies, you can modify general role and resource options in the
following pages of the admin console:
a. (Optional) Set additional Web browsing options (such as allowing users to create
their own bookmarks or enabling hostname masking) Users > User Roles > Select
Role > Web > Options page of the admin console.
384
Copyright © 2011, Juniper Networks, Inc.
Chapter 20: Web Rewriting
NOTE: Even if you enable hostname masking, links corresponding to
protocols not rewritten by the SA Series Appliance are not obfuscated.
For example, ftp://xyz.juniper.net and
file://fileshare.juniper.net/filename are not obfuscated. By not
obfuscating the hostname, users can still access these resources.
b. (Optional) Set additional Web options for individual resources (such as enabling
the SA Series Appliance to match IP addresses to host names) using settings in
the Users > Resource Policies> Web > Options page of the admin console.
NOTE: Certain Web rewriting features (such as passthrough proxy and
SSO to NTLM resources) require additional configuration. For more
information, see the appropriate configuration instructions.
Related
Documentation
•
Writing a Web Access Resource Policy on page 415
•
Defining a Single Sign-On Autopolicy on page 395
•
Defining a Caching Autopolicy on page 398
•
Writing a Java Access Control Resource Policy on page 432
•
Defining a Rewriting Autopolicy on page 401
•
Defining a Web Compression Autopolicy on page 405
•
Writing a Web Proxy Resource Policy on page 448
•
Automatically Launching JSAM on page 528
•
Writing An HTTP 1.1 Protocol Resource Policy on page 450
•
Defining Resource Policies: General Options on page 453
Web Rewriting
The SA Series Appliance Web rewriting feature enables you to intermediate Web URLs
through the Content Intermediation Engine. You can intermediate URLs on the World
Wide Web or on your corporate Intranet.
When you intermediate standard Web content through the SA Series Appliance, you can
create supplemental policies that “fine-tune” the access requirements and processing
instructions for the intermediated content. You can create these supplemental policies
through resource profiles (recommended) or resource policies.
Copyright © 2011, Juniper Networks, Inc.
385
Secure Access Administration Guide
Standard Web rewriting policy types include:
•
Web access control—Web access policies control which Web resources users can
access in order to connect to the Internet, intranet, or extranet.
•
Single sign-on—Single sign-on policies enable you to automatically pass user credentials
to a Web application. You can configure single sign-on policies to intercept basic
authentication and NTLM challenges or post the credentials and headers that you
specify to the Web application.
•
Caching—Caching policies control which Web content the SA Series Appliance caches
on a user’s machine.
•
Java—Java policies control to which servers and ports Java applets can connect. These
policies also specify trusted servers for which the SA Series Appliance resigns content.
•
Rewriting—Rewriting policies specify resources that the SA Series Appliance should
not intermediate, minimally intermediation, or only intermediate selectively.
•
Web compression—Web compression policies specify which types of Web data the
SA Series Appliance should and should not compress.
•
Web proxy—(Resource policies only) Web proxy resource policies specify Web proxy
servers for which the SA Series Appliance should intermediate content. Note that the
SA Series Appliance intermediates both forward and backwards proxies, but only
enables single sign-on to trusted proxies.
•
Launch JSAM—(Resource policies only) Launch JSAM policies specify URLs for which
the SA Series Appliance automatically launches J-SAM on the client. This feature is
useful if you enable applications that require J-SAM but do not want to require users
to run J-SAM unnecessarily.
•
Protocol—(Resource policies only) Protocol resource policies enable or disable HTTP
1.1 protocol support on the SA Series Appliance. .
•
Options— (Resource policies only) You can enable IP based matching for hostnames
as well as case-sensitive matching for path and query strings in Web resources through
resource policy options.
Web rewriting is a standard feature on all Secure Access appliances except the SA700
Series Appliance. If you are using an SA700 Series Appliance, you must install a Core
Clientless Access upgrade license in order to access baseline Web rewriting features.
Note, however, that the following advanced Web rewriting features are not available on
the SA700 Series Appliance, even if you have the Core Clientless Access upgrade license:
Related
Documentation
386
•
Remote SSO
•
WSAM & JSAM rewriting policies (available through Web application resource profiles)
•
Non-Java ICA rewriting options (available through Citrix templates)
•
Task summary: Configuring the Web Rewriting Feature on page 384
•
Writing a Web Access Resource Policy on page 415
•
Defining a Single Sign-On Autopolicy on page 395
Copyright © 2011, Juniper Networks, Inc.
Chapter 20: Web Rewriting
•
Defining a Caching Autopolicy on page 398
•
Writing a Java Access Control Resource Policy on page 432
•
Defining a Rewriting Autopolicy on page 401
•
Defining a Web Compression Autopolicy on page 405
•
Writing a Web Proxy Resource Policy on page 448
•
Automatically Launching JSAM on page 528
•
Writing An HTTP 1.1 Protocol Resource Policy on page 450
•
Defining Resource Policies: General Options on page 453
Remote SSO Overview
The Remote Single Sign-On (SSO) feature enables you to specify the URL sign-in page
of an application to which you want the SA Series Appliance to post a user’s credentials,
minimizing the need for users to re-enter their credentials when accessing multiple
back-end applications. You may also specify additional forms values and custom headers
(including cookies) to post to an application’s sign-in form.
Remote SSO configuration consists of specifying Web resource policies:
•
Form POST policy—This type of Remote SSO policy specifies the sign-in page URL of
an application to which you want to post SA Series Appliance data and the data to
post. This data can include the user’s primary or secondary SA Series Appliance
username and password as well as system data stored by system variables. You can
also specify whether or not users can modify this information.
•
Headers/Cookies policy—This type of Remote SSO policy specifies resources, such as
customized applications, to which you can send custom headers and cookies.
If a user’s SA Series credentials differ from those required by the back-end application,
the user can alternatively access the application:
•
By signing in manually—The user can quickly access the back-end application by
entering his credentials manually into the application’s sign-in page. The user may also
permanently store his credentials and other required information in the SA Series
Appliance through the Preferences page as described below, but is not required to
enter information in this page.
•
Specifying the required credentials on the SA Series Appliance—The user must provide
the SA Series Appliance with his correct application credentials by setting them through
the Preferences page. Once set, the user must sign out and sign back in to save his
credentials on the SA Series Appliance. Then, the next time the user clicks the Remote
SSO bookmark to sign in to the application, the SA Series Appliance sends the updated
credentials.
Copyright © 2011, Juniper Networks, Inc.
387
Secure Access Administration Guide
NOTE: Use the Remote SSO feature to pass data to applications with
static POST actions in their HTML forms. It is not practical to use Remote
SSO with applications that employ frequently changing URL POST actions,
time-based expirations, or POST actions that are generated at the time
the form is generated.
Related
Documentation
•
System Variables and Examples on page 1010
•
Multiple Sign-In Credentials Execution on page 241
•
Writing a Remote SSO Form POST Resource Policy on page 424
•
Writing a Remote SSO Headers/Cookies Resource Policy on page 426
Passthrough Proxy Overview
The passthrough proxy feature enables you to specify Web applications for which the
SA Series Appliance performs minimal intermediation. Unlike traditional reverse proxy
functionality, which also rewrites only selective parts of a server response but requires
network changes as well as complex configuration, this feature only requires that you
specify application servers and the way in which the SA Series Appliance receives client
requests to those application servers:
•
Via an SA Series Appliance port—When specifying an application for the passthrough
proxy to intermediate, you specify a port on which the SA Series Appliance listens for
client requests to the application server. When the SA Series Appliance receives a
client request for the application server, it forwards the request to the specified
application server port. When you choose this option, you must open traffic to the
specified SA Series Appliance port on your corporate firewall.
•
Via virtual host name—When specifying an application for the passthrough proxy to
intermediate, you specify an alias for the application server host name. You need to
add an entry for this alias in your external DNS server that resolves to the SA Series
Appliance. When the SA Series Appliance receives a client request for the alias, it
forwards the request to the port you specify for the application server.
This option is useful if your company has restrictive policies about opening firewall
ports to either internal servers or servers in the DMZ. When using this option, we
recommend that each host name alias contains the same domain substring as your
SA Series Appliance host name and that you upload a wild card server certificate to
the SA Series Appliance in the format: *.domain.com.
For example, if your SA Series Appliance is iveserver.yourcompany.com, then a host
name alias should be in the format appserver.yourcompany.com and the wild card
certificate format would be *.yourcompany.com. If you do not use a wild card certificate,
then a client’s browser issues a certificate name check warning when a user browses
to an application server, because the application server host name alias does not match
the certificate domain name. This behavior does not prevent a user from accessing
the application server, however.
388
Copyright © 2011, Juniper Networks, Inc.
Chapter 20: Web Rewriting
NOTE: When you configure passthrough proxy to work in virtual host name
mode, users must use the SA Series Appliance host name that you specify
through the System > Network > Overview page of the admin console when
signing into the SA Series Appliance. They cannot access use passthrough
proxy if they sign into the SA Series Appliance using its IP address.
Just as with the Content Intermediation Engine, the passthrough proxy option offers
increased security relative to the Secure Application Manager, because when enabled
for an application, the SA Series Appliance allows the client to send only layer-7 traffic
directed to fixed application ports to the enterprise network. Use this option to enable
the SA Series Appliance to support applications with components that are incompatible
with the Content Intermediation Engine, such as Java applets in Oracle e-business suite
applications or applets that run in an unsupported Java Virtual Machine (JVM).
Note the following:
Related
Documentation
•
Passthrough proxy URLs must be host names. Paths of host names are not supported.
•
Juniper Networks strongly recommends that you not mix passthrough proxy Port mode
and passthrough proxy Host mode.
•
The passthrough proxy option works only for applications that listen on fixed ports
and where the client does not make direct socket connections.
•
To use passthrough proxy with Oracle E-Business applications, you must install a real
certificate on the SA Series Appliance and you must configure Oracle Forms to use the
Forms Listener Servlet mode.
•
The following advanced features of the SA Series Appliance framed toolbar are not
available in passthrough proxy: bookmark current page, display the original URL, display
the favorite bookmarks.
•
Task Summary: Configuring Passthrough Proxy on page 389
•
Examples of Using Passthrough Proxy on page 390
•
Creating a Passthrough Proxy Resource Policy on page 437
Task Summary: Configuring Passthrough Proxy
To configure the Web rewriting feature:
1.
Create resource profiles that enable access to Web applications, create supporting
Web rewriting autopolicies that enable passthrough proxy, include bookmarks that
Copyright © 2011, Juniper Networks, Inc.
389
Secure Access Administration Guide
link to the Web applications, and assign the policies and bookmarks to user roles using
settings in the Users > Resource Profiles> Web page of the admin console.
Alternatively, you can:
a. Create resource policies that enable access to Web applications using settings in
the Users > Resource Policies> Web > Web ACL page of the admin console.
b. Create supporting Web rewriting resource policies that enable passthrough proxy
using settings in the Users > Resource Policies> Web > Web ACL page of the admin
console.
c. Determine which user roles may access the Web applications that you want to
intermediate with passthrough proxy, and then enable Web access for those roles
through the Users > User Roles > Select Role > General > Overview page of the
admin console.
d. Create bookmarks to your Web sites using settings in the Users > User Roles >
Select Role > Web > Bookmarks page of the admin console.
2. If your passthrough proxy resource policy enables the SA Series Appliance to receive
client requests through an SA Series Appliance port, open traffic to the specified port
in your corporate firewall. Or, if your policy enables requests through a virtual host
name:
a. Add an entry for each application server host name alias in your external DNS that
resolves to the SA Series Appliance.
b. Define the SA Series Appliance name and host name through the System > Network
> Internal Port page of the admin console.
c. Upload a wildcard certificate to the SA Series Appliance through the System >
Configuration > Certificates > Device Certificates page of the admin console. Or,
upload multiple certificates and associate a virtual port with each certificate using
settings in the same page.
Related
Documentation
•
Passthrough Proxy Overview on page 388
•
Examples of Using Passthrough Proxy on page 390
•
Creating a Passthrough Proxy Resource Policy on page 437
•
Resource Policies on page 127
•
General Network Settings on page 674
Examples of Using Passthrough Proxy
If your SA Series Appliance is iveserver.yourcompany.com and you have an Oracle server
at oracle.companynetwork.net:8000, you could specify the following application
parameters when specifying an SA Series Appliance port:
Server: oracle.companynetwork.net
390
Copyright © 2011, Juniper Networks, Inc.
Chapter 20: Web Rewriting
Port: 8000
SA Series Appliance port: 11000
When the SA Series Appliance receives Oracle client traffic sent to
iveserver.yourcompany.com:11000, it forwards the traffic to
oracle.companynetwork.net:8000.
Or, if you want to specify a host name alias, you could configure the application with
these parameters:
Server: oracle.companynetwork.net
Port: 8000
SA Series Appliance: oracle.yourcompany.com
When the SA Series Appliance receives Oracle client traffic sent to
oracle.yourcompany.com, it forwards the traffic to oracle.companynetwork.net:8000
Related
Documentation
•
Task Summary: Configuring Passthrough Proxy on page 389
•
Passthrough Proxy Overview on page 388
Creating a Custom Web Application Resource Profile
A custom Web application resource profile is a resource profile that controls access to
a Web application, Web server, or HTML page.
To create a custom Web application resource profile:
1.
In the admin console, select Users > Resource Profiles > Web.
2. Click New Profile.
3. From the Type list, choose Custom.
4. Enter a unique name and optionally a description for the resource profile.
5. In the Base URL field, enter the URL of the Web application or page for which you
want to control access using the format: [protocol://]host[:port][/path]. (The SA
Series Appliance uses the specified URL to define the default bookmark for the resource
profile.)
6. In the Autopolicy: Web Access Control section, create a policy that allows or denies
users access to the resource specified in the Base URL field. (By default, the SA Series
Appliance automatically creates a policy for you that enables access to the Web
resource and all of its sub-directories.)
7. (Optional) Click Show ALL autopolicy types to create additional autopolicies that
fine-tune access to the resource. Then, create the autopolicies using instructions in
the following sections:
8. Click Save and Continue.
9. In the Roles tab, select the roles to which the resource profile applies and click Add.
Copyright © 2011, Juniper Networks, Inc.
391
Secure Access Administration Guide
The selected roles inherit the autopolicies and bookmarks created by the resource
profile. If it is not already enabled, the SA Series Appliance also automatically enables
the Web option in the Users > User Roles > Select Role > General > Overview page
of the admin console for all of the roles you select.
10. Click Save Changes.
11. (Optional) In the Bookmarks tab, modify the default bookmark created by the SA
Series Appliance and/or create new ones. (By default, the SA Series Appliance creates
a bookmark to the base URL defined in the Base URL field and displays it to all users
assigned to the role specified in the Roles tab.)
Defining Base URLs
When creating a Web resource profile, you must use the following format when defining
base URLs:
[protocol://]host[:port][/path]
Within this format, the components are:
•
Protocol (required)—Possible values: http:// and https://. Note that you cannot use
special characters within the protocol.
•
Host (required)—Possible values:
•
DNS Hostname—For example: www.juniper.com
•
IP address—You must enter the IP address in the format: a.b.c.d. For example:
10.11.149.2. You cannot use special characters in the IP address.
•
Ports (optional)—You must use the delimiter “:” when specifying a port. For example:
10.11.149.2/255.255.255.0:*
•
Path (optional)—When specifying a path for a base URL, the SA Series Appliance does
not allow special characters. If you specify a path, you must use the “/” delimiter. For
example, http://www.juniper.net/sales.
Defining Web Resources
When creating a Web resource profile, you must use the following format when defining
resources for autopolicies:
[protocol://]host[:ports][/path]
Within this format, the four components are:
•
Protocol (required)—Possible values: http:// and https://. Note that you cannot use
special characters within the protocol.
•
Host (required)—Possible values:
•
DNS Hostname—For example: www.juniper.com
You may use the following special characters allowed in the hostname:
392
Copyright © 2011, Juniper Networks, Inc.
Chapter 20: Web Rewriting
Table 21: DNS hostname special characters
*
Matches ALL characters.
%
Matches any character except dot (.)
?
Matches exactly one character
•
IP address/Netmask—You must enter the IP address in the format: a.b.c.d
You may use one of two formats for the netmask:
•
Prefix: High order bits
•
IP: a.b.c.d
For example: 10.11.149.2/24 or 10.11.149.2/255.255.255.0
You cannot use special characters in the IP address or netmask.
•
Ports (optional)—You must use the delimiter “:” when specifying a port. For example:
10.11.149.2/255.255.255.0:*
Table 22: Port possible values
*
Matches ALL ports; you cannot use any other special characters
port[,port]*
A comma-delimited list of single ports. Valid port numbers are [1-65535].
[port1]-[port2]
A range of ports, from port1 to port2, inclusive.
NOTE: You can mix port lists and port ranges, such as: 80,443,8080-8090
If the port is missing, then the default port 80 is assigned for http, 443 for https.
•
Related
Documentation
Path (optional)—When specifying a path for a Web access control autopolicy, you
may use a * character, meaning ALL paths match. (The SA Series Appliance does not
support any other special characters.) If you specify a path, you must use the “/”
delimiter. For example:
•
http://www.juniper.net/sales
•
http://www.juniper.net:80/*
•
https://www.juniper.net:443/intranet/*
•
Resource Profiles on page 109
•
About Hosted Java Applet Templates on page 347
•
About Citrix Templates on page 361
•
Creating Resource Profiles Using the Lotus iNotes Template on page 371
Copyright © 2011, Juniper Networks, Inc.
393
Secure Access Administration Guide
•
Creating Resource Profiles Using the Microsoft OWA Template on page 375
•
Creating Resource Profiles Using the Microsoft Sharepoint Template on page 379
•
Defining a Web Access Control Autopolicy on page 394
•
Defining a Single Sign-On Autopolicy on page 395
•
Defining a Rewriting Autopolicy on page 401
•
Defining a Web Compression Autopolicy on page 405
•
Defining a Java Access Control Autopolicy on page 400
•
Defining a Caching Autopolicy on page 398
Defining a Web Access Control Autopolicy
Web access policies control which Web resources users can access in order to connect
to the Internet, intranet, or extranet. When defining a custom Web resource profile, you
must enable a corresponding Web access control autopolicy that enables access to the
profile’s primary resource. The SA Series Appliance simplifies the process for you by
automatically creating an autopolicy that allows access to the Web resource and all of
its sub-directories.
If necessary, you may choose to modify this default autopolicy or create supplementary
Web access control autopolicies that control access to additional resources. For instance,
your IT department may use one server to store Web pages for your company intranet
(http://intranetserver.com) and another server to store the images that the Web pages
reference (http://imagesserver.com). In this case, you can create two Web access control
autopolicies that enable access to both servers so that your users can access both your
Web pages and the corresponding images.
To create a new Web access control autopolicy:
1.
Create a custom Web application resource profile.
2. If available, click the Show ALL autopolicy types button to display the autopolicy
configuration options.
3. If it is not already enabled, select the Autopolicy: Web Access Control checkbox.
4. In the Resource field, specify the Web server or HTML page to which you want to
control access using the format: [protocol://]host[:ports][/path].
5. From the Action list, choose Allow to enable access to the specified resource or Deny
to block access to the specified resource.
6. Click Add.
7. Click Save Changes.
Related
Documentation
394
•
Creating a Custom Web Application Resource Profile on page 391
•
Configuring General Role Options on page 93
Copyright © 2011, Juniper Networks, Inc.
Chapter 20: Web Rewriting
Defining a Single Sign-On Autopolicy
Single sign-on policies enable you to automatically pass user credentials to the Web
application specified in your policy. Single sign-on autopolicies also intermediate the
data that you pass.
To create a single sign-on (SSO) autopolicy:
1.
Create a Web resource profile.
2. If available, click the Show ALL autopolicy types button to display the autopolicy
configuration options.
3. Select the Autopolicy: Single Sign-On checkbox.
4. Select a single sign-on method and configure the corresponding SSO options:
NOTE: SSO options require you to select credentials. If you have not
already done so, define the credentials using the Resource Policies > Web
> General page prior to defining your SSO autopolicy.
•
Disable SSO—Disables single sign-on.
•
Basic Auth—Enables the SA Series Appliance to intermediate the
challenge/response sequence during basic authentication and use the credentials
it collects to sign into a protected resource within the same Intranet zone. This
option does not apply to Citrix resource profiles.
•
NTLM—Enables the SA Series Appliance to intermediate the challenge/response
sequence during NTLM authentication and use the credentials it collects to sign
into a protected resource within the same Intranet zone. This option does not apply
to Citrix resource profiles.
NOTE: Web rewriting and file browsing both support NTLM v1 and NTLM
v2.
•
Kerberos—Enables the SA Series Appliance to intermediate the challenge/response
sequence during Kerberos authentication and use the credentials it collects to sign
into a protected resource within the same Intranet zone.
•
Constrained Delegation—Enables authentication of users by Kerberos after their
identity has been verified using a non-Kerberos authentication method. For example,
suppose a user authenticates with RADIUS and enters their passcode (typically PIN
and tokencode). When accessing a service, the user may be challenged again
because the PIN is not recognized. With constrained delegation, the administrator
sets up passwords for constrained delegation users. The users do not need to know
Copyright © 2011, Juniper Networks, Inc.
395
Secure Access Administration Guide
this password. When accessing the same HTTP service, the SA Series Appliance
now fetches the ticket on behalf of the user without challenging the user.
•
Remote SSO—Enables the SA Series Appliance to post the data that you specify
(including SA Series Appliance usernames, passwords, and system data stored by
variables) to Web applications. This option also enables you specify custom headers
and cookies to post to Web applications.
5. Click Save Changes.
Specifying Basic Authentication, NTLM or Kerberos SSO Autopolicy Options
To configure basic authentication, NTLM or Kerberos SSO autopolicy options:
1.
Create an SSO autopolicy and choose Basic Auth, NTLM or Kerberos.
2. In the Resource field, specify the resources to which this policy applies.
When entering a resource in this field, note that:
•
If you want the SA Series Appliance to automatically post values to a specific URL
when an end-user clicks on an SA Series bookmark, the resource that you enter
here must exactly match the URL that you specify in the Base URL field of the
resource profile.
•
If you want the SA Series Appliance to automatically submit SA Series user
credentials to other Web sites within the same Intranet zone, the host name that
you enter here must end in the DNS suffix configured in the System > Network >
Overview page of the admin console.
3. Select the credentials to use. If this pull-down menu is blank, no credentials are defined
in the SSO General tab.
4. (NTLM only) Select the Fallback to NTLM V1 option to fallback to NTLM V1 if NTLM
V2 fails. If you do not select this option, the SA Series Appliance falls back only to
NTLM V2. An intermediation page appears if SSO fails.
5. (Kerberos only) Select the Fallback to NTLM V2 only option to fallback only to NTLM
V2 if kerberos fails. If you do not select this option, a Kerberos intermediation page
appears if Kerberos SSO fails.
6. (Constrained delegation only) Select the Fallback to Kerberos option fallback to
Kerberos if constrained delegation fails. If you do not select this option, an error page
appears if SSO fails.
Specifying Remote SSO Autopolicy Options
396
Copyright © 2011, Juniper Networks, Inc.
Chapter 20: Web Rewriting
To configure remote SSO autopolicy options:
1.
Create an SSO autopolicy through a custom Web resource profile and choose Remote
SSO.
2. If you want to perform a form POST when a user makes a request to the resource
specified in the Resource field, select the POST the following data checkbox. Then:
a. In the Resource field, specify the application’s sign-in page, such as:
http://my.domain.com/public/login.cgi. The SA Series Appliance does not accept
wildcard characters in this field.
If you want the SA Series Appliance to automatically post values to a specific URL
when an end-user clicks on an SA Series bookmark, the resource that you enter
here must exactly match the URL that you specify in the Base URL or Web Interface
(NFuse) URL field of the resource profile.
b. In the Post URL field, specify the absolute URL where the application posts the
user’s credentials, such as: http://yourcompany.com/login.cgi. You can determine
the appropriate URL using a TCP dump or by viewing the application’s sign-in page
source and searching for the POST parameter in the FORM tag.
c. Optionally specify the user data you want to post and user modification permissions.
To specify user data to post, enter data in the following fields and click Add:
•
Name—The name to identify the data of the Value field. (The back-end
application should expect this name.)
•
Value—The value to post to the form for the specified Name. You can enter static
data, a system variable, or SA Series Appliance session variables containing
username and password values.
•
User modifiable? setting—Set to Not modifiable if you do not want the user to
be able to change the information in the Value field. Set to User CAN change
value if you want the user to have the option of specifying data for a back-end
application. Set to User MUST change value if users must enter additional data
in order to access a back-end application. If you