Configuring Host Checker

Configuring Host Checker
Junos Pulse Secure Access Service
Administration Guide
Release
7.3
Published: 2013-08-26
Part Number: , Revision 1
Copyright © 2013, 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.
Junos Pulse Secure Access Service Administration Guide
Revision History
June 2012—Beta
The information in this document is current as of the date on the title page.
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 © 2013, Juniper Networks, Inc.
Abbreviated Table of Contents
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvii
Part 1
Getting Started
Chapter 1
Initial Verification and Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Chapter 2
Introduction to Secure Access Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Part 2
Access Management Framework
Chapter 3
General Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Chapter 4
User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Chapter 5
Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Chapter 6
Virtual Desktop Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Chapter 7
Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Chapter 8
Authentication and Directory Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Chapter 9
SAML Single Sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Chapter 10
Authentication Realms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Chapter 11
Sign-In Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Chapter 12
Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Chapter 13
Synchronizing User Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Part 3
Endpoint Defense
Chapter 14
Host Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Chapter 15
Cache Cleaner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Part 4
Remote Access
Chapter 16
Hosted Java Applets Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Chapter 17
Citrix Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Chapter 18
Lotus iNotes Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Chapter 19
Microsoft OWA Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Chapter 20
Microsoft Sharepoint Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Chapter 21
Web Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Chapter 22
File Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Chapter 23
Secure Application Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
Chapter 24
Telnet/SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
Copyright © 2013, Juniper Networks, Inc.
iii
Junos Pulse Secure Access Service Administration Guide
Chapter 25
Terminal Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
Chapter 26
Junos Pulse Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Chapter 27
Email Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
Chapter 28
VPN Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Part 5
System Management
Chapter 29
General System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Chapter 30
Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
Chapter 31
System Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Chapter 32
Logging and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
Chapter 33
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
Chapter 34
Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
Chapter 35
Delegating Administrator Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
Chapter 36
Instant Virtual System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965
Chapter 37
IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019
Chapter 38
Secure Access Service and IDP Interoperability . . . . . . . . . . . . . . . . . . . . . 1039
Chapter 39
Routing AAA Over the Management Port for Virtual Appliances . . . . . . 1049
Part 6
System Services
Chapter 40
Secure Access Service Serial Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055
Chapter 41
Customizable Admin and End-User UIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
Chapter 42
SA6000 Series Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
Chapter 43
SA4500 and SA6500 Series Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
Chapter 44
Secure Access FIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077
Chapter 45
SA4500 and SA6500 FIPS Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089
Chapter 46
Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099
Chapter 47
Multi-Language Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1103
Chapter 48
Handheld Devices and PDAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107
Chapter 49
Using IKEv2 with the Secure Access Service . . . . . . . . . . . . . . . . . . . . . . . . . 1115
Chapter 50
Writing Custom Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1123
Part 7
Index
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1149
iv
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvii
Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvii
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvii
Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvii
Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxviii
Obtaining Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxviii
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxviii
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxviii
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . xxxix
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxix
Part 1
Getting Started
Chapter 1
Initial Verification and Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Verifying User Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Creating a Test Scenario to Learn Secure Access Service 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 Secure Access Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Secure Access Service Solution Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Securing Traffic with Secure Access Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authenticating Users with Existing Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Fine-Tuning Access to Secure Access Service and the Resources It
Intermediates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Creating a Seamless Integration Between Secure Access Service and the
Resources It Intermediates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Protecting Against Infected Computers and Other Security Concerns . . . . . . . . . . 21
Ensuring Redundancy in the Secure Access Service Environment . . . . . . . . . . . . . 22
Making the Secure Access Service Interface Match My Company’s
Look-and-Feel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Enabling Users on a Variety of Computers and Devices to Use Secure Access
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Providing Secure Access for My International Users . . . . . . . . . . . . . . . . . . . . . . . . 24
Configuring Secure Access Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Copyright © 2013, Juniper Networks, Inc.
v
Junos Pulse Secure Access Service Administration Guide
Network and Security Manager and the Secure Access Service . . . . . . . . . . . . . . 25
How Secure Access Service and NSM communicate . . . . . . . . . . . . . . . . . . . 25
Available Services and Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . 27
DMI Communication with the Secure Access Service . . . . . . . . . . . . . . . . . . . 27
Configuring Secure Access for the Initial DMI Connection . . . . . . . . . . . . . . . . . . . 28
Managing Large Binary Data Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
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
Secure Access Service Gateway Deployment Options . . . . . . . . . . . . . . . . . . 39
Platform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Junos Pulse Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Configuring a Role for Junos Pulse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Client Connection Set Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Connection is Established Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Creating a Client Connection Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Configuring Connection Rules for Location Awareness . . . . . . . . . . . . . . . . . . . . . 49
Junos Pulse Component Set Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Creating a Client Component Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Junos Pulse Client Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Installing the Junos Pulse Client from the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Installing the Junos Pulse Client Using a Preconfiguration File . . . . . . . . . . . . . . . 55
Installing the Pulse Client Using Advanced Command Line Options . . . . . . . 56
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Repairing a Pulse Installation on a Windows Endpoint . . . . . . . . . . . . . . . . . . 58
Part 2
Access Management Framework
Chapter 3
General Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Access Management Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Policies, Rules & Restrictions, and Conditions Overview . . . . . . . . . . . . . . . . . . . . 62
Accessing Authentication Realms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Accessing User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
vi
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Accessing Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Policies, Rules & Restrictions, and Conditions Evaluation . . . . . . . . . . . . . . . . . . . 64
Dynamic Policy Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Understanding Dynamic Policy Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Understanding Standard Policy Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Enabling Dynamic Policy Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Specifying Source IP Access Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
About Source IP Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Specifying Source IP Restrictions at the Realm Level . . . . . . . . . . . . . . . . . . . 70
Specifying Source IP Restrictions at the Role Level . . . . . . . . . . . . . . . . . . . . . 70
Specifying Source IP Restrictions in Resource Policies . . . . . . . . . . . . . . . . . . . 71
Specifying Browser Access Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Specifying Certificate Access Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Specifying Password Access Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Specifying Session Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
IF-MAP Federation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
IF-MAP Federation Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
IF-MAP Federation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
IF-MAP Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Task Summary: Configuring IF-MAP Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Configuring IF-MAP Server Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Configuring the IF-MAP Federation Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
IF-MAP Federation Network Timing Considerations . . . . . . . . . . . . . . . . . . . . . . . 85
Session-Export and Session-Import Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Default Session-Export and Session-Import Policy Action . . . . . . . . . . . . . . 88
Advanced Session-Export and Session-Import Policies . . . . . . . . . . . . . . . . . 88
Configuring Session-Export Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Session-Import Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Troubleshooting the IF-MAP Federation Network . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Viewing Active Users on the IF-MAP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Trusted Server List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Administrator and User Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
White List Flow Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Chapter 4
User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
User Roles Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
User Role Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Permissive Merge Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Configuration of User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Configuring General Role Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Role Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Specifying Role-Based Source IP Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Specifying Role Session Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Customizing the Secure Access Service Welcome Page . . . . . . . . . . . . . . . . . . . 105
Secure Access Service Optimized Interface for the Apple iPad . . . . . . . . . . . . . . . 110
Defining Default Options for User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Customizing Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Customizing UI Views for User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Copyright © 2013, Juniper Networks, Inc.
vii
Junos Pulse Secure Access Service Administration Guide
Chapter 5
Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Resource Profile Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Defining Resource Profile Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Defining Resource Profile Autopolicies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Defining Resource Profile Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Defining Resource Profile Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Resource Profile Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Chapter 6
Virtual Desktop Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Virtual Desktop Resource Profile Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Configuring a Citrix XenDesktop Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . 128
Configuring a VMware View Manager Resource Profile . . . . . . . . . . . . . . . . . . . . 129
Defining Bookmarks for a Virtual Desktop Profile . . . . . . . . . . . . . . . . . . . . . . . . . 130
Configuring the Client Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Connecting to the Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Chapter 7
Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Resource Policy Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Specifying Resources for a Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
General Notes About the Canonical Formats . . . . . . . . . . . . . . . . . . . . . . . . . 135
Specifying Server Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Resource Policy Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Creating Detailed Rules for Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Writing a Detailed Rule for Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Customizing Resource Policy UI Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Chapter 8
Authentication and Directory Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
About Authentication and Directory Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Task Summary: Configuring Authentication Servers . . . . . . . . . . . . . . . . . . . . . . . 145
About Anonymous Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Anonymous Server Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Defining an Anonymous Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Using an RSA ACE/Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Defining an ACE/Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Using an RSA ACE/Server with a Secure Access Service Cluster . . . . . . . . . . . . . 151
Using Active Directory or NT Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Defining an Active Directory or Windows NT Domain Server Instance . . . . . . . . . 154
Configuring a Role-Mapping Rule Based on the Active Directory LDAP Primary
Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Multi-Domain User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Windows 2000 and Windows 2003 Multi-Domain Authentication . . . . . . . 159
Windows NT4 Multi-Domain Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 159
NT User Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Join Domain for Active Directory-based Authentication Server Without Using a
Domain Admin Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Using the Kerberos Debugging Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
viii
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Active Directory and NT Group Lookup Support . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Active Directory Lookup Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
NT4 Group Lookup Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Certificate Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Configuring a Certificate Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Using an LDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Defining an LDAP Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Configuring LDAP Search Attributes for Meeting Creators . . . . . . . . . . . . . . . . . . 168
Enabling LDAP Password Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Enabling LDAP Password Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Supported LDAP Directories and Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Microsoft Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Sun iPlanet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Supported LDAP Password Management Functions . . . . . . . . . . . . . . . . 171
AD/NT Password Management Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Troubleshooting LDAP Password Management on the Secure Access
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Using a Local Authentication Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Defining a Local Authentication Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Creating User Accounts on a Local Authentication Server . . . . . . . . . . . . . . . . . . 176
Configuring an NIS Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Configuring a RADIUS Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
User Experience for RADIUS Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Using CASQUE Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Defining a Secure Access Service RADIUS Server Instance . . . . . . . . . . . . . . . . . 180
Enabling RADIUS Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
General RADIUS Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Understanding Clustering Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Understanding the Interim Update Feature . . . . . . . . . . . . . . . . . . . . . . . . . . 195
eTrust SiteMinder Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Authentication Using Various Authentication Schemes . . . . . . . . . . . . . . . . 198
Determining the Username . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Configuring SiteMinder to Work with the Secure Access Service . . . . . . . . . . . . . 199
Configuring the SiteMinder Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Creating a SiteMinder Authentication Scheme for the Secure Access Service . . 201
Creating a SiteMinder Domain for the Secure Access Service . . . . . . . . . . . . . . . 203
Creating a SiteMinder Realm for the Secure Access Service . . . . . . . . . . . . . . . . 203
Creating a Rule/Response Pair to Pass Usernames to the Secure Access
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Configuring Secure Access to Work with SiteMinder . . . . . . . . . . . . . . . . . . . . . . 205
Using SiteMinder User Attributes for Secure Access Role Mapping . . . . . . . . . . . 215
Defining a SiteMinder Realm for Automatic Sign-In . . . . . . . . . . . . . . . . . . . . . . . 215
Debugging SiteMinder and Secure Access Issues . . . . . . . . . . . . . . . . . . . . . . . . . 216
Defining a SAML Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Copyright © 2013, Juniper Networks, Inc.
ix
Junos Pulse Secure Access Service Administration Guide
Chapter 9
SAML Single Sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Junos Pulse Secure Access Service SAML 2.0 SSO Solutions . . . . . . . . . . . . . . . . 221
Understanding SAML 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
About SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
SAML Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Secure Access Service SAML 2.0 Supported Features Reference . . . . . . . . . 222
Supported SAML SSO Deployment Modes . . . . . . . . . . . . . . . . . . . . . . 222
Supported SAML SSO Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
FIPS Support Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Secure Access Service SAML 2.0 Configuration Tasks . . . . . . . . . . . . . . . . . . . . . 230
Configuring System-Wide SAML Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Configuring Global SAML Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Managing SAML Metadata Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Configuring Secure Access Service as a SAML 2.0 Service Provider . . . . . . . 233
Configuring Secure Access Service as a SAML 2.0 Identity Provider . . . . . . . 237
Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Configuring Sign-in SAML Metadata Provider Settings . . . . . . . . . . . . . 238
Configuring Sign-in SAML Identity Provider Settings . . . . . . . . . . . . . . . 238
Configuring Peer SAML Service Provider Settings . . . . . . . . . . . . . . . . . 240
Configuring a SAML SSO Resource Policy for Gateway Mode
Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Configuring a SAML SSO External Applications Policy . . . . . . . . . . . . . 246
Configuring a SAML 2.0 ACL Web Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Example: Implementing SAML 2.0 Web Browser SSO for Google Apps . . . . . . . 249
Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Configuring the Google Apps SAML service provider . . . . . . . . . . . . . . . . . . . 251
Configuring the Secure Access Service SAML Identity Provider . . . . . . . . . . 253
Verifying the Google Apps SAML SSO Deployment . . . . . . . . . . . . . . . . . . . 257
Junos Pulse Secure Access Service SAML 1.1 Support . . . . . . . . . . . . . . . . . . . . . 258
About SAML Version 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Understanding SAML 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Understanding SAML 1.1 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Understanding SAML 1.1 Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Creating a Trust Relationship Between SAML 1.1 Systems . . . . . . . . . . . 266
Secure Access Service SAML Version 1.1 Configuration Tasks . . . . . . . . . . . . 270
Creating a SAML 1.1 Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Configuring SAML 1.1 SSO Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Creating a SAML 1.1 SSO POST Profile . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Creating a SAML 1.1 ACL Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . 279
Chapter 10
Authentication Realms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Authentication Realm Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Creating an Authentication Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Defining Authentication Access Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Role Mapping Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Specifying Role Mapping Rules for an Authentication Realm . . . . . . . . . . . . . . . 287
Machine Authentication for Junos Pulse Connections . . . . . . . . . . . . . . . . . . . . . 289
Junos Pulse Connection Realm and Role Preferences for Machine
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
x
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Using the LDAP Server Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Customizing User Realm UI Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Chapter 11
Sign-In Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
About Sign-In Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Task Summary: Configuring Sign In Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
About Configuring Sign In Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Configuring User Sign In Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
About Sign-In Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Configuring and Implementing Sign-in Notifications . . . . . . . . . . . . . . . . . . . . . . 306
Defining Authorization-Only Access Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Defining Meeting Sign-In Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Configuring Sign-In pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Configuring Standard Sign-In Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Chapter 12
Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
About Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
About Multiple Sign-In Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Task Summary: Configuring Multiple Authentication Servers . . . . . . . . . . . . . . . . 315
Task Summary: Enabling SSO to Resources Protected by Basic
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Task Summary: Enabling SSO to Resources Protected by NTLM . . . . . . . . . . . . . 316
Multiple Sign-In Credentials Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Understanding SAML 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Configuring SAML 1.1 SSO Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Creating a SAML 1.1 SSO POST Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Creating a SAML 1.1 ACL Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Creating a Trust Relationship Between SAML 1.1 Systems . . . . . . . . . . . . . . . . . . 335
Configuring Trusted Application URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Configuring an Issuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Configuring Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Configuring SSO Transactions: Artifact Profile . . . . . . . . . . . . . . . . . . . . 336
Configuring SSO Transactions: POST Profile . . . . . . . . . . . . . . . . . . . . . 337
Configuring Access Control Transactions . . . . . . . . . . . . . . . . . . . . . . . . 338
Configuring User Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Chapter 13
Synchronizing User Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
About User Record Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Enabling User Record Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Configuring the User Record Synchronization Authentication Server . . . . . . . . . 344
Configuring the User Record Synchronization Server . . . . . . . . . . . . . . . . . . . . . . 345
Configuring the User Record Synchronization Client . . . . . . . . . . . . . . . . . . . . . . 345
Configuring the User Record Synchronization Database . . . . . . . . . . . . . . . . . . . 346
Scheduling User Record Synchronization Backup . . . . . . . . . . . . . . . . . . . . . . . . 347
Copyright © 2013, Juniper Networks, Inc.
xi
Junos Pulse Secure Access Service Administration Guide
Part 3
Endpoint Defense
Chapter 14
Host Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Host Checker and Trusted Network Computing . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Task Summary: Configuring Host Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Creating Global Host Checker Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Enabling Enhanced Endpoint Security Functionality . . . . . . . . . . . . . . . . . . . . . . 357
Enabling Connection Control Host Checker Policies (Windows Only) . . . . . . . . 359
Creating and Configuring New Client-side Host Checker Policies . . . . . . . . . . . . 360
Checking for Third-Party Applications Using Predefined Rules (Windows
Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Configuring a Predefined Antivirus Rule with Remediation Options . . . . . . . . . . 362
Configuring a Predefined Firewall Rule with Remediation Options (Windows
Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Configuring a Predefined AntiSpyware Rule (Windows Only) . . . . . . . . . . . . . . . 365
Configuring Virus Signature Version Monitoring and Patch Assessment Data
Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Patch Management Info Monitoring and Patch Deployment . . . . . . . . . . . . . . . 368
Additional Functionality with Pulse 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Using a System Management Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Specifying Customized Requirements Using Custom Rules . . . . . . . . . . . . . . . . . 372
Using a Wildcard or Environment Variable in a Host Checker Rule . . . . . . . . . . . . 377
Configuring Patch Assessment Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Using a System Management Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Configuring Patch Assessment Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Using Third-party Integrity Measurement Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 383
Configuring a Remote IMV Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Implementing the Third-Party IMV Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Implementing Host Checker Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Executing Host Checker Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Configuring Host Checker Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Remediating Host Checker Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
General Host Checker Remediation User Experience . . . . . . . . . . . . . . . . . . 394
Configuring General Host Checker Remediation . . . . . . . . . . . . . . . . . . . . . . . . . 395
Upgrading the Endpoint Security Assessment Plug-In . . . . . . . . . . . . . . . . . . . . . 397
Defining Host Checker Pre-Authentication Access Tunnels . . . . . . . . . . . . . . . . 399
Specifying Host Checker Pre-Authentication Access Tunnel Definitions . . . . . . 400
Specifying General Host Checker Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Specifying Host Checker Installation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Client ActiveX Installation Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Using Host Checker with the GINA Automatic Sign-In Function . . . . . . . . . . . . . 406
Installing Host Checker Automatically or Manually . . . . . . . . . . . . . . . . . . . . . . . 407
Using Host Checker Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
xii
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Configuring Host Checker for Windows Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Requiring Junos Pulse Mobile Security for Secure Access Service Gateway
Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Host Checker for Apple iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Host Checker for Pulse iOS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Configuring Host Checker for Pulse iOS Clients . . . . . . . . . . . . . . . . . . . . . . . 411
Implementing Host Checker Policies for Pulse for iOS Devices . . . . . . . . . . . 413
Using Proxy Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Enabling the Secure Virtual Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Secure Virtual Workspace Restrictions and Defaults . . . . . . . . . . . . . . . . . . 416
Configuring the Secure Virtual Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Defining Secure Virtual Workspace Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Defining a Secure Virtual Workspace Application Policy . . . . . . . . . . . . . . . . . . . 419
Defining a Secure Virtual Workspace Security Policy . . . . . . . . . . . . . . . . . . . . . . 420
Defining Secure Virtual Workspace Environment Options . . . . . . . . . . . . . . . . . . 421
Defining Secure Virtual Workspace Remediation Policy . . . . . . . . . . . . . . . . . . . . 421
Chapter 15
Cache Cleaner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
About Cache Cleaner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Setting Global Cache Cleaner Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Implementing Cache Cleaner Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Specifying Cache Cleaner Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
About Cache Cleaner Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Part 4
Remote Access
Chapter 16
Hosted Java Applets Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
About Hosted Java Applet Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Task Summary: Hosting Java Applets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Uploading Java Applets to Secure Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Signing Uploaded Java Applets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Creating HTML Pages That Reference Uploaded Java Applets . . . . . . . . . . . . . . 434
Accessing Java Applet Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Creating a Hosted Java Applet Resource Profile . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Configuring Hosted Java Applet Resource Profile Bookmarks . . . . . . . . . . . . . . . 436
Creating Hosted Java Applets Bookmarks Through the User Roles Page . . . . . . 438
Required Attributes for Uploaded Java Applets . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Required Parameters for Uploaded Java Applets . . . . . . . . . . . . . . . . . . . . . . . . 440
Use case: Creating a Citrix JICA 9.5 Java Applet Bookmark . . . . . . . . . . . . . . . . . 441
Chapter 17
Citrix Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
About Citrix Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Comparing Secure Access Access Mechanisms for Configuring Citrix . . . . . . . . 446
Creating Resource Profiles Using Citrix Web Applications . . . . . . . . . . . . . . . . . . 449
Chapter 18
Lotus iNotes Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Creating Resource Profiles Using the Lotus iNotes Template . . . . . . . . . . . . . . . 455
Chapter 19
Microsoft OWA Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Creating Resource Profiles Using the Microsoft OWA Template . . . . . . . . . . . . . 459
Copyright © 2013, Juniper Networks, Inc.
xiii
Junos Pulse Secure Access Service Administration Guide
Chapter 20
Microsoft Sharepoint Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Creating Resource Profiles Using the Microsoft Sharepoint Template . . . . . . . . 463
Chapter 21
Web Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Web Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Silverlight Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Task Summary: Configuring the Web Rewriting Feature . . . . . . . . . . . . . . . . . . . 470
Remote SSO Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Passthrough Proxy Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Creating a Custom Web Application Resource Profile . . . . . . . . . . . . . . . . . . . . . 474
Defining a Web Access Control Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Defining a Single Sign-On Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Defining a Caching Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Defining a Java Access Control Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Defining a Rewriting Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Defining a Web Compression Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Defining Web Resource Profile Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Specifying Web Browsing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Resource Policy Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Writing a Web Access Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Defining Single Sign-On Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
About Basic, NTLM and Kerberos Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Writing the Basic, NTLM and Kerberos Resources . . . . . . . . . . . . . . . . . . . . . . . . 501
Writing a Basic Authentication, NTLM or Kerberos Intermediation Resource
Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Writing a Remote SSO Form POST Resource Policy . . . . . . . . . . . . . . . . . . . . . . 507
Writing a Remote SSO Headers/Cookies Resource Policy . . . . . . . . . . . . . . . . . 509
Writing a Web Caching Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
About OWA and Lotus Notes Caching Resource Policies . . . . . . . . . . . . . . . . . . . 513
Specifying General Caching Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Writing a Java Access Control Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Writing a Java Code Signing Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Creating a Selective Rewriting Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Creating a Passthrough Proxy Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
Creating a Custom Header Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Creating an ActiveX Parameter Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Restoring the Default Secure Access Service ActiveX Resource Policies . . . . . . 525
Creating Rewriting Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Writing a Web Compression Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
Defining an OWA Compression Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Writing a Web Proxy Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Specifying Web Proxy Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Writing An HTTP 1.1 Protocol Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Creating a Cross Domain Access Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
Defining Resource Policies: General Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Managing Resource Policies: Customizing UI Views . . . . . . . . . . . . . . . . . . . . . . . 536
xiv
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Chapter 22
File Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
File Rewriting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Creating a File Rewriting Resource Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Creating a File Access Control Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
Creating a File Compression Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
Creating a Single Sign-On Autopolicy (Windows Only) . . . . . . . . . . . . . . . . . . . . 543
Configuring File Resource Profile Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
Creating Windows File Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
Creating Advanced Bookmarks to Windows Resources . . . . . . . . . . . . . . . . . . . . 547
Creating Windows Bookmarks that Map to LDAP Servers . . . . . . . . . . . . . . . . . . 548
Defining General Windows File Browsing Options . . . . . . . . . . . . . . . . . . . . . . . . 548
Writing a File Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
Windows File Resources Canonical Format . . . . . . . . . . . . . . . . . . . . . . . . . 549
Writing a Windows Access Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
Writing a Windows SSO Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
Writing a Windows Compression Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . 552
Defining General File Writing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Creating UNIX File Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
Creating Advanced Bookmarks to UNIX Resources . . . . . . . . . . . . . . . . . . . . . . . 554
Defining General UNIX File Browsing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Defining UNIX/NFS File Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
Canonical Format: UNIX/NFS File Resources . . . . . . . . . . . . . . . . . . . . . . . . 556
Writing UNIX/NFS Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Writing a UNIX/NFS Compression Resource Policy . . . . . . . . . . . . . . . . . . . . . . . 558
Defining General UNIX/NFS File Writing Options . . . . . . . . . . . . . . . . . . . . . . . . . 559
Chapter 23
Secure Application Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
Secure Application Manager Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Task Summary: Configuring WSAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Launching VPN Tunneling During a WSAM Session . . . . . . . . . . . . . . . . . . . . . . . 563
Debugging WSAM Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
About WSAM Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Creating WSAM Client Application Resource Profiles . . . . . . . . . . . . . . . . . . . . . 565
Creating WSAM Destination Network Resource Profiles . . . . . . . . . . . . . . . . . . . 566
Specifying Applications and Servers for WSAM to Secure . . . . . . . . . . . . . . . . . . 567
Specifying Applications that Need to Bypass WSAM . . . . . . . . . . . . . . . . . . . . . 569
Specifying Role-Level WSAM Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Specifying Application Servers that Users Can Access . . . . . . . . . . . . . . . . . . . . . 572
Specifying Resource Level WSAM Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Using the WSAM Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
JSAM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
Task Summary: Configuring JSAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Using JSAM for Client/Server Communications . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Assigning IP Loopback Addresses to Servers . . . . . . . . . . . . . . . . . . . . . . . . . 581
Using Static Loopback Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
IP Loopback Address Considerations When Merging Roles . . . . . . . . . . . . . 583
Resolving Host Names to Localhost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Configuring a PC that Connects to the Secure Access Service Through a Proxy
Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Copyright © 2013, Juniper Networks, Inc.
xv
Junos Pulse Secure Access Service Administration Guide
Determining the Secure Access Service-Assigned Loopback Address . . . . . . . . 585
Configuring External DNS Servers and User Machines . . . . . . . . . . . . . . . . . . . . 586
JSAM Linux and Macintosh Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Standard Application Support: MS Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Client/Server Communication Using JSAM . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Standard Application Support: Lotus Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Client/Server Communication Using JSAM . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Configuring the Lotus Notes Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
Standard Application Support: Citrix Web Interface for MetaFrame (NFuse
Classic) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Enabling Citrix Published Applications on the Citrix Native Client . . . . . . . . . . . . 592
Enabling Citrix Secure Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
Creating a JSAM Application Resource Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Specifying Applications for JSAM to Secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Specifying Role Level JSAM Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Automatically Launching JSAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Specifying Application Servers that Users Can Access . . . . . . . . . . . . . . . . . . . . 605
Specifying Resource Level JSAM Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Chapter 24
Telnet/SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
About Telnet/SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
Task Summary: Configuring the Telnet/SSH Feature . . . . . . . . . . . . . . . . . . . . . . 610
Creating a Telnet/SSH Resource Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Associating Bookmarks with Telnet/SSH Resource Profiles . . . . . . . . . . . . . . . . 612
Configuring General Telnet/SSH Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Writing a Telnet/SSH Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
Chapter 25
Terminal Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
About Terminal Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Terminal Services User Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Task Summary: Configuring the Terminal Services Feature . . . . . . . . . . . . . . . . . 621
Terminal Services Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Configuring Citrix to Support ICA Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 624
About Terminal Services Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Configuring a Windows Terminal Services Resource Profile . . . . . . . . . . . . . . . . . 627
Defining a Hosted Java Applet Autopolicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Defining a Bookmark for a Windows Terminal Services Profile . . . . . . . . . . . . . . 631
Creating a Windows Terminal Services Bookmark Through the User Roles
Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
Defining Display Options for the Windows Terminal Services Session . . . . . . . . 633
Defining SSO Options for the Windows Terminal Services Session . . . . . . . . . . 634
Defining Application Settings for the Windows Terminal Services Session . . . . 634
Defining Device Connections for the Windows Terminal Services Session . . . . . 635
Defining Desktop Settings for the Windows Terminal Services Session . . . . . . . 637
Creating a Citrix Terminal Services Resource Profile Using Default ICA
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Defining a Bookmark for a Citrix Profile Using Default ICA Settings . . . . . . . . . . 638
Defining Display Options for the Citrix Terminal Services Session . . . . . . . . . . . . 641
Defining SSO Options for the Citrix Terminal Services Session . . . . . . . . . . . . . . 641
xvi
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Defining Application, Auto-Launch, and Session Reliability Settings for the Citrix
Terminal Services Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Defining Device Connections for the Citrix Terminal Services Session . . . . . . . . 643
Creating a Citrix Resource Profile That Uses a Custom ICA File . . . . . . . . . . . . . 644
Defining a Bookmark for a Citrix Profile Using a Custom ICA File . . . . . . . . . . . . 646
Creating a Citrix Profile That Lists Published Applications . . . . . . . . . . . . . . . . . . 647
Defining a Bookmark for a Citrix Profile Listing Applications . . . . . . . . . . . . . . . . 648
Creating Session Bookmarks to Your Terminal Server . . . . . . . . . . . . . . . . . . . . . 650
Creating Advanced Terminal Services Session Bookmarks . . . . . . . . . . . . . . . . . 651
Creating Links from an External Site to a Terminal Services Session
Bookmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
Specifying General Terminal Services Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
Configuring Terminal Services Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . 666
Specifying the Terminal Services Resource Option . . . . . . . . . . . . . . . . . . . . . . . 667
Using the Remote Desktop Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
Chapter 26
Junos Pulse Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Junos Pulse Collaboration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Task Summary: Configuring Junos Pulse Collaboration . . . . . . . . . . . . . . . . . . . . 671
Scheduling Meetings Through the Secure Access Service End-User Console . . . 672
Scheduling Meetings Through Microsoft Outlook . . . . . . . . . . . . . . . . . . . . . . . . 673
Sending Notification Emails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Junos Pulse Collaboration Bridge Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Junos Pulse Collaboration Bridge Profile Overview . . . . . . . . . . . . . . . . . . . . 676
Creating a Junos Pulse Collaboration Bridge Profile . . . . . . . . . . . . . . . . . . . 677
Viewing, Editing and Deleting Your Junos Pulse Collaboration Bridge
Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Viewing the Contents of the Junos Pulse Collaboration Bridge
Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Editing a Junos Pulse Collaboration Bridge Profile . . . . . . . . . . . . . . . . . 679
Deleting a Junos Pulse Collaboration Bridge Profile . . . . . . . . . . . . . . . 680
Entering the Junos Pulse Collaboration Bridge Profile Conference and PIN
IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
Joining Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Attending Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Conducting Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
Presenting Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
About Instant Meetings and Support Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . 685
About MyMeeting Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Joining MyMeeting Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Enabling and Configuring Junos Pulse Collaboration . . . . . . . . . . . . . . . . . . . . . . 687
Permissive Merge Guidelines for Junos Pulse Collaboration . . . . . . . . . . . . . . . . 691
Specifying Authentication Servers that Meeting Creators Can Access . . . . . . . . 692
Configuring System-Level Meeting Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Configuring a Junos Pulse Collaboration Meeting Server . . . . . . . . . . . . . . . . . . 696
Junos Pulse Collaboration Meeting Server Use Cases . . . . . . . . . . . . . . . . . . . . . 697
Troubleshooting Junos Pulse Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Known Issues with Junos Pulse Collaboration . . . . . . . . . . . . . . . . . . . . . . . 700
Monitoring Junos Pulse Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Copyright © 2013, Juniper Networks, Inc.
xvii
Junos Pulse Secure Access Service Administration Guide
Chapter 27
Email Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
About the E-Mail Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
Choosing an E-Mail Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Working with a Standards-Based Mail Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Working with the Microsoft Exchange Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Exchange Server and IMAP Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Exchange Server and POP Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Exchange Server and Outlook Web Access . . . . . . . . . . . . . . . . . . . . . . . . . . 707
About Lotus Notes and the Lotus Notes Mail Server . . . . . . . . . . . . . . . . . . . . . . 708
Enabling the E-Mail Client at the Role Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Writing the E-Mail Client Resource Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
Chapter 28
VPN Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
About VPN Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
VPN Tunneling on 64-Bit Linux Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
Task Summary: Configuring VPN Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
VPN Tunneling Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
Automatically Signing into VPN Tunneling using GINA . . . . . . . . . . . . . . . . . . . . . 718
Using GINA Chaining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
Credential Provider for Windows Vista and Later . . . . . . . . . . . . . . . . . . . . . . . . . 720
Smart Card Credential Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Credential Provider Authentication for Pulse Secure Access Service . . . . . . . . . . 723
Launching VPN Tunneling During a Windows Secure Application Manager
Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
Logging In To Windows Through a Secure Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 728
VPN Tunneling Connection Profiles with Support for Multiple DNS Settings . . . 729
VPN Tunneling Incompatibility with Other VPN Client Applications . . . . . . . . . . 730
Linux Client Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730
Client Side Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730
VPN Tunneling Proxy Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
VPN Tunneling Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
VPN Tunneling Multicast Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
Defining VPN Tunneling Role Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
About VPN Tunneling Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
Defining VPN Tunneling Access Control Policies . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Creating VPN Tunneling Connection Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Defining Split Tunneling Network Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
VPN Tunneling Resource Policy Configuration Use Case . . . . . . . . . . . . . . . . . . . 748
About VPN Tunneling Bandwidth Management Policies . . . . . . . . . . . . . . . . . . . 749
User is Mapped to Multiple Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752
Writing a VPN Tunneling Bandwidth Management Resource Policy . . . . . . . . . . 752
Specifying IP Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
VPN Tunneling Installer Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
VPN tunneling Installation Process Dependencies . . . . . . . . . . . . . . . . . . . . 754
VPN Tunneling Un-installation Process Dependencies . . . . . . . . . . . . . . . . . 755
Network Connect Launcher (NC Launcher) Overview . . . . . . . . . . . . . . . . . . . . . 757
Launching Network Connect On Other Platforms . . . . . . . . . . . . . . . . . . . . . . . . 759
xviii
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Troubleshooting Network Connect Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
nc.windows.app.23792 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
Version Conflict on Downgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
Error When Connecting to a FIPS Appliance . . . . . . . . . . . . . . . . . . . . . . . . . 762
Part 5
System Management
Chapter 29
General System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
General Network Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Internal and External Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
Bonding Ports on the SA 6000 SSL VPN Appliance . . . . . . . . . . . . . . . . . . . 767
Bonding Ports on the SA 6500 SSL VPN Appliance . . . . . . . . . . . . . . . . . . . 768
Configuring the Internal and External Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
Configuring the Internal Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
Configuring the External Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
Configuring SFP Ports on the SA Series 6000 SSL VPN Appliance . . . . . . . . . . . 773
Configuring the Management Port on the SA Series 6000 SSL VPN
Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
Using VLANs with Secure Access Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
Creating a New VLAN Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Using Virtual Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
About Virtual Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Creating Virtual Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
Associating a Device Certificate with a Virtual Port . . . . . . . . . . . . . . . . . . . . 779
Associating a Virtual Port with a Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
Using Virtual Ports with Client Certificate Authentication . . . . . . . . . . . . . . 780
Creating Virtual Ports for a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Configuring Static Routes for Network Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
Creating ARP Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
Specifying Host Names for Secure Access Service to Resolve Locally . . . . . . . . 783
Configuring System Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
Reviewing System Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
Upgrading or Downgrading the Secure Access Service Device . . . . . . . . . . . 786
Upgrading Virtual Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786
Setting System Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786
Downloading Application Installers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
Obtaining, Entering and Upgrading Your License Keys . . . . . . . . . . . . . . . . . . . . . 791
Configuring License Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794
Upgrading License Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795
About Subscription Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797
Available Subscription Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798
Activating and Deactivating Emergency Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 798
Setting Security Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
Setting System-Wide Security Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
Configuring Lockout Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
Configuring NCP and JCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803
Installing a Juniper Software Service Package . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
Configuring Your Management Port Network Settings From the Serial
Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805
Copyright © 2013, Juniper Networks, Inc.
xix
Junos Pulse Secure Access Service Administration Guide
Configuring Management Port Network Settings . . . . . . . . . . . . . . . . . . . . . . . . 805
Adding Static Routes to the Management Route Table . . . . . . . . . . . . . . . . . . . 808
Assigning Certificate to Management Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
Controlling Administrator Sign-In Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809
Signing in Over the Management Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
Setting Role-Mapping Rules Using Custom Expressions . . . . . . . . . . . . . . . . . . . 810
Troubleshooting the Management Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811
Using the Management Port on a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
Importing Configurations to a System with the Management Port Enabled . . . . 812
Chapter 30
Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
About Using Certificates on Secure Access Service . . . . . . . . . . . . . . . . . . . . . . . 814
Using Device Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815
Importing Certificates Into the Secure Access Service . . . . . . . . . . . . . . . . . . . . . 816
Downloading a Device Certificate From the Secure Access Service . . . . . . . . . . 818
Creating a Certificate Signing Request (CSR) for a New Certificate . . . . . . . . . . 819
Using Intermediate Server CA Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
Importing Intermediate Server CA Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
Using Multiple Secure Access Service Certificates . . . . . . . . . . . . . . . . . . . . . . . . 821
Task summary: Enabling Multiple Device Certificates . . . . . . . . . . . . . . . . . . 821
Associating a Certificate With a Virtual Port . . . . . . . . . . . . . . . . . . . . . . . . . 822
Using a Trusted Client CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
About Trusted CAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 822
Enabling Trusted Client CAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824
Automatically Importing an Intermediate Trusted Client CA Certificate . . . . . . . 825
Manually Uploading CA Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827
Specifying Attributes for the Trusted Client CA Certificate . . . . . . . . . . . . . . . . . 829
Specifying Client-side Certificate Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . 831
Enabling Client CA Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833
Enabling CRLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834
Sending CRL Download Requests to a Proxy Server . . . . . . . . . . . . . . . . . . . . . . 836
Specifying CDP Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836
Enabling OCSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838
Using Trusted Server CAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840
Uploading Trusted Server CA Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841
Renewing a Trusted Server CA Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Viewing Trusted Server CA Certificate Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
Restoring the Prepopulated Group of Trusted Server CA Certificates . . . . . . . . . 843
Using Code-signing Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843
Additional Considerations for SUN JVM Users . . . . . . . . . . . . . . . . . . . . . . . 844
Task Summary: Configuring the Secure Access Service to Sign or Re-Sign Java
Applets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
Importing a Code-Signing Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845
About Two-Way SSL Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
Task Summary: Configuring the Secure Access Service for Two-Way SSL
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847
Importing the Certificates for Two-Way SSL Handshake . . . . . . . . . . . . . . . . . . . 847
Mapping Resource Policies to the Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848
xx
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Mapping an Client Authentication Auto-Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 849
Chapter 31
System Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
About System Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Specifying Archiving Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853
Creating Local Backups of Secure Access Service Configuration Files . . . . . . . . 854
Importing and Exporting Secure Access Service Configuration Files . . . . . . . . . 856
Importing and Exporting IVS Configuration Settings . . . . . . . . . . . . . . . . . . . . . . 860
Importing and Exporting XML Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . 861
Creating and Modifying XML Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863
Integrity Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866
Mapping the XML Instance to UI Components . . . . . . . . . . . . . . . . . . . . . . . 867
Downloading the Schema File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868
Strategies for Working With XML Instances . . . . . . . . . . . . . . . . . . . . . . . . . 868
Importing and Exporting XML Configuration Data . . . . . . . . . . . . . . . . . . . . . . . . 870
System Restarts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
XML Import/Export Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878
Importing to a System with the Management Port . . . . . . . . . . . . . . . . . . . . . . . 882
Using Operation Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
General Import Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
Using the Push Configuration Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
Defining Push Configuration Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
Pushing Configuration Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
Archiving Junos Pulse Collaboration Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . 889
Chapter 32
Logging and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
Logging and Monitoring Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
Log File Severity Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
Custom Filter Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
Dynamic Log Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893
Viewing and Deleting User Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894
Configuring Log Monitoring Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895
Configuring Events, User Access, Admin Access, and Sensor Logs . . . . . . . 895
Creating, Resetting, or Saving a Dynamic Log Query . . . . . . . . . . . . . . . . . . 896
Specifying Which Events to Save in the Log File . . . . . . . . . . . . . . . . . . . . . . 896
Creating, Editing, or Deleting Log Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Example: Using IP Address Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Monitoring the Secure Access Service as an SNMP Agent . . . . . . . . . . . . . . . . . 899
Viewing System Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
About Client-Side Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906
Enabling Client-Side Logging and Global Options . . . . . . . . . . . . . . . . . . . . 906
Enabling and Viewing Client-Side Log Uploads . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Viewing General Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908
Viewing System Capacity Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909
Specifying Time Range and Data to Display in Graphs . . . . . . . . . . . . . . . . . 910
Configuring Graph Appearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Viewing Critical System Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
Downloading the Current Service Package . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
Editing the System Date and Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911
Copyright © 2013, Juniper Networks, Inc.
xxi
Junos Pulse Secure Access Service Administration Guide
Monitoring Active Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Viewing and Cancelling Scheduled Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Adding Real Source IP Addresses to Log Messages . . . . . . . . . . . . . . . . . . . . . . . 914
Chapter 33
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
About Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
Simulating and Tracking Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
Simulating Events That Cause a Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
Tracking Events Using Policy Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
Recording a Trace File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Creating System State Snapshot Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922
Creating TCP Dump Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Secure Access Service Network Connectivity Tools . . . . . . . . . . . . . . . . . . . . . . . 924
Address Resolution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924
Ping or Ping6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924
Traceroute or Traceroute6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
NSlookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
AvgRTTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Using UNIX Commands to Test Network Connectivity . . . . . . . . . . . . . . . . . . . . . 925
Running NSLookup to Test Name Server Connectivity . . . . . . . . . . . . . . . . . . . . 926
Running Debugging Tools Remotely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926
Creating Debugging Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
Monitoring Cluster Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
Configuring Group Communication Monitoring on a Cluster . . . . . . . . . . . . . . . . 928
Configuring Network Connectivity Monitoring on a Cluster . . . . . . . . . . . . . . . . . 929
Chapter 34
Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
About Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
Cluster Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932
Example 1: Licenses Distributed Equally Among Nodes . . . . . . . . . . . . . . . . 933
Example 2: Licenses Distributed Unequally Among Nodes . . . . . . . . . . . . . 933
Example 3: Licenses Distributed Unequally Among Nodes (Extreme
Case) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933
Upgrading From Previous Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934
Task Summary: Deploying a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935
Defining and Initializing a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936
Joining an Existing Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937
Re-adding a Node to a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938
Deploying Two Nodes in an Active/Passive Cluster . . . . . . . . . . . . . . . . . . . . . . . 939
Failing Over the VIP to Another Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940
Deploying Two or More Units in an Active/Active Cluster . . . . . . . . . . . . . . . . . . 940
Synchronizing the Cluster State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942
Specifying Active/Passive, Active/Active, and Other Cluster Settings . . . . . . . . 944
Adding Multiple Cluster Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
General Cluster Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947
Managing Network Settings for Cluster Nodes . . . . . . . . . . . . . . . . . . . . . . . 947
Upgrading Clustered Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947
Upgrading the Cluster Service Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947
Migrating Cluster Configurations to a Replacement Cluster . . . . . . . . . . . . . . . . 948
Changing the IP Address of a Cluster Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949
xxii
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Deleting a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
Restarting or Rebooting Clustered Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950
Configuring the External VIP for An Active/Passive Cluster . . . . . . . . . . . . . . . . . 950
Admin Console Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
Monitoring Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953
Troubleshooting Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
“Management IP Address Differs From the Management IP Address” Error
Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
Serial Console Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956
Joining the Secure Access Service to a Cluster Through Its Serial Console . . . . . 956
Disabling a Clustered Secure Access Service Using Its Serial Console . . . . . . . . 958
Chapter 35
Delegating Administrator Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
About Delegating Administrator Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
Creating and Configuring Administrator Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 960
Specifying Management Tasks to Delegate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
Delegating System Management Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
Delegating User and Role Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
Delegating User Realm Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
Delegating Administrative Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
Delegating Resource Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 963
Delegating Resource Profile Management . . . . . . . . . . . . . . . . . . . . . . . . . . 963
Delegating Access to IVS Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963
Chapter 36
Instant Virtual System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965
Instant Virtual System (IVS) Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
Deploying an IVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
Virtualized Secure Access Service Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 970
Signing In to the Root System or the IVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
Signing-In Using the Sign-In URL Prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
Signing-In Over Virtual Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973
Signing-In Over a VLAN Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
Navigating to the IVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
IVS Configuration Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
Administering the Root System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977
Configuring the Root Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977
IVS Provisioning Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
Configuring Sign-In Ports for IVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980
Virtual Local Area Network (VLAN) on Subscriber IVS . . . . . . . . . . . . . . . . . . . . 982
Configuring VLANs on the Virtualized Secure Access Service . . . . . . . . . . . . . . . 983
Adding Static Routes to the VLAN Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . 984
Deleting a VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985
Loading the Certificates Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
Creating a Virtual System (IVS Profile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
IVS Initial Config Via Copy from the Root System or Another IVS . . . . . . . . . . . . 988
Use Cases for IVS Initial Config Via Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
Signing In Directly to the IVS as an IVS Administrator . . . . . . . . . . . . . . . . . . . . . 990
About Role-Based Source IP Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
Associating Roles with Source IP Addresses in an IVS . . . . . . . . . . . . . . . . . . . . . 991
Copyright © 2013, Juniper Networks, Inc.
xxiii
Junos Pulse Secure Access Service Administration Guide
Configuring Policy Routing Rules on the IVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992
Routing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
Overlapping IP Address Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
Define Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993
Clustering a Virtualized Secure Access Service . . . . . . . . . . . . . . . . . . . . . . . . . . 994
Accessing a DNS Server on the MSP Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 995
Accessing a DNS Server on a Subscriber Company Intranet . . . . . . . . . . . . . . . . 996
Configuring VPN Tunneling for Use on a Virtualized Secure Access Service . . . . 997
Configuring a Centralized DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1000
About Authentication Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001
Rules Governing Access to Authentication Servers . . . . . . . . . . . . . . . . . . . 1002
Configuring Authentication on a RADIUS Server . . . . . . . . . . . . . . . . . . . . . 1002
Configuring Authentication on Active Directory . . . . . . . . . . . . . . . . . . . . . . 1003
Delegating Administrative Access to IVS Systems . . . . . . . . . . . . . . . . . . . . . . . 1003
Accessing Standalone Installers on an IVS System . . . . . . . . . . . . . . . . . . . . . . 1004
Exporting and Importing IVS Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . 1004
Using XML Import and XML Export on IVS Systems . . . . . . . . . . . . . . . . . . . . . 1006
Monitoring Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
Troubleshooting VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
IVS Use Case: Policy Routing Rules Resolution . . . . . . . . . . . . . . . . . . . . . . . . . 1009
Use Case: Configuring a Global Authentication Server for Multiple
Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014
Use Case: Configuring a DNS/WINS Server IP Address per Subscriber . . . . . . . 1015
Use Case: Configuring Access to Web Applications and Web Browsing for Each
Subscriber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015
Use Case: Configuring File Browsing Access for Each Subscriber . . . . . . . . . . . . 1016
Use Case: Setting Up Multiple Subnet IP Addresses for a Subscriber’s
End-Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
Use Case: Configuring Multiple IVS Systems to Allow Access to Shared
Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018
Chapter 37
IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019
Understanding IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019
About IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019
About IPv6 Address Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020
About IPv6 Address Text Representation . . . . . . . . . . . . . . . . . . . . . . . . . . 1020
About the IPv6 Unspecified Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
About the IPv6 Loopback Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
About IPv6 Address Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
System Normalization of IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
About Neighbor Discovery Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1022
IPv6 Support Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023
Client Access Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023
Network Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025
xxiv
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
IPv6 Support and Limitations for Secure Access Service Features . . . . . . . 1031
IPv6 Feature Configuration Task Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
Managing the Neighbor Discovery Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034
Example: Creating a Cluster That Supports IPv6 Client Access . . . . . . . . . . . . . 1035
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035
Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035
Defining and Initializing a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036
Joining Nodes to the Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037
Advanced Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037
Chapter 38
Secure Access Service and IDP Interoperability . . . . . . . . . . . . . . . . . . . . . 1039
About IDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1039
Licensing: IDP Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1040
IDP Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1040
Configuring the Secure Access Service to Interoperate with IDP . . . . . . . . . . . . 1041
Interaction Between the IC Series and IDP . . . . . . . . . . . . . . . . . . . . . . . . . . 1042
Configuring IDP Sensor Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1042
Defining Automatic Response Sensor Event Policies . . . . . . . . . . . . . . . . . . . . . 1044
Identifying and Managing Quarantined Users Manually . . . . . . . . . . . . . . . . . . 1046
Chapter 39
Routing AAA Over the Management Port for Virtual Appliances . . . . . . 1049
About Traffic Segregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1049
Configuring AAA Traffic Over the Management Port . . . . . . . . . . . . . . . . . . . . . 1050
Configuring AAA Traffic Through Both the Internal and Management Ports . . . 1051
Part 6
System Services
Chapter 40
Secure Access Service Serial Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055
Using the Serial Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055
Rolling Back to a Previous System State Through the Serial Console . . . . . . . . 1056
Resetting a Secure Access Service Device to the Factory Setting Using the Serial
Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057
Performing Common Recovery Tasks with the Serial Console . . . . . . . . . . . . . . 1058
Chapter 41
Customizable Admin and End-User UIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
Customizable Admin and End-User UIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1061
Customizable End-User Interface Elements Overview . . . . . . . . . . . . . . . . 1062
Chapter 42
SA6000 Series Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
SA6000 Series Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
SA6000 Field-Replaceable Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064
Chapter 43
SA4500 and SA6500 Series Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
SA4500 and SA6500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
Standard Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
SA Series 6500 Field-Replaceable Units . . . . . . . . . . . . . . . . . . . . . . . . . . . 1068
Device Status LED Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1069
Ethernet Port LED Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1070
Replacing the Cooling Fans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1071
Replacing a Hard Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1072
Replacing IOC Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1072
Copyright © 2013, Juniper Networks, Inc.
xxv
Junos Pulse Secure Access Service Administration Guide
Replacing a Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074
Chapter 44
Secure Access FIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077
SA FIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077
SA FIPS Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078
Creating Administrator Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1079
Deploying a Cluster in a Secure Access FIPS Environment . . . . . . . . . . . . . . . . 1080
Creating a New Security World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1082
Recovering an Archived Security World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085
Chapter 45
SA4500 and SA6500 FIPS Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089
FIPS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089
Name and Password Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1090
Initializing a Keystore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
Reinitializing the Keystore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
Joining a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1092
Importing Device Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1093
Changing the Security Officer Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1093
Changing the Web User Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Resetting the HSM Card In Case Of An Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095
Upgrading the HSM Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095
Binary Importing and Exporting of the Keystore . . . . . . . . . . . . . . . . . . . . . . . . . 1096
FIPS Device Status LED Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096
Chapter 46
Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099
About Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099
Enabling System-Level Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1101
Chapter 47
Multi-Language Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1103
About Multi-Language Support for the Secure Access Service . . . . . . . . . . . . . . 1103
Encoding Files for Multi-Language Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104
Localizing the User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104
Localizing Custom Sign-In and System Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105
Chapter 48
Handheld Devices and PDAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107
Handheld Devices and PDAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107
Task Summary: Configuring the Secure Access Service for PDAs and
Handhelds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1108
Defining Client Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1110
Enabling WSAM on PDAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111
Enabling ActiveSync For Handheld Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112
Chapter 49
Using IKEv2 with the Secure Access Service . . . . . . . . . . . . . . . . . . . . . . . . . 1115
About IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115
Extensible Authentication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115
Client Certificate-Based Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1116
Client Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1116
Supported Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117
Task Summary: Configuring Secure Access for IKEv2 . . . . . . . . . . . . . . . . . . . . . . 1118
Defining the IKEv2 Role Mapping Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1119
xxvi
Copyright © 2013, Juniper Networks, Inc.
Table of Contents
Enabling the IKEv2 Access Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1120
Configuring the IKEv2 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1120
Chapter 50
Writing Custom Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1123
Custom Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1123
Elements Used in Custom Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124
Wildcard Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1127
Distinguished Name Variables and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 1128
System Variables and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1128
Using System Variables in Realms, Roles, and Resource Policies . . . . . . . . . . . . 1139
Using Multi-Valued Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1140
Specifying Multi-valued Attributes in a Bookmark Name . . . . . . . . . . . . . . . . . . . 1141
Specifying Fetch Attributes in a Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1141
Specifying the homeDirectory Attribute for LDAP . . . . . . . . . . . . . . . . . . . . . . . . 1142
Using Custom Variables and Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1142
About Custom Variables and Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1142
Using Macros in Custom Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143
append . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144
daysdiff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145
regmatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1146
Part 7
Index
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1149
Copyright © 2013, Juniper Networks, Inc.
xxvii
Junos Pulse Secure Access Service Administration Guide
xxviii
Copyright © 2013, Juniper Networks, Inc.
List of Figures
Part 1
Getting Started
Chapter 2
Introduction to Secure Access Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 1: Secure Access Service Working within a LAN . . . . . . . . . . . . . . . . . . . . . . . 17
Part 2
Access Management Framework
Chapter 3
General Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 2: Security Checks Performed During a User Session . . . . . . . . . . . . . . . . . 65
Figure 3: Federation IF-MAP Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Figure 4: Session-Import and Session-Export Policies . . . . . . . . . . . . . . . . . . . . . . 87
Chapter 4
User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figure 5: Security Checks Performed by the Secure Access Service to Create a
Session Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Chapter 5
Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Figure 6: Using Roles and Resource Policies to Configure Resources . . . . . . . . . . 119
Figure 7: Using Resource Profiles to Configure Resources . . . . . . . . . . . . . . . . . . . 120
Chapter 7
Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Figure 8: Resource Policy Evaluation Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Chapter 9
SAML Single Sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Figure 9: Secure Access Service as a SAML Service Provider in a
Service-Provider-Initiated SSO Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Figure 10: Secure Access Service as a SAML Service Provider in an
Identity-Provider-Initiated SSO Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Figure 11: Secure Access Service as a SAML Identity Provider (Gateway
Mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Figure 12: Secure Access Service as a SAML Identity Provider (Peer Mode) in a
Service-Provider-Initiated SSO Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Figure 13: Secure Access Service as a SAML Identity Provider (Peer Mode) in an
Identity-Provider-Initiated SSO Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Figure 14: Secure Access Service as a SAML identity provider (Gateway
Mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Figure 15: Secure Access Service as a SAML Identity Provider (Peer Mode) in a
Service-Provider-Initiated SSO Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Figure 16: Secure Access Service as a SAML Identity Provider (Peer Mode) in an
Identity-Provider-Initiated SSO Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Figure 17: Google Apps Advanced Tools: SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Figure 18: SAML Global Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Figure 19: SAML Identity Provider Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Copyright © 2013, Juniper Networks, Inc.
xxix
Junos Pulse Secure Access Service Administration Guide
Figure 20: Peer SP Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Figure 21: External Applications Policy Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Figure 22: Artifact Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Figure 23: POST Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Figure 24: Access Control Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Chapter 10
Authentication Realms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Figure 25: Junos Pulse Role Mapping Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Figure 26: Server Catalog > Attributes Tab — Adding an Attribute for LDAP . . . . 293
Figure 27: Server Catalog > Groups Tab — Adding LDAP Groups . . . . . . . . . . . . . 294
Figure 28: Server Catalog > Groups Tab — Adding Active Directory Groups . . . . 296
Chapter 12
Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Figure 29: Collecting and Submitting Credentials from Multiple Servers . . . . . . . 317
Figure 30: Artifact Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Figure 31: POST Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Figure 32: Access Control Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Part 3
Endpoint Defense
Chapter 14
Host Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Figure 33: Host Checker Creates a Tunnel from a Client to a Policy Server Behind
the Secure Access Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Part 4
Remote Access
Chapter 23
Secure Application Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
Figure 34: Java Secure Application Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Figure 35: Java Secure Application Manager and Enhanced MS Exchange
Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Figure 36: Java Secure Application Manager and Enhanced Lotus Notes
Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Chapter 26
Junos Pulse Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Figure 37: Using the Junos Pulse Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Figure 38: Using the Junos Pulse Collaboration Tab in the Options Window . . . 674
Figure 39: Online Meeting Button is Not Used . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Figure 40: Deleting the Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Chapter 28
VPN Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Figure 41: GINA Installation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Figure 42: Pulse Logon Tile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Figure 43: Credential Provider Log Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
Part 5
System Management
Chapter 29
General System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Figure 44: Example VLAN Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
Figure 45: License Key Generation and Activation . . . . . . . . . . . . . . . . . . . . . . . . 792
Chapter 31
System Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Figure 46: Secure Access Service Object Referential Integrity Constraints . . . . 866
xxx
Copyright © 2013, Juniper Networks, Inc.
List of Figures
Chapter 32
Logging and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
Figure 47: Using IP Address Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
Chapter 34
Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
Figure 48: Active/Passive Cluster Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940
Figure 49: Active/Active Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942
Chapter 36
Instant Virtual System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965
Figure 50: MSP Deployment Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 968
Figure 51: IVS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 970
Figure 52: Setting a Static Route in MSP Network DNS or Application Servers . . 998
Chapter 37
IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019
Figure 53: Secure Access Service IPv4 Support: IPv4-Only Network . . . . . . . . . 1025
Figure 54: Secure Access Service IPv6 Support: IPv6-Only Networks . . . . . . . . 1026
Figure 55: Secure Access Service IPv6 Support: Dual Stack . . . . . . . . . . . . . . . . 1027
Figure 56: Secure Access Service IPv6 Support: Client or ISP-Side Transition
Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028
Figure 57: Secure Access Service IPv6 Support: ISP or Corporate Network-Side
Transition Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1029
Figure 58: Secure Access Service IPv6 Support: One-Arm Deployment . . . . . . 1030
Chapter 38
Secure Access Service and IDP Interoperability . . . . . . . . . . . . . . . . . . . . . 1039
Figure 59: Secure Access Service and IDP Topology Scenario 1 . . . . . . . . . . . . . 1041
Figure 60: Secure Access Service and IDP Topology Scenario 2 . . . . . . . . . . . . . 1041
Part 6
System Services
Chapter 40
Secure Access Service Serial Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055
Figure 61: Secure Access Service Serial Console . . . . . . . . . . . . . . . . . . . . . . . . . 1056
Copyright © 2013, Juniper Networks, Inc.
xxxi
Junos Pulse Secure Access Service Administration Guide
xxxii
Copyright © 2013, Juniper Networks, Inc.
List of Tables
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxvii
Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxviii
Part 1
Getting Started
Chapter 2
Introduction to Secure Access Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Table 2: Configurable Parameters for Junos Pulse Connection Sets . . . . . . . . . . . 43
Part 2
Access Management Framework
Chapter 4
User Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Table 3: Session Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Table 4: Configurable Options on the Apple iPad . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Table 5: View Menu Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Chapter 5
Resource Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Table 6: Resource Profile Types and Configuration Information . . . . . . . . . . . . . . 120
Chapter 7
Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Table 7: DNS Hostname Special Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Table 8: Port Possible Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Chapter 8
Authentication and Directory Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Table 9: Supported Password Management Functions . . . . . . . . . . . . . . . . . . . . . 172
Table 10: AD/NT Password Management Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Table 11: Attributes Common to both Start and Stop Messages . . . . . . . . . . . . . 184
Table 12: Start Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Table 13: Stop Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Table 14: RADIUS Role Mapping Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Table 15: eTrust SiteMinder Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . 207
Table 16: eTrust SiteMinder Advanced Configuration Options . . . . . . . . . . . . . . . 212
Table 17: SAML SP Profile (POST and Artifact) . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Chapter 9
SAML Single Sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Table 18: Supported SAML 2.0 Deployment Profiles . . . . . . . . . . . . . . . . . . . . . . 228
Table 19: SAML Support for FIPS Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Table 20: SAML Global Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Table 21: SAML Metadata Provider Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Table 22: SAML Service Provider Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Table 23: Sign-in SAML Identity Provider Metadata Provider Settings . . . . . . . . 238
Table 24: Sign-in SAML Identity Provider Settings . . . . . . . . . . . . . . . . . . . . . . . . 239
Table 25: Peer Service Provider Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Copyright © 2013, Juniper Networks, Inc.
xxxiii
Junos Pulse Secure Access Service Administration Guide
Table 26: SAML SSO Resource Policy Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Table 27: SAML SSO External Applications Policy Settings . . . . . . . . . . . . . . . . . 246
Table 28: SAML ACL Web Policy Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Table 29: Google Apps SSO Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Table 30: SAML Authentication Server (SAML 1.1) . . . . . . . . . . . . . . . . . . . . . . . . . 271
Part 3
Endpoint Defense
Chapter 14
Host Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Table 31: Wildcard Characters for Specifying a File Name or Process Name . . . . 377
Table 32: Environment Variables for Specifying a Directory Path on Windows . . 378
Table 33: Environment Variables for Specifying a Directory Path on Macintosh,
Linux and Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Part 4
Remote Access
Chapter 17
Citrix Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Table 34: Accessing the Citrix Web Interface Server using Web Resource Profile
Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Chapter 21
Web Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Table 35: DNS hostname special characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Table 36: Port possible values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Table 37: Port Possible Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Table 38: Port Possible Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Table 39: OWA Caching Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Table 40: iNotes Caching Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Table 41: Predefined Resource Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Chapter 23
Secure Application Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
Table 42: WSAM Command Line Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Chapter 25
Terminal Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
Table 43: Case-Insensitive Terminal Services Session Bookmark Parameter
Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Chapter 28
VPN Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Table 44: Installing Standard 32-Bit Libraries and Components . . . . . . . . . . . . . 714
Table 45: VPN tunneling Compatibility with Third-Party VPN Clients . . . . . . . . . 730
Table 46: Syntax for IP Address Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
Table 47: Privilege Levels and Percent of Maximum Bandwidth . . . . . . . . . . . . . 750
Part 5
System Management
Chapter 29
General System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Table 48: Internal Port Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
Table 49: External Port Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Table 50: RAID and Hard Drive Status for the SA6000 and SA6500 . . . . . . . . . 785
Table 51: RAID and Hard Drive Status for the MAG-SM360 . . . . . . . . . . . . . . . . . 785
Table 52: Management Port Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806
Chapter 31
xxxiv
System Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851
Copyright © 2013, Juniper Networks, Inc.
List of Tables
Table 53: System Behavior When Editing Options . . . . . . . . . . . . . . . . . . . . . . . . 876
Table 54: Legal Operation Attribute Relationships . . . . . . . . . . . . . . . . . . . . . . . 883
Chapter 32
Logging and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
Table 55: Configuration Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901
Chapter 33
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
Table 56: Snapshot Configuration Options and Details . . . . . . . . . . . . . . . . . . . . 923
Chapter 34
Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
Table 57: Cluster Status Page Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
Table 58: Cluster Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
Chapter 36
Instant Virtual System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965
Table 59: VLAN1 Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011
Table 60: VLAN2 Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1012
Table 61: VLAN3 Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1012
Table 62: VLAN4 Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1012
Table 63: VLAN1 Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
Table 64: VLAN2 route table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014
Table 65: VLAN3 route table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014
Table 66: VLAN4 route table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014
Chapter 37
IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019
Table 67: System Normalization of IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . . 1021
Table 68: Secure Access Service Release 7.3 Client Access Scenarios . . . . . . . 1023
Table 69: Summary of IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1031
Table 70: IPv6 Feature Configuration Task Summary . . . . . . . . . . . . . . . . . . . . . 1033
Table 71: Secure Access Service Clusters: Advanced Configuration
Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Chapter 39
Routing AAA Over the Management Port for Virtual Appliances . . . . . . 1049
Table 72: Configuring Traffic Segregation Options . . . . . . . . . . . . . . . . . . . . . . . 1050
Part 6
System Services
Chapter 43
SA4500 and SA6500 Series Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067
Table 73: Device Status LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1070
Table 74: 4-Port Copper Gigabit Ethernet LEDs (available on IC4500 and
IC6500) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1070
Chapter 45
SA4500 and SA6500 FIPS Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1089
Table 75: Security Officer Name and Username Requirements . . . . . . . . . . . . 1090
Table 76: Status LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097
Chapter 50
Writing Custom Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1123
Table 77: Custom Expression Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124
Table 78: System Variables and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1129
Copyright © 2013, Juniper Networks, Inc.
xxxv
Junos Pulse Secure Access Service Administration Guide
xxxvi
Copyright © 2013, Juniper Networks, Inc.
About This Guide
•
Objective on page xxxvii
•
Audience on page xxxvii
•
Document Conventions on page xxxvii
•
Documentation on page xxxviii
•
Obtaining Documentation on page xxxviii
•
Documentation Feedback on page xxxviii
•
Requesting Technical Support on page xxxviii
Objective
This guide describes basic configuration procedures for Juniper Networks Secure Access
Secure Access Service. This document was formerly titled Secure Access Administration
Guide. This document is now part of the Junos Pulse documentation set.
Audience
This guide is designed for network administrators who are configuring and maintaining
a Juniper Networks Secure Access Service device. To use this guide, you need a broad
understanding of networks in general and the Internet in particular, networking principles,
and network configuration. Any detailed discussion of these concepts is beyond the scope
of this guide.
Document Conventions
Table 1 on page xxxviii defines notice icons used in this guide.
Copyright © 2013, Juniper Networks, Inc.
xxxvii
Junos Pulse Secure Access Service Administration Guide
Table 1: 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.
Documentation
For a list of related Secure Access Service documentation, see
http://www.juniper.net/support/products/sa/. If the information in the latest Release
Notes differs from the information in the documentation, follow the Release Notes.
Obtaining Documentation
To obtain the most current version of all Juniper Networks technical documentation, see
the products documentation page on the Juniper Networks web site at
http://www.juniper.net/techpubs.
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can
improve the documentation. You can send your comments to
techpubs-comments@juniper.net, or fill out the documentation feedback form at
https://www.juniper.net/cgi-bin/docbugreport/ . If you are using e-mail, be sure to include
the following information with your comments:
•
Document name
•
Page number
•
Software release version
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.
xxxviii
Copyright © 2013, Juniper Networks, Inc.
About This Guide
•
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.
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 © 2013, Juniper Networks, Inc.
xxxix
Junos Pulse Secure Access Service Administration Guide
xl
Copyright © 2013, Juniper Networks, Inc.
PART 1
Getting Started
•
Initial Verification and Key Concepts on page 3
•
Introduction to Secure Access Service on page 15
Copyright © 2013, Juniper Networks, Inc.
1
Junos Pulse Secure Access Service Administration Guide
2
Copyright © 2013, Juniper Networks, Inc.
CHAPTER 1
Initial Verification and Key Concepts
•
Verifying User Accessibility on page 3
•
Creating a Test Scenario to Learn Secure Access Service 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 Secure Access Service device. After creating the account through
the admin console, sign in as the user on the Secure Access Service 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.
Secure Access Service 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 Secure Access
Service.
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 Secure Access Service.
Copyright © 2013, Juniper Networks, Inc.
3
Junos Pulse Secure Access Service Administration Guide
8. Enter the username and password you created for the user account and then click
Sign In to access the Secure Access Service home page for users.
9. Enter the URL to an internal Web server in the Address box and click Browse. Secure
Access Service opens the Web page in the same browser window, so to return to the
Secure Access Service 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 Secure Access Service home
page, and click Browse. Secure Access Service opens the Web page in the same
browser window, so use the button on the toolbar to return to the Secure Access
Service home page.
11. Click Browsing > Windows Files on the Secure Access Service 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 Secure Access Service 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 Secure Access Service Concepts and Best Practices
Secure Access Service 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, Secure Access Service 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 © 2013, Juniper Networks, Inc.
Chapter 1: Initial Verification and Key Concepts
Secure Access Service supports two types of users:
Related
Documentation
•
Administrators—An administrator is a person who may view or modify Secure Access
Service configuration settings. You create the first administrator account through the
serial console.
•
Users—A user is a person who uses Secure Access Service 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
Secure Access Service 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 Secure Access Service 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 © 2013, Juniper Networks, Inc.
5
Junos Pulse Secure Access Service 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 Secure Access Service 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 Secure Access Service grants
access to a resource or performs an action. Note that Secure Access Service is
preconfigured with two types of resource policies:
•
Web Access—The predefined Web Access resource policy, Initial Policy for Local
Resources, allows access only to hosts belonging to domains within the secured
network.
•
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 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 © 2013, 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 Secure Access Service (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.
Secure Access Service 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 Secure Access Service 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 Secure Access Service.
Related
Documentation
•
Verifying User Accessibility on page 3
•
Creating a Test Scenario to Learn Secure Access Service 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 Secure
Access Service, the user specifies an authentication realm, which is associated with an
authentication server. Secure Access Service forwards the user’s credentials to this
authentication server to verify the user’s identity.
Copyright © 2013, Juniper Networks, Inc.
7
Junos Pulse Secure Access Service Administration Guide
Secure Access Service 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 Secure Access Service. Secure Access Service is
preconfigured with one local authentication server for users called “System Local.” This
predefined local authentication server is a Secure Access Service 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: Secure Access Service 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 Secure Access Service 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 Secure Access Service Concepts and Best Practices
on page 4
•
Defining a User Role on page 5
Copyright © 2013, 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. Secure Access Service 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 Secure Access Service submits credentials to an authentication server for
verification.
•
A directory server, which is an LDAP server that provides user and group attribute
information to Secure Access Service for use in role mapping rules and resource policies
(optional).
•
Role mapping rules, which are conditions a user must meet for Secure Access Service
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.
Secure Access Service 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 © 2013, Juniper Networks, Inc.
9
Junos Pulse Secure Access Service Administration Guide
Wait for Secure Access Service 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 Secure Access Service 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 Secure Access Service.
•
A sign-in page to display to the user.
•
Whether or not the user needs to type or select an authentication realm to which Secure
Access Service submits credentials.
•
The authentication realms where the sign-in policy applies.
All Secure Access Service 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 Secure Access Service, Secure Access Service 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 Secure Access
Service has the Junos Pulse Collaboration Upgrade license, the */meeting sign-in policy
10
Copyright © 2013, Juniper Networks, Inc.
Chapter 1: Initial Verification and Key Concepts
is also listed on this page. This policy enables you to customize the sign-in page for Junos
Pulse Collaboration 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 Secure Access Service 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
Copyright © 2013, Juniper Networks, Inc.
11
Junos Pulse Secure Access Service Administration Guide
•
Defining an Authentication Realm on page 9
•
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 Secure
Access Service device.
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 Secure Access
Service home page for users.
Secure Access Service forwards the credentials to Test Realm, which is configured
to use Test Server. Upon successful verification by this authentication server, Secure
Access Service 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.
Secure Access Service opens the Web page in the same browser window, so to return
to the Secure Access Service home page, click the center icon in the browsing toolbar
that appears on the target Web page.
5. On the Secure Access Service home page, type www.google.com and click Browse.
Secure Access Service 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 Secure Access Service 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 © 2013, Juniper Networks, Inc.
Chapter 1: Initial Verification and Key Concepts
8. On the Secure Access Service home page, type www.google.com and click Browse.
Secure Access Service opens the Web page in the same browser window.
9. The test scenario demonstrates the basic Secure Access Service 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 Secure
Access Service access management, we recommend that you take a few minutes to
review the online Help to familiarize yourself with its contents.
When you configure Secure Access Service for your enterprise, we recommend that
you perform user access configuration. Before you make your Secure Access Service
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 Secure Access Service 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, Secure Access Service 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
Secure Access Service. 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 Secure Access Service 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 a Secure Access Service database that stores administrator accounts. You
create the first administrator account in this server through the serial console. (Secure
Access Service 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 © 2013, Juniper Networks, Inc.
13
Junos Pulse Secure Access Service 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 Secure Access Service followed by /admin, Secure
Access Service 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 © 2013, Juniper Networks, Inc.
CHAPTER 2
Introduction to Secure Access Service
•
Secure Access Service Solution Overview on page 16
•
Securing Traffic with Secure Access Service on page 18
•
Authenticating Users with Existing Servers on page 19
•
Fine-Tuning Access to Secure Access Service and the Resources It
Intermediates on page 20
•
Creating a Seamless Integration Between Secure Access Service and the Resources
It Intermediates on page 21
•
Protecting Against Infected Computers and Other Security Concerns on page 21
•
Ensuring Redundancy in the Secure Access Service Environment on page 22
•
Making the Secure Access Service Interface Match My Company’s
Look-and-Feel on page 23
•
Enabling Users on a Variety of Computers and Devices to Use Secure Access
Service on page 23
•
Providing Secure Access for My International Users on page 24
•
Configuring Secure Access Service on page 24
•
Network and Security Manager and the Secure Access Service on page 25
•
Configuring Secure Access for the Initial DMI Connection on page 28
•
Managing Large Binary Data Files on page 30
•
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 © 2013, Juniper Networks, Inc.
15
Junos Pulse Secure Access Service Administration Guide
•
Junos Pulse Configuration Overview on page 40
•
Configuring a Role for Junos Pulse on page 41
•
Client Connection Set Options on page 43
•
Creating a Client Connection Set on page 47
•
Configuring Connection Rules for Location Awareness on page 49
•
Junos Pulse Component Set Options on page 51
•
Creating a Client Component Set on page 52
•
Junos Pulse Client Installation Overview on page 53
•
Installing the Junos Pulse Client from the Web on page 54
•
Installing the Junos Pulse Client Using a Preconfiguration File on page 55
Secure Access Service Solution Overview
The Juniper Networks Secure Access Service 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.
Secure Access Service 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, Secure Access Service 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, Secure Access Service eliminates the need
to deploy extranet toolkits in a traditional DMZ or provision a remote access VPN for
employees.
To access the intuitive Secure Access Service 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 Secure Access Service product
and upgrade options you have purchased.
16
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
Figure 1: Secure Access Service Working within a LAN
You can configure Secure Access Service in the following ways:
•
Provide users with secure access to a variety of resources. Secure Access Service
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 Secure Access Service 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.
Secure Access Service acts as a secure, Application Layer gateway intermediating all
requests between the public Internet and internal corporate resources. All requests that
enter Secure Access Service are already encrypted by the end user's browser, using
SSL/HTTPS 128-bit or 168-bit encryption—unencrypted requests are dropped. Because
Secure Access Service 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 Secure Access Service on page 18
•
Authenticating Users with Existing Servers on page 19
Copyright © 2013, Juniper Networks, Inc.
17
Junos Pulse Secure Access Service Administration Guide
•
Fine-Tuning Access to Secure Access Service and the Resources It Intermediates on
page 20
•
Creating a Seamless Integration Between Secure Access Service and the Resources
It Intermediates on page 21
•
Protecting Against Infected Computers and Other Security Concerns on page 21
•
Ensuring Redundancy in the Secure Access Service Environment on page 22
•
Making the Secure Access Service Interface Match My Company’s Look-and-Feel on
page 23
•
Enabling Users on a Variety of Computers and Devices to Use Secure Access Service
on page 23
•
Providing Secure Access for My International Users on page 24
Securing Traffic with Secure Access Service
Secure Access Service 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 Secure Access Service’s Content Intermediation Engine to intermediate
traffic to Web-based applications and Web pages.
Secure Access Service 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 Secure Access Service
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.
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
Related
Documentation
•
Client/server applications—Use the Secure Application Manager (SAM) feature to
intermediate this type of content. SAM comes in two varieties (Windows and Java
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.
•
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 Secure Access Service,
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 VPN Tunneling 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.
•
Secure Access Service Solution Overview on page 16
Authenticating Users with Existing Servers
You can easily configure Secure Access Service 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 Secure Access Service device. Secure Access Service 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 Secure Access Service and use Secure Access Service 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 Secure
Access Service, you can use the Secure Access Service anonymous authentication server,
which allows users to access the Secure Access Service device without providing a
username or password.
Copyright © 2013, Juniper Networks, Inc.
19
Junos Pulse Secure Access Service Administration Guide
Related
Documentation
•
Secure Access Service Solution Overview on page 16
•
About Authentication and Directory Servers on page 144
Fine-Tuning Access to Secure Access Service and the Resources It Intermediates
In addition to using authentication servers to control access to Secure Access Service,
you can control access to Secure Access Service and the resources it intermediates using
a variety of additional client-side checks. Secure Access Service enables you to create
a multilayered approach to protect Secure Access Service and your resources:
1.
First, you can perform preauthentication checks that control user access to the Secure
Access Service sign-in page. For instance, you might configure Secure Access Service
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 Secure Access Service sign-in page until the user has updated
the computer’s antivirus software.
2. Once a user has successfully accessed the Secure Access Service sign-in page, you
can perform realm-level checks to determine whether he can access the Secure
Access Service 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 Secure
Access Service end-user home page. Otherwise, Secure Access Service does not
enable the user to sign in, or Secure Access Service displays a “stripped down” version
of the 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. Secure Access Service provides
extremely flexible policy definitions, enabling you to dynamically alter end-user
resource access based on corporate security policies.
3. After Secure Access Service 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.
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
20
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
members of the Employees role and to sign into Secure Access Service during business
hours to access your company Intranet.
Related
Documentation
•
Secure Access Service Solution Overview on page 16
•
Access Management Overview on page 61
Creating a Seamless Integration Between Secure Access Service and the Resources
It Intermediates
In a typical Secure Access Service configuration, you could add bookmarks directly to
the Secure Access Service end-user home page. These bookmarks are links to the
resources that you configure Secure Access Service to intermediate. Adding these
bookmarks enables users to sign into a single place (Secure Access Service) and find a
consolidated list of all of the resources available to them.
Within this typical configuration, you can streamline the integration between Secure
Access Service and the intermediated resources by enabling single sign-on (SSO). SSO
is a process that allows preauthenticated Secure Access Service users to access other
applications or resources that are protected by another access management system
without having to re-enter their credentials. During Secure Access Service configuration,
you can enable SSO by specifying user credentials that you want the Secure Access
Service to pass to the intermediated resources.
Or, if you do not want to centralize user resources on the Secure Access Service end-user
home page, you could create links to the Secure Access Service-intermediated resources
from another Web page. For instance, you can configure bookmarks on Secure Access
Service, 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 Secure Access Service home page.
As with standard Secure Access Service bookmarks, you can enable SSO for these
external links.
Related
Documentation
•
Secure Access Service Solution Overview on page 16
•
About Single Sign-On on page 313
Protecting Against Infected Computers and Other Security Concerns
Secure Access Service 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 Secure Access Service. 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 Secure Access Service sign-in pages, realms,
roles, and resources based on the results that Host Checker returns. Or, you can display
remediation instructions to users so they can bring their computers into compliance
Copyright © 2013, Juniper Networks, Inc.
21
Junos Pulse Secure Access Service Administration Guide
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 Secure Access Service session when the session is complete.
You can also secure your network from hostile outside intrusion by integrating your Secure
Access Service 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
•
Secure Access Service Solution Overview on page 16
•
Configuring the Secure Access Service to Interoperate with IDP on page 1041
Ensuring Redundancy in the Secure Access Service Environment
You can ensure redundancy in your Secure Access Service environment using the 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.
In Active/Passive mode, one Secure Access Service device actively serves user requests
while the other Secure Access Service device runs passively in the background to
synchronize state data. If the active Secure Access Service device goes offline, the passive
Secure Access Service device 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. The load balancer hosts the cluster VIP and routes user requests to Secure
Access Service defined in its cluster group based on source-IP routing. If a Secure Access
Service device goes offline, the load balancer adjusts the load on the other active Secure
Access Service device.
NOTE: WAN clustering is not supported on the MAG Series Junos Pulse
Gateways, except as it relates to campus networks. In a well-connected
campus network, where the connectivity is more LAN-like than WAN-like,
the Junos Pulse Gateways can be clustered in separate buildings.
Related
Documentation
22
•
Secure Access Service Solution Overview on page 16
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
Making the Secure Access Service Interface Match My Company’s Look-and-Feel
Secure Access Service 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
Secure Access Service end-user console so it will resemble one of your standard company
Web pages or applications.
For instance, you can easily customize the headers, background colors, and logos that
Secure Access Service displays in the sign-in page and end-user console to match your
company’s style. You can also easily customize the order in which Secure Access Service
displays bookmarks and the help system that Secure Access Service displays to users.
Or, if you do not want to display the Secure Access Service 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 Secure Access Service
console. If you choose to use this option, you may want to add links to your Secure Access
Service bookmarks on the new page.
If you want to further customize the Secure Access Service sign-in page, you can use the
Secure Access Service’s custom sign-in pages feature. Unlike the standard customization
options that you can configure through the Secure Access Service 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
•
Secure Access Service Solution Overview on page 16
•
Creating a Seamless Integration Between Secure Access Service and the Resources
It Intermediates on page 21
•
Customizable Admin and End-User UIs on page 1061
Enabling Users on a Variety of Computers and Devices to Use Secure Access Service
In addition to allowing users to access Secure Access Service from standard workstations
and kiosks running Windows, Macintosh, and Linux operating systems, end users can
access Secure Access Service from connected PDAs, handhelds and smart phones such
as i-mode and Pocket PC. When a user connects from a PDA or handheld device, Secure
Access Service determines which pages and functionality to display based on settings
that you configure.
For more information about specifying which pages Secure Access Service displays to
different devices, see the Secure Access Service supported platforms document available
on the Juniper Networks Customer Support Center website.
Related
Documentation
•
Secure Access Service Solution Overview on page 16
•
Handheld Devices and PDAs on page 1107
Copyright © 2013, Juniper Networks, Inc.
23
Junos Pulse Secure Access Service Administration Guide
Providing Secure Access for My International Users
Secure Access Service supports English (US), French, German, Spanish, Simplified
Chinese, Traditional Chinese, Japanese, and Korean. When your users sign into Secure
Access Service, Secure Access Service automatically 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
•
Secure Access Service Solution Overview on page 16
•
About Multi-Language Support for the Secure Access Service on page 1103
Configuring Secure Access Service
To enable users to start using Secure Access Service, 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.
2. After you connect the Secure Access Service device 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, Secure Access Service
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 Secure Access Service.
d. Define a sign-in policy that specifies the URL that users must access to sign into
Secure Access Service 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.
Secure Access Service 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.
24
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
Once you have completed these basic steps, your Secure Access Service is ready for use.
You can start using it as is, or configure additional advanced features such as endpoint
defense and clustering.
Related
Documentation
•
Creating a Test Scenario to Learn Secure Access Service Concepts and Best Practices
on page 4
Network and Security Manager and the Secure Access Service
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
Secure Access Service configurations.
With NSM you can manage most of the parameters that you can configure through the
Secure Access Service admin console. The configuration screens rendered through NSM
are similar to the Secure Access Service’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 Secure
Access Service admin console interface, or you can manage from the Secure Access
Service admin console.
How Secure Access Service and NSM communicate
Secure Access Service 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 device specific 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.
Secure Access Service’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 Secure Access Service using 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 Secure Access Service’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.
Copyright © 2013, Juniper Networks, Inc.
25
Junos Pulse Secure Access Service Administration Guide
Before attempting to communicate with NSM, you must first complete the initial
configuration of Secure Access Service. Initial configuration includes network interface
settings, DNS settings, licensing, and password administration.
If you have several Secure Access Service devices 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 Secure
Access Service to communicate with NSM using the appropriate network information.
Once Secure Access Service has been configured to communicate with NSM, Secure
Access Service contacts NSM and establishes a DMI session through an initial TCP
handshake.
All communications between Secure Access Service and NSM occur over SSH to ensure
data integrity.
After Secure Access Service initially contacts NSM and a TCP session is established,
interaction between Secure Access Service and NSM is driven from NSM, which issues
commands to get hardware, software, and license details of Secure Access Service. NSM
connects to the Schema Repository to download the configuration schema that is
particular to Secure Access Service.
NSM then issues a command to retrieve configuration information from Secure Access
Service. If NSM is contacted by more than one Secure Access Service device as a member
of a cluster, information from only one of the cluster devices is gathered. NSM attempts
to validate the configuration received from Secure Access Service against the schema
from Juniper Networks.
Once Secure Access Service and NSM are communicating, Secure Access Service delivers
syslog and event information to NSM.
After NSM and Secure Access Service are connected, you can make any configuration
changes directly on Secure Access Service, bypassing NSM. NSM automatically detects
these changes and imports the new configuration data. Changes to Secure Access Service
cluster members will similarly be detected by NSM.
When you make changes to the Secure Access Service configuration through NSM you
must push the changes to the device by performing an Update Device operation.
When you double-click the Secure Access Service 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 Secure Access Service interface.
26
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
Available Services and Configuration Options
The following services and options are provided to NSM by Secure Access Service:
•
Inventory management service—inventory management service enables management
of Secure Access Service 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 Secure Access Service
status to be obtained, including name, domain, OS version, synchronization status,
connection details, and current alarms.
•
Logging service—logging service allow Secure Access Service logs to be obtained in
a time-generated order. Logging configuration details that are set on Secure Access
Service will apply to NSM.
•
XML-based configuration management service—configuration management service
enables NSM to manage the configuration of Secure Access Service. NSM uses the
same XML Schema as Secure Access Service, so you can troubleshoot NSM using XML
files downloaded from Secure Access Service.
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 Secure Access Service
DMI Communication with the Secure Access Service
To configure the Secure Access Service to communicate with NSM you must coordinate
actions between the Secure Access Service 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 Secure Access Service and NSM you will need to do the following:
Related
Documentation
•
Install and configure the Secure Access Service.
•
Add the Secure Access Service as a device in NSM.
•
Configure and activate the DMI agent on the Secure Access Service.
•
Confirm connectivity and import the Secure Access Service configuration into NSM.
•
Configuring Secure Access Service for the Initial DMI Connection
•
Managing Large Binary Data Files on page 30
•
Uploading and Linking Large Binary Data Files with NSM on page 30
Copyright © 2013, Juniper Networks, Inc.
27
Junos Pulse Secure Access Service Administration Guide
Configuring Secure Access for the Initial DMI Connection
To permit Secure Access and NSM to make an initial connection, you must add an NSM
administrative user to the Secure Access configuration. This topic provides a summary
of adding the NSM administrator and configuring the DMI agent to allow the Secure
Access device and NSM to communicate. Complete configuration of the Secure Access
device for authenticating users is outside the scope of this topic.
To initiate a DMI session for communication between Secure Access and NSM:
1.
Ensure that basic connection information is configured on the Secure Access device
(network address, DNS, password).
2. Ensure that the proper licenses are installed on the Secure Access device.
3. From the NSM UI client Device Manager, click the Add icon and select Device to open
the Add Device wizard, and enter the applicable information required to add a Secure
Access device to NSM. See the Administration Guide.
NOTE: You must enter a unique NSM admin username and password on
the NSM UI client. This username will be used on the Secure Access device
as the username for the administrator account that will be used to manage
the Secure Access device. NSM must have a unique account login to avoid
interrupting the communication with Secure Access. NSM automatically
generates a unique ID which is used for the HMAC key.
4. From the Secure Access admin console, select Authentication > Auth. servers and
enter the username and password of the NSM admin using the credentials you entered
on NSM in the applicable authentication server. Use the NSM username and password
that you entered in the NSM UI Client.
NOTE: Only password-based authentication servers can be used. One-time
password authentication is not supported.
5. Select Administrators > Admin Roles and create a DMI agent administrator role.
6. Select Administrators > Admin Realms and create a new DMI agent admin realm for
the DMI agent on the Secure Access device and use role mapping to associate the
DMI agent role and realm.
7. On the NSM interface, select the Domain menu and choose the domain to which the
Secure Access device will be added.
8. In Device Manager, click the Add icon and select Device to open the Add Device wizard,
and enter the applicable information required to add a Secure Access device to NSM.
See the Administration Guide.
28
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
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.
9. After you have added the Secure Access device to NSM, select System > Configuration
> DMI Agent on the Secure Access admin console.
10. Under DMI connection, select the:
•
Inbound Enabled check box if you are using an SSH secure shell Command Line
Interface (CLI) to manage the Secure Access device. The Secure Access device 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 Secure Access device to
communicate with NSM.
NOTE: When you enable or disable a connection, it takes a few minutes
for the connection state to be updated.
11. Under DMI settings for inbound connections, enter the TCP port in which the Secure
Access device should accept connections. This TCP port should not be used by any
other Secure Access processes. We recommend you use the default port or a port
number larger than 1024.
12. 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.
13. Select the Admin realm that you have configured for the DMI agent.
14. If you do not want DMI logging for both inbound and outbound DMI connections,
uncheck the DMI Logging checkbox. By default, DMI logging is enabled.
The Secure Access device initiates a TCP connection to NSM. After the Secure Access
device is identified to NSM through the HMAC key and device ID hash, the Secure Access
device and NSM negotiate an SSH tunnel, and NSM requests authentication to the Secure
Access device 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.
Copyright © 2013, Juniper Networks, Inc.
29
Junos Pulse Secure Access Service Administration Guide
To add a Secure Access cluster in NSM, you first add the cluster, then you add each
member. Adding a member is similar to adding a standalone Secure Access device. 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 Secure Access Service
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
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 Secure Access Service, 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 Secure Access Service configuration tree.
30
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
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 Secure Access Service 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 Secure Access Service. 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 Secure Access Service.
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.
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 Secure Access Service 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 30
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 Secure
Access Service.
Copyright © 2013, Juniper Networks, Inc.
31
Junos Pulse Secure Access Service Administration Guide
To create a link from a Secure Access Service configuration tree to a shared object
containing a custom sign-in access page:
1.
In the Device Manager, double-click the Secure Access Service 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.
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 Secure Access Service configuration tree to a shared object
containing a custom sign-in meeting page:
1.
In the Device Manager, double-click the Secure Access Service 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 311
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.
32
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
To create a link from a Secure Access Service configuration tree to a shared object
containing an antivirus (AV) liveupdate file:
1.
In the Device Manager, double-click the Secure Access Service 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.
To create a link from a Secure Access Service configuration tree to a shared object
containing an AV patch liveupdate file:
1.
In the Device Manager, double-click the Secure Access Service 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 352
Importing Endpoint Security Assessment Plug-in (ESAP) Packages with NSM
The Endpoint Security Assessment Plug-in (ESAP) on the Secure Access Service checks
third-party applications on endpoints for compliance with the predefined rules you
configure in a Host Checker policy.
To download the Endpoint Security Assessment Plug-in from the Juniper Networks
Customer Support Center to your NSM client computer:
1.
Open the following page:
http://www.juniper.net/support/products/esap/
2. Click the Software tab.
3. Navigate to the ESAP release you want and click the link to download the package
file to your computer.
Copyright © 2013, Juniper Networks, Inc.
33
Junos Pulse Secure Access Service Administration Guide
To create a link from a Secure Access Service configuration tree to a shared object
containing an ESAP package:
1.
In the Device Manager, double-click the Secure Access Service 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.
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
34
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
package-name.policy-name. For example, to enforce the FileCheck policy in the
myPestPatrol package, use myPestPatrol.FileCheck.
Related
Documentation
•
Host Checker and Trusted Network Computing on page 352
Linking to a Third-Party Host Checker Policy Shared Object with NSM
To create a link from a Secure Access Service configuration tree to a shared object
containing a third-party host checker policy:
1.
In the Device Manager, double-click the Secure Access Service 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 352
Linking to a Secure Virtual Workspace Wallpaper Image Shared Object with NSM
To create a link from a Secure Access Service configuration tree to a shared object
containing a secure virtual workspace wallpaper image:
1.
In the Device Manager, double-click the Secure Access Service 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.
Copyright © 2013, Juniper Networks, Inc.
35
Junos Pulse Secure Access Service Administration Guide
Related
Documentation
•
Enabling the Secure Virtual Workspace on page 415
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 Secure Access Service. 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 the Secure Access Service 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 a Secure Access Service configuration tree to a shared object
containing a Java applet:
1.
In the Device Manager, double-click the Secure Access Service 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 431
•
Task Summary: Hosting Java Applets on page 432
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
Importing a Custom Citrix Client .cab File with NSM
The custom Citrix client file enables you to provision the Citrix client from the Secure
Access Service instead of requiring that it be pre-installed on end-user machines or
downloaded from some other web server.
To create a link from the Secure Access Service configuration tree to a shared object
containing a Custom Citrix .cab file:
In the Device Manager, double-click the Secure Access Service 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 128
•
Creating Resource Profiles Using Citrix Web Applications on page 449
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 Secure Access
Service devices.
NOTE: This topic provides a brief overview of Junos Pulse. For complete
information on Junos Pulse, see the Junos Pulse Administration Guide.
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
the Secure Access Service, 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 resources within the network that are protected by Juniper Networks devices
Copyright © 2013, Juniper Networks, Inc.
37
Junos Pulse Secure Access Service Administration Guide
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 Secure Access Service 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.
NOTE: Location awareness does not work when split tunneling is disabled.
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.
NOTE: Certificate-based authentication may fail from a Windows mobile
device if both expired and valid certificates with the same common name
(CN) are present on the device.
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.
38
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
Secure Access Service Gateway Deployment Options
On the network side, the Junos Pulse configuration is integrated into the admin console
of supported gateways. On the Secure Access Service, you can deploy all of the
connections and components required for clients to connect to any supported gateway.
Secure Access Service supports the following deployment options:
•
Web install—Create all of the settings that an endpoint needs for connectivity and
services, and install the software on endpoints that connect to the access gateway
Web portal and successfully log in to the gateway. The Secure Access Service include
a default client connection set and client component set. The default settings enable
you to deploy Junos Pulse to users without creating new connection sets or component
sets. The default settings for the client permit dynamic connections, install only the
components required for the connection, and permit an automatic connection to the
Secure Access Service to which the endpoint connects.
•
Default installer—A default Junos Pulse installer package (in both .msi and .exe formats)
is included in the access gateway software. You can distribute this default installer to
endpoints, install it, and then let users create their own connections. Or, after installing
the default Junos Pulse package, users can automatically install dynamic connections
by browsing to the user Web portal of an access gateway where a dynamic connection
has been made available. A dynamic connection is a predefined set of connection
parameters that enables a client to connect to a specific server. If the user is able to
log in to the access gateway’s user Web portal, the connection parameters are
downloaded and installed on the Junos Pulse client.
•
Preconfigured installer—Create the connections that an endpoint needs for connectivity
and services, download the settings file (.jnprpreconfig), download default Pulse .msi
installation program, and then run the .msi installation program by using an msiexec
command with the settings file as an option. You can use the msiexec command to
deploy Pulse using a standard software distribution process, such as SMS/SCCM.
NOTE: Junos Pulse for mobile devices uses a different deployment model
than Pulse for Windows endpoints. For information about Pulse on mobile
devices, see the Junos Pulse Administration Guide.
Platform Support
The following Juniper Networks devices support Junos Pulse:
•
Unified Access Control 4.0 or later
•
Secure Access Service 7.0 or later
•
App Acceleration Series JWOS 6.1 or later
•
SRX Series 9.5
The Junos Pulse client is supported on Windows XP SP3 32, Windows Vista SP1/2 32
and 64, and Windows 7.
Copyright © 2013, Juniper Networks, Inc.
39
Junos Pulse Secure Access Service Administration Guide
NOTE: The Junos Pulse for Windows client is not compatible with the Instant
Virtual System (IVS) feature of Secure Access Service. In an IVS system, a
Pulse client always takes its IP address from the root Secure Access Service
address pool instead of using the pool defined for the virtualized Secure
Access Service.
Related
Documentation
•
Junos Pulse Configuration Overview on page 40
•
Client Connection Set Options on page 43
•
Creating a Client Connection Set on page 47
•
Configuring a Role for Junos Pulse on page 41
Junos Pulse Configuration Overview
Configure the Secure Access Service and the Junos Pulse settings on the gateway so
that when users request authentication, they are assigned a role based on the role
mappings and optional security profile that you create. Access to specific resources is
permitted only for users and devices that provide the proper credentials for the realm,
that are associated with the appropriate roles, and whose endpoints meet security
restrictions. If a user attempts to connect to the network from an endpoint that does not
comply with the security restrictions you have defined, the user cannot access the realm
or role.
As you plan your Pulse configuration, be sure you know how you want to deploy Junos
Pulse. You can use one or more of the following Junos Pulse deployment options:
40
•
Use the defaults or make changes to the Junos Pulse default component set and
default connection set, and then download and distribute Pulse by having users log in
to the gateway’s user Web portal and be assigned to a role. After the installation is
complete, users have all the connections they need to access network resources.
•
Create connections that an endpoint needs for connectivity and services, download
the Pulse settings file (.jnprpreconfig), download default Pulse .msi installation program,
and then run the .msi installation program by using an msiexec command with the
settings file as an option. You can use the msiexec command to deploy Pulse using a
standard software distribution process, such as SMS/SCCM.
•
Distribute Junos Pulse with no preconfiguration. You can download the default Junos
Pulse installation file in either .msi or .exe format from the Secure Access Service, and
then distribute the file to endpoints using your organization’s standard software
distribution methods. Because the installer does not contain preconfigured connections,
users must define network connections manually. Or you can create dynamic
connections on each access gateway. These connections are automatically downloaded
to the installed Pulse client when users provide their login credentials to the gateway’s
user Web portal.
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
The following tasks summarize how to configure Junos Pulse on the Secure Access
Service:
Related
Documentation
•
Create and assign user roles to control who can access different resources and
applications on the network. If you are converting your access environment from
agentless or a VPN Tunneling environment, you should create new roles that are specific
for Junos Pulse.
•
Define security restrictions for endpoints with Host Checker policies.
•
Define user realms to establish authentication domains. If you are converting your
access environment from agentless or a NC environment, typically you can use your
existing realms.
•
Associate the roles with appropriate realms to define your access control hierarchy
using role mapping.
•
Define Junos Pulse component sets, connection sets, and connections.
•
Deploy Junos Pulse to endpoints.
•
Junos Pulse Overview on page 37
•
Client Connection Set Options on page 43
•
Creating a Client Connection Set on page 47
•
Creating a Client Component Set on page 52
•
Configuring a Role for Junos Pulse on page 41
Configuring a Role for Junos Pulse
A user role defines 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 can 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 following procedure describes the role configuration options that apply to a role that
employs Junos Pulse.
To create a role for Junos Pulse endpoints:
1.
Select Users > User Roles > New User Role in the admin console, or select an existing
role.
2. Enter a name for the role and, optionally, a description. This name appears in the list
of Roles on the Roles page.
3. Click Save Changes. Role configuration tabs appear.
Configuring Role Options for Junos Pulse
Copyright © 2013, Juniper Networks, Inc.
41
Junos Pulse Secure Access Service Administration Guide
All of the options for role configuration tabs are described in Access Management
Framework. The role options that are specific to Junos Pulse are located in the Network
tab.
To configure a role for Junos Pulse endpoints:
1.
From the admin console, select Users > User Roles.
2. Click the role you want to configure and then click the VPN Tunneling tab.
3. Under Client Options, select Junos Pulse.
4. Under Split Tunneling Options, select your options:
•
Split Tunneling—Split tunneling options let you define how network traffic flows on
the client.
•
Enable— Pulse modifies routes on the client so that traffic meant for the corporate
intranet uses the virtual adapter created by Pulse (the Pulse tunnel) and all other
traffic goes through the local physical adapter.
•
Disable—When the Pulse session is established, predefined local subnet and
host-to-host routes that might cause split-tunneling behavior are removed, and
all network traffic from the client goes through the Pulse tunnel. With split
tunneling disabled, users cannot access local LAN resources during an active VPN
session.
NOTE: Location awareness behavior is affected by split tunneling
configuration. For example, if a location awareness rule relies on a
address resolution made on the physical adapter, and split tunneling
is disabled, the rule always resolves to FALSE after Pulse establishes
the connection.
•
Route Override—You can define which routing table takes precedence:
•
Yes—The route table associated with the Pulse virtual adapter take precedence.
Pulse overwrites the physical interface routes if there is conflict between the
Pulse virtual adapter and the physical adapters. Pulse restores the original routes
when the connection is ended.
•
•
No—Current IP routes take precedence.
Route Monitor—Pulse can monitor the route tables and take appropriate action.
•
Yes—Pulse ends the connection if a change is made to the routing tables.
•
No—Route tables are allowed to change on the client endpoint.
5. Under Auto Launch Options, select the Auto-launch check box to activate Pulse
automatically when the endpoint is started.
6. In the Session scripts area, optionally specify a location for the following:
•
Windows: Session start script—Specify a script to run for users assigned to the role
after Junos Pulse connects with the Secure Access Service. For example, you can
42
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
specify a script that maps network drives on an endpoint to shares on protected
resources.
•
Windows: Session end script—Specify a script to run for users assigned to the role
after Junos Pulse disconnects from the Secure Access Service. For example, you
can specify a script that disconnects mapped network drives. If there is no start
script defined, or the start script has not been run, the end script does not run.
7. Click Save Changes.
Host Checker options allow you to enable Host Checker policies, to choose one or more
policies for the role, and to specify whether the endpoint must meet all or just one of the
selected Host Checker policies. See Endpoint Defense for complete information on
configuring endpoint security settings.
To configure Host Checker for a selected role:
1.
For a selected role, select General > Restrictions > Host Checker.
2. Select the check box Allow users whose workstations meet the requirements specified
by these Host Checker policies.
3. Click Add to move Host Checker policies from the Available Policies list to the Selected
Policies list.
4. Select the check box Allow access to the role... to grant access if the endpoint passes
any of the selected Host Checker policies.
5. Click Save Changes.
Related
Documentation
•
Client Connection Set Options on page 43
•
Creating a Client Connection Set on page 47
•
Creating a Client Component Set on page 52
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 2 on page 43 details the available options for a connection set.
Table 2: 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.
Copyright © 2013, Juniper Networks, Inc.
43
Junos Pulse Secure Access Service Administration Guide
Table 2: Configurable Parameters for Junos Pulse Connection
Sets (continued)
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.
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.
Support Non-broadcast SSID—Allows users to connect to a non-broadcast
wireless network from the Pulse interface.
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.
SSL VPN or (UAC) L3 options:
Allow user to override connection policy—Allows a user to override the
connection policy by manually connecting or disconnecting.
44
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
Table 2: Configurable Parameters for Junos Pulse Connection
Sets (continued)
Support Remote Access (SSL VPN) or LAN Access (UAC) on this
connection—This option specifies that the connection is used for network
connectivity. This option must be selected if this connection is for Pulse Access
Control Service. If the connection is for Pulse Secure Access Service, you can
disable this check box and use the connection for accessing Pulse
Collaboration meetings only by also selecting Enable Junos Pulse Collaboration
integration on this connection.
Enable Junos Pulse Collaboration integration on this connection—This option
specifies that the connection is used for Junos Pulse Collaboration meetings.
(Formerly called Secure Meeting.) This option must be disabled if this
connection is for Pulse Access Control Service. If the connection is for Pulse
Secure Access Service, you can enable this check box and use the connection
for accessing Junos Pulse Collaboration meetings.
You can enable a connection for Junos Pulse Collaboration to be used for
remote access only, for Junos Pulse Collaboration integration only, or for both
remote access and Junos Pulse Collaboration integration. If you do not select
either option, an error occurs when you save changes to this connection.
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.
SRX 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.
App Acceleration 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 Pulse Application
Acceleration server can form an adjacency for application acceleration only
if they belong to the same community as identified by the community string.
When you create an App Acceleration connection, be sure the community
string for the connection matches the community string defined on Pulse
Application Acceleration server.
If you create an SSL VPN or (UAC) L3 or a SRX 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:
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.
Copyright © 2013, Juniper Networks, Inc.
45
Junos Pulse Secure Access Service Administration Guide
Table 2: Configurable Parameters for Junos Pulse Connection
Sets (continued)
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
the Secure Access Service 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:
•
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.
Connection is Established Settings
For all connection types, you specify how the connection is established. The options vary
according to the type of connection. These settings also enable you to specify a connection
as a machine authentication connection or a credential provider connection.
NOTE: A Pulse connection that is used for machine authentication has some
special considerations. See“Junos Pulse Connection Realm and Role
Preferences for Machine Authentication” on page 290 for more information.
The settings Connections can be established using the following options:
46
•
Manually by the user—(All connection types.) 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 user interface to select a connection.
•
Automatically after user signs into the desktop—(All connection types.) When the
endpoint is started and the user has logged in to the endpoint, the Junos Pulse client
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
software connects automatically. For App Acceleration connections, automatically is
the default because Pulse forms an adjacency with Pulse Application Acceleration
Service automatically if the service is available.
NOTE: All connections on an endpoint that are configured to start
automatically attempt to connect to their target networks at startup time.
To avoid multiple connection attempts, be sure that only one connection
is configured to start automatically or configure location awareness rules.
•
Automatically when the machine starts. Machine credentials used for
authentication—(SSL VPN or UAC (L3) connections only) Enables machine
authentication, which requires that Active Directory is used as the authentication server
and that machine credentials are configured in Active Directory.
NOTE: If the machine and user have different roles, each role should map
to the same connection set. Otherwise after the user connects, the existing
connection set might be replaced.
Related
Documentation
•
Automatically when the machine starts. Connection is authenticated again when
the user signs in into the desktop—(SSL VPN or UAC (L3) connections only) Enables
machine authentication for the initial connection. After the user connects with user
credentials, the machine authentication is dropped. When the user logs off, the machine
authentication connection is restored.
•
Automatically during desktop authentication. User is presented with the Junos Pulse
credential tile at the logon screen—(SSL VPN or UAC (L3) connections only) This
option enables Pulse client interaction with the credential provider software on the
endpoint.
•
Creating a Client Connection Set on page 47
•
Creating a Client Component Set on page 52
•
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.
NOTE: You must enter a name, otherwise you cannot create a connection
set.
Copyright © 2013, Juniper Networks, Inc.
47
Junos Pulse Secure Access Service Administration Guide
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
7. Under connections, click New to define a new connection.
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
•
SSL VPN or (UAC) L3
•
SRX
•
App Acceleration
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.
•
Support Non-broadcast SSID—Select this option to allow users to connect to
non-broadcast networks.
11. Click Save Changes.
12. If you select SSL VPN or (UAC) L3 after Options, select or clear the check box for each
of the following items:
•
Allow user to override connection policy
•
Support Remote Access (SSL VPN) or LAN Access (UAC) on this connection—This
option must be selected if this connection is for Pulse Access Control Service. If the
connection is for Pulse Secure Access Service, you can disable this check box and
use the connection for accessing Pulse Collaboration meetings only by also selecting
Support Remote Access (SSL VPN) or LAN Access (UAC) on this connection.
•
Support Remote Access (SSL VPN) or LAN Access (UAC) on this connection—This
option must be disabled if this connection is for Pulse Access Control Service. If the
connection is for Pulse Secure Access Service, you can enable this check box and
use the connection for accessing Pulse Collaboration meetings.
48
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
•
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 SRX, 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.
16. If you select App Acceleration, select the Connect Automatically check box to permit
the client to automatically connect to App Acceleration 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 43
•
Junos Pulse Component Set Options on page 51
•
Creating a Client Component Set on page 52
•
Configuring Connection Rules for Location Awareness on page 49
Configuring Connection Rules for Location Awareness
The location awareness feature enables a Pulse client to recognize its location and then
make the correct connection. For example, a Pulse client that is started in a remote
location automatically connects to the Secure Access Service. But that same client
automatically connects to an IC Series appliance when it is started in the corporate office.
NOTE: Location awareness and session migration are similar because they
both simplify connectivity for the user, but they do so under different
conditions. With location awareness, the Pulse client makes a decision on
where to connect when a user logs in to the computer. Session migration
occurs when the user puts the computer into a stand by or hibernate mode
without first logging off, and then opens the computer in a different network
environment. Location awareness enables the Pulse client to intelligently
start a new session. Session migration enables Pulse servers to intelligently
migrate an existing session.
Location awareness relies on rules you define for each connection. If the conditions
specified in the rules are true, Pulse attempts to make the connection. To set up the
location awareness rules that select among many connections, you must define location
Copyright © 2013, Juniper Networks, Inc.
49
Junos Pulse Secure Access Service Administration Guide
awareness rules for each connection. Each location awareness rule is based on the
endpoint’s ability to reach an IP address or resolve a DNS name over a specified network
interface.
NOTE: Location awareness behavior is affected by split tunneling
configuration. For example, if a location awareness rule relies on a address
resolution made on the physical adapter, and split tunneling is disabled, the
rule always resolves to FALSE after Pulse establishes the connection.
NOTE: Connections can be set to manual, automatic, or controlled by location
awareness rules. When the user logs in, the Pulse client attempts every
connection in its connections list that is set to automatic or controlled by
location awareness rules.
To configure location awareness rules:
1.
If you have not already done so, create a connection or open an existing connection.
2. In the Connection is established area, select According to location awareness rules,
and then click New.
3. Enter a name for this rule.
4. In the Action list, select one of the following:
•
DNS server—Connect if the DNS server associated with the endpoint's network
properties is (or is not) set to a certain value or set of values. Specify the DNS server
IP address in the IP address box. Also specify a network interface on which the
condition must be satisfied:
•
Physical—The condition must be satisfied on the physical interfaces on the
endpoint.
•
Junos Pulse—The condition must be satisfied on the virtual interface that Junos
Pulse creates when it establishes a connection.
•
•
Any—Use any interface.
Resolve address—Connect if the configured host name or set of host names is (or
is not) resolvable by the endpoint to a particular IP address. Specify the host name
in the DNS name box and the IP address or addresses in the IP address box. Also
specify a network interface on which the condition must be satisfied.
50
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
NOTE: The Pulse client software evaluates IP and DNS policies on
network interface changes. DNS lookups occur on DNS configuration
changes or when the time-to-live setting (10 minutes) expires for a
particular host record. If Pulse cannot resolve the host for any reason,
it polls the configured DNS server list every 30 seconds. If the host had
been resolved successfully previously and the time-to-live timer has
not expired, the polling continues until the timer expires. If the host had
not been resolved successfully previously, the resolution attempt fails
immediately.
•
Endpoint Address—Connect if a network adapter on the endpoint has an IP address
that falls within or outside of a range or a set of ranges. Specify the IP address or
addresses in the IP address box. Also specify a network interface on which the
condition must be satisfied.
5. Click Save Changes.
After you create the rule or rules, you must enable each rule you want to use for the
connection. To enable a negative form of a rule, use a custom version of the rule. To
enable location awareness rules:
1.
In the list of connection awareness rules for a connection, select the check box next
to each rule you want to enable.
2. To specify how to enforce the selected location awareness rules, select one of the
following options:
•
All of the above rules—The condition is TRUE and the connection is attempted only
when all selected location awareness rules are satisfied.
•
Any of the above rules—The condition is TRUE and the connection is attempted
when any select location awareness rule is satisfied.
•
Custom—The condition is TRUE and the connection is attempted only when all
selected location awareness rules are satisfied according to the Boolean logic you
specify in the Custom box. Use the Boolean condition to specify a negative location
rule. For example, connect to the Secure Access Service when Rule–1 is false and
Rule–2 is true. The boolean logic in the custom box would be: NOT Rule-1 AND
Rule-2. The accepted Boolean operators are AND, OR, NOT, and the use of ( ).
3. Click Save Changes.
Related
Documentation
•
Creating a Client Connection Set on page 47
Junos Pulse Component Set Options
A Junos Pulse component includes specific software components that provide Pulse
connectivity and services.
Copyright © 2013, Juniper Networks, Inc.
51
Junos Pulse Secure Access Service Administration Guide
A component set options includes the following options:
•
All components—Includes all components. 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. Use the All components option only when
you want client endpoints to be able to connect to all supported Pulse servers and to
be able to use application acceleration. When you include the App Acceleration
component, the disk space requirement for the Junos Pulse client installation increases
to 300 MB.
•
No components—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 an IC or Secure
Access Service connection, the component set includes only the components required
to connect to Pulse Access Control Service or Pulse Secure Access Service. The default
is Minimal components, which provides all needed components for the selected
connections and limits the size of the Junos Pulse installation file.
NOTE: Selecting Pulse components applies to a Web installation only. The
preconfigured installer always installs all components unless you specify
the specific components you want using command line options.
Related
Documentation
•
Creating a Client Component Set on page 52
•
Configuring a Role for Junos Pulse on page 41
•
The Client Installer Package
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 > Pulse > Connections
and create a new connection set. Alternately, use the default client configuration,
which permits dynamic connections, supports the outer username anonymous, and
allows the client to connect automatically to an IC Series or Secure Access Service
device.
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.
52
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
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.
8. Click Save Changes.
9. After you create a component set, distribute the client 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 are changed even
though the list of components has not, the existing configuration on the endpoint is
replaced immediately 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 one that determines which client (component
set) is deployed.
Related
Documentation
•
Client Connection Set Options on page 43
•
Creating a Client Connection Set on page 47
•
Junos Pulse Component Set Options on page 51
•
The Client Installer Package
•
Configuring a Role for Junos Pulse on page 41
Junos Pulse Client Installation Overview
The Secure Access Service include a default connection set and a default component
set. These defaults enable you to deploy Junos Pulse to users without creating new
connection sets or component sets. The default settings for the client permit dynamic
connections, install only the components required for the connection, and permit an
automatic connection to the Secure Access Service to which the endpoint connects.
In all deployment scenarios, you must have already configured authentication settings,
realms, and roles.
Copyright © 2013, Juniper Networks, Inc.
53
Junos Pulse Secure Access Service Administration Guide
You can deploy Junos Pulse to endpoints from Secure Access Service in the following
ways:
•
Web install—With a Web install, users log in to the access gateway’s Web portal and
are assigned to a role that supports a Pulse installation. When a user clicks the link to
run Junos Pulse, the default installation program adds Pulse to the endpoint and adds
the default component set and the default connection set. If you do not make any
changes to the defaults, the endpoint receives a Pulse installation in which a connection
to the gateway is set to connect automatically. You can edit the default connection
set to add connections of other gateways and change the default options.
NOTE: A Web install requires that the user have Java installed and enabled
for an installation through the Firefox browser or ActiveX enabled for an
installation through Internet Explorer. If the browser does not meet this
requirement, the user receives a descriptive message at the beginning of
the installation process.
•
Preconfigured installer—The preconfigured installer enables you to specify all
connections that endpoints need, and then to create an installation program that you
can distribute to endpoints using your local organization’s standard software distribution
method (such as Microsoft SCCM/SMS). After Pulse is installed on an endpoint, the
user does not need to do any additional configuration.
•
Default installer—You can download the default Pulse installation program in either
.exe or .msi format and distribute it to endpoints using your local organization’s standard
software distribution method (such as Microsoft SMS/SCCM). The Junos Pulse client
software is installed with all components and no connections. After users install a
default Pulse installation, they can add new connections manually through the Pulse
client user interface or by using a browser to access a gateway’s Web portal. For the
latter, the gateway’s dynamic connection is downloaded automatically and the new
connection is added to the Pulse client’s connections list.
Installing the Junos Pulse Client from the Web
For a Web install, you direct users to the Web interface of the access gateway. After a
successful login, a user is assigned to a role that includes an automatic download and
installation of the Junos Pulse client software.
NOTE: A Web install requires that the user have Java installed and enabled
for an installation through the Firefox browser or ActiveX enabled for an
installation through Internet Explorer. If the browser does not meet this
requirement, the user receives a descriptive message at the beginning of the
installation process.
The default Junos Pulse installation settings includes minimal components and a
connection to the access gateway. If you want a Web install that has customized settings,
you can do any of the following:
54
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
•
Edit the default connection set and add new connections. The default installer uses
the default component set which includes the default connection set.
•
Create a new connection set and edit the default component set to include the new
connection set.
•
Edit the role to specify a component set that includes the connections you want for
the default installation.
Installing the Junos Pulse Client Using a Preconfiguration File
The following procedures apply to Windows installations only.
After you create client connection sets and specify the connections to include within a
client component set, you can create a preconfiguration file with all of the connections
you want to distribute with the Pulse client. You specify the preconfiguration file as an
option when you run the Pulse .msi installer program using an msiexec
(windows\system32\msiexec.exe) command.
NOTE: The preconfigured installer always installs all components unless
you specify the specific components you want using ADDLOCAL command
line options. The components installed by a preconfigured installer are
determined by ADDLOCAL options and not by the component set you select
when you create the preconfiguration file.
NOTE: When you run msiexec, you should append /qn or /qb (msiexec
command line options) to the command line to suppress the installation
program user interface. For example, the user interface lets the user choose
a complete installation or a custom installation, which can override the
components you specify with ADDLOCAL options. If the user selects
Complete, the msiexec programs ignores the ADDLOCAL options in the
command line and installs all components. The /qn option specifies a silent
install, no user interface appears. The /qb option also hides the user interface
but it displays a progress bar.
To create a preconfigured Pulse installer for distribution to Windows endpoints:
1.
Select Users > Junos Pulse > Connections and create a connection set with the
connections that you want to distribute.
2. Select Users > Junos Pulse > Components.
3. If necessary, create a new component set with the connection sets you want to
distribute.
It does not matter which component option you select, All components, No components,
or Minimal components. You can specify the specific components to install in the
msiexec command line.
Copyright © 2013, Juniper Networks, Inc.
55
Junos Pulse Secure Access Service Administration Guide
4. Select the check boxes next to the component sets that you want to distribute.
5. Click Download Installer Configuration.
You are prompted to save the preconfiguration. You can also specify the name of the
target Pulse server for the connections, which enables you to create configuration
files that are the same except for the target server.
The default file name of the .jnprpreconfig file is the name of the selected component
set. Make note of the file name and location where you put the file. The
preconfiguration file must be available to the clients either through a network share
or distributed along with the Junos Pulse .msi installer file.
6. Select Maintenance > System > Installers.
If necessary for your environment, download and install the Juniper Installer Service.
To install Pulse, users must have appropriate privileges. The Juniper Installer Service
allows you to bypass privilege restrictions and allow users with limited privileges to
install Pulse.
7. Download the appropriate Junos Pulse installer for your Windows environment:
•
Junos Pulse Installer (32-bit)
•
Junos Pulse Installer (64-bit)
Installing the Pulse Client Using Advanced Command Line Options
The Junos Pulse installer includes the Pulse client and all of the software components
for all of the Pulse services. The preconfiguration file contains the definitions of the Pulse
connections that provide client access to specific Pulse servers and services.
You run the Pulse preconfigured installer program with msiexec (the command line for
launching .msi programs on Windows platforms) and specify the following options.
NOTE: Command line options (CONFIGFILE and ADDLOCAL) are case
sensitive and must be all caps.
•
CONFIGFILE—This property specifies a configuration file to be imported into Pulse
during installation. The property must include the full path to the configuration file. For
example:
msiexec -i JunosPulse.msi CONFIGFILE=c:\temp\myconfiguration.jnprpreconfig
•
ADDLOCAL—This property specifies which features and feature options (sub-features)
to install when you want to install only specific Pulse features. If you do not specify
ADDLOCAL options, all Pulse components are installed. A feature comprises the
components required to support client connections. When you use ADDLOCAL, you
should append msiexec options /qn or /qb to the command line to suppress the
installation program user interface.
Feature and sub-feature names are case sensitive. To specify multiple features in a
single command, separate each feature with a comma.
56
Copyright © 2013, Juniper Networks, Inc.
Chapter 2: Introduction to Secure Access Service
ADDLOCAL features:
•
PulseSA—Pulse components required for Pulse Secure Access Service.
•
PulseUAC—Pulse components required for Pulse Access Control Service.
•
PulseSRX—Pulse components required for SRX Series Gateways.
•
PulseAppAccel—Pulse components required for Pulse Application Acceleration
Service.
Optional sub-features:
•
Pulse8021x—Available with PulseUAC. Includes 802.1x connectivity components.
•
SAEndpointDefense—Available with PulseSA. Includes Enhanced Endpoint Security
components for connections to Pulse Secure Access Service.
•
SAHostChecker—Available with PulseSA. Includes Host Checker components for
connections to Pulse Secure Access Service.
•
UACEndpointDefense—Available with PulseUAC. Includes Enhanced Endpoint
Security components for connections to Pulse Access Control Service.
•
UACHostChecker—Available with PulseUAC. Includes Host Checker components
for connections to Pulse Access Control Service.
•
UACIPSec—Available with PulseUAC. Includes components required to connect
to Pulse Access Control Service using IPSec from 32-bit Windows endpoints. This
feature is available in the 32-bit MSI only.
•
UACIPSec64—Available with PulseUAC. Includes components required to connect
to Pulse Access Control Service using IPSec from 64-bit Windows endpoints. This
feature is available in the 64-bit MSI only.
Examples
When you use ADDLOCAL, you should append msiexec options /qn or /qb to the
command line to suppress the installation program user interface. These examples use
/qb.
To install PulseUAC with 802.1x and Enhanced Endpoint Security support on a Windows
32-bit endpoint using a configuration file, use the following command line:
msiexec -i JunosPulse.x86.msi CONFIGFILE=c:\pulse\Pulse-Connection-no.jnprpreconfig
ADDLOCAL=PulseUAC,Pulse8021x,UACEndpointDefense /qb
To install PulseSA on a 32-bit Windows endpoint using a configuration file, use the
following command line:
msiexec -i JunosPulse.x86.msi CONFIGFILE=c:\temp\myconfiguration.jnprpreconfig
ADDLOCAL=PulseSA /qb
To install PulseSA with Enhanced Endpoint Security and Host Checker on a 64-bit
Windows endpoint using a configuration file, use the following command line:
msiexec -i JunosPulse.x64.msi CONFIGFILE=c:\temp\myconfiguration.jnprpreconfig
ADDLOCAL=PulseSA,SAEndpointDefense,SAHostChecker /qb
Copyright © 2013, Juniper Networks, Inc.
57
Junos Pulse Secure Access Service Administration Guide
To install PulseAppAccel on a 64-bit Windows endpoint using a configuration file, use
the following command line:
msiexec -i JunosPulse.x64.msi CONFIGFILE=c:\temp\myconfiguration.jnprpreconfig
ADDLOCAL=PulseAppAccel /qb
To install all Pulse components on a 64-bit Windows endpoint using a configuration file,
use the following command line:
msiexec -i JunosPulse.x64.msi CONFIGFILE=c:\temp\myconfiguration.jnprpreconfig /qb
Repairing a Pulse Installation on a Windows Endpoint
Junos Pulse uses an MSI installer, which supports a repair function. If problems with Pulse
on a Windows endpoint indicate missing or damaged files or registry settings, the user
can easily run the installation repair program. The repair program performs a reinstallation
and replaces any missing files. The repair program does not install any files that were
not part of the original installation. For example, if the file that holds Pulse connection
configurations is damaged, the file installed by the repair program does not replace any
Pulse connections that were created by the user or deployed to the endpoint after the
original Pulse installation.
To repair a Pulse installation on a Windows endpoint:
1.
On the Windows endpoint where Pulse is installed, click Start > Programs > Juniper
Networks > Junos Pulse > Repair Junos Pulse.
2. Follow the prompts for the installation wizard.
When the program is finished, you might be prompted to reboot the system.
Related
Documentation
58
•
Creating a Client Connection Set on page 47
•
Creating a Client Component Set on page 52
Copyright © 2013, Juniper Networks, Inc.
PART 2
Access Management Framework
•
General Access Management on page 61
•
User Roles on page 95
•
Resource Profiles on page 117
•
Virtual Desktop Resource Profiles on page 127
•
Resource Policies on page 133
•
Authentication and Directory Servers on page 143
•
SAML Single Sign-on on page 221
•
Authentication Realms on page 283
•
Sign-In Policies on page 299
•
Single Sign-On on page 313
•
Synchronizing User Records on page 341
Copyright © 2013, Juniper Networks, Inc.
59
Junos Pulse Secure Access Service Administration Guide
60
Copyright © 2013, Juniper Networks, Inc.
CHAPTER 3
General Access Management
•
Access Management Overview on page 61
•
Policies, Rules & Restrictions, and Conditions Overview on page 62
•
Policies, Rules & Restrictions, and Conditions Evaluation on page 64
•
Dynamic Policy Evaluation on page 67
•
Specifying Source IP Access Restrictions on page 69
•
Specifying Browser Access Restrictions on page 72
•
Specifying Certificate Access Restrictions on page 74
•
Specifying Password Access Restrictions on page 75
•
Specifying Session Limits on page 76
•
IF-MAP Federation Overview on page 79
•
IF-MAP Federation Details on page 81
•
Task Summary: Configuring IF-MAP Federation on page 84
•
Configuring IF-MAP Server Settings on page 84
•
Configuring the IF-MAP Federation Client on page 85
•
IF-MAP Federation Network Timing Considerations on page 85
•
Session-Export and Session-Import Policies on page 86
•
Configuring Session-Export Policies on page 88
•
Session-Import Policies on page 90
•
Troubleshooting the IF-MAP Federation Network on page 91
•
Viewing Active Users on the IF-MAP Client on page 91
•
Trusted Server List on page 92
Access Management Overview
The Secure Access Service 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
Secure Access Service) 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 Secure Access Service, to gain access to features, and
Copyright © 2013, Juniper Networks, Inc.
61
Junos Pulse Secure Access Service Administration Guide
even to access specific URLs, files, and other server resources. The Secure Access Service
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 Secure Access Service
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 Secure Access Service access management framework is available on all Secure
Access Service products. The access management features, including realms, roles,
resource policies, and servers, are the base of the platform on which all Secure Access
Service products are built.
Related
Documentation
•
User Roles Overview on page 95
•
Authentication Realm Overview on page 283
Policies, Rules & Restrictions, and Conditions Overview
The Secure Access Service 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
Secure Access Service) 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 Secure
Access Service 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 Secure Access Service 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
Secure Access Service that the Secure Access Service uses to map users to one or
more user roles.
•
Role mapping rules—conditions a user must meet for the Secure Access Service 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 the Secure Access Service
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
62
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: General Access Management
Secure Access Service checks the authentication policy defined for the chosen realm.
The user must meet the security requirements you define for a realm's authentication
policy or else the Secure Access Service 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 Secure Access
Service forwards the user's credentials to the appropriate authentication server. If this
server successfully authenticates the user, then the Secure Access Service 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 Secure Access Service 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
Secure Access Service maps the user to the role. When a user makes a request to the
backend resources available to the role, the Secure Access Service 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 Secure Access Service 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 Secure Access Service 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 Secure Access Service
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.
Copyright © 2013, Juniper Networks, Inc.
63
Junos Pulse Secure Access Service Administration Guide
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,
the Secure Access Service 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 Secure Access Service
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 64
•
Dynamic Policy Evaluation on page 67
Policies, Rules & Restrictions, and Conditions Evaluation
The following diagram illustrates the access management security checks that the Secure
Access Service performs when a user tries to access resources through the Secure Access
Service. A detailed description of each step follows after the diagram.
64
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: General Access Management
Figure 2: Security Checks Performed During a User Session
1.
The user enters the URL of the Secure Access Service end-user console (such as
http://employees.yourcompany.com/marketing) in a Web browser.
2. The Secure Access Service 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 Secure Access Service evaluates pre-authentication restrictions and determines
if the user’s system passes host checks and other requirements. If the
pre-authentication checks fail, the Secure Access Service denies the user access. If
the checks pass, the Secure Access Service prompts the user to enter the username
and password for the realms whose preauthentication checks succeeded. (If required
by the realm, the Secure Access Service 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 Secure Access Service evaluates the post-authentication restrictions and
determines whether the user’s password conforms to specified limits and requirements.
If the postauthentication checks fail, the Secure Access Service denies the user access.
Copyright © 2013, Juniper Networks, Inc.
65
Junos Pulse Secure Access Service Administration Guide
If the checks pass, the Secure Access Service passes the user’s credentials to the
realm’s authentication server.
5. The Secure Access Service 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 Secure Access Service to use in
role mapping.) If the authentication server returns failure, Secure Access denies the
user access. If the server returns success, the Secure Access Service stores the user’s
credentials. If the realm has a separate LDAP authorization server, the Secure Access
Service 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 Secure Access Service repeats this process with the secondary server.
6. The Secure Access Service evaluates the realm’s role mapping rules and determines
the roles for which the user is eligible. The Secure Access Service determines eligibility
using information from the LDAP or RADIUS server or the user’s username.
7. The Secure Access Service 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 Secure Access Service creates a “session role,” determining the user’s session
permissions. If you enable permissive merging, the Secure Access Service determines
session permissions by merging all valid roles and granting the allowed resources
from each valid role. If you disable merging, the Secure Access Service assigns the
user to the first role to which he is mapped.
9. When the user requests a resource, the Secure Access Service checks whether the
corresponding access feature is enabled for the session user role. If not, the Secure
Access Service denies the user access. If the access feature is enabled, the evaluates
resource policies.
10. The Secure Access Service 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 Secure Access Service
denies user access to the resource if specified by the profile or policy. Otherwise, the
Secure Access Service intermediates the user request if the profile or policy enables
access.
11. The Secure Access Service intermediates the user request, forwarding the user’s
request and credentials (if necessary) to the appropriate server. Then, the Secure
Access Service 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
Secure Access Service may also force the user out if the session if you enable dynamic
policy evaluation and the user fails a policy.
NOTE: If you enable dynamic policy evaluation, the Secure Access Service
performs additional checks beyond the ones mentioned here.
66
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: General Access Management
Related
Documentation
•
Dynamic Policy Evaluation on page 67
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 Secure Access Service 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 Secure Access Service enables or denies the
user access to the dependent realms, roles, or resource policies accordingly.
The Secure Access Service does not check for changes in user attributes from a RADIUS,
LDAP, or SiteMinder server when performing dynamic policy evaluation. Instead, the
Secure Access Service re-evaluates rules and policies based on the original user attributes
that it obtained when the user signed into the Secure Access Service.
Understanding Dynamic Policy Evaluation
During dynamic policy evaluation, the Secure Access Service evaluates the following
types of resource policies:
•
Windows Secure Application Manager
•
Java Secure Application Manager
•
VPN Tunneling
•
Telnet/SSH
•
Terminal Services (Windows and Citrix)
•
Java Access
•
Code signing (for Java applets)
NOTE: Because the Secure Access Service 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 Secure Access Service does
not use dynamic policy evaluation for Meetings resource policies and Email
Client resource policies.
If the Secure Access Service determines after a dynamic policy evaluation that a user no
longer meets the security requirements of a policy or role, the Secure Access Service
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 VPN Tunneling,
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 Secure
Access Service again.
Copyright © 2013, Juniper Networks, Inc.
67
Junos Pulse Secure Access Service Administration Guide
The Secure Access Service 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 Secure Access Service evaluates policies
and roles only when the following events occur:
•
When the user first tries to access the Secure Access Service sign-in page, the Secure
Access Service evaluates the Host Checker policies (if any) for a realm.
•
Immediately after the user’s initial authentication, the Secure Access Service 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 Secure Access Service 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 Secure Access
Service 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 Secure Access Service
enforces those changes only when the events described above occur.
If you use dynamic policy evaluation, the Secure Access Service 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:
•
68
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 Secure Access Service to perform a dynamic policy evaluation
at the realm level based on:
•
An automatic timer—You can specify a refresh interval that determines how often
the Secure Access Service 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 Secure Access Service 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.
•
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.
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: General Access Management
Related
Documentation
•
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 Secure Access
Service to evaluate resource policies whenever a user’s Host Checker status changes.
(If you do not enable dynamic policy evaluation for Host Checker, the Secure Access
Service 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 912
Specifying Source IP Access Restrictions
This topic describes options to enforce source IP restrictions for access to the corporate
network or intranet resources. It includes the following information:
•
About Source IP Restrictions on page 69
•
Specifying Source IP Restrictions at the Realm Level on page 70
•
Specifying Source IP Restrictions at the Role Level on page 70
•
Specifying Source IP Restrictions in Resource Policies on page 71
About Source IP Restrictions
You can enforce access rules based on the source IP address of the request. You can
configure rules related to sign-in, role-mapping, and resource access.
At the realm level, you can add source IP rules to the realms associated with sign-in
pages. The user must sign in from a host with an IP address that is allowed by the source
IP requirements for the authentication realm. If the source IP policy does not allow the
host to access the realm, the Secure Access Service does not forward the user's
credentials to the authentication server, and the user is denied access. You can set up
multiple rules. 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).
At the user role level, you can add source IP rules to the criteria that determine user role
membership. If the source IP rule disqualifies a user from a role, subsequent role mapping
rules are consulted.
In resource policies, you can add allow/deny rules based on source IP.
Copyright © 2013, Juniper Networks, Inc.
69
Junos Pulse Secure Access Service Administration Guide
Specifying Source IP Restrictions at the Realm Level
To specify source IP restrictions:
1.
Navigate to the administrator or user realm you want to configure:
•
Administrators > Admin Realms > Realm
•
Users > User Realms > Realm
2. Select Authentication Policy > Source IP to display the Source IP policy configuration
page.
3. Choose one of the following options:
•
Allow users to sign in from any IP address—Essentially, this option turns off source
IP restrictions.
•
Allow or deny users from the following IP addresses—Specifies source IP restrictions.
If you select this option, use the policy table controls to create source IP rules.
4. Add a rule to the table:
a. Use the text boxes to specify source IP address match criteria:
•
For IPv4 clients, enter IPv4 address and netmask pairs.
•
For IPv6 clients, enter IPv6 address and prefix length pairs.
b. Use the Allow and Deny option buttons to specify the action when a rule matches.
c. Click Add to add the rule to the table.
d. Use the selection box and arrow buttons to order the list. Move the highest priority
restrictions to the top of the list. 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 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.
5. Click Save Changes to save your settings.
Specifying Source IP Restrictions at the Role Level
To specify source IP restrictions:
1.
Navigate to the administrator or user role you want to configure:
•
Administrators > Admin Roles > Role
•
Users > User Roles > Role
2. Select General > Restrictions > Source IP to display the Source IP policy configuration
page.
3. Choose one of the following options:
70
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: General Access Management
•
Allow users to sign in from any IP address—Essentially, this option turns off source
IP restrictions.
•
Allow or deny users from the following IP addresses—Specifies source IP restrictions.
If you select this option, use the policy table controls to create source IP rules.
4. Add a rule to the table:
a. Use the text boxes to specify source IP address match criteria:
•
For IPv4 clients, enter IPv4 address and netmask pairs.
•
For IPv6 clients, enter IPv6 address and prefix length pairs.
b. Use the Allow and Deny option buttons to specify the action when a rule matches.
c. Click Add to add the rule to the table.
d. Use the selection box and arrow buttons to order the list. Move the highest priority
restrictions to the top of the list. 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 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.
5. Click Save Changes to save your settings.
Specifying Source IP Restrictions in Resource Policies
A third way to use source IP restrictions is by creating custom rules in resource policies.
The action for custom rules is either allow or deny. The match criteria include resources
and conditions. One of the conditions you can set is source IP, so you can enforce source
IP restrictions through resource policies. For example:
1.
Navigate to Users > Resource Policies.
2. Select a policy. Click Web Access Policies, for example, to display its policies list.
3. Click the Initial Policy for Local Resources policy to edit it.
4. Click the Detailed Rules tab.
5. Under Conditions, expand the Prebuilt Conditions list, expand the SourceIPStr
selections, select one of the example expressions, such as SourceIPStr =
"192.168.10.0/24" or SourceIPStr = "2001:DB8::15", and click Insert Expression to add
the string to the Conditions box.
6. Modify the IP address. In other words, replace 192.168.10.0/24 with an IPv4 address
/ netmask pair; replace 2001:DB8::15 with an IPv6 address.
7. Specify the other match condition (resource) and specify the action (allow or deny).
8. Click Save Changes to save your settings.
Related
Documentation
•
Role Restrictions on page 100
•
Creating an Authentication Realm on page 284
Copyright © 2013, Juniper Networks, Inc.
71
Junos Pulse Secure Access Service Administration Guide
•
Specifying Browser Access Restrictions on page 72
•
Specifying Certificate Access Restrictions on page 74
•
Specifying Password Access Restrictions on page 75
•
Configuring Host Checker Restrictions on page 392
Specifying Browser Access Restrictions
Use a browser restriction to control from which Web browsers users can access a Secure
Access Service sign-in page or be mapped to a role. If a user tries to sign in to the Secure
Access Service 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 Secure Access Service and resource access by browser-type:
•
When administrators or users try to sign in to the Secure Access Service—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 Secure Access Service submits the user's
credentials to the authentication server. If the realm “denies” the browser's user-agent
string, then the Secure Access Service 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 Secure Access Service may map
the user. If the user-agent string does not meet the “allowed” or “denied” requirements
for a role, then the Secure Access Service 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 Secure Access Service 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.
To specify browser restrictions:
1.
Select the level at which you want to implement browser restrictions:
•
•
72
Realm level—Navigate to:
•
Administrators > Admin Realms > Select Realm > Authentication Policy > Browser
•
Users > User Realms > Select Realm > Authentication Policy > Browser
Role level—Navigate to:
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: General Access Management
•
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 Secure Access Service 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.
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
Copyright © 2013, Juniper Networks, Inc.
73
Junos Pulse Secure Access Service Administration Guide
* Deny
Specifying Certificate Access Restrictions
When you install a client-side certificate on the Secure Access Service through the System
> Configuration > Certificates > Trusted Client CAs page of the admin console, you can
restrict Secure Access Service and resource access by requiring client-side certificates:
•
When administrators or users try to sign in to the Secure Access Service—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 Secure Access
Service determines that the user's browser does not possess the certificate, the Secure
Access Service does not submit the user's credentials to the authentication server and
the user cannot access features on the Secure Access Service.
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 Secure Access Service may map the user. If the user's machine
does not possess the certificate information required by a role, then the Secure Access
Service 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
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 Secure Access Service does not allow the user to access the resource.
•
Users > Resource Policies> SelectResource > SelectPolicy > Detailed
RulesSelect|CreateRule > ConditionField
Related
Documentation
74
•
Dynamic Policy Evaluation on page 67
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: General Access Management
Specifying Password Access Restrictions
You can restrict Secure Access Service and resource access by password-length when
administrators or users try to sign in to the Secure Access Service. 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 Secure
Access Service 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 Secure Access Service.
•
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.
NOTE: This option is not applicable for IKEv2 users and therefore is not
enforced for IKEv2 users.
3. Select Enable Password Management if you want to enable password management.
You must also configure password management on the Secure Access Service
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 Secure Access Service 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 Secure Access Service local
authentication database, for example, requires user passwords to be a minimum length
of six characters.
Related
Documentation
•
Dynamic Policy Evaluation on page 67
Copyright © 2013, Juniper Networks, Inc.
75
Junos Pulse Secure Access Service Administration Guide
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 Secure Access Service
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 Secure Access Service 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. Each session counts towards the user license.
Users who enter through a realm with this feature enabled must have no more than the
specified number of sessions open. If the user attempts to open a new session that
exceeds the limit, a message appears and gives the user the option to continue or cancel.
When considering concurrent users per session, make note of the following:
76
•
All session-related SSO attributes are saved in their respective session in the cache.
These attributes are not shared with other sessions.
•
All form-related SSO attributes are saved in their respective session in the cache. These
attributes are not shared with other sessions.
•
All Form-SSO related attributes will be saved in its respective session in the cache.
The Form SSO state will not be shared with other sessions. The admin configured Form
SSO values will be shared across all sessions.
•
End-user’s home page changes are reflected across all sessions. Any changes to the
following will appear in the other concurrent sessions:
•
Bookmarks
•
Panel sorting (Preferences > User Home)
•
Email information, Daylight Saving Time, Junos Pulse Collaboration (Preferences >
General)
•
Autostart Client Application Session session (Preferences > Applications)
•
Cached Email Info settings (Preferences > Advanced)
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: General Access Management
•
Delete Cookies (Preferences > Advanced) now has options to let you remove cookies
from the current session only or to remove cookies from all sessions.
•
Delete Password (Preferences > Advanced) now has options to let you remove
passwords from the current session only or to remove passwords stored by all
sessions.
•
Cache Cleaner and Host Checker information is saved in each session. They are not
shared across concurrent sessions
•
Log messages will contain session identifiers (concatenated at the end of the log
message) to differentiate which session the message refers to.
•
Only one session can host a scheduled meeting. users can not launch multiple
scheduled meetings from concurrent sessions.
•
Users can attend meetings from any sessions. However, since only one meeting client
can be run per system, if a user wishes to attend more than one meeting, they must
attend the other meetings from a different end-user system.
•
Meeting host passes from one session to the other when you log out of a session. For
example, suppose you are the meeting host, you join the meeting in user session A and
then join the meeting again with user session B. User session A retains the meeting
host. However, if you are the meeting host from user session A, exit the meeting from
user session A and then join the meeting in user session B then user session B assumes
the meeting host role.
•
Each user session maintains its own VPN Tunneling information. This information is
not shared between concurrent sessions. However, administrator network connect
sessions are shared between concurrent sessions.
•
If you log in to the Secure Access Service as administrator, the first session is edit mode.
If you log in as an administrator in a concurrent session, that administrator is logged
in as read-only mode.
•
VPN Tunneling bandwidth allocation is enforced on a per-session basis. For example,
if a user is allocated a 1M bandwidth then each user session has a 1M bandwidth. The
total bandwidth for this user is the number of sessions of this user times 1M.
•
Users can launch terminal services, JSAM or WSAM from any session. Session
information is saved per each session, they are not shared across concurrent sessions.
Multiple instances of terminal services, JSAM and WSAM can not be started on the
same client.
•
If a user has concurrent sessions and starts the email client from multiple sessions,
the email client from the last session is the only one that can access the backend email
server through Secure Access Service. For example, if a user has two concurrent sessions
and starts the email client from both sessions, only the second session can access the
email server.
Copyright © 2013, Juniper Networks, Inc.
77
Junos Pulse Secure Access Service Administration Guide
NOTE: If you enable the multiple sessions per user feature, IKEv2 clients and
VPN Tunneling clients may not be assigned the same IP address. For example,
an IKEv2/VPN Tunneling client may be assigned a different VPN Tunneling
VIP address each time they connect to the Secure Access Service when the
Secure Access Service is obtaining the DHCP addresses from a DHCP server.
Use limits restrictions to set minimum and maximum concurrent users on the realm.
To specify the number of concurrent users limit restrictions:
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.
To specify the number of concurrent users per session limit restriction:
1.
Select Authentication > Signing In > Sign-in Policies.
2. Select the Display open user session[s] warning notification checkbox to determine
when to display a message to the user. By displaying this message, users can log out
of one of their existing sessions before continuing with the current log in if they have
already met the maximum session count.
If you do not select this checkbox and the user attempts to log in when their maximum
session count has already been met, the Secure Access Service terminates the session
that has been idle the longest.
•
Select Always to notify the user each time they log in when they already have
another active session
•
Select If the maximum session has been exceeded to display the warning message
only when the user’s maximum session count has been met.
3. Select the Enable multiple user sessions checkbox.
4. Select Users > User Realms > RealmName > Authentication Policy > Limits.
78
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: General Access Management
5. Specify the number of sessions permitted for users in the Maximum number of sessions
per user text box.
6. Click Save Changes.
NOTE: If you do not select the Enable multiple user sessions checkbox, only
one session per user is allowed regardless of the value you specify in the
Maximum number of sessions per user text box.
Related
Documentation
•
Dynamic Policy Evaluation on page 67
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 Secure Access Services.
Federation allows users to authenticate to a single Secure Access Service 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 Secure Access Services 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 Secure Access Service 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 IF-MAP 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 Secure Access Service 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, Secure Access Service 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.
IF-MAP Federation is not supported for non-root IVSes on the Secure Access Service.
Copyright © 2013, Juniper Networks, Inc.
79
Junos Pulse Secure Access Service Administration Guide
IF-MAP Federation is available on all Secure Access Services with version 6.4 or greater.
No licensing is required.
1.
The endpoint authenticates through the IF-MAP client (Secure Access Service). The
IF-MAP client publishes session information to the IF-MAP server.
2. The endpoint attempts to access protected resources that are behind the Infranet
Enforcer.
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 Secure Access Service to work in an IF-MAP Federated
network with the Infranet Controller, see IF-MAP Federation.
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, Secure Access Services, 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 Secure
Access Services? 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.
80
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: General Access Management
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:
Related
Documentation
•
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
•
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 81
•
Task Summary: Configuring IF-MAP Federation on page 84
IF-MAP Federation Details
You can configure the Secure Access Service 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 the Secure Access
Service 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. Secure Access
Services that are IF-MAP clients can subscribe to the information on an IF-MAP server.
When a user accesses the Secure Access Service 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 IF-MAP
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 the Secure Access Service 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 Secure
Access Service (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
Copyright © 2013, Juniper Networks, Inc.
81
Junos Pulse Secure Access Service Administration Guide
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 Secure Access Services and Infranet
Controllers and that will be connected in the network.
In addition to the server and client settings, you configure Session-Export policies on
Secure Access Services 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 Secure Access Services
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 Secure Access
Service 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 Secure
Access Service or the Secure Access Service into IF-MAP data. To translate session
information into IF-MAP data, you enter detailed user information. The Secure Access
Service 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 Secure Access Service 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 Secure Access Services. 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 Secure Access Service 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.
82
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: General Access Management
Figure 3: Federation IF-MAP Topology
The interaction between the endpoints, the clients and the server is as follows:
•
An endpoint authenticates through the Secure Access Service depicted in the figure
and starts VPN Tunneling or Junos Pulse.
•
The Secure Access Service 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
Secure Access Service derives IF-MAP data from the endpoint’s session.
•
The Secure Access Service 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 Secure Access Service must be running VPN Tunneling.
Imported user sessions do not count against the maximum user count for either platform,
as each user is counted on the Secure Access Service from which they authenticated.
For details on configuring an IF-MAP Federation network, see IF-MAP Federation.
Copyright © 2013, Juniper Networks, Inc.
83
Junos Pulse Secure Access Service Administration Guide
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 Access Control Service administrator,
in conjunction with an administrator for the Secure Access Service. On the Secure Access
Service, you configure Session-Export policies and you configure IF-MAP client settings.
For details on configuring an IF-MAP Federation network, see IF-MAP Federation.
To use IF-MAP Federation, perform the following tasks on the Access Control Service
and Secure Access Service:
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 IF-MAP
server.
4. On the Access Control Service and Secure Access Service, 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 Secure Access Services to define how sessions
are translated into IF-MAP data.
6. Configure Session-Import policies on Secure Access Services that correspond with
Export policies to translate IF-MAP data into Secure Access Service roles.
7. On the Infranet Controller, configure Source IP policies for Secure Access Service users
who will use Source IP to access the network.
Related
Documentation
•
Configuring IF-MAP Server Settings on page 84
•
Configuring the IF-MAP Federation Client on page 85
•
Session-Export and Session-Import Policies on page 86
•
Troubleshooting the IF-MAP Federation Network on page 91
Configuring IF-MAP Server Settings
You must add all IF-MAP clients to the Secure Access Service 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 IF-MAP Federation.
84
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: General Access Management
Related
Documentation
•
Troubleshooting the IF-MAP Federation Network on page 91
Configuring the IF-MAP Federation Client
You must identify the IF-MAP server to each Secure Access Service 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 Secure Access Services 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 84
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 IF-MAP 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.
Copyright © 2013, Juniper Networks, Inc.
85
Junos Pulse Secure Access Service Administration Guide
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 84
•
Configuring the IF-MAP Federation Client on page 85
•
Session-Export and Session-Import Policies on page 86
•
Troubleshooting the IF-MAP Federation Network on page 91
Session-Export and Session-Import Policies
You configure Session-Export policies on all of the Secure Access Services 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
Secure Access Services 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 Secure Access
Service: 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 Secure Access Service. An IF-MAP capability
is closer to the concept of a role on the Secure Access Service. An IFMAP capability is a
collection of privileges assigned as a result of an access request. This is more analogous
to the Secure Access Service 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 the Secure
Access Service, 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
86
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: General Access Management
Checker policy (you specify the Host Checker policy in the Session-Import policy). If the
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 4: 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:
•
the Secure Access Service maps to the identical IF-MAP username.
•
A role on the Secure Access Service 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 the
Secure Access Service.
Copyright © 2013, Juniper Networks, Inc.
87
Junos Pulse Secure Access Service Administration Guide
•
After you decide on pairings between IF-MAP capabilities and the roles on the Secure
Access Service, 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 Secure Access Service 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 Secure Access Service 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
Secure Access Service roles.
Device attributes, IF-MAP roles and identities can be accessed through the advanced
options links. IF-MAP capabilities and Secure Access Service roles should provide the
functionality that most Secure Access Service IF-MAP Federation requires.
Related
Documentation
•
Configuring Session-Export Policies on page 88
•
Session-Import Policies on page 90
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 Secure Access
Service 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 Secure
Access Services for which you have users that will be allowed to access resources behind
an Infranet Enforcer in the network.
88
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: General Access Management
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 IF-MAP
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.
•
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 © 2013, Juniper Networks, Inc.
89
Junos Pulse Secure Access Service Administration Guide
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 Secure
Access Service 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 capabilities 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 Secure Access Service.
•
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 86
•
Troubleshooting the IF-MAP Federation Network on page 91
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
90
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: General Access Management
server. Session-Import policies establish rules for importing user sessions from the Secure
Access Service. 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 IF-MAP Federation.
Related
Documentation
•
Troubleshooting the IF-MAP Federation Network on page 91
Troubleshooting the IF-MAP Federation Network
Diagnostic tools on the Infranet Controller and Secure Access Service 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 Secure Access Service 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 91
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
Secure Access Services 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 Secure Access Service 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.
Copyright © 2013, Juniper Networks, Inc.
91
Junos Pulse Secure Access Service Administration Guide
3. Select Activate or De-activate.
Related
Documentation
•
Troubleshooting the IF-MAP Federation Network on page 91
Trusted Server List
The Secure Access Service 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 Secure Access Services, 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 Secure Access
Service. When the user makes a decision to trust Secure Access Service, the Secure
Access Service 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:
qa.juniper.net
92
Copyright © 2013, Juniper Networks, Inc.
Chapter 3: General Access Management
dev1.juniper.net
66.129.224.48
NOTE: Whitelist files are not deleted when the Secure Access Service
software is removed.
There are two modes of enforcement:
•
Allow Admin List Only—When software launches from the Secure Access Service 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 Secure Access Service is in the
administrator whitelist, the launch proceeds as requested.
•
Prompt—When software launches from Secure Access Service 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
Secure Access Service 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
Secure Access Service software to the latest revision.
To add clusters to the whitelist file:
•
For Active/Passive clusters enter the VIP in the whitelist.
•
For Active/Active clusters enter the load balancer hostname in the whitelist.
Copyright © 2013, Juniper Networks, Inc.
93
Junos Pulse Secure Access Service Administration Guide
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
94
•
Uploading Java Applets to Secure Access on page 432
Copyright © 2013, Juniper Networks, Inc.
CHAPTER 4
User Roles
•
User Roles Overview on page 95
•
Configuring General Role Options on page 99
•
Role Restrictions on page 100
•
Specifying Role-Based Source IP Aliases on page 101
•
Specifying Role Session Options on page 101
•
Customizing the Secure Access Service Welcome Page on page 105
•
Secure Access Service Optimized Interface for the Apple iPad on page 110
•
Defining Default Options for User Roles on page 112
•
Customizing Messages on page 113
•
Customizing UI Views for User Roles on page 114
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 Secure Access Service access management framework supports two types of user
roles:
•
Administrators—An administrator role specifies Secure Access Service management
functions and session properties for administrators who map to the role. You can
customize an administrator role by selecting the Secure Access Service 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 Secure Access Service access features, defining Web, application, and session
Copyright © 2013, Juniper Networks, Inc.
95
Junos Pulse Secure Access Service Administration Guide
bookmarks, and configuring session settings for the enabled access features. You can
create and configure user roles through the Roles page. Click Users > User Roles in the
admin console.
User roles are an integral part of the Secure Access Service access management
framework, and therefore are available on all Secure Access Service 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 Secure Access Service’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 5: Security Checks Performed by the Secure Access Service to
Create a Session Role
96
Copyright © 2013, Juniper Networks, Inc.
Chapter 4: User Roles
The Secure Access Service performs the following security checks to create a session
role:
1.
The Secure Access Service 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 Secure Access Service determines if the user meets the rule conditions.
If so, then:
•
The Secure Access Service adds the corresponding roles to a list of “eligible roles”
available to the user.
•
The Secure Access Service considers whether or not the “stop on match” feature
is configured. If so, then the engine jumps to step 5.
2. The Secure Access Service 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 Secure Access Service evaluates all role mapping rules,
it compiles a comprehensive list of eligible roles.
3. The Secure Access Service evaluates the definition for each role in the eligibility list
to determine if the user complies with any role restrictions. The Secure Access Service
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 Secure Access Service assigns
the user to that role. Otherwise, the Secure Access Service continues the evaluation
process.
4. The Secure Access Service 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 Secure
Access Service 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
Secure Access Service 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 Secure Access Service 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 Secure Access Service 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 Secure Access Service repeats the
role evaluation process described in this section.
Copyright © 2013, Juniper Networks, Inc.
97
Junos Pulse Secure Access Service Administration Guide
Permissive Merge Guidelines
A permissive merge is a merge of two or more roles that combines enabled features and
settings following these guidelines:
•
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
Junos Pulse Collaboration while the other role enables Junos Pulse Collaboration,
Secure Access Service allows the user to use Junos Pulse Collaboration for that session.
•
In the case of Secure Application Manager, the Secure Access Service enables the
version corresponding to the first role that enables this feature. Furthermore, the Secure
Access Service merges the settings from all the roles that correspond to the selected
version.
NOTE: If you are using Junos Pulse, then Junos Pulse is always enabled as
the default client.
•
In the case of user interface options, the Secure Access Service applies the settings
that correspond to the user’s first role.
•
In the case of session timeouts, the Secure Access Service 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 Secure Access Service
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.
98
Copyright © 2013, 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 Secure Access Service 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 Secure Access Service 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 62
•
Configuring General Role Options on page 99
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 Secure Access Service 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:
•
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.
Copyright © 2013, Juniper Networks, Inc.
99
Junos Pulse Secure Access Service Administration Guide
•
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 Secure Access
Service users and non-Secure Access Service 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.
•
VPN Tunneling—provides secure, SSL-based network-level remote access to all
enterprise application resources using the Secure Access Service.
5. Click Save Changes to apply the settings to the role.
Related
Documentation
•
Role Restrictions on page 100
•
Specifying Role Session Options on page 101
Role Restrictions
Click Restrictions at the top of the General tab to specify access management options
for the role. The Secure Access Service considers these restrictions when determining
whether or not to map a user to the role. The Secure Access Service 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 Secure Access Service 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
100
•
Specifying Source IP Access Restrictions on page 69
•
Specifying Browser Access Restrictions on page 72
•
Specifying Certificate Access Restrictions on page 74
Copyright © 2013, Juniper Networks, Inc.
Chapter 4: User Roles
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 Secure Access
Service merges roles, the Secure Access Service 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
•
Using Virtual Ports on page 778
•
Configuring the Internal and External Ports on page 768
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
Copyright © 2013, Juniper Networks, Inc.
101
Junos Pulse Secure Access Service Administration Guide
activity. Select the Session Options check box on the Overview tab to enable these settings
for the role.
To configure general session options:
1.
In the admin GUI, click User > User Roles > RoleName > General > Session Options.
2. Configure session options, as described in Table 3 on page 102.
3. Click Save Changes to apply the settings to the role.
Table 3: Session Options
Option
Guidelines
Session lifetime
•
For Idle Timeout, specify the number of minutes a nonadministrative 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
Secure Access Service 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 Secure Access Service
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 Secure Access Service
prompts the user to reenter authentication credentials, which avoids the problem of
terminating the user session without warning.
•
For Reminder Time, specify when the Secure Access Service 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.
102
Copyright © 2013, Juniper Networks, Inc.
Chapter 4: User Roles
Table 3: Session Options (continued)
Option
Guidelines
Enable session timeout warning
Enable 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.
For example, a Secure Access Service user may unknowingly reach the idle timeout set
for his role while using an e-mail client configured to work with the Secure Access
Service, because the Secure Access Service does not receive data while the user
composes e-mail. If the session timeout warning is enabled, however, the Secure Access
Service prompts the user to reactivate his Secure Access Service session before the
session times out and forces the user’s Secure Access Service session to end. This
warning gives the user the opportunity to save his partially composed e-mail.
Optionally, 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 Secure
Access Service only displays expiration messages to users—it does not give them the
option to extend their sessions. Instead, users need to access the Secure Access Service
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 VPN
Tunneling.
Roaming session
Select one of the following options:
•
Enabled—Enables unlimited roaming sessions. An unlimited roaming session allows
mobile users (laptop users) with dynamic IP addresses to sign in to the Secure Access
Service 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. If you enable unlimited
session roaming, a session is maintained within an IPv4 network, within an IPv6
network, or from IPv4 to IPv6 and vice versa.
•
Limit to subnet—Limits the roaming session to the local subnet, specified by netmask
for IPv4 subnets and prefix length for IPv6 subnets. 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. If you configure limited session roaming, you
can specify IPv4 or IPv6 subnets within which the session is maintained. However,
with limited session roaming, you cannot allow sessions to roam from IPv4 to IPv6
networks, or vice versa.
•
Disabled—Disables roaming user sessions for users mapped to this role. Users who
sign in from one IP address may not continue an active Secure Access Service session
from another IP address; user sessions are tied to the initial source IP address.
Copyright © 2013, Juniper Networks, Inc.
103
Junos Pulse Secure Access Service Administration Guide
Table 3: Session Options (continued)
Option
Guidelines
Persistent session
By default, the Secure Access Service session cookie is flushed from the browser’s
memory when the browser is closed. The Secure Access Service session length is
determined by both the idle timeout value and maximum session length value that you
specify for the role. The Secure Access Service session does not terminate when a user
closes the browser; a Secure Access Service session only terminates when a user signs
out of the Secure Access Service.
Enable the persistent session option to write the Secure Access Service session cookie
to the client hard disk so that the user’s Secure Access Service credentials are saved
for the duration of the Secure Access Service session.
Assume persistent session is enabled and a user starts a VPN Tunneling session from
a browser. Later, the user quits the browser application. The next time the user opens
a new browser window and logs in to the same Secure Access Service, the user is not
prompted to enter his or her credentials again.
NOTE: (Macintosh only) Persistent session applies only for browser login as stated
earlier. If you start VPN Tunneling from the standalone launcher (by opening
NetworkConnect.dmg) and later open a new browser and log in to that same Secure
Access Service, you are prompted to reenter your credentials.
NOTE: If you enable the Persistent session option and a user closes the browser window
without signing out, any user can open another instance of the same browser to access
the Secure Access Service 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 Secure Access Service credentials and that
you make sure these users understand the importance of signing out of the Secure
Access Service when they are finished.
Remove Browser Session Cookie
Enable to remove the Secure Access Service session cookie and logs users out of their
Secure Access Service Web session once the client component launches, enhancing
security for your VPN Tunneling, WSAM and Pulse session.
Disable to retain the Secure Access Service session cookie and keep users logged in to
their Secure Access Service Web session once the client component starts.
Because browser cookies are plain text files, they are susceptible to malicious attacks.
The Remove Browser Session Cookie option removes the Secure Access Service session
cookie, making your VPN Tunneling, WSAM and Junos Pulse sessions more secure.
When enabled, users are logged out of their Secure Access Service Web session once
the client component (for example, Junos Pulse) launches. Users are logged out of
their Web session regardless of whether the client component launches successfully
or not. If the client component does not successfully launch, users can restart their Web
session and try launching their client component again. This option also prevents any
client component from launching a browser through the client.
NOTE: The Remove Browser Session Cookie removes only the Secure Access Service
session cookie. It does not remove non-Secure Access Service cookies or other any
other cookie.
104
Copyright © 2013, Juniper Networks, Inc.
Chapter 4: User Roles
Table 3: Session Options (continued)
Option
Guidelines
Persistent password caching
Enable to allow cached passwords to persist across sessions for a role.
The Secure Access Service supports Windows 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 Secure Access Service 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 Secure Access Service
server or another resource in the NT domain. By default, the Secure Access Service
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 Secure Access
Service, click Preferences and then click the Advanced tab.
Browser request follow-through
Enable to allow the Secure Access Service to complete a user request made after an
expired user session after the user reauthenticates.
Idle timeout application activity
Enable 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.
Upload Logs
Enable to allow the user to transmit (upload) client logs to the Secure Access Service.
NOTE: Use the System > Log/Monitoring > Client Logs > Settings page to completely
enable client-side logs for the user.
Related
Documentation
•
Junos Pulse Collaboration Overview on page 669
Customizing the Secure Access Service Welcome Page
Click UI Options at the top of the General tab to specify customized settings for the Secure
Access Service welcome page and the browsing toolbar for users mapped to this role.
The Secure Access Service welcome page (or home page) is the Web interface presented
to authenticated Secure Access Service 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 Secure Access Service 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
Secure Access Service displays the user interface corresponding to the first role to which
a user is mapped.
To customize the Secure Access Service 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 Secure Access Service 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.
Copyright © 2013, Juniper Networks, Inc.
105
Junos Pulse Secure Access Service Administration Guide
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 Secure Access Service
Bookmarks page.
•
Meetings page—Select this option to display the standard Secure Access Service
meetings page.
•
Custom page—Select this option to display a custom start page and then specify
the URL to the page. The Secure Access Service 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 Secure Access Service Browse field on the toolbar.) The
Secure Access Service 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.
106
Copyright © 2013, Juniper Networks, Inc.
Chapter 4: User Roles
NOTE: The Secure Access Service 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:
•
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 Secure Access
Service 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 Secure Access Service 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 Secure Access Service Browse field on the toolbar.)
The Secure Access Service 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 Secure Access Service 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/.
7. Under User Toolbar, select options for the toolbar on the Secure Access Service
Bookmarks page and other secure gateway pages on the Secure Access Service:
•
Home—Select this option to display the Home icon on the Secure Access Service
Bookmarks page and other secure gateway pages on the Secure Access Service.
•
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 VPN Tunneling or Secure
Application Manager. If you do not select this option, the Secure Access Service
Copyright © 2013, Juniper Networks, Inc.
107
Junos Pulse Secure Access Service Administration Guide
displays the Client Application Sessions panel on the Secure Access Service
Bookmarks page.
8. Under Browsing toolbar, select options for the toolbar that users see when browsing
pages not located on the Secure Access Service, 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 Secure Access Service
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 CIE Development,
•
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:
•
108
•
Bookmarks page—Links the logo to the Secure Access Service 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 Secure Access Service. The
Secure Access Service 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 Secure Access Service Browse field on the toolbar.) The Secure Access
Service 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:
Copyright © 2013, Juniper Networks, Inc.
Chapter 4: User Roles
•
Enable "Home" link—Select this option to display the Home Page button, which
is linked to the Secure Access Service 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 Secure Access Service
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 Secure Access
Service 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 Secure
Access Service Bookmarks page (optional):
•
Enabled—Select this option to display the personalized greeting. The Secure Access
Service 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 Secure
Access Service 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 Secure Access Service 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 Secure Access Service 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 Secure
Access Service may display the end user’s home page incorrectly.
Copyright © 2013, Juniper Networks, Inc.
109
Junos Pulse Secure Access Service Administration Guide
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 101
Secure Access Service Optimized Interface for the Apple iPad
Secure Access Service is optimized for a number of platforms, including the Apple iPad.
This optimization includes:
•
110
Login pages – includes the login and logout pages as well as intermediate pages that
appear after the user enters their credentials on the sign-in page and before the Home
page appears. The following is a list of these customized login pages:
•
Cancel.thtml
•
Defender.thtml
•
ExceededConcurrent.thtml
•
GeneratePin.thtml
•
GraceLoginUsed.thtml
•
LoginPage.thtml
•
Logout.thtml
•
NewPin.thtml
•
NextToken.thtml
•
PasswordChange.thtml
•
PasswordExpiration.thtml
•
SelectRole.thtml
•
ShowSystemPin.thtml
•
SigninNotifPostAuth.thtml
•
SigninNotifPreAuth.thtml
•
SM-NewPinSelect.thtml
•
SM-NewPinSystem.thtml
•
SM-NewUserPin.thtml
•
SM-NextToken.thtml
Copyright © 2013, Juniper Networks, Inc.
Chapter 4: User Roles
•
SSL.thtml
•
confirmation.thtml
•
confirmation_opensessions.thtml
•
user_unknown.thtml
•
Home page – this home page displays the welcome panel and any applicable
notification messages as well as the Web Bookmark panel, the File Bookmark (or Files)
panel, the VPN and Preferrences button.
•
Web Bookmark pages – located on the home page, the Web Bookmark panel lists
each individual bookmarks and allows user to tap and browse the bookmark destination
page. To to edit bookmarks, tap the Edit button on the panel header and the Edit
Bookmark page appears. On this page, user can edit individual bookmarks, reorder
bookmarks, and delete bookmarks. Editing is limited to user-created bookmarks.
•
File Bookmark pages – located on the home page, the File Bookmark panel lists each
individual bookmarks. To edit bookmarks, tap the Edit button on the panel header and
the Edit File Bookmark page will be displayed. On this page, user can edit individual
bookmarks, reorder bookmarks, and delete bookmarks. Editing is limited to user-created
file bookmarks.
•
Preferences page – located the home page is a Preferences button. When tapped, it
displays the Preferences setting page, containing configuration options for changing
username, delete cookies, delete session cookies and delete passwords.
•
Error pages – error pages that can be seen while using the features made available on
the iPad are customized.
•
Company logos – Most pages display a company logo. These pages are capable of
displaying custom logos if uploaded from the Secure Access Service admin GUI.
The following table lists the supported configurable options on the Apple iPad.
Table 4: Configurable Options on the Apple iPad
Custom User Interface Options
Supported
Header Logo Image
Yes
Header Background Color
No
Sub-Header Background Color
No
Sub-Header Text Color
No
Start Page Message (Welcome message)
Yes
Bookmark Panel Arrangement
No
Enable/Disable Help Link
Yes
Window Size of Help Page
No
Copyright © 2013, Juniper Networks, Inc.
111
Junos Pulse Secure Access Service Administration Guide
Table 4: Configurable Options on the Apple iPad (continued)
Related
Documentation
Custom User Interface Options
Supported
Show/Hide Preferences Toolbar
No
Show/Hide Session Counter
Yes
Browsing Toolbar Items
Yes
Post-Auth Sign-In Notification
Yes
Personalized Greetings
Yes
Show Copyright Notice in Footer
No
•
Defining Default Options for User Roles
You can define default options for all user roles, just as you can for delegated administrator
roles. Default values are used for newly created roles or for roles where the session or UI
option checkboxes are not selected in the User > User Roles > UserName > General >
Overview window.
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.
•
Browser request follow-through—Define response to browser session expiration.
•
Idle timeout application activity—Define Secure Access Service response to application
session activity.
•
112
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.
Copyright © 2013, Juniper Networks, Inc.
Chapter 4: User Roles
•
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 99
•
Role Restrictions on page 100
Customizing Messages
You can customize basic messages that may be displayed to your end users when they
sign in to the Secure Access Service. 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.
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.
Copyright © 2013, Juniper Networks, Inc.
113
Junos Pulse Secure Access Service Administration Guide
6. Click Save Changes.
7. Repeat the process to create messages in additional languages.
Related
Documentation
•
About Multi-Language Support for the Secure Access Service on page 1103
•
Localizing the User Interface on page 1104
•
Localizing Custom Sign-In and System Pages on page 1105
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.
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 Junos Pulse Collaboration settings that you have configured for the specified roles.
Also displays links you can use to access the corresponding Junos Pulse Collaboration
configuration pages.
VPN Tunneling
Displays VPN Tunneling settings that you have configured for the specified roles. Also
displays links you can use to access the corresponding VPN Tunneling configuration pages.
114
Copyright © 2013, Juniper Networks, Inc.
Chapter 4: User Roles
Table 5: View Menu Options (continued)
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.
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.
Copyright © 2013, Juniper Networks, Inc.
115
Junos Pulse Secure Access Service Administration Guide
Table 5: View Menu Options (continued)
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: VPN
Tunneling
Displays the VPN Tunneling 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.
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.
116
Copyright © 2013, Juniper Networks, Inc.
CHAPTER 5
Resource Profiles
•
Resource Profiles on page 117
•
Resource Profile Components on page 118
•
Defining Resource Profile Resources on page 120
•
Defining Resource Profile Autopolicies on page 122
•
Defining Resource Profile Roles on page 123
•
Defining Resource Profile Bookmarks on page 124
•
Resource Profile Templates on page 125
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 Secure Access Service 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 Secure Access Service 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 Secure Access Service access management
framework, and therefore are available on all Secure Access Service 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 © 2013, Juniper Networks, Inc.
117
Junos Pulse Secure Access Service 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 118
•
Resource Profile Templates on page 125
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 Secure Access Service 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 Secure
Access Service 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.
118
Copyright © 2013, Juniper Networks, Inc.
Chapter 5: Resource Profiles
Figure 6: 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 Secure Access
Service automatically enables the appropriate access mechanism to the roles to which
you assign the bookmark.
Copyright © 2013, Juniper Networks, Inc.
119
Junos Pulse Secure Access Service Administration Guide
Figure 7: Using Resource Profiles to Configure Resources
Related
Documentation
•
Defining a Resource Profile on page 6
•
Defining Resource Profile Autopolicies on page 122
•
Defining Resource Profile Roles on page 123
•
Defining Resource Profile Bookmarks on page 124
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 Secure Access Service.
File browsing
Windows and UNIX/NFS servers, shares, and file paths
SAM client application
Client/server applications
WSAM destination
Destination networks or servers
120
Copyright © 2013, 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 VPN Tunneling using
resource profiles. Instead, you must use roles and resource policies.
When defining resources, you can use Secure Access Service 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 122
•
Defining Resource Profile Roles on page 123
•
Defining Resource Profile Bookmarks on page 124
Copyright © 2013, Juniper Networks, Inc.
121
Junos Pulse Secure Access Service 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 Secure
Access Service handles the data that it passes to and from the specified resource.
When creating resource profiles, the Secure Access Service 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 Secure Access Service displays autopolicies that you can use to enable access
to the specified application’s server. On the other hand, the Secure Access Service 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 Secure Access Service network settings.
Additionally, the Secure Access Service 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.
122
Copyright © 2013, 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 Secure Access Service 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
Secure Access Service product, note that autopolicies are resource policies.
The Secure Access Service allows you to sort and order autopolicies along
with standard resource policies in the Users > Resource Policies pages of the
admin console. However, the Secure Access Service 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
Secure Access Service 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 Secure Access Service 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 Roles on page 123
•
Defining Resource Profile Bookmarks on page 124
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 Secure Access Service automatically enables it for you.
NOTE: Note that you can assign roles to a resource profile through the Secure
Access Service role framework as well as the resource profile framework.
Copyright © 2013, Juniper Networks, Inc.
123
Junos Pulse Secure Access Service Administration Guide
Related
Documentation
•
Defining a Resource Profile on page 6
•
Defining Resource Profile Autopolicies on page 122
•
Defining Resource Profile Bookmarks on page 124
Defining Resource Profile Bookmarks
When you create a resource profile, the Secure Access Service 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 Secure Access Service
end-user console.
NOTE: WSAM and JSAM resource profiles do not include bookmarks, since
the Secure Access Service 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 Secure Access Service 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:
124
•
“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 © 2013, 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 Secure Access
Service. To change the list of roles associated with the resource profile,
use settings in its Roles tab.
•
Bookmarks simply control which links the Secure Access Service 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 Secure Access Service allows you to create multiple bookmarks to the
same resource. If you assign duplicate bookmarks to the same user role,
however, the Secure Access Service 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 Secure Access Service updates the
corresponding bookmarks accordingly.
•
Defining a Resource Profile on page 6
•
Defining Resource Profile Autopolicies on page 122
•
Defining Resource Profile Roles on page 123
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 Secure Access Service pre-populates a variety of values for you
based on your chosen application and prompts you to configure additional settings as
necessary.
Currently, the Secure Access Service includes templates for the following third-party
applications:
•
Citrix
•
Lotus Notes
•
Microsoft Outlook
•
Microsoft Sharepoint
•
NetBIOS file browsing
Copyright © 2013, Juniper Networks, Inc.
125
Junos Pulse Secure Access Service Administration Guide
Related
Documentation
126
•
About Citrix Templates on page 445
•
Creating Resource Profiles Using the Lotus iNotes Template on page 455
•
Standard Application Support: MS Outlook on page 587
•
Creating Resource Profiles Using the Microsoft Sharepoint Template on page 463
Copyright © 2013, Juniper Networks, Inc.
CHAPTER 6
Virtual Desktop Resource Profiles
•
Virtual Desktop Resource Profile Overview on page 127
•
Configuring a Citrix XenDesktop Resource Policy on page 128
•
Configuring a VMware View Manager Resource Profile on page 129
•
Defining Bookmarks for a Virtual Desktop Profile on page 130
•
Configuring the Client Delivery on page 131
•
Connecting to the Servers on page 132
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 128
•
Configuring a VMware View Manager Resource Profile on page 129
•
Defining Bookmarks for a Virtual Desktop Profile on page 130
Copyright © 2013, Juniper Networks, Inc.
127
Junos Pulse Secure Access Service Administration Guide
•
Configuring the Client Delivery on page 131
•
Connecting to the Servers on page 132
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 Secure Access Service 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.
128
Copyright © 2013, 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 Secure
Access Service and/or create new ones.
Related
Documentation
•
Virtual Desktop Resource Profile Overview on page 127
•
Configuring a VMware View Manager Resource Profile on page 129
•
Defining Bookmarks for a Virtual Desktop Profile on page 130
•
Configuring the Client Delivery on page 131
•
Connecting to the Servers on page 132
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 © 2013, Juniper Networks, Inc.
129
Junos Pulse Secure Access Service 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 Secure
Access Service and/or create new ones.
Related
Documentation
•
Virtual Desktop Resource Profile Overview on page 127
•
Configuring a Citrix XenDesktop Resource Policy on page 128
•
Defining Bookmarks for a Virtual Desktop Profile on page 130
•
Configuring the Client Delivery on page 131
•
Connecting to the Servers on page 132
Defining Bookmarks for a Virtual Desktop Profile
When you create a virtual desktop resource profile, the Secure Access Service
automatically creates a bookmark that links to the server that you specified in the resource
profile. The Secure Access Service 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 Secure Access Service 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 Secure Access Service 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.
130
Copyright © 2013, 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 Secure Access Service 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 633
•
Virtual Desktop Resource Profile Overview on page 127
•
Configuring a Citrix XenDesktop Resource Policy on page 128
•
Configuring a VMware View Manager Resource Profile on page 129
•
Configuring the Client Delivery on page 131
•
Connecting to the Servers on page 132
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 © 2013, Juniper Networks, Inc.
131
Junos Pulse Secure Access Service Administration Guide
1.
Choose System > Configuration> Virtual Desktop.
2. Select Download from Secure Access Service to download the client file from the
Secure Access Service. 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 127
•
Connecting to the Servers on page 132
Connecting to the Servers
When an end-user clicks a desktop icon, The Secure Access Service passes credentials
to the server based on the desktop profile.
For XenDesktop, the Secure Access Service 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 Secure Access Service 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 Secure Access Service
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
Secure Access Service 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 Secure Access Service 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.
Related
Documentation
132
•
Virtual Desktop Resource Profile Overview on page 127
•
Configuring the Client Delivery on page 131
Copyright © 2013, Juniper Networks, Inc.
CHAPTER 7
Resource Policies
•
Resource Policies on page 133
•
Resource Policy Components on page 134
•
Specifying Resources for a Resource Policy on page 135
•
Resource Policy Evaluation on page 137
•
Creating Detailed Rules for Resource Policies on page 139
•
Writing a Detailed Rule for Resource Policies on page 140
•
Customizing Resource Policy UI Views on page 142
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 Secure
Access Service, 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 Secure Access Service’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 Secure Access Service:
•
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 Secure Access Service should use to sign java applets, resources
that the Secure Access Service should and should not rewrite, applications for which
the Secure Access Service 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.
•
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.
Copyright © 2013, Juniper Networks, Inc.
133
Junos Pulse Secure Access Service Administration Guide
•
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.
•
VPN Tunneling Resource Policies—The VPN Tunneling 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 Secure Access Service access management
framework, and therefore are available on all Secure Access Service 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 134
•
Resource Policy Evaluation on page 137
•
Creating Detailed Rules for Resource Policies on page 139
•
Customizing Resource Policy UI Views on page 142
Resource Policy Components
A resource policy contains the following information:
•
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 Secure Access Service to take when a user requests the
resource corresponding to the Resource list. An action may specify to allow or deny 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
134
Copyright © 2013, Juniper Networks, Inc.
Chapter 7: Resource Policies
can define one or more rules and specify the order in which the Secure Access Service
evaluates them.
Specifying Resources for a Resource Policy
The Secure Access Service 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, Secure Access Service 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.
NOTE: You cannot specify a host name for a VPN Tunneling 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
Copyright © 2013, Juniper Networks, Inc.
135
Junos Pulse Secure Access Service Administration Guide
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 VPN Tunneling
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 VPN Tunneling 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:
Table 7: DNS Hostname Special Characters
*
Matches ALL characters
%
Matches any character except dot (.)
?
Matches exactly one character
136
Copyright © 2013, Juniper Networks, Inc.
Chapter 7: Resource Policies
NOTE: You cannot specify a host name for a VPN Tunneling 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 VPN Tunneling 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
VPN Tunneling, 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 Secure Access Service 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 Secure Access Service knows to use the Web resource policies. In the case of
Web requests, the Secure Access Service 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 Secure Access Service
then evaluates the Web Access policies until it finds one that pertains to the requested
resource.
The Secure Access Service 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 Secure Access Service 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:
Copyright © 2013, Juniper Networks, Inc.
137
Junos Pulse Secure Access Service Administration Guide
Figure 8: Resource Policy Evaluation Steps
Details regarding each evaluation step:
1.
The Secure Access Service 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 Secure Access Service determines which policies match the request. The Secure
Access Service 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 Secure Access Service using resource profiles,
the Secure Access Service 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 Secure
Access Service 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.
3. The Secure Access Service evaluates and executes the rules specified in the matching
policies. You can configure policy rules to do two things:
•
138
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.
Copyright © 2013, Juniper Networks, Inc.
Chapter 7: Resource Policies
•
Require the user to meet specific conditions written as boolean expressions or
custom expressions in order to apply the action.
4. The Secure Access Service 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 Secure Access Service repeats the
resource evaluation process described in this section.
Related
Documentation
•
User Roles Overview on page 95
•
Creating Detailed Rules for Resource Policies on page 139
•
Dynamic Policy Evaluation on page 67
Creating Detailed Rules for Resource Policies
The Web, file, Secure Application Manager, Telnet/SSH, and VPN Tunneling 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).
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.
Copyright © 2013, Juniper Networks, Inc.
139
Junos Pulse Secure Access Service Administration Guide
•
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 140
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 Secure Access Service disables automatic SSO authentication
for this user role and, instead, prompts the user for sign-in credentials.
•
BasicBasic—This option specifies that the Secure Access Service 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 Secure Access Service
does not intermediate the challenge/response sequence.
NOTE: The Secure Access Service 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 Secure Access Service use the Microsoft
NTLM Intermediation method to control SSO behavior.
140
Copyright © 2013, Juniper Networks, Inc.
Chapter 7: Resource Policies
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 Secure Access Service falls back only to NTLM V2.
An intermediation page appear if SSO fails.
•
Kerberos—This option specifies that the Secure Access Service 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 Secure Access Service 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.
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.
Copyright © 2013, Juniper Networks, Inc.
141
Junos Pulse Secure Access Service Administration Guide
NOTE: You can use the <USER> substitution variable in ACLs for web
pages, telnet, files, and SAM. You cannot use the variable in VPN
Tunneling 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 Secure
Access Service to evaluate them. Keep in mind that once the Secure Access Service
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 501
•
Using System Variables in Realms, Roles, and Resource Policies on page 1139
•
Elements Used in Custom Expressions on page 1124
Customizing Resource Policy UI Views
You can limit which resource policies the Secure Access Service 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 Secure Access Service 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 Secure Access Service displays resource policies that are assigned
to the selected roles.
142
Copyright © 2013, Juniper Networks, Inc.
CHAPTER 8
Authentication and Directory Servers
•
About Authentication and Directory Servers on page 144
•
Task Summary: Configuring Authentication Servers on page 145
•
About Anonymous Servers on page 146
•
Defining an Anonymous Server Instance on page 147
•
Using an RSA ACE/Server on page 148
•
Defining an ACE/Server Instance on page 149
•
Using an RSA ACE/Server with a Secure Access Service Cluster on page 151
•
Using Active Directory or NT Domains on page 153
•
Defining an Active Directory or Windows NT Domain Server Instance on page 154
•
Configuring a Role-Mapping Rule Based on the Active Directory LDAP Primary
Group on page 158
•
Multi-Domain User Authentication on page 159
•
Join Domain for Active Directory-based Authentication Server Without Using a Domain
Admin Account on page 160
•
Using the Kerberos Debugging Tool on page 162
•
Active Directory and NT Group Lookup Support on page 162
•
Certificate Server on page 163
•
Configuring a Certificate Server Instance on page 164
•
Using an LDAP Server on page 165
•
Defining an LDAP Server Instance on page 166
•
Configuring LDAP Search Attributes for Meeting Creators on page 168
•
Enabling LDAP Password Management on page 169
•
Using a Local Authentication Server on page 174
•
Defining a Local Authentication Server Instance on page 174
•
Creating User Accounts on a Local Authentication Server on page 176
•
Configuring an NIS Server Instance on page 178
•
Configuring a RADIUS Server Instance on page 179
•
Defining a Secure Access Service RADIUS Server Instance on page 180
Copyright © 2013, Juniper Networks, Inc.
143
Junos Pulse Secure Access Service Administration Guide
•
Enabling RADIUS Accounting on page 183
•
General RADIUS Notes on page 194
•
eTrust SiteMinder Overview on page 195
•
Configuring SiteMinder to Work with the Secure Access Service on page 199
•
Configuring the SiteMinder Agent on page 200
•
Creating a SiteMinder Authentication Scheme for the Secure Access Service on page 201
•
Creating a SiteMinder Domain for the Secure Access Service on page 203
•
Creating a SiteMinder Realm for the Secure Access Service on page 203
•
Creating a Rule/Response Pair to Pass Usernames to the Secure Access
Service on page 204
•
Configuring Secure Access to Work with SiteMinder on page 205
•
Using SiteMinder User Attributes for Secure Access Role Mapping on page 215
•
Defining a SiteMinder Realm for Automatic Sign-In on page 215
•
Debugging SiteMinder and Secure Access Issues on page 216
•
Defining a SAML Server Instance on page 217
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 Secure Access
Service appliance, the user specifies an authentication realm, which is associated with
an authentication server. If the user meets the realm’s authentication policy, the Secure
Access Service 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 Secure Access
Service and, if the realm also uses the server as a directory/attribute server, the user’s
group information or other user attribute information. The Secure Access Service then
evaluates the realm’s role mapping rules to determine to which user roles the user may
be mapped.
The Secure Access Service 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 Secure Access Service.
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 Secure
Access Service 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
144
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
or SiteMinder server instance name does not appear in a realm’s Directory/Attribute
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 Secure Access Service 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 Secure Access Service access
management framework, and therefore available on all Secure Access Service 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 145
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 drop-down 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 Secure Access Service 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 © 2013, Juniper Networks, Inc.
145
Junos Pulse Secure Access Service Administration Guide
NOTE:
• An authentication server must be able to contact the Secure Access
Service. 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 Secure Access Service 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 Secure
Access Service.
•
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 144
About Anonymous Servers
The anonymous server feature allows users to access the Secure Access Service 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 Secure Access
Service 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
Secure Access Service do not require extreme security, or if you think that other security
measures provided through the Secure Access Service 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 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.
146
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
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 Secure Access Service 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 Secure Access Service cannot
display individual session data without collecting usernames.
•
Task Summary: Configuring Authentication Servers on page 145
•
Defining an Anonymous Server Instance on page 147
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 Secure Access Service, 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.
Related
Documentation
•
About Anonymous Servers on page 146
•
Task Summary: Configuring Authentication Servers on page 145
Copyright © 2013, Juniper Networks, Inc.
147
Junos Pulse Secure Access Service Administration Guide
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 Secure Access Service sign-in page—The
user browses to the standard Secure Access Service 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 Secure Access Service then forwards
the user’s credentials to ACE/Server.
•
Using a software token and the custom SoftID Secure Access Service 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
Secure Access Service. For information about enabling the SoftID custom sign-in pages,
see
http://www.juniper.net/techpubs/software/ive/admin/j-sa-sslvpn-7.0-customsigninpages.pdf.
If the ACE/Server positively authenticates the user, the user gains access to the Secure
Access Service. 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
Secure Access Service 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 Secure Access Service
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 Secure Access Service to ACE/Server without user interaction.
•
Redirects the user to the standard Secure Access Service 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 Secure Access Service cancels the transaction and
notifies the user to re-enter their credentials.
The Secure Access Service 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 Secure Access Service, 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 user may then
keep their Secure Access Service session open, even though her ACE/Server transaction
is closed.
The Secure Access Service supports the following ACE/Server features: New PIN mode,
Next Token mode, DES/SDI encryption, AES encryption, slave ACE/Server support, name
148
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
locking, and clustering. The Secure Access Service 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 Secure Access Service does not support customizing the load balancing algorithm.
Related
Documentation
•
Defining an ACE/Server Instance on page 149
•
Using an RSA ACE/Server with a Secure Access Service Cluster on page 151
•
Task Summary: Configuring Authentication Servers on page 145
Defining an ACE/Server Instance
To define an ACE/Server:
1.
Generate an ACE/Agent configuration file (sdconf.rec) for the Secure Access Service
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 Secure Access Service agent.
d. For Network Address, enter the IP address of the Secure Access Service.
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
Secure Access Service, the ACE server selects Sent Node Secret. If you later want
the ACE server to send a new Node Secret to the Secure Access Service 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.
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 Secure Access Service and ACE server are in sync.
Likewise, if you delete the verification file from the Secure Access Service, you
should uncheck the Sent Node Secret check box on the ACE server.
Copyright © 2013, Juniper Networks, Inc.
149
Junos Pulse Secure Access Service Administration Guide
If you use RSA ACE/Server authentication and change the Secure Access Service
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 Secure Access Service.
i.
Click Assign Acting Servers and select your ACE server.
j.
Click Generate Config File. When you add the ACE server to the Secure Access
Service, 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 Secure Access Service, 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 Secure Access Service 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
Secure Access Service anytime you make changes to the source file. Likewise, if you
delete the instance file from the Secure Access Service, 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
150
•
Task Summary: Configuring Authentication Servers on page 145
•
Using an RSA ACE/Server on page 148
•
Using an RSA ACE/Server with a Secure Access Service Cluster on page 151
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Using an RSA ACE/Server with a Secure Access Service Cluster
There are six tasks required to integrate RSA SecurID with a Secure Access Service cluster
(Active/Active or Active/Passive):
1.
Add each Secure Access Service node as an Agent Host in the RSA Authentication
Manager database.
2. Generate the sdconf.rec file.
3. Add the ACE server to the Secure Access Service configuration and import the
sdconf.rec file.
4. Bind the ACE server to a Secure Access Service authentication realm.
5. Configure role mapping rules.
6. Verify the system functions as expected.
To integrate RSA SecurID with a Secure Access Service cluster:
1.
Add each Secure Access Service node as an Agent Host in the RSA Authentication
Manager database:
a. On the RSA Authentication Manager host computer, go to Start > All Programs >
RSA Security > RSA Authentication Manger Host Mode to display the RSA
Authentication Manager.
b. From the menu bar, select Agent Host > Add Agent Host to display the Edit Agent
Host dialog box.
c. Complete the following settings:
•
For Name, type the hostname of the first Secure Access Service cluster node.
Let’s call this Node A.
•
For Network Address, type the Secure Access Service internal interface IP address.
•
For Agent Type, select Communication Server.
•
For Encryption Type, select your encryption method. The Secure Access Service
supports SDI and DES encryption.
•
Assign users to the Agent Host either by selecting Open to All Locally Known
Users or clicking User Activations.
d. Click OK to add the Secure Access Service as an Agent Host to the RSA
Authentication Manager database.
e. Repeat the previous steps for the second Secure Access Service cluster node. Let’s
call this Node B.
2. Generate the sdconf.rec file:
Copyright © 2013, Juniper Networks, Inc.
151
Junos Pulse Secure Access Service Administration Guide
a. From the RSA Authentication Manager menu bar, select Generate Configuration
File > One Agent Host to display the Generate Agent Host dialog box.
b. Select One Agent Host and click OK to display the Select Agent Host dialog box.
c. Select one of the Agent Host configurations you completed for the Secure Access
Service cluster and click OK.
d. Save the sdconf.rec file to your localhost or to a location you can access when you
use the Secure Access Service admin console. In the next step, you import this file
into the Secure Access Service.
3. Add the ACE server to the Secure Access Service configuration and import the
sdconf.rec file:
a. In the Secure Access Service admin console, go to Authentication > Auth. Servers.
b. Do one of the following:
•
To create a new server instance, 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.
c. Complete the following settings.
•
For Name, enter a name to identify the ACE server instance.
•
For Port, change if necessary. The default is 5500. Note that the Secure Access
Service only uses this setting if no port is specified in the sdconf.rec file.
•
For Import New Config File, click the Browse button and upload the sdconf.rec
file.
d. Click Save Changes.
After the sdconf.rec file is imported, the ACE configuration is synchronized across all
members of the cluster.
NOTE: Under Node Verification File on the ACE server configuration page,
the Creation Time column is blank. This is not filled in until at least one
user authenticates successfully to each of the nodes. You must log into
the physical IP of each node to allow the Secure Access Service and the
ACE server to negotiate a node secret on first successful login.
4. Bind the ACE server to a Secure Access Service authentication realm.
a. In the admin console, go to Users > Roles and create a role for SecureID users based
on your secure access policies.
b. Go to Users > Realm > New and enter the appropriate information for the
authentication realm. Select the ACE server you created and click Save Changes.
152
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
5. Configure role mapping rules.
a. Go to Users > Realm and click the link for the user Realm you created.
b. Click the Role-Mapping tab.
c. Click New Rule and create a new rule.
Configuration is complete. SecurID authentication is enabled on the Secure Access
Service. Users can log in with their username and SecureID passcode.
6. Verify the system is functioning as expected:
a. Open a browser to the Node A physical IP address and log in using your SecurID
passcode.
b. In the admin console, go to Authentication > Auth. Servers and click the link for the
ACE Server.
c. Under Node Verification File on the ACE server configuration page, note that the
Creation Time column is no longer blank. It shows the timestamp for the first
successful login using the ACE server. This indicates that the Secure Access Service
and the ACE server negotiated a node secret on first successful login.
d. Repeat these verification steps for Node B.
Related
Documentation
•
Using an RSA ACE/Server on page 148
•
Creating an Authentication Realm on page 284
•
Specifying Role Mapping Rules for an Authentication Realm on page 287
Using Active Directory or NT Domains
When authenticating users with an NT Primary Domain Controller (PDC) or Active
Directory, users sign in to the Secure Access Service using the same username and
password they use to access their Windows desktops. The Secure Access Service 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 Secure Access Service displays all groups from
the configured domain controller and its trusted domains.
The Secure Access Service 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.
Copyright © 2013, Juniper Networks, Inc.
153
Junos Pulse Secure Access Service Administration Guide
NOTE:
Related
Documentation
•
We do not support interoperation with Active Directory implementations
that use the equal sign operator (=) in a group name, such as: "\=THIRD
FLOOR GROUP". Authentication processing by the Secure Access Service
involves search operations that use the equal sign operator (=) when
parsing server catalogs to retrieve group names, user names and domain
names, as well as user_SID and domain_SID values. You might encounter
unexpected behavior that can affect normal processing of authentication
services if a group name configured on your Active Directory server includes
an equal sign operator (=).
•
The Secure Access Service honors trust relationships in Active Directory
and Windows NT environments.
•
When sending user credentials to an Active Directory authentication server,
the Secure Access Service uses whichever authentication protocol(s) you
specify on the New Active Directory/Windows NT page. The Secure Access
Service defaults to the authentication protocols in order. In other words, if
you have selected the check boxes for Kerberos and NTLMv2, the Secure
Access Service sends the credentials to Kerberos. If Kerberos succeeds,
the Secure Access Service does not send the credentials to NTLMv2. If
Kerberos is not supported or fails, the Secure Access Service 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 Secure Access Service supports Domain Local Groups, Domain Global
Groups, and Universal Groups defined in the Active Directory forest.
•
The Secure Access Service 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 Secure Access
Service, 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.
•
Defining an Active Directory or Windows NT Domain Server Instance on page 154
•
About Basic, NTLM and Kerberos Resources on page 499
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:
154
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
•
To create a new server instance on Secure Access Service, select Active Directory/
Windows NT 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 for the primary domain controller or Active Directory
server.
5. (Optional). Specify the IP address of your back-up domain controller or Active Directory
server.
6. Enter the NetBios 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.
7. 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
8. Select the Allow trusted domains check box to get group information from all trusted
domains within a forest.
9. 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.
10. 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.
11. Specify options under Group Search with LDAP if you want to retrieve group
membership information from the LDAP server for users.
NOTE: When using LDAP group search the group lookup fails if the same
user name is present in both the parent and child domain and if only the
child domain user is part of a group. Native active directory group search
works correctly.
Active directory group lookup using LDAP fails if a user from a different
domain tree attempts to log in to Secure Access Service. Native Active
Directory group lookup works correctly.
•
Select Enable Group Search With LDAP to look up group information for a user.
•
Select whether to use LDAP or LDAPS (LDAP communication using an SSL tunnel)
protocol.
You enable LDAPS by installing a properly formatted certificate. If you select LDAPS,
optionally select Validate Server Certificate to validate this certificate.
Copyright © 2013, Juniper Networks, Inc.
155
Junos Pulse Secure Access Service Administration Guide
•
For Admin DN, enter the administrator Distinguished Name.
•
Enter the Base Search DN. This is the point from where Secure Access Service starts
searching for the user. Base DN will look something like dc=juniper,dc=com.
•
For Nested Group Level, enter how many levels within a group to search for the user.
Note that higher numbers create longer queries or search time.
12. Under Authentication Protocol, specify which protocol Secure Access Service should
use during authentication.
13. Under Kerberos Realm Name:
•
Select Use LDAP to get Kerberos realm name if you want Secure Access Service 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.
14. Expand the Advanced Options group and configure the following advanced options:
•
User may belong to Domain Local Groups across trust boundaries—Specify if the
trusted domains' Domain Local Groups must be searched to determine users' group
memberships. This may impact performance.
•
Container name—Container path on the AD server where Secure Access Service
joins. The default is Computers, which is a standard container created during
installation of the AD server. The AD Computers container is the default location
for new computer accounts created in the domain.
If desired, you may specify a different container or OU. Use the following format for
nested OUs: outer OU\\inner OU. Note the use of two backslash symbols (\): the
first is the separator of the OUs, and the second is an escape sequence. For example,
the following entry conforms with the required format: CompObjects\\SA.
•
Computer Name—The name that Secure Access Service uses to join the specified
Active Directory domain as a computer.
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 Secure Access
Service. You can change this to a unique name, either the one provided by default
or one of your own choosing to 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. The following entry conforms with the
required format: IVE_123.
In a clustered environment with the same AD authentication server, this name is
also unique among all cluster nodes, and Secure Access Service displays all of the
identifiers for all attached cluster nodes.
15. Select the Enable User Record Synchronization checkbox to allow users to retain their
bookmarks and individual preferences regardless of which Secure Access Service they
log in to.
156
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
16. 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)
17. Click Save Changes. If you are creating the server instance for the first time, the Settings
and Users tabs appear. After you save changes, Secure Access Service masks the
administrator password using five asterisk characters, regardless of the password
length.
18. Click Reset to undo your edits and return all options on this page to their default value.
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 499
•
Using Active Directory or NT Domains on page 153
Copyright © 2013, Juniper Networks, Inc.
157
Junos Pulse Secure Access Service Administration Guide
Configuring a Role-Mapping Rule Based on the Active Directory LDAP Primary Group
When the Secure Access Service queries the Active Directory LDAP server for a user's
group membership details, the memberOf attribute is not populated with the user's
Primary group. This is a known issue. See Microsoft KB article 275523.
This topic describes how to work around this problem so that you can use the Active
Directory LDAP primary group value as the basis for role mapping rules.
1.
®
Use the Active Directory Service Interfaces Editor (ADSI Edit) tool to find the RID
(Relative Identifier) of the user’s primary group.
a. Right-click the Domain Users group and select the properties of the Group.
b. Find the value assigned to the attribute PrimaryGroupToken. This value is the RID
for that Group. In this example, let’s say the assigned value is 513.
2. Update the Secure Access Service server catalog:
a. Go to Authentication > Auth. Servers > and click the link for your LDAP server
configuration.
b. Under the “Determining group membership” group of settings, click the Server
Catalog link.
c. Click the Attribute tab and use the controls to add a new attribute named
primaryGroupID.
3. Create a new role mapping rule based on the RID user attribute:
a. Go to Users > User Realms and click the link of the realm you want to modify to
display its configuration page.
b. Under Role Mapping, click New Rule to display the role mapping rule editor.
c. Select User Attribute from the “Rule based on” list and click Update.
d. Under Rule, select primaryGroupID from the list and set the rule matching to the
RID value. In this example, you set the rule to match value 513. In your deployment,
use the appropriate RID.
e. Complete the remaining role mapping rule configuration options according to your
objectives and click Save Changes.
Related
Documentation
158
•
Defining an LDAP Server Instance on page 166
•
Specifying Role Mapping Rules for an Authentication Realm on page 287
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Multi-Domain User Authentication
Secure Access Service allows for multi-domain Active Directory and Windows NT
authentication. Secure Access Service authenticates users in the domain you configure
on the Authentication > Auth. Servers > New Active Directory / Windows 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 Secure
Access Service Active Directory server configuration, users in the default domain
authenticate to Secure Access Service 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 Secure Access Service 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
Secure Access Service supports Kerberos-based Active Directory authentication with
Windows 2000 and Windows 2003 domain controllers. When a user logs in to Secure
Access Service, it 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. Secure Access Service cannot then
authenticate against child or trusted realms of the realm you specify.
•
If you misspell the realm name, Secure Access Service cannot authenticate users
against the proper realm.
Windows NT4 Multi-Domain Authentication
Secure Access Service does not support Kerberos-based authentication in Windows
NT4 domain controllers. Instead of Kerberos authentication, Secure Access Service uses
NTLM authentication.
NOTE:
Copyright © 2013, Juniper Networks, Inc.
•
For user authentication, Secure Access Service 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 Secure Access Service 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.
159
Junos Pulse Secure Access Service Administration Guide
NT User Normalization
To support multi-domain authentication, Secure Access Service uses “normalized” NT
credentials when contacting an Active Directory or NT4 domain controller for
authentication. Normalized NT credentials include both the domain name and the
username: domain\username. Regardless of how the user signs in to Secure Access
Service, either using just a username or using the domain\username format, Secure
Access Service always treats the username in the domain\username format.
When a user attempts to authenticate using only their username, Secure Access Service
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 Secure Access Service using the domain\username format, Secure
Access Service 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. Secure Access Service 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, Secure Access Service treats
this rule semantically as NTUser = someusername AND NTDomain = defaultdomain.
This allows Secure Access Service to work seamlessly with preexisting role mapping
rules.
Related
Documentation
•
Using Active Directory or NT Domains on page 153
•
Defining an Active Directory or Windows NT Domain Server Instance on page 154
Join Domain for Active Directory-based Authentication Server Without Using a Domain
Admin Account
With Active Directory on Windows Server 2000, Windows Server 2003 and Windows
Server 2008, Secure Access Service can join domain (for an Active Directory based
Authentication server) without using a domain administrator account.
1.
Identify the user or group.
•
Identify the user or group to be granted permissions to perform AD operations on
behalf of Secure Access Service. This can be any pre-existing user or group, or it
can be a new one that you create.
•
If you use a group, be sure to add a user to the group with which you will configure
the Secure Access Service Active Directory authentication server.
2. Open the Active Directory Users and Computers window.
a. Click Start > Programs > Administrative Tools > Active Directory Users and Computers.
160
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
b. In the Active Directory Users and Computers interface, click View, and then select
Advanced Features.
3. Open the Access Control Settings for Computers dialog box.
a. In the Active Directory Users and Computers window, right-click Computers and
then click Properties. The Computer Properties dialog appears.
b. Click the Security tab and then click Advanced. The Advanced Security Settings
for Computers dialog box appears.
4. Grant the user (or group) permission to Create Computer Objects and Delete Computer
Objects in the Computers container.
a. In the Advanced Security Settings for Computers dialog box, click Add. The Select
User, Computer, or Group dialog box appears.
b. Select or manually enter the name of the user or group you want to grant
permissions to perform AD operations on behalf of Secure Access Service, and
then click OK.
c. In the Permission Entry for Computers dialog box that appears, click This object
only in the Apply onto list.
d. In the Permissions list, select the Create Computer Objects check box and the Delete
Computer Objects check box, and then click OK.
5. Grant the user (or group) permission to reset passwords and modify permissions on
objects.
a. In the Active Directory Users and Computers window, right-click Users and then
click Properties. The User Properties dialog box appears.
b. Click the Security tab and then click Advanced. The Advanced Security Settings
for Users dialog box appears.
c. Click Add. The Select User, Computer, or Group dialog box appears.
d. Click or manually enter the name of the user (or group) you want to grant
permissions to perform AD operations on behalf of Secure Access Service, and
then click OK.
e. In the Permission Entry for Users dialog box, click User objects in the Apply onto
list.
f.
n the Permissions list, select the Reset Password checkbox, and then click OK.
6. Verify there are no Deny entries that would affect the user (or group).
7. Exit the Advanced Security Settings for Users dialog box.
a. In the Advanced Security Settings for Users dialog box, click OK.
Copyright © 2013, Juniper Networks, Inc.
161
Junos Pulse Secure Access Service Administration Guide
b. In the Users Properties dialog box, click OK.
8. Exit the Active Directory Users and Computers interface.
9. Configure the Secure Access Service Active Directory Authentication Server.
a. In the Administrator section of the Active Directory authentication server
configuration, enter the user name you identified in Step 1 above and their password
in the Admin Username and Admin Password fields respectively, and click Save
Changes.
b. Restart the Secure Access Service services.
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:
Related
Documentation
•
Clear All Tickets—Removes all tickets associated with the specified Secure Access
Service 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
credentials it obtains to make sure they belong to a trusted KDB site. The Server Realm
and Server KDC fields are optional.
•
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 499
Active Directory and NT Group Lookup Support
Secure Access Service 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, Secure Access Service first tries to join the domain
using the default computer name. For this operation to succeed, you must specify valid
162
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
domain administrator credentials in the Active Directory server configuration on Secure
Access Service.
Active Directory Lookup Requirements
Secure Access Service supports user group lookup in Domain Local, Domain Global, and
Universal groups in the default domain, child domains, and all trusted domains. Secure
Access Service 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
Secure Access Service 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, Secure Access Service attempts group lookup in the
following order:
•
Secure Access Service checks for all Domain Global groups using the user’s security
context.
•
If Secure Access Service has not found that the user is a member of some of the groups
referenced in the role mapping rules, Secure Access Service performs an LDAP query
to determine the user’s group membership.
•
If Secure Access Service has not found that the user is a member of some of the groups
referenced in the role mapping rules, Secure Access Service performs an RPC lookup
to determine the user’s Domain Local group membership.
NT4 Group Lookup Requirements
Secure Access Service 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.
Secure Access Service obtains Domain Global group information from the user’s security
context, and Domain Local information using RPC calls. Secure Access Service uses no
LDAP-based search calls in the NT4 environment.
Related
Documentation
•
Using Active Directory or NT Domains on page 153
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 Secure Access Service determines that the user’s certificate is valid, it signs
Copyright © 2013, Juniper Networks, Inc.
163
Junos Pulse Secure Access Service Administration Guide
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, Secure Access Service 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, Secure Access Service 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 Secure
Access Service. If they do not, other users may be able to use their open
browser sessions to access certificate-protected resources on the Secure
Access Service 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 302
•
Configuring a Certificate Server Instance on page 164
•
Task Summary: Configuring Authentication Servers on page 145
Configuring a Certificate Server Instance
When defining a certificate server on the Secure Access Service, 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 Secure Access Service should
construct a username. You may use any combination of certificate variables
contained in angle brackets and plain text.
164
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
NOTE: If you choose a certificate attribute with more than one value,
the Secure Access Service 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 Secure Access Service uses the
“management” value. To use all values, add the SEP attribute to the
variable. For example, if you enter <certDN.OUT SEP=”:”> the Secure
Access Service 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
•
Specifying Client-side Certificate Restrictions on page 831
•
Certificate Server on page 163
•
Using System Variables in Realms, Roles, and Resource Policies on page 1139
Using an LDAP Server
The Secure Access Service supports two LDAP-specific authentication options:
•
Unencrypted—in which the Secure Access Service sends the username and password
to the LDAP Directory Service in clear, simple text.
•
LDAPS—in which the Secure Access Service encrypts the data in the LDAP
authentication session using Secure Socket Layer (SSL) protocol before sending it to
the LDAP Directory Service.
The Secure Access Service performs substantial input validation for the following items:
•
LDAP Server—The Secure Access Service provides a warning if the server is not
reachable.
•
LDAP Port—The Secure Access Service provides a warning if the LDAP server is not
reachable.
•
Administrator credentials—The Secure Access Service generates an error if the
verification of admin credentials fails.
Copyright © 2013, Juniper Networks, Inc.
165
Junos Pulse Secure Access Service Administration Guide
Related
Documentation
•
Base DN for users—The Secure Access Service generates an error if the base-level
search on the Base DN value fails.
•
Base DN for groups—The Secure Access Service generates an error if the baselevel
search on the Base DN value fails.
•
Task Summary: Configuring Authentication Servers on page 145
•
Defining an LDAP Server Instance on page 166
•
Enabling LDAP Password Management on page 169
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 Secure Access Service, 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 Secure Access Service uses
to validate your users.
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). Secure Access Service 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 Secure Access Service and LDAP
Directory Service should be unencrypted, use SSL (LDAPs), or should use TLS.
If you select LDAPS, you have the option to require validation for the server certificate
for the configured LDAP server(s) and its referral servers. If you enable validation for
the referral servers, make sure your network DNS supports reverse lookup zone.
166
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
9. Specify how long you want Secure Access Service 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 Secure Access Service to wait for search results from a
connected LDAP server.
11. Click Test Connection to verify the connection between Secure Access Service and
the specified LDAP server(s). (optional)
12. Select the Authentication required? check box if Secure Access Service 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; Secure Access Service uses the
first DN returned if more than 1 DN is returned.
15. Secure Access Service supports both static and dynamic groups. (Note that Secure
Access Service only supports dynamic groups with LDAP servers.) To enable group
lookup, you need to specify how Secure Access Service 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:
Copyright © 2013, Juniper Networks, Inc.
167
Junos Pulse Secure Access Service Administration Guide
•
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, Secure Access Service searches the
Server Catalog first. If Secure Access Service finds no match in the catalog, then
it queries LDAP to determine if a group member is a sub-group.
NOTE: Because Secure Access Service 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.
NOTE: When the Secure Access Service queries the Active Directory
LDAP server for a user's group membership details, the memberOf
attribute is not populated with the user's Primary group. This is a known
issue. See Microsoft KB article 275523. To work around this issue, see
“Configuring a Role-Mapping Rule Based on the Active Directory LDAP
Primary Group” on page 158.
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 Secure Access Service 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.
NOTE: Secure Access Service supports referral chasing if enabled on your
LDAP server.
Related
Documentation
•
Using the LDAP Server Catalog on page 292
•
Using an LDAP Server on page 165
•
Task Summary: Configuring Authentication Servers on page 145
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 Secure Access Service users when scheduling a meeting.
168
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
To configure Junos Pulse Collaboration search attributes:
1.
In the admin console, choose Authentication > Auth. Servers.
2. Click an LDAP server name (or create an LDAP server and then save it), and then
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
•
Junos Pulse Collaboration Overview on page 669
Enabling LDAP Password Management
The Secure Access Service password management feature enables users who
authenticate through an LDAP server to manage their passwords through the Secure
Access Service using the policies defined on the LDAP server. For example, if a user tries
to sign in to the Secure Access Service with an LDAP password that is about to expire,
the Secure Access Service catches the expired password notification, presents it to the
user through the Secure Access Service 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,
they can change them themselves through the Secure Access Service 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 Secure Access Service
may inform the user that his password is expired or about to expire. If expired, the Secure
Access Service prompts the user to change his password. If the password has not expired,
the Secure Access Service may allow the user to sign in to the Secure Access Service
using his existing password. After he has signed in, he may change his password from
the Preferences page.
Once enabled, the Secure Access Service 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 Secure Access Service does this by using its internal LDAP or
Copyright © 2013, Juniper Networks, Inc.
169
Junos Pulse Secure Access Service Administration Guide
Samba client. Many servers, such as Microsoft Active Directory or Sun iPlanet, offer an
Administrative Console to configure account and password options.
The Secure Access Service enforces password policies by reading password attributes
from the LDAP server. Therefore, for the Secure Access Service password management
feature to work correctly, the password policy attributes on the back-end server need to
be configured properly. The following configuration guidelines apply:
•
For Active Directory in general, 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.
•
For Active Directory 2008, the Secure Access Service supports the Fine Grained
Password Policy (FGP) configured in the AD user container.
•
The Secure Access Service does not support customized password policies.
•
The Secure Access Service does not support password management based on the
Active Directory Global Catalog because password policy attributes are not fully
populated on the Active Directory Global Catalog.
The Secure Access Service relies on the back-end 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 Secure Access Service. 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 the LDAP server.
Next, you associate the LDAP server with the applicable realms. Finally, you select the
enable password management feature at the realm level.
Supported LDAP Directories and Servers
The Secure Access Service supports password management with the following LDAP
directories:
•
Microsoft Active Directory/Windows NT
•
Sun iPlanet
•
Novell eDirectory
LDAP-based Password Management does not work on generic LDAP servers like
OpenLDAP.
Additionally, the Secure Access Service supports password management with the
following Windows servers:
170
•
Microsoft Active Directory 2008
•
Microsoft Active Directory 2003
•
Windows NT 4.0
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
The following sections list specific issues related to individual server types.
•
Microsoft Active Directory on page 171
•
Sun iPlanet on page 171
•
General on page 171
•
Supported LDAP Password Management Functions on page 171
•
AD/NT Password Management Matrix on page 173
Microsoft Active Directory
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 Secure Access Service
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 object and Fine-Grained Password Policy objects or the Domain
Security Policy LDAP objects.
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 Secure Access Service only displays a warning about password expiry if the password
is scheduled to expire in 14 days or less. The Secure Access Service displays the message
during each Secure Access Service 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 supported password management functions, 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
Secure Access Service can pass the corresponding messages, functions, and restrictions
Copyright © 2013, Juniper Networks, Inc.
171
Junos Pulse Secure Access Service Administration Guide
to end-users. The Active Directory attribute names shown are specific to the Domain
Security Policy object. Similar attributes for the corresponding functions are used for the
Active Directory 2008 Fine-Grained Password Policy. Refer to Microsoft documentation
for details.
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
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 Secure Access Service
displays warning if less
than 14 days)
If now() passwordExpirationTime<
14 days
(the Secure Access Service
displays warning if less
than 14 days)
( is read from domain
attributes)
(the Secure Access Service
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 Secure Access
Service displays message
telling user minPwdLength
If set, the Secure Access
Service displays message
telling user
passwordMinLength
If set, the Secure Access
Service 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
172
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 9: Supported Password Management Functions (continued)
Function
Active Directory
iPlanet
Novell eDirectory
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
AD/NT Password Management Matrix
The following matrix describes supported password management functions.
Table 10: AD/NT Password Management Matrix
Function
Active Directory
Active Directory 2003
Active Directory 2008
FGP
Windows NT
Authenticate user
Yes
Yes
Yes
Yes
Allow user to change password if enabled
Yes
Yes
Yes
Yes
Log out user after password change
Yes
Yes
Yes
Yes
Force password change at next login
Yes
Yes
Yes
Yes
Password expired notification
Yes
Yes
Yes
Yes
Account disabled
Yes
Yes
Yes
Yes
Account expired
Yes
Yes
Yes
Yes
Troubleshooting LDAP Password Management on the Secure Access Service
When troubleshooting, please provide any pertinent Secure Access Service logs, server
logs, configuration information, and a TCP trace from the Secure Access Service. If you
are using LDAPS, please switch to the “Unencrypted” LDAP option in the Secure Access
Service LDAP server configuration while taking the LDAP TCP traces.
Related
Documentation
•
Using an LDAP Server on page 165
•
Defining an LDAP Server Instance on page 166
Copyright © 2013, Juniper Networks, Inc.
173
Junos Pulse Secure Access Service Administration Guide
Using a Local Authentication Server
The Secure Access Service enables you to create one or more local databases of users
who are authenticated by the Secure Access Service. 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.
Related
Documentation
•
Task Summary: Configuring Authentication Servers on page 145
•
Defining a Local Authentication Server Instance on page 174
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 Secure Access Service, 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.
174
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
NOTE:
• If the maximum length set on the authentication server is shorter
than the maximum length specified in the Secure Access Service,
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.
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).
Copyright © 2013, Juniper Networks, Inc.
175
Junos Pulse Secure Access Service Administration Guide
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
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 174
•
Specifying Password Access Restrictions on page 75
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 Secure Access Service 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.
176
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
•
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.
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 Secure Access Service 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.
Copyright © 2013, Juniper Networks, Inc.
177
Junos Pulse Secure Access Service Administration Guide
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 Secure
Access Service sessions.
•
Using a Local Authentication Server on page 174
•
Defining a Local Authentication Server Instance on page 174
Configuring an NIS Server Instance
When authenticating users with a UNIX/NIS server, the Secure Access Service 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
Secure Access Service cannot contain two consecutive tilde symbols (~~).
NOTE: You can only use NIS authentication with the Secure Access Service
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 Secure
Access Service, 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 Secure Access Service, 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.
178
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
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 145
•
Defining Authentication Access Policies on page 285
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 Secure Access Service users, you need to configure it to
recognize the Secure Access Service as a client and specify a shared secret for the RADIUS
server to use to authenticate the client request.
The Secure Access Service 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 Secure Access Service supports the standard RADIUS authentication schemes,
including:
•
Access-Request
•
Access-Accept
•
Access-Reject
•
Access-Challenge
The Secure Access Service 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 Secure Access Service 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 Secure Access Service to work
with many different RADIUS implementations and new versions of the RADIUS server,
such as Defender 5.0. The Secure Access Service 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.
Copyright © 2013, Juniper Networks, Inc.
179
Junos Pulse Secure Access Service Administration Guide
If you are using a PassGo Defender RADIUS Server, the user sign-in process is:
•
The user signs in to the Secure Access Service with a username and password. The
Secure Access Service forwards these credentials to Defender.
•
Defender sends a unique challenge string to the Secure Access Service and the Secure
Access Service 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 Secure Access Service 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 Secure Access
Service then generates an intermediate page that automatically launches the CASQUE
player installed on the user’s system.
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 145
•
Enabling RADIUS Accounting on page 183
Defining a Secure Access Service RADIUS Server Instance
To configure a connection to the RADIUS server on Secure Access Service:
1.
In the admin console, choose Authentication > Auth. Servers.
2. Do one of the following:
•
To create a new server instance on Secure Access Service, 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 Secure Access Service
Network Access Server (NAS) client that communicates with the RADIUS server. If
you leave this field empty, the Secure Access Service uses the value specified in the
Hostname field of the System > Network > Overview page of the admin console. If
180
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
no value is specified in Hostname field, the Secure Access Service 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 Secure Access Service 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 Secure Access Service’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 Secure Access Service to wait for a response from
the RADIUS server before timing out the connection.
11. Enter the number of times for the Secure Access Service 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 Secure Access Service.
13. In the Backup Server section, enter a secondary RADIUS server for the Secure Access
Service 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 Secure Access Service 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 Secure Access Service
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 Secure Access Service username to the accounting
server.
•
<REALM> logs the user’s Secure Access Service realm to the accounting server.
Copyright © 2013, Juniper Networks, Inc.
181
Junos Pulse Secure Access Service Administration Guide
•
<ROLE> logs the user’s Secure Access Service role to the accounting server. If
the user is assigned to more than one role, the Secure Access Service
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 Secure Access
Service for the Framed-IP-Address attribute.
Two IP addresses are recorded: one prior to authenticating with the Secure Access
Service, and one returned by VPN Tunneling after authentication. Select this option
to use the VPN Tunneling 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
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:
182
•
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
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
string sent by the Secure Access Service 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.
Configuring the RADIUS Server to Recognize the Secure Access Service
You need to configure the RADIUS server to recognize the Secure Access Service by
specifying:
Related
Documentation
•
The host name given to the Secure Access Service.
•
The network IP address of the Secure Access Service.
•
The Secure Access Service 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 179
•
Enabling RADIUS Accounting on page 183
•
System Variables and Examples on page 1128
Enabling RADIUS Accounting
You can configure the Secure Access Service to send session start and stop messages
to a RADIUS accounting server. The Secure Access Service recognizes two categories of
sessions—user-sessions and sub-sessions. A user session may contain multiple
sub-sessions. The Secure Access Service recognizes the following types of sub-sessions:
Copyright © 2013, Juniper Networks, Inc.
183
Junos Pulse Secure Access Service Administration Guide
•
JSAM
•
WSAM
•
VPN Tunneling (formerly called Network Connect)
The Secure Access Service sends a user-session start message after the user successfully
signs in and the Secure Access Service maps him to a role. The Secure Access Service
sends a sub-session start message when the sub-session becomes active; for example,
after launching JSAM. The Secure Access Service 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 Secure Access Service sends a user-session
stop message to the accounting server. A user session terminates whenever the user:
•
Manually signs out of the Secure Access Service
•
Times out of the Secure Access Service either due to inactivity or because of exceeding
the maximum session length
•
Is denied access due to Host Checker or Cache Cleaner role-level restrictions
•
Is manually forced out of the Secure Access Service by an administrator or due to
dynamic policy evaluation.
The Secure Access Service 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 a Secure Access Service 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
184
Attribute
Description
User-Name (1)
String that the Secure Access Service administrator specifies during
RADIUS server configuration
NAS-IP-Address (4)
Secure Access Service’s IP address
NAS-Port (5)
The Secure Access Service 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 Secure Access Service client under the
RADIUS server configuration
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 11: Attributes Common to both Start and Stop Messages (continued)
Attribute
Description
Acct-Status-Type (40)
The Secure Access Service 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 Secure
Access Service generates the accounting record
Table 12: Start Attributes
Attribute
Description
Acct-Authentic (45)
The Secure Access Service 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 Secure Access Service 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)
Copyright © 2013, Juniper Networks, Inc.
•
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 Secure Access Service 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
185
Junos Pulse Secure Access Service Administration Guide
Table 13: Stop Attributes (continued)
Attribute
Description
Acct-Terminate-Cause
(49)
The Secure Access Service 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 Secure
Access Service 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
Secure Access Service.
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 Secure Access Service 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 or VPN Tunneling 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
186
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.
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 14: RADIUS Role Mapping Attributes (continued)
Attribute
Description
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).
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
Copyright © 2013, Juniper Networks, Inc.
187
Junos Pulse Secure Access Service Administration Guide
Table 14: RADIUS Role Mapping Attributes (continued)
188
Attribute
Description
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.
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.
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 14: RADIUS Role Mapping Attributes (continued)
Attribute
Description
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.
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.
Copyright © 2013, Juniper Networks, Inc.
189
Junos Pulse Secure Access Service Administration Guide
Table 14: RADIUS Role Mapping Attributes (continued)
190
Attribute
Description
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.
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.
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 14: RADIUS Role Mapping Attributes (continued)
Attribute
Description
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.
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).
Copyright © 2013, Juniper Networks, Inc.
191
Junos Pulse Secure Access Service Administration Guide
Table 14: RADIUS Role Mapping Attributes (continued)
192
Attribute
Description
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.
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.
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 14: RADIUS Role Mapping Attributes (continued)
Attribute
Description
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.
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.
Copyright © 2013, Juniper Networks, Inc.
193
Junos Pulse Secure Access Service Administration Guide
Table 14: RADIUS Role Mapping Attributes (continued)
Related
Documentation
•
Attribute
Description
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.
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 179
General RADIUS Notes
Please note the following issues.
194
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Understanding Clustering Issues
Accounting messages are sent to the RADIUS server by each cluster node without
consolidation. RADIUS accounting 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.
We do 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
the session is less than 30 seconds long and the applications keep the connections open
all the time.
Related
Documentation
•
Configuring a RADIUS Server Instance on page 179
eTrust SiteMinder Overview
When you configure the Secure Access Service to authenticate users with an eTrust
SiteMinder policy server, the Secure Access Service 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 Secure Access Service 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 Secure Access Service 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 Secure Access Service passed.
Copyright © 2013, Juniper Networks, Inc.
195
Junos Pulse Secure Access Service Administration Guide
The Secure Access Service 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 Secure Access Service 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 Secure Gateway: If the user tries to access a SiteMinder resource from within his
Secure Access Service session (for example, from the Secure Access Service file
browsing page), the Secure Access Service 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 Secure Access Service 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 Secure Access Service can use an
SMSESSION cookie generated by another agent to enable single sign-on from a SiteMinder
resource to the Secure Access Service. When a user accesses the Secure Access Service
sign-in page with an SMSESSION cookie, the Secure Access Service verifies the
SMSESSION cookie. Upon successful verification, the Secure Access Service establishes
a Secure Access Service session for the user. You can use the following authentication
mechanisms when you enable automatic sign-in through the Secure Access Service:
196
•
Custom agent: The Secure Access Service 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 SSO on
these agents, update each of them to accept third party cookies If you select this option
and the user enters his Secure Access Service session with an SMSESSION cookie, The
Secure Access Service attempts automatic sign-in when the user enters the Secure
Access Service session.
•
HTML form post: The Secure Access Service 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 Secure Access Service session with an SMSESSION cookie, the Secure Access
Service attempts automatic sign-in when the user enters the Secure Access Service
session.
•
Delegated authentication: The Secure Access Service delegates authentication to a
standard agent. If this option is enabled, the Secure Access Service tries to determine
the FCC URL associated with the protected resource. The Secure Access Service then
redirects the user to the FCC URL with the Secure Access Service sign-in URL as the
TARGET. Upon successful authentication, the user is redirected back to the Secure
Access Service with an SMSESSION cookie and the Secure Access Service does an
automatic sign-in for the user.
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
NOTE:
Copyright © 2013, 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 Secure Access Service.
•
SiteMinder sends the SMSESSION cookie to the Secure Access Service as
a persistent cookie. To maximize security, the Secure Access Service resets
the persistent cookie as a session cookie once authentication is complete.
•
When you use SiteMinder to authenticate, the Secure Access Service
disregards any Secure Access Service 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 Secure
Access Service 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 Secure Access Service using an IP address,
they may receive an authentication failure and will be prompted to
authenticate again.
•
The Secure Access Service logs any SiteMinder error codes on the System
> Log/Monitoring > User Access page. For information on the SiteMinder
error codes, see the SiteMinder documentation.
197
Junos Pulse Secure Access Service 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 Secure Access Service
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 Secure Access Service through the System >
Certificates > Trusted Client CAs tab.
•
If you do not want to display the standard Secure Access Service 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 Secure
Access Service client-side certificate authentication. If you choose both,
the Secure Access Service first authenticates using the Secure Access
Service 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 Secure
Access Service may obtain a username from various sources, such as a policy server
header, certificate attribute, or from the Secure Access Service sign-in page. Listed below
are the various methods a user may employ to access the Secure Access Service and
how the Secure Access Service determines the username for each. When a user:
•
198
Signs in through the standard Secure Access Service sign-in page— The Secure
Access Service first checks the username that the policy server returned in its
OnAuthAccept response header. If SiteMinder does not define a username, the Secure
Access Service uses the name that the user entered during sign-in. Otherwise, if neither
Copyright © 2013, 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 Secure Access Service uses the UserDN value set by the policy
server.
•
Automatically signs in to the Secure Access Service using SiteMinder credentials—The
Secure Access Service first checks the username that the policy server returned in its
OnAuthAccept response header. If SiteMinder does not define a username, the Secure
Access Service checks the SMSESSION cookie. Otherwise, if SiteMinder does not
populate the response header or SMSESSION cookie with a username, the Secure
Access Service checks the UserDN value in the SMSESSION cookie.
Once the Secure Access Service 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 Secure Access Service, you should
configure the OnAuthAccept response on the SiteMinder policy server.
Related
Documentation
•
Configuring Secure Access Service to Work with SiteMinder
•
Creating a Rule/Response Pair to Pass Usernames to the Secure Access Service on
page 204
•
Creating a SiteMinder Realm for the Secure Access Service on page 203
•
Creating a SiteMinder Domain for the Secure Access Service on page 203
•
Creating a SiteMinder Authentication Scheme for the Secure Access Service on page 201
•
Configuring the SiteMinder Agent on page 200
•
Configuring SiteMinder to Work with the Secure Access Service on page 199
Configuring SiteMinder to Work with the Secure Access Service
The following steps are required to configure a SiteMinder policy server to work with the
Secure Access Service. These are not complete SiteMinder configuration instructions—they
are only intended to help you make SiteMinder work with the Secure Access Service. For
in-depth SiteMinder configuration information, refer to the documentation provided with
your SiteMinder policy server.
Related
Documentation
•
Configure the SiteMinder Agent.
•
Create a SiteMinder authentication scheme for the Secure Access Service.
•
Create a SiteMinder domain for the Secure Access Service.
•
Create a SiteMinder realm for the Secure Access Service.
•
Create a Rule/Response pair to pass usernames to the Secure Access Service.
•
Create a SiteMinder Policy under the domain.
•
eTrust SiteMinder Overview on page 195
•
Configuring the SiteMinder Agent on page 200
Copyright © 2013, Juniper Networks, Inc.
199
Junos Pulse Secure Access Service Administration Guide
•
Creating a SiteMinder Authentication Scheme for the Secure Access Service on page 201
•
Creating a SiteMinder Domain for the Secure Access Service on page 203
•
Creating a SiteMinder Realm for the Secure Access Service on page 203
•
Creating a Rule/Response Pair to Pass Usernames to the Secure Access Service on
page 204
•
Configuring Secure Access Service to Work with SiteMinder
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 Secure Access Service, you must configure the Secure Access Service
as 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 Secure Access Service as 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 Secure Access
Service.
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 Secure Access Service.
6. Under IP Address or Host Name, enter the name or IP address of the Secure Access
Service.
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 Secure Access Service.
8. Click OK.
200
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Related
Documentation
•
eTrust SiteMinder Overview on page 195
•
Configuring SiteMinder to Work with the Secure Access Service on page 199
•
Creating a SiteMinder Authentication Scheme for the Secure Access Service on page 201
•
Creating a SiteMinder Domain for the Secure Access Service on page 203
•
Creating a SiteMinder Realm for the Secure Access Service on page 203
•
Creating a Rule/Response Pair to Pass Usernames to the Secure Access Service on
page 204
•
Configuring Secure Access Service to Work with SiteMinder
Creating a SiteMinder Authentication Scheme for the Secure Access Service
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 Secure Access Service:
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 Secure
Access Service).
•
X509 Client Cert Template
•
X509 Client Cert and Basic Authentication
NOTE:
• The Secure Access Service only supports the authentication scheme
types listed here.
Copyright © 2013, Juniper Networks, Inc.
•
You must select HTML Form Template if you want the Secure Access
Service 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 Secure Access
Service through the System > Certificates > Trusted Client CAs tab.
201
Junos Pulse Secure Access Service Administration Guide
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 Secure Access Service 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 Secure Access Service host name (for example,
sales.yourcompany.net).
•
Select the Use SSL Connection checkbox.
•
Under Target, enter the Secure Access Service sign-in URL defined in this step’s
first bullet plus the parameter “ive=1” (for example, /highproturl?ive=1). (The Secure
Access Service 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 Secure Access Service, 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.
Related
Documentation
202
•
Configuring Secure Access Service to Work with SiteMinder
•
Creating a Rule/Response Pair to Pass Usernames to the Secure Access Service on
page 204
•
Creating a SiteMinder Realm for the Secure Access Service on page 203
•
Creating a SiteMinder Domain for the Secure Access Service on page 203
•
Configuring the SiteMinder Agent on page 200
•
Configuring SiteMinder to Work with the Secure Access Service on page 199
•
eTrust SiteMinder Overview on page 195
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Creating a SiteMinder Domain for the Secure Access Service
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 Secure Access Service to work with SiteMinder, you must give Secure
Access Service users access to a SiteMinder resource within a realm, and then group the
realm into a domain.
To configure a SiteMinder domain for the Secure Access Service:
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 Secure Access Service on page 199
•
Creating a SiteMinder Realm for the Secure Access Service on page 203
Creating a SiteMinder Realm for the Secure Access Service
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 Secure Access Service, you must define realms to determine which resources Secure
Access Service 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 Secure Access Service, you must define realms to determine which resources Secure
Access Service users may access.
1.
In the SiteMinder Administration interface, select the Domains tab.
2. Expand the domain that you created for the Secure Access Service.
3. Right-click on Realms and choose Create Realm.
4. Enter a name and (optionally) description for the realm.
5. In the Agent field, select the Web agent that you created for the Secure Access Service.
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 Secure Access Service. 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
Secure Access Service.
8. Click OK.
Copyright © 2013, Juniper Networks, Inc.
203
Junos Pulse Secure Access Service Administration Guide
Related
Documentation
•
Configuring SiteMinder to Work with the Secure Access Service on page 199
•
Creating a SiteMinder Domain for the Secure Access Service on page 203
Creating a Rule/Response Pair to Pass Usernames to the Secure Access Service
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 Secure Access Service, 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 Secure Access Service
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 Secure Access Service, and then expand
Realms.
3. Right-click on the realm that you created for the Secure Access Service, 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 Secure Access Service.
3. Right-click on Responses and select Create Response.
4. Enter a name and (optionally) a description for the response.
5. Select SiteMinder and then select the Secure Access Service 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.
204
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Related
Documentation
•
Configuring SiteMinder to Work with the Secure Access Service on page 199
•
Configuring the SiteMinder Agent on page 200
Configuring Secure Access to Work with SiteMinder
This section includes instructions for configuring Secure Access to work with a SiteMinder
policy server.
Configuring Secure Access to Work with Multiple Authentication Schemes
To configure Secure Access to work with multiple SiteMinder authentication schemes,
you must:
1.
Configure the authentication schemes on the SiteMinder policy server.
2. Create one Secure Access instance of the SiteMinder policy server for all SiteMinder
authentication schemes you want to use.
3. Specify which Secure Access realm should use the Secure Access 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 Secure Access
sign-in policy. In the Authentication > Authentication > Signing In Policies > New
Sign-In Policy page:
•
Specify a Secure Access 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 a Secure Access sign-in URL to match a SiteMinder URL of XYZ/ACE,
where XYZ is the name of a realm.
•
Select the Secure Access realm that you specified should use the SiteMinder policy
server.
The user signs into Secure Access using one of the Secure Access sign-in URLs. Secure
Access sends the protected resource URL to SiteMinder, and based on the resource,
SiteMinder determines which type of scheme to use to authenticate the user. Secure
Access collects the credentials that the authentication scheme requires, and then passes
them to SiteMinder for authentication.
Configuring Secure Access to Grant Users Different Protected Resources
To configure Secure Access 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 Secure Access instance of the SiteMinder policy server for all protected
resources and corresponding protection levels that you want to allow.
Copyright © 2013, Juniper Networks, Inc.
205
Junos Pulse Secure Access Service Administration Guide
3. Specify which Secure Access realm should use the Secure Access instance of the
SiteMinder policy server.
4. For each resource on the SiteMinder policy server, create a Secure Access sign-in
policy for each realm-level resource filter. In the configuration page for the sign-in
policy, specify:
•
A Secure Access 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 Secure Access realm that you specified should use the SiteMinder policy
server.
During production, the user signs into Secure Access using one of the URLs. Secure Access
extracts the protected resource from the URL and authenticates the user against the
appropriate realm.
Defining an eTrust SiteMinder Server Instance
Within Secure Access, a SiteMinder instance is a set of configuration settings that defines
how Secure Access interacts with the SiteMinder policy server. After defining the
SiteMinder server instance, specify which Secure Access realm(s) should use the Secure
Access instance of the SiteMinder policy server to authenticate and authorize
administrators and users.
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 Secure Access, 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 207.
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.
206
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
c. 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.
5. Click Save Changes.
6. Set advanced SiteMinder configuration options (optional) using the settings described
in Table 15 on page 207.
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 Secure Access appliance use the main policy
server unless it fails.
•
Select No to have the Secure Access 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. Version 12.0 supports only version 12.0. The default value is 5.5 policy
servers.
On logout, redirect
to
Specify a URL to which users are redirected when they sign out of Secure
Access (optional). If you leave this field empty, users see the default
Secure Access 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, Secure Access uses this default URL to set the user’s
protection level for the session. Secure Access also uses this default URL
if you select the Automatic Sign-In option. If your users are signing in to
the “*” URL (default Secure Access sign-in page), enter any URL
(“/Secure Access-authentication” is the default) to set the protection
level to the default Secure Access value. If you do create sign-in policies
for SiteMinder, Secure Access 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” ).
Copyright © 2013, Juniper Networks, Inc.
207
Junos Pulse Secure Access Service Administration Guide
Table 15: eTrust SiteMinder Configuration Options (continued)
Option
Description
Resource Action
(Read-only) For new SiteMinder server instances, Secure Access sets
the resource action to GET. If your SiteMinder instance is upgraded from
a 3.x instance, Secure Access 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 for either the end-user or for the Secure Access
Service. A cookie domain is a domain in which the user’s cookies are
active. For example, Secure Access 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
Secure Access device as “http://ive.juniper.net” in order to ensure that
his SMSESSION cookie is sent back to the Secure Access Service.
Protocol
(Read-only) Indicates that Secure Access uses HTTPS protocol to send
cookies to the user’s Web browser.
Secure Access
Service Cookie
DomainIC Cookie
Domain
Enter the Internet domain(s) to which Secure Access sends the
SMSESSION cookie using the same guidelines outlined for the Cookie
Domain field. (A Secure Access 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
208
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 15: eTrust SiteMinder Configuration Options (continued)
Option
Description
Automatic Sign-In
Select the Automatic Sign-In option to automatically sign in users who
have a valid SMSESSION cookie in to Secure Access. 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 Secure Access realm, Secure
Access uses the protection level associated with the cookie.
•
In order to enable single sign-on from another Web agent to Secure
Access, Secure Access needs to validate an existing SMSESSION cookie
created by a standard Web agent.
•
Secure Access 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.
•
Secure Access 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.
Secure Access maps the user to a role based on the role mapping rules
defined in the selected realm.
•
If Automatic Sign In fails, redirect to
Enter an alternative URL for users who sign into Secure Access through
the Automatic Sign-In mechanism. Secure Access redirects users to
the specified URL if Secure Access 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 Secure Access.
Note:
•
Users who sign in through the Secure Access sign-in page are always
redirected back to the Secure Access 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 Secure Access
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.
Copyright © 2013, Juniper Networks, Inc.
209
Junos Pulse Secure Access Service Administration Guide
Table 15: eTrust SiteMinder Configuration Options (continued)
Option
Description
Authenticate using
custom agent
Choose this option if you want to authenticate using the Secure Access
custom Web agent. Note that if you select this option, you must also:
Authenticate using
HTML form post
•
Update all of your standard Web agents to the appropriate Siteminder
Agent Quarterly Maintenance Release (QMR) in order to accept the
cookies created by Secure Access. If you are running SiteMinder version
5 Web agents, use the QMR5 hot fix. Secure Access 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.
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 Secure Access 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:
210
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 15: eTrust SiteMinder Configuration Options (continued)
Option
Description
•
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 Secure Access 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.
•
Web Agent
Name of the Web agent from which Secure Access 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.
Copyright © 2013, Juniper Networks, Inc.
211
Junos Pulse Secure Access Service Administration Guide
Table 15: eTrust SiteMinder Configuration Options (continued)
Option
Description
Delegate
authentication to a
standard agent
Choose this option if you want to delegate authentication to a standard
agent. When the user accesses the Secure Access sign-in page, Secure
Access determines the FCC URL associated with the protected resource’s
authentication scheme. Secure Access redirects the user to that URL,
setting the Secure Access 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 Secure Access. Secure
Access then automatically signs in the user and establishes a Secure
Access session.
NOTE:
•
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, Secure Access tries to
automatically sign in using the existing SMSESSION cookie. If the cookie
is invalid, Secure Access clears the SMSESSION cookie and
corresponding Secure Access cookies and presents the user with a
“timeout” page. Secure Access 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.
Table 16: eTrust SiteMinder Advanced Configuration Options
212
Option
Description
Poll Interval
Enter the interval at which Secure Access polls the Siteminder policy
server to check for a new key.
Max. Connections
Controls the maximum number of simultaneous connections that Secure
Access 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 Secure Access 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
Secure Access ends the connection. The default setting of “none”
indicates no time limit.
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 16: eTrust SiteMinder Advanced Configuration Options (continued)
Option
Description
Authorize while
Authenticating
Specifies that Secure Access 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 Secure Access 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:
•
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 Secure Access. Not until the user tries
to access a protected resource does Secure Access check his
authorization rights and deny him access.
•
Secure Access 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 .
Enable Session
Grace Period,
Validate cookie
every N seconds
You can eliminate the overhead of verifying a user’s SMSESSION cookie
each time the user requests the same resource by indicating that Secure
Access should consider the cookie valid for a certain period of time.
During that period, Secure Access assumes that its cached cookie is valid
rather than re-validating it against the policy server. If you do not select
this option, Secure Access checks the user’s SMSESSION cookie on each
request. Note that the value entered here does not affect session or idle
timeout checking.
Ignore Query Data
By default, when a user requests a resource, Secure Access sends the
entire URL for that resource to the policy server (including the query
parameter, if present). For example, Secure Access 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.)
Secure Access 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.
Copyright © 2013, Juniper Networks, Inc.
213
Junos Pulse Secure Access Service Administration Guide
Table 16: eTrust SiteMinder Advanced Configuration Options (continued)
Option
Description
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.
Overlook Session
for Methods
Compares the request method to the methods listed here. If a match is
found, Web Agent does not create a new or update an existing
SMSESSION cookie, nor will it make any updates to the cookie provider
for that request.
You can enter multiple methods; use a comma to separate method
names.
If Overlook Session for Methods parameter is set but not Overlook
Session for URLs, then all requests that match the methods defined in
this parameter are processed (SMSESSION cookie creation/update is
blocked).
If both Overlook Session for Methods and Overlook Session for
URLsparameters are set, both the method and the URL of the request
are matched before proceeding. Then, all URLs with specified methods
are processed (SMSESSION cookie creation/update is blocked).
Overlook Session
for URLs
Compares the request URL to the URLs listed in this parameter. If a match
is found, Web Agent does not create a new or update an existing
SMSESSION cookie, nor will it make any updates to the cookie provider
for that request.
Specify a relative URL. For example: If the URL is
http://fqdn.host/MyDocuments/index.html, enter
/MyDocuments/index.html
If Overlook Session for URLs is set but not Overlook Session for
Methods, then all requests, regardless of the methods, matching the
URLs defined in this parameter are processed (SMSESSION cookie
creation/update is blocked).
If both Overlook Session for Methods and Overlook Session for
URLsparameters are defined, both the method and the URL of the
request are matched before proceeding. Then, all URLs with specified
methods are processed (SMSESSION cookie creation/update is blocked).
Flush Cache
214
Use to delete the Secure Access resource cache, which caches resource
authorization information for 10 minutes.
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Related
Documentation
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.
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
•
Creating an Authentication Realm on page 284
•
Role Mapping Rules on page 286
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.
Copyright © 2013, Juniper Networks, Inc.
215
Junos Pulse Secure Access Service Administration Guide
•
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.
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 Secure Access Service on page 199
•
Debugging SiteMinder and Secure Access Issues on page 216
Debugging SiteMinder and Secure Access Issues
216
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.
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Related
Documentation
•
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.
•
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 Secure Access Service on page 199
Defining a SAML Server Instance
This topic describes how to configure Secure Access Service as an Authentication Server
for a SAML 2.0 deployment. For information on configuring an Authentication Server for
a SAML 1.1 deployment, see “Creating a SAML 1.1 Server Instance” on page 270.
To configure the Secure Access Service as a SAML SP:
1.
In the admin console, select Authentication > Auth. Servers.
2. Select SAML Server from the New list and then click New Server.
3. Complete the settings as described in Table 17 on page 217.
4. Click Save Changes.
After you save changes for the first time, the page is redisplayed and now has two
tabs. The Settings tab allows you to modify any of the settings pertaining to the SAML
Server instance. The Users tab lists valid users of the server.
Table 17: SAML SP Profile (POST and Artifact)
Setting
Guideline
Name
Specify a name to identify the server instance.
Settings
SAML Version
Select 2.0.
Secure Access Service
Entity Id
This value is prepopulated. It is generated by the system, based on the value for the Host FQDN
for SAML setting on the System > Configuration > SAML > Settings page.
Configuration Mode
Select Manual or Metadata. If a metadata file or location is available from the SAML IdP, use the
metadata option to make configuration simpler and less prone to error. To upload or set the
location for the published metadata file, go to System > Configuration > SAML and click the New
Metadata Provider button.
Copyright © 2013, Juniper Networks, Inc.
217
Junos Pulse Secure Access Service Administration Guide
Table 17: SAML SP Profile (POST and Artifact) (continued)
Setting
Guideline
Identity Provider Entity ID
The IdP entity ID is sent as the Issuer value in the assertion generated by the SAML IdP.
If you use the metadata option, this setting can be completed by selecting the IdP entity ID from
the list. The list is populated by the IdP entities defined in metadata files added to the System >
Configuration > SAML page.
If you complete this setting manually, specify the Issuer value in assertions generated by the SAML
IdP. Typically, you ask the SAML IdP administrator for this setting.
Identity Provider Single
Sign On Service URL
The IdP SSO service URL is a URL provisioned by the SAML IdP. The setting is required to support
SP-initiated SSO. If missing, the Secure Access Service cannot successfully redirect the user
request.
If you use the metadata option, this setting can be completed by selecting the SSO service URL
from the list. The list is populated by the IdP entities defined in metadata files added to the System
> Configuration > SAML page.
If you complete this setting manually, ask the SAML IdP administrator for this setting.
User Name Template
Specify how the Secure Access Service is to derive the username from the assertion. If the field is
left blank, it uses the string received in the NameID field of the incoming assertion as the username.
If you choose a certificate attribute with more than one value, the Secure Access Service 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 Secure Access Service uses “management”. To use
all values, add the SEP attribute to the variable. For example, if you enter <certDN.OUT SEP=”:”>,
the Secure Access Service uses “management:sales”. The attributes received in the attribute
statement in the incoming assertion are saved under userAttr. These variables can also be used
with angle brackets and plain text. If the user name cannot be generated using the specified
template, the login fails. If the NameID filed of the incoming assertion is of type X509Nameformat,
then the individual fields can be extracted using system variable “assertionNameDN”.
Allowed Clock Skew
Determines the maximum allowed difference in time between the Secure Access Service clock
and the SAML IdP server clock.
Support Single Logout
Single logout is a mechanism provided by SAML for logging out a particular user from all the
sessions created by the IdP. Select this option if the Secure Access Service must receive and send
single logout request for the peer SAML IdP.
If you use the metadata option, the Single Logout Service URL setting can be completed by selecting
the SLO service URL from the list. The list is populated by the IdP entities defined in metadata
files added to the System > Configuration > SAML page. The Secure Access Service sends Single
Logout requests to this URL.
In addition, if you use the metadata option, the Single Logout Response URL setting is completed
based on your selection for Single Logout Service URL. If the IdP has left this setting empty in its
metadata file, the Secure Access Service sends the Single Logout response to the SLO service
URL.
If you complete these settings manually, ask the SAML IdP administrator for guidance.
SSO Method
218
Copyright © 2013, Juniper Networks, Inc.
Chapter 8: Authentication and Directory Servers
Table 17: SAML SP Profile (POST and Artifact) (continued)
Setting
Guideline
Artifact
When configured to use the Artifact binding, the Secure Access Service contacts the Artifact
Resolution Services (ARS) to fetch the assertion using SOAP protocol. If the ARS is hosted on a
HTTPS URL, then the certificate presented by the ARS is verified by the Secure Access Service.
For this verification to pass successfully, the CA of the server certificate issued to the IdP ARS must
be added to the Trusted Server CA on the Secure Access Service.
Complete the following settings to configure SAML using the HTTP Artifact binding:
POST
•
Source ID. Enter the source ID for the IdP ARS. Source ID is Base64 encoded 20 byte identifier
for the IdP ARS. If left blank, this value is generated by the Secure Access Service.
•
Source Artifact Resolution Service URL. For metadata-based configuration, this field is completed
automatically from the metadata file and is not configurable. For manual configurations, enter
the URL of the service to which the SP ACS is to send ArtifactResolve requests. ArtifactResolve
requests are used to fetch the assertion from the artifact received by it.
•
SOAP Client Authentication. Select HTTP Basic or SSL Client Certificate and complete the related
settings. If you use an SSL client certificate, select a certificate from the Secure Access Service
device certificate list.
•
Select Device Certificate for Signing. Select the device certificate the Secure Access Service
uses to sign the AuthnRequest sent to the IdP SSO service. If you do not select a certificate, the
Secure Access Service does not sign AuthnRequest.
•
Select Device Certificate for Encryption. Select the device certificate the Secure Access Service
uses to decrypt encrypted data received in the SAML response. The public key associated with
the device certificate is used by the IdP for encryption.
When configured to use the POST binding, the Secure Access Service uses a response signing
certificate to verify the signature in the incoming response or assertion. The certificate file must
be in PEM or DER format. The certificate you select should be the same certificate used by the IdP
to sign SAML responses.
Complete the following settings to configure SAML using the HTTP POST binding:
•
Response Signing Certificate. If you use the metadata-based configuration option, select a
certificate from the list. The list is populated by the IdP entities defined in metadata files added
to the System > Configuration > SAML page.
If you configure these settings manually, browse to and upload the certificate to be used to
validate the signature in the incoming response or assertion.
If no certificate is specified, the certificate embedded in the response is used.
•
Enable Signing Certificate status checking. Select this option to check the validity of the signing
certificate before verifying the signature. This setting applies to any certificate used for signature
verification. If this option is enabled, the response will be rejected if the certificate is revoked,
expired, or untrusted. If this option is selected, the certificate CA must be added to the Secure
Access Service Trusted Client CA store.
If this option is not enabled then the certificate is used without any checks.
•
Select Device Certificate for Signing. Select the device certificate the Secure Access Service
uses to sign the AuthnRequest sent to the IdP SSO service. If you do not select a certificate, the
Secure Access Service does not sign AuthnRequest.
•
Select Device Certificate for Encryption. Select the device certificate the Secure Access Service
uses to decrypt encrypted data received in the SAML response. The public key associated with
the device certificate is used by the IdP for encryption.
Service Provider Metadata Settings
Metadata Validity
Enter the number of days the Secure Access metadata is valid. Valid values are 0 to 9999. 0
specifies the metadata does not expire.
Copyright © 2013, Juniper Networks, Inc.
219
Junos Pulse Secure Access Service Administration Guide
Table 17: SAML SP Profile (POST and Artifact) (continued)
Setting
Guideline
Do Not Publish Secure
Access Service Metadata
Select this option if you do not want the Secure Access Service to publish the metadata at the
location specified by the Secure Access Service Entity ID field.
Download Metadata
This button appears only after you have saved the Authentication Server configuration. Use this
button to download the metadata of the current SAML SP.
User Record Synchronization
Enable User Record
Synchronization
Related
Documentation
220
Allow users to retain their bookmarks and individual preferences regardless of which Secure Access
Service device they log in to.
•
Understanding SAML 2.0 on page 221
•
Configuring Secure Access Service as a SAML 2.0 Service Provider on page 233
Copyright © 2013, Juniper Networks, Inc.
CHAPTER 9
SAML Single Sign-on
This chapter describes how to use the Junos Pulse Secure Access Service in a SAML
single sign-on deployment. It includes the following sections:
•
Junos Pulse Secure Access Service SAML 2.0 SSO Solutions on page 221
•
Secure Access Service SAML 2.0 Configuration Tasks on page 230
•
Example: Implementing SAML 2.0 Web Browser SSO for Google Apps on page 249
•
Junos Pulse Secure Access Service SAML 1.1 Support on page 258
Junos Pulse Secure Access Service SAML 2.0 SSO Solutions
This section provides a brief overview of the Security Assertion Markup Language (SAML)
standard produced and approved by the Organization for the Advancement of Structured
Information Standards (OASIS). It includes the following topics:
•
Understanding SAML 2.0 on page 221
•
Secure Access Service SAML 2.0 Supported Features Reference on page 222
Understanding SAML 2.0
This topic provides a reference to the Security Assertion Markup Language (SAML)
standard and an overview of SAML 2.0 use cases. It includes the following information:
•
About SAML on page 221
•
SAML Use Cases on page 222
About SAML
SAML is an XML-based framework for communicating user authentication, entitlement,
and attribute information. The standard defines the XML-based assertions, protocols,
bindings, and profiles used in communication between SAML entities. SAML is used
primarily to implement Web browser single sign-on (SSO). SAML enables businesses to
leverage an identity-based security system like the Junos Pulse Secure Access Service
to enforce secure access to websites and other resources without prompting the user
with more than one authentication challenge.
For complete details on the SAML standard, see the OASIS website:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
Copyright © 2013, Juniper Networks, Inc.
221
Junos Pulse Secure Access Service Administration Guide
SAML Use Cases
This section provides a brief summary of the primary SAML use cases. It includes the
following information:
•
SAML SSO on page 222
•
SAML ACL on page 222
SAML SSO
SAML is primarily used to enable Web browser single sign-on (SSO). The user experience
objective for SSO is to allow a user to authenticate once and gain access to separately
secured systems without resubmitting credentials. The security objective is to ensure
the authentication requirements are met at each security checkpoint.
In an SSO transaction, the SAML services implemented at each secured system exchange
requests and assertions to determine whether to allow access. The SAML assertions
used in SSO transactions include authentication statements and attribute statements.
SAML ACL
SAML can also be used to enforce access control list (ACL) permissions. In an ACL
transaction, the SAML services implemented for each secured system exchange assertions
to determine whether a user can access the resource. The SAML assertions used in ACL
transactions include authorization requests and authorization decision statements.
Related
Documentation
•
Secure Access Service SAML 2.0 Supported Features Reference on page 222
•
Configuring Secure Access Service as a SAML 2.0 Service Provider on page 233
•
Configuring Secure Access Service as a SAML 2.0 Identity Provider on page 237
•
Configuring a SAML 2.0 ACL Web Policy on page 247
Secure Access Service SAML 2.0 Supported Features Reference
This topic provides an overview of Junos Pulse Secure Access Service support for Security
Assertion Markup Language (SAML) single sign-on (SSO). It includes the following
information related to SAML 2.0 support:
•
Supported SAML SSO Deployment Modes on page 222
•
Supported SAML SSO Profiles on page 228
•
FIPS Support Notes on page 229
Supported SAML SSO Deployment Modes
In a SAML deployment, a SAML service provider is a secured resource (an application,
website, or service) that is configured to request authentication from a SAML identity
provider. The SAML identity provider responds with assertions regarding the identity,
attributes, and entitlements (according to your configuration). The exchange enforces
security and enables the SSO user experience.
222
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
The Secure Access Service can act as a SAML service provider, a SAML identity provider,
or both. The following sections provide illustrations:
•
Secure Access Service as a SAML Service Provider on page 223
•
Secure Access Service As a SAML Identity Provider (Gateway Mode) on page 225
•
Secure Access Service as a SAML Identity Provider (Peer Mode) on page 226
Secure Access Service as a SAML Service Provider
If you are working with a partner that has implemented a SAML identity provider, you can
deploy the Secure Access Service as a SAML service provider to interoperate with it,
thereby enabling SSO for users who should have access to resources in both networks.
In this model, the user is authenticated by the SAML identity provider. The Secure Access
Service uses the SAML response containing the assertion to make an authentication
decision.
The choices the identity provider makes to implement SAML determine the Secure Access
Service deployment choices, for example whether to use SAML 2.0 or SAML 1.1, whether
to reference a published metadata configuration file, and whether to use a POST or
artifact profile. When you deploy the Secure Access Service as a SAML service provider,
you create a SAML authentication server that references the partner SAML identity
provider, and a set of Secure Access Service access management framework objects
(realm, role mapping rules, and sign-in policy) that reference the SAML authentication
server.
When you configure the SAML service provider, some particular settings are necessary
to support either identity-provider-initiated or service-provider-initiated SSO. The
documentation for the configuration steps makes note of these settings. Regardless,
you configure the SAML service provider to support both identity-provider-initiated and
service-provider-initiated SSO.
Figure 9 on page 224 illustrates the flow of network communication in a
service-provider-initiated SSO scenario.
Copyright © 2013, Juniper Networks, Inc.
223
Junos Pulse Secure Access Service Administration Guide
Figure 9: Secure Access Service as a SAML Service Provider in a
Service-Provider-Initiated SSO Scenario
User
2.2
1
2b
3b
2a
3a
Identity
provider
Service provider
g037730
2.1
4
1 – The user clicks a link to access a resource.
2 – The service provider redirects the user to the identity provider, initiating SAML communication. If the user already has a
session with the identity provider, steps 2.1 and 2.2 are skipped.
2.1 – If the user does not have a session, the identity provider sends an authentication challenge to the user.
2.2 – The user enters sign-in credentials.
3 – The SAML identity provider responds to the SAML request.
4 – The external resource is delivered to the user’s browser.
Figure 10 on page 225 illustrates the flow of network communication in an
identity-provider-initiated SSO scenario.
224
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
Figure 10: Secure Access Service as a SAML Service Provider in an
Identity-Provider-Initiated SSO Scenario
User
1
3
4b
5
2
4a
g037734
Identity
provider
Service provider
1 – The user authenticates to the identity provider.
2 – The identity provider returns a portal page with links to external resources.
3 – The user clicks a link for an external resource.
4 – The SAML identity provider initiates an exchange of SAML requests and assertions. The SAML exchange is a substitute for
user interaction. The SAML exchange conducts the security without interrupting the user.
5 – The external resource is delivered to the user’s browser.
Secure Access Service As a SAML Identity Provider (Gateway Mode)
When you deploy the Secure Access Service in front of enterprise resources that support
SAML and have been configured as a SAML service provider, the Secure Access Service
acts as a gateway for user access to the secured resource, just as it does with its other
resource policies. The Secure Access Service maintains the session and uses its rewriting
or pass-through proxy features to render data to the user. In the SAML exchange, the
Secure Access Service acts as a SAML identity provider. When deployed as a gateway,
the SAML SSO communication is always identity-provider-initiated. Figure 11 on page 226
illustrates this scenario.
Copyright © 2013, Juniper Networks, Inc.
225
Junos Pulse Secure Access Service Administration Guide
Figure 11: Secure Access Service as a SAML Identity Provider (Gateway
Mode)
User
1
2
Identity
provider
g037732
3
Service
provider
1 – A user logs into the Secure Access Service.
2 – The user clicks a link to a resource protected by a security system that supports SAML and has implemented a SAML service
provider.
3 – The SAML identity provider initiates the SAML authentication request to the SAML service provider. Users are granted access
to particular resources according to the Secure Access Service SAML SSO resource policy.
Secure Access Service as a SAML Identity Provider (Peer Mode)
When deployed to support access to external resources (for example, public cloud
resources), the Secure Access Service does not have to be a gateway to user access.
The user can access the external resource directly, and the traffic does not flow through
the Secure Access Service device. You configure the Secure Access Service as a SAML
identity provider to correspond with the external SAML service provider, and you configure
a SAML SSO external applications policy to determine the users and resources to which
the SAML SSO experience applies.
When you configure the SAML identity provider, some settings are necessary to support
either identity-provider-initiated or service-provider-initiated SSO. The documentation
for the configuration steps makes note of these settings. Regardless, you configure the
226
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
SAML identity provider to support both identity-provider-initiated and
service-provider-initiated SSO.
Figure 12 on page 227 illustrates the flow of network communication in a
service-provider-initiated SSO scenario.
Figure 12: Secure Access Service as a SAML Identity Provider (Peer Mode)
in a Service-Provider-Initiated SSO Scenario
User
2.2
1
2b
3b
2a
3a
Identity provider
Service
provider
g037731
2.1
4
1 – The user clicks a link to access a resource.
2a – The service provider sends an HTTP redirect status code (HTTP 302) to the user. The SAML request and all other SAML
details are sent as URL parameters in the URL Location header.
2b – The user sends an HTTP GET request to the identity provider. The SAML request and all other SAML details are sent as
URL parameters.
If the user already has a session with the identity provider, steps 2.1 and 2.2 are skipped.
2.1 – If the user does not have a session, the identity provider sends an authentication challenge to the user.
2.2 – The user enters sign-in credentials.
3a – The identity provider sends a successful status code (HTTP 200 OK) to the user with a form in the HTML body.
3b – The user sends the form to the service provider.
4 – The external resource is delivered to the user’s browser.
Figure 13 on page 228 illustrates the flow of network communication in an
identity-provider-initiated SSO scenario.
Copyright © 2013, Juniper Networks, Inc.
227
Junos Pulse Secure Access Service Administration Guide
Figure 13: Secure Access Service as a SAML Identity Provider (Peer Mode)
in an Identity-Provider-Initiated SSO Scenario
User
1
3
4b
5
4a
Identity provider
g037733
2
Service
provider
1 – The user authenticates to the identity provider.
2 – The identity provider returns a portal page with links to external resources.
3 – The user clicks a link for an external resource.
4a – The identity provider sends a successful status code (HTTP 200 OK) to the user with a form in the HTML body.
4b – The user sends the form to the service provider.
5 – The external resource is delivered to the user’s browser.
Supported SAML SSO Profiles
Table 18 on page 228 summarizes support for SAML 2.0 deployment profiles.
Table 18: Supported SAML 2.0 Deployment Profiles
Profile
Message Flows
Binding
Service Provider
Identity Provider
(Gateway)
Identity Provider
(Peer)
Web
browser
SSO
<AuthnRequest>
from service provider
to identity provider
HTTP redirect
Supported
–
Supported
HTTP POST
Not supported
–
Supported
HTTP artifact
Not supported
–
Not supported
HTTP POST
Supported
Supported
Supported
HTTP artifact
Supported
Supported
Supported
Identity provider
<Response> to
service provider
228
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
Table 18: Supported SAML 2.0 Deployment Profiles (continued)
Profile
Message Flows
Binding
Service Provider
Identity Provider
(Gateway)
Identity Provider
(Peer)
Assertion
query /
request
Artifact resolution
<ArtifactResolve>
<ArtifactResponse>
SOAP
Supported
Supported
Supported
Single
logout
Logout request
HTTP redirect
Supported
Not supported
Not supported
HTTP POST
Not supported
Not supported
Not supported
HTTP artifact
Not supported
Not supported
Not supported
SOAP
Not supported
Not supported
Not supported
HTTP redirect
Supported
Not supported
Not supported
HTTP POST
Not supported
Not supported
Not supported
HTTP artifact
Not supported
Not supported
Not supported
SOAP
Not supported
Not supported
Not supported
Logout response
FIPS Support Notes
In FIPS deployments, private keys are managed in a way that is problematic for SAML
functionality that depends on access to the private key. Table 19 on page 229 summarizes
our support for SAML for FIPS deployments.
Table 19: SAML Support for FIPS Deployments
SAML 2.0
7.2
SAML 1.1
Service Provider
Identity Provider
Consumer
Producer
The following configuration restrictions
apply to the Authentication Server
configuration:
The following configuration restrictions
apply to the Sign-In SAML Identity
Provider configuration:
No
limitations
Artifact
profile only
•
Set Select Device Certificate for
Signing to Not Applicable.
•
•
Set Select Device Certificate for
Encryption to Not Applicable.
Set Protocol Binding to Use for SAML
Response to Artifact. POST is not
supported.
•
Set Signing Certificate to No Signing.
•
Set Decryption Certificate to No
Encryption.
•
Clear the Enable Artifact Response
Signing and Encryption check box.
Support for valid 7.1 configurations
(Legacy mode)
Copyright © 2013, Juniper Networks, Inc.
229
Junos Pulse Secure Access Service Administration Guide
Table 19: SAML Support for FIPS Deployments (continued)
SAML 2.0
7.1
7.0
SAML 1.1
Service Provider
Identity Provider
Consumer
Producer
The following configuration restrictions
apply to the authentication server
configuration:
Artifact profile only
No
limitations
Artifact
profile only
–
No
limitations
Artifact
profile only
•
Set Select Device Certificate for
Signing to Not Applicable.
•
Set Select Device Certificate for
Encryption to Not Applicable.
–
Related
Documentation
•
Understanding SAML 2.0 on page 221
•
Configuring Secure Access Service as a SAML 2.0 Service Provider on page 233
•
Configuring Secure Access Service as a SAML 2.0 Identity Provider on page 237
Secure Access Service SAML 2.0 Configuration Tasks
This section includes the tasks you perform to enable and configure SAML services. It
includes the following information:
•
Configuring System-Wide SAML Settings on page 230
•
Configuring Secure Access Service as a SAML 2.0 Service Provider on page 233
•
Configuring Secure Access Service as a SAML 2.0 Identity Provider on page 237
•
Configuring a SAML 2.0 ACL Web Policy on page 247
Configuring System-Wide SAML Settings
This section describes tasks related to configuring system-wide SAML settings. It includes
the following topics:
•
Configuring Global SAML Settings on page 230
•
Managing SAML Metadata Files on page 232
Configuring Global SAML Settings
The system-wide SAML settings impact all SAML service provider and identity provider
instances.
To configure global SAML settings:
1.
In the admin console, select System > Configuration > SAML.
2. Click the Settings button.
230
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
3. Complete the settings described in Table 20 on page 231.
4. Click Save Changes.
Table 20: SAML Global Settings
Setting
Description
Timeout value for
metadata fetch request
Specify the number of seconds after which a download request is abandoned. If the peer SAML
entity publishes its metadata at a remote location, the Secure Access Service downloads the
metadata file from the specified location.
Validity of
uploaded/downloaded
metadata file
Specify the maximum duration for which the Secure Access Service considers the metadata file
of the peer SAML entity to be valid. If the metadata file provided by the peer SAML entity contains
validity information, the lower value takes precedence.
Host FQDN for SAML
Specify the fully qualified domain name for the Secure Access Service host. The value you specify
here is used in the SAML entity ID and the URLs for SAML services, including:
•
Entity ID for SAML service provider and SAML identity provider instances. The SAML entitiy ID
is the URL where the Secure Access Service publishes its SAML metadata file.
•
Single sign-on service URL
•
Single logout service URL
•
Assertion consumer service URL
•
Artifact resolution service URL
BEST PRACTICE: The Secure Access Service uses HTTPS for these services. Therefore, we
recommend that you assign a valid certificate to the interface that has the IP address to which
this FQDN resolves so that users do not see invalid certificate warnings.
Alternate Host FQDN for
SAML
Optional.
If you have enabled the Reuse Existing NC (Pulse) Session on the SAML Identity Provider Sign-In
page, specify the fully qualified domain name used to generate the Secure Access Service SSO
Service URL.
Set up your DNS service to ensure that the alternate hostname resolves to a different IP address
when a session is established and when not established. We recommend the following DNS
behavior:
•
If the NC (Pulse) session is not established, the IP address of the alternate hostname should
resolve to the public IP address on the Secure Access Service external port.
•
If the NC (Pulse) session is established, the IP address of the alternate hostname should resolve
to the private IP address on the Secure Access Service internal port.
BEST PRACTICE: The Secure Access Service uses HTTPS for this service. Therefore, we recommend
that you assign a valid certificate to the interface that has the IP address to which this FQDN
resolves so that users do not see invalid certificate warnings.
Update Entity IDs
Related
Documentation
Use this button to regenerate the SAML entity IDs of all configured service providers and identity
providers. Typically, you take this action when the Host FQDN for SAML is changed.
•
Managing SAML Metadata Files on page 232
Copyright © 2013, Juniper Networks, Inc.
231
Junos Pulse Secure Access Service Administration Guide
Managing SAML Metadata Files
You use the System > Configuration > SAML pages to maintain a table of SAML metadata
files for the SAML service providers and identity providers in your network. Using SAML
metadata files makes configuration easier and less prone to error.
You can add the metadata files to the Secure Access Service by:
•
Uploading a metadata file.
•
Retrieving the metadata file from a well-known URL.
To add metadata files:
In the admin console, choose System > Configuration > SAML.
1.
2. Click New Metadata Provider.
3. Complete the settings described in Table 21 on page 232.
4. Click Save Changes.
Table 21: SAML Metadata Provider Settings
Setting
Description
Metadata Provider
Location Configuration
Use one of the following methods:
Metadata Provider
Verification Configuration
Metadata Provider Filter
Configuration
232
•
Local. Click Browse and locate the metadata file on your local host or file system.
•
Remote. Enter the URL of the metadata file. Only http and https protocols are supported.
Select options:
•
Accept Untrusted Server Certificate. If you specify a URL for the metadata provider, select this
option to allow the Secure Access Service to download the metadata file even if the server
certificate is not trusted. This is necessary only for HTTPS URLs.
•
Accept Unsigned Metadata. If this option is not selected, unsigned metadata is not imported.
Signed metadata is imported only after signature verification.
•
Signing Certificate. Click Browse and locate the certificate that verifies the signature in the
metadata file. This certificate overrides the certificate specified in the signature of the received
metadata. If no certificate is uploaded here then the certificate present in the signature of the
received metadata is used.
•
Enable Certificate Status Checking. Verify the certificate before using it. Certificate verification
applies both to the certificate specified here and the certificate specified in the signature in the
metadata file.
Select options and enter Entity IDs:
•
Roles. Select whether the metadata file includes configuration details for a SAML service
provider, identity provider, or Policy Decision Point. You may select more than one. If you select
a role that is not in the metadata file, it is ignored. If none of the selected roles are present in
the metadata file, Secure Access Service returns an error.
•
Entity IDs To Import. Enter the SAML Entity IDs to import from the metadata files. Enter only
one ID per line. Leave this field blank to import all IDs. This option is available only for uploading
local metadata files.
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
The Refresh button downloads the metadata files from the remote location even if these
files have not been modified. This operation applies only to remote locations; local
metadata providers are ignored if selected.
To refresh a metadata file:
1.
In the admin console, choose System > Configuration > SAML.
2. Select the metadata file to refresh and click Refresh.
To delete a metadata file:
1.
In the admin console, choose System > Configuration > SAML.
2. Select the metadata file to delete and click Delete.
Related
Documentation
•
Configuring Peer SAML Service Provider Settings on page 240
Configuring Secure Access Service as a SAML 2.0 Service Provider
This topic describes how to configure the Secure Access Service as a SAML service
provider. When the Secure Access Service is a SAML service provider, it relies on the
SAML identity provider authentication and attribute assertions when users attempt to
sign in to the Secure Access Service. Note that authentication is only part of the Secure
Access Service security system. The access management framework determines access
to the Secure Access Service and protected resources.
Secure Access Service supports:
•
HTTP Redirect binding for sending AuthnRequests
•
HTTP Redirect binding for sending/receiving SingleLogout requests/responses
•
HTTP POST and HTTP Artifact bindings for receiving SAML responses
Before you begin:
•
Check to see whether the SAML identity provider uses HTTP POST or HTTP Artifact
bindings for SAML assertions.
•
Check to see whether the SAML identity provider has published a SAML metadata file
that defines its configuration. If the SAML identity provider metadata file is available,
configuration is simpler and less prone to error.
•
Complete the Secure Access Service system-wide SAML settings if you have not already
done so. Select System > Configuration > SAML > Settings. For details, see “Configuring
Global SAML Settings” on page 230.
•
Add metadata for the SAML identity provider to the metadata provider list if you have
not already done so. Select System > Configuration > SAML. For details, see “Managing
SAML Metadata Files” on page 232.
Copyright © 2013, Juniper Networks, Inc.
233
Junos Pulse Secure Access Service Administration Guide
To configure the Secure Access Service as a SAML service provider:
1.
In the admin console, select Authentication > Auth. Servers.
2. Select SAML Server from the New list and then click New Server.
3. Complete the settings as described in Table 22 on page 234.
4. Click Save Changes.
After you save changes for the first time, the page is redisplayed and now has two
tabs. The Settings tab allows you to modify any of the settings pertaining to the SAML
server instance. The Users tab lists valid users of the server.
Next steps:
•
Configure the access management framework to use the SAML authentication server.
Start with realm and role mapping rules. For details, see “Creating an Authentication
Realm” on page 284 and “Specifying Role Mapping Rules for an Authentication Realm”
on page 287.
•
Configure a sign-in policy. When using a SAML authentication server, the sign-in policy
can map to a single realm only. For details, see “Defining a Sign-In Policy” on page 10.
Table 22: SAML Service Provider Profile
Setting
Description
Name
Specify a name to identify the server instance.
Settings
SAML Version
Select 2.0.
SA Entity Id
This value is prepopulated. It is generated by the system, based on the value for the Host FQDN
for SAML setting on the System > Configuration > SAML > Settings page.
Configuration Mode
Select Manual or Metadata. If a metadata file or location is available from the SAML identity
provider, use the metadata option to make configuration simpler and less prone to error. To upload
or set the location for the published metadata file, select System > Configuration > SAML and click
the New Metadata Provider button.
Identity Provider Entity ID
The identity provider entity ID is sent as the Issuer value in the assertion generated by the SAML
identity provider.
If you use the metadata option, this setting can be completed by selecting the identity provider
entity ID from the list. The list is populated by the identity provider entities defined in metadata
files added to the System > Configuration > SAML page.
If you complete this setting manually, specify the Issuer value in assertions generated by the SAML
identity provider. Typically, you ask the SAML identity provider administrator for this setting.
234
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
Table 22: SAML Service Provider Profile (continued)
Setting
Description
Identity Provider Single
Sign On Service URL
The identity provider SSO service URL is a URL provisioned by the SAML identity provider. The
setting is required to support service-provider-initiated SSO. If missing, the Secure Access Service
cannot successfully redirect the user request.
If you use the metadata option, this setting can be completed by selecting the SSO service URL
from the list. The list is populated by the identity provider entities defined in metadata files added
to the System > Configuration > SAML page.
If you complete this setting manually, ask the SAML identity provider administrator for this setting.
User Name Template
Specify how the Secure Access Service is to derive the username from the assertion. If the field is
left blank, it uses the string received in the NameID field of the incoming assertion as the username.
If you choose a certificate attribute with more than one value, the Secure Access Service 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 Secure Access Service uses “management”. To use
all values, add the SEP attribute to the variable. For example, if you enter <certDN.OUT SEP=”:”>,
the Secure Access Service uses “management:sales”. The attributes received in the attribute
statement in the incoming assertion are saved under userAttr. These variables can also be used
with angle brackets and plain text. If the username cannot be generated using the specified
template, the login fails. If the NameID filed of the incoming assertion is of type X509Nameformat,
then the individual fields can be extracted using system variable “assertionNameDN”.
Allowed Clock Skew
Specify the maximum allowed difference in time between the Secure Access Service clock and
the SAML identity provider server clock.
Support Single Logout
Single logout is a mechanism provided by SAML for logging out a particular user from all the
sessions created by the identity provider. Select this option if the Secure Access Service must
receive and send a single logout request for the peer SAML identity provider.
If you use the metadata option, the Single Logout Service URL setting can be completed by selecting
the SLO service URL from the list. The list is populated by the identity provider entities defined in
metadata files added to the System > Configuration > SAML page. The Secure Access Service
sends Single Logout requests to this URL.
In addition, if you use the metadata option, the Single Logout Response URL setting is completed
based on your selection for Single Logout Service URL. If the identity provider has left this setting
empty in its metadata file, the Secure Access Service sends the Single Logout response to the
SLO service URL.
If you complete these settings manually, ask the SAML identity provider administrator for guidance.
SSO Method
Copyright © 2013, Juniper Networks, Inc.
235
Junos Pulse Secure Access Service Administration Guide
Table 22: SAML Service Provider Profile (continued)
Setting
Description
Artifact
When configured to use the Artifact binding, the Secure Access Service contacts the Artifact
Resolution Service (ARS) to fetch the assertion using SOAP protocol. If the ARS is hosted on a
HTTPS URL, then the certificate presented by the ARS is verified by the Secure Access Service.
For this verification to pass successfully, the CA of the server certificate issued to the identity
provider ARS must be added to the trusted server CA on the Secure Access Service.
Complete the following settings to configure SAML using the HTTP Artifact binding:
POST
•
Source ID. Enter the source ID for the identity provider ARS. Source ID is Base64-encoded,
20-byte identifier for the identity provider ARS. If left blank, this value is generated by the Secure
Access Service.
•
Source Artifact Resolution Service URL. For metadata-based configuration, this field is completed
automatically from the metadata file and is not configurable. For manual configurations, enter
the URL of the service to which the SP ACS is to send ArtifactResolve requests. ArtifactResolve
requests are used to fetch the assertion from the artifact received by it.
•
SOAP Client Authentication. Select HTTP Basic or SSL Client Certificate and complete the related
settings. If you use an SSL client certificate, select a certificate from the Secure Access Service
device certificate list.
•
Select Device Certificate for Signing. Select the device certificate the Secure Access Service
uses to sign the AuthnRequest sent to the identity provider SSO service. If you do not select a
certificate, the Secure Access Service does not sign AuthnRequest.
•
Select Device Certificate for Encryption. Select the device certificate the Secure Access Service
uses to decrypt encrypted data received in the SAML response. The public key associated with
the device certificate is used by the identity provider for encryption.
When configured to use the POST binding, the Secure Access Service uses a response signing
certificate to verify the signature in the incoming response or assertion. The certificate file must
be in PEM or DER format. The certificate you select should be the same certificate used by the
identity provider to sign SAML responses.
Complete the following settings to configure SAML using the HTTP POST binding:
•
Response Signing Certificate. If you use the metadata-based configuration option, select a
certificate from the list. The list is populated by the identity provider entities defined in metadata
files added to the System > Configuration > SAML page.
If you configure these settings manually, browse to and upload the certificate to be used to
validate the signature in the incoming response or assertion.
If no certificate is specified, the certificate embedded in the response is used.
•
Enable Signing Certificate status checking. Select this option to check the validity of the signing
certificate before verifying the signature. This setting applies to any certificate used for signature
verification. If this option is enabled, the response will be rejected if the certificate is revoked,
expired, or untrusted. If this option is selected, the certificate CA must be added to the Secure
Access Service Trusted Client CA store.
If this option is not enabled then the certificate is used without any checks.
•
Select Device Certificate for Signing. Select the device certificate the Secure Access Service
uses to sign the AuthnRequest sent to the identity provider SSO service. If you do not select a
certificate, the Secure Access Service does not sign AuthnRequest.
•
Select Device Certificate for Encryption. Select the device certificate the Secure Access Service
uses to decrypt encrypted data received in the SAML response. The public key associated with
the device certificate is used by the identity provider for encryption.
Service Provider Metadata Settings
236
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
Table 22: SAML Service Provider Profile (continued)
Setting
Description
Metadata Validity
Enter the number of days the Secure Access metadata is valid. Valid values are 0 to 9999. 0
specifies the metadata does not expire.
Do Not Publish SA
Metadata
Select this option if you do not want the Secure Access Service to publish the metadata at the
location specified by the Secure Access Service Entity ID field.
Download Metadata
This button appears only after you have saved the authentication server configuration. Use this
button to download the metadata of the current SAML service provider.
User Record Synchronization
Enable User Record
Synchronization
Allow users to retain their bookmarks and individual preferences regardless of which Secure Access
Service device they log in to.
Logical Auth Server Name
Related
Documentation
•
Understanding SAML 2.0 on page 221
•
Secure Access Service SAML 2.0 Supported Features Reference on page 222
Configuring Secure Access Service as a SAML 2.0 Identity Provider
This topic describes how to configure the Secure Access Service as a SAML identity
provider. It includes the following sections:
•
Configuration Overview on page 237
•
Configuring Sign-in SAML Metadata Provider Settings on page 238
•
Configuring Sign-in SAML Identity Provider Settings on page 238
•
Configuring Peer SAML Service Provider Settings on page 240
•
Configuring a SAML SSO Resource Policy for Gateway Mode Deployments on page 244
•
Configuring a SAML SSO External Applications Policy on page 246
Configuration Overview
Implementing Secure Access Service as a SAML identity provider includes the following
basic steps.
1.
Configure system-wide SAML settings. Select System > Configuration > SAML >
Settings. See “Configuring Global SAML Settings” on page 230.
2. Add SAML metadata provider files. Select System > Configuration > SAML. See
“Managing SAML Metadata Files” on page 232.
3. Configure Sign-In SAML metadata provider settings. See “Configuring Sign-in SAML
Metadata Provider Settings” on page 238.
4. Configure Sign-In SAML identity provider settings. See “Configuring Sign-in SAML
Identity Provider Settings” on page 238.
Copyright © 2013, Juniper Networks, Inc.
237
Junos Pulse Secure Access Service Administration Guide
5. Configure peer service provider settings. See “Configuring Peer SAML Service Provider
Settings” on page 240.
6. Configure a resource policy:
•
For gateway mode deployments, configure a SAML SSO resource policy. See
“Configuring a SAML SSO Resource Policy for Gateway Mode Deployments” on
page 244.
•
For peer mode deployments, configure a SAML SSO external applications policy.
See “Configuring a SAML SSO External Applications Policy” on page 246.
Configuring Sign-in SAML Metadata Provider Settings
Sign-in SAML metadata provider settings determine how Secure Access Service identity
provider metadata is published.
To configure the identity provider metadata publication settings:
1.
In the admin console, select Authentication > Signing In > Sign-In SAML > Metadata
Provider.
2. Complete the settings described in Table 23 on page 238.
3. Click Save Metadata Provider to save your changes.
Table 23: Sign-in SAML Identity Provider Metadata Provider Settings
Setting
Description
Entity ID
This value is prepopulated. It is generated by the system, based on the value for the Host FQDN
for SAML setting on the System > Configuration > SAML > Settings page.
Metadata Validity
Specify the maximum duration for which a peer SAML entity can cache the Secure Access Service
SAML metadata file. Valid values are 1 to 9999. The default is 365 days.
Do Not Publish SA
Metadata
Select this option if you do not want the Secure Access Service to publish the metadata at the
location specified by the Secure Access Service Entity ID field. You can use this option to toggle
off publication without deleting your settings.
Download Metadata
Use this button to download the Secure Access Service SAML identity provider metadata.
Configuring Sign-in SAML Identity Provider Settings
The settings defined in this procedure are the default settings for Secure Access Service
SAML identity provider communication with all SAML service providers. If necessary, you
can use the peer service provider configuration to override these settings for particular
service providers.
To configure sign-in SAML identity provider settings:
1.
238
In the admin console, select Authentication > Signing In > Sign-In SAML > Identity
Provider.
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
2. Complete the settings described in Table 24 on page 239.
3. Click Save Changes.
Table 24: Sign-in SAML Identity Provider Settings
Setting
Description
Basic Identity Provider (IdP) Configuration (Published in Metadata)
Protocol Binding to use for
SAML Response
Select POST, Artifact, or both, depending on your total requirements.
Signing Certificate
Select the certificate used to sign the SAML messages sent by the Secure Access Service. The
certificates listed here are configured on the System > Configuration > Certificate > Device
Certificates page.
Decryption Certificate
Select the certificate used to decrypt the SAML messages sent by peer service providers. The
public key associated with this certificate is used by the peer service provider to encrypt SAML
messages exchanged with this identity provider. The decryption certificate must be configured if
the peer service provider encrypts the SAML messages sent to the Secure Access Service. The
certificates listed here are configured on the System > Configuration > Certificate > Device
Certificates page.
Other Configurations
Reuse Existing NC (Pulse) Session. This feature applies to an service-provider-initiated SSO
scenario—that is, when a user clicks a link to log into the service provider site. The service provider
redirects the user to the identity provider SSO Service URL.
If this option is selected, a user with an active NC/Pulse session is not prompted to authenticate.
The Secure Access Service uses information from the existing session to form the SAML response.
Accept unsigned AuthnRequest. In an service-provider-initiated SSO scenario, the SP sends an
AuthnRequest to the identity provider. This AuthnRequest could be either signed or unsigned. If
this option is unchecked, the Secure Access Service rejects unsigned AuthnRequests. Note that
the Secure Access Service also rejects signed AuthnRequests if signature verification fails.
Service-Provider-Related IdP Configuration
Relay State
SAML RelayState attribute sent to the service provider in an identity-provider-initiated SSO
scenario. If left blank, the RelayState value is the URL identifier of the resource being accessed.
Session Lifetime
Suggest a maximum duration of the session at the service provider created as a result of the SAML
SSO. Select one of the following options:
•
None. The identity provider does not suggest a session duration.
•
Role Based. Suggest the value of the session lifetime configured for the user role.
•
Customized. If you select this option, the user interface displays a text box in which you specify
a maximum in minutes.
Sign-In Policy
Select the sign-in URL to which the user is redirected in an service-provider-initiated scenario.
The list is populated by the sign-in pages configured on the Authentication > Signing In > Sign-in
Policies page.
Note: The user is not redirected if he or she already has a session with the Secure Access Service
and had authenticated through this sign-in policy.
Copyright © 2013, Juniper Networks, Inc.
239
Junos Pulse Secure Access Service Administration Guide
Table 24: Sign-in SAML Identity Provider Settings (continued)
Setting
Description
Force Authentication
Behavior
In an service-provider-initiated scenario, the service provider sends an AuthnRequest to the identity
provider. If the service provider AuthnRequest includes the ForceAuthn attribute set to true and
the user has a valid Secure Access Service session, this setting determines how the identity provider
responds. Select one of the following options:
•
Reject AuthnRequest. Do not honor the SAML SSO request.
•
Re-Authenticate User. Invalidate the user session and prompt for reauthentication.
Note: This setting prevails over the Pulse session reuse setting.
User Identity
Subject Name Format. Format of the NameIdentifier field in the generated assertion. Select one
of the following options:
•
DN. Username in the format of DN(distinguished name).
•
Email address. Username in the format of an email address.
•
Windows. Username in the format of a Windows domain qualified username.
•
Other. Username in an unspecified format.
Subject Name. Template for generating the username that is sent as the value of the NameIdentifier
field in the assertion.
You may use any combination of available system or custom variables contained in angle brackets
and plain text.
Web Service
Authentication
These settings apply when the HTTP Artifact binding is used.
Authentication Type. Method used to authenticate the service provider assertion consumer service
to the identity provider on the Secure Access Service system. Select one of the following options:
•
None. Do not authenticate the assertion consumer service.
•
Username/Password. If you select this option, use the controls to specify username and password
settings.
•
Certificate. For certificate-based authentication, the Client CA of the service provider should
be present in Secure Access Service system Trusted Client CA list (located on the System >
Configuration > Certificates > Trusted Client CAs page).
Artifact configuration
These settings apply when the HTTP Artifact binding is used.
Source ID. This is the Base64-encoded, 20-byte identifier of the Artifact Resolution Service on
the identity provider.
Enable Artifact Response Signing and Encryption. If checked, the identity provider signs and
encrypts the artifact response.
Configuring Peer SAML Service Provider Settings
The peer service provider list defines the set of service providers configured to
communicate with the Secure Access Service SAML identity provider. When you add a
peer service provider to the list, you can customize the SAML identity provider settings
used to communicate with the individual service provider. If the service provider provides
a SAML metadata file, you can use it to simplify configuration, or you can complete more
240
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
detailed manual steps. If available, we recommend you use metadata so that
configuration is simpler and less prone to error.
To configure peer SAML service provider settings:
1.
In the admin console, select Authentication > Signing In > Sign-In SAML > Identity
Provider.
2. Under Peer Service Provider Configuration, create a list of service providers that are
SAML peers to the Secure Access Service SAML identity provider. To add a service
provider to the list, click Add SP.
3. Complete the settings described in Table 25 on page 241.
4. Click Save Changes.
Table 25: Peer Service Provider Configuration
Setting
Description
Configuration Mode
Select Manual or Metadata.
Service Provider Configuration - Metadata
Entity Id
If you use metadata, select the SAML entity ID of the service provider. This list contains all the
service providers specified in all the metadata files added to the System > Configuration > SAML
page.
Select certificates
manually
When you use the metadata configuration, the Secure Access Service SAML identity provider
iterates through all the signature verification certificates specified when verifying the incoming
SAML messages coming from the service provider. Similarly, when encrypting the SAML messages
going out, the Secure Access Service SAML identity provider encrypts the messages with the first
valid encryption certificate encountered in the metadata.
Select this option to override this default behavior and select certificates manually.
Signature Verification
Certificate
If you select the Select certificates manually option, select the certificate to be used by the identity
provider to verify the signature of incoming SAML messages.
Encryption Certificate
If you select the Select certificates manually option, select the certificate to be used if the assertions
sent by the identity provider must be encrypted.
Service Provider Configuration - Manual
Entity Id
If you are completing a manual configuration, ask the SAML service provider administrator for
this setting.
Assertion Consumer
Service URL
SAML service provider URL that receives the assertion or artifact sent by the identity provider.
Protocol Binding supported
by the Assertion Consumer
Service at the SP
Select POST, Artifact, or both. This setting must be consistent with the SAML identity provider
configuration.
Copyright © 2013, Juniper Networks, Inc.
241
Junos Pulse Secure Access Service Administration Guide
Table 25: Peer Service Provider Configuration (continued)
Setting
Description
Default Binding
If both POST and Artifact bindings are supported, which is the default?
•
Post
•
Artifact
This setting must be consistent with the SAML identity provider configuration.
Signature Verification
Certificate
Upload the certificate to be used by the identity provider to verify the signature of incoming SAML
messages. If no certificate is specified, the certificate embedded in the incoming SAML message
is used for signature verification.
Encryption Certificate
Upload the certificate to be used if the assertions sent by the identity provider must be encrypted.
If not certificate is specified, the assertions sent by the identity provider are not encrypted.
Certificate Attribute
Configuration for Artifact
Resolution Service
Optional. Specify attributes that must be present in the certificate presented to the Artifact
Resolution Service (ARS) at the identity provider by the service provider assertion consumer
service.
This option appears only if the SAML service provider supports the HTTP Artifact binding, the
Secure Access Service SAML identity provider has been configured to support the HTTP Artifact
binding, and the Web service authentication type specified for the service provider is Certificate.
Certificate Status Checking Configuration
Enable signature
verification certificate
status checking
Select this option to enable revocation checks for the signing certificate. Uses the configuration
on the System > Configuration > Certificates > Trusted Client CAs page.
Enable encryption
certificate status checking
Select this option to enable revocation checks for the encryption certificate. Uses the configuration
on the System > Configuration > Certificates > Trusted Client CAs page.
Customize identity provider Behavior
Override Default
Configuration
Select this option to set custom behavior of the Secure Access Service SAML identity provider
for this SP instance. If you select this option, the user interface displays the additional options
listed next.
Reuse Existing NC (Pulse)
Session
This option cannot be enabled here if it is not selected for the sign-in SAML identity provider
default settings.
Accept unsigned
AuthnRequest
Individual service providers can choose to accept unsigned AuthnRequest.
Relay State
SAML RelayState attribute sent to the service provider in an identity-provider-initiated SSO
scenario. If left blank, the RelayState value is the URL identifier of the resource being accessed.
Session Lifetime
Suggest a maximum duration of the session at the service provider created as a result of the SAML
SSO. Select one of the following options:
•
None. The identity provider does not suggest a session duration.
•
Role Based. Suggest the value of the session lifetime configured for the user role.
•
Customized. If you select this option, the user interface displays a text box in which you specify
a maximum in minutes.
242
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
Table 25: Peer Service Provider Configuration (continued)
Setting
Description
Sign-In Policy
Select the Sign-In URL to which the user is redirected in an service-provider-initiated scenario.
The list is populated by the sign-in pages configured in Authentication > Signing In > Sign-in
Policies.
Note: The user is not redirected if he or she already has a session with the Secure Access Service
and had authenticated through this sign-in policy.
Force Authentication
Behavior
In an service-provider-initiated scenario, the service provider sends an AuthnRequest to the identity
provider. If the service provider AuthnRequest includes the ForceAuthn attribute set to true and
the user has a valid Secure Access Service session, this setting determines how the identity provider
responds. Select one of the following options:
•
Reject AuthnRequest. Do not honor the SAML SSO request.
•
Re-Authenticate User. Invalidate the user session and prompt for reauthentication.
Note: This setting prevails over the Pulse session reuse setting.
User Identity
Subject Name Format. Format of NameIdentifier field in generated Assertion. Select one of the
following options:
•
DN. Username in the format of DN (distinguished name).
•
Email address. Username in the format of an e-mail address.
•
Windows. Username in the format of a Windows domain qualified username.
•
Other. Username in an unspecified format.
Subject Name. Template for generating the username that is sent as the value of the NameIdentifier
field in the assertion.
You may use any combination of available system or custom variables contained in angle brackets
and plain text.
Web Service
Authentication
These settings apply when the HTTP Artifact binding is used.
Authentication Type. Method used to authenticate the service provider assertion consumer service
to the identity provider on the Secure Access Service system. Select one of the following options:
•
None. Do not authenticate the assertion consumer service.
•
Username/Password. Use the controls to specify username and password settings.
•
Certificate. For certificate-based authentication, the client CA of the service providers should
be present in the Secure Access Service system trusted client CA list (located on the System
> Configuration > Certificates > Trusted Client CAs page).
Artifact configuration
These settings apply when the HTTP Artifact binding is used.
Source ID. This is the Base64-encoded, 20-byte identifier of the Artifact Resolution Service on
the identity provider.
Enable Artifact Response Signing and Encryption. If checked, the identity provider signs and
encrypts the Artifact response.
Copyright © 2013, Juniper Networks, Inc.
243
Junos Pulse Secure Access Service Administration Guide
Configuring a SAML SSO Resource Policy for Gateway Mode Deployments
When deployed as a gateway in front of enterprise resources, the SAML SSO policy acts
like other Secure Access Service resource policies. The Secure Access Service maintains
the session and uses its rewriting or pass-through proxy features to render data to the
user. You use a SAML SSO resource policy when the protected resource supports SAML
SSO and has been configured as a SAML service provider. When deployed as a gateway,
the SAML SSO communication is always identity-provider-initiated.
Figure 14 on page 244 illustrates a gateway mode deployment.
Figure 14: Secure Access Service as a SAML identity provider (Gateway
Mode)
User
1
2
Identity
provider
g037732
3
Service
provider
1 — A user logs into the Secure Access Service.
2 — The user requests a resource protected by a security system that supports SAML and has implemented a SAML service
provider.
3 – The SAML identity provider initiates the SAML authentication request to the SAML service provider. Users are granted access
to particular resources according to the Secure Access Service SAML SSO resource policy.
244
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
To configure a SAML SSO resource policy:
In the admin console, select Users > Resource Policies > Web.
1.
2. Use the tabs to display the SSO > SAML page.
If your administrator view is not configured to show SAML policies, click the Customize
button in the upper-right corner of the page and select the SSO and SAML check
boxes.
3. Click New Policy.
4. Complete the settings described in Table 26 on page 245.
5. Click Save Changes.
Table 26: SAML SSO Resource Policy Settings
Setting
Description
Name
Type a name for the policy.
Description
Type a description that would be meaningful to other administrators.
Resources
Specify the fully qualified domain name for the resources for which this policy applies. These are
the resources protected at the SAML service provider.
Roles
Select one of the following options:
•
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.
Action
Select one of the following options:
•
Use the SAML SSO defined below. Typically, this is the setting you use for a SAML SSO resource
policy. The Secure Access Service SAML identity provider makes the SSO request when a user
tries to access a SAML resource specified in the Resources list.
•
Do NOT use SAML. Secure Access Service does not perform an SSO request. Use this if there
is a problem with the SAML service provider and you want to allow access.
•
SAML SSO Details
Use Detailed Rules. Use this option to configure advanced rules.
SAML Version. Select 2.0.
Service Provider Entity ID. Select the service provider entity ID. The service provider entity IDs listed
here are configured on the Authentication > Signing In > Sign-in SAML > Identity Provider > Peer
Service Provider pages.
Cookie Domain. Enter a comma-separated list of domains to which Secure Access Service sends
the SSO cookie.
Copyright © 2013, Juniper Networks, Inc.
245
Junos Pulse Secure Access Service Administration Guide
NOTE: The SAML SSO resource policy settings differ from Secure Access
Service 7.1 to 7.2. Policies you created with Secure Access Service 7.1 are
preserved in edit-only mode for legacy use.
Configuring a SAML SSO External Applications Policy
When deployed to support access to external resources (for example, public cloud
resources), the Secure Access Service does not have to be a gateway to user access.
The user can access the external resource directly, and the traffic does not flow through
the Secure Access Service device. To enable SAML SSO in these deployments, you
configure the Secure Access Service as a SAML identity provider to correspond with the
external SAML service provider, and you configure an SSO SAML external applications
policy to determine the users and resources to which the SAML SSO experience applies.
To configure a SAML External Apps resource policy:
In the admin console, select Users > Resource Policies > Web.
1.
2. Use the tabs to display the SSO > SAML External Apps page.
If your administrator view is not configured to show SAML policies, click the Customize
button in the upper-right corner of the page and select the SSO and SAML check
boxes.
3. Click New Policy.
4. Complete the settings described in Table 27 on page 246.
5. Click Save Changes.
Table 27: SAML SSO External Applications Policy Settings
Setting
Description
Name
Type a name for the policy.
Description
Type a description that would be meaningful to other administrators.
Resources
Specify the fully qualified domain name for the resources for which this policy applies. These are
the resources protected at the SAML service provider.
Roles
Select one of the following options:
•
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.
246
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
Table 27: SAML SSO External Applications Policy Settings (continued)
Setting
Description
Action
Select one of the following actions:
•
Use the SAML SSO defined below. Typically, this is the setting you use for a SAML SSO resource
policy. The Secure Access Service SAML identity provider 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 Service does not perform an SSO request. Use this if there
is a problem with the SAML service provider and you want to allow access.
•
SAML SSO Details
Use Detailed Rules. Use this option to configure advanced rules.
SAML Version. Select 2.0.
Service Provider Entity ID. Select the service provider entity ID. The service provider entity IDs listed
here are configured on the Authentication > Signing In > Sign-in SAML > Identity Provider > Peer
Service Provider pages.
Related
Documentation
Example: Implementing SAML 2.0 Web Browser SSO for Google Apps on page 249
•
Configuring a SAML 2.0 ACL Web Policy
To configure the Secure Access Service as a policy enforcement point, you must create
a SAML ACL web policy.
To configure a SAML ACL web policy:
1.
In the admin console, select Users > Resource Policies > Web.
2. Use the tabs to display the Access > SAML ACL page.
If your administrator view is not configured to show SAML policies, click the Customize
button in the upper-right corner of the page and select the SAML ACL check box.
3. On the SAML Access Control Policies page, click New Policy.
4. Complete the settings described in Table 28 on page 247.
5. Click Save Changes.
6. On the SAML Access Control Policies page, order the policies according to how you
want the Secure Access Service to evaluate them. Keep in mind that once the Secure
Access Service 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.
Table 28: SAML ACL Web Policy Settings
Setting
Description
Name
Type a name for the policy.
Description
Type a description that would be meaningful to other administrators.
Copyright © 2013, Juniper Networks, Inc.
247
Junos Pulse Secure Access Service Administration Guide
Table 28: SAML ACL Web Policy Settings (continued)
Setting
Description
Resources
Specify the fully qualified domain name for the resources for which this policy applies. These are
the resources protected at the SAML service provider.
Roles
Select one of the following options:
•
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.
Action
Select one of the following options:
•
Use the SAML Access Control checks defined below. Secure Access Service performs an access
control check to the specified URL using the data specified in the SAML Access Control Details
section.
SAML Access Control
Details
•
Do not use SAML Access. The Secure Access Service does not perform an access control check.
•
Use Detailed Rules. Use this option to configure advanced rules.
SAML Version. Select 2.0.
Configuration Mode. If you select manual, complete the SAML Access Control details. If you select
Metadata, select the policy decision point to use.
If the metadata option is disabled, you have not defined or uploaded a metadata file on the System
> Configuration > SAML page.
SAML Web Service URL. Completed automatically if using metadata. If you configure manually,
enter the URL of the access management system SAML server. For example, enter
https://hostname/ws.
SAML Web Service Issuer. Enter the hostname of the issuer, typically the hostname of the access
management system.
NOTE: You must enter unique string that the SAML Web service uses to identify itself in
authorization assertions.
Authentication Type
Select one of the following options:
•
None—Do not authenticate the Secure Access Service.
•
Username—Authenticate using a username and password. Enter the username and password
that the Secure Access Service must send the Web service.
•
Certificate Attribute—Authenticate using a certificate signed by a trusted certificate authority.
If you have more than one certificate installed on the Secure Access Service, use the drop-down
list to select which certificate to send to the Web service.
248
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
Table 28: SAML ACL Web Policy Settings (continued)
Setting
Description
User Identity
Subject Name Type—Specify which method the Secure Access Service and SAML Web service
should use to identify the user. Select one the following options:
•
DN—Send the username in the format of a DN (distinguished name) attribute.
•
Email Address—Send the username in the format of an e-mail address.
•
Windows—Send the username in the format of a Windows domain qualified username.
•
Other—Send the username in another format agreed upon by the Secure Access Service and
the SAML Web service.
Subject Name—Use variables to specify the username to the SAML Web service. Or, enter static
text.
NOTE: You must send a username or attribute that the SAML Web service will recognize.
Device Issuer—Enter a name that uniquely identifies the SAML authority, such as the device
hostname.
Maximum Cache Time
You can eliminate the overhead of generating an authorization decision each time the user requests
the same URL by indicating that the Secure Access Service must cache the access management
system’s authorization responses. Enter the amount of time the Secure Access Service should
cache the responses (in seconds).
Ignore Query Data
By default, when a user requests a resource, the Secure Access Service sends the entire URL for
that resource (including the query parameter) to the SAML Web service and caches the URL. You
can specify that the Secure Access Service should remove the query string from the URL before
requesting authorization or caching the authorization response.
Related
Documentation
•
Understanding SAML 2.0 on page 221
•
Secure Access Service SAML 2.0 Supported Features Reference on page 222
Example: Implementing SAML 2.0 Web Browser SSO for Google Apps
This example shows how to implement SAML 2.0 Web browser SSO for Google Apps.
It includes the following sections:
•
Topology on page 249
•
Configuring the Google Apps SAML service provider on page 251
•
Configuring the Secure Access Service SAML Identity Provider on page 253
•
Verifying the Google Apps SAML SSO Deployment on page 257
Topology
When deployed to support access to external resources (for example, public cloud
resources), the Secure Access Service does not have to be a gateway to user access.
The user can access the external resource directly, and the traffic does not flow through
the Secure Access Service device. You configure the Secure Access Service as a SAML
identity provider to correspond with the external SAML service provider, and you configure
Copyright © 2013, Juniper Networks, Inc.
249
Junos Pulse Secure Access Service Administration Guide
a SAML SSO external applications policy to determine the users and resources to which
the SAML SSO experience applies.
When you configure the SAML identity provider, some settings are necessary to support
either identity-provider-initiated or service-provider-initiated SSO. The documentation
for the configuration steps makes note of these settings. Regardless, you configure the
SAML identity provider to support both identity-provider-initiated and
service-provider-initiated SSO.
Figure 15 on page 250 illustrates the flow of network communication in a
service-provider-initiated SSO scenario.
Figure 15: Secure Access Service as a SAML Identity Provider (Peer Mode)
in a Service-Provider-Initiated SSO Scenario
User
2.2
1
2b
3b
2a
3a
Identity provider
Service
provider
g037731
2.1
4
1 – The user clicks a link to access a resource.
2a – The service provider sends an HTTP redirect status code (HTTP 302) to the user. The SAML request and all other SAML
details are sent as URL parameters in the URL Location header.
2b – The user sends an HTTP GET request to the identity provider. The SAML request and all other SAML details are sent as
URL parameters.
If the user already has a session with the identity provider, steps 2.1 and 2.2 are skipped.
2.1 – If the user does not have a session, the identity provider sends an authentication challenge to the user.
2.2 – The user enters sign-in credentials.
3a – The identity provider sends a successful status code (HTTP 200 OK) to the user with a form in the HTML body.
3b – The user sends the form to the service provider.
4 – The external resource is delivered to the user’s browser.
250
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
Figure 16 on page 251 illustrates the flow of network communication in an
identity-provider-initiated SSO scenario.
Figure 16: Secure Access Service as a SAML Identity Provider (Peer Mode)
in an Identity-Provider-Initiated SSO Scenario
User
1
3
4b
5
4a
Identity provider
Service
provider
g037733
2
1 – The user authenticates to the identity provider.
2 – The identity provider returns a portal page with links to external resources.
3 – The user clicks a link for an external resource.
4a – The identity provider sends a successful status code (HTTP 200 OK) to the user with a form in the HTML body.
4b – The user sends the form to the service provider.
5 – The external resource is delivered to the user’s browser.
Configuring the Google Apps SAML service provider
To configure the Google Apps SAML service provider:
1.
Log into the Google Apps control panel. The URL is similar to the following:
https://www.google.com/a/cpanel/acmegizmo.com.
2. Click Advanced Tools in the menu bar.
3. Click the Set up single sign-on (SSO) link to display its configuration page, as shown
in Figure 17 on page 252.
4. Configure the SAML service provider settings as described in Table 29 on page 252.
5. Click Save Changes.
Copyright © 2013, Juniper Networks, Inc.
251
Junos Pulse Secure Access Service Administration Guide
Figure 17: Google Apps Advanced Tools: SSO
Table 29: Google Apps SSO Configuration
Setting
Description
Enable Single Sign-on
Select this option.
Sign-in page URL
Type the URL of the Secure Access Service SAML SSO service. The URL formed with the primary
host FQDN for SAML has the following form:
https://SAMLHostName/dana-na/auth/saml-sso.cgi
For example:
https://i5.lab.juniper.net/dana-na/auth/saml-sso.cgi
The URL formed with the alternate host FQDN for SAML (to support Pulse/NC session detection)
has the following form:
https://i5pulse.lab.juniper.net/dana-na/auth/saml-sso.cgi
252
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
Table 29: Google Apps SSO Configuration (continued)
Setting
Description
Sign-out page URL
We recommend using the URL for the sign-in page for the realm associated with the Secure Access
Service SAML identity provider. Users who already have a session will be directed to the sign-in
page and can decide whether to log out from the Secure Access Service or not. The default sign-in
URL has the form:
https://FQDN
For example:
https://i5.lab.juniper.net/
Change password URL
We recommend using the URL for the sign-in page for the realm associated with the Secure Access
Service SAML identity provider. Secure Access Service provides password management capabilities
for some back-end auth servers (such as AD, LDAP, or Local Auth). When implemented, the
password management capabilities are accessed from the sign-in page. The default sign-in URL
has the form:
https://FQDN
For example:
https://i5.lab.juniper.net/
Verification certificate
Click Browse and select the Secure Access Service device certificate. Then click Upload and ensure
that the certificate is saved.
Use a domain specific
issuer
Select this option.
Network masks
Do not select.
Configuring the Secure Access Service SAML Identity Provider
You configure the Secure Access Service SAML identity provider settings to match the
Google Apps SAML service provider settings.
Copyright © 2013, Juniper Networks, Inc.
253
Junos Pulse Secure Access Service Administration Guide
To configure Secure Access Service SAM identity provider settings:
1.
In the admin console, select System > Configuration > SAML > Settings to complete
the global SAML settings. These settings apply to all of your SAML deployments.
Figure 18 on page 254 shows an example of SAML global settings.
Figure 18: SAML Global Settings
2. Select Authentication > Signing In > Sign-In SAML > Identity Provider to configure SAML
identity provider settings. These settings apply to all of your deployments where the
Secure Access Service is a SAML identity provider. Figure 19 on page 255 shows an
example of SAML identity provider settings.
254
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
Figure 19: SAML Identity Provider Settings
3. On the SAML Sign-In Identity Provider page, click Add SP and complete the settings
for communication with Google Apps. Google Apps does not publish metadata, so
the configuration is manually configured. The Google SAML service provider uses the
HTTP POST binding and takes usernames in e-mail address format.
Figure 20 on page 256 shows an example of SP settings for Google Apps.
Copyright © 2013, Juniper Networks, Inc.
255
Junos Pulse Secure Access Service Administration Guide
Figure 20: Peer SP Settings
4. Select Users > Resource Policies > Web > SSO > SAML SSO External Apps and complete
settings for the external applications policy that controls the users and the resources
that can use the SSO implementation. Figure 21 on page 257 shows an example of an
SAML SSO external applications policy for Google Apps.
256
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
Figure 21: External Applications Policy Settings
Verifying the Google Apps SAML SSO Deployment
Access a Google Docs or Google Apps resource as a non-admin user to verify the solution
works as expected.
Copyright © 2013, Juniper Networks, Inc.
257
Junos Pulse Secure Access Service Administration Guide
TIP: Use a browser plugin such as HTTP Watch if you want to trace the SAML
communication between the SAML service provider and SAML identity
provider.
To verify service-provider-initiated SSO:
1.
Make sure you are not logged into the Secure Access Service or Google.
2. Open a Web browser and open a location on Google Docs or Google Apps. Google
Apps redirects you to the Secure Access Service sign-in page to authenticate.
3. Log in.
The Secure Access Service redirects you to the Google Docs or Google Apps location
you had requested.
To verify Pulse/NC session detection for service-provider-initiated SSO:
1.
Make sure you are not logged into the Secure Access Service or Google.
2. Use Pulse or VPN tunneling client to create an SSL VPN connection.
3. Open a Web browser and open a location on Google Docs or Google Apps.
You should not have to authenticate to access the Google Docs or Google Apps
location.
To verify identity-provider-initiated SSO:
1.
Use the Secure Access Service admin console to create a bookmark to a location on
Google Docs or Google Apps.
2. As a user, log in to the Secure Access Service.
3. Click the bookmark link to the Google Docs or Google Apps location.
You should not have to authenticate to access the Google Docs or Google Apps
location.
Related
Documentation
•
Google Code: SAML Single Sign-on (SSO) Service for Google Apps
•
Google Support: SSO (Single Sign-on)
•
Configuring Secure Access Service as a SAML 2.0 Identity Provider on page 237
Junos Pulse Secure Access Service SAML 1.1 Support
The trend in SAML deployments is converging on the SAML 2.0 specification. Junos Pulse
Secure Access Service Release 7.2 continues to support SAML 1.1. The following sections
reprint previous information we have provided about SAML 1.1 deployments:
258
•
About SAML Version 1.1 on page 259
•
Secure Access Service SAML Version 1.1 Configuration Tasks on page 270
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
About SAML Version 1.1
The following topics provide background information about SAML version 1.1:
•
Understanding SAML 1.1 on page 259
•
Understanding SAML 1.1 Profiles on page 261
•
Understanding SAML 1.1 Assertions on page 264
•
Creating a Trust Relationship Between SAML 1.1 Systems on page 266
Understanding SAML 1.1
The Secure Access Service enables you to pass user and session state information
between the Secure Access Service and another trusted access management system
that supports the Security Assertion 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.
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 Secure Access Service supports two SAML use case scenarios:
•
The Secure Access Service as the SAML authority—The user signs into a resource by
way of the Secure Access Service first, and all other systems are SAML receivers, relying
on the Secure Access Service for authentication and authorization of the user. Under
this scenario, the Secure Access Service can use either an artifact profile or a POST
profile.
•
The Secure Access Service as the SAML receiver—The user signs into another system
on the network first, and the Secure Access Service is the SAML receiver, relying on the
other system for authentication and authorization of the user.
For example, in the first scenario, an authenticated Secure Access Service user named
John Smith may try to access a resource protected by an access management system.
When he does, the Secure Access Service 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 Secure Access Service (and therefore trust that the Secure Access Service 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 Secure Access
Service.
Copyright © 2013, Juniper Networks, Inc.
259
Junos Pulse Secure Access Service Administration Guide
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 Secure Access Service. 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 Secure Access Service, which can decide whether or
not to link to the reference.
3. If the Secure Access Service links to the reference, the portal sends a SOAP message
containing the SAML assertion (an XML message containing the user’s credentials)
to the Secure Access Service, which can then decide whether or not to allow the user
access to the requested resource.
NOTE: SOAP requests generated by the Secure Access Service (when
configured as a SAML 1.1 consumer) are not signed.
4. If the Secure Access Service allows the user access, the Secure Access Service presents
to the user the requested resource.
5. If the Secure Access Service rejects the SAML assertion, or the user credentials, the
Secure Access Service responds to the user with an error message.
When configuring the Secure Access Service, 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 resubmitting his credentials. In
this type of transaction, the Secure Access Service can be either the SAML authority
or the SAML receiver. When acting as the SAML authority, the Secure Access Service
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 Secure Access Service, the user is seamlessly
signed into the assertion consumer service using the username contained in the
statement.
When acting as the SAML receiver, the Secure Access Service 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 Secure
Access Service must interpret, based on criteria that the Secure Access Service
administrator has specified in a SAML server instance definition. If the Secure Access
Service chooses to trust the asserting party, the Secure Access Service allows the user
to sign in seamlessly using the credentials contained in the SAML assertion.
•
260
Access control authorization—In a SAML access control transaction, the Secure Access
Service asks an access management system whether the user has access. In this type
of transaction, the Secure Access Service is the relying party (also called a policy
enforcement point in access control transactions). It consumes and enforces an
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
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
Secure Access Service user has sufficient access privileges, the user may access the
requested resource
The Secure Access Service does not support attribute statements, which declare
specific details about the user (such as “John Smith is a member of the gold group”).
The Secure Access Service 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 Secure Access Service also allows you
to define users’ access rights to a URL using Secure Access Service-only mechanisms
(Users > Resource Profiles > Web Applications/Pages tab). If you define access controls
through the Secure Access Service as well as through a SAML authority, both sources
must grant access to a URL for a user to access it. For example, you may configure a
Secure Access Service 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 Secure Access Service 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 Secure Access
Service receives an indeterminate response, it denies the user access.
The session timeouts on the Secure Access Service and your access management
system may not coordinate with one another. If a user’s access management system
session cookie times out before his Secure Access Service destination signaling identifier
(DSID) cookie 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
•
Configuring SAML 1.1 SSO Profiles on page 272
Understanding SAML 1.1 Profiles
The Secure Access Service 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 the Secure Access Service first,
and then to access the Secure Access Service with single sign-on (SSO) through the
SAML consumer service.
As a result, the user who authenticates elsewhere can access resources behind the Secure
Access Service 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
Copyright © 2013, Juniper Networks, Inc.
261
Junos Pulse Secure Access Service Administration Guide
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:
The user accesses a source site through a browser. The source site might be a corporate
portal using a non-Secure Access Service authentication access management system.
1.
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 a link on the source site, which points to a resource on a server
that is protected behind the Secure Access Service.
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. The Secure Access Service accepts the assertion as a valid authentication if the
elapsed time falls within the allowable clock skew time. If the user also meets the
other Secure Access Service policy restrictions, the Secure Access Service grants the
user access to the requested resource.
The main tasks you are required to fulfill to support the Secure Access Service as the
relying party with the artifact profile include:
•
•
262
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 Service
process, which:
•
Maps the SAML assertion to a local user.
•
Creates a Secure Access Service user session.
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
•
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 website, 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 website.
7. The portal application directs the request to the local intersite 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.
8. The intersite 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 website’s assertion
consumer service.
10. The replying party's assertion consumer (in this case, on the destination website)
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. The Secure Access Service, on the destination site, verifies that the user is authorized
to access the destination site and the TARGET resource.
13. If the user is authorized to access the destination site and the TARGET resource, the
Secure Access Service returns the TARGET resource to the browser.
The main tasks you are required to fulfill to support the Secure Access Service as the
relying party with the POST profile include:
•
Implement the assertion consumer service, which receives and processes the POST
form
•
Integrate the assertion consumer service with the existing Secure Access Service
process, which:
Copyright © 2013, Juniper Networks, Inc.
263
Junos Pulse Secure Access Service Administration Guide
Related
Documentation
•
•
Maps the SAML assertion to a local user.
•
Creates a Secure Access Service user session.
•
Performs local authorization.
•
Serves the resource or denies access.
Understanding SAML 1.1 Assertions on page 264
Understanding SAML 1.1 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—the Secure Access
Service—can authenticate a user who has signed in to the source site and who now
wants to access a resource protected by the Secure Access Service. The source site
sends the artifact to the Secure Access Service in a redirect, after the user attempts
to access a resource protected by the Secure Access Service. The artifact contains:
•
TypeCode—A 2-byte hex code of 0x0001 that identifies the artifact type.
•
SourceID—A Base64-encoded string of 20 bytes that determines the source site
identity and location. You can use OpenSSL or similar Base64 encoding tool to
generate the encoded string. The Secure Access Service maintains a table of SourceID
values and the URL for the corresponding SAML responder. The Secure Access
Service and the source site communicate this information in a back channel. On
receiving the SAML artifact, the Secure Access Service decodes it and ensures that
it is 20 bytes. It 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—A 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 intersite transfer service is the identity provider URL on the source site (not the
Secure Access Service). Your specification of this URL in the admin console enables
the Secure Access Service 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://<intersite transfer hostname and
path>?TARGET=<Target>...<HTTP-Version><other HTTP 1.0 or 1.1 components>
In the preceding sample, <intersite transfer hostname and path> consists of the
hostname, port number, and path components of the intersite transfer URL at the
source and where Target=<Target> specifies the requested target resource at the
destination (Secure Access Service protected) site. This request might look like:
264
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
GET http://10.56.1.123:8002/xferSvc?TARGET=http://www.dest.com/sales.htm
•
The intersite transfer service redirects the user’s browser to the assertion consumer
service at the destination site—in this case, the Secure Access Service. The HTTP
response from the source site intersite transfer service must be in the following format:
<HTTP-Version> 302 <Reason Phrase>
<other headers>
Location: http://<assertion consumer hostname and path>?<SAML
searchpart><other HTTP 1.0 or 1.1 components>
In the preceding sample, <assertion consumer hostname and path> provides the
hostname, 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.
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 hostname and path>?<SAML searchpart>
<HTTP-Version><other HTTP 1.0 or 1.1 request components>
In the preceding sample, <assertion consumer hostname and path> provides the
hostname, 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.
Copyright © 2013, Juniper Networks, Inc.
265
Junos Pulse Secure Access Service Administration Guide
•
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 username template is a reference to the SAML name identifier element, which
allows the asserting party to provide a format for the username. 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 the content is in the form of an e-mail 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 username template to accept the type of username your SAML
assertion contains.
Related
Documentation
•
You can prevent eavesdropping on the SAML artifact by synchronizing the clocks on
the source and destination sites. The Secure Access Service provides an Allowed Clock
Skew attribute that dictates the maximum time difference allowed between the Secure
Access Service and the source site. The Secure Access Service rejects any assertions
whose timing exceeds the allowed clock skew.
•
Understanding SAML 1.1 Profiles on page 261
•
Creating a SAML 1.1 Server Instance on page 270
Creating a Trust Relationship Between SAML 1.1 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 (the Secure Access Service) needs to know the URL of the other system.
(The Secure Access Service 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.
The following list shows the different transaction types and the URLs you must configure
for each:
•
266
SSO transactions: Artifact profile—On the Secure Access Service, you must enter the
URL of the assertion consumer service. For example, use https://hostname/acs.
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
You must also enter the following URL for the Secure Access Service on the assertion
consumer service. For example, use
https://<SecureAccessHostname>/dana-ws/saml.ws.
•
SSO transactions: POST profile—On the Secure Access Service, you must enter the
URL of the assertion consumer service. For example, use https://hostname/acs.
•
Access control transactions—On the Secure Access Service, you must enter the URL
of the SAML Web service. For example, use 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 hostnames 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.
The following list shows the different transaction types and the issuers you must configure
for each:
•
SSO transactions—You must specify a unique string on the Secure Access Service
(typically its hostname) 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 hostname) that it can use to identify itself and then
configure the Secure Access Service 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 the Secure
Access Service SAML transactions to use SSL (HTTPS).
Configuring SSO Transactions: Artifact Profile
Artifact profile transactions involve numerous communications back and forth between
the Secure Access Service and the access management system. The methods you use
to pass data and authenticate the two systems affect which certificates you must install
and configure.
The following list shows 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 Service Web server
certificate on the access management system. (The Secure Access Service 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
Copyright © 2013, Juniper Networks, Inc.
267
Junos Pulse Secure Access Service Administration Guide
system, you ensure that the access management system will trust the CA that issued
the Secure Access Service 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 the Secure Access
Service. (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 the Secure
Access Service, you ensure that the Secure Access Service 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 the Secure Access Service to the access
management system, enter a URL that begins with HTTPS in the SAML Assertion
Consumer Service URL field during the Secure Access Service configuration. You may
also need to enable SSL on the access management system.
•
Transactions using certificate authentication—If you choose to authenticate the access
management system using a certificate, you must:
•
Install the access management system’s root CA certificate on the Secure Access
Service. You can install the root CA from the System > Configuration > Certificates
> Trusted Client CAs page in the admin console.
•
Specify which certificate values the Secure Access Service 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, the Secure Access Service sends signed authentication
statements to the access management system. Generally, it sends them over an SSL
connection (recommended), but in some configurations, the Secure Access Service may
send statements through a standard HTTP connection.
The following list shows the different POST profile configuration options that require
special certificate configurations:
•
268
All POST profile transactions—Regardless of your POST profile configuration, you must
specify which certificate the Secure Access Service 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 the Secure Access
Service device certificate on the access management system. You can download the
Secure Access Service certificate from the System > Configuration > Certificates >
Device Certificates > [Certificate] > Certificate Details page.
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
•
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 the Secure Access
Service. (In an SSL connection, the initiator must trust the system to which it is
connecting. By installing the access management system’s certificate on the Secure
Access Service, you ensure that the Secure Access Service 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 the Secure Access Service to the access
management system, enter a URL that begins with HTTPS in the SAML assertion
consumer service URL field during the Secure Access Service configuration. You may
also need to enable SSL on the access management system.
Configuring Access Control Transactions
In an access control transaction, the Secure Access Service 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.
The following list shows the different access control configuration options that require
special certificate configurations:
•
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 the Secure Access Service. (In an SSL connection,
the initiator must trust the system to which it is connecting. By installing the access
management system’s certificate on the Secure Access Service, you ensure that the
Secure Access Service 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 the Secure Access Service certificate. Optionally, you may also choose to
accept the certificate based on the following additional options:
•
Upload the Secure Access Service certificate public key to the access management
system.
•
Validate the Secure Access Service using specific certificate attributes.
These options require that you specify which certificate the Secure Access Service
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 the Secure
Access Service certificate, see your access management system’s documentation. If
your access management system does not require certificate authentication, or if it
Copyright © 2013, Juniper Networks, Inc.
269
Junos Pulse Secure Access Service Administration Guide
uses username/password authentication, you do not need to configure the Secure
Access Service 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 hardcode 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 the Secure Access Service 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. Choose a username or attribute that the access management system will recognize.
Related
Documentation
•
Using a Trusted Client CA on page 822
•
Understanding SAML 1.1 on page 259
•
Configuring SAML 1.1 SSO Profiles on page 272
•
Configuring General Role Options on page 99
Secure Access Service SAML Version 1.1 Configuration Tasks
The following topics describe how to configure the Secure Access Service features that
support SAML version 1.1:
•
Creating a SAML 1.1 Server Instance on page 270
•
Configuring SAML 1.1 SSO Profiles on page 272
•
Creating a SAML 1.1 SSO POST Profile on page 276
•
Creating a SAML 1.1 ACL Resource Policy on page 279
Creating a SAML 1.1 Server Instance
To create a new SAML server instance:
1.
In the admin console, choose Authentication > Auth. Servers.
2. Select SAML Server from the New list, and then click New Server.
3. Complete the settings as described in Table 30 on page 271.
4. Click Save Changes.
After you save changes for the first time, the page is redisplayed and now has two tabs.
The Settings tab allows you to modify any of the settings pertaining to the SAML Server
instance. The Users tab lists valid users of the server.
270
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
Table 30: SAML Authentication Server (SAML 1.1)
Setting
Guideline
Name
Specify a name to identify the server instance.
Settings
SAML Version
Select 1.1.
Source Site Inter-Site Transfer
Service URL
User is redirected to this URL in destination first scenario.
Issuer Value for Source Site
Typically the URI or hostname of the issuer of the assertion.
User Name Template
Enter the mapping string from the SAML assertion to a Secure Access Service user realm.
For example, enter <assertionNameDN.CN> to derive the username from the CN value
in the assertion.
Allowed Clock Skew
The maximum allowed difference in time between the Secure Access Service clock and
the source site clock.
SSO Method
Artifact
•
Source ID. A Base64-encoded string of 20 bytes that the Secure Access Service uses
to recognize an assertion from a given source site.
•
Source SOAP Responder Service URL
•
SOAP Client Authentication. Select HTTP Basic or SSL Client Certificate and complete
the related settings.
NOTE: SOAP requests generated by the Secure Access Service (when configured as a
SAML 1.1 consumer) are not signed.
•
POST
Response Signing Certificate. Enter the name of, or browse to locate, 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.
•
Enable Signing Certificate status checking. Select this option 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 or has been revoked.
User Record Synchronization
Enable User Record Synchronization
Allow users to retain their bookmarks and individual preferences regardless of which
Secure Access Service device they log in to.
Logical Auth Server Name
Related
Documentation
Copyright © 2013, Juniper Networks, Inc.
271
Junos Pulse Secure Access Service Administration Guide
Configuring SAML 1.1 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
the Secure Access Service or whether the Secure Access Service 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 the Secure Access
Service, 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
the Secure Access Service.
Figure 22 on page 272 shows the SAML communication process when the implementation
uses the artifact profile.
Figure 22: Artifact Profile
The Secure Access Service 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 the Secure Access Service
and tries to access a protected resource on a Web server.
2. The Secure Access Service sends an HTTP or HTTPS GET request to the ACS—the
Secure Access Service intercepts the request and checks whether it has already
performed the necessary SSO operation to honor the request. If not, the Secure Access
Service creates an authentication statement and passes an HTTP query variable
called an artifact to the assertion consumer service.
An artifact profile is a Base64-encoded string that contains the source ID of the source
site (that is, a 20-byte string that references the Secure Access Service) 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, the Secure Access Service does not send
a statement. Also note that the Secure Access Service discards a handle after its first
use to prevent the handle from being used twice.)
3. The ACS sends a SAML request to the Secure Access Service—The assertion consumer
service uses the source ID sent in the previous step to determine the location of the
272
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
Secure Access Service. Then the assertion consumer service sends a statement request
wrapped in a SOAP message to the following address on the Secure Access Service:
https://<<ivehostname>/danaws/saml.ws
The request includes the statement handle passed in the previous step.
NOTE: The Secure Access Service 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 Service), 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. The Secure Access Service sends an authentication statement to the ACS—the Secure
Access Service uses the statement handle in the request to find the correct statement
in the Secure Access Service cache and then sends the appropriate authentication
statement back to the assertion consumer service. The unsigned statement contains
the user's identity and the mechanism he used to sign into the Secure Access Service.
5. The ACS sends a cookie to the Secure Access Service—The assertion consumer service
accepts the statement and then it sends a cookie back to the Secure Access Service
that enables the user’s session.
6. The Secure Access Service sends the cookie to the Web server—the Secure Access
Service caches the cookie to handle future requests. Then the Secure Access Service
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 the Secure Access Service to use artifact profiles,
you must install the Secure Access Service 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 check box.
c. Select the SAML check box below the SSO check box.
d. Click OK.
3. Use the tabs to display the SSO > SAML page.
Copyright © 2013, Juniper Networks, Inc.
273
Junos Pulse Secure Access Service Administration Guide
4. 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 SSO defined below—The Secure Access Service performs a single-sign
on (SSO) request to the specified URL using the data specified in the SAML SSO
details section. The Secure Access Service makes the SSO request when a user
tries to access a SAML resource specified in the Resources list.
•
Do NOT use SAML—The Secure Access Service 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 the Secure Access
Service 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 the
Secure Access Service 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 the Secure Access Service.
•
Profile—Select Artifact to indicate that the assertion consumer service should “pull”
information from the Secure Access Service during SSO transactions.
•
Source ID—Enter the source ID for the Secure Access Service. It must be a
Base64-encoded string. The Secure Access Service decodes it and ensures that it
is 20 bytes. You can use OpenSSL or other Base64 tool to generate the
Base64-encoded string.
274
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
NOTE: The Secure Access Service identifier (that is, the source ID) must
map to the following URL on the assertion consumer service:
https://<ivehostname>/dana-ws/saml.ws
•
Issuer—Enter a unique string that the Secure Access Service can use to identify itself
when it generates assertions (typically its hostname).
NOTE: You must configure the assertion consumer service to recognize
the Secure Access Service unique string.
10. In the User Identity section, specify how the Secure Access Service and the assertion
consumer service should identify the user:
•
Subject Name Type—Specify which method the Secure Access Service 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 the Secure Access
Service and the assertion consumer service.
•
Subject Name—Use variables to specify the username that the Secure Access Service
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
the Secure Access Service 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 the Secure Access Service.
•
Certificate Attribute—Authenticate the assertion consumer service using certificate
attributes. Enter the attributes that the assertion consumer service must send the
Secure Access Service (one attribute per line). For example, use cn=sales. You must
use values that match the values contained in the assertion consumer service
certificate.
NOTE: If you select this option, you must install the assertion consumer
service root CA on the Secure Access Service.
Copyright © 2013, Juniper Networks, Inc.
275
Junos Pulse Secure Access Service Administration Guide
12. Cookie Domain—Enter a comma-separated list of domains to which we send the SSO
cookie.
13. Click Save Changes.
14. On the SAML SSO Policies page, order the policies according to how you want the
Secure Access Service to evaluate them. Keep in mind that once the Secure Access
Service 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 Secure Access Service on page 814
Creating a SAML 1.1 SSO POST Profile
When you choose to communicate using a POST profile (also called browser/POST
profile), the Secure Access Service “pushes” authentication data to the access
management system using an HTTP POST command over an SSL 3.0 connection.
Figure 23 on page 276 shows the SAML communication process when the implementation
uses the POST profile.
Figure 23: POST Profile
The Secure Access Service and an access management system use the following process
to pass information:
1.
The user tries to access a resource—A user is signed into the Secure Access Service
and tries to access a protected resource on a Web server.
2. The Secure Access Service posts a statement—the Secure Access Service intercepts
the request and checks whether it has already performed the necessary SSO operation
to honor the request. If not, the Secure Access Service 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 the Secure Access Service uses to sign the statement.
276
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
3. The AM establishes a session—If the user has the proper permissions, the access
management server sends a cookie back to the Secure Access Service that enables
the user’s session.
4. The Secure Access Service sends the cookie to the Web server—the Secure Access
Service caches the cookie to handle future requests. Then the Secure Access Service
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 the Secure Access Service to use POST profiles,
you must install the assertion consumer service’s root CA on the Secure
Access Service 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, 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 check box.
c. Select the SAML check box below the SSO check box.
d. Click OK.
3. Use the tabs to display the SSO > SAML page.
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:
Copyright © 2013, Juniper Networks, Inc.
277
Junos Pulse Secure Access Service Administration Guide
•
Use the SAML SSO defined below—The Secure Access Service performs a single-sign
on (SSO) request to the specified URL using the data specified in the SAML SSO
details section. The Secure Access Service makes the SSO request when a user
tries to access a SAML resource specified in the Resources list.
•
Do NOT use SAML—The Secure Access Service does not perform an 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 the Secure Access
Service should use to contact the assertion consumer service (that is, the access
management server). For example, use https://hostname/acs.
•
Profile—Select POST to indicate that the Secure Access Service should “push”
information to the assertion consumer service during SSO transactions.
•
Issuer—Enter a unique string that the Secure Access Service can use to identify itself
when it generates assertions. Typically, the issuer string is a hostname.
NOTE: You must configure the assertion consumer service to recognize
the Secure Access Service unique string.
•
Signing Certificate—Specify which certificate the Secure Access Service should use
to sign its assertions.
10. In the User Identity section, specify how the Secure Access Service and the assertion
consumer service should identify the user:
•
Subject Name Type—Specify which method the Secure Access Service 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 e-mail address.
•
Windows—Send the username in the format of a Windows domain qualified
username.
•
Other—Send the username in another format agreed upon by the Secure Access
Service and the assertion consumer service.
•
Subject Name—Use variables to specify the username that the Secure Access Service
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.
278
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
11. Click Save Changes.
12. On the SAML SSO Policies page, order the policies according to how you want the
Secure Access Service to evaluate them. Keep in mind that once the Secure Access
Service 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 Secure Access Service on page 814
•
Writing a Web Proxy Resource Policy on page 531
Creating a SAML 1.1 ACL Resource Policy
When enabling access control transactions to a trusted access management system,
the Secure Access Service and trusted access management system exchange information
using the method shown in Figure 24 on page 279.
Figure 24: Access Control Policies
The Secure Access Service and an access management system use the following process
to pass information:
1.
The user tries to access a resource—A user is signed into the Secure Access Service
and tries to access a protected resource on a Web server.
2. The Secure Access Service posts an authorization decision query—If the Secure Access
Service has already made an authorization request and it is still valid, the Secure
Access Service 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,
the Secure Access Service 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 access management system 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. The Secure Access Service sends the request to the Web browser—If the authorization
decision statement returns a result of permit, the Secure Access Service allows the
Copyright © 2013, Juniper Networks, Inc.
279
Junos Pulse Secure Access Service Administration Guide
user access. If not, the Secure Access Service presents an error page to the user telling
him that he does not have the proper access permissions.
NOTE: If you configure the Secure Access Service to use access control
transactions, you must install the SAML Web service root CA on the Secure
Access Service.
To create 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 check box below the Access check box.
c. Click OK.
3. Use the tabs to display the Access > SAML ACL page.
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—The Secure Access Service
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—The Secure Access Service 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:
280
Copyright © 2013, Juniper Networks, Inc.
Chapter 9: SAML Single Sign-on
•
SAML Web Service URL—Enter the URL of the access management system’s SAML
server. For example, use https://hostname/ws.
•
Issuer—Enter the hostname of the issuer, which in most cases is the hostname of
the access management system.
NOTE: You must enter a unique string that the SAML Web service uses
to identify itself in authorization assertions.
10. In the User Identity section, specify how the Secure Access Service and the SAML
Web service should identify the user:
•
Subject Name Type—Specify which method the Secure Access Service 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 e-mail address.
•
Windows—Send the username in the format of a Windows domain qualified
username.
•
Other—Send the username in another format agreed upon by the Secure Access
Service and the SAML Web service.
•
Subject Name—Use variables to specify the username that the Secure Access Service
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 the Secure Access Service:
•
None—Do not authenticate the Secure Access Service.
•
Username—Authenticate the Secure Access Service using a username and password.
Enter the username and password that the Secure Access Service must send the
Web service.
•
Certificate Attribute—Authenticate the Secure Access Service using a certificate
signed by a trusted certificate authority. If you have more than one certificate
installed on the Secure Access Service, 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
Service Web server certificate on the access management system Web
server and determine which method the SAML Web service uses to trust
the certificate.
Copyright © 2013, Juniper Networks, Inc.
281
Junos Pulse Secure Access Service Administration Guide
12. In the Options section, specify:
•
Maximum Cache Time—You can eliminate the overhead of generating an
authorization decision each time the user requests the same URL by indicating that
the Secure Access Service must cache the access management system’s
authorization responses. Enter the amount of time the Secure Access Service should
cache the responses (in seconds).
•
Ignore Query Data—By default, when a user requests a resource, the Secure Access
Service sends the entire URL for that resource (including the query parameter) to
the SAML Web service and caches the URL. You can specify that the Secure Access
Service should remove 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 the Secure Access Service to evaluate them. Keep in mind that once the Secure
Access Service 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
282
•
About Using Certificates on Secure Access Service on page 814
•
Writing a Web Proxy Resource Policy on page 531
Copyright © 2013, Juniper Networks, Inc.
CHAPTER 10
Authentication Realms
•
Authentication Realm Overview on page 283
•
Creating an Authentication Realm on page 284
•
Defining Authentication Access Policies on page 285
•
Role Mapping Rules on page 286
•
Specifying Role Mapping Rules for an Authentication Realm on page 287
•
Machine Authentication for Junos Pulse Connections on page 289
•
Junos Pulse Connection Realm and Role Preferences for Machine
Authentication on page 290
•
Using the LDAP Server Catalog on page 292
•
Customizing User Realm UI Views on page 296
Authentication Realm Overview
An authentication realm specifies the conditions that users must meet in order to sign
into the Secure Access Service. A realm consists of a grouping of authentication resources,
including:
•
An authentication server — verifies that the user is who he claims to be. The Secure
Access Service 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
Secure Access Service that the Secure Access Service uses to map users to one or
more user roles.
•
An authentication policy—specifies realm security requirements that need to be met
before the Secure Access Service submits a user's credentials to an authentication
server for verification.
•
Role mapping rules—conditions a user must meet in order for the Secure Access Service
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 Secure Access Service access
management framework, and therefore are available on all Secure Access products.
Note, however that custom expressions are not available on the Secure Access Service
Copyright © 2013, Juniper Networks, Inc.
283
Junos Pulse Secure Access Service Administration Guide
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 299
•
Defining Authentication Access Policies on page 285
•
Creating an Authentication Realm on page 284
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
284
Copyright © 2013, Juniper Networks, Inc.
Chapter 10: Authentication Realms
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
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 285
•
Configuring User Sign In Policies on page 302
•
Dynamic Policy Evaluation on page 67
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
Copyright © 2013, Juniper Networks, Inc.
285
Junos Pulse Secure Access Service Administration Guide
credentials to the appropriate authentication server. If this server successfully
authenticates the user, then Secure Access moves on to the role evaluation process.
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 69
•
Specifying Password Access Restrictions on page 75
•
Specifying Certificate Access Restrictions on page 74
•
Specifying Browser Access Restrictions on page 72
•
Specifying Session Limits on page 76
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:
•
•
286
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.
•
To 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.
Copyright © 2013, Juniper Networks, Inc.
Chapter 10: Authentication Realms
•
Specify the roles to assign to the authenticated user.
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 95
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 Rule to 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 © 2013, Juniper Networks, Inc.
287
Junos Pulse Secure Access Service 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:
<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.
288
Copyright © 2013, Juniper Networks, Inc.
Chapter 10: Authentication Realms
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 286
•
Policies, Rules & Restrictions, and Conditions Overview on page 62
Machine Authentication for Junos Pulse Connections
Junos Pulse supports machine authentication. Machine authentication uses machine
credentials (machine name and password or machine certificate) to authenticate the
endpoint. You can enable machine authentication for Pulse Secure Access Service as
part of a Junos Pulse connection and distribute the connection to endpoints through the
normal Pulse distribution methods.
The following describes the requirements for a machine authentication environment:
•
Machine authentication for Pulse Secure Access Service is available for Pulse layer 3
connections only.
•
The authentication server used by the Pulse connection must be Active
Directory/Windows NT for machine name/password authentication or a certificate
server for machine certificate authentication. You can also use machine credentials
when authenticating to RADIUS servers that verify the machine credentials against an
Active Directory listing.
•
The endpoint must be a member of a Windows domain and the machine credentials
must be defined in Active Directory. Typically, during login, the user must enter
domain/user in the username box.
•
The Pulse connection must be configured so that no prompts are presented during the
login process. For example, prompts for realm or role selection or a server certificate
trust prompt cause the connection to fail.
•
For machine certificate authentication, the domain workstation logon certificate must
be issued by the domain certificate authority. The root certificate (CA) must be in the
Machine Trusted Certificate store instead of the certificate store for a particular user.
To enable a Pulse connection for machine authentication:
1.
Click Users > Junos Pulse > Connections and create or select a connection set.
2. Create or edit a connection. Machine authentication is available for connection type
SSL VPN or UAC (L3) only.
Copyright © 2013, Juniper Networks, Inc.
289
Junos Pulse Secure Access Service Administration Guide
3. Under Connection is established, select one of the following options:
•
Automatically when the machine starts. Machine credentials used for
authentication—This option enables machine-only authentication. Machine
credentials are used to connect to the Pulse Secure Access Service before the user
logs on. The user does not need to be logged in. The connection is maintained when
a users logs on, logs off, or switches to a different logon.
•
Automatically when the machine starts. Connection is authenticated again when the
user signs in into the desktop—This option enables user-after-desktop authentication.
Machine credentials are used to authenticate the endpoint when no user is logged
on. When a user logs on, the machine authentication connection is dropped and
the user login is used instead. When the user logs off, the machine connection is
reestablished.
Junos Pulse Connection Realm and Role Preferences for Machine Authentication
When a Junos Pulse connection is configured to use machine authentication, any prompts
that occur during the login process cause the connection to fail. For example, if the Pulse
server authentication policy allows a user to select a realm or a role during the login
process, Pulse presents a dialog box to the user and prompts for the realm or role
selection. To avoid failed connections due to prompts during machine authentication
you can specify a preferred role and realm for a Pulse connection.
For a Pulse connection that is used for machine authentication, you do not need to specify
the preferred role if any of the following conditions are true:
•
Users are mapped to only one role.
•
Users are mapped to more than one role, but the realm’s role mapping properties are
set to merge settings for all assigned roles.
For a Pulse connection that is used for machine authentication, you must specify the
preferred realm if the authentication sign-in policy allows the user to select a realm. If
that realm maps to only one role, you do not need to specify the role.
For a Pulse connection that is used for machine authentication, you must specify the
preferred role if any of the following conditions are true:
290
•
The realm that the user connects to maps to more than one role and the realm’s role
mapping properties are set to require that the user must select a role. The preferred
role set must be the name of a role assigned in that realm.
•
The realm that the user connects to maps to more than one role and the realm’s role
mapping properties are defined by role mapping rules. You specify the preferred role
by specifying the name of a rule that assigns the role set. Figure 25 on page 291 shows
a role mapping rule with the rule name highlighted.
Copyright © 2013, Juniper Networks, Inc.
Chapter 10: Authentication Realms
Figure 25: Junos Pulse Role Mapping Rule
When you create a Pulse connection for machine authentication, you must use the
connection type SSL VPN or UAC (L3). To identify the connection as a machine
authentication connection, you specify how the connection is established using one of
the following options:
•
Automatically when the machine starts. Machine credentials used for authentication
This option uses the machine credentials defined in Active Directory for the machine
login process and uses the same credentials for user login. When you select this option,
the Realm and Role Set Preferences enable you to specify the following options:
•
Preferred Machine Realm—Type the realm name that maps to the role you want to
assign.
•
Preferred Machine Role Set—Type the name of the role. The role must be one that is
identified in the realm’s role mapping properties. Or specify the name of a role
mapping rule that assigns the role set.
•
Automatically when the machine starts. Connection is authenticated again when the
user signs in into the desktop
This option uses the Active Directory machine credentials for the machine login process.
When machine login is complete, Pulse drops that connection and then uses the user
credentials for user login. When you select this option, the Realm and Role Set
Preferences enable you to specify the following options:
•
Preferred Machine Realm—Type the realm name that maps to the role you want to
assign.
•
Preferred Machine Role Set—Type the name of the role. The role must be one that is
identified in the realm’s role mapping properties. Or specify the name of a role
mapping rule that assigns the role set.
Copyright © 2013, Juniper Networks, Inc.
291
Junos Pulse Secure Access Service Administration Guide
•
Preferred User Realm—Type the realm name that maps to the role you want to assign.
•
Preferred User Role Set—Type the name of the role. The role must be one that is
identified in the realm’s role mapping properties. Or specify the name of a role
mapping rule that assigns the role set.
NOTE: Realm and role prompts are not the only prompts that are possible
during the login process. If the Pulse connection has the Dynamic Certificate
Trust option enabled, and there is an issue with the server certificate, Pulse
asks the user if it is Ok to proceed. That certificate prompt causes a machine
connection to fail. Note that the Pulse prompt for upgrading Pulse software
is presented after the user connection is established and it will not affect a
machine authentication connection.
Related
Documentation
•
Role Mapping Rules on page 286
•
Policies, Rules & Restrictions, and Conditions Overview on page 62
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.
292
Copyright © 2013, Juniper Networks, Inc.
Chapter 10: Authentication Realms
•
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 26: Server Catalog > Attributes Tab — Adding an Attribute for LDAP
Copyright © 2013, Juniper Networks, Inc.
293
Junos Pulse Secure Access Service Administration Guide
Figure 27: Server Catalog > Groups Tab — Adding LDAP Groups
294
Copyright © 2013, Juniper Networks, Inc.
Chapter 10: Authentication Realms
Copyright © 2013, Juniper Networks, Inc.
295
Junos Pulse Secure Access Service Administration Guide
Figure 28: Server Catalog > Groups Tab — Adding Active Directory Groups
Related
Documentation
•
Specifying Role Mapping Rules for an Authentication Realm on page 287
•
Custom Expressions on page 1123
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.
296
Copyright © 2013, Juniper Networks, Inc.
Chapter 10: Authentication Realms
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.
Copyright © 2013, Juniper Networks, Inc.
297
Junos Pulse Secure Access Service Administration Guide
298
Copyright © 2013, Juniper Networks, Inc.
CHAPTER 11
Sign-In Policies
•
About Sign-In Policies on page 299
•
Task Summary: Configuring Sign In Pages on page 302
•
About Configuring Sign In Policies on page 302
•
Configuring User Sign In Policies on page 302
•
About Sign-In Notifications on page 305
•
Configuring and Implementing Sign-in Notifications on page 306
•
Defining Authorization-Only Access Policies on page 308
•
Defining Meeting Sign-In Policies on page 309
•
Configuring Sign-In pages on page 311
About Sign-In Policies
Sign-in policies define the URLs that users and administrators use to access the Secure
Access Service and the sign-in pages that they see. The Secure Access Service 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 Secure Access Service, 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 Secure Access Service
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 Junos Pulse Collaboration 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 Secure Access Service. If you have the proper license, you may
also create additional meeting sign-in pages, enabling different Junos Pulse Collaboration
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 © 2013, Juniper Networks, Inc.
299
Junos Pulse Secure Access Service Administration Guide
For example, you can create sign-in policies that specify:
•
Members of the “Partners” realm can sign in to the Secure Access Service 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 Secure Access Service
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 Secure Access Service 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 Secure Access Service 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 Secure Access Service creates the new user
session and terminates the existing session.
300
Copyright © 2013, Juniper Networks, Inc.
Chapter 11: Sign-In Policies
NOTE: When enabling multiple sign-in URLs, note that in some cases the
Secure Access Service 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
Secure Access Service creates these cookies when the user signs into the
Secure Access Service. (When a user signs into the Secure Access Service,
the Secure Access Service responds with a cookie that includes the sign-in
domain of the URL. The Secure Access Service then attaches this cookie to
every Secure Access Service request the user makes.) Generally, these cookies
ensure that the Secure Access Service displays the correct sign-in URL and
page to the user. For example, if a user signs into the Secure Access Service
using the URL http://yourcompany.net/employees and then her session
times out, the Secure Access Service 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 Secure Access
Service 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
Secure Access Service 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 Secure Access Service using the sign-in URL
http://yourcompany.net/employees. Then she may try to access the Secure
Access Service 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 Secure Access Service 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 Secure Access Service 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 Junos Pulse Collaboration users.
•
The ability to create and upload custom sign-in pages to the Secure Access Service.
•
Task Summary: Configuring Sign In Pages on page 302
•
Defining Meeting Sign-In Policies on page 309
•
Configuring User Sign In Policies on page 302
Copyright © 2013, Juniper Networks, Inc.
301
Junos Pulse Secure Access Service 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 302
•
Configuring User Sign In Policies on page 302
•
Defining Meeting Sign-In Policies on page 309
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 302
•
Defining Meeting Sign-In Policies on page 309
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.
3. Select Users or Administrators to specify which type of user can sign into Secure
Access using the access policy.
302
Copyright © 2013, Juniper Networks, Inc.
Chapter 11: Sign-In Policies
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.
•
SAML authentication does not support sign-in URLs that contain multiple
realms. Instead, map each sign-in URL to a single realm.
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 © 2013, Juniper Networks, Inc.
303
Junos Pulse Secure Access Service 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.
If you select this option, all user sessions are immediately terminated. If this device
is part of a cluster, all user sessions across all nodes in the cluster are immediately
terminated.
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.
304
Copyright © 2013, Juniper Networks, Inc.
Chapter 11: Sign-In Policies
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.
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 302
About Sign-In Notifications
With sign-in notifications, you can create and configure detailed notification messages
that appear for Pulse clients and for agentless access endpoints when the user attempts
to sign in. For example, you could configure a notification message that explains terms
of use, company-specific policies, a welcome page, an end user license agreement
(EULA), or a message of the day (MOTD).
For a browser-based (agentless) login, the notification message appears in a separate
page either before (pre-auth) or after (post-auth) user authentication during the sign-in
process. For a Pulse client login, the notification messages appear in a Pulse message
box. The user is expected to read the content of the sign-in notification message and
acknowledge by clicking a Proceed button. The user may indicate disagreement by clicking
a Decline button, which ends the login attempt.
You can configure a sign-in policy to use a sign-in notification either as pre-auth or
post-auth (or both). In the case of post-auth configuration, you can either use a common
message for all roles or use separate messages for each role.
You can create a multi-language sign-in notification package that relies on the language
setting of the endpoint. You can customize the sign-in notification page appearance for
browser-based logins by modifying the related fields in a sign-in page in the Admin UI or
by using a custom sign-in page.
Notes:
Related
Documentation
•
Sign-in notifications are supported on Windows, Mac, and for browser-based access
on mobile devices. However, sign-in notifications might not work well with all mobile
devices due to device limitations.
•
Sign-in notifications (including uploaded packages) are included in XML exports.
•
If a Pulse session is resumed or extended, the pre-auth notification message is not
shown again. However, if the user switches roles when resuming a session, and that
role change results in a new notification, Pulse displays the message. You can configure
the post-auth message to be skipped if it has already been seen. If the post-auth
message is not marked to be skipped, then it always appears.
•
Configuring and Implementing Sign-in Notifications on page 306
Copyright © 2013, Juniper Networks, Inc.
305
Junos Pulse Secure Access Service Administration Guide
Configuring and Implementing Sign-in Notifications
Sign-in notifications appear for Pulse client and for browser-based logins when the user
attempts to sign in.
To configure and implement sign-in notifications:
1.
In the admin console, select Authentication > Signing In > Sign-in Notifications.
2. Click New Notification.
3. Specify a Name for the notification. This name appears in the sign-in policies page,
and in the UI Options page for a selected role.
4. Select Text or Package in the Type box.
•
If you select Text, type the desired sign-in notification message, or copy and paste
the relevant text into the Text field.
•
If you select Package, click the Browse button and navigate to a previously prepared
.zip file. A package is typically used to provide different language versions of the
notification message.
•
The zip file should include a default.txt file and one or more <language>.txt files
(Example: en.txt).
•
Language-abbreviations should be strings that can appear in Accept-Language
header of an HTTP request.
•
The character encoding supported is UTF-8.
NOTE: When you create a zip file, do not add the folder containing
the files, but add the files directly.
5. Click Save Changes.
To enable sign-in notifications:
1.
In the admin console, click Authentication > Signing In > Sign-in Policies.
2. Select an existing URL or create a new URL.
3. Under Configure Sign-in Notifications, select the check box for Pre-Auth Sign-in
Notification, Post-Auth Sign-in Notification, or both.
306
•
After Pre-Auth Sign-in Notification, select a previously configured sign-in notification
from the drop-down menu.
•
After Post-Auth Sign-in Notification, select the option for Use a common Sign-in
Notification for all roles or Use the Sign-in Notification associated to the assigned
role.
•
If you select Use a common Sign-in Notification for all roles, select a previously
configured sign-in notification from the drop-down menu.
Copyright © 2013, Juniper Networks, Inc.
Chapter 11: Sign-In Policies
•
If you select Use the Sign-in Notification associated to the assigned role, the sign-in
notification configured for the assigned role will be used.
•
Prevent the Post-Auth sign-in notification from being displayed to users who have
seen it before, by selecting the Skip if already shown check box. (This is only a hint
to the system and might not be honored in all environments.)
4. Click Save Changes.
5. You can customize the appearance of the sign-in notification message by selecting
Authentication > Signing In > Sign-in Pages and creating a sign-in page or using an
existing page.
6. Under Sign-in Notification appearance, customize UI options for Pre-Auth Notifications
and Post-Auth Notifications by changing the following items:
•
For Notification Title enter the text that appears at the top of the sign-in notification
page.
•
In the Proceed Button box, enter the text for the button that the user clicks to proceed
with the sign-in.
This text applies to browser-based logins only. A Pulse client login always displays
Proceed.
•
Optionally, clear the check box for Display “Decline” Button. If this box is not checked,
the user does not have the option to decline.
•
In the Decline Button box, enter the text for the button that the user clicks to decline.
This text applies to browser-based logins only. A Pulse client login always displays
Decline.
•
In the Message on Decline box, enter the text that you would like to appear when a
user clicks the Decline button.
7. Click Save Changes.
NOTE: If you enabled Use the Sign-in Notification associated to the assigned
role you must complete the implementation by selecting the sign-in
notification on the Users > User Roles > Role Name > General > UI Options
page or Administrators > Admin Roles > Role Name > General > UI Options
page, as applicable.
If more than one role is available to a user, the sign-in notification
associated with the first role assigned is displayed.
8. Add the sign-in page in which you have customized the sign-in notification appearance
to the sign-in policy.
Related
Documentation
•
About Sign-In Notifications on page 305
Copyright © 2013, Juniper Networks, Inc.
307
Junos Pulse Secure Access Service Administration Guide
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
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.
308
Copyright © 2013, Juniper Networks, Inc.
Chapter 11: Sign-In Policies
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
•
eTrust SiteMinder Overview on page 195
•
Specifying Web Browsing Options on page 493
•
Specifying Browser Access Restrictions on page 72
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.
Copyright © 2013, Juniper Networks, Inc.
309
Junos Pulse Secure Access Service Administration Guide
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
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.
310
Copyright © 2013, Juniper Networks, Inc.
Chapter 11: Sign-In Policies
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 311
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 Secure Access Service 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 Secure Access Service. 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 Secure Access Service 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 Secure
Access Service.
For more information on customized sign-in pages, see
http://www.juniper.net/techpubs/software/ive/admin/j-sa-sslvpn-7.0-customsigninpages.pdf.
Configuring Standard Sign-In Pages
Standard sign-in pages that come with the Secure Access Service include:
•
Default Sign-In Page—the Secure Access Service displays this page to users when they
sign into the Secure Access Service.
•
Meeting Sign-In Page—the Secure Access Service displays this page to users when
they sign into a meeting. This page is only available if you install a Junos Pulse
Collaboration license on the Secure Access Service.
You can modify the default sign-in page that the Secure Access Service displays to users
when they sign into the Secure Access Service. You can also create new standard sign-in
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.
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:
Copyright © 2013, Juniper Networks, Inc.
311
Junos Pulse Secure Access Service Administration Guide
•
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 Secure Access Service 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 Secure Access Service
may display the end-user’s Secure Access Service 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 Secure Access Service. Note that the Secure Access Service does not display
images and other content referenced in this HTML page. (Not available for the Junos
Pulse Collaboration 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, Secure Access Service user home
page, and admin console appearance.
312
Copyright © 2013, Juniper Networks, Inc.
CHAPTER 12
Single Sign-On
•
About Single Sign-On on page 313
•
Task Summary: Configuring Multiple Authentication Servers on page 315
•
Task Summary: Enabling SSO to Resources Protected by Basic
Authentication on page 315
•
Task Summary: Enabling SSO to Resources Protected by NTLM on page 316
•
Multiple Sign-In Credentials Execution on page 317
•
Understanding SAML 1.1 on page 322
•
Configuring SAML 1.1 SSO Profiles on page 324
•
Creating a SAML 1.1 SSO POST Profile on page 329
•
Creating a SAML 1.1 ACL Resource Policy on page 332
•
Creating a Trust Relationship Between SAML 1.1 Systems on page 335
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 © 2013, Juniper Networks, Inc.
313
Junos Pulse Secure Access Service 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.
314
Copyright © 2013, Juniper Networks, Inc.
Chapter 12: Single Sign-On
Related
Documentation
•
Remote SSO Overview on page 472
•
Understanding SAML 1.1 on page 259
•
Defining a Single Sign-On Autopolicy on page 478
•
Defining an Active Directory or Windows NT Domain Server Instance on page 154
•
eTrust SiteMinder Overview on page 195
•
About Terminal Services on page 620
•
About the E-Mail Client on page 703
•
Multiple Sign-In Credentials Execution on page 317
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 283
•
Specifying Password Access Restrictions on page 75
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 © 2013, Juniper Networks, Inc.
315
Junos Pulse Secure Access Service 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 316
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 Secure Access Service 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
316
Copyright © 2013, Juniper Networks, Inc.
Chapter 12: 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 315
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 29: 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 © 2013, Juniper Networks, Inc.
317
Junos Pulse Secure Access Service 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:
•
318
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 © 2013, Juniper Networks, Inc.
Chapter 12: 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 © 2013, Juniper Networks, Inc.
319
Junos Pulse Secure Access Service Administration Guide
•
320
•
(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 © 2013, Juniper Networks, Inc.
Chapter 12: 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 © 2013, Juniper Networks, Inc.
321
Junos Pulse Secure Access Service 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, SAML 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 179
Understanding SAML 1.1
The Secure Access Service enables you to pass user and session state information
between the Secure Access Service and another trusted access management system
that supports the Security Assertion 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.
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 Secure Access Service supports two SAML use case scenarios:
•
The Secure Access Service as the SAML authority—The user signs into a resource by
way of the Secure Access Service first, and all other systems are SAML receivers, relying
on the Secure Access Service for authentication and authorization of the user. Under
this scenario, the Secure Access Service can use either an artifact profile or a POST
profile.
•
The Secure Access Service as the SAML receiver—The user signs into another system
on the network first, and the Secure Access Service is the SAML receiver, relying on the
other system for authentication and authorization of the user.
For example, in the first scenario, an authenticated Secure Access Service user named
John Smith may try to access a resource protected by an access management system.
322
Copyright © 2013, Juniper Networks, Inc.
Chapter 12: Single Sign-On
When he does, the Secure Access Service 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 Secure Access Service (and therefore trust that the Secure Access Service 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 Secure Access
Service.
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 Secure Access Service. 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 Secure Access Service, which can decide whether or
not to link to the reference.
3. If the Secure Access Service links to the reference, the portal sends a SOAP message
containing the SAML assertion (an XML message containing the user’s credentials)
to the Secure Access Service, which can then decide whether or not to allow the user
access to the requested resource.
NOTE: SOAP requests generated by the Secure Access Service (when
configured as a SAML 1.1 consumer) are not signed.
4. If the Secure Access Service allows the user access, the Secure Access Service presents
to the user the requested resource.
5. If the Secure Access Service rejects the SAML assertion, or the user credentials, the
Secure Access Service responds to the user with an error message.
When configuring the Secure Access Service, 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 resubmitting his credentials. In
this type of transaction, the Secure Access Service can be either the SAML authority
or the SAML receiver. When acting as the SAML authority, the Secure Access Service
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 Secure Access Service, the user is seamlessly
signed into the assertion consumer service using the username contained in the
statement.
When acting as the SAML receiver, the Secure Access Service 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 Secure
Copyright © 2013, Juniper Networks, Inc.
323
Junos Pulse Secure Access Service Administration Guide
Access Service must interpret, based on criteria that the Secure Access Service
administrator has specified in a SAML server instance definition. If the Secure Access
Service chooses to trust the asserting party, the Secure Access Service allows the user
to sign in seamlessly using the credentials contained in the SAML assertion.
•
Access control authorization—In a SAML access control transaction, the Secure Access
Service asks an access management system whether the user has access. In this type
of transaction, the Secure Access Service 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
Secure Access Service user has sufficient access privileges, the user may access the
requested resource
The Secure Access Service does not support attribute statements, which declare
specific details about the user (such as “John Smith is a member of the gold group”).
The Secure Access Service 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 Secure Access Service also allows you
to define users’ access rights to a URL using Secure Access Service-only mechanisms
(Users > Resource Profiles > Web Applications/Pages tab). If you define access controls
through the Secure Access Service as well as through a SAML authority, both sources
must grant access to a URL for a user to access it. For example, you may configure a
Secure Access Service 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 Secure Access Service 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 Secure Access
Service receives an indeterminate response, it denies the user access.
The session timeouts on the Secure Access Service and your access management
system may not coordinate with one another. If a user’s access management system
session cookie times out before his Secure Access Service destination signaling identifier
(DSID) cookie 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
•
Configuring SAML 1.1 SSO Profiles on page 272
Configuring SAML 1.1 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
the Secure Access Service or whether the Secure Access Service should “push” it to the
access management system. You indicate which communication method the two systems
324
Copyright © 2013, Juniper Networks, Inc.
Chapter 12: Single Sign-On
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 the Secure Access
Service, 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
the Secure Access Service.
Figure 22 on page 272 shows the SAML communication process when the implementation
uses the artifact profile.
Figure 30: Artifact Profile
The Secure Access Service 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 the Secure Access Service
and tries to access a protected resource on a Web server.
2. The Secure Access Service sends an HTTP or HTTPS GET request to the ACS—the
Secure Access Service intercepts the request and checks whether it has already
performed the necessary SSO operation to honor the request. If not, the Secure Access
Service creates an authentication statement and passes an HTTP query variable
called an artifact to the assertion consumer service.
An artifact profile is a Base64-encoded string that contains the source ID of the source
site (that is, a 20-byte string that references the Secure Access Service) 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, the Secure Access Service does not send
a statement. Also note that the Secure Access Service discards a handle after its first
use to prevent the handle from being used twice.)
3. The ACS sends a SAML request to the Secure Access Service—The assertion consumer
service uses the source ID sent in the previous step to determine the location of the
Secure Access Service. Then the assertion consumer service sends a statement request
wrapped in a SOAP message to the following address on the Secure Access Service:
https://<<ivehostname>/danaws/saml.ws
The request includes the statement handle passed in the previous step.
Copyright © 2013, Juniper Networks, Inc.
325
Junos Pulse Secure Access Service Administration Guide
NOTE: The Secure Access Service 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 Service), 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. The Secure Access Service sends an authentication statement to the ACS—the Secure
Access Service uses the statement handle in the request to find the correct statement
in the Secure Access Service cache and then sends the appropriate authentication
statement back to the assertion consumer service. The unsigned statement contains
the user's identity and the mechanism he used to sign into the Secure Access Service.
5. The ACS sends a cookie to the Secure Access Service—The assertion consumer service
accepts the statement and then it sends a cookie back to the Secure Access Service
that enables the user’s session.
6. The Secure Access Service sends the cookie to the Web server—the Secure Access
Service caches the cookie to handle future requests. Then the Secure Access Service
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 the Secure Access Service to use artifact profiles,
you must install the Secure Access Service 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 check box.
c. Select the SAML check box below the SSO check box.
d. Click OK.
3. Use the tabs to display the SSO > SAML page.
4. Click New Policy.
5. On the New Policy page, enter:
a. A name to label this policy.
326
Copyright © 2013, Juniper Networks, Inc.
Chapter 12: 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—The Secure Access Service performs a single-sign
on (SSO) request to the specified URL using the data specified in the SAML SSO
details section. The Secure Access Service makes the SSO request when a user
tries to access a SAML resource specified in the Resources list.
•
Do NOT use SAML—The Secure Access Service 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 the Secure Access
Service 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 the
Secure Access Service 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 the Secure Access Service.
•
Profile—Select Artifact to indicate that the assertion consumer service should “pull”
information from the Secure Access Service during SSO transactions.
•
Source ID—Enter the source ID for the Secure Access Service. It must be a
Base64-encoded string. The Secure Access Service decodes it and ensures that it
is 20 bytes. You can use OpenSSL or other Base64 tool to generate the
Base64-encoded string.
NOTE: The Secure Access Service identifier (that is, the source ID) must
map to the following URL on the assertion consumer service:
https://<ivehostname>/dana-ws/saml.ws
Copyright © 2013, Juniper Networks, Inc.
327
Junos Pulse Secure Access Service Administration Guide
•
Issuer—Enter a unique string that the Secure Access Service can use to identify itself
when it generates assertions (typically its hostname).
NOTE: You must configure the assertion consumer service to recognize
the Secure Access Service unique string.
10. In the User Identity section, specify how the Secure Access Service and the assertion
consumer service should identify the user:
•
Subject Name Type—Specify which method the Secure Access Service 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 the Secure Access
Service and the assertion consumer service.
•
Subject Name—Use variables to specify the username that the Secure Access Service
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
the Secure Access Service 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 the Secure Access Service.
•
Certificate Attribute—Authenticate the assertion consumer service using certificate
attributes. Enter the attributes that the assertion consumer service must send the
Secure Access Service (one attribute per line). For example, use cn=sales. You must
use values that match the values contained in the assertion consumer service
certificate.
NOTE: If you select this option, you must install the assertion consumer
service root CA on the Secure Access Service.
12. Cookie Domain—Enter a comma-separated list of domains to which we send the SSO
cookie.
328
Copyright © 2013, Juniper Networks, Inc.
Chapter 12: Single Sign-On
13. Click Save Changes.
14. On the SAML SSO Policies page, order the policies according to how you want the
Secure Access Service to evaluate them. Keep in mind that once the Secure Access
Service 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 Secure Access Service on page 814
Creating a SAML 1.1 SSO POST Profile
When you choose to communicate using a POST profile (also called browser/POST
profile), the Secure Access Service “pushes” authentication data to the access
management system using an HTTP POST command over an SSL 3.0 connection.
Figure 23 on page 276 shows the SAML communication process when the implementation
uses the POST profile.
Figure 31: POST Profile
The Secure Access Service and an access management system use the following process
to pass information:
1.
The user tries to access a resource—A user is signed into the Secure Access Service
and tries to access a protected resource on a Web server.
2. The Secure Access Service posts a statement—the Secure Access Service intercepts
the request and checks whether it has already performed the necessary SSO operation
to honor the request. If not, the Secure Access Service 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 the Secure Access Service uses to sign the statement.
Copyright © 2013, Juniper Networks, Inc.
329
Junos Pulse Secure Access Service Administration Guide
3. The AM establishes a session—If the user has the proper permissions, the access
management server sends a cookie back to the Secure Access Service that enables
the user’s session.
4. The Secure Access Service sends the cookie to the Web server—the Secure Access
Service caches the cookie to handle future requests. Then the Secure Access Service
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 the Secure Access Service to use POST profiles,
you must install the assertion consumer service’s root CA on the Secure
Access Service 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, 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 check box.
c. Select the SAML check box below the SSO check box.
d. Click OK.
3. Use the tabs to display the SSO > SAML page.
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:
330
Copyright © 2013, Juniper Networks, Inc.
Chapter 12: Single Sign-On
•
Use the SAML SSO defined below—The Secure Access Service performs a single-sign
on (SSO) request to the specified URL using the data specified in the SAML SSO
details section. The Secure Access Service makes the SSO request when a user
tries to access a SAML resource specified in the Resources list.
•
Do NOT use SAML—The Secure Access Service does not perform an 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 the Secure Access
Service should use to contact the assertion consumer service (that is, the access
management server). For example, use https://hostname/acs.
•
Profile—Select POST to indicate that the Secure Access Service should “push”
information to the assertion consumer service during SSO transactions.
•
Issuer—Enter a unique string that the Secure Access Service can use to identify itself
when it generates assertions. Typically, the issuer string is a hostname.
NOTE: You must configure the assertion consumer service to recognize
the Secure Access Service unique string.
•
Signing Certificate—Specify which certificate the Secure Access Service should use
to sign its assertions.
10. In the User Identity section, specify how the Secure Access Service and the assertion
consumer service should identify the user:
•
Subject Name Type—Specify which method the Secure Access Service 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 e-mail address.
•
Windows—Send the username in the format of a Windows domain qualified
username.
•
Other—Send the username in another format agreed upon by the Secure Access
Service and the assertion consumer service.
•
Subject Name—Use variables to specify the username that the Secure Access Service
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.
Copyright © 2013, Juniper Networks, Inc.
331
Junos Pulse Secure Access Service Administration Guide
11. Click Save Changes.
12. On the SAML SSO Policies page, order the policies according to how you want the
Secure Access Service to evaluate them. Keep in mind that once the Secure Access
Service 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 Secure Access Service on page 814
•
Writing a Web Proxy Resource Policy on page 531
Creating a SAML 1.1 ACL Resource Policy
When enabling access control transactions to a trusted access management system,
the Secure Access Service and trusted access management system exchange information
using the method shown in Figure 24 on page 279.
Figure 32: Access Control Policies
The Secure Access Service and an access management system use the following process
to pass information:
1.
The user tries to access a resource—A user is signed into the Secure Access Service
and tries to access a protected resource on a Web server.
2. The Secure Access Service posts an authorization decision query—If the Secure Access
Service has already made an authorization request and it is still valid, the Secure
Access Service 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,
the Secure Access Service 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 access management system posts an authorization decision statement—The
access management system sends an HTTPS POST containing a SOAP message
332
Copyright © 2013, Juniper Networks, Inc.
Chapter 12: Single Sign-On
that contains the authorization decision statement. The authorization decision
statement contains a result of permit, deny, or indeterminate.
4. The Secure Access Service sends the request to the Web browser—If the authorization
decision statement returns a result of permit, the Secure Access Service allows the
user access. If not, the Secure Access Service presents an error page to the user telling
him that he does not have the proper access permissions.
NOTE: If you configure the Secure Access Service to use access control
transactions, you must install the SAML Web service root CA on the Secure
Access Service.
To create 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 check box below the Access check box.
c. Click OK.
3. Use the tabs to display the Access > SAML ACL page.
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—The Secure Access Service
performs an access control check to the specified URL using the data specified in
the SAML Access Control Details section.
Copyright © 2013, Juniper Networks, Inc.
333
Junos Pulse Secure Access Service Administration Guide
•
Do not use SAML Access—The Secure Access Service 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, use https://hostname/ws.
•
Issuer—Enter the hostname of the issuer, which in most cases is the hostname of
the access management system.
NOTE: You must enter a unique string that the SAML Web service uses
to identify itself in authorization assertions.
10. In the User Identity section, specify how the Secure Access Service and the SAML
Web service should identify the user:
•
Subject Name Type—Specify which method the Secure Access Service 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 e-mail address.
•
Windows—Send the username in the format of a Windows domain qualified
username.
•
Other—Send the username in another format agreed upon by the Secure Access
Service and the SAML Web service.
•
Subject Name—Use variables to specify the username that the Secure Access Service
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 the Secure Access Service:
•
None—Do not authenticate the Secure Access Service.
•
Username—Authenticate the Secure Access Service using a username and password.
Enter the username and password that the Secure Access Service must send the
Web service.
•
Certificate Attribute—Authenticate the Secure Access Service using a certificate
signed by a trusted certificate authority. If you have more than one certificate
installed on the Secure Access Service, use the drop-down list to select which
certificate to send to the Web service.
334
Copyright © 2013, Juniper Networks, Inc.
Chapter 12: Single Sign-On
NOTE: If you select this option, you must install the Secure Access
Service Web server certificate on the access management system Web
server and determine which method the SAML Web service uses to trust
the certificate.
12. In the Options section, specify:
•
Maximum Cache Time—You can eliminate the overhead of generating an
authorization decision each time the user requests the same URL by indicating that
the Secure Access Service must cache the access management system’s
authorization responses. Enter the amount of time the Secure Access Service should
cache the responses (in seconds).
•
Ignore Query Data—By default, when a user requests a resource, the Secure Access
Service sends the entire URL for that resource (including the query parameter) to
the SAML Web service and caches the URL. You can specify that the Secure Access
Service should remove 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 the Secure Access Service to evaluate them. Keep in mind that once the Secure
Access Service 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 Secure Access Service on page 814
•
Writing a Web Proxy Resource Policy on page 531
Creating a Trust Relationship Between SAML 1.1 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 (the Secure Access Service) needs to know the URL of the other system.
(The Secure Access Service 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.
The following list shows the different transaction types and the URLs you must configure
for each:
Copyright © 2013, Juniper Networks, Inc.
335
Junos Pulse Secure Access Service Administration Guide
•
SSO transactions: Artifact profile—On the Secure Access Service, you must enter the
URL of the assertion consumer service. For example, use https://hostname/acs.
You must also enter the following URL for the Secure Access Service on the assertion
consumer service. For example, use
https://<SecureAccessHostname>/dana-ws/saml.ws.
•
SSO transactions: POST profile—On the Secure Access Service, you must enter the
URL of the assertion consumer service. For example, use https://hostname/acs.
•
Access control transactions—On the Secure Access Service, you must enter the URL
of the SAML Web service. For example, use 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 hostnames 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.
The following list shows the different transaction types and the issuers you must configure
for each:
•
SSO transactions—You must specify a unique string on the Secure Access Service
(typically its hostname) 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 hostname) that it can use to identify itself and then
configure the Secure Access Service 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 the Secure
Access Service SAML transactions to use SSL (HTTPS).
Configuring SSO Transactions: Artifact Profile
Artifact profile transactions involve numerous communications back and forth between
the Secure Access Service and the access management system. The methods you use
to pass data and authenticate the two systems affect which certificates you must install
and configure.
The following list shows the different artifact profile configuration options that require
special certificate configurations:
•
336
All artifact profile transactions—Regardless of your artifact profile configuration, you
must install the certificate of the CA that signed the Secure Access Service Web server
Copyright © 2013, Juniper Networks, Inc.
Chapter 12: Single Sign-On
certificate on the access management system. (The Secure Access Service 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
the Secure Access Service 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 the Secure Access
Service. (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 the Secure
Access Service, you ensure that the Secure Access Service 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 the Secure Access Service to the access
management system, enter a URL that begins with HTTPS in the SAML Assertion
Consumer Service URL field during the Secure Access Service configuration. You may
also need to enable SSL on the access management system.
•
Transactions using certificate authentication—If you choose to authenticate the access
management system using a certificate, you must:
•
Install the access management system’s root CA certificate on the Secure Access
Service. You can install the root CA from the System > Configuration > Certificates
> Trusted Client CAs page in the admin console.
•
Specify which certificate values the Secure Access Service 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, the Secure Access Service sends signed authentication
statements to the access management system. Generally, it sends them over an SSL
connection (recommended), but in some configurations, the Secure Access Service may
send statements through a standard HTTP connection.
The following list shows 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 the Secure Access Service 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 the Secure Access
Service device certificate on the access management system. You can download the
Copyright © 2013, Juniper Networks, Inc.
337
Junos Pulse Secure Access Service Administration Guide
Secure Access Service 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 the Secure Access
Service. (In an SSL connection, the initiator must trust the system to which it is
connecting. By installing the access management system’s certificate on the Secure
Access Service, you ensure that the Secure Access Service 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 the Secure Access Service to the access
management system, enter a URL that begins with HTTPS in the SAML assertion
consumer service URL field during the Secure Access Service configuration. You may
also need to enable SSL on the access management system.
Configuring Access Control Transactions
In an access control transaction, the Secure Access Service 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.
The following list shows the different access control configuration options that require
special certificate configurations:
•
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 the Secure Access Service. (In an SSL connection,
the initiator must trust the system to which it is connecting. By installing the access
management system’s certificate on the Secure Access Service, you ensure that the
Secure Access Service 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 the Secure Access Service certificate. Optionally, you may also choose to
accept the certificate based on the following additional options:
•
Upload the Secure Access Service certificate public key to the access management
system.
•
Validate the Secure Access Service using specific certificate attributes.
These options require that you specify which certificate the Secure Access Service
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.
338
Copyright © 2013, Juniper Networks, Inc.
Chapter 12: Single Sign-On
To determine how to configure your access management system to validate the Secure
Access Service 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 the Secure
Access Service 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 hardcode 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 the Secure Access Service 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. Choose a username or attribute that the access management system will recognize.
Related
Documentation
•
Using a Trusted Client CA on page 822
•
Understanding SAML 1.1 on page 259
•
Configuring SAML 1.1 SSO Profiles on page 272
•
Configuring General Role Options on page 99
Copyright © 2013, Juniper Networks, Inc.
339
Junos Pulse Secure Access Service Administration Guide
340
Copyright © 2013, Juniper Networks, Inc.
CHAPTER 13
Synchronizing User Records
•
About User Record Synchronization on page 341
•
Enabling User Record Synchronization on page 343
•
Configuring the User Record Synchronization Authentication Server on page 344
•
Configuring the User Record Synchronization Server on page 345
•
Configuring the User Record Synchronization Client on page 345
•
Configuring the User Record Synchronization Database on page 346
•
Scheduling User Record Synchronization Backup on page 347
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
Copyright © 2013, Juniper Networks, Inc.
341
Junos Pulse Secure Access Service Administration Guide
must be the same for user record data to be synchronized across the servers. The logical
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 7.2 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.
342
Copyright © 2013, Juniper Networks, Inc.
Chapter 13: 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.
The user record synchronization feature will not start automatically after
importing a system configuration that has this feature enabled. The
workaround is to disable user record synchronization and then enable user
record synchronization from the user interface after the configuration import.
Related
Documentation
•
Enabling User Record Synchronization on page 343
•
Configuring the User Record Synchronization Authentication Server on page 344
•
Configuring the User Record Synchronization Server on page 345
•
Configuring the User Record Synchronization Client on page 345
•
Configuring the User Record Synchronization Database on page 346
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.
Copyright © 2013, Juniper Networks, Inc.
343
Junos Pulse Secure Access Service Administration Guide
5. Select whether this node is client only or if this node acts as both a client and server.
6. Click Save Changes.
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 344
•
Configuring the User Record Synchronization Server on page 345
•
Configuring the User Record Synchronization Client on page 345
•
Configuring the User Record Synchronization Database on page 346
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
344
•
Configuring the User Record Synchronization Client on page 345
•
Configuring the User Record Synchronization Database on page 346
Copyright © 2013, Juniper Networks, Inc.
Chapter 13: Synchronizing User Records
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.
Select System > Configuration > User Record Synchronization > This Server.
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 344
•
Configuring the User Record Synchronization Client on page 345
•
Configuring the User Record Synchronization Database on page 346
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.
Copyright © 2013, Juniper Networks, Inc.
345
Junos Pulse Secure Access Service Administration Guide
Related
Documentation
•
Configuring the User Record Synchronization Authentication Server on page 344
•
Configuring the User Record Synchronization Server on page 345
•
Configuring the User Record Synchronization Database on page 346
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.
346
•
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.
Copyright © 2013, Juniper Networks, Inc.
Chapter 13: Synchronizing User Records
•
Click Export to export the user records from the specified source (cache or database).
You will be prompted where to save the file.
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 344
•
Configuring the User Record Synchronization Server on page 345
•
Configuring the User Record Synchronization Client on page 345
Scheduling User Record Synchronization Backup
You can configure periodic backups of the user record database. User record
synchronization backup can be enabled only on a user record synchronization server.
To backup the user record database:
1.
Ensure the system is set up as a user record synchronization server. See System >
Configuration > User Record Synchronization.
2. Select Maintenance > Archiving > Archiving Servers.
3. Select the Archive User Record Synchronization Database check box.
Copyright © 2013, Juniper Networks, Inc.
347
Junos Pulse Secure Access Service Administration Guide
4. Specify an archive schedule. Through the options, schedule archives on any
combination of weekdays including weekends.
NOTE: If you schedule an archival operation to occur during the hour that
your system switches to Daylight Savings Time (DST) the operation may
not occur as scheduled. For example, if your system is set to change to
DST at 1:00 a.m. and you have scheduled an archival operation to occur
at anytime between 1:01 a.m. and 1:59 a.m., the operation is not
accomplished, because at 1:00 a.m. the system clock is moved forward
to 2:00 a.m. and the system never reaches your archival time for that date.
5. Define a specific time when you want Secure Access Service to archive data or elect
to archive data every hour, which produces twenty-four files with unique timestamps.
NOTE: We recommend you schedule an archival operation during hours
when traffic is light in order to minimize its impact to your users. The
automatic archiving process compresses files and, if the system is busy,
can degrade performance for users. Also, a cluster node may appear
unresponsive if the system is busy with traffic and performing archiving
simultaneously.
6. Provide a password if you want to encrypt system configuration or user account
archives with a password (optional).
7. Click Save Changes.
Related
Documentation
348
•
Configuring the User Record Synchronization Database on page 346
Copyright © 2013, Juniper Networks, Inc.
PART 3
Endpoint Defense
•
Host Checker on page 351
•
Cache Cleaner on page 423
Copyright © 2013, Juniper Networks, Inc.
349
Junos Pulse Secure Access Service Administration Guide
350
Copyright © 2013, Juniper Networks, Inc.
CHAPTER 14
Host Checker
•
Host Checker and Trusted Network Computing on page 352
•
Task Summary: Configuring Host Checker on page 354
•
Creating Global Host Checker Policies on page 355
•
Enabling Enhanced Endpoint Security Functionality on page 357
•
Enabling Connection Control Host Checker Policies (Windows Only) on page 359
•
Creating and Configuring New Client-side Host Checker Policies on page 360
•
Checking for Third-Party Applications Using Predefined Rules (Windows
Only) on page 361
•
Configuring a Predefined Antivirus Rule with Remediation Options on page 362
•
Configuring a Predefined Firewall Rule with Remediation Options (Windows
Only) on page 364
•
Configuring a Predefined AntiSpyware Rule (Windows Only) on page 365
•
Configuring Virus Signature Version Monitoring and Patch Assessment Data
Monitoring on page 366
•
Patch Management Info Monitoring and Patch Deployment on page 368
•
Specifying Customized Requirements Using Custom Rules on page 372
•
Using a Wildcard or Environment Variable in a Host Checker Rule on page 377
•
Configuring Patch Assessment Policies on page 379
•
Configuring Patch Assessment Rules on page 381
•
Using Third-party Integrity Measurement Verifiers on page 383
•
Configuring a Remote IMV Server on page 384
•
Implementing the Third-Party IMV Policy on page 388
•
Implementing Host Checker Policies on page 389
•
Configuring Host Checker Restrictions on page 392
•
Remediating Host Checker Policies on page 393
•
Configuring General Host Checker Remediation on page 395
•
Upgrading the Endpoint Security Assessment Plug-In on page 397
•
Defining Host Checker Pre-Authentication Access Tunnels on page 399
•
Specifying Host Checker Pre-Authentication Access Tunnel Definitions on page 400
Copyright © 2013, Juniper Networks, Inc.
351
Junos Pulse Secure Access Service Administration Guide
•
Specifying General Host Checker Options on page 403
•
Specifying Host Checker Installation Options on page 404
•
Client ActiveX Installation Delay on page 406
•
Using Host Checker with the GINA Automatic Sign-In Function on page 406
•
Installing Host Checker Automatically or Manually on page 407
•
Using Host Checker Logs on page 408
•
Configuring Host Checker for Windows Mobile on page 408
•
Host Checker for Apple iOS on page 410
•
Using Proxy Exceptions on page 414
•
Enabling the Secure Virtual Workspace on page 415
•
Defining Secure Virtual Workspace Permissions on page 417
•
Defining a Secure Virtual Workspace Application Policy on page 419
•
Defining a Secure Virtual Workspace Security Policy on page 420
•
Defining Secure Virtual Workspace Environment Options on page 421
•
Defining Secure Virtual Workspace Remediation Policy on page 421
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 Secure Access Service.
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 Secure Access Service 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 Secure Access Service realms, launch the software
352
Copyright © 2013, Juniper Networks, Inc.
Chapter 14: Host Checker
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 display remediation instructions to users so they
can bring their computers into compliance.
NOTE: If you configure a large number of Host Checker policies, and the
Secure Access Service is under a heavy load, the server process inside the
device could get overloaded. When this happens, a message appears in the
event log (Log/Monitoring > Events > Log).
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 Secure Access Service and verify a particular aspect of an host’s integrity.
Each IMV on the Secure Access Service 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 Secure Access Service that are responsible
for verifying a particular aspect of an endpoint’s integrity.
The Secure Access Service and Host Checker manage the flow of information between
the corresponding pairs of IMVs and IMCs. Each IMV on the Secure Access Service 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 355
•
Task Summary: Configuring Host Checker on page 354
Copyright © 2013, Juniper Networks, Inc.
353
Junos Pulse Secure Access Service Administration Guide
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.
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:
354
•
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.
Copyright © 2013, Juniper Networks, Inc.
Chapter 14: Host Checker
•
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:
•
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 355
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.
Copyright © 2013, Juniper Networks, Inc.
355
Junos Pulse Secure Access Service Administration Guide
Secure Access provides many options that you can use to enable, create, and configure
Host Checker policies:
Related
Documentation
356
•
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:
•
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 384
•
Implementing Host Checker Policies on page 389
Copyright © 2013, Juniper Networks, Inc.
Chapter 14: Host Checker
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.
•
Adware
•
Dialers
•
Hijack
•
Spy Cookie
•
Commercial System Monitor
•
System Monitor (detects spyware, keyloggers, screenscrapers and any malware that
monitors the system)
•
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, *.cloudfront.net, *.edgesuite.net and *.akamai.net.
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
Copyright © 2013, Juniper Networks, Inc.
357
Junos Pulse Secure Access Service Administration Guide
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
VPN Tunneling.
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.
User Experience
For endpoints that do not have VPN Tunneling 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
358
Copyright © 2013, Juniper Networks, Inc.
Chapter 14: Host Checker
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
•
Configuring Host Checker Restrictions on page 392
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.
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 VPN Tunneling
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.
Copyright © 2013, Juniper Networks, Inc.
359
Junos Pulse Secure Access Service Administration Guide
Related
Documentation
•
Configuring Host Checker Restrictions on page 392
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.
NOTE: We recommend you check for multiple MAC addresses in a single
policy instead of creating a policy for each MAC address. If you create policies
for each MAC address, unexpected results may occur if there are more than
100 policies due to browser cookie size limitations.
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.
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
360
•
Checking for Third-Party Applications Using Predefined Rules (Windows Only) on
page 361
•
Specifying Customized Requirements Using Custom Rules on page 372
•
Configuring General Host Checker Remediation on page 395
•
Configuring Host Checker Restrictions on page 392
Copyright © 2013, Juniper Networks, Inc.
Chapter 14: Host Checker
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:
•
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.
•
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
Copyright © 2013, Juniper Networks, Inc.
361
Junos Pulse Secure Access Service Administration Guide
•
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 360
•
Configuring a Predefined Firewall Rule with Remediation Options (Windows Only) on
page 364
•
Configuring a Predefined Antivirus Rule with Remediation Options on page 362
•
Implementing Host Checker Policies on page 389
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.
362
Copyright © 2013, Juniper Networks, Inc.
Chapter 14: Host Checker
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.
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.
Copyright © 2013, Juniper Networks, Inc.
363
Junos Pulse Secure Access Service Administration Guide
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 366
•
Creating and Configuring New Client-side Host Checker Policies on page 360
•
Implementing Host Checker Policies on page 389
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.
364
Copyright © 2013, Juniper Networks, Inc.
Chapter 14: Host Checker
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.
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 360
•
Implementing Host Checker Policies on page 389
Configuring a Predefined 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.
Copyright © 2013, Juniper Networks, Inc.
365
Junos Pulse Secure Access Service Administration Guide
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 360
•
Implementing Host Checker Policies on page 389
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.
366
Copyright © 2013, Juniper Networks, Inc.
Chapter 14: Host Checker
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.
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.
Copyright © 2013, Juniper Networks, Inc.
367
Junos Pulse Secure Access Service Administration Guide
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 841
•
Implementing Host Checker Policies on page 389
Patch Management Info Monitoring and Patch Deployment
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. Host Checker does not scan for non-security patches.
You obtain the most current patch version information from a Juniper Networks staging
site. You can manually download and import the list into the Secure Access Service, or
you can automatically import the list from the Juniper Networks staging site or your own
staging site at a specified interval.
Monitoring is based on either 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. In addition, for Microsoft
products, you can specify the severity level of patches that you wish to ignore. For example,
you could ignore low or moderate threats.
The Secure Access Service can send remediation instructions (such as. a message
describing what patches or software are non-compliant, and a link to where the endpoint
can obtain the patch). The Secure Access Service does not autoremediate in the event
368
Copyright © 2013, Juniper Networks, Inc.
Chapter 14: Host Checker
of a non-compliant endpoint. However, you can send the items to the client for manual
remediation of managed machines.
When an endpoint first connects to the Secure Access Service, 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 the files are outdated, they
are automatically updated at subsequent checks. If this is the first time the endpoint has
connected to the Secure Access Service 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 that 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.
Additional Functionality with Pulse 2.0
With Pulse 2.0, additional functionality is provided for Patch Info Monitoring and
Deployment.
Endpoints with Pulse 2.0 that are not in compliance with specified patch policies can be
updated with the required patches and brought into compliance automatically. This is
achieved through a new patch deployment engine. The patch deployment engine executes
on endpoints, downloads specified patches, and installs patches that are required through
the Host Checker policy. The patch deployment engine provides a new means of
remediating endpoints that do not meet the patch assessment policies defined on the
Secure Access Service. This functionality is available for Windows XP, and Vista and
Windows 7 32 bit and 64 bit versions.
The Host Checker IMC on the endpoint interfaces with the patch deployment engine to
download and install missing patches reported by the IMV. When the patch installation
is complete, the IMC signals the TNC client to start a new handshake with the Secure
Access Service, and enables the Secure Access Service to make access control decisions
based on the result of the handshake.
Endpoints without Pulse 2.0 can still use the legacy basic patch remediation mechanism,
in which a pre-installed SMS client is triggered to get patches from a pre-configured SMS
server. This mechanism installs only those patches that are published on the SMS server.
If the SMS client is not installed, or the server doesn’t host the patches required by the
policies on Secure Access Service, the endpoint cannot be fully remediated.
The patch deployment engine is an executable file that is hosted on the Secure Access
Service. The executable can be downloaded to any endpoint that you would like to
remediate. Unlike the SMS client, one can specify what patches need to be applied. The
patch deployment engine directly downloads missing patches from vendor websites,
without going through the Secure Access Service. Therefore, Internet connectivity is
needed for Shavlik remediation to work. The patch deployment engine does not work
with Layer 2 without Layer 3 connectivity. You can configure a remediation VLAN for post
authentication. Once Layer 3 connectivity is obtained, endpoints can remediate
successfully. With Layer 3 connectivity, the patch deployment engine downloads missing
patches.
Copyright © 2013, Juniper Networks, Inc.
369
Junos Pulse Secure Access Service Administration Guide
A separate license is required for patch info monitoring and deployment functionality. It
is not available as part of the endpoint solution.
All of the files required for patch deployment are a part of a ESAP packages beginning
with Secure Access Service software version 7.1. The default ESAP package shipped with
Series SSL VPN Appliance software version 7.1 contains the required patch deployment
files. Any older ESAP packages fail to update on these devices.
The IMC and IMV for patch monitoring is backward compatible. Since this feature is
available from Pulse 2.0 onward, a new Pulse communicating with an older IMV (with
Pulse support), or a new IMV communicating to an older IMC exhibit the same behavior
as today. There should be no change in the patch assessment, and Shavlik’s deployment
engine is not invoked for remediation.
User Experience
Patch remediation can take a good deal of time, and policies continue to fail until the
process is completed. When an update is required, the user is given an option to proceed
with patch deployment. If the user decides not to deploy the patch(es) and proceed, the
user may not have connectivity or may have limited connectivity, depending on the Secure
Access Service administration configuration. If any patches require a reboot subsequent
to installation, the application informs Host Checker, and Pulse notifies the user. In this
case, until the machine is rebooted, patches continue to be reported as missing in
subsequent patch assessments. If a reboot is required, any further patch deployment is
not carried out until the machine is rebooted. The user is notified if a reboot is required.
Pulse notifies the user that patches need to be installed, and provides status as the
download is occurring. When the installation is complete, the client presents the login
dialogue.
Using a System Management Server
You can use a System Management Server (SMS) to provide a method for automatic
updates to non-compliant software.
Pulse 2.0 can support either the SMS download method or the patch deployment engine
for patch deployment, depending on the configuration on the Secure Access Service. If
the Secure Access Service is configured for the SMS method for patch deployment, the
client machine should have the SMS client already installed in the machine for deployment
to begin , otherwise remediation fails.
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 might have to wait until
the next update interval to login.
Using the SMS download method, 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
370
Copyright © 2013, Juniper Networks, Inc.
Chapter 14: Host Checker
notifies the client to poll the server for an immediate update. The client receives
notification that an SMS update has started.
To configure SMS to update the client when notified, set the advertisement time on the
SMS to As soon as possible. The following process then occurs:
•
The Secure Access Service 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 Secure Access Service.
•
The Secure Access Service 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 server
can advertise patches for that collection. You can configure roles on the Secure Access
Service 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 the SMS sends back the
advertisement.
Juniper Networks recommends only one patch deployment on the endpoint at any point
in time. However, there is no way to determine if an SMS update is in progress, and so it
may be possible that the patch deployment engine is started while a SMS Update is also
occurring (this could happen if Pulse is connected to two IC Series or Secure Access
Services with one using SMS remediation and the other using the patch deployment
engine). Given the fact that most patches will not allow two instances to be running, one
of the remediations fail, depending on which began first.
The Admin Console allows you to select only one of the remediation options (either SMS
or patch deployment engine) for all the policies.
If Pulse is connected to more than one IC Series or Secure Access Service, and one requires
patch deployment engine remediation and the other requires SMS remediation, both
requests are met. If both require the patch deployment engine method, the requests are
queued.
Copyright © 2013, Juniper Networks, Inc.
371
Junos Pulse Secure Access Service 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.
372
Copyright © 2013, Juniper Networks, Inc.
Chapter 14: 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