Secure Access Administration Guide

Secure Access Administration Guide
Juniper Networks Secure Access
Administration Guide
Release 6.5
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Part Number: 65A190410
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.
Juniper Networks, the Juniper Networks logo, NetScreen, NetScreen Technologies, the NetScreen logo, NetScreen-Global Pro, ScreenOS, and GigaScreen are
registered trademarks of Juniper Networks, Inc. in the United States and other countries.
The following are trademarks of Juniper Networks, Inc.: ERX, E-series, ESP, Instant Virtual Extranet, Internet Processor, J2300, J4300, J6300, J-Protect,
J-series, J-Web, JUNOS, JUNOScope, JUNOScript, JUNOSe, M5, M7i, M10, M10i, M20, M40, M40e, M160, M320, M-series, MMD, NetScreen-5GT,
NetScreen-5XP, NetScreen-5XT, NetScreen-25, NetScreen-50, NetScreen-204, NetScreen-208, NetScreen-500, NetScreen-5200, NetScreen-5400,
NetScreen-IDP 10, NetScreen-IDP 100, NetScreen-IDP 500, NetScreen-Remote Security Client, NetScreen-Remote VPN Client, NetScreen-SA 1000 Series,
NetScreen-SA 3000 Series, NetScreen-SA 5000 Series, NetScreen-SA Central Manager, NetScreen Secure Access, NetScreen-SM 3000, NetScreen-Security
Manager, NMC-RX, SDX, Stateful Signature, T320, T640, T-series, and TX Matrix. All other trademarks, service marks, registered trademarks, or registered
service marks are the property of their respective owners. All specifications are subject to change 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.
Copyright © 2008, Juniper Networks, Inc.
All rights reserved. Printed in USA.
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.
Year 2000 Notice
Juniper Networks hardware and software products are Year 2000 compliant. The JUNOS software has no known time-related limitations through the year
2038. However, the NTP application is known to have some difficulty in the year 2036.
Software License
The terms and conditions for using this software are described in the software license contained in the acknowledgment to your purchase order or, to the
extent applicable, to any reseller agreement or end-user purchase agreement executed between you and Juniper Networks. By using this software, you
indicate that you understand and agree to be bound by those terms and conditions.
Generally speaking, the software license restricts the manner in which you are permitted to use the software and may contain prohibitions against certain
uses. The software license may state conditions under which the license is automatically terminated. You should consult the license for further details.
For complete product documentation, please see the Juniper Networks Web site at www.juniper.net/techpubs.
End User License Agreement
READ THIS END USER LICENSE AGREEMENT ("AGREEMENT") BEFORE DOWNLOADING, INSTALLING, OR USING THE SOFTWARE. BY
DOWNLOADING, INSTALLING, OR USING THE SOFTWARE OR OTHERWISE EXPRESSING YOUR AGREEMENT TO THE TERMS CONTAINED HEREIN, YOU
(AS CUSTOMER OR IF YOU ARE NOT THE CUSTOMER, AS A REPRESENTATIVE/AGENT AUTHORIZED TO BIND THE CUSTOMER) CONSENT TO BE BOUND
BY THIS AGREEMENT. IF YOU DO NOT OR CANNOT AGREE TO THE TERMS CONTAINED HEREIN, THEN (A) DO NOT DOWNLOAD, INSTALL, OR USE THE
SOFTWARE, AND (B) YOU MAY CONTACT JUNIPER NETWORKS REGARDING LICENSE TERMS.
1. The Parties. The parties to this Agreement are Juniper Networks, Inc. and its subsidiaries (collectively “Juniper”), and the person or organization that
originally purchased from Juniper or an authorized Juniper reseller the applicable license(s) for use of the Software (“Customer”) (collectively, the “Parties”).
2. The Software. In this Agreement, “Software” means the program modules and features of the Juniper or Juniper-supplied software, and updates and
releases of such software, for which Customer has paid the applicable license or support fees to Juniper or an authorized Juniper reseller.
3. License Grant. Subject to payment of the applicable fees and the limitations and restrictions set forth herein, Juniper grants to Customer a non-exclusive
and non-transferable license, without right to sublicense, to use the Software, in executable form only, subject to the following use restrictions:
a. Customer shall use the Software solely as embedded in, and for execution on, Juniper equipment originally purchased by Customer from Juniper or an
authorized Juniper reseller, unless the applicable Juniper documentation expressly permits installation on non-Juniper equipment.
b. Customer shall use the Software on a single hardware chassis having a single processing unit, or as many chassis or processing units for which Customer
has paid the applicable license fees.
c. Product purchase documents, paper or electronic user documentation, and/or the particular licenses purchased by Customer may specify limits to
Customer’s use of the Software. Such limits may restrict use to a maximum number of seats, registered endpoints, concurrent users, sessions, calls,
connections, subscribers, clusters, nodes, or transactions, or require the purchase of separate licenses to use particular features, functionalities, services,
applications, operations, or capabilities, or provide throughput, performance, configuration, bandwidth, interface, processing, temporal, or geographical
limits. Customer’s use of the Software shall be subject to all such limitations and purchase of all applicable licenses.
The foregoing license is not transferable or assignable by Customer. No license is granted herein to any user who did not originally purchase the applicable
license(s) for the Software from Juniper or an authorized Juniper reseller.
4. Use Prohibitions. Notwithstanding the foregoing, the license provided herein does not permit the Customer to, and Customer agrees not to and shall not:
(a) modify, unbundle, reverse engineer, or create derivative works based on the Software; (b) make unauthorized copies of the Software (except as necessary
for backup purposes); (c) rent, sell, transfer, or grant any rights in and to any copy of the Software, in any form, to any third party; (d) remove any
proprietary notices, labels, or marks on or in any copy of the Software or any product in which the Software is embedded; (e) distribute any copy of the
Software to any third party, including as may be embedded in Juniper equipment sold in the secondhand market; (f) use any ‘locked’ or key-restricted
feature, function, service, application, operation, or capability without first purchasing the applicable license(s) and obtaining a valid key from Juniper, even
if such feature, function, service, application, operation, or capability is enabled without a key; (g) distribute any key for the Software provided by Juniper to
any third party; (h) use the Software in any manner that extends or is broader than the uses purchased by Customer from Juniper or an authorized Juniper
reseller; (i) use the Software on non-Juniper equipment where the Juniper documentation does not expressly permit installation on non-Juniper equipment;
(j) use the Software (or make it available for use) on Juniper equipment that the Customer did not originally purchase from Juniper or an authorized Juniper
reseller; or (k) use the Software in any manner other than as expressly provided herein.
5. Audit. Customer shall maintain accurate records as necessary to verify compliance with this Agreement. Upon request by Juniper, Customer shall furnish
such records to Juniper and certify its compliance with this Agreement.
6. Confidentiality. The Parties agree that aspects of the Software and associated documentation are the confidential property of Juniper. As such, Customer
shall exercise all reasonable commercial efforts to maintain the Software and associated documentation in confidence, which at a minimum includes
restricting access to the Software to Customer employees and contractors having a need to use the Software for Customer’s internal business purposes.
7. Ownership. Juniper and Juniper’s licensors, respectively, retain ownership of all right, title, and interest (including copyright) in and to the Software,
associated documentation, and all copies of the Software. Nothing in this Agreement constitutes a transfer or conveyance of any right, title, or interest in the
Software or associated documentation, or a sale of the Software, associated documentation, or copies of the Software.
8. Warranty, Limitation of Liability, Disclaimer of Warranty. The warranty applicable to the Software shall be as set forth in the warranty statement that
accompanies the Software (the “Warranty Statement”). Nothing in this Agreement shall give rise to any obligation to support the Software. Support services
may be purchased separately. Any such support shall be governed by a separate, written support services agreement. TO THE MAXIMUM EXTENT
PERMITTED BY LAW, JUNIPER SHALL NOT BE LIABLE FOR ANY LOST PROFITS, LOSS OF DATA, OR COSTS OR PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES, OR FOR ANY SPECIAL, INDIRECT, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, THE SOFTWARE, OR ANY JUNIPER
OR JUNIPER-SUPPLIED SOFTWARE. IN NO EVENT SHALL JUNIPER BE LIABLE FOR DAMAGES ARISING FROM UNAUTHORIZED OR IMPROPER USE OF
ANY JUNIPER OR JUNIPER-SUPPLIED SOFTWARE. EXCEPT AS EXPRESSLY PROVIDED IN THE WARRANTY STATEMENT TO THE EXTENT PERMITTED BY
LAW, JUNIPER DISCLAIMS ANY AND ALL WARRANTIES IN AND TO THE SOFTWARE (WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE),
INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT DOES
JUNIPER WARRANT THAT THE SOFTWARE, OR ANY EQUIPMENT OR NETWORK RUNNING THE SOFTWARE, WILL OPERATE WITHOUT ERROR OR
INTERRUPTION, OR WILL BE FREE OF VULNERABILITY TO INTRUSION OR ATTACK. In no event shall Juniper’s or its suppliers’ or licensors’ liability to
Customer, whether in contract, tort (including negligence), breach of warranty, or otherwise, exceed the price paid by Customer for the Software that gave
rise to the claim, or if the Software is embedded in another Juniper product, the price paid by Customer for such other product. Customer acknowledges and
agrees that Juniper has set its prices and entered into this Agreement in reliance upon the disclaimers of warranty and the limitations of liability set forth
herein, that the same reflect an allocation of risk between the Parties (including the risk that a contract remedy may fail of its essential purpose and cause
consequential loss), and that the same form an essential basis of the bargain between the Parties.
9. Termination. Any breach of this Agreement or failure by Customer to pay any applicable fees due shall result in automatic termination of the license
granted herein. Upon such termination, Customer shall destroy or return to Juniper all copies of the Software and related documentation in Customer’s
possession or control.
10. Taxes. All license fees for the Software are exclusive of taxes, withholdings, duties, or levies (collectively “Taxes”). Customer shall be responsible for
paying Taxes arising from the purchase of the license, or importation or use of the Software.
11. Export. Customer agrees to comply with all applicable export laws and restrictions and regulations of any United States and any applicable foreign
agency or authority, and not to export or re-export the Software or any direct product thereof in violation of any such restrictions, laws or regulations, or
without all necessary approvals. Customer shall be liable for any such violations. The version of the Software supplied to Customer may contain encryption
or other capabilities restricting Customer’s ability to export the Software without an export license.
12. Commercial Computer Software. The Software is “commercial computer software” and is provided with restricted rights. Use, duplication, or
disclosure by the United States government is subject to restrictions set forth in this Agreement and as provided in DFARS 227.7201 through 227.7202-4,
FAR 12.212, FAR 27.405(b)(2), FAR 52.227-19, or FAR 52.227-14(ALT III) as applicable.
13. Interface Information. To the extent required by applicable law, and at Customer's written request, Juniper shall provide Customer with the interface
information needed to achieve interoperability between the Software and another independently created program, on payment of applicable fee, if any.
Customer shall observe strict obligations of confidentiality with respect to such information and shall use such information in compliance with any
applicable terms and conditions upon which Juniper makes such information available.
14. Third Party Software. Any licensor of Juniper whose software is embedded in the Software and any supplier of Juniper whose products or technology
are embedded in (or services are accessed by) the Software shall be a third party beneficiary with respect to this Agreement, and such licensor or vendor
shall have the right to enforce this Agreement in its own name as if it were Juniper. In addition, certain third party software may be provided with the
Software and is subject to the accompanying license(s), if any, of its respective owner(s). To the extent portions of the Software are distributed under and
subject to open source licenses obligating Juniper to make the source code for such portions publicly available (such as the GNU General Public License
(“GPL”) or the GNU Library General Public License (“LGPL”)), Juniper will make such source code portions (including Juniper modifications, as appropriate)
available upon request for a period of up to three years from the date of distribution. Such request can be made in writing to Juniper Networks, Inc., 1194 N.
Mathilda Ave., Sunnyvale, CA 94089, ATTN: General Counsel. You may obtain a copy of the GPL at http://www.gnu.org/licenses/gpl.html, and a copy of the
LGPL at http://www.gnu.org/licenses/lgpl.html.
15. Miscellaneous. This Agreement shall be governed by the laws of the State of California without reference to its conflicts of laws principles. The
provisions of the U.N. Convention for the International Sale of Goods shall not apply to this Agreement. For any disputes arising under this Agreement, the
Parties hereby consent to the personal and exclusive jurisdiction of, and venue in, the state and federal courts within Santa Clara County, California. This
Agreement constitutes the entire and sole agreement between Juniper and the Customer with respect to the Software, and supersedes all prior and
contemporaneous agreements relating to the Software, whether oral or written (including any inconsistent terms contained in a purchase order), except that
the terms of a separate written agreement executed by an authorized Juniper representative and Customer shall govern to the extent such terms are
inconsistent or conflict with terms contained herein. No modification to this Agreement nor any waiver of any rights hereunder shall be effective unless
expressly assented to in writing by the party to be charged. If any portion of this Agreement is held invalid, the Parties agree that such invalidity shall not
affect the validity of the remainder of this Agreement. This Agreement and associated documentation has been written in the English language, and the
Parties agree that the English version will govern. (For Canada: Les parties aux présentés confirment leur volonté que cette convention de même que tous
les documents y compris tout avis qui s'y rattaché, soient redigés en langue anglaise. (Translation: The parties confirm that this Agreement and all related
documentation is and will be in the English language)).
Table of Contents
About This Guide
xxiii
Audience..................................................................................................... xxiii
Where to find additional information.......................................................... xxiii
Administrator and developer documentation ....................................... xxiii
Error Message Documentation ............................................................. xxiv
Hardware documentation ..................................................................... xxiv
Product downloads............................................................................... xxiv
Conventions................................................................................................ xxiv
Documentation ............................................................................................ xxv
Release Notes ........................................................................................ xxv
Web Access ........................................................................................... xxv
Contacting Customer Support ...................................................................... xxv
Part 1
Getting Started
Chapter 1
Initial Verification and Key Concepts
3
Verifying User Accessibility .............................................................................. 3
Creating a Test Scenario to Learn IVE Concepts and Best Practices.................. 5
Defining a User Role.................................................................................. 6
Defining a Resource Profile ....................................................................... 8
Defining an Authentication Server ........................................................... 10
Defining an Authentication Realm ........................................................... 13
Defining a Sign-In Policy.......................................................................... 16
Using the Test Scenario ........................................................................... 19
Configuring Default Settings for Administrators ............................................. 22
Chapter 2
Introduction to the IVE
25
What Is the IVE?............................................................................................. 25
What Can I Do with the IVE?.......................................................................... 27
Can I Use the IVE to Secure Traffic to All of My Company’s Applications,
Servers, and Web Pages? .................................................................. 27
Can I Use My Existing Servers to Authenticate IVE Users? .......................29
Can I Fine-Tune Access to the IVE and the Resources It Intermediates?... 29
Can I Create a Seamless Integration Between the IVE and the
Resources It Intermediates? .............................................................. 30
Can I Use the IVE to Protect Against Infected Computers and
Other Security Concerns?.................................................................. 31
Can I Ensure Redundancy in my IVE Environment? ................................ 31
Can I Make the IVE Interface Match My Company’s Look-and-Feel? ........ 31
Table of Contents

v
Juniper Networks Secure Access Administration Guide
Can I Enable Users on a Variety of Computers and Devices to
Use the IVE?...................................................................................... 32
Can I Provide Secure Access for My International Users?......................... 32
How Do I Start Configuring the IVE? .............................................................. 32
Using Network and Security Manager with the IVE ........................................ 33
How the IVE and NSM communicate ....................................................... 34
Task Summary: Configuring DMI Communication for NSM ..................... 35
Managing Large Binary Data Files............................................................ 37
Part 2
Access Management Framework
Chapter 3
General Access Management
49
Licensing: Access Management Availability....................................................50
Policies, Rules & Restrictions, and Conditions Overview................................ 50
Accessing Authentication Realms ............................................................ 50
Accessing User Roles ............................................................................... 51
Accessing Resource Policies..................................................................... 51
Policies, Rules & Restrictions, and Conditions Evaluation .............................. 53
Dynamic Policy Evaluation............................................................................. 55
Understanding Dynamic Policy Evaluation .............................................. 55
Understanding Standard Policy Evaluation .............................................. 56
Enabling Dynamic Policy Evaluation ....................................................... 56
Configuring Security Requirements................................................................ 57
Specifying Source IP Access Restrictions ................................................. 58
Specifying Browser Access Restrictions ................................................... 59
Specifying Certificate Access Restrictions ................................................ 62
Specifying Password Access Restrictions ................................................. 63
Specifying Host Checker Access Restrictions ........................................... 64
Specifying Cache Cleaner Access Restrictions.......................................... 64
Specifying Limits Restrictions .................................................................. 64
Federation of User Sessions with IF-MAP ....................................................... 66
IF-MAP Federation Licensing ................................................................... 66
IF-MAP Federation Overview ................................................................... 66
IF-MAP Federation Workflow................................................................... 69
IF-MAP Federation Details ....................................................................... 69
IF-MAP Logging ....................................................................................... 72
Configuring IF-MAP Federation................................................................ 72
IF-MAP Servers ........................................................................................ 72
Configuring IF-MAP Client Settings .......................................................... 73
IF--MAP Federation Network Timing Considerations ............................... 73
Session-Export and Session-Import Policies............................................. 74
Default Session-Export and Session-Import Policy Action ........................ 76
Advanced Session-Export and Session-Import Policies ............................ 76
Configuring Session-Export Policies ......................................................... 76
Session-Import Policies............................................................................ 78
Troubleshooting the IF-MAP Federation Network .................................... 79
Viewing Active Users on the IF-MAP Client .............................................. 79
Trusted Server List................................................................................... 79
vi

Table of Contents
Table of Contents
Chapter 4
User Roles
83
Licensing: User Roles Availability ................................................................... 84
User Role Evaluation ...................................................................................... 84
Permissive Merge Guidelines ................................................................... 85
Configuring User Roles................................................................................... 86
Configuring General Role Options............................................................ 87
Configuring Role Restrictions................................................................... 88
Specifying Role-Based Source IP Aliases .................................................. 89
Specifying Session Options...................................................................... 89
Specifying UI Options .............................................................................. 92
Defining Default Options for User Roles .................................................. 97
Customizing UI Views for User Roles ............................................................. 99
Chapter 5
Resource Profiles
103
Licensing: Resource Profile Availability ........................................................104
Task Summary: Configuring Resource Profiles .............................................104
Resource Profile Components ......................................................................104
Defining Resources................................................................................107
Defining Autopolicies.............................................................................108
Defining Roles .......................................................................................109
Defining Bookmarks ..............................................................................110
Resource Profile Templates..........................................................................111
Chapter 6
Virtual Desktop Resource Profiles
113
Configuring a Citrix XenDesktop Resource Profile........................................113
Configuring a VMware View Manager Resource Profile ................................114
Defining Bookmarks for a Virtual Desktop Profile ........................................116
Configuring the Client Delivery ....................................................................117
Connecting to the Servers ............................................................................117
Chapter 7
Resource Policies
119
Licensing: Resource Policies Availability ......................................................120
Resource Policy Components.......................................................................120
Specifying Resources for a Resource Policy ...........................................121
Resource Policy Evaluation ..........................................................................124
Creating Detailed Rules for Resource Policies...............................................125
Writing a Detailed Rule..........................................................................126
Customizing Resource Policy UI Views.........................................................128
Chapter 8
Authentication and Directory Servers
131
Licensing: Authentication Server Availability................................................132
Task Summary: Configuring Authentication Servers ....................................132
Defining an Authentication Server Instance .................................................133
Defining an Authentication Server Instance...........................................134
Modifying an Existing Authentication Server Instance ...........................134
Configuring an Anonymous Server Instance ................................................134
Anonymous Server Restrictions.............................................................135
Defining an Anonymous Server Instance...............................................135
Configuring an ACE/Server Instance.............................................................136
Defining an ACE/Server Instance ...........................................................137
Generating an ACE/Agent Configuration File..........................................138
Table of Contents 
vii
Juniper Networks Secure Access Administration Guide
Configuring an Active Directory or NT Domain Instance..............................139
Defining an Active Directory or Windows NT Domain Server Instance..140
Multi-Domain User Authentication.........................................................143
Active Directory and NT Group Lookup Support ....................................144
Configuring a Certificate Server Instance.......................................................... 145
Configuring an LDAP Server Instance...........................................................147
Defining an LDAP Server Instance .........................................................147
Configuring LDAP Search Attributes for Meeting Creators .....................150
Monitoring and Deleting Active User Sessions .......................................150
Enabling LDAP Password Management .................................................151
Configuring a Local Authentication Server Instance .....................................155
Defining a Local Authentication Server Instance....................................155
Creating User Accounts on a Local Authentication Server ......................157
Managing User Accounts .......................................................................158
Configuring an NIS Server Instance..............................................................159
Configuring a RADIUS Server Instance .........................................................160
User Experience for RADIUS Users ........................................................161
Configuring the IVE to Work with a Back-end RADIUS Server................162
Enabling RADIUS Accounting ................................................................165
Configuring an eTrust SiteMinder Server Instance........................................174
eTrust SiteMinder Overview ..................................................................174
Configuring SiteMinder to Work with the IVE ........................................179
Configuring the IVE to Work with SiteMinder ........................................185
Debugging SiteMinder and IVE Issues....................................................198
Configuring a SAML Server Instance ............................................................198
Using the Artifact Profile and the POST Profile ......................................199
Creating a new SAML Server Instance ...................................................203
Chapter 9
Authentication Realms
207
Licensing: Authentication Realms Availability ..............................................208
Creating an Authentication Realm................................................................208
Defining Authentication Policies ..................................................................210
Creating Role Mapping Rules .......................................................................211
Specifying Role Mapping Rules for an Authentication Realm .................212
Customizing User Realm UI Views ...............................................................220
Chapter 10
Sign-In Policies
223
Licensing: Sign-In Policies and Pages Availability .........................................225
Task summary: Configuring Sign-In Policies.................................................225
Configuring Sign-In Policies..........................................................................225
Defining Sign-in Policies ........................................................................226
Defining authorization-only access policies............................................227
Defining Meeting Sign-In Policies...........................................................229
Enabling and Disabling Sign-In Policies .................................................230
Specifying the Order in Which Sign-In Policies are Evaluated ................230
Configuring Sign-In pages ............................................................................231
Configuring Standard Sign-In Pages .......................................................232
Chapter 11
Single Sign-On
235
Licensing: Single Sign-On Availability...........................................................235
Single Sign-On Overview..............................................................................235
Multiple Sign-In Credentials Overview..........................................................237
Task Summary: Configuring Multiple Authentication Servers.................237
viii

Table of Contents
Table of Contents
Task Summary: Enabling SSO to Resources Protected by Basic
Authentication ................................................................................238
Task Summary: Enabling SSO to Resources Protected by NTLM............238
Multiple Sign-In Credentials Execution...................................................240
Configuring SAML ........................................................................................245
Configuring SAML SSO Profiles ....................................................................248
Creating an artifact profile .....................................................................248
Creating a POST Profile .........................................................................252
Creating an Access Control Policy..........................................................255
Creating a Trust Relationship Between SAML-Enabled Systems .............258
Chapter 12
Synchronizing User Records
265
Enabling User Record Synchronization ........................................................267
Configuring the Authentication Server .........................................................267
Configuring the User Record Synchronization Server ...................................268
Configuring the Client ..................................................................................268
Configuring the Database.............................................................................269
Part 3
Endpoint Defense
Chapter 13
Host Checker
273
The TNC Architecture Within Host Checker..................................................273
Host Checker Overview................................................................................274
Task Summary: Configuring Host Checker ...................................................274
Creating Global Host Checker Policies ..........................................................276
Enabling Enhanced Endpoint Security Functionality..............................277
Enabling Connection Control Policies (Windows Only) ..........................280
Creating and Configuring New Client-side Policies .......................................280
Checking for Third-Party Applications Using Pre-defined
Rules (Windows Only) ...........................................................................281
Configuring a Predefined Antivirus Rule with Remediation Options ......283
Configuring a Predefined Firewall Rule with Remediation Options ........285
Configuring a Pre-defined Anti-Spyware Rule ........................................286
Configuring Virus Signature Version Monitoring and
Patch Assessment Data Monitoring .................................................288
Specifying Customized Requirements Using Custom Rules ..........................290
Using a Wildcard or Environment Variable in a Host Checker Rule .......297
Evaluating Multiple Rules in a Single Host Checker Policy .....................298
Configuring Patch Assessment Policies ..................................................299
Using third-party integrity Measurement Verifiers........................................303
Configuring a Remote IMV Server..........................................................303
Implementing the Third-Party IMV Policy ..............................................308
Combining Multiple Integrity Measurement Rules with
Custom Expressions ..............................................................................309
Enabling Customized Server-side Policies ..............................................310
Implementing Host Checker Policies............................................................311
Executing Host Checker Policies ............................................................312
Configuring Host Checker Restrictions...................................................314
Remediating Host Checker Policies ..............................................................316
Host Checker Remediation User Experience..........................................317
Table of Contents

ix
Juniper Networks Secure Access Administration Guide
Configuring General Host Checker Remediation ....................................318
Defining Host Checker Pre-Authentication Access Tunnels ..........................321
Specifying Host Checker Pre-Authentication Access Tunnel Definitions.322
Specifying General Host Checker Options ....................................................325
Specifying Host Checker Installation Options ...............................................327
Removing the Juniper ActiveX Control...................................................328
Using Host Checker with the GINA Automatic Sign-In Function .............328
Automatically install Host Checker ........................................................329
Manually install Host Checker................................................................330
Using Host Checker Logs..............................................................................330
Configuring Host Checker for Windows Mobile ............................................331
Using Proxy Exceptions ...............................................................................331
Enabling the Secure Virtual Workspace........................................................332
Secure Virtual Workspace Features........................................................333
Secure Virtual Workspace Restrictions and Defaults ..............................333
Configuring the Secure Virtual Workspace.............................................334
Chapter 14
Cache Cleaner
341
Licensing: Cache Cleaner Availability ...........................................................341
Setting Global Cache Cleaner Options ..........................................................342
Implementing Cache Cleaner Options..........................................................345
Executing Cache Cleaner .......................................................................345
Specifying Cache Cleaner Restrictions ...................................................347
Specifying Cache Cleaner Installation Options .............................................349
Using Cache Cleaner Logs ............................................................................350
Part 4
Remote Access
Choosing a Remote Access Mechanism........................................................351
Chapter 15
Hosted Java Applets Templates
353
Licensing: Hosted Java Applets Availability ..................................................353
Task Summary: Hosting Java Applets ...........................................................353
Hosted Java Applets Overview .....................................................................354
Uploading Java Applets To The IVE ........................................................355
Signing Uploaded Java Applets ..............................................................356
Creating HTML Pages That Reference Uploaded Java Applets ................356
Accessing Java Applet Bookmarks .........................................................357
Defining Resource Profiles: Hosted Java Applets ..........................................358
Defining Hosted Java Applet Bookmarks ...............................................359
Use case: Creating a Citrix JICA 9.5 Java Applet Bookmark ..........................364
JICA 9.5 Applet Example .......................................................................365
JICA 8.x Applet Example........................................................................366
Chapter 16
Citrix Templates
369
Citrix Web Template Overview ....................................................................369
Comparing IVE Access Mechanisms for Configuring Citrix...........................370
Creating Resource Profiles Using Citrix Web Applications............................372
x

Table of Contents
Table of Contents
Chapter 17
Lotus iNotes Templates
379
Chapter 18
Microsoft OWA Templates
383
Chapter 19
Microsoft Sharepoint Templates
387
Chapter 20
Web Rewriting
389
Licensing: Web Rewriting Availability ..........................................................390
Task summary: Configuring the Web Rewriting Feature ..............................390
Web URL Rewriting Overview......................................................................392
Remote SSO Overview ..........................................................................393
Passthrough Proxy Overview.................................................................394
Defining Resource Profiles: Custom Web Applications .................................397
Defining Base URLs ...............................................................................398
Defining Web Resources........................................................................399
Defining a Web Access Control Autopolicy ............................................400
Defining a Single Sign-On Autopolicy ....................................................401
Defining a Caching Autopolicy...............................................................404
Defining a Java Access Control Autopolicy.............................................407
Defining a Rewriting Autopolicy ............................................................409
Defining a Web Compression Autopolicy...............................................413
Defining a Web Bookmark ....................................................................414
Defining Role Settings: Web URLs................................................................416
Creating Bookmarks Through Existing Resource Profiles .......................417
Creating Standard Web Bookmarks .......................................................418
Specifying General Web Browsing Options ............................................419
Defining Resource Policies: Overview ..........................................................423
Defining Resource Policies: Web Access ......................................................425
Defining Resource Policies: Single Sign-On ..................................................426
Defining the Basic, NTLM and Kerberos Resources................................426
Writing a Basic Authentication, NTLM or Kerberos Intermediation
Resource Policy...............................................................................431
Writing a Remote SSO Form POST Resource Policy ..............................434
Writing a Remote SSO Headers/Cookies Resource Policy ......................436
Defining Resource Policies: Caching.............................................................438
Writing a Caching Resource Policy ........................................................438
Creating OWA and Lotus Notes Caching Resource Policies ....................441
Specifying General Caching Options ......................................................441
Defining Resource Policies: External Java Applets ........................................442
Writing a Java Access Control Resource Policy ......................................442
Writing a Java Code Signing Resource Policy .........................................444
Defining Resource Policies: Rewriting ..........................................................445
Creating a Selective Rewriting Resource Policy......................................445
Creating a Passthrough Proxy Resource Policy ......................................448
Creating a Custom Header Resource Policy ...........................................450
Creating an ActiveX Parameter Resource Policy ....................................452
Restoring the Default IVE ActiveX Resource Policies..............................454
Creating Rewriting Filters ......................................................................455
Defining Resource Policies: Web Compression ............................................455
Writing a Web Compression Resource Policy ........................................456
Defining an OWA Compression Resource Policy ...................................457
Defining Resource Policies: Web Proxy........................................................457
Writing a Web Proxy Resource Policy ...................................................457
Table of Contents

xi
Juniper Networks Secure Access Administration Guide
Specifying Web Proxy Servers ...............................................................459
Defining Resource Policies: HTTP 1.1 Protocol.............................................460
Defining Resource Policies: Cross-Domain Access (XMLHttpRequest Calls)..461
Defining Resource Policies: General Options................................................463
Managing Resource Policies: Customizing UI Views .....................................463
Chapter 21
File Rewriting
465
Licensing: File Rewriting Availability ............................................................465
Defining Resource Profiles: File Rewriting....................................................465
Defining File Resources .........................................................................467
Defining a File Access Control Autopolicy..............................................468
Defining a File Compression Autopolicy ................................................468
Defining a Single Sign-On Autopolicy (Windows Only) ..........................469
Defining a File Bookmark ......................................................................470
Defining Role Settings: Windows Resources ................................................472
Creating Advanced Bookmarks to Windows Resources .........................473
Creating Windows Bookmarks that Map to LDAP Servers......................474
Defining General File Browsing Options ................................................475
Defining Resource Policies: Windows File Resources ...................................475
Canonical Format: Windows File Resources ..........................................476
Writing a Windows Access Resource Policy...........................................477
Writing a Windows SSO Resource Policy...............................................478
Writing a Windows Compression Resource Policy.................................480
Defining General File Writing Options ...................................................481
Defining Role Settings: UNIX/NFS File Resources .........................................482
Creating Advanced Bookmarks to UNIX Resources................................482
Defining General File Browsing Options ................................................483
Defining Resource Policies: UNIX/NFS File Resources ..................................484
Canonical Format: UNIX/NFS File Resources .........................................485
Writing UNIX/NFS Resource Policies......................................................485
Writing a Unix/NFS Compression Resource Policy.................................486
Defining General File Writing Options ...................................................488
Chapter 22
Secure Application Manager
489
Licensing: Secure Application Manager Availability ......................................490
Task Summary: Configuring WSAM .............................................................490
WSAM Overview ..........................................................................................491
Securing Client/server Traffic Using Wsam ............................................491
Launching Network Connect During a WSAM Session ...........................494
Debugging WSAM Issues .......................................................................494
Defining Resource Profiles: WSAM...............................................................495
Creating WSAM Client Application Resource Profiles.............................495
Creating WSAM Destination Network Resource Profiles ........................497
Defining Role Settings: WSAM .....................................................................498
Specifying Applications and Servers for WSAM to Secure ......................498
Specifying Applications that Need to Bypass WSAM ..............................501
Specifying Role-Level WSAM Options ....................................................502
Downloading WSAM Applications..........................................................504
Defining Resource Policies: WSAM...............................................................504
Specifying Application Servers that Users can Access ............................504
Specifying Resource Level WSAM Options.............................................506
Using the WSAM Launcher...........................................................................507
Running Scripts Manually ......................................................................508
xii

Table of Contents
Table of Contents
Running Scripts Automatically...............................................................509
Task Summary: Configuring JSAM................................................................510
JSAM Overview ............................................................................................512
Using JSAM for Client/Server Communications ......................................512
Linux and Macintosh Support ................................................................520
Standard Application Support: MS Outlook ............................................521
Standard Application Support: Lotus Notes............................................523
Standard Application Support: Citrix Web Interface for
MetaFrame (NFuse Classic) .............................................................524
Custom Application Support: Citrix Published Applications
Configured From the Native Client ..................................................525
Custom Application Support: Citrix Secure Gateways ............................528
Defining Resource Profiles: JSAM .................................................................529
Defining Role Settings: JSAM........................................................................534
Specifying Applications for JSAM to Secure............................................534
Specifying Role Level JSAM Options ......................................................537
Defining Resource Policies: JSAM .................................................................538
Automatically Launching JSAM ..............................................................538
Specifying Application Servers that Users Can Access ...........................540
Specifying Resource Level JSAM Options ...............................................542
Chapter 23
Telnet/SSH
543
Licensing: Telnet/SSH Availability.................................................................544
Task summary: Configuring the Telnet/SSH Feature ....................................544
Defining Resource Profiles: Telnet/SSH ........................................................544
Defining a Telnet/SSH resource profile bookmark..................................546
Defining Role Settings: Telnet/SSH ...............................................................548
Creating advanced session bookmarks ..................................................548
Configuring General Telnet/SSH Options................................................549
Defining Resource Policies: Telnet/SSH ........................................................550
Writing Telnet/SSH Resource Policies ....................................................551
Matching IP Addresses to Host Names...................................................552
Chapter 24
Terminal Services
555
Licensing: Terminal Services Availability......................................................555
Task Summary: Configuring the Terminal Services Feature .........................555
Terminal Services Overview.........................................................................557
Terminal Services User Experience........................................................557
Terminal Services Execution..................................................................558
Configuring Citrix to Support ICA Load Balancing..................................559
Defining Resource Profiles: Terminal Services Overview..............................561
Defining Resource Profiles: Windows Terminal Services..............................562
Defining a Hosted Java Applet Autopolicy..............................................564
Defining a Bookmark for a Windows Terminal Services Profile .............566
Defining Resource Profiles: Citrix Terminal Services (Default ICA) ...............572
Defining a Bookmark for a Citrix Profile Using Default ICA Settings ......573
Defining Resource Profiles: Citrix Terminal Services (Custom ICA) ..............579
Defining a Bookmark for a Citrix Profile Using a Custom ICA File .........580
Defining Resource Profiles: Citrix Listed Applications ..................................581
Defining a Bookmark for a Citrix Profile Listing Applications.................583
Defining Role Settings: Terminal Services ....................................................585
Creating Advanced Terminal Services Session Bookmarks ....................586
Table of Contents

xiii
Juniper Networks Secure Access Administration Guide
Creating Links from an External Site to a Terminal Services
Session Bookmark...........................................................................593
Specifying General Terminal Services Options.......................................597
Defining Resource Policies: Terminal Services .............................................600
Configuring Terminal Services Resource Policies ...................................600
Specifying the Terminal Services Resource Option ................................602
Using the Remote Desktop Launcher ...........................................................602
Chapter 25
Secure Meeting
605
Licensing: Secure Meeting Availability..........................................................605
Task Summary: Configuring Secure Meeting ................................................606
Secure Meeting Overview.............................................................................607
Scheduling Meetings..............................................................................608
Sending Notification Emails...................................................................610
Joining Meetings ....................................................................................611
Attending Meetings................................................................................613
Conducting Meetings .............................................................................613
Presenting Meetings ..............................................................................614
Creating instant Meetings and Support Meetings ...................................615
Creating MySecureMeeting Meetings .....................................................616
Defining Role Settings: Secure Meeting ........................................................617
Enabling and Configuring Secure Meeting .............................................617
Permissive Merge Guidelines for Secure Meeting...................................621
Specifying Authentication Servers that Meeting Creators can Access .....622
Configuring System-Level Meeting Settings ..................................................623
Troubleshooting Secure Meeting ..................................................................626
Known Issues ........................................................................................627
Monitoring Secure Meeting ..........................................................................628
Chapter 26
Email Client
629
Licensing: Email Client Availability...............................................................630
Email Client Overview..................................................................................630
Choosing an Email Client.......................................................................630
Working with a Standards-Based Mail Server.........................................631
Working with the Microsoft Exchange Server ........................................631
Working with Lotus Notes and the Lotus Notes Mail Server ...................633
Defining Role Settings: Email Client .............................................................633
Defining Resource Policies: Email Client ......................................................634
Chapter 27
Network Connect
637
Task Summary: Configuring Network Connect.............................................640
Network Connect Overview .........................................................................641
Network Connect Execution ..................................................................642
Network Connect Connection Profiles with Support for Multiple DNS
Settings ...........................................................................................650
Network Connect Incompatibility with Other VPN Client Applications...650
Client-Side Logging ................................................................................651
Network Connect Proxy Support ...........................................................652
Network Connect Quality of Service ......................................................653
Network Connect Multicast Support.......................................................653
Defining Role Settings: Network Connect.....................................................654
Defining Resource Policies: Network Connect ..............................................657
Defining Network Connect Access Control Policies................................657
xiv

Table of Contents
Table of Contents
Creating Network Connect Connection Profiles .....................................659
Defining Network Connect Split Tunneling Policies ...............................666
Use Case: Network Connect Resource Policy Configuration...................667
Defining Network Connect Bandwidth Management Policies ................669
Defining System Settings: Network Connect ................................................673
Specifying IP Filters ...............................................................................673
Downloading the Network Connect installer..........................................674
Network Connect Installation Process Dependencies.............................674
Network Connect Un-installation Process Dependencies .......................676
Using the Network Connect Launcher (NC Launcher) ...................................678
Launching Network Connect On Other Platforms ..................................680
Troubleshooting Network Connect errors.....................................................681
nc.windows.app.23792 .........................................................................681
Version Conflict on Downgrade .............................................................681
Error When Connecting to a FIPS Appliance..........................................682
Part 5
System Management
Chapter 28
General System Management
685
Licensing: System Management Availability.................................................685
Task Summary: Configuring Management Capabilities ................................686
Configuring Network Settings.......................................................................686
Bonding Ports........................................................................................687
Configuring General Network Settings ...................................................687
Configuring Internal and External Ports.................................................689
Configuring SFP Ports............................................................................692
Configuring the Management Port .........................................................692
Configuring VLANs ................................................................................693
Configuring Virtual Ports .......................................................................695
Task Summary: Defining Subnet Destinations Based on Roles ..............697
Configuring Static Routes for Network Traffic ........................................697
Creating ARP Caches .............................................................................698
Specifying Host Names for the IVE to Resolve Locally ...........................699
Specifying IP Filters ...............................................................................699
Using Central Management Features............................................................700
Modifying Central Management Dashboard Graphs...............................700
Configuring System Utilities .........................................................................702
Reviewing System Data .........................................................................702
Upgrading or Downgrading the IVE ......................................................704
Setting System Options .........................................................................704
Downloading Application Installers........................................................706
Configuring Licensing, Security, and NCP ....................................................709
Entering or Upgrading IVE Licenses.......................................................709
Activating and Deactivating Emergency Mode.......................................715
Setting Security Options ........................................................................716
Configuring NCP and JCP.......................................................................719
Installing a Juniper Software Service Package ........................................720
Configuring and Using the Management Port...............................................721
Configuring Management Port Network Settings ...................................722
Adding Static Routes to the Management Route Table...........................723
Assigning Certificate to Management Port .............................................723
Table of Contents 
xv
Juniper Networks Secure Access Administration Guide
Controlling Administrator Sign-In Access...............................................724
Signing in Over the Management Port ...................................................725
Setting Role-Mapping Rules Using Custom Expressions .........................725
Troubleshooting the Management Port..................................................726
Using the Management Port on a Cluster...............................................727
Importing Configurations to a System with the
Management Port Enabled ..............................................................727
Chapter 29
Certificates
729
Licensing: Certificate Availability..................................................................730
Using Device Certificates..............................................................................730
Importing Certificates Into the IVE ........................................................731
Downloading a Device Certificate From the IVE ....................................733
Creating a Certificate Signing Request (CSR) for a New Certificate.........734
Using Intermediate Server Ca Certificates..............................................735
Using Multiple IVE Device Certificates ...................................................736
Using Trusted Client CAs..............................................................................738
Enabling Trusted Client CAs ..................................................................739
Enabling Client CA Hierarchies ..............................................................747
Enabling CRLs .......................................................................................748
Enabling OCSP ......................................................................................751
Using Trusted Server CAs .............................................................................753
Uploading Trusted Server CA Certificates ..............................................754
Renewing a Trusted Server CA Certificate..............................................754
Deleting a trusted server CA Certificate .................................................755
Viewing Trusted Server CA Certificate Details........................................755
Using Code-signing Certificates ....................................................................755
Additional Considerations for SUN JVM Users........................................757
Task Summary: Configuring the IVE to Sign or Re-Sign java Applets .....757
Importing a Code-Signing Certificate .....................................................757
Chapter 30
System Archiving
759
Licensing: System Archiving Availability ......................................................759
Archiving IVE Binary Configuration Files......................................................760
Creating Local Backups of IVE Configuration Files........................................762
Importing and Exporting IVE Configuration Files .........................................765
Exporting a System Configuration File...................................................765
Importing a System Configuration File ..................................................766
Exporting Local User Accounts or Resource Policies ..............................767
Importing Local User Accounts or Resource Policies..............................768
Exporting IVS Configuration Settings .....................................................768
Importing IVS Configuration Settings.....................................................769
Importing and Exporting XML Configuration Files .......................................769
Creating and Modifying XML Instances..................................................771
Referential Integrity Constraints ............................................................774
Mapping the XML Instance to UI Components.......................................776
Downloading the Schema File ...............................................................777
Strategies for Working With XML Instances...........................................777
System Restarts.....................................................................................785
XML Import/Export Use Cases ...............................................................786
Importing to a System with the Management Port ................................790
Using Operation Attributes ....................................................................790
Pushing Configurations from one IVE to Another .........................................793
xvi

Table of Contents
Table of Contents
Defining the Target IVEs ........................................................................794
Pushing the Configuration Settings ........................................................795
Archiving Secure Meetings ...........................................................................797
Chapter 31
Logging and Monitoring
799
Licensing: Logging and Monitoring Availability ............................................799
Logging and Monitoring Overview ...............................................................800
Log File Severity Levels..........................................................................801
Custom Filter Log Files ..........................................................................801
Dynamic Log Filters...............................................................................802
Viewing and Deleting User Sessions ......................................................802
Configuring the Log Monitoring Features .....................................................803
Configuring Events, User Access, Admin Access, and IDP Sensor ...............804
Creating, Resetting, or Saving a Dynamic Log Query.............................804
Specifying Which Events to Save in the Log File ....................................805
Creating, Editing, or Deleting Log Filters................................................806
Creating custom filters and Formats for Your Log Files .........................807
Monitoring the IVE as an SNMP Agent .........................................................808
Viewing System Statistics.............................................................................814
Enabling Client-Side Logs .............................................................................814
Enabling Client-Side Logging and Global Options...................................815
Enabling Client-Side Log Uploads...........................................................816
Viewing Uploaded Client-Side Logs ........................................................817
Viewing General Status ................................................................................818
Viewing System Capacity Utilization......................................................818
Specifying Time Range and Data to Display in Graphs ..........................819
Configuring Graph Appearance..............................................................819
Viewing Critical System Events..............................................................820
Downloading the Current Service Package ............................................820
Editing the System Date and Time ........................................................820
Monitoring Active Users ...............................................................................821
Viewing and Cancelling Scheduled Meetings ................................................822
Adding Real Source IP Addresses to Log Messages.......................................823
Chapter 32
Troubleshooting
825
Licensing: Troubleshooting Availability ........................................................825
Simulating or Tracking Events......................................................................826
Simulating Events That Cause a Problem...............................................826
Tracking Events Using Policy Tracing ....................................................828
Recording Sessions ......................................................................................830
Creating Snapshots of the IVE System State .................................................831
Creating TCP Dump Files .............................................................................832
Testing IVE Network Connectivity ................................................................834
Address Resolution Protocol (ARP) ........................................................834
Ping .......................................................................................................834
Traceroute .............................................................................................834
NSlookup ...............................................................................................835
Running Debugging Tools Remotely ............................................................835
Creating Debugging Logs .............................................................................836
Monitoring Nodes ........................................................................................837
Configuring Group Communication Monitoring on a Cluster ........................837
Configuring Network Connectivity Monitoring on a Cluster..........................838
Table of Contents

xvii
Juniper Networks Secure Access Administration Guide
Chapter 33
Clustering
841
Licensing: Clustering Availability ..................................................................842
Task Summary: Deploying a Cluster ............................................................842
Creating and Configuring a Cluster...............................................................843
Defining and Initializing a Cluster ..........................................................844
Joining an Existing Cluster .....................................................................846
Configuring Cluster Properties .....................................................................849
Deploying Two Nodes in an Active/Passive Cluster ................................849
Deploying Two or More Units in an Active/Active Cluster ......................850
Synchronizing the Cluster State .............................................................852
Configuring Cluster Properties ...............................................................855
Managing and Configuring Clusters..............................................................856
Adding Multiple Cluster Nodes...............................................................857
Managing Network Settings for Cluster Nodes .......................................857
Upgrading Clustered Nodes ...................................................................858
Changing the IP Address of a Cluster Node............................................858
Upgrading the Cluster Service Package ..................................................859
Deleting a Cluster ..................................................................................859
Restarting or Rebooting Clustered Nodes...............................................859
Admin Console Procedures....................................................................859
Monitoring Clusters ...............................................................................861
Troubleshooting Clusters .......................................................................862
Serial Console Procedures ............................................................................864
Joining an IVE to a Cluster Through Its Serial Console ...........................864
Disabling a Clustered IVE by Using Its Serial Console ............................867
Chapter 34
Delegating Administrator Roles
869
Licensing: Delegated Administration Role Availability..................................870
Creating and Configuring Administrator Roles .............................................870
Creating Administrator Roles.................................................................871
Modifying Administrator Roles ..............................................................871
Deleting Administrator Roles .................................................................872
Specifying Management Tasks to Delegate ..................................................872
Delegating System Management Tasks..................................................872
Delegating User and Role Management .................................................873
Delegating User Realm Management .....................................................874
Delegating Administrative Management ................................................875
Delegating Resource Policy Management ..............................................876
Delegating Resource Profile Management..............................................877
Defining General System Administrator Role Settings ..................................878
Defining Default Options for Administrator Roles..................................879
Managing General Role Settings and Options ........................................879
Specifying Access Management Options for the Role ............................879
Specifying General Session Options .......................................................880
Specifying UI Options ............................................................................881
Delegating Access to IVS Systems..........................................................882
Chapter 35
Instant Virtual System (IVS)
883
Licensing: IVS Availability ............................................................................884
Deploying an IVS .........................................................................................884
Virtualized IVE Architecture ...................................................................886
Signing In to the Root System or the IVS......................................................887
Signing-In Using the Sign-In URL Prefix .................................................888
xviii

Table of Contents
Table of Contents
Signing-In Over Virtual Ports .................................................................890
Signing-In Over a VLAN Interface ..........................................................891
Navigating to the IVS .............................................................................891
Determining the Subscriber Profile ..............................................................891
IVS Configuration Worksheet.................................................................891
Administering the Root System .............................................................894
Configuring the Root Administrator .......................................................894
Provisioning an IVS ......................................................................................895
Understanding the Provisioning Process ......................................................896
Configuring Sign-In Ports .............................................................................898
Configuring the External Port ................................................................898
Configuring a Virtual Port for Sign-In on the External Port.....................899
Configuring a Virtual Port for Sign-In on the Internal Port .....................899
Configuring a Virtual Local Area Network (VLAN).........................................900
Configuring VLANs on the Virtualized IVE..............................................901
Adding Static Routes to the VLAN Route Table ......................................902
Deleting a VLAN ....................................................................................903
Loading the Certificates Server.....................................................................904
Creating a Virtual System (IVS Profile) .........................................................904
Defining the IVS Profile .........................................................................904
IVS Initial Config Via Copy from the Root System or Another IVS..........907
Signing In Directly to the IVS as an IVS Administrator .................................908
Configuring Role-Based Source IP Aliasing ...................................................909
Associating Roles with VLANs and the Source IP Address......................909
Configuring Virtual Ports for a VLAN......................................................909
Associating Roles with Source IP Addresses in an IVS............................910
Configuring Policy Routing Rules on the IVS ................................................911
Routing Rules ........................................................................................912
Overlapping IP Address Spaces .............................................................912
Define Resource Policies........................................................................913
Clustering a Virtualized IVE ..........................................................................913
Configuring DNS for the IVS.........................................................................914
Accessing a DNS Server on the MSP Network ........................................914
Accessing a DNS Server on a Subscriber Company intranet ..................915
Configuring Network Connect for Use on a Virtualized IVE ..........................916
Configuring the Network Connect Connection Profile............................916
Configuring Network Connect on Backend Routers ...............................917
Configuring a Centralized DHCP Server .......................................................920
Configuring Authentication Servers ..............................................................921
Rules Governing Access to Authentication Servers.................................922
Configuring Authentication on a RADIUS Server....................................922
Configuring Authentication on Active Directory.....................................923
Delegating Administrative Access to IVS Systems ........................................923
Accessing Standalone Installers....................................................................924
Performing Export and Import of IVS Configuration Files ............................924
Exporting and importing the root System Configuration........................925
Monitoring Subscribers ................................................................................926
Suspending Subscriber Access to the IVS...............................................927
Troubleshooting VLANs................................................................................927
Performing TCPDump on a VLAN..........................................................927
Using Commands on a VLAN (Ping, traceroute, NSLookup, ARP) ..........928
IVS Use Cases...............................................................................................928
Policy Routing Rules Resolution Use Case for IVS ..................................929
Configuring a Global Authentication Server for Multiple Subscribers......934
Table of Contents

xix
Juniper Networks Secure Access Administration Guide
Configuring a DNS/WINS Server IP Address per Subscriber ...................934
Configuring Access to Web Applications and Web Browsing for
Each Subscriber ..............................................................................935
Configuring File Browsing Access for Each Subscriber ...........................936
Setting Up Multiple Subnet IP Addresses for a Subscriber’s End-Users...937
Configuring Multiple IVS Systems to Allow Access to Shared Server ......938
Chapter 36
IVE and IDP Interoperability
939
Licensing: IDP Availability............................................................................940
Deployment Scenarios .................................................................................941
Configuring the IVE to Interoperate with IDP ...............................................942
Configuring IDP Connections.................................................................942
Interaction Between the IVE and IDP.....................................................945
Defining Automatic Response Sensor Event Policies .............................945
Identifying and Managing Quarantined Users Manually.........................947
Part 6
System Services
Chapter 37
IVE Serial Console
951
Licensing: Serial Console Availability............................................................951
Connecting to an IVE Appliance’s Serial Console .........................................951
Rolling Back to a Previous System State.......................................................952
Rolling Back to a Previous System State Through the Admin Console....953
Rolling Back to a Previous System State Through the Serial Console .....953
Resetting an IVE Appliance to the Factory Setting........................................954
Performing Common Recovery Tasks ..........................................................957
Chapter 38
Customizable Admin and End-User UIs
959
Licensing: Customizable UI Availability ........................................................959
Customizable Admin Console Elements Overview .......................................959
Customizable End-User Interface Elements Overview ..................................961
Chapter 39
Secure Access 6000
963
Standard Hardware ......................................................................................963
Secure Access 6000 Field-Replaceable Units ................................................964
Chapter 40
Secure Access 4500 and 6500
967
Standard Hardware ......................................................................................967
SA 6500 Field-Replaceable Units ..................................................................969
Replacing the Cooling Fans ..........................................................................970
Removing and Installing a Cooling Fan..................................................970
Replacing a Hard Drive ................................................................................970
Removing and Installing a Hard Drive ...................................................971
Replacing IOC Modules ................................................................................971
Installing an IOM ...................................................................................972
Removing an IOM .................................................................................972
Replacing an AC Power Supply ....................................................................973
Removing and Installing an AC Power Supply .......................................973
Removing and Installing a DC Power Supply .........................................973
xx

Table of Contents
Table of Contents
Chapter 41
Secure Access FIPS
975
Licensing: Secure Access FIPS Availability....................................................975
Secure Access FIPS Execution ......................................................................976
Creating Administrator Cards.......................................................................977
Administrator Card Precautions.............................................................978
Deploying a Cluster in a Secure Access FIPS Environment ...........................978
Creating a New Security World ....................................................................980
Creating a Security World on a Stand-Alone IVE ....................................981
Creating a Security World in a Clustered Environment ..........................982
Replacing Administrator Cards ..............................................................982
Recovering an Archived Security World .......................................................983
Importing a Security World Into a Stand-Alone IVE ...............................984
Importing a Security World Into a Cluster..............................................984
Chapter 42
Secure Access 4500 & 6500 FIPS
987
FIPS Overview .............................................................................................988
Name and Password Requirements .............................................................988
Initializing a Keystore...................................................................................988
Reinitializing the Keystore ...........................................................................989
Joining a Cluster ...........................................................................................990
Device Certificates .......................................................................................991
Changing the Security Officer Password.......................................................991
Changing the Web User Password ...............................................................991
Resetting the HSM Card In Case Of An Error................................................992
Upgrading the HSM Firmware......................................................................992
Binary Importing and Exporting of the Keystore ..........................................993
FIPS Device Status LED Behavior...........................................................993
Chapter 43
Compression
995
Licensing: Compression Availability .............................................................995
Compression Execution ...............................................................................995
Supported Data Types..................................................................................996
Enabling Compression at the System Level ..................................................997
Creating Compression Resource Profiles and Policies ..................................998
Chapter 44
Multi-Language Support
999
Licensing: Multi-Language Support Availability........................................... 1000
Encoding Files............................................................................................ 1000
Localizing the User Interface ...................................................................... 1000
Localizing Custom Sign-In and System Pages............................................. 1001
Chapter 45
Handheld Devices and PDAs
1003
Licensing: Handheld and PDA Support Availability .................................... 1004
Task Summary: Configuring the IVE for PDAs and Handhelds ...................1004
Defining Client Types................................................................................. 1005
Enabling WSAM on PDAs........................................................................... 1007
Enabling ActiveSync................................................................................... 1008
Table of Contents

xxi
Juniper Networks Secure Access Administration Guide
Part 7
Supplemental Information
Appendix A
Writing Custom Expressions
1013
Licensing: Custom Expressions Availability ................................................1013
Custom Expressions................................................................................... 1013
Wildcard Matching .............................................................................. 1017
DN Variables and Functions ................................................................ 1017
System Variables and Examples................................................................. 1018
Using System Variables in Realms, Roles, and Resource Policies ............... 1027
Using Multi-valued Attributes............................................................... 1028
Specifying Fetch Attributes in a Realm ................................................1029
Specifying the homeDirectory Attribute for LDAP................................ 1030
xxii

Table of Contents
About This Guide
This guide provides the information you need to understand, configure, and
maintain a Juniper Networks Instant Virtual Extranet (IVE) appliance, including:

Overview material to familiarize yourself with Secure Access products and the
underlying access management system

Overview material describing baseline and advanced features, as well as
upgrade options

Instructions for configuring and managing your IVE appliance or cluster
Audience
This guide is for the system administrator responsible for configuring Secure Access
and Secure Access FIPS products.
Where to find additional information
Administrator and developer documentation

To download a PDF version of this administration guide, go to the IVE OS
Product Documentation page of the Juniper Networks Customer Support Center.

For information about the changes that Secure Access clients make to client
computers, including installed files and registry changes, and for information
about the rights required to install and run Secure Access clients, refer to the
Client-side Changes Guide.

For information on how to develop Web applications that are compliant with
the IVE Content Intermediation Engine, refer to the Content Intermediation
Engine Best Practices Guide.

For information on how to personalize the look-and-feel of the preauthentication, password management, and Secure Meeting pages that the IVE
displays to end-users and administrators, refer to the Custom Sign-In Pages
Solution Guide.
Audience

xxiii
Juniper Networks Secure Access Administration Guide
Error Message Documentation

For information about error messages that Network Connect and WSAM
displays to end-users, refer to Network Connect and WSAM Error Messages.

For information about error messages that Secure Meeting displays to
administrators end-users, refer to Secure Meeting Error Messages.
Hardware documentation

For help during installation, refer to the Quick Start Guide that comes with the
product.

For Secure Access and Secure Access FIPS safety information, refer to the
Juniper Networks Security Products Safety Guide.

For information on how to install hard disks, power supplies, and cooling fans
on Secure Access 6000 appliances, refer to the Secure Access 6000 Field
Replaceable Units Guide.

To download the latest build of the Secure Access and Secure Access FIPS OS
and release notes, go to the IVE OS Software page of the Juniper Networks
Customer Support Center.
Product downloads
Conventions
Table 1 defines notice icons used in this guide, and Table 2 defines text conventions
used throughout the book.
Table 1: Notice icons
Icon
Meaning
Description
Informational note
Indicates important features or instructions.
Caution
Indicates that you may risk losing data or damaging your
hardware.
Warning
Alerts you to the risk of personal injury.
Table 2: Text conventions (except for command syntax)
xxiv

Convention
Description
Examples
Bold typeface
Indicates buttons, field names, dialog
box names, and other user interface
elements.
Use the Scheduling and Appointment tabs to
schedule a meeting.
Conventions
About This Guide
Table 2: Text conventions (except for command syntax) (Continued)
Convention
Description
Examples
Plain sans serif typeface
Represents:
Examples:
 Code, commands, and keywords
 Code:
 URLs, file names, and directories
certAttr.OU = 'Retail Products Group'
 URL:
Download the JRE application from:
http://java.sun.com/j2se/
Italics
Identifies:
Examples:
 Terms defined in text
 Defined term:
 Variable elements
 Book names
An RDP client is a Windows component that
enables a connection between a Windows
server and a user’s machine.
Variable element:
Use settings in the Users > User Roles >
Select Role > Terminal Services page to create
a terminal emulation session.
 Book name:
See the IVE Supported Platforms document.
Documentation
Release Notes
Release notes are included with the product software and are available on the Web.
In the Release Notes, you can find the latest information about features, changes,
known problems, and resolved problems. If the information in the Release Notes
differs from the information found in the documentation set, follow the Release
Notes.
Web Access
To view the documentation on the Web, go to:
http://www.juniper.net/techpubs/
Contacting Customer Support
For technical support, contact Juniper Networks at support@juniper.net, or at 1-888314-JTAC (within the United States) or 408-745-9500 (from outside the United
States).
Documentation

xxv
Juniper Networks Secure Access Administration Guide
xxvi

Contacting Customer Support
Part 1
Getting Started
The IVE is a hardened network appliance that provides robust security by
intermediating the data streams that flow between external users and internal
resources. This section contains the following information about beginning to use
and understand the IVE:

“Initial Verification and Key Concepts” on page 3

“Introduction to the IVE” on page 25

1
Juniper Networks Secure Access Administration Guide
2

Chapter 1
Initial Verification and Key Concepts
This topic describes the tasks you do after initially installing and configuring your
IVE. It assumes that you have already followed the Task Guide in the admin console
to update your software image and to generate and apply your Secure Access
license key.
Verifying User Accessibility
You can easily create a user account in the system authentication server for use in
verifying user accessibility to your IVE. After creating the account through the
admin console, sign in as the user on the IVE user sign-in page.
To verify user accessibility:
1. Select Authentication > Auth. Servers from the admin console.
2. Select the System Local link.
The System Local page appears.
3. Select the Users tab.
4. Click New.
The New Local User page appears.
5. Type testuser1 as the username and enter a password, and then click Save
Changes. The IVE 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 IVE.
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 IVE appliance. See Figure 1.
Verifying User Accessibility

3
Juniper Networks Secure Access Administration Guide
Figure 1: User Sign-in Page
8. Enter the username and password you created for the user account and then
click Sign In to access the IVE home page for users. See Figure 2.
Figure 2: User Home Page (Default)
9. Enter the URL to an internal Web server in the Address box and click Browse.
The IVE opens the Web page in the same browser window, so to return to the
IVE home page, click the center button on the toolbar that appears on the target
Web page. See Figure 3.
4

Verifying User Accessibility
Chapter 1: Initial Verification and Key Concepts
Figure 3: Example Internal Web Page with Browsing Toolbar
10. Enter the URL to your external corporate site on the IVE home page (see
Figure 2), and click Browse. The IVE opens the Web page in the same browser
window, so use the button on the toolbar to return to the IVE home page.
11. Click Browsing > Windows Files on the IVE home page (see Figure 2) to
browse through available Windows file shares or Browsing > UNIX/NFS Files
to browse through available UNIX NFS file shares.
After verifying user accessibility, return to the admin console to go through an
introduction of key concepts, as described in “Creating a Test Scenario to Learn IVE
Concepts and Best Practices” on page 5.
Creating a Test Scenario to Learn IVE Concepts and Best Practices
The IVE provides a flexible access management system that makes it easy to
customize a user’s remote access experience through the use of roles, resource
policies, authentication servers, authentication realms, and sign-in policies. To
enable you to quickly begin working with these entities, the IVE ships with system
defaults for each. This section describes these system defaults and shows you how
to create each access management entity by performing the following tasks:

“Defining a User Role” on page 6

“Defining a Resource Profile” on page 8

“Defining an Authentication Server” on page 10

“Defining an Authentication Realm” on page 13

“Defining a Sign-In Policy” on page 16
Creating a Test Scenario to Learn IVE Concepts and Best Practices

5
Juniper Networks Secure Access Administration Guide

“Using the Test Scenario” on page 19
NOTE: The IVE supports two types of users:

Administrators—An administrator is a person who may view or modify IVE
configuration settings. You create the first administrator account through the
serial console.

Users—A user is a person who uses the IVE to gain access to corporate
resources as configured by an administrator. You created the first user account
(testuser1) in “Verifying User Accessibility” on page 3.
The following test scenario focuses on using the IVE access management elements
to configure access parameters for a user. For information about the system default
settings for administrators, see “Configuring Default Settings for Administrators” on
page 22.
Defining a User Role
The IVE 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.
NOTE: 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. Choose Users > User Roles from the admin console. The Roles page appears.
2. Click New Role. The New Role page appears. See Figure 4.
3. Enter Test Role in the Name box and then click Save Changes. Wait for the IVE
to display the Test Role page with the General tab and Overview link selected.
See Figure 8.
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.
NOTE: To quickly create a user role that enables Web and file browsing, duplicate
the Users role, and then enable additional access features as desired.
6

Creating a Test Scenario to Learn IVE Concepts and Best Practices
Chapter 1: Initial Verification and Key Concepts
Figure 4: New Role Page
Figure 5: Test Role Page
Creating a Test Scenario to Learn IVE Concepts and Best Practices

7
Juniper Networks Secure Access Administration Guide
Defining a Resource Profile
A resource profile is a set of configuration options that contains all of the resource
policies, role assignments, and end-user bookmarks required to provide access to
an individual resource.
Within a resource profile, a resource policy specifies the resources to which the
policy applies (such as URLs, servers, and files) and whether the IVE grants access
to a resource or performs an action. Note that the IVE is preconfigured with two
types of resource policies:

Web Access—The predefined Web Access resource policy enables all users to
access the Internet and all corporate Web servers through the IVE. By default,
this resource policy applies to the Users role.

Windows Access—The predefined Windows Access resource policy enables all
users mapped to the Users role to access all corporate Windows file servers. By
default, this resource policy applies to the Users role.
NOTE: Delete the default Web Access and Windows Access resource policies if you
are concerned about users having access to all of your Web and file content.
To define a resource profile:
1. Select Users > Resource Profiles > Web from the admin console. The Web
Applications Resource Profile page appears.
2. Click New Profile. The Web Applications Resource Profile page appears. See
Figure 6.
8

Creating a Test Scenario to Learn IVE Concepts and Best Practices
Chapter 1: Initial Verification and Key Concepts
Figure 6: New Web Application Resource Profile Page
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
c.
In the Base URL box, type http://www.google.com
d. Under Autopolicy: Web Access Control, select the check box next to the
default policy created by the IVE (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.
Creating a Test Scenario to Learn IVE Concepts and Best Practices

9
Juniper Networks Secure Access Administration Guide
b.
Click Save Changes.
The IVE adds Test Web Access to the Web Application Resource Policies page and
automatically creates a corresponding bookmark that links to google.com.
After completing these steps, you have configured a Web Access resource profile.
Even though the IVE comes with a resource policy that enables access to all Web
resources, users mapped to Test Role are still prohibited from accessing
http://www.google.com. These users are denied access because the autopolicy you
created during the resource profile configuration takes precedence over the default
Web access policy that comes with the IVE.
Defining an Authentication Server
An authentication server is a database that stores user credentials—username and
password—and typically group and attribute information. When a user signs in to
an IVE, the user specifies an authentication realm, which is associated with an
authentication server. The IVE forwards the user’s credentials to this authentication
server to verify the user’s identity.
The IVE supports the most common authentication servers, including Windows NT
Domain, Active Directory, RADIUS, LDAP, NIS, RSA ACE/Server, SAML Server, and
eTrust SiteMinder, and enables you to create one or more local databases of users
who are authenticated by the IVE. The IVE is preconfigured with one local
authentication server for users called “System Local.” This predefined local
authentication server is an IVE database that enables you to quickly create user
accounts for user authentication. This ability provides flexibility for testing
purposes and for providing third-party access by eliminating the need to create
user accounts in an external authentication server.
You can view the default local authentication server on the Authentication Servers
page.
NOTE: The IVE 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. Select Authentication > Auth. Servers from the admin console. The
Authentication Servers page appears.
2. Select Local Authentication from the New list and then click New Server. The
New Local Authentication page appears. see Figure 7.
10

Creating a Test Scenario to Learn IVE Concepts and Best Practices
Chapter 1: Initial Verification and Key Concepts
Figure 7: new Local Authentication Page
3. Enter Test Server in the Name box and then click Save Changes. Wait for the
IVE 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. See
Figure 8.
Creating a Test Scenario to Learn IVE Concepts and Best Practices

11
Juniper Networks Secure Access Administration Guide
Figure 8: New Local user Page
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.
See Figure 9.
12

Creating a Test Scenario to Learn IVE Concepts and Best Practices
Chapter 1: Initial Verification and Key Concepts
Figure 9: Test Server Page
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.
NOTE: 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.
Defining an Authentication Realm
An authentication realm is a grouping of authentication resources, including:

An authentication server, which verifies a user’s identity. The IVE forwards
credentials submitted on a sign-in page to an authentication server.

An authentication policy, which specifies realm security requirements that
need to be met before the IVE submits credentials to an authentication server
for verification.
Creating a Test Scenario to Learn IVE Concepts and Best Practices

13
Juniper Networks Secure Access Administration Guide

A directory server, which is an LDAP server that provides user and group
attribute information to the IVE for use in role mapping rules and resource
policies (optional).

Role mapping rules, which are conditions a user must meet for the IVE to map
a user to one or more roles. These conditions are based on information
returned by the realm's directory server, the person’s username, or certificate
attributes.
The IVE 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 create in “Verifying User Accessibility” on
page 3 is part of the Users realm, because this account is created in the System
Local authentication server. The “testuser2” account you create in “Defining an
Authentication Server” on page 10 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. Select Users > User Realms from the admin console. The User Authentication
Realms page appears.
2. Click New. The New Authentication Realm page appears. See Figure 10.
14

Creating a Test Scenario to Learn IVE Concepts and Best Practices
Chapter 1: Initial Verification and Key Concepts
Figure 10: New Authentication Realm Page
3. Enter Test Realm in the Name box.
4. Select Test Server from the Authentication list.
5. Click Save Changes. Wait for the IVE 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. See Figure 11.
Creating a Test Scenario to Learn IVE Concepts and Best Practices

15
Juniper Networks Secure Access Administration Guide
Figure 11: Role Mapping Rule Page
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.
Defining a Sign-In Policy
A sign-in policy is a system rule that specifies:
16


A URL where a user may sign in to the IVE

A sign-in page to display to the user

Whether or not the user needs to type or select an authentication realm to
which the IVE submits credentials

The authentication realms where the sign-in policy applies
Creating a Test Scenario to Learn IVE Concepts and Best Practices
Chapter 1: Initial Verification and Key Concepts
All Secure Access and Secure Access FIPS IVEs are preconfigured with one sign-in
policy that applies to users: */. This default user sign-in policy (*/) specifies that
when a user enters the URL to the IVE, the IVE 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 in “Defining an Authentication Realm” on page 13.
You can view the default user sign-in policy on the Signing In page. If your IVE has
the Secure Meeting Upgrade license, the */meeting sign-in policy is also listed on
this page. This policy enables you to customize the sign-in page for secure
meetings.
To define a sign-in policy:
1.
Select Authentication > Signing in > Sign-in Policies from the admin console.
The Signing In page appears.
2. Click */ under User URLs. The */ page appears. See Figure 12.
Figure 12: The */ Page
3. Enter test after */ in the Sign-in URL box.
Creating a Test Scenario to Learn IVE Concepts and Best Practices

17
Juniper Networks Secure Access Administration Guide
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:
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 Signin 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. See Figure 13.
18

Creating a Test Scenario to Learn IVE Concepts and Best Practices
Chapter 1: Initial Verification and Key Concepts
Figure 13: The */test/ Page
6. Select Test Sign-in Page from the Sign-in page list and then click Save Changes.
After completing these optional steps, you have finished defining a new sign-in
page that is associated with the */test/ sign-in policy.
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 signin 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.
Creating a Test Scenario to Learn IVE Concepts and Best Practices

19
Juniper Networks Secure Access Administration Guide
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 IVE appliance. See Figure 14.
Figure 14: User Sign-in Page
NOTE: If you performed the optional configuration steps in “Defining a Sign-In
Policy” on page 16, 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
IVE home page for users. See Figure 15.
The IVE forwards the credentials to Test Realm, which is configured to use Test
Server. Upon successful verification by this authentication server, the IVE
processes the role mapping rule defined for Test Realm, which maps testuser2
to Test Role. Test Role enables Web browsing for users.
20

Creating a Test Scenario to Learn IVE Concepts and Best Practices
Chapter 1: Initial Verification and Key Concepts
Figure 15: User Home Page
4. In the browser Address box, enter the URL to your corporate Web site and click
Browse. The IVE opens the Web page in the same browser window, so to
return to the IVE home page, click the center icon in the browsing toolbar that
appears on the target Web page.
5. On the IVE home page, type www.google.com and click Browse. The IVE
displays an error message, because the Test Web Access resource policy denies
access to this site for users mapped to Test Role. See Figure 16.
Figure 16: Example Error Message for Denied Resource
6. Return to the IVE 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.
8. On the IVE home page, type www.google.com and click Browse. The IVE
opens the Web page in the same browser window.
Creating a Test Scenario to Learn IVE Concepts and Best Practices

21
Juniper Networks Secure Access Administration Guide
The test scenario demonstrates the basic IVE 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 IVE access
management, we recommend that you take a few minutes to review the online
Help to familiarize yourself with its contents.
NOTE:

When you configure the IVE for your enterprise, we recommend that you
perform user access configuration in the order presented in this section.

For detailed configuration information, see the instructions in other sections of
this guide.

Before you make your IVE available from external locations, we recommend that
you import a signed digital certificate from a trusted certificate authority (CA).
Configuring Default Settings for Administrators
Just like for users, the IVE provides default settings that enable you to quickly
configure accounts for administrators. This list summarizes the system default
settings for administrators:

22

Administrator roles—There are two built-in administrator roles.

.Administrators — This built-in role permits administrators to manage all
aspects of the IVE. 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 IVE 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 IVE database that stores administrator accounts.
You create the first administrator account in this server through the serial
console. (The IVE 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 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.
Configuring Default Settings for Administrators
Chapter 1: Initial Verification and Key Concepts

*/admin sign-in policy — The default administrator sign-in policy (*/admin)
specifies that when a user enters the URL to the IVE followed by /admin, the
IVE 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.
Configuring Default Settings for Administrators  23
Juniper Networks Secure Access Administration Guide
24

Configuring Default Settings for Administrators
Chapter 2
Introduction to the IVE
The Juniper Networks Instant Virtual Extranet (IVE) platform serves as the
underlying hardware and software for the Juniper Networks SSL VPN appliances.
These products 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.
This topic contains the following information about the IVE:

“What Is the IVE?” on page 25

“What Can I Do with the IVE?” on page 27

“How Do I Start Configuring the IVE?” on page 32

“Using Network and Security Manager with the IVE” on page 33
What Is the IVE?
The IVE is a hardened network operating system that acts as the platform for all
Juniper Networks Secure Access products. These appliances provide a range of
enterprise-class scalability, high availability, and security features that extend
secure, remote access to network resources.
The IVE provides robust security by intermediating the data that flows between
external users and your company’s internal resources. Users gain authenticated
access to authorized resources through an extranet session hosted by the appliance.
During intermediation, the IVE receives secure requests from the external,
authenticated users and then makes requests to the internal resources on behalf of
those users. By intermediating content in this way, the IVE eliminates the need to
deploy extranet toolkits in a traditional DMZ or provision a remote access VPN for
employees.
To access the intuitive IVE 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. See Figure 17.
What Is the IVE?

25
Juniper Networks Secure Access Administration Guide
NOTE: These capabilities depend upon the Juniper Networks Secure Access
product and upgrade options you have purchased.
Figure 17: The IVE Working within a LAN
You can configure a Juniper Networks Secure Access appliance in the following
ways:
26

What Is the IVE?

Provide users with secure access to a variety of resources. The IVE
intermediates access to multiple types of applications and resources such as
Web-based enterprise applications, Java applications, file shares, terminal hosts,
and other client/server applications such as Microsoft Outlook, Lotus Notes, the
Citrix ICA Client, and pcAnywhere. Additionally, administrators can provision
an access method that allows full Layer 3 connectivity, providing the same level
of access that a user would get if they were on the corporate LAN.

Fine-tune user access to the appliance, resource types, or individual resources
based on factors such as group membership, source IP address, certificate
attributes, and endpoint security status. For instance, you can use dual-factor
authentication and client-side digital certificates to authenticate users to the IVE
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.
Chapter 2: Introduction to the IVE
The IVE acts as a secure, Application Layer gateway intermediating all requests
between the public Internet and internal corporate resources. All requests that enter
the IVE are already encrypted by the end user's browser, using SSL/HTTPS 128-bit
or 168-bit encryption—unencrypted requests are dropped. Because the IVE
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.
What Can I Do with the IVE?
The IVE offers a wide variety of features that you can use to secure your company’s
resources and easily maintain your environment. The following topics answer
questions you may have about the IVE’s security and management capabilities:

“Can I Use the IVE to Secure Traffic to All of My Company’s Applications,
Servers, and Web Pages?” on page 27

“Can I Use My Existing Servers to Authenticate IVE Users?” on page 29

“Can I Fine-Tune Access to the IVE and the Resources It Intermediates?” on
page 29

“Can I Create a Seamless Integration Between the IVE and the Resources It
Intermediates?” on page 30

“Can I Use the IVE to Protect Against Infected Computers and Other Security
Concerns?” on page 31

“Can I Ensure Redundancy in my IVE Environment?” on page 31

“Can I Make the IVE Interface Match My Company’s Look-and-Feel?” on
page 31

“Can I Enable Users on a Variety of Computers and Devices to Use the IVE?” on
page 32

“Can I Provide Secure Access for My International Users?” on page 32
Can I Use the IVE to Secure Traffic to All of My Company’s Applications, Servers, and
Web Pages?
The IVE enables you to secure access to a wide variety of applications, servers, and
other resources through its remote access mechanisms. Once you have chosen
which resource you want to secure, you can then choose the appropriate access
mechanism.
For instance, if you want to secure access to Microsoft Outlook, you can use the
Secure Application Manager (SAM). The Secure Application Manager intermediates
traffic to client/server applications including Microsoft Outlook, Lotus Notes, and
Citrix. Or, if you want to secure access to your company Intranet, you can use the
Web rewriting feature. This feature uses the IVE’s Content Intermediation Engine to
intermediate traffic to Web-based applications and Web pages.
What Can I Do with the IVE?

27
Juniper Networks Secure Access Administration Guide
The IVE includes remote access mechanisms that intermediate the following types
of traffic:
28

What Can I Do with the IVE?

Web-based traffic, including Web pages and Web-based applications—Use
the Web rewriting feature to intermediate this type of content. The Web
rewriting feature includes templates that enable you to easily configure access
to applications such as Citrix, OWA, Lotus iNotes, and Sharepoint. In addition,
you can use the Web rewriting custom configuration option to intermediate
traffic from a wide variety of additional Web-based applications and Web pages,
including custom-built Web applications.

Java applets, including Web applications that use Java applets—Use the
hosted Java applets feature to intermediate this type of content. This feature
enables you to host Java applets and the HTML pages that they reference
directly on the IVE rather than maintaining a separate Java server.

File traffic, including file servers and directories—Use the file rewriting
feature to intermediate and dynamically “webify” access to file shares. The file
rewriting feature enables you to secure traffic to a variety of Windows and Unix
based servers, directories, and file shares.

Client/server applications—Use the Secure Application Manager (SAM) feature
to intermediate this type of content. SAM comes in two varieties (Windows and
Java 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 the IVE, eliminating the need to use another Web server to
host the clients.

E-mail clients based on the IMAP4, POP3, and SMTP protocols—Use the email client feature to intermediate this type of content. This feature enables you
to easily configure access to any corporate mail server based on the IMAP4,
POP3, and SMTP protocols, such as Microsoft Exchange Server and Lotus Notes
Mail servers.

All network traffic—Use the Network Connect feature to create a secure, Layer
3 tunnel over the SSL connection, allowing access to any type of application
available on the corporate network. This feature enables you to easily connect
remote users into your network by tunneling network traffic over port 443,
enabling users full access to all of your network resources without configuring
access to individual servers, applications, and resources.
Chapter 2: Introduction to the IVE
For more information about securing traffic using the IVE remote access
mechanisms, see “Remote Access” on page 351.
Can I Use My Existing Servers to Authenticate IVE Users?
You can easily configure the IVE 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 IVE. The IVE supports integration with LDAP, RADIUS, NIS,
Windows NT Domain, Active Directory, eTrust SiteMinder, SAML, and RSA
ACE/Servers.
Or, if you do not want to use one of these standard servers, you can store
usernames and credentials directly on the IVE and use the IVE itself as an
authentication server. In addition, you can choose to authenticate users based on
attributes contained in authentication assertions generated by SAML authorities or
client-side certificates. Or, if you do not want to require your users to sign into the
IVE, you can use the IVE anonymous authentication server, which allows users to
access the IVE without providing a username or password.
For more information about protecting access to the IVE using authentication
servers, see “Authentication and Directory Servers” on page 131.
Can I Fine-Tune Access to the IVE and the Resources It Intermediates?
In addition to using authentication servers to control access to the IVE, you can
control access to the IVE and the resources it intermediates using a variety of
additional client-side checks. The IVE enables you to create a multilayered approach
to protect the IVE and your resources:
1. First, you can perform preauthentication checks that control user access to the
IVE sign-in page. For instance, you might configure the IVE 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 IVE sign-in page until the user has updated the computer’s
antivirus software.
2. Once a user has successfully accessed the IVE sign-in page, you can perform
realm-level checks to determine whether he can access the IVE 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
IVE end-user home page. Otherwise, the IVE does not enable the user to sign in,
or the IVE displays a “stripped down” version of the IVE home page that you
create. Generally, this stripped down version contains significantly less
functionality than is available to your standard users because the user has not
passed all of your authentication criteria. The IVE provides extremely flexible
policy definitions, enabling you to dynamically alter end-user resource access
based on corporate security policies.
What Can I Do with the IVE?

29
Juniper Networks Secure Access Administration Guide
3. After the IVE 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 members of the Employees role and to
sign into the IVE during business hours to access your company Intranet.
For more information about fine-tuning access to the IVE and the resources it
intermediates, see “Access Management Framework” on page 47.
Can I Create a Seamless Integration Between the IVE and the Resources It
Intermediates?
In a typical IVE configuration, you could add bookmarks directly to the IVE end-user
home page. These bookmarks are links to the resources that you configure the IVE
to intermediate. Adding these bookmarks enables users to sign into a single place
(the IVE) and find a consolidated list of all of the resources available to them.
Within this typical configuration, you can streamline the integration between the
IVE and the intermediated resources by enabling single sign-on (SSO). SSO is a
process that allows preauthenticated IVE users to access other applications or
resources that are protected by another access management system without having
to re-enter their credentials. During IVE configuration, you can enable SSO by
specifying user credentials that you want the IVE to pass to the intermediated
resources. See “Single Sign-On” on page 235.
Or, if you do not want to centralize user resources on the IVE end-user home page,
you could create links to the IVE-intermediated resources from another Web page.
For instance, you can configure bookmarks on the IVE, 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 IVE home page. As with standard IVE bookmarks, you
can enable SSO for these external links.
30

What Can I Do with the IVE?
Chapter 2: Introduction to the IVE
Can I Use the IVE to Protect Against Infected Computers and Other Security Concerns?
The IVE enables you to protect against viruses, attacks, and other security concerns
using the Host Checker feature. Host Checker performs security checks on the
clients that connect to the IVE. 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 IVE 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.
You can also use Host Checker to create a protected workspace on clients running
Windows 2000 or Windows XP. Through Host Checker, you can enable the Secure
Virtual Workspace (SVW) feature to create a protected workspace on the client
desktop, ensuring that any end user signing in to your intranet must perform all
interactions within a completely protected environment. Secure Virtual Workspace
encrypts information that applications write to disk or the registry and then
destroys all information pertaining to itself or the IVE session when the session is
complete.
You can also secure your network from hostile outside intrusion by integrating your
IVE 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.
For more information about Host Checker and other native IVE endpoint defense
mechanisms, see “Endpoint Defense” on page 271. For more information about
integrating the IVE with IDP, see “IVE and IDP Interoperability” on page 939.
Can I Ensure Redundancy in my IVE Environment?
You can ensure redundancy in your IVE environment using the IVE clustering
feature. With this feature, you can deploy two or more appliances as a cluster,
ensuring no user downtime in the rare event of failure and stateful peering that
synchronizes user settings, system settings, and user session data.
These appliances support active/passive or active/active configurations across a LAN
or a WAN. In Active/Passive mode, one IVE actively serves user requests while the
other IVE runs passively in the background to synchronize state data. If the active
IVE goes offline, the standby IVE 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 an IVE defined in its cluster group based on source-IP
routing. If an IVE goes offline, the load balancer adjusts the load on the active IVEs.
Can I Make the IVE Interface Match My Company’s Look-and-Feel?
The IVE 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 IVE
end-user console so it will resemble one of your standard company Web pages or
applications.
What Can I Do with the IVE?

31
Juniper Networks Secure Access Administration Guide
For instance, you can easily customize the headers, background colors, and logos
that the IVE displays in the IVE sign-in page and end-user console to match your
company’s style. You can also easily customize the order in which the IVE displays
bookmarks and the help system that the IVE displays to users.
Or, if you do not want to display the IVE 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 IVE console. If you
choose to use this option, you may want to add links to your IVE bookmarks on the
new page, as explained in “Can I Create a Seamless Integration Between the IVE
and the Resources It Intermediates?” on page 30.
If you want to further customize the IVE sign-in page, you can use the IVE’s custom
sign-in pages feature. Unlike the standard customization options that you can
configure through the IVE 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.
For more information about customizing the look-and-feel of the IVE, see
“Customizable Admin and End-User UIs” on page 959.
Can I Enable Users on a Variety of Computers and Devices to Use the IVE?
In addition to allowing users to access the IVE from standard workstations and
kiosks running Windows, Macintosh, and Linux operating systems, the IVE also
allows end users to access the IVE from connected PDAs, handhelds and smart
phones such as i-mode and Pocket PC. When a user connects from a PDA or
handheld device, the IVE determines which IVE pages and functionality to display
based on settings that you configure.
For more information about specifying which pages the IVE displays to different
devices, see the IVE supported platforms document available on the IVE OS
Software page of the Juniper Networks Customer Support Center.
For more information about the exact operating systems, PDAs, and handheld
devices that the IVE supports, see “Handheld Devices and PDAs” on page 1003.
Can I Provide Secure Access for My International Users?
The IVE supports English (US), French, German, Spanish, Simplified Chinese,
Traditional Chinese, Japanese, and Korean. When your users sign into the IVE, the
IVE 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.
For more information about localization, see “Multi-Language Support” on
page 999.
How Do I Start Configuring the IVE?
To enable users to start using your Secure Access appliance, you must complete the
following basic steps:
32

How Do I Start Configuring the IVE?
Chapter 2: Introduction to the IVE
1. Plug in the appliance, connect it to your network, and configure its initial
system and network settings. This quick and easy process is detailed in the
Secure Access Quick Start Guide.
2. After you connect the IVE to your network, you need to set the system date and
time, upgrade to the latest service package, and install your product licenses.
When you first sign into the admin console, the IVE displays an initial
configuration task guide that quickly walks you through this process.
3. After you install your product licenses, you need to set up your access
management framework to enable your users to authenticate and access
resources. Configuration steps include:
a.
Define an authentication server that verifies the names and passwords of
your users.
b.
Create user roles that enable access mechanisms, session options, and UI
options for user groups.
c.
Create a user authentication realm that specifies the conditions that users
must meet to sign into the IVE.
d. Define a sign-in policy that specifies the URL that users must access to sign
into the IVE and the page that they see when they sign in.
e.
Create resource profiles that control access to resources, specify which user
roles can access them, and include bookmarks that link to the resources.
The IVE 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. Or, you can use the tutorial included in
this guide. For more information, see “Initial Verification and Key Concepts” on
page 3.
Once you have completed these basic steps, your Secure Access appliance is ready
for use. You can start using it as is, or configure additional advanced features such
as endpoint defense and clustering.
Using Network and Security Manager with the IVE
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 IVE configurations.
With NSM you can manage most of the parameters that you can configure through
the IVE admin console. The configuration screens rendered through NSM are similar
to the IVE’s native interface.
NSM incorporates a broad configuration management framework that allows comanagement using other methods. You can import and export XML via the IVE’s
admin console interface, or you can manage from the IVE’s admin console.
Using Network and Security Manager with the IVE

33
Juniper Networks Secure Access Administration Guide
How the IVE and NSM communicate
The IVE 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, XMLbased configuration, text-based configuration, alarm monitoring, and devicespecific commands), structured syslog, and threat flow for network profiling. DMI
supports third-party network management systems that incorporate the DMI
standard, however only one DMI-based agent per device is supported.
The IVE’s configuration is represented as a hierarchical tree of configuration items.
This structure is expressed in XML that can be manipulated with NetConf. NetConf
is a network management protocol that uses XML. DMI uses NetConf’s generic
configuration management capability and applies it to allow remote configuration
of the device.
To allow NSM to manage the IVE using the DMI protocol, NSM must import the
schema and meta-data files from the Juniper Update Repository, a publiclyaccessible resource that is updated with each device release.
The Juniper Update Repository enables access to XSD and XML files defined for
each device, model and software version.
Before attempting to communicate with NSM, you must first complete the initial
configuration of the IVE. Initial configuration includes network interface settings,
DNS settings, licensing, and password administration.
If you have several IVEs that will be configured in a clustering environment, you
must first configure the cluster in the IVE admin UI and then manually add the
nodes into the NSM cluster object. NSM cannot auto-detect cluster membership.
After you have completed the initial network configuration, you can configure the
IVE to communicate with NSM using the appropriate network information. Once
the IVE has been configured to communicate with NSM, the IVE contacts NSM and
establishes a DMI session through an initial TCP handshake.
All communications between the IVE and NSM occur over SSH to ensure data
integrity.
After the IVE initially contacts NSM and a TCP session is established, interaction
between the IVE and NSM is driven from NSM, which issues commands to get
hardware, software, and license details of the IVE. NSM connects to the Juniper
Update Repository to download the configuration schema that is particular to the
IVE.
Once the IVE and NSM are communicating, the IVE delivers syslog and event
information to NSM.
After NSM and the IVE are connected, you can make any configuration changes
directly on the IVE, bypassing NSM. Currently there is no automatic re-import
feature on NSM. If you make changes directly on the IVE you must manually report
them into NSM.
34

Using Network and Security Manager with the IVE
Chapter 2: Introduction to the IVE
When you make changes to the IVE configuration through NSM you must push the
changes to the device by performing an Update Device operation.
When you double-click the IVE device 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 IVE interface.
Available Services and Configuration Options
The following services and options are provided to NSM by the IVE:

Inventory management service—inventory management service enables
management of the IVEs 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 the IVE’s status to
be obtained, including name, domain, OS version, synchronization status,
connection details, and current alarms.

Logging service—logging service allow the IVEs logs to be obtained in a timegenerated order. Logging configuration details that are set on the IVE will apply
to NSM.

XML-based configuration management service—configuration management
service enables NSM to manage the configuration of the IVE. See “Importing
and Exporting XML Configuration Files” on page 716.
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

Adding device certificates
Task Summary: Configuring DMI Communication for NSM
To configure the IVE to communicate with NSM you must coordinate actions
between the IVE 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 IVE and NSM.
To connect the IVE and NSM you will need to do the following:

Install and configure the IVE.

Add the IVE as a device in NSM.

Configure and activate the DMI agent on the IVE.

Confirm connectivity and import the IVE configuration into NSM.
Using Network and Security Manager with the IVE

35
Juniper Networks Secure Access Administration Guide
Configuring the IVE for the Initial DMI Connection
To permit the IVE and NSM to make an initial connection, you must add an NSM
administrative user to the IVE configuration. This section provides a summary of
adding the NSM administrator and configuring the DMI agent to allow the IVE and
NSM to communicate. Complete configuration of the IVE for authenticating users is
outside the scope of this section.
To initiate a DMI session for communication between the IVE and NSM:
1. Ensure that basic connection information is configured on the IVE (network
address, DNS, password).
2. Ensure that the proper licenses are installed on the IVE.
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 an IVE to NSM. See Juniper Networks Netscreen Security Manager
Administrator’s Guide.
NOTE: You must enter a unique NSM admin username and password on the NSM
UI client. This username will be used on the IVE as the username for the
administrator account that will be used to manage the IVE. NSM must have a
unique account login to avoid interrupting the communication with the IVE. NSM
automatically generates a unique ID which is used for the HMAC key.
4. From the IVE 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. See “Authentication and
Directory Servers” on page 93.
NOTE: Only password-based authentication servers can be used. One-timepassword authentication is not supported.
5. On the NSM interface, select the Domain menu and choose the domain to
which the IVE will be added.
6. In Device Manager, click the Add icon and select Device to open the Add Device
wizard, and enter the applicable information required to add an IVE to NSM.
See Juniper Networks Netscreen Security Manager Administrator’s Guide.
NOTE:
36


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.
Using Network and Security Manager with the IVE
Chapter 2: Introduction to the IVE
7. After you have added the IVE to NSM, select System > Configuration > DMI
Agent on the IVE admin console.
8. Under DMI connection, select the:

Inbound Enabled check box if you are using an SSH secure shell
Command Line Interface (CLI) to manage the IVE. The IVE 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 IVE to
communicate with NSM.
NOTE: When you enable or disable a connection, it takes a few minutes for the
connection state to be updated.
9. Under DMI settings for inbound connections, enter the TCP port in which the
IVE should accept connections. This TCP port should not be used by any other
IVE processes. We recommend you use the default port or a port number larger
than 1024.
10. Under DMI settings for outbound connections, 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.
11. Select the Admin realm that you have configured for the DMI agent.
The IVE initiates a TCP connection to NSM. After the IVE is identified to NSM
through the HMAC key and device ID hash, The IVE and NSM negotiate an SSH
tunnel, and NSM requests authentication to the IVE 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.
Adding IVE Clusters
To add an IVE cluster in NSM, you first add the cluster, then you add each member.
Adding a member is similar to adding a standalone IVE. 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 Secure Access
devices 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.
Using Network and Security Manager with the IVE

37
Juniper Networks Secure Access Administration Guide
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 device, 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.
The following sections provide detailed instructions on managing large binary data
files in NSM, and specific instructions about how to upload each file and link it to
the device configuration object.

“Uploading and Linking Large Binary Data Files” on page 38

“Importing Custom Sign-In Pages” on page 39

“Importing Antivirus Liveupdate Settings” on page 40

“Importing Endpoint Security Assessment Plug-in (ESAP) Packages” on page 41

“Linking to a Third-Party Host Checker Policy Shared Object” on page 43

“Linking to a Secure Virtual Workspace Wallpaper Image Shared Object” on
page 43

“Importing Hosted Java Applets” on page 44

“Importing a Custom Citrix Client .cab File” on page 44
Uploading and Linking Large Binary Data Files
This topic describes the complete procedure for downloading a large binary data
file and linking that file into the Secure Access device configuration tree.
Subsequent sections provide details about each large binary data file.
To upload and link a large binary data file, follow these steps:
1. In the Device Manager, right-click the device icon and select Import Device
from the list to Import the Secure Access device configuration.
38

Using Network and Security Manager with the IVE
Chapter 2: Introduction to the IVE
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 device. 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 device.
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 device 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.
Importing Custom Sign-In Pages
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 device.
To create a link from a Secure Access configuration tree to a shared object
containing a custom sign-in access page, follow these steps:
1. In the Device Manager, double-click the Secure Access device to open the device
editor, and then select the Configuration tab.
Using Network and Security Manager with the IVE

39
Juniper Networks Secure Access Administration Guide
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 configuration tree to a shared object
containing a custom sign-in meeting page, follow these steps:
1. In the Device Manager, double-click the Secure Access device 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.
Importing Antivirus Liveupdate Settings
Retrieve the latest AV liveupdate file from the Juniper Downloads Web site.
Specifically, you can find this file at
https://download.juniper.net/software/av/uac/epupdate_hist.xml.
Retrieve the latest patch file from the Juniper Download Web site at
https://download.juniper.net/software/hc/patchdata/patchupdate.dat.
To create a link from a Secure Access device configuration tree to a shared object
containing an antivirus (AV) liveupdate file, follow these steps:
1. In the Device Manager, double-click the Secure Access device to open the device
editor, and then select the Configuration tab.
40

Using Network and Security Manager with the IVE
Chapter 2: Introduction to the IVE
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 configuration tree to a shared object
containing an AV patch liveupdate file, follow these steps:
1. In the Device Manager, double-click the Secure Access device 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.
Importing Endpoint Security Assessment Plug-in (ESAP) Packages
The Endpoint Security Assessment Plug-in (ESAP) on the Secure Access device
checks third-party applications on endpoints for compliance with the predefined
rules you configure in a Host Checker policy.
To upload the Endpoint Security Assessment Plug-in from the Juniper Networks
Customer Support Center to your NSM client computer, follow these steps:
1. Open the following page:
https://www.juniper.net/customers/csc/software/ive/
2. To access the Customer Support Center, enter a user name and password for a
Juniper Networks Support account.
3. Click the ESAP link.
4. Click the ESAP Download Page link.
5. Navigate to the ESAP release you want.
6. Upload the plug-in zip file to your computer.
To create a link from a Secure Access configuration tree to a shared object
containing an ESAP package, follow these steps:
1. In the Device Manager, double-click the Secure Access device to open the device
editor, and then select the Configuration tab.
Using Network and Security Manager with the IVE

41
Juniper Networks Secure Access Administration Guide
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
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. See the Secure Access Administration Guide or the Unified Access
Control Administration Guide for details about configuring host checker
restrictions.
If you want to verify that the package itself is installed and running on the
client computer (as opposed to a specific policy in the package passing or
failing) you can use the name you specified when you uploaded the policy
package (for example, myPestPatrol). To enforce a particular policy in the
package, use the syntax package-name.policy-name. For example, to enforce
the FileCheck policy in the myPestPatrol package, use myPestPatrol.FileCheck.
42

Using Network and Security Manager with the IVE
Chapter 2: Introduction to the IVE
Linking to a Third-Party Host Checker Policy Shared Object
To create a link from a Secure Access device configuration tree to a shared object
containing a third-party host checker policy, follow these steps:
1. In the Device Manager, double-click the Secure Access device 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.
Linking to a Secure Virtual Workspace Wallpaper Image Shared Object
To create a link from a Secure Access device configuration tree to a shared object
containing a secure virtual workspace wallpaper image:
1. In the Device Manager, double-click the Secure Access device 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.
Using Network and Security Manager with the IVE

43
Juniper Networks Secure Access Administration Guide
Importing Hosted Java Applets
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 device. For
example, you can upload the 3270 applet, 5250 applet, or Citrix Java applet to
shared NSM objects. These applets enable users to establish sessions to IBM
mainframes, AS/400s, and Citrix MetaFrame servers through terminal emulators. To
enable the Citrix Java ICA client through an IVE 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 device configuration tree to a shared object
containing a Java applet, follow these steps:
1. In the Device Manager, double-click the Secure Access device 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.
Importing a Custom Citrix Client .cab File
The custom Citrix client file enables you to provision the Citrix client from the
Secure Access device instead of requiring that it be pre-installed on end-user
machines or downloaded from some other web server.
44

Using Network and Security Manager with the IVE
Chapter 2: Introduction to the IVE
To create a link from a Secure Access device configuration tree to a shared object
containing a Custom Citrix .cab file, follow these steps:
1. In the Device Manager, double-click the Secure Access device to open the
device editor, and then select the Configuration tab.
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.
Using Network and Security Manager with the IVE

45
Juniper Networks Secure Access Administration Guide
46

Using Network and Security Manager with the IVE
Part 2
Access Management Framework
The IVE protects resources by using the following access management
mechanisms:

Authentication realms—Resource accessibility begins with the authentication
realm. An authentication realm specifies conditions that users must meet in
order to sign into the IVE. An authentication realm specification includes
several components, including an authentication server which verifies that the
user is who he claims to be. The user must meet the security requirements you
define for a realm's authentication policy or else the IVE does not forward the
user's credentials to the authentication server.

User roles—A role's configuration serves as the second level of resource access
control. A role is a defined entity that specifies IVE session properties for users
who are mapped to the role. 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.

Resource policies—A resource policy serves as the third level of resource
access control. 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. 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. Note that you can create separate
resource policies or you can create automatic resource policies (called
autopolicies) during resource profile configuration (recommended).

Authentication and Directory Servers—You can configure most authentication
and directory servers to work with the IVE to store user information and
provide authentication services. The IVE also contains a local authentication
server if you do not use an external authentication or directory server.

User realms—Authentication realms permit clients to request authentication
from the IVE. You map different roles to realms to determine which resources
users can access based on their successful authentication to a realm.
This section contains the following information about the IVE access management
framework:

“General Access Management” on page 49

“User Roles” on page 83

47
Juniper Networks Secure Access Administration Guide
48


“Resource Profiles” on page 103

“Resource Policies” on page 119

“Authentication and Directory Servers” on page 131

“Authentication Realms” on page 207

“Sign-In Policies” on page 223

“Single Sign-On” on page 235
Chapter 3
General Access Management
The IVE 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
IVE) 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 IVE, to gain access to IVE features, and even to access
specific URLs, files, and other server resources. The IVE 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 IVE to provision shared user sessions from any number of different SA
appliances and Infranet Controllers. IF-MAP Federation allows users to access
resources protected by any number of Juniper Networks Firewalls (Infranet
Enforcers) without requiring additional authentication.
This topic contains the following information about the access management
framework:

“Licensing: Access Management Availability” on page 50

“Policies, Rules & Restrictions, and Conditions Overview” on page 50

“Policies, Rules & Restrictions, and Conditions Evaluation” on page 53

“Dynamic Policy Evaluation” on page 55

“Configuring Security Requirements” on page 57

“Federation of User Sessions with IF-MAP” on page 66

49
Juniper Networks Secure Access Administration Guide
Licensing: Access Management Availability
The IVE access management framework is available on all Secure Access products.
The access management features, including realms, roles, resource policies, and
servers, are the base of the IVE platform on which all Secure Access products are
built.
Policies, Rules & Restrictions, and Conditions Overview
The IVE 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
IVE) down to a very granular level (controlling which authenticated users may
access a particular URL or file).
This section contains the following information about access management policies,
rules, restrictions, and conditions:

“Accessing Authentication Realms” on page 50

“Accessing User Roles” on page 51

“Accessing Resource Policies” on page 51
Accessing Authentication Realms
Resource accessibility begins with the authentication realm. An authentication realm
is a grouping of authentication resources, including:
50


An authentication server, which verifies that the user is who he claims to be.
The IVE forwards credentials that a user submits on a sign-in page to an
authentication server. For more information, see “Authentication and Directory
Servers” on page 131.

An authentication policy, which specifies realm security requirements that
need to be met before the IVE submits a user's credentials to an authentication
server for verification. For more information, see “Defining Authentication
Policies” on page 210.

A directory server, which is an LDAP server that provides user and group
information to the IVE that the IVE uses to map users to one or more user roles.
For more information, see “Authentication and Directory Servers” on page 131.

Role mapping rules, which are conditions a user must meet for the IVE 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.
For more information, see “Creating Role Mapping Rules” on page 211.
Licensing: Access Management Availability
Chapter 3: General Access Management
You can associate one or more authentication realms with an IVE 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 IVE
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
IVE 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
IVE forwards the user's credentials to the appropriate authentication server. If this
server successfully authenticates the user, then the IVE evaluates the role mapping
rules defined for the realm to determine which roles to assign to the user. See
“Authentication Realms” on page 207.
Accessing User Roles
A role is a defined entity that specifies IVE 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 these
security requirements or else the IVE does not map the user to a role.
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 IVE maps the user to the role. When a user makes a request to
the backend resources available to the role, the IVE 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 IVE evaluates the requirements
specified in both areas to make sure the user complies before it maps the user to a
role. See “User Roles” on page 83.
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 IVE does not process the user's request.
Policies, Rules & Restrictions, and Conditions Overview  51
Juniper Networks Secure Access Administration Guide
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 IVE
either denies or grants access to the requested resource. You may enable Web
access at the role level, for example, and a user mapped to the role may make a
Web request. You may also configure a Web resource policy to deny requests to a
particular URL or path when Host Checker finds an unacceptable file on the user's
machine. In this scenario, the IVE 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
IVE 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). For more information, see:
52


“Resource Profile Components” on page 104

“Resource Policies” on page 119
Policies, Rules & Restrictions, and Conditions Overview
Chapter 3: General Access Management
Policies, Rules & Restrictions, and Conditions Evaluation
The following diagram illustrates the access management security checks that the
IVE performs when a user tries to access resources through the IVE. A detailed
description of each step follows after the diagram.
Figure 18: Security checks performed by the IVE during a user session
1. The user enters the URL of the IVE end-user console (such as
http://employees.yourcompany.com/marketing) in a Web browser.
2. The IVE 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 IVE evaluates pre-authentication restrictions and determines if the user’s
system passes host checks and other requirements. If the pre-authentication
checks fail, the IVE denies the user access. If the checks pass, the IVE prompts
the user to enter the username and password for the realms whose preauthentication checks succeeded. (If required by the realm, the IVE 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.
Policies, Rules & Restrictions, and Conditions Evaluation  53
Juniper Networks Secure Access Administration Guide
4. The IVE evaluates the post-authentication restrictions and determines whether
the user’s password conforms to specified limits and requirements. If the postauthentication checks fail, the IVE denies the user access. If the checks pass,
the IVE passes the user’s credentials to the realm’s authentication server.
5. The IVE 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 IVE to use in role mapping.)
If the authentication server returns failure, the IVE denies the user access. If the
server returns success, the IVE stores the user’s credentials. If the realm has a
separate LDAP authorization server, the IVE 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 IVE repeats this
process with the secondary server.
6. The IVE evaluates the realm’s role mapping rules and determines the roles for
which the user is eligible. The IVE determines eligibility using information from
the LDAP or RADIUS server or the user’s username.
7. The IVE 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 IVE creates a “session role,” determining the user’s session permissions. If
you enable permissive merging, the IVE determines session permissions by
merging all valid roles and granting the allowed resources from each valid role.
If you disable merging, the IVE assigns the user to the first role to which he is
mapped. For more information, see “User Role Evaluation” on page 84.
9. When the user requests a resource, the IVE checks whether the corresponding
access feature is enabled for the session user role. If not, the IVE denies the
user access. If the access feature is enabled, the evaluates resource policies.
10. The IVE 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 IVE denies user access
to the resource if specified by the profile or policy. Otherwise, the IVE
intermediates the user request if the profile or policy enables access. For more
information, see “Resource Policy Evaluation” on page 124.
11. The IVE intermediates the user request, forwarding the user’s request and
credentials (if necessary) to the appropriate server. Then, the IVE 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 IVE may also force the user out if the session if you enable
dynamic policy evaluation and the user fails a policy. For more information,
see “Understanding Dynamic Policy Evaluation” on page 55.
NOTE: If you enable dynamic policy evaluation, the IVE performs additional
checks beyond the ones mentioned here. For more information, see
“Understanding Dynamic Policy Evaluation” on page 55.
54

Policies, Rules & Restrictions, and Conditions Evaluation
Chapter 3: General Access Management
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 IVE 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 IVE enables or denies the user access to the dependent realms, roles, or
resource policies accordingly.
NOTE: The IVE does not check for changes in user attributes from a RADIUS,
LDAP, or SiteMinder server when performing dynamic policy evaluation. Instead,
the IVE re-evaluates rules and policies based on the original user attributes that it
obtained when the user signed into the IVE.
This section contains the following information about dynamic policy evaluation:

“Understanding Dynamic Policy Evaluation” on page 55

“Understanding Standard Policy Evaluation” on page 56

“Enabling Dynamic Policy Evaluation” on page 56
Understanding Dynamic Policy Evaluation
During dynamic policy evaluation, the IVE evaluates the following types of resource
policies:

Windows Secure Application Manager

Java Secure Application Manager

Network Connect

Telnet/SSH

Terminal services (Windows and Citrix)

Java Access

Code signing (for java applet)
NOTE: Because the IVE 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 IVE does not use dynamic policy evaluation for Meetings
resource policies and Email Client resource policies.
Dynamic Policy Evaluation

55
Juniper Networks Secure Access Administration Guide
If the IVE determines after a dynamic policy evaluation that a user no longer meets
the security requirements of a policy or role, the IVE terminates the connection
immediately with the user. The user may see the closing of a TCP or application
connection, or the termination of a user session for Network Connect, Secure
Application Manager, Terminal or Telnet/SSH. The user must take the necessary
steps to meet the security requirements of the policy or role, and then sign into the
IVE again.
The IVE 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 IVE evaluates policies and roles
only when the following events occur:

When the user first tries to access the IVE sign-in page, the IVE evaluates the
Host Checker and Cache Cleaner policies (if any) for a realm.

Immediately after the user’s initial authentication, the IVE evaluates the user’s
realm restrictions in the authentication policy, role mapping rules, and role
restrictions.

Whenever the user makes a request for a resource, the IVE evaluates resource
policies.

Whenever the Host Checker and Cache Cleaner status of the user’s machine
changes, the IVE evaluates the Host Checker and Cache Cleaner policies (if any)
for a 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
IVE enforces those changes only when the events described above occur. See
“Policies, Rules & Restrictions, and Conditions Evaluation” on page 53
If you use dynamic policy evaluation, the IVE enforces changes when the events
described above occur, and it also enforces changes at the times you specify. For
more information, see “Enabling Dynamic Policy Evaluation” on page 56.
Enabling Dynamic Policy Evaluation
You can use dynamic policy evaluation in the following ways:

Evaluate all signed-in users in a realm—You can automatically or manually
refresh the roles of all currently signed-in users of a realm by using the General
tab of the Administrators > Admin Realms > Select Realm or Users > User
Realms > Select Realm page. You can trigger the IVE to perform a dynamic
policy evaluation at the realm level based on:

56

Dynamic Policy Evaluation
An automatic timer—You can specify a refresh interval that determines
how often the IVE 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 IVE 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.
Chapter 3: General Access Management

On-demand—At any time, you can manually evaluate the authentication
policy, role mapping rules, role restrictions, and resource policies of all
currently signed-in realm users. This technique is especially useful if you
make changes to an authentication policy, role mapping rules, role
restrictions, or resource policies and you want to immediately refresh the
roles of a realm’s users.

Evaluate all signed-in users in all realms—At any time, you can manually
refresh the roles of all currently signed-in users in all realms by using settings in
the System > Status >Active Users page. For information, see “Monitoring
Active Users” on page 821.

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 IVE to evaluate resource policies whenever a user’s Host Checker
status changes. (If you do not enable dynamic policy evaluation for Host
Checker, the IVE 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.) For more information, see “Specifying
General Host Checker Options” on page 325.
Configuring Security Requirements
You can specify additional security requirements on the IVE through the options
and features described in the following sections:

“Specifying Source IP Access Restrictions” on page 58

“Specifying Browser Access Restrictions” on page 59

“Specifying Certificate Access Restrictions” on page 62

“Specifying Password Access Restrictions” on page 63

“Specifying Host Checker Access Restrictions” on page 64

“Specifying Cache Cleaner Access Restrictions” on page 64
Configuring Security Requirements

57
Juniper Networks Secure Access Administration Guide
Specifying Source IP Access Restrictions
Use a source IP restriction at the role or the realm level to control from which IP
addresses users can access an IVE sign-in page, be mapped to a role, or access a
resource.
Use a source IP restriction to control from which IP addresses users can access an
IVE sign-in page, be mapped to a role, or access a resource.
You can restrict resource access by source IP:

When administrators or users try to sign in to the IVE —The user must sign
in from a machine whose IP address/netmask combination meets the specified
source IP requirements for the selected authentication realm. If the user's
machine does not have the IP address/netmask combination required by the
realm, the IVE does not forward the user's credentials to the authentication
server and the user is denied access to the IVE. You can allow or deny access to
any specific IP address/netmask combination. For example, you can deny
access to all users on a wireless network (10.64.4.100), and allow access to all
other network users (0.0.0.0).

When administrators or users are mapped to a role—The authenticated user
must be signed in from a machine whose IP address/netmask combination
meets the specified Source IP requirements for each role to which the IVE may
map the user. If the user's machine does not have the IP address/netmask
combination required by a role, then the IVE does not map the user to that role.

When users request a resource—The authenticated, authorized user must
make a resource request from a machine whose IP address/netmask
combination meets the specified Source IP requirements for the resource policy
corresponding to the user's request. If the user's machine does not have the
required IP address/netmask combination required by the resource, then the
IVE does not allow the user to access the resource.
To specify source IP restrictions:
1. Select the level at which you want to implement IP restrictions:


58

Configuring Security Requirements
Realm level—navigate to:

Administrators > Admin Realms > SelectRealm > Authentication
Policy > Source IP

Users > User Realms > SelectRealm > Authentication Policy >
Source IP
Role level—Navigate to:

Administrators > Admin Roles > Select Role > General >
Restrictions > Source IP

Users > User Roles > Select Role > General > Restrictions >
Source IP
Chapter 3: General Access Management

Resource policy level—Navigate to: Users > Resource Policies > Select
Resource > Select Policy > Detailed Rules > Select|CreateRule >
Condition Field
2. Choose one of the following options:

Allow users to sign in from any IP address — Enables users to sign into
the IVE from any IP address in order to satisfy the access management
requirement.

Allow or deny users from the following IP addresses — Specifies
whether to allow or deny users access to the IVE from all of the listed IP
addresses, based on their settings. To specify access from an IP address:
i.
Enter the IP address and netmask.
ii.
Select either:

Allow to allow users to sign in from the specified IP address.

Deny to prevent users from signing in from the specified IP address.
iii. Click Add.
iv. If you add multiple IP addresses, move the highest priority restrictions
to the top of the list by selecting the check box next to the IP address,
and then clicking the up arrow button. For example, to deny access to
all users on a wireless network (10.64.4.100) and allow access to all
other network users (0.0.0.0), move the 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.

Enable administrators to sign in on the external port — Enables
administrators to sign in to the IVE from the external interface. You must
enable the external port before setting this option.
3. Click Save Changes to save your settings.
Specifying Browser Access Restrictions
Use a browser restriction to control from which Web browsers users can access an
IVE sign-in page, be mapped to a role, or access a resource. If a user tries to sign in
to the IVE 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 IVE from browsers that are
compatible with corporate applications or are approved by corporate security
policies.
Configuring Security Requirements

59
Juniper Networks Secure Access Administration Guide
You can restrict IVE and resource access by browser-type:

When administrators or users try to sign in to the IVE—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 IVE submits the user's
credentials to the authentication server. If the realm “denies” the browser's
user-agent string, then the IVE 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 IVE may map
the user. If the user-agent string does not meet the “allowed” or “denied”
requirements for a role, then the IVE 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 IVE does not allow
the user to access the resource.
NOTE: 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.
Specifying Browser Restrictions
To specify browser restrictions:
1. Select the level at which you want to implement browser restrictions:


60

Configuring Security Requirements
Realm level—Navigate to:

Administrators > Admin Realms > Select Realm > Authentication
Policy > Browser

Users > User Realms > Select Realm > Authentication Policy >
Browser
Role level—Navigate to:

Administrators > Admin Realms > Select Realm > Role Mapping >
Select|Create Rule > Custom Expressions

Administrators > Admin Roles > Select Role > General >
Restrictions > Browser

Users > User Realms > Select Realm > Role Mapping >
Select|Create Rule > Custom Expression
Chapter 3: General Access Management


Users > User Roles > Select Role > General > Restrictions >
Browser
Resource policy level—Navigate to: Users > Resource Policies > Select
Resource > Select Policy > Detailed Rules > Select|Create Rule >
Condition Field
2. Choose one of the following options:

Allow all users matching any user-agent string sent by the browser—
Allows users to access the IVE 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:
i.
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.
ii.
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.
iii. Click Add.
3. Click Save Changes to save your settings.
NOTE:

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
Configuring Security Requirements

61
Juniper Networks Secure Access Administration Guide
*MSIE 5.5*Allow
*MSIE 6.*Allow
* Deny
Specifying Certificate Access Restrictions
When you install a client-side certificate on the IVE through the System >
Configuration > Certificates > Trusted Client CAs page of the admin console,
you can restrict IVE and resource access by requiring client-side certificates:

When administrators or users try to sign in to the IVE—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 IVE determines that the user's browser does not possess the
certificate, the IVE does not submit the user's credentials to the authentication
server and the user cannot access features on the IVE.
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 IVE may map
the user. If the user's machine does not possess the certificate information
required by a role, then the IVE does not map the user to that role.
To implement certificate restrictions at the role level, navigate to:

62

Configuring Security Requirements

Administrators > Admin Roles > SelectRole > General > Restrictions
> Certificate

Users > User Realms > SelectRealm > 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 IVE does not allow the user to
access the resource.
Chapter 3: General Access Management
To implement certificate restrictions at the resource policy level, navigate to:
Users > Resource Policies > SelectResource > SelectPolicy > Detailed Rules
> Select|CreateRule > ConditionField
Specifying Password Access Restrictions
You can restrict IVE and resource access by password-length when administrators
or users try to sign in to an IVE. 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 IVE 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 IVE.

Only allow users that have passwords of a minimum length — Requires
the user to enter a password with a minimum length of the number
specified.
3. Select Enable Password Management if you want to enable password
management. You must also configure password management on the IVE
authentication server configuration page (local authentication server) or
through an LDAP server. For more information about password management,
see “Enabling LDAP Password Management” on page 151.
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.
NOTE: By default, the IVE 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 IVE local
authentication database, for example, requires user passwords to be a minimum
length of six characters.
Configuring Security Requirements

63
Juniper Networks Secure Access Administration Guide
Specifying Host Checker Access Restrictions
For information about restricting a user’s access to the IVE, a role, or a resource
based on Host Checker status, see “Implementing Host Checker Policies” on
page 311.
Specifying Cache Cleaner Access Restrictions
For information about restricting a user’s access to the IVE, a role, or a resource
based on his Cache Cleaner status, see “Implementing Cache Cleaner Options” on
page 345.
Specifying Limits Restrictions
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 IVE presents the sign-in page to the user.
Use limits restrictions to set minimum and maximum concurrent users on the
realm.
To specify the limits restrictions:
1. Select an administrator or user realm for which you want to implement limits
restrictions.
Navigate to:

Administrators > Admin Realms > SelectRealm > Authentication
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:
a.
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.
b.
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.
64

Configuring Security Requirements
Chapter 3: General Access Management
Figure 19: IF-MAP Overview
Configuring Security Requirements

65
Juniper Networks Secure Access Administration Guide
Federation of User Sessions with IF-MAP
This section describes the interoperation between heterogeneous network
appliances in a federated network. In a federated network, users who provide valid
credentials can access resources protected by any number of Juniper Networks
Security Devices without re-authenticating through a different device. Juniper
Networks Intrusion Detection and Prevention (IDP) devices can be incorporated
into a federated network to protect against attacks within the network.
To use IF-MAP Federation, you will need to coordinate with Unified Access Control
(UAC) Infranet Controller administrators.
This section includes the following topics:

“IF-MAP Federation Overview” on page 66

“IF-MAP Federation Details” on page 69

“IF-MAP Logging” on page 72

“Configuring IF-MAP Federation” on page 72

“IF-MAP Servers” on page 72

“Configuring IF-MAP Client Settings” on page 73

“IF--MAP Federation Network Timing Considerations” on page 73

“Session-Export and Session-Import Policies” on page 74

“Default Session-Export and Session-Import Policy Action” on page 76

“Configuring Session-Export Policies” on page 76

“Session-Import Policies” on page 78

“Troubleshooting the IF-MAP Federation Network” on page 79

“Viewing Active Users on the IF-MAP Client” on page 79
IF-MAP Federation Licensing
IF-MAP Federation is available on all SA appliances with version 6.4 or greater. No
licensing is required.
IF-MAP Federation Overview
You can configure a Juniper Networks Unified Access Control (UAC) Infranet
Controller to store user session information for other Infranet Controllers and SA
appliances. Federation allows users to authenticate to a single SA appliance or
Infranet Controller, and then access resources that are protected by any number of
Juniper Networks firewall devices known as Infranet Enforcers that are controlled
by different Infranet Controllers. Federation enhances network performance. If a
66

Federation of User Sessions with IF-MAP
Chapter 3: General Access Management
user is required to login to multiple SA appliances or Infranet Controllers during the
course of a day to access different resources, each device must perform
authentication and Host-Checking, often with periodic Host Checker updates
throughout the day. The overhead can lead to decreased performance not only on
the devices, but also on the network and the endpoint. Imported IF-MAP sessions
eliminate redundant logins and Host Checks.
Federation on the IVE uses the standard IF-MAP (Interface for Metadata Access
Point) protocol to share session information and other data between connected
devices over distributed networks. IF-MAP is a protocol defined by the Trusted
Network Connect Working Group (TNC-WG) as a standard interface between
different network elements and devices. Federation is accomplished using an IFMAP server and IF-MAP clients.
It is important as an administrator to understand the fundamental underlying
communication method for data transmission in a Federation network over IF-MAP.
Policies that you configure on the SA appliance permit this communication.
In a federated network, the IF-MAP server functions as the repository, or data store
for IF-MAP clients to use for publishing information regarding activity on the
network. For example, SA appliance IF-MAP clients can publish information about
sessions on the network, and Juniper Networks IDP devices can communicate
information about potential threats to the IF-MAP client for publishing. IF-MAP
clients can search for information about sessions or threats, and an IF-MAP client
can establish a subscription so the IF-MAP server notifies the client when other
clients publish new or changed information. In addition, IF-MAP clients can purge
data that is no longer valid. All transactions are initiated by the IF-MAP client. “IFMAP Overview” on page 68 shows a simple IF-MAP transaction. Not all of the steps
for IF-MAP Federation are shown.
IF-MAP Federation does is not supported for non-root IVS on the SA Appliance.
Federation of User Sessions with IF-MAP

67
Juniper Networks Secure Access Administration Guide
Figure 20: IF-MAP Overview
1. The endpoint authenticates through the IF-MAP client (an SA appliance). The IFMAP client publishes session information to the IF-MAP server.
2. The endpoint attempts to access protected resources that are behind the
Infranet Enforcer.
3. The Infranet Enforcer notifies the Infranet Controller (also an IF-MAP client).
The IF-MAP client searches for session information on the IF-MAP server.
4. The Infranet Controller subscribes to session information about the endpoint’s
IP address.
5. The Infranet Controller notifies the Infranet Enforcer that session information
exists for the IP address attempting to access resources, and the Infranet
Enforcer provisions an auth table entry.
6. Access is granted to the protected resources. If any session information about
the user changes, the authenticating IF-MAP client publishes the new
information. Having subscribed to the user’s session information, the Infranet
Controller will be aware of any changes and provision access in accordance
with the changed session information.
For details about configuring the SA appliance to work in an IF-MAP Federated
network with the Infranet Controller, see the Unified Access Control Administrator’s
Guide.
68

Federation of User Sessions with IF-MAP
Chapter 3: General Access Management
IF-MAP Federation Workflow
Configuring an IF-MAP federated network requires coordination between
administrators of the different devices that will be in the federated network.
This document describes IF-MAP deployments that include only Juniper Networks
devices: Infranet Controllers, SA appliances, Infranet Enforcer firewalls, and Juniper
Networks IDP. For implementations that incorporate third-party components,
contact Juniper Networks Technical Support.
The mix of devices in the federated network is important when planning the
network. Will your network consist of only Infranet Controllers, or will you
incorporate SA appliances? Do the devices in your network have similar role
mapping policies, or is each device different?
Determine and understand your goals for the federated network. The big picture
guides your implementation as it becomes more complex. Juniper Networks
recommends that you begin slowly. For example, start with a single role on each
device, and then build the network incrementally.
In the simplest model, you can use the default policies. Using this model, you can
quickly establish a federated network, and session information will automatically
be shared among distributed devices in the network. This simple model should be
adequate for most implementations in which the devices in the federated network
have identical or very similar role mapping policies.
If your configuration requires more complex policies, you will need to perform a
number of tasks to achieve your intended results. The following guidelines will help
you plan your workflow:

Ensure that communications between IF-MAP servers and IF-MAP clients is
established

Determine the resources that will be shared among the different devices

Define who can access specific resources

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
You can configure the SA appliance as an IF-MAP client for an IF-MAP server. You
configure an Infranet Controller as an IF-MAP server. Any endpoint sessions with an
IP address created on an IF-MAP server are automatically published to that IF-MAP
server.
Federation of User Sessions with IF-MAP

69
Juniper Networks Secure Access Administration Guide
You can create source IP policies for endpoints that authenticate to an SA appliance
to permit access to resources behind Infranet Enforcers (ScreenOS Enforcers and
JUNOS Enforcers). Session-Export policies that you configure on the IF-MAP clients
allow the clients to publish endpoint user data to the IF-MAP server. SA appliances
that are IF-MAP clients can subscribe to the information on an IF-MAP server.
When a user accesses an SA appliance that is configured as an IF-MAP client, the
client publishes basic session information, including the IP address, user name and
roles, to the IF-MAP server. The server stores the information as metadata. Other IFMAP clients in the network can poll the server for metadata when session
information is needed as a result of an endpoint attempting to access protected
resources behind an Infranet Enforcer.
When an authenticated user from an SA appliance that is configured as an IF-MAP
client attempts to access resources that are protected by an Infranet Enforcer for an
Infranet Controller that is also configured as an IF-MAP client, the Infranet
Controller automatically provisions an auth table entry for the user on the Infranet
Enforcer to allow access without requiring the user to authenticate to the Infranet
Controller.
The Infranet Enforcer as an IF-MAP client subscribes to session information and
other data for the endpoint based on the originating IP address. The authenticating
SA appliance (the original IF-MAP client) publishes any changes in session
parameters to the IF-MAP server. Since the Infranet Controller that is protecting the
accessed resources subscribes to the metadata on the Federation server, session
information is always current.
The Infranet Enforcer allows or denies traffic based on the resource access policies
that are configured on the Infranet Controller to which it is connected.
You configure server settings on the Infranet Controller that will be the IF-MAP
server. You configure client settings on each of the SA appliances and Infranet
Controllers and that will be connected in the network.
In addition to the server and client settings, you configure Session-Export policies
on SA appliances and Infranet Controllers that are IF-MAP clients You configure and
Session-Import policies on Infranet Controller IF-MAP clients that are connected to
Infranet Enforcers.
IF-MAP allows servers and clients to publish, search, poll, and subscribe to data
within a network of IF-MAP servers and clients. All of the data from the IVEs and SA
appliances in the network that is published to the IF-MAP server uses the IF-MAP
protocol. Session-Export and Session-Import polices that you configure on the SA
appliance and Infranet Controller allow the devices to utilize the IF-MAP protocol to
share session information.
Session-Export policies specify how to translate an endpoint’s session on the IVE or
the SA appliance into IF-MAP data. To translate session information into IF-MAP
data, you enter detailed user information. The IVE or the SA appliance evaluates the
Export policies to determine a session’s IF-MAP roles, capabilities, identities, and
device attributes and publishes the data to the IF-MAP server.
70

Federation of User Sessions with IF-MAP
Chapter 3: General Access Management
The Session-Import policies that you configure on the IVE 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 IVEs or SA appliances. Import policies are
similar to Role Mapping policies on a realm. You must be precise when configuring
Export and Import policies, otherwise roles cannot be assigned properly.
“Federation IF-MAP Topology” on page 71 depicts a scenario in which there are two
IVEs configured as IF-MAP clients, one SA appliance configured as a IF-MAP client,
and another IVE 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 IVE 1.
Figure 21: Federation IF-MAP Topology
The interaction between the endpoints, the clients and the server is as follows:

An endpoint authenticates through the SA appliance depicted in the figure and
starts Network Connect.

The SA appliance provisions an IP address for the endpoint to use on the
internal network. Once the endpoint’s IP address on the internal network is
known, the SA appliance derives IF-MAP data from the endpoint’s session.

The SA appliance IF-MAP client publishes the session information as IF-MAP
data to the IF-MAP server using Session-Export policies.

When the user attempts to access resources behind the enforcement point,
access is blocked since the Infranet Enforcer has no information about the
endpoint. The Infranet Enforcer sends out a dynamic discovery message that
includes the endpoint’s source IP address.

IVE 1 uses the IP address to retrieve session data from the IF-MAP server.
Federation of User Sessions with IF-MAP

71
Juniper Networks Secure Access Administration Guide

The IVE uses Session-Import policies to retrieve session data from the IF-MAP
server.
The endpoint authenticating to the SA appliance must be running Network
Connect.
Imported user sessions do not count against the maximum user count for either
platform, as each user is counted on the SA appliance from which they
authenticated.
For details on configuring an IF-MAP Federation network see the Unified Access
Control Administrator’s Guide.
IF-MAP Logging
IF-MAP related events are logged on both the IF-MAP server and the IF-MAP client.
Configuring IF-MAP Federation
The tasks listed in this section are performed by an Infranet Controller
administrator, in conjunction with an administrator for the SA appliance. On the SA
appliance, you configure Session-Export policies and you configure IF-MAP client
settings. For details on configuring an IF-MAP Federation network see the Unified
Access Control Administrator’s Guide.
To use IF-MAP Federation, perform the following tasks on the Infranet Controller
and SA appliance:
1. Enable dynamic auth table provisioning on any connected Infranet Enforcers
that you want to use with Federation.
2. On the Infranet Controller, configure IF-MAP server settings to permit the
server to communicate with IF-MAP clients.
3. Configure IF-MAP client settings to permit clients to communicate with the IFMAP server.
4. On the Infranet Controller and SA appliance, coordinate Session-Import
policies, Session-Export policies, roles, and resource access policies between all
of the clients in the Federated network.
5. Configure Session-Export policies on IVEs and SA appliances to define how
sessions are translated into IF-MAP data.
6. Configure Session-Import policies on IVEs that correspond with Export policies
to translate IF-MAP data into IVE roles.
7. On the Infranet Controller, configure Source IP policies for SA appliance users
who will use Source IP to access the network.
IF-MAP Servers
You must add all IF-MAP Clients to the IVE IF-MAP server. To add clients, you must
specify the IP address and the security mechanism and credentials for the client.
72

Federation of User Sessions with IF-MAP
Chapter 3: General Access Management
For details on configuring an IF-MAP Server see the Unified Access Control
Administrator’s Guide.
Configuring IF-MAP Client Settings
You must identify the IF-MAP server to each SA appliance IF-MAP client. To add the
server, you specify the IF-MAP URL of the server and how to authenticate to the
server. Match the URL and security settings to equal those on the IF-MAP server(s)
to which the IF-MAP client will connect.
To configure IF-MAP client settings on the SA appliances that will be IF-MAP clients:
1. From the admin console select System > IF-MAP Federation > Overview.
2. Select the Enable IF-MAP Client option button.
3. Type the Server URL for IF-MAP Web service on the IF-MAP server. Append the
server URL with /dana-ws/soap/dsifmap for all Juniper Networks IF-MAP
servers.
4. Select the Client Authentication Method: Basic or Certificate.
a.
If you select Basic, enter a Username and Password. This is the same as the
information that was entered on the IF-MAP server.
b.
If you select Certificate, select the Device Certificate to use.
c.
Ensure that the certificate of the CA that signed the IF-MAP server
certificate is added from the System > Configuration > Certificates >
Trusted Server CA page.
The IF-MAP client validates the IF-MAP server certificate: if validation fails,
the connection fails. Ensure that the hostname in the IF-MAP URL on the
client machine matches the hostname of the server certificate on the IFMAP server, and that the CA that signed the server certificate is configured
as a trusted server CA on the IF-MAP client.
5. Click Save Changes.
IF--MAP Federation Network Timing Considerations
It is important that the time on all IF-MAP servers is correct, as timeout issues are
critical to ensure that IF-MAP provides complete and timely information. The IFMAP Federation is designed to fail secure. If any component in the network does
not receive timely information, the IF-MAP metadata will be purged from the data
stores.
The components are designed to fail-secure. If complete and timely information can
not be provided, a user’s session will be deleted. For example, if the chain of
connections between an IF-MAP client that publishes a session and a client that
grants access to a resource breaks, the client that granted access will remove the
session. The fail-secure time limit is three minutes.
The timeout limit for IF-MAP is three minutes and applies to the following events:
Federation of User Sessions with IF-MAP

73
Juniper Networks Secure Access Administration Guide

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
Session-Export and Session-Import Policies
You configure Session-Export policies on all of the SA appliances and Infranet
Controllers in the Federation network that are IF-MAP clients. These policies allow
IF-MAP clients to translate outgoing session information into IF-MAP data and
incoming IF-MAP data into session information. These translations enable sessions
to be shared between SA appliances and Infranet Controllers even if the devices
sharing sessions have different role configurations.
To accurately configure Session-Export and Session-Import policies you need a
minimal understanding of IF-MAP identifiers and IF-MAP metadata. An identifier is
a unique value required for all metadata operations. Each instance of metadata is
associated with an identifier. Examples of identifiers include access-request, identity,
IP address, and MAC address. Examples of metadata include capability, role, and
device-attribute.
IF-MAP recognizes two metadata types that are similar to roles on the IVE and SA
appliance: IF-MAP roles and IF-MAP capabilities. An IF-MAP role is an attribute
assigned to a user in the organization. When IF-MAP metadata is published to the
IF-MAP server, this information could be one way to identify individuals on the
network. This is somewhat different from the concept of roles on the SA appliance.
An IF-MAP capability is closer to the concept of a role on the SA appliance. An IFMAP capability is a collection of privileges assigned as a result of an access request.
This is more analogous to an SA appliance role since they are derived through role
mapping in an authentication realm.
The data that is published to the IF-MAP server about a user session is derived by
applying the Session-Export policies to the user session. The Session-Import
policies are applied to the data from the IF-MAP server to assign a set of roles to the
user.
When an endpoint attempts to access protected resources associated with an IVE,
the device queries the IF-MAP server for data. The Infranet Controller uses SessionImport policies to derive roles and a user name from the IF-MAP data. For example,
you could configure a Session-Import policy that looks for a specific Host Checker
policy (you specify the Host Checker policy in the Session-Import policy). If the
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. “Session-Import and SessionExport Policies” on page 75 illustrates a coordinated IF-MAP Federated network
configuration with policies that permit an example user to access protected
resources.
74

Federation of User Sessions with IF-MAP
Chapter 3: General Access Management
Figure 22: 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:

An SA appliance maps to the identical IF-MAP username.

A role on an SA appliance is paired with an IF-MAP capability.

Capabilities can have the same name as the roles they are paired with, or a
different name.

When different IF-MAP clients have different but equivalent role names (e.g.
Legal and Law, both referring to members of the corporate legal department) a
single IF-MAP capability must be chosen.

Not every role needs to be paired with an IF-MAP capability: roles can be local
to an SA appliance.

After you decide on pairings between IF-MAP capabilities and the roles on the
SA appliance or IVE, you create a session export policy for each pairing. On an
Infranet Controller that controls Infranet Enforcers, you create a session import
policy.

The only parameters for the policies are the SA appliance roles and the IF-MAP
capability; everything else is fixed.
Federation of User Sessions with IF-MAP

75
Juniper Networks Secure Access Administration Guide
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 IVE or SA appliance roles) to be
published to the IF-MAP server and retrieved from the IF-MAP server, provided
there are matching roles on each IF-MAP client. You can open new Session-Import
and Session-Export policies on each device, and then name and close the policies.
Any matching roles that the IF-MAP clients in the federated network have can be
used to access resources.
Advanced Session-Export and Session-Import Policies
By default, advanced policy actions are not visible unless you click the advanced
options links on the Session-Export and Session-Import policy pages. In default
mode, you configure Session-Export and Session-Import policies using IF-MAP
capabilities and IVE roles.
Device attributes, IF-MAP roles and identities can be accessed through the
advanced options links. IF-MAP capabilities and IVE roles should provide the
functionality that most IVE and SA Appliance IF-MAP Federation requires.
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 IVEs. 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 IVEs to identify which roles the user
should be assigned. You configure Session-Export policies based on IVE or SA
Appliance roles, and users belonging to those roles can access resources on an
Infranet Enforcer only if the role can be successfully matched with a role on the
target IVE.
You configure Session-Export policies on all IVEs and SA appliances for which you
have users that will be allowed to access resources behind an Infranet Enforcer in
the network.
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 IVE 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 IVE
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).
76

Federation of User Sessions with IF-MAP
Chapter 3: General Access Management
A DHCP server assigns an IP address to the endpoint after authentication. An IFMAP enabled DHCP server publishes an ip-mac link to IF-MAP, associating the
endpoint’s IP address with its IF-MAP session information.
Including administrative domains in MAC addresses allows the ip-mac link to be
created based on the administrative domain.
If your IF-MAP Federated network spans different administrative domains, you
should configure separate Session-Export policies for each domain to prevent MAC
address spoofing. Each administrative domain should have an associated DHCP
server and unique Session-Export policies.
Other aspects of the Session-Export policies within the IF-MAP Federated network
can overlap.
To configure a Session-Export policy:
1. From the admin console select System > IF-MAP > Session-Export Policies.
2. Click New to create a new policy.
3. Type a Policy Name, and optionally a Description.
4. Optionally, add Available Roles to the Selected Roles column 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 capabilities data.

Set capabilities specified below—Enter capabilities, one per line.
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 IVE and SA Appliance IFMAP Federation):
1. Select the View Advanced Actions link. Additional options appear on the page.
Federation of User Sessions with IF-MAP

77
Juniper Networks Secure Access Administration Guide
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. See “Administrative Domains In SessionExport Policies” on page 76.
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
roles data.

Copy all Roles—Selecting this action copies all of the roles from the user
session to the IF-MAP capabilities data.

Set roles specified below—Enter roles, one per line.
5. Set IF-MAP Device Attributes—Device attributes represent a passed Host
Checker policy on the IVE or SA appliance.

Copy Host Checker policy names. The name of each Host Checker policy
that passed for the session is copied to a device attribute.

Set Device Attributes. Type Device Attributes, one per line, into the text
box.
6. Select Save Changes to save this advanced Session-Export policy.
You must create corresponding Session-Import policies that allow IF-MAP client
IVEs that are connected to an Infranet Enforcer in front of protected resources to
collect IF-MAP data from the IF-MAP server.
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 server. Session-Import policies establish rules for importing user
sessions from an SA appliance. Import policies allow you to match authenticated
users with corresponding roles on the target device. For example, you might
configure an Import policy to specify that when IF-MAP data for a session includes
the “Contractor” capability, the imported session should have the “limited” role.
Session-Import policies allow the Infranet Controller to properly assign roles based
on information that the IF-MAP server provides.
78

Federation of User Sessions with IF-MAP
Chapter 3: General Access Management
You configure Session-Import policies on IF-MAP client IVEs that are connected to
an Infranet Enforcer in front of protected resources. For information about
configuring Session-Import policies, see the Unified Access Control Administrator’s
Guide.
Troubleshooting the IF-MAP Federation Network
Diagnostic tools on the IVE and SA appliance can assist you with troubleshooting a
federated network.
IF-MAP Client User Messages—On the IF-MAP client, logs information that is
published and removed from the IF-MAP server.

Enable IF-MAP Client User Messages from Log/Monitoring > User Access >
Settings on the IVE and SA appliance IF-MAP client.
IF-MAP Server Trace—On the IF-MAP server, logs the XML for all IF-MAP requests
and responses.

Enable the IF-MAP Server Trace from Log/Monitoring > Events > Settings on
the IF-MAP server.
IF-MAP Server Trace should only be enabled for troubleshooting purposes, as
running this diagnostic incurs a large performance impact.
Viewing Active Users on the IF-MAP Client
On an IF-MAP client, you can view all of the exported sessions to an Infranet
Controller. Session information that can be viewed includes the username, roles,
the user’s endpoint IP address, and the IP address of the SA appliance that
authenticated the user. You can select and remove sessions either temporarily or
permanently. A temporarily removed session can be restored in response to a
request for continued access. A permanently removed session cannot be restored.
To view, de-activate, or activate exported sessions on an IF-MAP client:
1. Select System > IF-MAP Federation > Active Users Exported from the IFMAP client admin console.
2. Select Imported or Exported.
3. Select Activate or De-activate.
Trusted Server List
The IVE 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:
Federation of User Sessions with IF-MAP

79
Juniper Networks Secure Access Administration Guide

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 IVE 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 an IVE or not.
When the user makes a decision to trust an IVE, the IVE 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: Network Connect GINA does not support the white list feature. However,
other applications such as Network Connect stand-alone launch, command-line
nclauncher and wsamlauncher do support it.
Admin and User Configuration
The following is a snippet of a whitelist file:
qa.juniper.net
dev1.juniper.net
66.129.224.48
NOTE: whitelist files are not deleted when the IVE software is removed.
There are two modes of enforcement:

80

Allow Admin List Only—When software launches from an IVE 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 IVE is in the administrator
whitelist, the launch proceeds as requested.
Federation of User Sessions with IF-MAP
Chapter 3: General Access Management

Prompt—When software launches from an IVE 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 IVE 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 IVE
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.
User Experience
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,
a.
If the origin site is listed in the whitelist, proceed with the launch.
b.
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,
Federation of User Sessions with IF-MAP

81
Juniper Networks Secure Access Administration Guide
a.
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
a.
If they select Always then add the server to user whitelist file
b.
Proceed with the launch
6. Abort the launch
82

Federation of User Sessions with IF-MAP
Chapter 4
User Roles
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 IVE supports two types of user roles:

Administrators—An administrator role specifies IVE management functions
and session properties for administrators who map to the role. You can
customize an administrator role by selecting the IVE 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 IVE access features, defining Web, application, and
session 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.
This topic includes the following information about roles:

“Licensing: User Roles Availability” on page 84

“User Role Evaluation” on page 84

“Configuring User Roles” on page 86

“Customizing UI Views for User Roles” on page 99

83
Juniper Networks Secure Access Administration Guide
Licensing: User Roles Availability
User roles are an integral part of the IVE access management framework, and
therefore are available on all Secure Access 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 IVE’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 23: Security Checks Performed by the IVE to Create a Session Role
The IVE performs the following security checks to create a session role:
1. The IVE 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 IVE determines if the user meets the rule conditions. If so, then:
84

Licensing: User Roles Availability
a.
The IVE adds the corresponding roles to a list of “eligible roles” available to
the user.
b.
The IVE considers whether or not the “stop on match” feature is
configured. If so, then the engine jumps to step 5.
Chapter 4: User Roles
2. The IVE evaluates the next rule on the authentication realm’s Role Mapping tab
according to the process in Step 1and repeats this process for each subsequent
rule. When the IVE evaluates all role mapping rules, it compiles a
comprehensive list of eligible roles.
3. The IVE evaluates the definition for each role in the eligibility list to determine
if the user complies with any role restrictions. The IVE 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 IVE assigns the user to
that role. Otherwise, the IVE continues the evaluation process.
4. The IVE 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
IVE 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 IVE presents a list of eligible roles to an authenticated user. The
user must select a role from the list, and the IVE 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 IVE 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 IVE performs a permissive
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 IVE repeats the role evaluation process
described in this section. See “Understanding Dynamic Policy Evaluation” on
page 55.
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 Secure Meeting while the other role enables Secure Meeting, the
IVE allows the user to use Secure Meeting for that session.

In the case of Secure Application Manager, the IVE enables the version
corresponding to the first role that enables this feature. Furthermore, the IVE
merges the settings from all the roles that correspond to the selected version.

In the case of user interface options, the IVE applies the settings that
correspond to the user’s first role.
User Role Evaluation

85
Juniper Networks Secure Access Administration Guide

In the case of session timeouts, the IVE applies the greatest value from all of
the roles to the user’s session.

If more than one role enables the Roaming Session feature, then the IVE
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.
Configuring 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:
86

Configuring User Roles

“Configuring General Role Options” on page 87

“Configuring Role Restrictions” on page 88

“Specifying Role-Based Source IP Aliases” on page 89

“Specifying Session Options” on page 89

“Specifying UI Options” on page 92

“Defining Default Options for User Roles” on page 97
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 IVE 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 IVE 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). See “Creating User Accounts
on a Local Authentication Server” on page 157. Or for instructions on how to
create users on third-party servers, see the documentation that comes with
that product.
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. If you do not select role-specific options, the IVE uses default settings
instead, as described in “Defining Default Options for User Roles” on page 97.
Role-specific options include:

VLAN/Source IP—Select this option to apply the role settings configured on
the General > VLAN/Source IP page. See “Specifying Role-Based Source IP
Aliases” on page 89.

Session Options—Select this option to apply the role settings in the
General > Session Options page to the role. See “Specifying Session
Options” on page 89.

UI Options—Select this option to apply the role settings in the General >
UI Options page to the role. See “Specifying UI Options” on page 92.
4. Under Access features, check the features you want to enable for the role.
Options include:

Web—See “Web Rewriting” on page 389

Files (Windows or UNIX/NFS version)—See “File Rewriting” on page 465
Configuring User Roles

87
Juniper Networks Secure Access Administration Guide

Secure Application Manager (Windows version or Java version)—See
“Secure Application Manager” on page 489

Telnet/SSH—See “Telnet/SSH” on page 543

Terminal Services—See “Terminal Services” on page 555

Meetings—See “Secure Meeting” on page 605

Email Client—See “Email Client” on page 629

Network Connect—See “Network Connect” on page 637
5. Click Save Changes to apply the settings to the role.
Configuring Role Restrictions
Click Restrictions at the top of the General tab to specify access management
options for the role. The IVE considers these restrictions when determining
whether or not to map a user to the role. The IVE does not map users to this role
unless they meet the specified restrictions. See “General Access Management” on
page 49.
You may configure any number of access management options for the role. If a
user does not conform to all of the restrictions, then the IVE 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 using instructions in the following sections:
88

Configuring User Roles

“Specifying Source IP Access Restrictions” on page 58

“Specifying Browser Access Restrictions” on page 59

“Specifying Certificate Access Restrictions” on page 62

“Specifying Password Access Restrictions” on page 63

“Specifying Host Checker Access Restrictions” on page 64

“Specifying Cache Cleaner Access Restrictions” on page 64
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. For more information on virtual ports, see “Configuring Internal and
External Ports” on page 689 and “Configuring Virtual Ports” on page 695.
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 IVE merges roles, the IVE
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.
Specifying Session Options
Click Session Options at the top of the General tab to specify session time limits,
roaming capabilities, session and password persistency, request follow-through
options, and idle timeout application activity. Select the Session Options check box
on the Overview tab to enable these settings for the role.
Configuring User Roles

89
Juniper Networks Secure Access Administration Guide
To specify general session options:
1. In the admin console, click Users > User Roles > RoleName > General >
Session Options.
2. Under Session lifetime, specify:

Idle Timeout—Specify the number of minutes a non-administrative user
session may remain idle before ending. The minimum is five minutes. The
default idle session limit is 10 minutes, which means that if a user’s session
is inactive for 10 minutes, the IVE ends the user session and logs the event
in the system log (unless you enable session timeout warnings described
later).

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 IVE 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 IVE prompts the user to reenter
authentication credentials, which avoids the problem of terminating the
user session without warning.

Reminder Time—Specify when the IVE should prompt non-administrative
users, warning them of an impending session or idle timeout. Specify in
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.
NOTE: If you are using Secure Meeting, you can configure meeting session limits
by clicking Users > Resource Policies > Meetings in the admin console. See
“Configuring System-Level Meeting Settings” on page 623.
3. Under Enable session timeout warning:
a.
Enabled—Select 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, an IVE user may unknowingly reach the idle timeout set for
his role while using an e-mail client configured to work with the IVE,
because the IVE does not receive data while the user composes e-mail. If
the session timeout warning is enabled, however, IVE prompts the user to
reactivate his IVE session before the session times out and forces the user’s
IVE session to end. This warning gives the user the opportunity to save his
partially composed e-mail.
90

Configuring User Roles
Chapter 4: User Roles
b.
Display sign-in page on max session time out—Select this option if you
want 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 IVE only
displays expiration messages to users—it does not give them the option to
extend their sessions. Instead, users need to access the IVE sign-in page and
authenticate into a new session.

The Enable session timeout warning option only applies to expiration
messages displayed by the end user's browser, not by other clients such as
WSAM or Network Connect.
4. Under Roaming session, specify:

Enabled—Select this option to enable roaming user sessions for users
mapped to this role. A roaming user session works across source IP
addresses, which allows mobile users (laptop users) with dynamic IP
addresses to sign in to the IVE 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.

Limit to subnet—Select this option to limit the roaming session to the local
subnet specified in the Netmask box. Users may sign in from one IP
address and continue using their sessions with another IP address as long
as the new IP address is within the same subnet.

Disabled—Select this option to disable roaming user sessions for users
mapped to this role. Users who sign in from one IP address may not
continue an active IVE session from another IP address; user sessions are
tied to the initial source IP address.
5. Under Persistent session, select Enabled to write the IVE session cookie to the
client hard disk so that the user’s IVE credentials are saved for the duration of
the IVE session.
By default, the IVE session cookie is flushed from the browser’s memory when
the browser is closed. The IVE session length is determined by both the idle
timeout value and maximum session length value that you specify for the role.
The IVE session does not terminate when a user closes the browser; an IVE
session only terminates when a user signs out of the IVE.
Configuring User Roles

91
Juniper Networks Secure Access Administration Guide
NOTE: If you enable the Persistent session option and a user closes the browser
window without signing out, any user may open another instance of the same
browser to access the IVE 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 IVE credentials and that you
make sure these users understand the importance of signing out of the IVE when
they are finished.
6. Under Persistent password caching, select Enabled to allow cached passwords
to persist across sessions for a role.
The IVE supports the NT LAN Manager (NTLM) authentication protocol and
HTTP Basic Authentication and supports servers that are set up to accept both
NTLM and anonymous sign-in. The IVE 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 IVE
server or another resource in the NT domain. By default, the IVE server 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 IVE,
click Preferences and then click the Advanced tab.
7. Under Browser request follow-through, select Enabled to allow the IVE to
complete a user request made after an expired user session after the user reauthenticates.
8. Under Idle timeout application activity, select Enabled to ignore activities
initiated by Web applications (such as polling for e-mails) when determining
whether a session is active. If you disable this option, periodic pinging or other
application activity may prevent an idle timeout.
9. Under Upload Logs, select the Enable Upload Logs option to allow the user to
transmit (upload) client logs to the IVE.
NOTE: Click System > Log/Monitoring > Client Logs > Settings page to
completely enable client-side logs for the user. See “Enabling Client-Side Logs” on
page 814.
10. Click Save Changes to apply the settings to the role.
Specifying UI Options
Click UI Options at the top of the General tab to specify customized settings for the
IVE welcome page and the browsing toolbar for users mapped to this role. The IVE
welcome page (or home page) is the Web interface presented to authenticated IVE
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 IVE uses the default
settings.
92

Configuring User Roles
Chapter 4: User Roles
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 IVE displays the user interface corresponding to the first role to which
a user is mapped.
To customize the IVE welcome page for role users:
1. Click Users > User Roles > Role Name > General > UI Options.
2. Under Header, specify a custom logo and alternate background color for the
header area of the IVE welcome page (optional):

Click the Browse button and locate your custom image file. The new logo
appears in the Current appearance box only after you save your changes.
NOTE: You can only specify a JPEG or GIF file for a custom logo image. Other
graphics formats are not displayed properly in the JSAM status window on some
OS platforms.

Type the hexidecimal number for the background color or click the Color
Palette icon and pick the desired color. The Current appearance box
updates immediately.
3. Under Sub-headers, select new background and text colors (optional):

Type the hexidecimal number for the Background color or click the Color
Palette icon and pick the desired color. The Current appearance box
updates immediately.

Type the hexidecimal number for the Text color or click the Color Palette
icon and pick the desired color. The Current appearance box updates
immediately.
4. Under Start page, specify the start page that you want users to see after they
sign in and when they click the Home icon on the toolbar:

Bookmarks page—Select this option to display the standard IVE
Bookmarks page.

Meetings page—Select this option to display the standard IVE meetings
page.

Custom page—Select this option to display a custom start page and then
specify the URL to the page. The IVE 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 IVE Browse field on the toolbar.) The IVE
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/.
Configuring User Roles

93
Juniper Networks Secure Access Administration Guide
5. Under Bookmarks Panel Arrangement, arrange the panels as you want to
display them on the user's bookmarks page:
a.
To select the name of a panel, click in the Left Column or Right Column
list.
b.
To position a panel above or below the other panels, click Move Up or
Move Down.
c.
To move a panel to the other side of the user's bookmarks page, click
Move > or < Move.
NOTE: The IVE displays all panels under Bookmarks Panel Arrangement for all
licensed features regardless of whether or not you enable the corresponding
feature for the role.
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 IVE
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 IVE 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 IVE Browse field on the
toolbar.) The IVE 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 IVE 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 IVE Bookmarks page
and other secure gateway pages on the IVE:
94

Configuring User Roles

Home—Select this option to display the Home icon on the IVE Bookmarks
page and other secure gateway pages on the IVE.

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.
Chapter 4: User Roles

Client Application Sessions—Select this option to display the Client Apps
button on the user toolbar. Users can click this button to display the Client
Application Sessions page where they can start client applications such as
Network Connect or Secure Application Manager. If you do not select this
option, the IVE displays the Client Application Sessions panel on the IVE
Bookmarks page.
8. Under Browsing toolbar, select options for the toolbar that users see when
browsing pages not located on the IVE, 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 IVE intermediates the page, top might reference a
different frame than you intend. This change might make the framed toolbar
disappear or could cause your intermediated application to work erratically or
incorrectly. See the Content Intermediation Engine Best Practices guide located on
the Juniper Networks website.

Toolbar logo and Toolbar logo (mobile)—Specify a custom logo (such as
your company’s logo) that you want to display on the standard and framed
toolbars by browsing to the image file (optional). When the user clicks the
logo, the page you specify for the Logo links to option appears. The
current logo for the browsing toolbar appears next to these options.

Logo links to— Select an option to link the browsing toolbar logo to a page
that appears when users click the logo:

Bookmarks page—Links the logo to the IVE 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 IVE. The
IVE 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 IVE Browse field on the toolbar.) The IVE evaluates the access
control rule after all other policies, which means another policy could
deny access to the URL.
Configuring User Roles

95
Juniper Networks Secure Access Administration Guide


Also allow access to directories below this url—Select this option to
allow users access to subdirectories of the custom URL.
Specify the items you want to display in the browsing toolbar:

Enable "Home" link—Select this option to display the Home Page
button, which is linked to the IVE 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 IVE
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 IVE 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 IVE Bookmarks page (optional):
96

Configuring User Roles

Enabled—Select this option to display the personalized greeting. The IVE
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 IVE
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 IVE 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 IVE system variables and attributes in this field, as explained
in “Using System Variables in Realms, Roles, and Resource Policies” on
page 1027.
Chapter 4: User Roles
NOTE:

The length of the personalized greeting cannot exceed 12K, or 12288
characters.

If you use unsupported HTML tags in your custom message, the IVE may
display the end user’s IVE home page incorrectly.
10. Under Other, specify whether or not you want the copyright notice and label
shown in the footer (optional). This setting applies only to those users whose
license permits disabling the copyright notice. For more information about this
feature, call Juniper Networks Support.
11. Click Save Changes. The changes take effect immediately, but current user
browser sessions may need to be refreshed to see the changes.
12. Click Restore Factory Defaults to reset all user-interface options back to
factory defaults (optional).
Defining Default Options for User Roles
You can define default options for all user roles, just as you can for delegated
administrator roles. The default options include, but are not limited to:


Session Options

Session lifetime—Define the idle timeout, maximum session length, and
reminder time in minutes.

Enable session timeout warning—Determine if warning and login page
display.

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 IVE response to application
session activity.
UI Options

Header—Define the logo and background color.

Sub-headers—Define the background and text color.

Start page—Define which page appears after the user logs in.
Configuring User Roles

97
Juniper Networks Secure Access Administration Guide

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.

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
using instructions in “Configuring General Role Options” on page 87 and
“Customizing Messages” on page 98.
4. Click Save Changes. These become the new defaults for all new user roles.
NOTE: 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.
Customizing Messages
You can customize three basic messages that may be displayed to your end users
when they sign in to the IVE. 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. The Roles page appears.
2. Click Default Options.
3. Select the Custom Messages tab.
4. Select the language you want to use from the menu.
5. Enter your text in the Custom Message box, below the default message you
want to override.
98

Configuring User Roles
Chapter 4: User Roles
6. Click Save Changes.
7. Repeat the process to create messages in additional languages.
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. Table 3 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 3: 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 Secure Meeting settings that you have configured for the
specified roles. Also displays links you can use to access the
corresponding Secure Meeting configuration pages.
Network Connect
Displays Network Connect settings that you have configured for
the specified roles. Also displays links you can use to access the
corresponding Network Connect configuration pages.
Role Mapping Rule &
Realms
Displays the assigned authentication realms, role mapping rule
conditions, and permissive merge settings for the specified
roles.Also displays links you can use to access the corresponding
realm and role mapping configuration pages.
Customizing UI Views for User Roles

99
Juniper Networks Secure Access Administration Guide
Table 3: View Menu Options (Continued)
100

Option
Description
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.
Customizing UI Views for User Roles
Chapter 4: User Roles
Table 3: View Menu Options (Continued)
Option
Description
ACL Resource Policies:
SAM
Displays the JSAM and WSAM resource policies that are associated
with the specified roles. Includes the type, name, description,
action, and resources for each policy. Also displays links you can
use to access the corresponding policy configuration pages.
ACL Resource Policies:
Telnet
Displays the Telnet/SSH resource policies that are associated with
the specified roles. Includes the type, name, description, action,
and resources for each policy. Also displays links you can use to
access the corresponding policy configuration pages.
ACL Resource Policies:
Terminal Services
Displays the Terminal Services resource policies that are associated
with the specified roles. Includes the type, name, description,
action, and resources for each policy. Also displays links you can
use to access the corresponding policy configuration pages.
ACL Resource Policies:
Network Connect
Displays the Network Connect resource policies that are associated
with the specified roles. Includes the type, name, description,
action, and resources for each policy. Also displays links you can
use to access the corresponding policy configuration pages.
Resource Profiles: All
Displays the resource profiles that are associated with the specified
roles. Includes the type, name, bookmarks, and supporting policies
for each profile. Also displays links you can use to access the
corresponding resource profile configuration pages.
Resource Profiles: Web
Applications
Displays the Web application resource profiles that are associated
with the specified roles. Includes the name, bookmarks, and
supporting policies for each profile. Also displays links you can use
to access the corresponding resource profile configuration pages.
Resource Profiles: Web
Hosted Java Applets
Displays the hosted Java applet resource profiles that are
associated with the specified roles. Includes the name, bookmarks,
and supporting policies for each profile. Also displays links you can
use to access the corresponding resource profile configuration
pages.
Resource Profiles: Files
(Windows)
Displays the Windows file resource profiles that are associated
with the specified roles. Includes the name, bookmarks, and
supporting policies for each profile. Also displays links you can use
to access the corresponding resource profile configuration pages.
Resource Profiles: Files
(UNIX)
Displays the UNIX file resource profiles that are associated with the
specified roles. Includes the name, bookmarks, and supporting
policies for each profile. Also displays links you can use to access
the corresponding resource profile configuration pages.
Resource Profiles: SAM
Client Applications
Displays the JSAM and WSAM application resource profiles that are
associated with the specified roles. Includes the name, bookmarks,
and supporting policies for each profile. Also displays links you can
use to access the corresponding resource profile configuration
pages.
Resource Profiles: SAM
WSAM destinations
Displays the WSAM destination resource profiles that are
associated with the specified roles. Includes the name, bookmarks,
and supporting policies for each profile. Also displays links you can
use to access the corresponding resource profile configuration
pages.
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.
Customizing UI Views for User Roles

101
Juniper Networks Secure Access Administration Guide
Table 3: View Menu Options (Continued)
102

Option
Description
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.
Customizing UI Views for User Roles
Chapter 5
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 IVE 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 IVE pre-populates a variety of
values for you based on your chosen application and prompts you to configure
additional settings as necessary.
NOTE: For administrators who are accustomed to using a pre-5.3 version of the IVE
product, note that you can still use the IVE role and resource policy framework to
create bookmarks and associated policies. We recommend that you use resource
profiles instead, however, since they provide a simpler, more unified configuration
structure.
This section contains the following information about resource profiles:

“Licensing: Resource Profile Availability” on page 104

“Task Summary: Configuring Resource Profiles” on page 104

“Resource Profile Components” on page 104

“Resource Profile Templates” on page 111

103
Juniper Networks Secure Access Administration Guide
Licensing: Resource Profile Availability
Resource profiles are an integral part of the IVE access management framework,
and therefore are available on all Secure Access products. However, you can only
access resource profile types that correspond to your licensed features. For instance,
if you are using an SA-700 appliance and have not purchased a Core Clientless
Access upgrade license, you cannot create Web resource profiles.
Task Summary: Configuring Resource Profiles
To create resource profiles, you must:
1. Create user roles through the Users > User Roles page of the admin console.
For instructions, see “Configuring User Roles” on page 86.
2. 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. For more information, see “Resource Profile Components” on
page 104.
Resource Profile Components
Resource profiles contain the following components:
104


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. For more information, see “Defining Resources” on page 107.

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 IVE handles the
data that it passes to and from the specified resource. For more information,
see “Defining Autopolicies” on page 108.

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. For more
information, see “Defining Roles” on page 109.
Licensing: Resource Profile Availability
Chapter 5: Resource Profiles

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 IVE displays these bookmarks to users who are
assigned to the user roles that you specify. For more information, see “Defining
Bookmarks” on page 110.
The following diagrams illustrate how resource profiles simplify the configuration of
individual resources.
The first 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.
The second 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 IVE automatically enables the appropriate access mechanism to the
roles to which you assign the bookmark.
Resource Profile Components

105
Juniper Networks Secure Access Administration Guide
Figure 24: Using Roles and Resource Policies to Configure Resources
106

Resource Profile Components
Chapter 5: Resource Profiles
Figure 25: Using Resource Profiles to Configure Resources
Defining Resources
When you are defining a resource profile, you must specify the individual resource
that you want to configure. The type of profile that you choose is dependent on the
type of resource you want to configure, as described in the following table:
Table 4: Resource Profile Types and Configuration Information
Use this type of resource To configure this type of
profile:
resource:
For configuration instructions,
see:
Web application/pages
URLs to Web applications, “Defining Resource Profiles: Custom
Web servers, and Web
Web Applications” on page 397
pages; Java applets that are
stored on third party
servers
Hosted java applet
Java applets that you
upload directly to the IVE
“Hosted Java Applets Templates” on
page 353
File browsing
Windows and UNIX/NFS
servers, shares, and file
paths
“Defining Resource Profiles: File
Rewriting” on page 465
SAM client application
Client/server applications
“Defining Resource Profiles: WSAM”
on page 495 and “Defining Resource
Profiles: JSAM” on page 529
WSAM destination
Destination networks or
servers
“Defining Resource Profiles: WSAM”
on page 495
Telnet/SSH
Telnet or SSH servers
“Defining Resource Profiles:
Telnet/SSH” on page 544
Resource Profile Components

107
Juniper Networks Secure Access Administration Guide
Table 4: Resource Profile Types and Configuration Information
Use this type of resource To configure this type of
profile:
resource:
For configuration instructions,
see:
Terminal Services
“Defining Resource Profiles: Terminal
Services Overview” on page 561
Windows and Citrix
terminal servers
NOTE: You cannot configure applications through Network Connect using resource profiles.
Instead, you must use roles and resource policies. For more information, see “Network Connect”
on page 637.
When defining resources, you can use IVE 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.
Defining 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 IVE handles the data that it passes to and from the specified
resource.
When creating resource profiles, the IVE 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
IVE displays autopolicies that you can use to enable access to the specified
application’s server. On the other hand, the IVE does not display Java access control
autopolicies, since Java settings do not apply to WSAM.
108

Resource Profile Components
Chapter 5: Resource Profiles
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 IVE network settings.
Additionally, the IVE 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.
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 IVE 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 IVE
product, note that autopolicies are resource policies. The IVE allows you to
sort and order autopolicies along with standard resource policies in the Users
> Resource Policies pages of the admin console. However, the IVE 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 IVE
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 IVE creates policies for both and displays them in the appropriate resource
policies page of the admin console.)
Defining 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.
Resource Profile Components

109
Juniper Networks Secure Access Administration Guide
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 IVE automatically enables it for
you.
NOTE: Note that you can assign roles to a resource profile through the IVE role
framework as well as the resource profile framework.
Defining Bookmarks
When you create a resource profile, the IVE generally creates a bookmark that links
to the profile’s primary resource1 (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 IVE enduser console.
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 IVE 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:

“Sales Intranet” bookmark: Creates a link to the http://intranet.com/sales
page and displays the link to members of the Sales role.
1. WSAM and JSAM resource profiles do not include bookmarks, since the IVE cannot launch the applications
specified in the resource profiles.
110

Resource Profile Components
Chapter 5: Resource Profiles

“Engineering Intranet” bookmark: Creates a link to the
http://intranet.com/engineering page and displays the link to members of the
Engineering role.
NOTE: When configuring bookmarks, note that:

You can only assign bookmarks to roles that you have already associated with
the resource profile—not all of the roles defined on the IVE. To change the list
of roles associated with the resource profile, use settings in its Roles tab.

Bookmarks simply control which links the IVE 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 IVE allows you to create multiple bookmarks to the same resource. If you
assign duplicate bookmarks to the same user role, however, the IVE 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 IVE updates the corresponding bookmarks accordingly.
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 IVE pre-populates a variety of values for you
based on your chosen application and prompts you to configure additional settings
as necessary.
Currently, the IVE includes templates for the following third-party applications:



Citrix—For more information, see:

“Citrix Templates” on page 369

“Defining Resource Profiles: WSAM” on page 495

“Defining Resource Profiles: JSAM” on page 529.
Lotus Notes—For more information, see:

“Lotus iNotes Templates” on page 379

“Defining Resource Profiles: WSAM” on page 495

“Defining Resource Profiles: JSAM” on page 529.
Microsoft Outlook—For more information, see:
Resource Profile Templates

111
Juniper Networks Secure Access Administration Guide
112

Resource Profile Templates

“Microsoft OWA Templates” on page 383

“Defining Resource Profiles: WSAM” on page 495

“Defining Resource Profiles: JSAM” on page 529.

Microsoft Sharepoint—For more information, see “Microsoft Sharepoint
Templates” on page 387.

NetBIOS file browsing—For more information, see:

“Defining Resource Profiles: WSAM” on page 495

“Defining Resource Profiles: JSAM” on page 529.
Chapter 6
Virtual Desktop Resource Profiles
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:

SSO so 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 Profile
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.
Configuring a Citrix XenDesktop Resource Profile

113
Juniper Networks Secure Access Administration Guide
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 Server checkbox 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 IVE 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.
13. Click Save Changes.
14. (Optional.) In the Bookmarks tab, modify the default bookmark created by the
IVE and/or create new ones using instructions in “Defining Bookmarks for a
Virtual Desktop Profile” on page 116.
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.
114

Configuring a VMware View Manager Resource Profile
Chapter 6: Virtual Desktop Resource Profiles
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 Server checkbox 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.
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
IVE and/or create new ones using instructions in “Defining Bookmarks for a
Virtual Desktop Profile” on page 116.
Configuring a VMware View Manager Resource Profile

115
Juniper Networks Secure Access Administration Guide
Defining Bookmarks for a Virtual Desktop Profile
When you create a virtual desktop resource profile, the IVE automatically creates a
bookmark that links to the server that you specified in the resource profile. The IVE
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 IVE 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 IVE 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.
(XenDesktop) Under Preferred Client, you can select Automatic Detection,
Citrix Client or Java. If you select Automatic Detection, the IVE 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.
See “Defining Display Options for the Windows Terminal Services Session” on
page 568.
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. See “Defining Device Connections for the
Windows Terminal Services Session” on page 570.
(VMware) Enable MMR—Redirect certain multimedia codecs running on the
remote desktop to the local client for rendering of full-motion video and audio.
116

Defining Bookmarks for a Virtual Desktop Profile
Chapter 6: Virtual Desktop Resource Profiles
(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. See
“Defining Desktop Settings for the Windows Terminal Services Session” on
page 571.
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.
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.
1. Choose System > Configuration> Virtual Desktop.
2. Select Download from the IVE to download the client file from the IVE. 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.
Connecting to the Servers
When an end-user clicks a desktop icon, the IVE passes credentials to the server
based on the desktop profile.
Configuring the Client Delivery

117
Juniper Networks Secure Access Administration Guide
For XenDesktop, the IVE 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 IVE 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 IVE 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 IVE 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 the IVE 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.
118

Connecting to the Servers
Chapter 7
Resource Policies
A resource policy is a system rule that specifies resources and actions for a particular
access feature. A resource is either a server or file that can be accessed through an
IVE appliance, and an action is to “allow” or “deny” a resource or to perform or not
perform a function. Each access feature has one or more types of policies, which
determine the IVE appliance’s response to a user request or how to enable an
access feature (in the case of Email Client). You may also define detailed rules for a
resource policy, which enable you to evaluate additional requirements for specific
user requests.
You can create the following types of resource policies through the Resource
Policies pages of the IVE:

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 IVE should use to sign
java applets, resources that the IVE should and should not rewrite, applications
for which the IVE 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.

Telnet/SSH Resource Policies—The Telnet/SSH resource policies allow or deny
access to the specified servers.

Terminal Services Policies—The Terminal Services resource policies allow or
deny access to the specified Windows servers or Citrix Metaframe servers.

Network Connect Resource Policies—The Network Connect resource policies
allow or deny access to the specified servers and specify IP address pools.

Secure Email Client Resource Policies—The Secure Email Client access
resource policy allows you to enable or disable email client support. To allow
end-users to open and save email attachments of different document types in
OWA and iNotes, select the OWA or iNotes type when defining a Web
Application Resource Profile.

119
Juniper Networks Secure Access Administration Guide
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.” For more information, see “Resource Profiles” on page 103.
This section provides the following information:

“Licensing: Resource Policies Availability” on page 120

“Resource Policy Components” on page 120

“Resource Policy Evaluation” on page 124

“Creating Detailed Rules for Resource Policies” on page 125

“Customizing Resource Policy UI Views” on page 128
Licensing: Resource Policies Availability
Resource policies are an integral part of the IVE access management framework,
and therefore are available on all Secure Access products. However, you can only
access resource policy types that correspond to your licensed features. For
instance, if you are using an SA-700 appliance and have not purchased a Core
Clientless Access upgrade license, you cannot create Web resource policy.
Resource Policy Components
A resource policy contains the following information:
120


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. For more information, see “Specifying
Resources for a Resource Policy” on page 121.

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 an IVE 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.
Licensing: Resource Policies Availability
Chapter 7: Resource Policies

Detailed Rules: An optional list of elements that specifies resource details
(such as a specific URL, directory path, file, or file type) to which you want to
apply a different action or for which you want to evaluate conditions before
applying the action. You can define one or more rules and specify the order in
which the IVE evaluates them. For more information, see “Creating Detailed
Rules for Resource Policies” on page 125.
Specifying Resources for a Resource Policy
The IVE platform’s engine that evaluates resource policies requires that the
resources listed in a policy’s Resources list follow a canonical format. This section
describes the canonical formats available for specifying Web, file, and server
resources. When a user tries to access a specific resource, an IVE appliance
compares the requested resource to the resources specified in the corresponding
policies, starting with the first policy in a policy list. When the engine matches a
requested resource to a resource specified in a policy’s Resources list, it then
evaluates further policy constraints and returns the appropriate action to the
appliance (no further policies are evaluated). If no policy applies, then the appliance
evaluates the auto-allow bookmarks (if defined); otherwise the default action for the
policy is returned.
NOTE: You may not see the auto-allow option, if you are using a new installation,
if you use resource profiles rather than resource policies, or if an administrator
has hidden the option. For more information on this option, see “Setting System
Options” on page 704.
General Notes About the 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 Network Connect resource policy.
You can only specify an IP address.
Resource Policy Components

121
Juniper Networks Secure Access Administration Guide

If a host name is not fully qualified in the hosts file, such as “juniper” instead of
“intranet.juniper.net”, and you are accessing a host name using the short
name, then the engine performs the resource matching against the short name.
If, however, the short name is not in the hosts file and the host name resolution
is done by DNS (by adding the domains listed in the Networks configuration
page), then the fully qualified domain name (FQDN) is used for resource
matching. In other words, for web resource policies a DNS lookup of the short
name is performed. The result of the DNS lookup is a FQDN; the engine
matches the FQDN with the ones entered in the UI.
Specifying Server Resources
When specifying server resources for Telnet/SSH, Terminal Services, or Network
Connect resource policies, note the following guidelines.
Canonical format: [protocol://] host [:ports]
The components are:

Protocol (optional)—Possible case-insensitive values:

tcp

udp

icmp
If the protocol is missing, then all protocols are assumed. If a protocol is
specified, then the delimiter “://” is required. No special characters are
allowed.
NOTE: Available only to Network Connect policies. For other access feature
resource policies, such as Secure Application Manager and Telnet/SSH, it is invalid
to specify this component.

Host (required)—Possible values:

IP address/Netmask—The IP address needs to be in the format: a.b.c.d
The netmask may be in one of two formats:

Prefix: High order bits

IP: a.b.c.d
For example: 10.11.149.2/24 or 10.11.149.2/255.255.255.0
No special characters are allowed.

122

Resource Policy Components
DNS Hostname—For example: www.juniper.com
Chapter 7: Resource Policies
Special characters allowed include:
Table 5: DNS Hostname Special Characters
*
Matches ALL characters
%
Matches any character except dot (.)
?
Matches exactly one character
NOTE: You cannot specify a host name for a Network Connect resource policy.
You can only specify an IP address.

Ports (optional)—Possible values:
Table 6: 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 [165535]. Do not enter a space between port numbers. You can
specify up to 15 ports.
[port1]-[port2]
A range of ports, from port1 to port2, inclusive.
NOTE: You may mix port lists and port ranges, such as: 80,443,8080-8090, except
for in Network Connect where mixing of port lists and port ranges is not
supported.
If the port is missing, then the default port 80 is assigned for http, 443 for https.
For Network Connect, if the port is missing then the default port http is *. If a
port is specified, then the delimiter “:” is required. For example:
<username>.danastreet.net:5901-5910
tcp://10.10.149.149:22,23
tcp://10.11.0.10:80
udp://10.11.0.10:*
Resource Policy Components

123
Juniper Networks Secure Access Administration Guide
Resource Policy Evaluation
When an IVE appliance receives a user request, it evaluates the resource policies
corresponding to the type of request. When it processes the policy that corresponds
to the requested resource, it applies the specified action to the request. This action
is defined on the policy’s General tab or Detailed Rules tab. For example, if a user
requests a Web page, the IVE knows to use the Web resource policies. In the case of
Web requests, the IVE 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 IVE then evaluates
the Web Access policies until it finds one that pertains to the requested resource.
An IVE appliance evaluates a set of resource policies for an access feature from the
top down, meaning that it starts with the policy numbered one and then continues
down the policy list until it finds a matching policy. If you defined detailed rules for
the matching policy, the IVE evaluates the rules from the top down, starting with the
rule numbered one and stopping when it finds a matching resource in the rule’s
Resource list. The following diagram illustrates the general steps of policy
evaluation:
Figure 26: Resource Policy Evaluation Steps
Details regarding each evaluation step:
1. The IVE 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. (For more
information, see “User Role Evaluation” on page 84.)
124

Resource Policy Evaluation
Chapter 7: Resource Policies
2. The IVE determines which policies match the request. The IVE 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 IVE using resource profiles, the IVE 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 IVE
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 IVE evaluates and executes the rules specified in the matching policies. You
can configure policy rules to do two things:

Specify resources to which an action applies at a more granular level. For
example, if you specify a Web server in the main policy settings for a Web
Access resource policy, you can define a detailed rule that specifies a
particular path on this server and then change the action for this path.

Require the user to meet specific conditions written as boolean
expressions or custom expressions in order to apply the action. for more
information, see “Creating Detailed Rules for Resource Policies” on
page 125).
4. The IVE 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 IVE repeats the resource evaluation
process described in this section. For more information, see “Dynamic Policy
Evaluation” on page 55.
Creating Detailed Rules for Resource Policies
The Web, file, Secure Application Manager, Telnet/SSH, and Network Connect
access features enable you to specify resource policies for individual Web, file,
application, and telnet servers. The Email Client access features have one policy
that applies globally. For this policies, you specify server settings that are used for
every role that enables these access features. For all other access features, you can
specify any number of resource polices, and for each, you can define one or more
detailed rules.
A detailed rule is a an extension of a resource policy that may specify:

Additional1 resource information—such as a specific path, directory, file, or file
type—for resources listed on the General tab.
1. 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.
Creating Detailed Rules for Resource Policies

125
Juniper Networks Secure Access Administration Guide

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

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.
Writing a Detailed Rule
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:
a.
126

In the Action section, specify:

Disable SSO—The IVE disables automatic SSO authentication for this
user role and, instead, prompts the user for sign-in credentials.

Basic—This option specifies that the IVE use the Basic Authentication
Intermediation method to control SSO behavior.
Creating Detailed Rules for Resource Policies
Chapter 7: Resource Policies
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. For more information, see “Defining the Basic, NTLM
and Kerberos Resources” on page 426.
Disable Intermediation—When you select this option, The IVE does
not intermediate the challenge/response sequence.
NOTE:

The IVE 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 IVE use the Microsoft NTLM
Intermediation method to control SSO behavior.
Select the credentials to use. If this pull-down menu is blank, no NTLM
SSO settings are defined in the SSO General tab. For more information,
see “Defining the Basic, NTLM and Kerberos Resources” on page 426.
Select the Fallback to NTLM V1 option to try both NTLM V1 and NTLM
V2. If you do not select this option, the IVE falls back only to NTLM V2.
An intermediation page appear if SSO fails.

Kerberos—This option specifies that the IVE 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. For more
information, see “Defining the Basic, NTLM and Kerberos Resources”
on page 426.
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 IVE 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.
For more information, see “Defining the Basic, NTLM and Kerberos
Resources” on page 426.
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.
Creating Detailed Rules for Resource Policies

127
Juniper Networks Secure Access Administration Guide
b.
c.
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. See
“System Variables and Examples” on page 1018 for a list of variables
available in resource policies.

Custom expressions: Using the custom expression syntax, write one or
more custom expressions. See “Custom Expressions” on page 1013 for
syntax and variable information.
NOTE: You can use the <USER> substitution variable in ACLs for web pages, telnet,
files, and SAM. You cannot use the variable in Network Connect ACLs.
d. Click Save Changes.
5. On the Detailed Rules tab, order the rules according to how you want the IVE
to evaluate them. Keep in mind that once the IVE 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).
Customizing Resource Policy UI Views
You can limit which resource policies the IVE 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 IVE 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 IVE displays resource policies that are assigned to the
selected roles.
128

Customizing Resource Policy UI Views
Chapter 7: Resource Policies
Customizing Resource Policy UI Views

129
Juniper Networks Secure Access Administration Guide
130

Customizing Resource Policy UI Views
Chapter 8
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 IVE, the
user specifies an authentication realm, which is associated with an authentication
server. If the user meets the realm’s authentication policy, the IVE 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 IVE and, if the
realm also uses the server as a directory/attribute server, the user’s group
information or other user attribute information. The IVE then evaluates the realm’s
role mapping rules to determine to which user roles the user may be mapped.
The Juniper Networks Instant Virtual Extranet platform 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 IVE. For server
overview and configuration information, see “Authentication and Directory Servers”
on page 131.
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
IVE supports LDAP servers for this purpose, which means you can use an LDAP
server for both authentication and authorization. You simply need to define one
server instance, and then the LDAP server’s instance name appears in both the
Authentication and Directory/Attribute drop-down lists on a realm’s General tab.
You can use the same server for any number of realms.
In addition to LDAP, you can use a RADIUS or SiteMinder server for retrieving user
attributes that can be used in role mapping rules. Unlike an LDAP server instance,
however, a RADIUS or SiteMinder server instance name does not appear in a
realm’s Directory/Attribute 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 IVE provides in an attribute list on the Role Mapping
Rule page after you select Rule based on User attribute.
.This section contains the following information about authentication and directory
servers:

“Licensing: Authentication Server Availability” on page 132

131
Juniper Networks Secure Access Administration Guide

“Task Summary: Configuring Authentication Servers” on page 132

“Defining an Authentication Server Instance” on page 133

“Configuring an Anonymous Server Instance” on page 134

“Configuring an ACE/Server Instance” on page 136

“Configuring an Active Directory or NT Domain Instance” on page 139

“Configuring a Certificate Server Instance” on page 145

“Configuring an LDAP Server Instance” on page 147

“Configuring a Local Authentication Server Instance” on page 155

“Configuring an NIS Server Instance” on page 159

“Configuring a RADIUS Server Instance” on page 160

“Configuring an eTrust SiteMinder Server Instance” on page 174

“Configuring a SAML Server Instance” on page 198
Licensing: Authentication Server Availability
Authentication servers are an integral part of the IVE access management
framework, and therefore available on all Secure Access products. Note, however,
that the eTrust Siteminder server is not available on the SA 700 appliance.
Task Summary: Configuring Authentication Servers
To specify an authentication server that a realm may use, you must first configure a
server instance on the Authentication > Auth. Servers page. When you save the
server’s settings, the server name (the name assigned to the instance) appears on
the realm’s General tab in the Authentication drop-down list. If the server is a(n):

LDAP or Active Directory server—The instance name also appears in the
Directory/Attribute drop-down list on the realm’s General tab. You may use
the same LDAP or Active Directory server for both authentication and
authorization for a realm, as well as use these servers for authorization for any
number of realms that use different authentication servers.

RADIUS server—The instance name also appears in the Accounting dropdown list on the realm’s General tab. You may use the same RADIUS server for
both authentication and accounting for a realm, as well as use these servers for
accounting for any number of realms that use different authentication servers.
To configure authentication servers:
1. Set up your authentication/authorization server using instructions from the
provider.
132

Licensing: Authentication Server Availability
Chapter 8: Authentication and Directory Servers
2. Create an instance of the server starting at the Authentication >
Authentication > Auth. Servers page in the admin console.
3. Create an authentication realm using settings in the Users > User Realms or
Administrators > Admin Realms page of the admin console. For instructions,
see “Creating an Authentication Realm” on page 208.
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. For instructions, see “Creating User Accounts on a Local
Authentication Server” on page 157.
5. Password management only: set up password management options using
instructions in “Enabling LDAP Password Management” on page 151.
NOTE: An authentication server must be able to contact the IVE. 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 IVE host name,
either through a DNS entry or an entry in the authentication server’s host file.
NOTE: When determining which server type to select:

You can only create one eTrust Siteminder server instance per IVE.

If you authenticate your Active Directory server with:


NTLM protocol—Choose Active Directory/Windows NT Domain. For
more information, see “Configuring an ACE/Server Instance” on
page 136.

LDAP protocol—Choose LDAP Server. For more information, see
“Configuring an LDAP Server Instance” on page 147.
If you are creating a local authentication server instance to authenticate user
administrators, you must select Local Authentication. For more information,
see “Configuring a Local Authentication Server Instance” on page 155.
Defining an Authentication Server Instance
Use the Auth. Servers page to define authentication server instances.
Authentication servers authenticate user credentials and authorization servers
provide user information that the IVE 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). For more information about authentication servers, see
“Authentication and Directory Servers” on page 131.
Defining an Authentication Server Instance

133
Juniper Networks Secure Access Administration Guide
This section contains the following information about authentication servers:

“Defining an Authentication Server Instance” on page 134

“Modifying an Existing Authentication Server Instance” on page 134
Defining an Authentication Server Instance
To define an authentication server instance:
1. In the admin console, choose Authentication > Auth. Servers.
2. Choose a server type from the New drop down menu.
3. Click New Server.
4. Depending on which server you selected, specify settings for the individual
server instance.
5. Specify which realms should use the server to authenticate and authorize
administrators and users. For more information, see “Defining Authentication
Policies” on page 210.
6. If you are configuring the local authentication server, define local user
accounts. For instructions, see “Configuring a Local Authentication Server
Instance” on page 155.
Modifying an Existing Authentication Server Instance
To modify an authentication server instance:
1. In the admin console, choose Authentication > Auth. Servers.
2. Click the link to the server you want to modify.
3. Make your modifications on the appropriate server page.
4. Click Save Changes.
Configuring an Anonymous Server Instance
The anonymous server feature allows users to access the IVE 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 IVE bypasses the
standard IVE sign-in page, and immediately displays the IVE welcome page to the
user.
134

Configuring an Anonymous Server Instance
Chapter 8: Authentication and Directory Servers
You may choose to use anonymous authentication if you think that the resources on
the IVE do not require extreme security, or if you think that other security measures
provided through the IVE 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.
This section contains the following information about anonymous servers:

“Anonymous Server Restrictions” on page 135

“Defining an Anonymous Server Instance” on page 135
Anonymous Server Restrictions
When defining and monitoring an anonymous server instance, note that:

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. For more information, see “Creating an Authentication
Realm” on page 208.

When creating role mapping rules through the Users > User Realms > Role
Mapping tab (as explained in “Creating Role Mapping Rules” on page 211), the
IVE 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). For more information, “Specifying Limits Restrictions” on
page 64.

You cannot view and delete the sessions of anonymous users through a Users
tab (as you can with other authentication servers), because the IVE cannot
display individual session data without collecting usernames.
Defining an Anonymous Server Instance
To define an anonymous server:
1. In the admin console, choose Authentication > Auth. Servers.
Configuring an Anonymous Server Instance

135
Juniper Networks Secure Access Administration Guide
2. Do one of the following:

To create a new server instance on the IVE, 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. For more
information, see “Defining Authentication Policies” on page 210.
Configuring an ACE/Server Instance
When authenticating users with an RSA ACE/Server, users may sign in using two
methods:

Using a hardware token and the standard IVE sign-in page—The user
browses to the standard IVE sign-in page, then enters her username and
password (consisting of the concatenation of her PIN and her RSA SecurID
hardware token’s current value). The IVE then forwards the user’s credentials
to ACE/Server.

Using a software token and the custom SoftID IVE sign-in page—The user
browses to the SoftID custom sign-in page. Then, using the SoftID plug-in, she
enters her 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 IVE.
For information about enabling the SoftID custom sign-in pages, the Custom
Sign-In Pages Solution Guide.
If ACE/Server positively authenticates the user, she gains access to the IVE.
Otherwise, the ACE/Server:
136


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 IVE for the first time. (The user sees different prompts depending on
the method she uses to sign in. If the user signs in using the SoftID plug-in, she
sees the RSA prompts for creating a new pin; otherwise the user sees the IVE
prompts.)

Prompts the user to enter her 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 IVE to ACE/Server without user
interaction.)
Configuring an ACE/Server Instance
Chapter 8: Authentication and Directory Servers

Redirects the user to the standard IVE 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, she has three minutes to
enter the required information before the IVE cancels the transaction and notifies
the user to re-enter her credentials.
The IVE 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 IVE, the ACE/Server
transaction is initiated when the user submits her request for authentication and
ends once the ACE/Server has finished processing the request. The user may then
keep her IVE session open, even though her ACE/Server transaction is closed.
The IVE supports the following ACE/Server features: New PIN mode, Next Token
mode, DES/SDI encryption, AES encryption, slave ACE/Server support, name
locking, and clustering. The IVE also supports the New PIN and Next Token modes
of RSA SecurID through the RADIUS protocol.
NOTE: Due to UNIX limitations of the ACE/Server library, you may define only one
ACE/Server configuration. For information on generating an ACE/Agent
configuration file for the IVE on the ACE server, see “Generating an ACE/Agent
Configuration File” on page 138.
The IVE does not support load balancing between multiple ACE servers.
This section contains the following information about ACE/Servers:

“Defining an ACE/Server Instance” on page 137

“Generating an ACE/Agent Configuration File” on page 138
Defining an ACE/Server Instance
NOTE: You can add only one ACE/Server instance.
To define an ACE/Server:
1. Generate an ACE/Agent configuration file (sdconf.rec) for the IVE on the ACE
server. For more information, see “Generating an ACE/Agent Configuration File”
on page 138.
2. In the admin console, choose Authentication > Auth. Servers.
3. Do one of the following:

To create a new server instance on the IVE, 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.
Configuring an ACE/Server Instance  137
Juniper Networks Secure Access Administration Guide
4. Specify a name to identify the server instance.
5. Specify a default port the ACE Port field. Note that the IVE 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 IVE anytime you make changes to the source file. Likewise, if you delete the
instance file from the IVE, go to the ACE Server Configuration Management
application, as described in “Generating an ACE/Agent Configuration File” on
page 138, and remove the check from the Sent Node Secret check box.
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. For more information, see “Defining Authentication
Policies” on page 210.
NOTE: For information about monitoring and deleting the sessions of users who
are currently signed in through the server, see “Monitoring Active Users” on
page 821.
Generating an ACE/Agent Configuration File
If you use ACE/Server for authentication, you must generate an ACE/Agent
configuration file (sdconf.rec) for the IVE on the ACE Server.
To generate an ACE/Agent configuration file:
1. Start the ACE/Server Configuration Management application and click Agent
Host.
2. Click Add Agent Host.
3. For Name, enter a name for the IVE agent.
4. For Network Address, enter the IP address of the IVE.
5. Enter a Site configured on your ACE server.
6. For Agent Type, select Communication Server.
7. For Encryption Type, select DES.
8. 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 IVE, the ACE server selects Sent Node Secret. If you later want the ACE
server to send a new Node Secret to the IVE on the next authentication request,
do the following:
138

a.
Click the Sent Node Secret check box to uncheck it.
b.
Sign in to the admin console and choose Authentication > Auth. Servers.
Configuring an ACE/Server Instance
Chapter 8: Authentication and Directory Servers
c.
Click the name of the ACE server in the Authentication/Authorization
Servers list.
d. Under Node Verification File, select the appropriate check box and click
Delete. These steps ensure that the IVE and ACE server are in sync.
Likewise, if you delete the verification file from the IVE, you should
uncheck the Sent Node Secret check box on the ACE server.
If you use RSA ACE/Server authentication and change the IVE IP address,
you must delete the node verification file on the IVE for ACE/Sever
authentication to work. Also, deselect the Sent Node Verification setting
on the ACE/Server for the IVE.
9. Click Assign Acting Servers and select your ACE server.
10. Click Generate Config File. When you add the ACE server to the IVE, you will
import this configuration file.
Configuring an Active Directory or NT Domain Instance
When authenticating users with an NT Primary Domain Controller (PDC) or Active
Directory, users sign in to the IVE using the same username and password they use
to access their Windows desktops. The IVE 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 IVE displays
all groups from the configured domain controller and its trusted domains.
The IVE 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.
Configuring an Active Directory or NT Domain Instance  139
Juniper Networks Secure Access Administration Guide
See “Creating Role Mapping Rules” on page 211 for more information.
NOTE:

The IVE honors trust relationships in Active Directory and Windows NT
environments.

When sending user credentials to an Active Directory authentication server,
the IVE uses whichever authentication protocol(s) you specify on the New
Active Directory/Windows NT page. The IVE defaults to the authentication
protocols in order. In other words, if you have selected the check boxes for
Kerberos and NTLMv2, the IVE sends the credentials to Kerberos. If Kerberos
succeeds, the IVE does not send the credentials to NTLMv2. If Kerberos is not
supported or fails, the IVE 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.For more information, see “Defining Resource Policies:
UNIX/NFS File Resources” on page 484.

The IVE supports Domain Local Groups, Domain Global Groups, and Universal
Groups defined in the Active Directory forest. It also supports Domain Local
and Domain Global groups for NT4 servers.

The IVE 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 an IVE, 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.
This section contains the following information about Active Directory and NT
Domain servers:

“Defining an Active Directory or Windows NT Domain Server Instance” on
page 140

“Multi-Domain User Authentication” on page 143

“Active Directory and NT Group Lookup Support” on page 144
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:
140


To create a new server instance on the IVE, 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.
Configuring an Active Directory or NT Domain Instance
Chapter 8: Authentication and Directory Servers
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. Specify the IP address of your back-up domain controller or Active Directory
server. (optional)
6. Enter the domain name of the Active Directory or Windows NT domain. For
example, if the Active Directory domain name is us.amr.asgqa.net and you
want to authenticate users who belong to the US domain, enter US in the
domain field.
7. If you want to specify a computer name, enter it into the Computer Name
field. The computer name field is where you specify the name that the IVE uses
to join the specified Active Directory domain as a computer. Otherwise, leave
the default identifier which uniquely identifies your system.
NOTE: You may note that the computer name is pre-filled with an entry in the
format of vcNNNNHHHHHHHH, where, in an IVS system, the NNNN is the IVS ID
(assuming you have an IVS license) and the HHHHHHHH is a hex representation of
the IP address of the IVE. A unique name, either the one provided by default or
one of your own choosing, you can more easily identify your systems in the Active
Directory. In a non-IVS system, the first six characters of the name will be ‘vc0000’
because there is no IVS ID to display. For example, the name could be something
like ‘vc0000a1018dF2’ for a non-IVS system.
In a clustered environment with the same AD authentication server, this name is
also unique among all cluster nodes, and the IVE displays all of the identifiers for
all attached cluster nodes.
8. 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
9. Select the Allow trusted domains check box to get group information from all
trusted domains within a forest.
10. 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.
Configuring an Active Directory or NT Domain Instance  141
Juniper Networks Secure Access Administration Guide
11. For Admin Username and Admin Password, enter an administrator username
and password for the AD or NT server.
NOTE:

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.

After you save changes, the IVE masks the administrator password using five
asterisk characters, regardless of the password length.
12. Under Authentication Protocol, specify which protocol the IVE should use
during authentication.
13. Under Kerberos Realm Name:

Select Use LDAP to get Kerberos realm name if you want the IVE 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. 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)
15. Click Save Changes. If you are creating the server instance for the first time, the
Settings and Users tabs appear.
16. Specify which realms should use the server to authenticate and authorize
administrators and users. For more information, see “Creating an
Authentication Realm” on page 208.
NOTE:
142


For information about monitoring and deleting the sessions of users who are
currently signed in through the server, see “Monitoring Active Users” on
page 821.

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.
Configuring an Active Directory or NT Domain Instance
Chapter 8: Authentication and Directory Servers
Multi-Domain User Authentication
The IVE allows for multi-domain Active Directory and Windows NT authentication.
The IVE 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 the
IVE Active Directory server configuration, users in the default domain authenticate
to the IVE using either just their username, or using the default domain plus
username in the format defaultdomain\username.
When you enable trusted domain authentication, users in trusted or child domains
authenticate to the IVE using the name of the trusted or child domain plus the
username in the format trusteddomain\username. Note that enabling trusted
domain authentication adds to the server’s response time.
Windows 2000 and Windows 2003 Multi-Domain Authentication
The IVE supports Kerberos-based Active Directory authentication with Windows
2000 and Windows 2003 domain controllers. When a user logs in to the IVE, the
IVE performs Kerberos authentication and attempts to fetch the Kerberos realm
name for the domain controller, as well as all child and trusted realms, using LDAP
calls.
You can alternately specify the Kerberos realm name when configuring an Active
Directory authentication server, but we do not recommend this method for two
reasons:

You cannot specify more than one realm name. The IVE cannot then
authenticate against child or trusted realms of the realm you specify.

If you misspell the realm name, the IVE cannot authenticate users against the
proper realm.
Windows NT4 Multi-Domain Authentication
The IVE does not support Kerberos-based authentication in Windows NT4 domain
controllers. Instead of Kerberos authentication, the IVE uses NTLM authentication.
NOTE:

For user authentication, the IVE joins the default domain controller server
using the machine name in the format <IVE-IPaddress>.

If the DNS configuration on the Windows NT4 domain controller changes,
make sure that the IVE 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.
Configuring an Active Directory or NT Domain Instance  143
Juniper Networks Secure Access Administration Guide
NT User Normalization
In order to support multi-domain authentication, the IVE 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 the IVE, either
using just a username or using the domain\username format, the IVE always treats
the username in the domain\username format.
When a user attempts to authenticate using only their username, the IVE always
normalizes their NT credentials as defaultdomain\username. Authentication
succeeds only if the user is a member of the default domain.
For a user who signs to the IVE using the domain\username format, the IVE always
attempts to authenticate the user as members of the domain the user specifies.
Authentication succeeds only if the user-specified domain is a trusted or child
domain of the default domain. If the user specifies an invalid or untrusted domain,
authentication fails.
Two variables, <NTUser> and <NTDomain>, allow you to individually refer to
domain and NT username values. The IVE populates these two variables with the
domain and NT username information.
NOTE: When using pre-existing role mapping rules or writing a new role mapping
rule for Active Directory authentication where USER = someusername, the IVE
treats this rule semantically as NTUser = someusername AND NTDomain =
defaultdomain. This allows the IVE to work seamlessly with pre-existing role
mapping rules.
Active Directory and NT Group Lookup Support
The IVE 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.
NOTE: For the NT/AD group lookup to work, the IVE first tries to join the domain
using the default computer name. For this operation to succeed, you must specify
valid domain administrator credentials in the Active Directory server configuration
on the IVE.
Active Directory Lookup Requirements
The IVE supports user group lookup in Domain Local, Domain Global, and Universal
groups in the default domain, child domains, and all trusted domains. The IVE
obtains group membership using one of three methods that have different
capabilities:
144


Group information in User’s Security Context—Returns information about a
user’s Domain Global groups.

Group information obtained using LDAP search calls—Returns information
about the user’s Domain Global groups, and information about the user’s
Universal groups if the IVE queries the Global Catalog Server.
Configuring an Active Directory or NT Domain Instance
Chapter 8: Authentication and Directory Servers

Group information using native RPC calls—Returns information about the
user’s Domain Local Group.
With respect to role mapping rules, The IVE attempts group lookup in the following
order:

The IVE checks for all Domain Global groups using the user’s security context.

If the IVE has not found that the user is a member of some of the groups
referenced in the role mapping rules, the IVE performs an LDAP query to
determine the user’s group membership.

If the IVE has not found that the user is a member of some of the groups
referenced in the role mapping rules, the IVE performs an RPC lookup to
determine the user’s Domain Local group membership.
NT4 Group Lookup Requirements
The IVE supports group lookup in the Domain Local and Domain Global groups
created in the default domain, as well as all child, and other trusted domains. The
IVE obtains Domain Global group information from the user’s security context, and
Domain Local information using RPC calls. The IVE uses no LDAP-based search
calls in the NT4 environment.
Configuring a Certificate Server Instance
The certificate server feature allows users to authenticate based on attributes
contained in client-side certificates. You may use certificate server by itself or in
conjunction with another server to authenticate users and map them to roles.
For example, you may choose to authenticate users solely based on their certificate
attributes. If the IVE determines that the user’s certificate is valid, it signs the user
in based on the certificate attributes you specify and does not prompt the user to
enter a username or password.
Or, you may choose to authenticate users by passing their client-side certificate
attributes to a second authentication server (such as LDAP). In this scenario, the
certificate server first determines if the user’s certificate is valid. Then, the IVE can
use realm-level role-mapping rules to compare the certificate attributes with the
user’s LDAP attributes. If it cannot find the proper match, the IVE can deny or limit
the user’s access based on your specifications.
NOTE: When using client-side certificates, we strongly recommend that you train
your end-users to close their Web browsers after signing out of the IVE. If they do
not, other users may be able to use their open browser sessions to access
certificate-protected resources on the IVE 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.
Configuring a Certificate Server Instance

145
Juniper Networks Secure Access Administration Guide
When defining a certificate server on the IVE, 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 IVE should construct a
username. You may use any combination of certificate variables contained
in angle brackets and plain text. For a list of certificate variables, see
“System Variables and Examples” on page 1018.
NOTE: If you choose a certificate attribute with more than one value, the IVE 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 IVE uses the
“management” value. To use all values, add the SEP attribute to the variable. For
example, if you enter <certDN.OU SEP=”:”> the IVE uses “management:sales”.
e.
Click Save Changes. If you are creating the server instance for the first
time, the Settings and Users tabs appear.
NOTE: For information about monitoring and deleting the sessions of users who
are currently signed in through the server, see “Monitoring Active Users” on
page 821.
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.
146

Configuring a Certificate Server Instance
Chapter 8: Authentication and Directory Servers
6. If you want to restrict users’ access to realms, roles, or resource policies based
on individual certificate attributes, use the settings described in “Specifying
Certificate Access Restrictions” on page 62.
Configuring an LDAP Server Instance
The IVE supports two LDAP-specific authentication options:

Unencrypted, in which the IVE sends the username and password to the LDAP
Directory Service in clear, simple text.

LDAPS, in which the IVE encrypts the data in the LDAP authentication session
using Secure Socket Layer (SSL) protocol before sending it to the LDAP
Directory Service.
The IVE performs substantial input validation for the following items:

LDAP Server—The IVE provides a warning if the server is not reachable.

LDAP Port—The IVE provides a warning if the LDAP server is not reachable.

Administrator credentials—The IVE generates an error if the verification of
admin credentials fails.

Base DN for users—The IVE generates an error if the base-level search on the
Base DN value fails.

Base DN for groups—The IVE generates an error if the base-level search on the
Base DN value fails.
This section contains the following information about LDAP servers:

“Defining an LDAP Server Instance” on page 147

“Configuring LDAP Search Attributes for Meeting Creators” on page 150

“Monitoring and Deleting Active User Sessions” on page 150

“Enabling LDAP Password Management” on page 151
Defining an LDAP Server Instance
To define an LDAP 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 IVE, 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.
Configuring an LDAP Server Instance  147
Juniper Networks Secure Access Administration Guide
3. Specify a name to identify the server instance.
4. Specify the name or IP address of the LDAP server that the IVE 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). The IVE uses the
specified servers for failover processing; each authentication request is first
routed to the primary LDAP server and then to the specified backup server(s) if
the primary server is unreachable.
NOTE: Backup LDAP servers must be the same version as the primary LDAP server.
Also, we recommend that you specify the IP address of a backup LDAP server
instead of its host name, which may accelerate failover processing by eliminating
the need to resolve the host name to an IP address.
7. Specify the type of LDAP server that you want to authenticate users against.
8. Specify whether or not the connection between the IVE and LDAP Directory
Service should be unencrypted, use SSL (LDAPs), or should use TLS.
9. Specify how long you want the IVE to wait for a connection to the primary
LDAP server first, and then each backup LDAP server in turn.
10. Specify how long you want the IVE to wait for search results from a connected
LDAP server.
11. Click Test Connection to verify the connection between the IVE appliance and
the specified LDAP server(s). (optional)
12. Select the Authentication required? check box if the IVE 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 more about password management, see “Enabling LDAP
Password Management” on page 151. 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

Filter if you want to fine-tune the search. For example:
samAccountname=<username> or cn=<username>
148

Configuring an LDAP Server Instance

Include <username> in the filter to use the username entered on the
sign-in page for the search.

Specify a filter that returns 0 or 1 user DNs per user; the IVE uses the
first DN returned if more than 1 DN is returned.
Chapter 8: Authentication and Directory Servers
14. The IVE supports both static and dynamic groups. (Note that the IVE only
supports dynamic groups with LDAP servers.) To enable group lookup, you
need to specify how the IVE searches the LDAP server for a group. Under
Determining group membership, specify a:

Base DN at which to begin searching for user groups.

Filter if you want to fine-tune the search for a user group.

Member Attribute to identify all the members of a static group. For
example:
member
uniquemember (iPlanet-specific)

Reverse group search to start the search from the member instead of the
group. This option is available only for Active Directory server types.

Query Attribute to specify an LDAP query that returns the members of a
dynamic group. For example:
memberURL

Nested Group Level to specify how many levels within a group to search
for the user. Note that the higher the number, the longer the query time, so
we recommend that you specify to perform the search no more than 2
levels deep.

Nested Group Search to search by:

Nested groups in the LDAP Server Catalog. This option is faster
because it can search within the implicit boundaries of the nested
group.

Search all nested groups. With this option, the IVE searches the
Server Catalog first. If the IVE finds no match in the catalog, then it
queries LDAP to determine if a group member is a sub-group.
NOTE: Because the IVE 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.
15. Under Bind Options, select:

Simple bind to send a user’s credentials in the clear (no encryption) to the
LDAP Directory Service.

StartTLS bind to encrypt a user’s credentials using the Transport Layer
Security (TLS) protocol before the IVE sends the data to the LDAP Directory
Service.
16. Click Save Changes. If you are creating the server instance for the first time, the
Settings and Users tabs appear.
Configuring an LDAP Server Instance  149
Juniper Networks Secure Access Administration Guide
17. Specify which realms should use the server to authenticate and authorize
administrators and users. For more information, see “Defining Authentication
Policies” on page 210.
If you want to create a Windows File bookmark that maps to a user’s LDAP home
directory, see “Creating Windows Bookmarks that Map to LDAP Servers” on
page 474.
NOTE: The IVE supports referral chasing if enabled on your LDAP server.
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 IVE users when scheduling a meeting.
To configure Secure Meeting search attributes:
1. In the admin console, choose Authentication > Auth. Servers.
2. Click on an LDAP server instance.
3. Choose the Meetings tab.
4. 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.
5. In the Email Address field, enter the email attribute for this server.
6. 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.
7. Click Save Changes.
Monitoring and Deleting Active User Sessions
For information about monitoring and deleting the sessions of users who are
currently signed in through the server, see “Monitoring Active Users” on page 821.
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.
150

Configuring an LDAP Server Instance
Chapter 8: Authentication and Directory Servers
Enabling LDAP Password Management
The IVE password management feature enables users who authenticate through an
LDAP server to manage their passwords through the IVE using the policies defined
on the LDAP server. For example, if a user tries to sign in to the IVE with an LDAP
password that is about to expire, the IVE catches the expired password notification,
presents it to the user through the IVE 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 IVE 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 IVE may inform
the user that his password is expired or about to expire. If expired, the IVE prompts
the user to change his password. If the password has not expired, the IVE may
allow the user to sign in to the IVE using his existing password. After he has signed
in, he may change his password from the Preferences page.
The password management feature enables users to change their passwords when
prompted or at will. For example, during the sign-in process, the IVE may inform
the user that his password is expired or about to expire. If expired, the IVE prompts
the user to change his password. If the password has not expired, the IVE may
allow the user to sign in to the IVE using his existing password. After he has signed
in, he may change his password from the Preferences page.
Once enabled, the IVE 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 IVE does this by using its internal LDAP or Samba client.
Many servers, such as Microsoft Active Directory or Sun iPlanet, offer an
Administrative Console to configure account and password options.
The IVE enforces password policies by reading password attributes from the LDAP
server. Therefore, for password management to work correctly, password policy
attributes on backend server need to be configured properly.

For Active Directory, password policy attributes can be configured in the user
entry container level or any organization level above the user container. If
these attributes are configured at multiple levels, the level closest to the user
node takes precedence.

The IVE does not support customized password policies.

The password management feature is not supported on the Active Directory
Global Catalog because password policy attributes are not fully populated on
the Active Directory Global Catalog.
Configuring an LDAP Server Instance  151
Juniper Networks Secure Access Administration Guide
The IVE relies on the backend server to pinpoint the cause of error when a
password change operation fails. However, while LDAP servers may report errors
accurately to human operators, they do not always do so when communicating
programmatically to systems like the IVE . Therefore, reported errors may at times
be generic or cryptic.
This section includes the following topics with information about the LDAP
password management feature:

“Task Summary: Enabling LDAP Password Management” on page 152

“Supported LDAP Directories and Servers” on page 152

“Supported LDAP Password Management Functions” on page 153
Task Summary: Enabling LDAP Password Management
To enable password management through the IVE, you must:
1. Create an instance of the LDAP server through the Authentication > Auth.
Servers page of the admin console.
2. Associate the LDAP server with a realm through the Administrators/Users >
User Realms > [Realm] > General page of the admin console.
3. Enable password management for the realm in the Administrators/Users >
User Realms > [Realm] > Authentication Policy >Password page of the
admin console. Note that the Enable Password Management option only
appears if the realm’s authentication server is an LDAP or NT/AD server.
Supported LDAP Directories and Servers
The IVE 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 IVE supports password management with the following Windows
servers:

Microsoft Active Directory

Microsoft Active Directory 2003

Windows NT 4.0
The following sections list specific issues related to individual server types.
152

Configuring an LDAP Server Instance
Chapter 8: Authentication and Directory Servers
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 IVE
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. As explained in
“Supported LDAP Password Management Functions” on page 153, Microsoft
Active Directory calculates the password expiration using the Maximum
Password Age and Password Last Set values retrieved from the User Policy
and Domain Security Policy LDAP objects.
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 IVE only displays a warning about password expiry if the password is
scheduled to expire in 14 days or less. The IVE displays the message during each
IVE sign in attempt. The warning message contains the remaining number of days,
hours, and minutes that the user has to change his password before it expires on
the server. The default value is 14 days; however, you may change it through the
Administrators|Users > Admin Realms|User Realms> Authorization >
Password configuration page of the admin console.
Supported LDAP Password Management Functions
The following matrix describes the password management functions supported by
Juniper Networks, their corresponding function names in the individual LDAP
directories, and any additional relevant details. These functions must be set
through the LDAP server itself before the IVE can pass the corresponding messages,
functions, and restrictions to end-users.
Table 7: 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
Configuring an LDAP Server Instance  153
Juniper Networks Secure Access Administration Guide
Table 7: Supported Password Management Functions (Continued)
Function
Active Directory
iPlanet
Novell eDirectory
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
Check date/time value in
OID
2.16.840.1.113730.3.4.4
== 0
passwordExpirationTime
Password expiration
notification (in X
days/hours)
if pwdLastSet - now() <
maxPwdAge - 14 days
If Bind Response includes
control OID
If now() passwordExpirationTime<
2.16.840.1.113730.3.4.5
14 days
(maxPwdAge is read from
(contains date/time)
(IVE displays warning if less
domain attributes)
(IVE
displays
warning
if
less
than 14 days)
(IVE displays warning if less
than 14 days)
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, IVE displays message If set, IVE displays message If set, IVE displays message
telling user minPwdLength telling user
telling user
passwordMinLength
passwordMinimumLength
Disallow user from
changing password
too soon
If pwdLastSet - now() <
minPwdAge, then we
disallow
Honor "password
complexity"
If pwdProperties == 0x1, Server tells us in bind
then enabled. Complexity
response
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 Nonalphabetic characters (ex. !,
$, %)
If passwordMinAge > 0,
Server tells us in bind
then if now() is earlier than response
passwordAllowChangeTime
, then we disallow
Server tells us in bind
response
AD/NT Password Management Matrix
The following matrix describes the Password Management functions supported by
Juniper Networks.
154

Configuring an LDAP Server Instance
Chapter 8: Authentication and Directory Servers
Table 8: AD/NT Password Management Matrix
Function
Active Directory
Active Directory 2003 Windows NT
Authenticate user
Yes
Yes
Yes
Allow user to change password if licensed and
if enabled
Yes
Yes
Yes
Log out user after password change
Yes
Yes
Yes
Force password change at next login
Yes
Yes
Yes
Password expired notification
Yes
Yes
Yes
Account disabled
Yes
Yes
Yes
Account expired
Yes
Yes
Yes
Yes
Yes
Yes
Troubleshooting LDAP Password Management on the IVE
When troubleshooting, please provide any pertinent IVE logs, server logs,
configuration information, and a TCP trace from the IVE. If you are using LDAPS,
please switch to the “Unencrypted” LDAP option in the IVE LDAP server
configuration while taking the LDAP TCP traces.
Configuring a Local Authentication Server Instance
The IVE enables you to create one or more local databases of users who are
authenticated by the IVE. 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 using instructions in “Defining
Authentication Policies” on page 210.
This section contains the following information about local authentication servers:

“Defining a Local Authentication Server Instance” on page 155

“Creating User Accounts on a Local Authentication Server” on page 157

“Managing User Accounts” on page 158
Defining a Local Authentication Server Instance
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.
To define a local authentication server instance:
Configuring a Local Authentication Server Instance

155
Juniper Networks Secure Access Administration Guide
1. In the admin console, choose Authentication > Auth. Servers.
2. Do one of the following:

To create a new server instance on the IVE, select Local Authentication
from the New list, and then click New Server.

To update an existing server instance, click the appropriate link in the
Authentication/Authorization Servers list.
3. Specify a name to identify the new server instance or edit the current name for
an existing server.
4. Specify password options:
a.
Under Password options, set the minimum character length for
passwords.
b.
Set the maximum character length for passwords (optional). The
maximum length cannot be less than the minimum length. There is no
maximum limit to the length.
NOTE:

If the maximum length set on the authentication server is shorter than the
maximum length specified on the IVE, 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 upperand lowercase letters (optional).
NOTE: Require passwords to contain at least two letters if you also require a mix of
upper- and lowercase letters.
f.
156

Enable the Password must be different from username check box if the
password cannot equal the username (optional).
Configuring a Local Authentication Server Instance
Chapter 8: Authentication and Directory Servers
g.
Enable the New passwords must be different from previous password
check box if a new password cannot equal the previous password
(optional).
5. Specify password management options:
a.
Under Password management, enable the Allow users to change their
passwords check box if you want users to be able to change their
passwords (optional).
b.
Enable the Force password change after _ days check box and specify the
number of days after which a password expires (optional).
NOTE: The default is 64 days, but you can set this value to any number you desire.
c.
Enable the Prompt users to change their password _ days before current
password expires check box and provide the number of days before
password expiration to prompt the user (optional).
NOTE: The default value is 14 days, but you can set the value to any number up to
the number placed in the previous option.
6.
Click Save Changes. If you are creating the server instance for the first time,
the Users tabs and Admin Users tabs appear.
NOTE: 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. See “Specifying Password Access Restrictions” on page 63 for
information about enabling password management.
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 IVE local authentication server to which you want to add a user
account.
3. Select the Users tab and click New.
Configuring a Local Authentication Server Instance

157
Juniper Networks Secure Access Administration Guide
4. Enter a Username and the user’s Full Name.

Do not include “~~” in a username.

If you want to change a username after creating the account, you must
create an entirely new account.
5. Enter the Password and Confirm Password. Make sure that the password you
enter conforms to the password options specified for the associated local
authentication server instance.
6. 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.
7. 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.
8. 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.
9. Click Save Changes. The user record is added to the IVE database.
NOTE: The admin console provides last access statistics for each user account on
various Users tabs throughout the console, under a set of columns titled Last Signin Statistic. The statistics reported include the last successful sign-in date and time
for each user, the user’s IP address, and the agent or browser type and version.
Managing User Accounts
To manage a local user account:
1. In the admin console, choose Authentication > Auth. Servers.
2. Click the appropriate server link in the Authentication/Authorization Servers
list.
3. Select the Users tab.
158

Configuring a Local Authentication Server Instance
Chapter 8: Authentication and Directory Servers
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.

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 IVE sessions.
NOTE: For information about managing users from the secure gateway home page,
see the “Adding and Modifying Users” topic in the end-user help, which is available
when signing in to the IVE as an end-user.
Configuring an NIS Server Instance
When authenticating users with a UNIX/NIS server, the IVE 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 IVE cannot contain two consecutive tilde symbols (~~).
NOTE: You can only use NIS authentication with the IVE 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 IVE, 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 IVE, 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.
Configuring an NIS Server Instance  159
Juniper Networks Secure Access Administration Guide
5. Specify the domain name for the NIS server.
6. Click Save Changes. If you are creating the server instance for the first time,
the Settings and Users tabs appear.
7. Specify which realms should use the server to authenticate and authorize
administrators and users. For more information, see “Defining Authentication
Policies” on page 210.
NOTE: For information about monitoring and deleting the sessions of users who
are currently signed in through the server, see “Monitoring Active Users” on
page 821.
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 remote users. When
using a RADIUS server to authenticate IVE users, you need to configure it to
recognize the IVE as a client and specify a shared secret for the RADIUS server to
use to authenticate the client request.
The IVE supports the standard RADIUS authentication schemes, including:

Access-Request

Access-Accept

Access-Reject

Access-Challenge
The IVE 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 IVE 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 IVE to work with
many different RADIUS implementations and new versions of the RADIUS server,
such as Defender 5.0. The IVE 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.
This topic contains the following information about RADIUS servers:
160


“User Experience for RADIUS Users” on page 161

“Configuring the IVE to Work with a Back-end RADIUS Server” on page 162

“Enabling RADIUS Accounting” on page 165
Configuring a RADIUS Server Instance
Chapter 8: Authentication and Directory Servers
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.
Using a PassGo Defender RADIUS Server
If you are using a PassGo Defender RADIUS Server, the user sign-in process is:
1. The user signs in to the IVE with a username and password. The IVE forwards
these credentials to Defender.
2. Defender sends a unique challenge string to the IVE and the IVE displays this
challenge string to the user.
3. The user enters the challenge string in a Defender token and the token
generates a response string.
4. The user enters the response string on the IVE 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 IVE
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.
Figure 27: CASQUE Authentication Challenge/Response Page with CASQUE Player
Configuring a RADIUS Server Instance

161
Juniper Networks Secure Access Administration Guide
Configuring the IVE to Work with a Back-end RADIUS Server
This section includes the following instructions for configuring the IVE and RADIUS
server to work together:

“Defining an IVE RADIUS Server Instance” on page 162

“Configuring the RADIUS Server to Recognize the IVE” on page 165
Defining an IVE RADIUS Server Instance
To configure a connection to the RADIUS server on the IVE:
1. In the admin console, choose Authentication > Auth. Servers.
2. Do one of the following:

To create a new server instance on the IVE, 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 IVE Network
Access Server (NAS) client that communicates with the RADIUS server. If you
leave this field empty, the IVE uses the value specified in the Hostname field of
the System > Network > Overview page of the admin console. If no value is
specified in Hostname field, the IVE uses the value “Juniper IVE.”
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 IVE machine 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 IVE’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 IVE to wait for a response from the RADIUS
server before timing out the connection.
11. Enter the number of times for the IVE to try to make a connection after the first
attempt fails.
162

Configuring a RADIUS Server Instance
Chapter 8: Authentication and Directory Servers
12. Select the Users authenticate using tokens or one-time passwords checkbox
if you do not want to submit the password entered by the user to other SSOenabled applications. You should generally select this option if the users submit
one-time use passwords to the IVE. For more information, see “Multiple Sign-In
Credentials Overview” on page 237.
13. In the Backup Server section, enter a secondary RADIUS server for the IVE 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 IVE 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 IVE should
send to the RADIUS accounting server. You may enter any of the
applicable session variables described in “System Variables and Examples”
on page 1018. 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 IVE username to the accounting server.

<REALM> logs the user’s IVE realm to the accounting server.

<ROLE> logs the user’s IVE role to the accounting server. If the user is
assigned to more than one role, the IVE 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. For more information, see “Understanding
the Interim Update Feature” on page 174.
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
IVE for the Framed-IP-Address attribute.
Two IP addresses are recorded: one prior to authenticating with the IVE, and
one returned by Network Connect after authentication. Select this option to use
the Network Connect IP address for the Framed-IP-Address attribute instead of
the pre-authenticated (original) IP address.
16. (optional) Click New Radius Rule to add a custom challenge rule that
determines the action to take for an incoming packet.
Configuring a RADIUS Server Instance

163
Juniper Networks Secure Access Administration Guide
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:

show NEW PIN page—user must enter a new PIN for his/her token

show NEXT TOKEN page—user must enter the next tokencode

show GENERIC LOGIN page—display an additional page to the user in
response to an Access Challenge sent by the server. Sometimes a
Radius server returns a Challenge packet and requires the user to enter
additional information to continue the login process. For example, a
server receives the initial username and password and sends an SMS
message to the user’s mobile phone with a one-time password (OTP).
The user enters the OTP in the generic login page.

show user login page with error—display the standard login page
with an embedded error message. This option lets you bypass the
standard message string sent by the IVE 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 ACCESSREQUEST 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.
164

Configuring a RADIUS Server Instance
Chapter 8: Authentication and Directory Servers
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. For more information, see “Defining
Authentication Policies” on page 210.
NOTE: For information about monitoring and deleting the sessions of users from
this server who are currently signed, see “Monitoring Active Users” on page 821.
Configuring the RADIUS Server to Recognize the IVE
You need to configure the RADIUS server to recognize the IVE by specifying:

The host name given to the IVE.

The network IP address of the IVE.

The IVE 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.
Enabling RADIUS Accounting
You can configure the IVE to send session start and stop messages to a RADIUS
accounting server. The IVE recognizes two categories of sessions—user-sessions
and sub-sessions. A user session may contain multiple sub-sessions. The IVE
recognizes the following types of sub-sessions:

JSAM

WSAM

Network Connect
The IVE sends a user-session start message after the user successfully signs in and
the IVE maps him to a role. The IVE sends a sub-session start message when the
sub-session becomes active; for example, after launching JSAM. The IVE 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 IVE sends a user-session stop message to
the accounting server. A user session terminates whenever the user:

Manually signs out of the IVE

Times out of the IVE either due to inactivity or because of exceeding the
maximum session length
Configuring a RADIUS Server Instance

165
Juniper Networks Secure Access Administration Guide

Is denied access due to Host Checker or Cache Cleaner role-level restrictions

Is manually forced out of the IVE by an administrator or due to dynamic policy
evaluation.
The IVE also sends stop messages for all active sub-sessions. The stop-messages for
the sub-sessions precede the stop-messages for the user-session.
.
NOTE: If users are signed into an IVE 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 9: Attributes Common to both Start and Stop Messages
Attribute
Description
User-Name (1)
String that the IVE administrator specifies during RADIUS server
configuration
NAS-IP-Address (4)
IVE’s IP address
NAS-Port (5)
The IVE 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 IVE client under the RADIUS server
configuration
Acct-Status-Type (40)
The IVE 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 AcctSession-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 IVE
generates the accounting record
Table 10: Start Attributes
Attribute
Acct-Authentic (45)
Description
The IVE 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
166

Configuring a RADIUS Server Instance
Chapter 8: Authentication and Directory Servers
Table 11: Stop Attributes
Attribute
Description
Acct-Session-Time (46)
Duration of the user-session or the sub-session
Acct-Terminate-Cause (49)
The IVE 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 IVE to
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
IVE.
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 IVE indicates the sub-session by using
one of the following suffixes in the Acct-Session-Id:

“JSAM” for JSAM sessions

“WSAM” for WSAM sessions

“NC” for Network Connect sessions
Supported RADIUS Attributes
The following RADIUS attributes are supported in RADIUS role mapping. For more
information, see the full descriptions (from which these descriptions were derived)
at the FreeRADIUS website located at http://www.freeradius.org/rfc/attributes.html.
Table 12: RADIUS Role Mapping Attributes
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 Framed- Protocol
of ARAP. Includes password information that the NAS
must send to the user in an ARAP feature flags packet.
ARAP-Password
Present in an Access-Request packet containing a
Framed-Protocol of ARAP. Only one of User-Password,
CHAP-Password, or ARAP-Password must be included
in an Access-Request, or one or more EAP-Messages.
ARAP-Security
Identifies the ARAP Security Module to be used in an
Access-Challenge packet.
Configuring a RADIUS Server Instance

167
Juniper Networks Secure Access Administration Guide
Table 12: RADIUS Role Mapping Attributes (Continued)
168

Attribute
Description
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
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.
Configuring a RADIUS Server Instance
Chapter 8: Authentication and Directory Servers
Table 12: RADIUS Role Mapping Attributes (Continued)
Attribute
Description
Acct-Session-Time
Indicates how many seconds the user has received
service.
Acct-Status-Type
Indicates whether this Accounting-Request marks the
beginning of the user service (Start) or the end (Stop).
Acct-Terminate-Cause
Indicates how the session was terminated.
Acct-Tunnel-Connection
Indicates the identifier assigned to the tunnel session.
Acct-Tunnel-Packets-Lost
Indicates the number of packets lost on a given link.
CHAP-Challenge
Contains the CHAP Challenge sent by the NAS to a
PPP Challenge-Handshake Authentication Protocol
(CHAP) user.
CHAP-Password
The response value provided by a PPP ChallengeHandshake Authentication Protocol (CHAP) user in
response to the challenge.
Callback-Id
The name of a location to be called, to be interpreted
by the NAS.
Callback-Number
The dialing string to be used for callback.
Called-Station-Id
Allows the NAS to send the phone number that the
user called, using Dialed Number Identification (DNIS)
or similar technology.
Calling-Station-Id
Allows the NAS to send the phone number that the call
came from, using Automatic Number Identification
(ANI) or similar technology.
Class
Sent by the server to the client in an Access-Accept
and then sent unmodified by the client to the
accounting server as part of the Accounting-Request
packet, if accounting is supported.
Configuration-Token
For use in large distributed authentication networks
based on proxy.
Connect-Info
Sent from the NAS to indicate the nature of the user's
connection.
EAP-Message
Encapsulates Extended Access Protocol [3] packets to
allow the NAS to authenticate dial-in users by means
of EAP without having to understand the EAP protocol.
Filter-Id
The name of the filter list for this user.
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.
Configuring a RADIUS Server Instance

169
Juniper Networks Secure Access Administration Guide
Table 12: RADIUS Role Mapping Attributes (Continued)
170

Attribute
Description
Framed-MTU
The Maximum Transmission Unit to be configured for
the user, when it is not negotiated by some other
means (such as PPP).
Framed-Pool
The name of an assigned address pool used to assign
an address for the user.
Framed-Protocol
The framing to be used for framed access.
Framed-Route
Routing information to be configured for the user on
the NAS.
Framed-Routing
The routing method for the user, when the user is a
router to a network.
Idle-Timeout
Sets the maximum number of consecutive seconds of
idle connection allowed to the user before termination
of the session or prompt.
Keep-Alives
Use SNMP instead of keep-alives.
Login-IP-Host
Indicates the system with which to connect the user,
when the Login-Service Attribute is included.
Login-LAT-Group
Contains a string identifying the LAT group codes that
this user is authorized to use.
Login-LAT-Node
Indicates the Node with which the user is to be
automatically connected by LAT.
Login-LAT-Port
Indicates the Port with which the user is to be
connected by LAT.
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 dialup user.
MS-Acct-EAP-Type
Represents the Extensible Authentication Protocol
(EAP) [15] type used to authenticate the dial-up user.
MS-BAP-Usage
Describes whether the use of BAP is allowed,
disallowed or required on new multilink calls.
MS-CHAP-CPW-1
Allows the user to change password if it has expired.
MS-CHAP-CPW-2
Allows the user to change password if it has expired.
MS-CHAP-Challenge
Contains the challenge sent by a NAS to a Microsoft
Challenge-Handshake Authentication Protocol (MSCHAP) user.
MS-CHAP-Domain
Indicates the Windows NT domain in which the user
was authenticated.
Configuring a RADIUS Server Instance
Chapter 8: Authentication and Directory Servers
Table 12: RADIUS Role Mapping Attributes (Continued)
Attribute
Description
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 Pointto-Point Encryption Protocol (MPPE).
MS-MPPE-Send-Key
Contains a session key for use by the Microsoft Pointto-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.
Configuring a RADIUS Server Instance

171
Juniper Networks Secure Access Administration Guide
Table 12: RADIUS Role Mapping Attributes (Continued)
172

Attribute
Description
NAS-IP-Address
Indicates the identifying IP Address of the NAS that is
requesting authentication of the user, and must be
unique to the NAS within the scope of the RADIUS
server.
NAS-Identifier
Contains a string identifying the NAS originating the
Access-Request.
NAS-Port
Indicates the physical port number of the NAS that is
authenticating the user.
NAS-Port-Id
Contains a text string that identifies the port of the
NAS that is authenticating the user.
NAS-Port-Type
Indicates the type of the physical port of the NAS that
is authenticating the user.
Password-Retry
Indicates how many authentication attempts a user is
allowed to attempt before being disconnected.
Port-Limit
Sets the maximum number of ports to be provided to
the user by the NAS.
Prompt
Indicates to the NAS whether it should echo the user's
response as it is entered, or not echo it.
Proxy-State
A proxy server can send this attribute to another
server when forwarding an Access-Request. The
attribute must be returned unmodified in the AccessAccept, 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.
Configuring a RADIUS Server Instance
Chapter 8: Authentication and Directory Servers
Table 12: RADIUS Role Mapping Attributes (Continued)
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-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.
Understanding Clustering Issues
Accounting messages are sent to the RADIUS server by each cluster node without
consolidation. RADIUS accounting on the IVE follows these assumptions:

If the cluster is active/passive, all users are connected to one node at a time.

If the cluster is active/active and does not use a balancer, users are connected
to different nodes but are static.

If the cluster is active/active and uses a balancer, the balancer usually enforces
a persistent source IP. In this case, users are always connected to the same
node.
The IVE does not support load balancing for RADIUS.
Configuring a RADIUS Server Instance

173
Juniper Networks Secure Access Administration Guide
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 five minutes long and the applications keep the
connections open all the time.
Configuring an eTrust SiteMinder Server Instance
When you configure the IVE to authenticate users with an eTrust SiteMinder policy
server, the IVE 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 client-side certificates to
authenticate the credentials (as explained in “Authentication Using Various
Authentication Schemes” on page 177).
The IVE also passes a protected resource to SiteMinder during authentication in
order to determine which SiteMinder realm it should use to authenticate the user.
When the IVE passes the protected resource, 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 IVE passed (as explained in “Configuring the IVE to Grant Users
Different Protected Resources” on page 186). If the user attempts to access a Web
resource with a higher protection level, either SiteMinder or the IVE handles the
request (as explained in “Reauthentication of Users with Insufficient Protection
Levels” on page 178).
This topic includes the following information about eTrust SiteMinder servers:

“eTrust SiteMinder Overview” on page 174

“Configuring SiteMinder to Work with the IVE” on page 179

“Configuring the IVE to Work with SiteMinder” on page 185
eTrust SiteMinder Overview
The IVE enables single sign-on (SSO) from the IVE 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 IVE creates a SMSESSION cookie and then
posts the cookie to the following locations so the user does not have to reauthenticate if he wants to access additional resources:
174

Configuring an eTrust SiteMinder Server Instance
Chapter 8: Authentication and Directory Servers

The IVE: If the user tries to access a SiteMinder resource from within his IVE
session (for example, from the IVE file browsing page), the IVE 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 IVE 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 (as explained in “Automatic Sign-In” on
page 189), the IVE can use an SMSESSION cookie generated by another agent to
enable single sign-on from a SiteMinder resource to the IVE. When a user accesses
the IVE sign-in page with an SMSESSION cookie, the IVE verifies the SMSESSION
cookie. Upon successful verification, the IVE establishes an IVE session for the user.
You can use the following authentication mechanisms when you enable automatic
sign-in through the IVE:

Custom agent: The IVE 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 (as
explained in “Authenticate using custom agent” on page 190). If you select this
option and the user enters his IVE session with an SMSESSION cookie, the IVE
attempts automatic sign-in when the user enters the IVE session.

HTML form post: The IVE 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 (as explained in on “Authenticate using
HTML form post” on page 191). If you select this option and the user enters his
IVE session with an SMSESSION cookie, the IVE attempts automatic sign-in
when the user enters the IVE session.

Delegated authentication: The IVE delegates authentication to a standard
agent. If this option is enabled, the IVE tries to determine the FCC URL
associated with the protected resource. The IVE then redirects the user to the
FCC URL with the IVE sign-in URL as the TARGET. Upon successful
authentication, the user is redirected back to the IVE with an SMSESSION
cookie and the IVE does an automatic sign-in for the user (as explained in
“Delegate authentication to a standard agent” on page 192).
Configuring an eTrust SiteMinder Server Instance

175
Juniper Networks Secure Access Administration Guide
NOTE:
176


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 IVE appliance.

SiteMinder sends the SMSESSION cookie to the IVE as a persistent cookie. To
maximize security, the IVE resets the persistent cookie as a session cookie
once authentication is complete.

When you use SiteMinder to authenticate, the IVE disregards any IVE 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 IVE 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 IVE using an IP address, they may receive an authentication failure and
will be prompted to authenticate again.

The IVE logs any SiteMinder error codes on the System > Log/Monitoring >
User Access page. For information on the SiteMinder error codes, see the
SiteMinder documentation.
Configuring an eTrust SiteMinder Server Instance
Chapter 8: Authentication and Directory Servers
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 IVE
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 IVE through the System > Certificates > Trusted
Client CAs tab. For more information, see “Using Trusted Client CAs” on
page 738.

If you do not want to display the standard IVE 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 IVE clientside certificate authentication. If you choose both, the IVE first authenticates
using the IVE configuration parameters. If this succeeds, it then passes
certificate values to SiteMinder for authentication.
For configuration information, see:

“Creating a SiteMinder Authentication Scheme for the IVE” on page 180

“Configuring the IVE to Work with Multiple Authentication Schemes” on
page 185
Configuring an eTrust SiteMinder Server Instance

177
Juniper Networks Secure Access Administration Guide
Reauthentication of Users with Insufficient Protection Levels
During IVE configuration, you must specify a protected resource in order to control
the protection level allowed in the user’s SiteMinder session, as explained in “eTrust
SiteMinder Overview” on page 174. If a user attempts to access a Web resource that
requires a higher protection level than he is authorized to access, however, the IVE
can also handle re-authentication by directing him to an intermediate page
(provided you have enabled the Resource for insufficient protection level option
on during IVE configuration). For more information, see “Resource for insufficient
protection level” on page 194.
The IVE intermediate page contains two options:

Continue—When the user selects this option, the IVE signs him out of his
current session, prompts him for the credentials required by the higher level
resource, and directs him to the page he is trying to access if his credentials
authenticate. (Note that if the user is running Host Checker or Cache Cleaner
and does not choose to enter his credentials when the IVE prompts him to reauthenticate, the Host Checker and/or Cache Cleaner application continues to
run on the user’s system until his IVE session times out.)

Cancel—When the user selects this option, he is redirected to the previous
page.
Otherwise, if you choose not to re-authenticate through the IVE, the reauthentication process is dependent on whether or not the policy server returns an
authentication scheme URL to the user. If the policy server:

Does not return an authentication scheme URL—The IVE returns a validation
failure message to the user and re-authenticates through the standard IVE signin page. The user is prompted to sign back in, but is assigned his original
protection level and may still be unable to sign in to the desired page.

Returns an authentication scheme URL—The IVE redirects to the Web agent
you specify in the IVE to handle re-authentication.
For information about making the IVE handle re-authentication, see “Creating a
SiteMinder Authentication Scheme for the IVE” on page 180.
Determining the User’s Username
With the availability of different authentication schemes and sign-in points, the IVE
may obtain a username from various sources, such as a policy server header,
certificate attribute, or from the IVE sign-in page. Listed below are the various
methods a user may employ to access the IVE and how the IVE determines the
username for each. When a user:

178

Signs in through the standard IVE sign-in page—The IVE first checks the
username that the policy server returned in its OnAuthAccept response header.
If SiteMinder does not define a username, the IVE uses the name that the user
entered during sign-in. Otherwise, if neither SiteMinder nor the user provide a
username because the user authenticates using a client certificate, the IVE uses
the UserDN value set by the policy server.
Configuring an eTrust SiteMinder Server Instance
Chapter 8: Authentication and Directory Servers

Automatically signs in to the IVE using SiteMinder credentials—The IVE first
checks the username that the policy server returned in its OnAuthAccept
response header. If SiteMinder does not define a username, the IVE checks the
SMSESSION cookie. Otherwise, if SiteMinder does not populate the response
header or SMSESSION cookie with a username, the IVE checks the UserDN
value in the SMSESSION cookie.
Once the IVE determines which username to use, it saves it in its session cache and
references it when a user wants to access additional resources (as explained in
“eTrust SiteMinder Overview” on page 174).
In order to consistently return the correct username to the IVE, you should
configure the OnAuthAccept response on the SiteMinder policy server, as explained
in “Creating a Rule/Response Pair to Pass Usernames to the IVE” on page 183.
Configuring SiteMinder to Work with the IVE
The following procedures outline how to configure a SiteMinder policy server to
work with the IVE. These are not complete SiteMinder configuration instructions—
they are only intended to help you make SiteMinder work with the IVE. For indepth SiteMinder configuration information, refer to the documentation provided
with your SiteMinder policy server.
NOTE: The instructions shown here are for SiteMinder policy server version 5.5.
Instructions may vary slightly if you are using a different product version.
To configure SiteMinder to work with the IVE, you must:
1. “Configuring the SiteMinder Agent” on page 180
2. “Creating a SiteMinder Authentication Scheme for the IVE” on page 180
3. “Creating a SiteMinder Domain for the IVE” on page 182
4. “Creating a SiteMinder Realm for the IVE” on page 182
5. “Creating a Rule/Response Pair to Pass Usernames to the IVE” on page 183
6. “Creating a SiteMinder Policy Under the Domain” on page 185
Configuring an eTrust SiteMinder Server Instance

179
Juniper Networks Secure Access Administration Guide
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 IVE, you must configure the
IVE 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 IVE 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, (as explained in
“Creating a SiteMinder Realm for the IVE” on page 182) and when configuring
the IVE (as explained in “Agent Name, Secret” on page 188).
4. You must select the Support 5.x agents option for compatibility with the IVE.
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 IVE.
6. Under IP Address or Host Name, enter the name or IP address of the IVE.
7. In the Shared Secret fields, enter and confirm a secret for the Web agent. Note
that you need to enter this secret when configuring the IVE (as explained in
“Agent Name, Secret” on page 188).
8. Click OK.
Creating a SiteMinder Authentication Scheme for the IVE
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 IVE:
1. In the SiteMinder Administration interface, choose the System tab.
2. Right-click on Authentication Schemes and choose Create Authentication
Scheme.
180

Configuring an eTrust SiteMinder Server Instance
Chapter 8: Authentication and Directory Servers
3. Enter a name for the scheme and (optionally) a description. Note that you need
to enter this name when configuring the SiteMinder realm (as explained in
“Creating a SiteMinder Realm for the IVE” on page 182).
4. Under Authentication Scheme Type, select one of the following options:

Basic Template

HTML Form Template

SecurID HTML Form Template1

X509 Client Cert Template

X509 Client Cert and Basic Authentication
NOTE:

The IVE only supports the authentication scheme types listed here.

You must select HTML Form Template if you want the IVE to handle reauthentication (as described in “Reauthentication of Users with Insufficient
Protection Levels” on page 178).

If you select X509 Client Cert Template or X509 Client Cert and Basic
Authentication, you must import the certificate into the IVE through the
System > Certificates > Trusted Client CAs tab. For more information, see
“Using Trusted Client CAs” on page 738.
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. For more
information, see “Creating a SiteMinder Realm for the IVE” on page 182.
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 IVE 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 IVE host name (for example,
sales.yourcompany.net).

Select the Use SSL Connection checkbox.
1. 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 IVE.
Configuring an eTrust SiteMinder Server Instance

181
Juniper Networks Secure Access Administration Guide

Under Target, enter the IVE sign-in URL defined in this step’s first bullet
plus the parameter “ive=1” (for example, /highproturl?ive=1). (The IVE
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 IVE, 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.
NOTE:

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.

For information about configuring the IVE to handle multiple authentication
schemes, see “Configuring the IVE to Work with Multiple Authentication
Schemes” on page 185.
Creating a SiteMinder Domain for the IVE
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 IVE to work with SiteMinder, you must give IVE
users access to a SiteMinder resource within a realm, and then group the realm into
a domain.
To configure a SiteMinder domain for the IVE, in the SiteMinder Administration
interface, choose the System tab, right-click on Domains and choose Create
Domain. Or, click on Domains and choose an existing SiteMinder domain. Note
that you need to add a realm to this domain (as explained in “Creating a SiteMinder
Realm for the IVE” on page 182).
Creating a SiteMinder Realm for the IVE
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 IVE, you must define realms to determine which resources IVE users may
access.
To configure a SiteMinder realm for the IVE:
1. In the SiteMinder Administration interface, choose the Domains tab.
2. Expand the domain that you created for the IVE. For more information, see
“Creating a SiteMinder Domain for the IVE” on page 182.
182

Configuring an eTrust SiteMinder Server Instance
Chapter 8: Authentication and Directory Servers
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 IVE. For more
information, see “Configuring the SiteMinder Agent” on page 180.
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 IVE (as explained in “Protected
Resource” on page 188). Or, if you use sign-in policies with non-default 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 IVE (as explained in “Creating a SiteMinder Authentication Scheme for the
IVE” on page 180).
8. Click OK.
Creating a Rule/Response Pair to Pass Usernames to the IVE
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 IVE, 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 IVE 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 IVE (as explained in “Creating a
SiteMinder Domain for the IVE” on page 182) and then expand Realms.
3. Right-click on the realm that you created for the IVE (as explained in “Creating
a SiteMinder Realm for the IVE” on page 182) 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.
Configuring an eTrust SiteMinder Server Instance

183
Juniper Networks Secure Access Administration Guide
2. Expand the domain that you created for the IVE (as explained in “Creating a
SiteMinder Domain for the IVE” on page 182).
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 IVE Web agent (as explained in
“Configuring the SiteMinder Agent” on page 180).
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.
Creating SiteMinder User Attributes for IVE Role Mapping
If you create SiteMinder user attributes on a SiteMinder policy server, you can use
those user attributes in IVE role mapping rules to map users to roles. For example,
you might want to map users to various IVE roles based on their department. To
use a SiteMinder user attribute in a role mapping rule, you reference the cookie
name contained in the SiteMinder user attribute cookie.
The following procedure is required only if you want to use SiteMinder user
attributes in IVE role mapping rules.
To create user attributes on a SiteMinder server:
1. In the SiteMinder Administration interface, choose the Domains tab.
2. Expand the domain that you created for the IVE (as explained in “Creating a
SiteMinder Domain for the IVE” on page 182).
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 IVE Web agent (as explained in
“Configuring the SiteMinder Agent” on page 180).
6. Click Create.
7. From the Attribute list, select WebAgent-HTTP-Cookie-Variable.
8. Under Attribute Kind, select User Attribute.
9. For Cookie Name, enter a name for the cookie, such as department. You can
reference this cookie name in an IVE role mapping rule.
184

Configuring an eTrust SiteMinder Server Instance
Chapter 8: Authentication and Directory Servers
10. For Attribute Name, enter the name of the attribute in the SiteMinder user
directory. (This refers to the attribute in the LDAP server that SiteMinder uses.)
11. Click OK.
12. Assign the User Attribute response to an OnAuthAccept type rule. (See
“Creating a Rule/Response Pair to Pass Usernames to the IVE” on page 183.)
13. Reference the cookie name in a role mapping rule for an IVE realm that uses
the SiteMinder policy server. For instructions, see “Using SiteMinder User
Attributes for IVE Role Mapping” on page 196.
Creating a SiteMinder Policy Under the Domain
Within SiteMinder, a policy associates users with rules. To configure a SiteMinder
policy under a domain, in the SiteMinder Administration interface, choose the
Domains tab, select the domain to which you want to add a policy, right-click on
Policies, and choose Create Policy.
Configuring the IVE to Work with SiteMinder
This section includes the following instructions for configuring the IVE to work with
a SiteMinder policy server:

“Configuring the IVE to Work with Multiple Authentication Schemes” on
page 185

“Configuring the IVE to Grant Users Different Protected Resources” on
page 186

“Defining an eTrust SiteMinder Server Instance” on page 187

“Defining a SiteMinder Realm for Automatic Sign-In” on page 197
Configuring the IVE to Work with Multiple Authentication Schemes
To configure the IVE to work with multiple SiteMinder authentication schemes, you
must:
1. Configure the authentication schemes on the SiteMinder policy server. For
instructions, see “Creating a SiteMinder Authentication Scheme for the IVE” on
page 180.
2. Create one IVE instance of the SiteMinder policy server for all SiteMinder
authentication schemes you want to use. For instructions, see “Defining an
eTrust SiteMinder Server Instance” on page 187.
3. Specify which IVE realm should use the IVE instance of the SiteMinder policy
server to authenticate and authorize administrators and users. For instructions,
see “Creating an Authentication Realm” on page 208.
Configuring an eTrust SiteMinder Server Instance

185
Juniper Networks Secure Access Administration Guide
4. For each protected resource on the SiteMinder policy server, create an IVE signin policy. In the Authentication > Authentication > Signing In Policies >
New Sign-In Policy page:

Specify an IVE sign-in URL that matches the SiteMinder protected resource
URL on the policy server. Make the path portion of the URL match the
SiteMinder resource filter in the SiteMinder realm configuration. For
example, you can specify */ACE/ as an IVE sign-in URL to match a
SiteMinder URL of XYZ/ACE, where XYZ is the name of a realm.

Select the IVE realm that you specified should use the SiteMinder policy
server.
For instructions, see “Configuring Sign-In Policies” on page 225.
The user signs into the IVE using one of the IVE sign-in URLs. The IVE sends the
protected resource URL to SiteMinder, and based on the resource, SiteMinder
determines which type of scheme to use to authenticate the user. The IVE collects
the credentials that the authentication scheme requires, and then passes them to
SiteMinder for authentication.
Configuring the IVE to Grant Users Different Protected Resources
To configure the IVE 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. For instructions, see “Creating a SiteMinder Realm for
the IVE” on page 182.
2. Create one IVE instance of the SiteMinder policy server for all protected
resources and corresponding protection levels that you want to allow. For
instructions, see “Defining an eTrust SiteMinder Server Instance” on page 187.
3. Specify which IVE realm should use the IVE instance of the SiteMinder policy
server. For instructions, see “Creating an Authentication Realm” on page 208.
4. For each resource on the SiteMinder policy server, create an IVE sign-in policy
for each realm-level resource filter. In the configuration page for the sign-in
policy, specify:

An IVE 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.
186

Configuring an eTrust SiteMinder Server Instance
Chapter 8: Authentication and Directory Servers

Select the IVE realm that you specified should use the SiteMinder policy
server.
For instructions, see“Configuring Sign-In Policies” on page 225.
During production, the user signs into the IVE using one of the URLs. The IVE
extracts the protected resource from the URL and authenticates the user against the
appropriate realm.
Defining an eTrust SiteMinder Server Instance
Within the IVE, a SiteMinder instance is a set of configuration settings that defines
how the IVE interacts with the SiteMinder policy server. After defining the
SiteMinder server instance, specify which IVE realm(s) should use the IVE instance
of the SiteMinder policy server to authenticate and authorize administrators and
users. For instructions, see “Creating an Authentication Realm” on page 208.
To define an eTrust SiteMinder server instance:
1. In the admin console, choose Authentication > Auth. Servers.
2. Do one of the following:

To create a new server instance on the IVE, 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 13.
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. (For information on
SiteMinder user attribute cookies, see “Creating SiteMinder User Attributes
for IVE Role Mapping” on page 184.)
c.
When you are finished adding cookie names, click OK. The IVE displays
the names of the SiteMinder user attribute cookies in the Attribute list on
the Role Mapping Rule page. For configuration instructions, see “Using
SiteMinder User Attributes for IVE Role Mapping” on page 196.
5. Click Save Changes.
6. Set advanced SiteMinder configuration options (optional) using the settings
described in Table 14.
NOTE: For information on monitoring and deleting the sessions of users who are
currently signed in through the server, see “Monitoring Active Users” on page 821.
Configuring an eTrust SiteMinder Server Instance

187
Juniper Networks Secure Access Administration Guide
Table 13: 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 IVE appliance use the main policy server unless
it fails.
 Select No to have the IVE appliance load balance among all the
specified policy servers.
Agent Name,
Secret
Enter the shared secret and agent name specified in “Configuring the
SiteMinder Agent” on page 180. Note that these are case-sensitive.
Compatible with
Choose a SiteMinder server version. Version 5.5 supports versions 5.5
and 6.0. Version 6.0 supports only version 6.0 of the SiteMinder server
API. The default value is 5.5 policy servers.
On logout, redirect to Specify a URL to which users are redirected when they sign out of the
IVE (optional). If you leave this field empty, users see the default IVE
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 specified in “Creating a SiteMinder
Realm for the IVE” on page 182. If you do not create sign-in policies for
SiteMinder, the IVE uses this default URL to set the user’s protection
level for the session. The IVE also uses this default URL if you select the
Automatic Sign-In option. If your users are signing in to the “*” URL
(default IVE sign-in page), enter any URL (“/IVE-authentication” is the
default) to set the protection level to the default IVE value. If you do
create sign-in policies for SiteMinder, the IVE uses those sign-in policies
instead of this default URL.
Note: You must enter a forward slash (/) at the beginning of the resource
(for example, “/ive-authentication”).
Resource Action
188

Configuring an eTrust SiteMinder Server Instance
(Read-only) For new SiteMinder server instances, the IVE sets the
resource action to GET. If your SiteMinder instance is upgraded from a
3.x instance, the IVE 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.
Chapter 8: Authentication and Directory Servers
Table 13: eTrust SiteMinder Configuration Options (Continued)
Option
Description
SMSESSION cookie settings
Cookie Domain
Enter the cookie domain of the IVE. (A cookie domain is a domain in
which the user’s cookies are active—The IVE 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 IVE as
“http://ive.juniper.net” in order to ensure that his SMSESSION cookie is
sent back to the IVE.
Protocol
(Read-only) Indicates that the IVE uses HTTPS protocol to send cookies
to the user’s Web browser.
IVE Cookie Domain
Enter the Internet domain(s) to which the IVE sends the SMSESSION
cookie using the same guidelines outlined for the Cookie Domain field.
(An IVE cookie domain enables single sign-on across multiple cookie
domains. It allows a user’s information to carry with him when he
navigates from one domain to another.) If you have configured a cookie
provider to enable single sign-on across multiple cookie domains, enter
the domain of the cookie provider. Otherwise, enter the domain(s) of
the Web agents for which single sign-on is desired. For example:
.juniper.net
Protocol
Choose HTTPS to send cookies securely if other Web agents are set up
to accept secure cookies, or HTTP to send cookies non-securely.
SiteMinder authentication settings
Automatic Sign-In
Select the Automatic Sign-In option to automatically sign in users who
have a valid SMSESSION cookie in to the IVE. 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 IVE realm, the IVE uses the
protection level associated with the cookie.
 In order to enable single sign-on from another Web agent to the IVE,
the IVE needs to validate an existing SMSESSION cookie created by a
standard Web agent.
 The IVE supports the following realm and role limitations with the
Automatic Sign-in feature: Host Checker, Cache Cleaner, IP address,
browser, and concurrent user limit checks. Certificate and password
restrictions are not supported since they are not applicable to
automatically signed-in users.
 The IVE 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:
Configuring an eTrust SiteMinder Server Instance

189
Juniper Networks Secure Access Administration Guide
Table 13: eTrust SiteMinder Configuration Options (Continued)
Option
Description
 To assign user roles, use this authentication realm
Select an authentication realm for automatically signed-in users. The
IVE maps the user to a role based on the role mapping rules defined
in the selected realm.
Note: If you map users to roles based on username, see “Determining
the User’s Username” on page 178 for information about which
username the IVE uses.
 If Automatic Sign In fails, redirect to
Enter an alternative URL for users who sign into the IVE through the
Automatic Sign-In mechanism explained in “Automatic Sign-In” on
page 189. The IVE redirects users to the specified URL if the IVE fails
to authenticate and no redirect response is received from the
SiteMinder policy server. If you leave this field empty, users are
prompted to sign back in to the IVE.
Note:
 Users who sign in through the IVE sign-in page are always
redirected back to the IVE sign-in page if authentication fails.
 If you are using the customizable UI (Custom Pages) option
explained in the Custom Sign-In Pages Solution Guide. note that the
IVE 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=timedout
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.
For more information on authorization-only access policies,
Authenticate using
custom agent
Choose this option if you want to authenticate using the IVE custom
Web agent. Note that if you select this option, you must also:
 Update all of your standard Web agents to the appropriate Siteminder
Agent Quarterly Maintenance Release (QMR) in order to accept the
cookies created by the IVE. If you are running SiteMinder version 5
Web agents, use the QMR5 hot fix. The IVE 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.
190

Configuring an eTrust SiteMinder Server Instance
Chapter 8: Authentication and Directory Servers
Table 13: eTrust SiteMinder Configuration Options (Continued)
Option
Description
Authenticate using
HTML form post
Choose this option if you want to post user credentials to a standard
Web agent that you have already configured rather than contacting the
SiteMinder policy server directly. If you select this option, the Web agent
contacts the policy server to determine the appropriate sign-in page to
display to the user. In order to configure the IVE 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=3
3554433&REALMOID=06-2525fa65-5a7f-11d5-9ee00003471b786c&GUID=&SMAUTHREASON=0&TARGET=$SM$http
%3a%2f%2fwebagent%2ejuniper%2enet%2fportal%2findex%2ejs
p
3. Extract information from the URL to enter in the fields that follow.
Note:
 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.
 The Authorize While Authenticating option is not applicable with
the HTML form post option.
 You can authenticate users using this option, but if you want to
authorize them as well, you must select Authenticate using custom
agent.
When you select the Authenticate using HTML form post option, you
must also configure the following sub-options:
 Target
URL on the external, eTrust-enabled Web server. In the Web agent
sign-in page URL, the target appears after &TARGET=$SM$. For
example, in the URL shown in “Authenticate using HTML form post”
on page 191, 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 IVE 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” on page 191, the protocol is HTTP.
Configuring an eTrust SiteMinder Server Instance

191
Juniper Networks Secure Access Administration Guide
Table 13: eTrust SiteMinder Configuration Options (Continued)
Option
Description
 Web Agent
Name of the Web agent from which the IVE 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” on page 191, 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” on page 191, 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 signin page and by the value specified in the Target field. These are the
default parameters for login.fcc—if you have made customizations,
you may need to change these parameters.
Delegate
authentication to a
standard agent
Choose this option if you want to delegate authentication to a standard
agent. When the user accesses the IVE sign-in page, the IVE determines
the FCC URL associated with the protected resource’s authentication
scheme. The IVE redirects the user to that URL, setting the IVE sign-in
URL as the target. After successfully authenticating with the standard
agent, an SMSESSION cookie is set in the user’s browser and he is
redirected back to the IVE. The IVE then automatically signs in the user
and establishes an IVE session. For information about configuring the
authentication scheme, see “Creating a SiteMinder Authentication
Scheme for the IVE” on page 180.
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, the IVE tries to
automatically sign in using the existing SMSESSION cookie. If the
cookie is invalid, the IVE clears the SMSESSION cookie and
corresponding IVE cookies and presents the user with a “timeout”
page. The IVE 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.
192

Configuring an eTrust SiteMinder Server Instance
Chapter 8: Authentication and Directory Servers
Table 13: eTrust SiteMinder Configuration Options (Continued)
Option
Description
Authorize requests
against SiteMinder
policy server
Select to use SiteMinder policy server rules to authorize user Web
resource requests. If you select this option, make sure that you create
the appropriate rules in SiteMinder that start with the server name
followed by a forward slash, such as: "www.yahoo.com/",
"www.yahoo.com/*", and "www.yahoo.com/r/f1". For more information,
please refer to the documentation provided with your SiteMinder server.
If you are using an authorization-only access policy, you must select this
option and enter values for the next three options (described below) in
order for the reverse proxy feature to work correctly. For more
information on authorization-only access policies, see “Defining
authorization-only access policies” on page 227.
If authorization fails,
redirect to
Enter an alternative URL that users are redirected to if the IVE fails to
authorize and no redirect response is received from the SiteMinder
policy server. If you leave this field empty, users are prompted to sign
back in to the IVE.
Note:
 If you are using an authorization-only access policy , you must
enter an alternative URL in this field regardless of whether the
Authorize requests against SiteMinder policy server option is
selected. Users are redirected to this URL when an access denied
error occurs. For more information on authorization-only access
policies, see “Defining authorization-only access policies” on
page 227.
Configuring an eTrust SiteMinder Server Instance

193
Juniper Networks Secure Access Administration Guide
Table 13: eTrust SiteMinder Configuration Options (Continued)
Option
Description
Resource for
insufficient
protection level
Enter a resource on the Web agent to which the IVE redirects users
when they do not have the appropriate permission.
When user accesses a resource with protection level higher than the one
in his SMSESSION cookie, he gets a secured sign-in page. Then after he
re-authenticates, he obtains a SMSESSION cookie with the higher
protection level and gets redirected to a Web page. The type of web page
IVE displays depends on which method you use to re-authenticate
users*:
 A standard Web agent with "FCCCompatMode = yes"
If you set your Web agent’s forms credential collector (FCC)**
compatibility mode to yes, users are redirected to page you specify in
the Resource for insufficient protection level field.
Note:
- You must redirect users to a page on the standard Web agent. The
IVE cannot direct the user to the original resource that he wanted to
access.
- You do not need to enter the entire URL leading to the resource (for
example:
https://sales.yourcompany.com/,DanaInfo=www.stdwebagent.com+inde
x.html)—you only need to enter the resource (index.html).
 A standard Web agent with "FCCCompatMode = no"
If you set your Web agent’s forms credential collector (FCC)**
compatibility mode to yes, users are redirected to page you specify in
the Resource for insufficient protection level field. Or, if you leave
this field empty, the user is redirected to the original resource that he
wanted to access.
 The IVE
If you re-authenticate users through the IVE, users are redirected to
the IVE intermediate page described in “Reauthentication of Users
with Insufficient Protection Levels” on page 178. Note that if you
want the IVE to redirect the user to the original resource that he
wanted to access, you must enable the Browser request follow
through option on the Users > User Roles > [Role] > General >
Session Options page of the admin console. (If you leave this field
empty but do not enable the Browser request follow through option,
the IVE redirects the user to the standard IVE user’s bookmark page.)
* For information about specifying a re-authentication method, see
“Creating a SiteMinder Authentication Scheme for the IVE” on
page 180.
** When a user makes a request to a protected resource, SiteMinder
routes it to a forms credential collector (FCC) which then invokes a Web
form on the policy server to collect credentials.
Ignore authorization
for files with
extensions
Enter file extensions corresponding to file types that do not require
authorization. You must enter the extensions of each file type that you
want to ignore, separating each with a comma. For example, enter “.gif,
.jpeg, .jpg, .bmp” to ignore various image types. You cannot use
wildcards characters (such *, *.*, or .*) to ignore a range of file types.
Table 14: eTrust SiteMinder Advanced Configuration Options
194

Option
Description
Poll Interval
Enter the interval at which IVE polls the Siteminder policy server to
check for a new key.
Configuring an eTrust SiteMinder Server Instance
Chapter 8: Authentication and Directory Servers
Table 14: eTrust SiteMinder Advanced Configuration Options (Continued)
Option
Description
Max. Connections
Controls the maximum number of simultaneous connections that the
IVE is allowed to make to the policy server. The default setting is 20.
Max. Requests/
Connection
Controls the maximum number of requests that the policy server
connection handles before the IVE ends the connection. If necessary,
tune to increase performance. The default setting is 1000.
Idle Timeout
Controls the maximum number of minutes a connection to the policy
server may remain idle (the connection is not handling requests) before
the IVE ends the connection. The default setting of “none” indicates no
time limit.
Authorize while
Authenticating
Specifies that the IVE should look up user attributes on the policy server
immediately after authentication to determine if the user is truly
authenticated. For example, if your eTrust server authenticates users
based on an LDAP server setting, you can select this option to indicate
that the IVE 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 the IVE. Not until the user tries to
access a protected resource does the IVE check his authorization
rights and deny him access.
 The IVE 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 described in “Authenticate using HTML form post” on
page 191 or the Automatic sign-in option described in “Automatic
Sign-In” on page 189.
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 the IVE
should consider the cookie valid for a certain period of time. During that
period, the IVE assumes that its cached cookie is valid rather than revalidating it against the policy server. If you do not select this option, the
IVE checks the user’s SMSESSION cookie on each request. Note that the
value entered here does not affect session or idle timeout checking.
Configuring an eTrust SiteMinder Server Instance

195
Juniper Networks Secure Access Administration Guide
Table 14: eTrust SiteMinder Advanced Configuration Options (Continued)
Option
Description
Ignore Query Data
By default, when a user requests a resource, the IVE sends the entire
URL for that resource to the policy server (including the query
parameter, if present). For example, the IVE may send the following URL
to the policy server: http://foo/bar?param=value. (Query data appears
after the ? character in the URL. Within this URL, param=value
represents the query parameter.)
The IVE 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.
The IVE 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, the IVE 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.
Accounting Port
The value entered in this field must match the accounting port value
entered through the Policy Server Management Console. By default, this
field matches the policy server’s default setting of 44441.
Authentication Port
The value entered in this field must match the authentication port value
entered through the Policy Server Management Console. By default, this
field matches the policy server’s default setting of 44442.
Authorization Port
The value entered in this field must match the authorization port value
entered through the Policy Server Management Console. By default, this
field matches the policy server’s default setting of 44443.
Flush Cache
Use to delete the IVE’s resource cache, which caches resource
authorization information for 10 minutes.
Using SiteMinder User Attributes for IVE Role Mapping
After you create user attributes on a SiteMinder policy server (see “Creating
SiteMinder User Attributes for IVE Role Mapping” on page 184), you can use them
in role mapping rules for a realm that uses the SiteMinder policy server.
To use SiteMinder user attributes for IVE 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 IVE realm that
uses the SiteMinder policy server, choose Same as Above from the
Directory/Attribute list. (For instructions, see “Creating an Authentication
Realm” on page 208.)
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.
196

Configuring an eTrust SiteMinder Server Instance
Chapter 8: Authentication and Directory Servers
3. On the IVE Role Mapping tab, create a rule based on IVE 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 IVE user attributes on the IVE Role
Mapping tab. Then specify a value for the SiteMinder user attribute cookie, such
as sales. For instructions, see “Creating Role Mapping Rules” on page 211.
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")
Defining a SiteMinder Realm for Automatic Sign-In
SiteMinder Automatic Sign In requires a realm whose authentication server is the
SiteMinder server. If you perform an upgrade and you have already defined the
Automatic Sign In realm that does not specify the SiteMinder server for
authentication, and you have configured the SiteMinder server:

The realms do not appear in the SiteMinder realm list under SiteMinder
authentication settings in the admin console.

The upgrade process creates a new realm called eTrust-Auto-Login-Realm which
is based on your existing realm, but which configures the SiteMinder server as
its authentication server.
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, as described in “Defining an eTrust SiteMinder
Server Instance” on page 187.
4. Click Save Changes.
5. Configure the realm, as described in “Creating an Authentication Realm” on
page 208, 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.
Configuring an eTrust SiteMinder Server Instance

197
Juniper Networks Secure Access Administration Guide
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.
Debugging SiteMinder and IVE Issues
At some point, you may encounter problems configuring the eTrust SiteMinder
server interactions with the IVE. You can use a number of debugging tools to
identify and resolve problems:

Review the IVE log file. The IVE tracks failures of cookie validation, authorizing
requests, and key rollovers.

Review the Policy Server Authentication and Authorization log files.

Review the Standard Web Agent log file if you have selected the Authentication
using HTLM Form POST option.

Confirm that the IVE contains the proper suffix that you defined in the Cookie
Domain field. If the IVE is not properly addressed, the browser may not
forward the correct SMSESSION cookie to the IVE and you may not be able to
sign in. You must enter the IVE’s FQDN on the browser, not the IVE IP address,
otherwise, your login fails.

Confirm that the IVE 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 the IVE 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
IVE 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 a SAML Server Instance
The IVE 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 IVE first. and then to access the IVE
with single sign-on (SSO) through the SAML consumer service.
As a result, the user who authenticates elsewhere is able to access resources behind
the IVE without signing in again.
198

Configuring a SAML Server Instance
Chapter 8: Authentication and Directory Servers
Using the Artifact Profile and the POST Profile
The two supported profiles provide different methods of accomplishing the same
task. The end-user’s goal is to sign in to all desired resources once, without
experiencing multiple sign-in pages for different resources or applications. Although
the end-user wants transparency, you, the administrator, want to ensure complete
security across the resources on your system, regardless of the servers or sites
represented.
The artifact profile requires that you construct an automated request-response
HTTP message that the browser can retrieve based on an HTTP GET request. For
details about this method, see “Using the Artifact Profile Scenario” on page 199.
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. For more details about this method, see
“Using the POST Profile Scenario” on page 200.
Using the Artifact Profile Scenario
The SAML server generally supports the following artifact profile scenario:
1. The user accesses a source site via a browser. The source site might be a
corporate portal using a non-IVE authentication access management system.
2. The source site challenges the user for username and password.
3. The user provides username and password, which the source site authenticates
through a call to an LDAP directory or other authentication server.
4. The user then clicks on a link on the source site, which points to a resource on a
server that is protected behind the IVE.
5. The link redirects the user to the Intersite Transfer Service URL on the source
site. The source site pulls an authentication assertion message from its cache
and encloses it in a SOAP message. The source site constructs a SAML artifact (a
Base64 string) that it returns to the browser in a URI along with the destination
and assertion address.
6. The destination site queries the authenticated assertion from the source site,
based on the artifact it receives from the source site.
7. If the elapsed time falls within the allowable clock skew time, the IVE accepts
the assertion as a valid authentication, and the user meets any other IVE policy
restrictions, the IVE grants the user access to the requested resource.
The main tasks you are required to fulfill to support the IVE as the relying party with
the artifact profile include:

Implement the assertion consumer service, which:

Receives the redirect URL containing the artifact

Generates and sends the SAML request

Receives and processes the SAML response
Configuring a SAML Server Instance

199
Juniper Networks Secure Access Administration Guide

Integrate the assertion consumer service with the existing IVE process, which:

Maps the SAML assertion to a local user

Creates an IVE user session

Performs local authorization

Serves the resource or denies access
Using the POST Profile Scenario
The SAML server generally supports the POST profile scenario, as follows:
1. The end-user accesses the source Web site, hereafter known as the source site.
2. The source site verifies whether or not the user has a current session.
3. If not, the source site prompts the user to enter user credentials.
4. The user supplies credentials, for example, username and password.
5. If the authentication is successful, the source site authentication server creates
a session for the user and displays the appropriate welcome page of the portal
application.
6. The user then selects a menu option or link that points to a resource or
application on a destination Web site.
7. The portal application directs the request to the local inter-site transfer service,
which can be hosted on the source site. The request contains the URL of the
resource on the destination site, in other words, the TARGET URL.
8. The inter-site transfer service sends an HTML form back to the browser. The
HTML FORM contains a SAML response, within which is a SAML assertion. The
response must be digitally signed. Typically the HTML FORM will contain an
input or submit action that will result in an HTTP POST. This can be a userclickable Submit button or a script that initiates the HTTP POST
programmatically.
9. The browser, either due to a user action or by way of an auto-submit action,
sends an HTTP POST containing the SAML response to the destination Web
site’s assertion consumer service.
10. The replying party's assertion consumer (in this case, on the destination Web
site) validates the digital signature on the SAML Response.
11. If valid, the assertion consumer sends a redirect to the browser, causing the
browser to access the TARGET resource.
12. The IVE, 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 IVE returns the TARGET resource to the browser.
200

Configuring a SAML Server Instance
Chapter 8: Authentication and Directory Servers
The main tasks you are required to fulfill to support the IVE 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 IVE process, which:

Maps the SAML assertion to a local user

Creates an IVE user session

Performs local authorization

Serves the resource or denies access
Understanding Assertions
Each party in the request-response communication must adhere to certain
requirements. The requirements provide a predictable infrastructure so that the
assertions and artifacts can be processed correctly.


The artifact is a Base64-encoded string of 40 bytes. An artifact acts as a token
that references an assertion on the source site, so the artifact holder—the IVE—
can authenticate a user who has signed in to the source site and who now
wants to access a resource protected by the IVE. The source site sends the
artifact to the IVE in a redirect, after the user attempts to access a resource
protected by the IVE. The artifact contains:

TypeCode—2-byte hex code of 0x0001 that identifies the artifact type.

SourceID—20-byte encrypted string that determines the source site
identity and location. The IVE maintains a table of SourceID values and the
URL for the corresponding SAML responder. The IVE and the source site
communicate this information in a back channel. On receiving the SAML
artifact, the IVE determines whether or not the SourceID belongs to a
known source site, and, if it does, obtains the site location before sending a
SAML request. The source site generates the SourceID by computing the
SHA-1 hash of the source site’s own URL.

AssertionHandle—20-byte random value that identifies an assertion stored
or generated by the source site. At least 8 bytes of this value should be
obtained from a cryptographically secure RNG or PRNG.
The inter-site transfer service is the identity provider URL on the source site
(not the IVE). Your specification of this URL in the admin console enables the
IVE to construct an authentication request to the source site, which holds the
user’s credentials in cache. The request is similar to the following example:
GET http://<inter-site transfer host name and path>?TARGET=<Target>…<HTTPVersion><other HTTP 1.0 or 1.1 components>
Configuring a SAML Server Instance

201
Juniper Networks Secure Access Administration Guide
In the preceding sample, <inter-site transfer host name and path> consists of the
host name, port number, and path components of the inter-site transfer URL at
the source and where Target=<Target> specifies the requested target resource
at the destination (IVE protected) site. This request might look like:
GET http://10.56.1.123:8002/xferSvc?TARGET=http://www.dest.com/sales.htm

The inter-site transfer service redirects the user’s browser to the assertion
consumer service at the destination site—in this case, the IVE. The HTTP
response from the source site inter-site transfer service must be in the
following format:
<HTTP-Version> 302 <Reason Phrase>
<other headers>
Location : http://<assertion consumer host name and path>?<SAML
searchpart><other HTTP 1.0 or 1.1 components>
In the preceding sample, <assertion consumer host name and path> provides
the host name, port number, and path components of an assertion consumer
URL at the destination site and where <SAML searchpart>= …TARGET=<Target>
…SAMLart=<SAML artifact>… consists of one target description, which must be
included in the <SAML searchpart> component. At least one SAML artifact must
be included in the SAML <SAML searchpart> component. The asserting party
can include multiple SAML artifacts.
NOTE:

You can use status code 302 to indicate that the requested resource
resides temporarily under a different URI.

If <SAML searchpart> contains more than one artifact, all of the artifacts
must share the same SourceID.
The redirect might look like:
HTTP/1.1 302 Found
Location:
http://www.ive.com:5802/artifact?TARGET=/www.ive.com/&SAMLart=artifact

The user's browser accesses the assertion consumer service, with a SAML
artifact representing the user's authentication information attached to the URL.
The HTTP request must appear as follows:
GET http://<assertion consumer host name and path>?<SAML searchpart>
<HTTP-Version><other HTTP 1.0 or 1.1 request components>
In the preceding sample, <assertion consumer host name and path> provides
the host name, port number, and path components of an assertion consumer
URL at the destination site.
<SAML searchpart>= …TARGET=<Target>…SAMLart=<SAML artifact> …
202

Configuring a SAML Server Instance
Chapter 8: Authentication and Directory Servers
A single target description MUST be included in the <SAML searchpart>
component. At least one SAML artifact MUST be included in the <SAML
searchpart> component; multiple SAML artifacts MAY be included. If more than
one artifact is carried within <SAML searchpart>, all the artifacts MUST have the
same SourceID.
You should not expose the assertion consumer URL unless over SSL 3.0 or TLS
1.0. Otherwise, transmitted artifacts might be available in plain text to an
attacker.

The issuer value is typically the URL of the source site. You can specify the
<ISSUER> variable which will return the issuer value from the assertion.

The user name template is a reference to the SAML name identifier element,
which allows the asserting party to provide a format for the user name. The
SAML specification allows for values in the following formats:

Unspecified—indicates that interpretation of the content is left up to the
individual implementations. In this case, you can use the variable
assertionName.

Email Address—indicates that content is in the form of an email address.
In this case, you can use the variable assertionName.

X.509 Subject Name—indicates that the content is in the form of an X.509
subject name. In this case, you can use the variable
assertionNameDN.<RDN>.

Windows Domain Qualified Name—indicates that the content is a string
in the form of DomainName\Username.
You should define the user name template to accept the type of user name your
SAML assertion contains.

To prevent eavesdropping on the SAML artifact, source and destination sites
should synchronize their clocks as closely as possible. The IVE provides an
Allowed Clock Skew attribute that dictates the maximum time difference
allowed between the IVE and the source site. The IVE rejects any assertions
whose timing exceeds the allowed clock skew.
Creating a new SAML Server Instance
To create a new SAML server instance, and configure the common elements:
1. In the admin console, choose Authentication > Auth. Servers.
2. Select SAML Server from the New list, and then click New Server.
3. Specify a name to identify the server instance.
4. Under Settings, specify the Source Site Inter-Site Transfer Service URL.
5. Specify the issuer value for the source site. Typically the URI or hostname of
the issuer of the assertion.
Configuring a SAML Server Instance

203
Juniper Networks Secure Access Administration Guide
6. Specify the user name template, which is a mapping string from the SAML
assertion to an IVE user realm. For example, enter <assertionNameDN.CN>,
which derives the username from the CN value in the assertion. For more
information about allowable values for this object, see “Configuring a SAML
Server Instance” on page 198.
7. Specify the Allowed Clock Skew value, in minutes. This value determines the
maximum allowed difference in time between the IVE clock and the source site
clock.
8. Proceed to define the configuration for either the artifact profile, as described
in “Configuring the SAML Server Instance to Use an Artifact Profile” on
page 204 or for the POST profile as described in “Configuring the SAML Server
Instance to Use the POST Profile” on page 204.
Configuring the SAML Server Instance to Use an Artifact Profile
To configure the SAML Server to use an artifact profile, continue the following
procedure from the last step in “Creating a new SAML Server Instance” on
page 203.
1. On the New SAML Server page, enter the Source ID. The source ID is the 20byte identifier that the IVE uses to recognize an assertion from a given source
site.
2. Enter the Source SOAP Responder Service URL. You should specify this URL in
the form of an HTTPS: protocol.
3. Choose the type of SOAP Client Authentication.

If you choose HTTP Basic, you must then enter the username and
password, and confirm the password.

If you choose SSL Client Certificate, choose an IVE certificate from the
drop down menu.
4. Click Save Changes. If you are creating the server instance for the first time, the
Settings and Users tabs appear.
The Settings tab allows you to modify any of the settings pertaining to the
SAML Server instance and the artifact profile. The Users tab lists valid users of
the server.
Configuring the SAML Server Instance to Use the POST Profile
To configure the SAML Server to use a POST profile, continue the following
procedure from the last step in “Creating a new SAML Server Instance” on
page 203.
1. On the New SAML Server page, select the Post option.
2. Enter the name of, or browse to locate, the Response Signing Certificate. This is
the PEM-formatted signing certificate, which is loaded for the SAML response
signature verification.
204

Configuring a SAML Server Instance
Chapter 8: Authentication and Directory Servers
The certificate you select should be the same certificate used for signing the
SAML response at the source site. The source site may send this certificate
along with the SAML response, depending on the source site configuration. By
default, the system performs signature verification of the SAML response first
on the locally configured certificate. If a certificate is not configured locally in
the SAML authentication server, then the system performs the signature
verification on the certificate included in the SAML response from the source
site.
3. Select the Enable Signing Certificate status checking option if you want the
IVE to be able to check the validity of the signing certificate configured in the
SAML authentication server POST profile. It is possible that the certificate has
already expired is has been revoked.
4. If you already have a certificate loaded and want to use another, locate the
certificate, then click Delete. You can then install another certificate.
5. Click Save Changes. If you are creating the server instance for the first time,
the Settings and Users tabs appear.
The Settings tab allows you to modify any of the settings pertaining to the
SAML Server instance and the artifact profile. The Users tab lists valid users of
the server.
Configuring a SAML Server Instance

205
Juniper Networks Secure Access Administration Guide
206

Configuring a SAML Server Instance
Chapter 9
Authentication Realms
An authentication realm specifies the conditions that users must meet in order to
sign into the IVE. A realm consists of a grouping of authentication resources,
including:

An authentication server, which verifies that the user is who he claims to be.
The IVE forwards credentials that a user submits on a sign-in page to an
authentication server. For more information, see “Authentication and Directory
Servers” on page 131.

A directory server, which is an LDAP server that provides user and group
information to the IVE that the IVE uses to map users to one or more user roles.
For more information, see “Authentication and Directory Servers” on page 131.

An authentication policy, which specifies realm security requirements that
need to be met before the IVE submits a user's credentials to an authentication
server for verification. For more information, see “Defining Authentication
Policies” on page 210.

Role mapping rules, which are conditions a user must meet in order for the
IVE 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. For more information, see “Creating Role Mapping Rules” on
page 211.
This section contains the following information about authentication realms:

“Licensing: Authentication Realms Availability” on page 208

“Creating an Authentication Realm” on page 208

“Defining Authentication Policies” on page 210

“Creating Role Mapping Rules” on page 211

“Customizing User Realm UI Views” on page 220

207
Juniper Networks Secure Access Administration Guide
Licensing: Authentication Realms Availability
Authentication realms are an integral part of the IVE access management
framework, and therefore are available on all Secure Access products. Note,
however that custom expressions are not available on the SA 700 appliance and are
only available on all other Secure Access products by special license. Therefore,
when creating a realm, not all administrators can create advanced role-mapping
rules using custom expressions.
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 IVE (optional).
NOTE: If the LDAP server is down, user authentication fails. You can find messages
and warnings in the event log files. When an attribute server is down, user
authentication does not fail. Instead, the groups/attributes list for role mapping
and policy evaluation is empty.
208

Licensing: Authentication Realms Availability
Chapter 9: Authentication Realms
7. If you want to submit secondary user credentials to an SSO-enabled resource or
enable two-factor authentication to access the IVE (as explained in “Multiple
Sign-In Credentials Overview” on page 237), 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 IVE 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, the IVE 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 IVE 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 the End session if authentication against this server fails if you
want to control access to the IVE 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 (as explained in
“Understanding Dynamic Policy Evaluation” on page 55), 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 IVE to
perform an automatic policy evaluation of all currently signed-in 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.)
NOTE: If you select Dynamic policy evaluation and you do not select Refresh
roles and Refresh resource policies, the IVE evaluates the realm’s authentication
policy, role mapping rules, and role restrictions only.
Creating an Authentication Realm

209
Juniper Networks Secure Access Administration Guide
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.
NOTE: Since dynamic policy evaluation can potentially impact system
performance, keep these guidelines in mind:

Since automatic (timer-based) refreshing of user roles and resource policies
can affect system performance, you can improve performance by disabling
either or both of the Refresh roles and Refresh resource policies options to
reduce the scope of the refresh.

To improve performance, set the Refresh interval option to a longer time
period.

Use the Refresh Now button at times when users may not be affected.
9. Click Save Changes to create the realm on the IVE. 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 as described in “Creating Role
Mapping Rules” on page 211.
b.
Configure an authentication policy for the realm as described in “Defining
Authentication Policies” on page 210.
Defining Authentication 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 the IVE 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 the IVE
presents the corresponding sign-in page to the user and then forwards the user's
credentials to the appropriate authentication server. If this server successfully
authenticates the user, then the IVE moves on to the role evaluation process.
To specify an authentication realm policy:
1. In the admin console, choose Administrators > Admin Realms or Users >
User Realms.
2. On the respective Authentication Realms page, click a realm and then click
the Authentication Policy tab.
210

Defining Authentication Policies
Chapter 9: Authentication Realms
3. On the Authentication Policy page, configure one or more of the access
management options described in the following sections:

“Specifying Source IP Access Restrictions” on page 58

“Specifying Browser Access Restrictions” on page 59

“Specifying Certificate Access Restrictions” on page 62

“Specifying Password Access Restrictions” on page 63

“Specifying Host Checker Access Restrictions” on page 64

“Specifying Cache Cleaner Access Restrictions” on page 641
Creating Role Mapping Rules
Role mapping rules are conditions a user must meet in order for the IVE 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.
(For administrators, you create role mapping rules on the Administrators >
Admin Realms > [Realm] > Role Mapping tab. For users, you create role
mapping rules on the Users > User Realms > [Realm] > Role Mapping tab.)
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:
1. Specify the type of condition on which to base the rule. Options include:

Username

User attribute

Certificate or certificate attribute

Group membership

Custom expressions
2. Specify the condition to evaluate, which consists of:
a.
Specifying one or more usernames, user attributes, certificate attributes,
groups (LDAP), or expressions depending on the type of condition selected
in step 1.
1. Not available in administrator realms.
Creating Role Mapping Rules

211
Juniper Networks Secure Access Administration Guide
b.
Specifying 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.
3. Specify the roles to assign to the authenticated user.
The IVE 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, the IVE
evaluates the definition for each role to determine if the user complies with any
role restrictions. The IVE uses this information to compile a list of valid roles, which
are roles for which the user meets any additional requirements. Finally, the IVE
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.
For more information about roles, see “User Roles” on page 83. For more
information about specifying role mapping rules, see “Specifying Role Mapping
Rules for an Authentication Realm” on page 212.
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. For
information about this catalog, see “Using the LDAP Server Catalog” on page 214.
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:
212

Creating Role Mapping Rules

Username—Username is the IVE username entered on the sign-in page.
Choose this option if you want to map users to roles based on their IVE
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.
Chapter 9: Authentication Realms
I

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.
The IVE 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, see “Using the LDAP Server Catalog” on page 214).

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 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, the IVE
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 IVE 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.
Creating Role Mapping Rules

213
Juniper Networks Secure Access Administration Guide
b.
Specifying to what the value(s) should equate, which may include a list of
IVE 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.
b.
Check Stop processing rules when this rule matches if you want the IVE
to stop evaluating role mapping rules if the user meets the conditions
specified for this rule.
7. Click Save Changes to create the rule on the Role Mapping tab. When you are
finished creating rules:

Make sure to order them in the order in which you want the IVE to evaluate
them. This task is particularly important when you want to stop processing
role mapping rules upon a match.

Specify whether or not you want to merge settings for all assigned roles.
See “Permissive Merge Guidelines” on page 85.
Using the LDAP Server Catalog
The LDAP server catalog is a secondary window through which you specify
additional LDAP information for the IVE to use when mapping users to roles,
including:

214

Creating Role Mapping Rules
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 IVE server catalog. Note that the IVE maintains a local copy of
the LDAP server’s values; attributes are not added to or deleted from your
LDAP server’s dictionary.
Chapter 9: Authentication Realms

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 IVE
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.

Expressions—The Server Catalog Expressions tab provides a mechanism to
write custom expressions for the role mapping rule. For more information
about custom expressions, see “Writing Custom Expressions” on page 1013.
To display the LDAP server catalog:
1. After choosing the User attribute option on the Role Mapping Rule page (see
“Specifying Role Mapping Rules for an Authentication Realm” on page 212),
click Update to display the Attribute list and the Attributes button.
2. 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 28: Server Catalog > Attributes Tab — Adding an Attribute for LDAP
Creating Role Mapping Rules

215
Juniper Networks Secure Access Administration Guide
Figure 29: Attribute Added in Server Catalog is Available for Role Mapping Rule
216

Creating Role Mapping Rules
Chapter 9: Authentication Realms
Figure 30: Server Catalog > Groups Tab — Adding LDAP Groups
Creating Role Mapping Rules

217
Juniper Networks Secure Access Administration Guide
Figure 31: Server Catalog > Groups Tab — Adding Active Directory Groups
218

Creating Role Mapping Rules
Chapter 9: Authentication Realms
Figure 32: Server Catalog > Expressions Tab — Adding a Custom Expression
Figure 33: Custom Expression Added in Server Catalog is Available for Role Mapping
Creating Role Mapping Rules

219
Juniper Networks Secure Access Administration Guide
Rule
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. 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. Navigate to Users > User Realms.
2. Select one of the following options from the View menu:
220

Customizing User Realm UI Views

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.
Chapter 9: Authentication Realms

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.
3. 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.
4. Click Update.
Customizing User Realm UI Views

221
Juniper Networks Secure Access Administration Guide
222

Customizing User Realm UI Views
Chapter 10
Sign-In Policies
Sign-in policies define the URLs that users and administrators use to access the IVE
and the sign-in pages that they see. The IVE 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 IVE, 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 IVE and the sign-in page that they
see. Or, if you have the proper license, you can create multiple user sign-in policies,
enabling different users to sign into different URLs and pages.
Additionally, appliances equipped with a Secure Meeting license come with a
meeting URL. You can use this URL to control the sign-in page that users see when
they sign into a meeting on the IVE appliance. If you have the proper license, you
may also create additional meeting sign-in pages, enabling different Secure Meeting
users to sign into different URLs and pages.
You can create multiple sign-in policies, associating different sign-in pages with
different URLs. When configuring a sign-in policy, you must associate it with a
realm or realms. Then, only members of the specified authentication realm(s) may
sign in using the URL defined in the policy. Within the sign-in policy, you may also
define different sign-in pages to associate with different URLs.
For example, you can create sign-in policies that specify:

Members of the “Partners” realm can sign in to the IVE 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 IVE 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 IVE 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.

223
Juniper Networks Secure Access Administration Guide
NOTE: If a user attempts to sign in while there is another active user session with
the same sign-in credentials, the IVE 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 IVE creates
the new user session and terminates the existing session.
NOTE: When enabling multiple sign-in URLs, note that in some cases the IVE 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 IVE creates these cookies
when the user signs into the IVE. (When a user signs into the IVE, the IVE
responds with a cookie that includes the sign-in domain of the URL. The IVE then
attaches this cookie to every IVE request the user makes.) Generally, these cookies
ensure that the IVE displays the correct sign-in URL and page to the user. For
example, if a user signs into the IVE using the URL
http://yourcompany.net/employees and then her session times out, the IVE 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 IVE
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 IVE 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 IVE using the sign-in URL
http://yourcompany.net/employees. Then she may try to access an IVE 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 IVE 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.
This section contains the following information about sign-in policies:
224


“Licensing: Sign-In Policies and Pages Availability” on page 225

“Task summary: Configuring Sign-In Policies” on page 225

“Configuring Sign-In Policies” on page 225

“Configuring Sign-In pages” on page 231
Chapter 10: Sign-In Policies
Licensing: Sign-In Policies and Pages Availability
Sign-in policies and pages are an integral part of the IVE 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:

The ability to create multiple sign-in policies

The ability to create sign-in pages for Secure Meeting users

The ability to create and upload custom sign-in pages to the IVE
Task summary: Configuring Sign-In Policies
To configure sign-in policies, you must:
1. Create an authentication realm through one of the Administrators > Admin
Realms or 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. 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.
4. If you differentiate between URLs using host names, you must associate each
host name with its own certificate or upload a wildcard certificate into the IVE
using options in the System > Configuration > Certificates > Device
Certificates page.
Configuring Sign-In Policies
Sign-in policies define the URLs that users and administrators can use to access the
IVE, as explained in “Sign-In Policies” on page 223.
This section contains the following information about sign-in policies:

“Defining Sign-in Policies” on page 226

“Defining Meeting Sign-In Policies” on page 229

“Specifying the Order in Which Sign-In Policies are Evaluated” on page 230

“Enabling and Disabling Sign-In Policies” on page 230
Licensing: Sign-In Policies and Pages Availability  225
Juniper Networks Secure Access Administration Guide
Defining Sign-in Policies
To create or configure administrator or user sign-in policies:
1. In the admin console, choose 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 the
IVE using the access policy.
4. In the Sign-in URL field, enter the URL that you want to associate with the
policy. Use the format <host>/<path> where <host> is the host name of the
IVE, and <path> is any string you want users to enter. For example:
partner1.yourcompany.com/outside. To specify multiple hosts, use the * wildcard
character. For instance:

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. The IVE does not recognize wildcards in the URL path.
5. Enter a Description for the policy (optional).
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 the IVE, a
variation of the standard sign-in page, or a custom page that you create using
the customizable UI feature. For more information, see “Configuring Standard
Sign-In Pages” on page 232.
7. (User URLs only) In the Meeting URL field, select the meeting URL that you
want to associate with this sign-in policy. The IVE 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:

226

Configuring Sign-In Policies
User types the realm name—The IVE 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.
Chapter 10: Sign-In Policies

User picks from a list of authentication realms—The IVE only maps the
sign-in policy to the authentication realms that you choose. The IVE
presents this list of realms to the user or administrator when he signs-in to
the IVE and allows him to choose a realm from the list. (Note that the IVE
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, the IVE 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.
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. The IVE 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), the
IVE 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 the IVE.
With authorization-only access, there is no SSO from the IVE. 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. For more information, see “Defining an eTrust SiteMinder
Server Instance” on page 187.
To create or configure authorization-only access policies:
Configuring Sign-In Policies

227
Juniper Networks Secure Access Administration Guide
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 the IVE’s IP
address. The name must be unique among all virtual hostnames used in passthrough 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 the IVE is converted to a request to
http://www.xyz.com:8080/test1. The response of the converted request is sent
to the original requesting web browser.
4. In the Backend URL field, enter the URL for the remote server. You must
specify the protocol, hostname and port of the server. For example,
http://www.mydomain.com:8080/*.
When requests match the hostname in the Virtual Hostname field, the request
is transformed to the URL specified in the Backend URL field. The client is
directed to the backend URL unaware of the redirect.
5. Enter a Description for this policy (optional).
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)
For more information on these role options, see “Configuring Advanced Web
Browsing Options” on page 420, “Specifying Source IP Access Restrictions” on
page 58 and “Specifying Browser Access Restrictions” on page 59.
Ensure the user role you select has an associated Web Access policy. See
“Defining Resource Policies: Web Access” on page 425.
228

Configuring Sign-In Policies
Chapter 10: Sign-In Policies
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. See “Enabling ActiveSync” on page 1008.
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).
Defining Meeting Sign-In Policies
To create or configure meeting sign-in policies:
1. In the admin console, choose Authentication > Authentication > Signing In
Policies.
2. To create a new sign-in policy, click New URL. Or, to edit an existing policy,
click a URL in the Meeting URLs column.
3. Select Meeting.
4. In the Sign-in URL field, enter the URL that you want to associate with the
meeting policy. Use the format <host>/<path> where <host> is the host name
of the IVE, 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, the IVE constructs the meeting URL in the
notification email using the host name specified by the user when signing
into the IVE. For instance, a user might sign into the IVE using the
following URL from the previous example:
Configuring Sign-In Policies

229
Juniper Networks Secure Access Administration Guide
http://YourInternalServer.YourCompany.net
Then, if the user creates a meeting, the IVE 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. Enter a Description for the policy (optional).
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 the IVE, a variation of the standard sign-in pages, or customized
pages that you create using the customizable UI feature. For more information,
see “Configuring Standard Sign-In Pages” on page 232.
7. Click Save Changes.
Enabling and Disabling Sign-In Policies
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 checkbox at the top of the page.
3. Click Save Changes.
Specifying the Order in Which Sign-In Policies are Evaluated
The IVE evaluates sign-in policies in the same order that you list them on the Signin 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:
230

Configuring Sign-In Policies
Chapter 10: Sign-In Policies

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, the IVE 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, the IVE
displays the default administrator sign-in page. If you list the policies in the opposite
order, however, the IVE displays the custom administrator sign-in page to those
administrators who access the IVE using the yourcompany.com/admin URL.
Note that the IVE 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, the IVE displays
Joe’s custom sign-in page to him when he uses the yourcompany.com/marketing/joe
URL to access the IVE. He does not see the Marketing sign-in page, even though it is
listed and evaluated first, because the path portion of his URL does not exactly
match the URL defined in the first policy.
To change the order in which administrator sign-in policies are evaluated:
1. In the admin console, choose Authentication > Signing In > Sign-in
Policies.
2. Select a sign-in policy in the Administrator URLs, User URLs, or Meeting URLs
list.
3. Click the up and down arrows to change the selected policy’s placement in the
list.
4. Click Save Changes.
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 IVE 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 IVE. You can modify standard sign-in pages
through the Authentication > Signing In > Sign-in Pages tab of the admin
console. For more information, see “Configuring Standard Sign-In Pages” on
page 232.
Configuring Sign-In pages

231
Juniper Networks Secure Access Administration Guide

Customized sign-in pages—Customized sign-in pages are THTML pages that
you produce using the Template Toolkit and upload to the IVE in the form of an
archived ZIP file. The customized sign-in pages feature is a licensed feature that
enables you to use your own pages rather than having to modify the sign-in
page included with the IVE.
For more information on customized sign-in pages, see the Custom Sign-In Pages
Solution Guide.
Configuring Standard Sign-In Pages
Standard sign-in pages that come with the IVE include:

Default Sign-In Page—By default, the IVE displays this page to users when they
sign into the IVE.

Meeting Sign-In Page—By default, the IVE displays this page to users when
they sign into a meeting. This page is only available if you install a Secure
Meeting license on the IVE.
You can modify these pages or create new 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, choose Authentication > Signing In > Sign-in Pages.
2. If you are:

Creating a new page—Click New Page.

Modifying an existing page—Select the link corresponding to the page you
want to modify.
3. (New pages only) Under Page Type, specify whether this is an
administrator/user access page or a meeting page.
4. Enter a name to identify the page.
5. In the Custom text section, revise the default text used for the various screen
labels as desired. When adding text to the Instructions field, note that you may
format text and add links using the following HTML tags: <i>, <b>, <br>, <font>,
and <a href>. However, the IVE 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.
NOTE: If you use unsupported HTML tags in your custom message, the IVE may
display the end-user’s IVE home page incorrectly.
6. In the Header appearance section, specify a custom logo image file for the
header and a different header color.
232

Configuring Sign-In pages
Chapter 10: Sign-In Policies
7. In the Custom error messages section, revise the default text that is displayed
to users if they encounter certificate errors. (Not available for the Secure
Meeting sign-in page.)
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 IVE. Note that the IVE does not display images and other content
referenced in this HTML page. (Not available for the Secure Meeting sign-in
page.)
9. Click Save Changes. The changes take effect immediately, but users with active
sessions might need to refresh their Web browsers.
NOTE: Click Restore Factory Defaults to reset the sign-in page, IVE user home
page, and admin console appearance.
Configuring Sign-In pages

233
Juniper Networks Secure Access Administration Guide
234

Configuring Sign-In pages
Chapter 11
Single Sign-On
Single sign-on (SSO) is a process that allows pre-authenticated IVE users to access
other applications or resources that are protected by another access management
system without having to re-enter their credentials.
This section contains the following information about single-sign on features:

“Licensing: Single Sign-On Availability” on page 235

“Single Sign-On Overview” on page 235

“Multiple Sign-In Credentials Overview” on page 237

“Configuring SAML” on page 245

“Configuring SAML SSO Profiles” on page 248
Licensing: Single Sign-On Availability
All Secure Access products contain some single sign-on features. However, note
that the Remote SSO, SAML, and eTrust SSO advanced sign-in features are not
available on the SA 700. Additionally, the basic authentication, NTLM
intermediation, and Telnet SSO features are only available on the SA 700 appliance
if you have the Core Clientless Access upgrade license.
Single Sign-On Overview
The IVE provides several integration mechanisms that allow you to configure SSO
connections from the IVE to other servers, applications, and resources. SSO
mechanisms include:

Remote SSO—The IVE provides loose integration with any application that uses
a static POST action within an HTML form to sign in users. You can configure
the IVE to post IVE 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. For more information, see
“Remote SSO Overview” on page 393.
Licensing: Single Sign-On Availability

235
Juniper Networks Secure Access Administration Guide
236

Single Sign-On Overview

SAML—The IVE 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 the IVE
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
the IVE, without re-authenticating. For more information, see “Configuring
SAML” on page 245.

Basic authentication and NTLM intermediation to Intranet sites—The IVE
allows you to automatically submit IVE 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, the IVE 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 the IVE to use base-64 encoding to protect the cached
credentials. For more information, see “Defining a Single Sign-On Autopolicy”
on page 401.

Active Directory server—The IVE 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, the IVE submits cached credentials to NTLMprotected Web sites whose host names end in the DNS suffix configured in the
System > Network > Overview page of the admin console. For more
information, see “Configuring an Active Directory or NT Domain Instance” on
page 139.

eTrust SiteMinder policy server—When you authenticate IVE 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 the IVE 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 the IVE without re-authenticating. For more information, see
“Configuring an eTrust SiteMinder Server Instance” on page 174.

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. For more
information, see “Terminal Services” on page 555. You may also pass a
username to the Telnet/SSH server, as explained in “Terminal Services” on
page 555.

Email clients—When you enable the Email Client feature for a role and then
create a corresponding resource policy, you allow users to access standardsbased email such as Outlook Express, Netscape Communicator, or Qualcomm’s
Eudora without re-authenticating. For more information, see “Email Client” on
page 629.
Chapter 11: Single Sign-On
The IVE 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 IVE sign-in page and then submit those credentials during SSO. For
more information, see “Multiple Sign-In Credentials Overview” on page 237.
The remaining mechanisms (SAML, eTrust SiteMinder, and the Email Client) use
unique methods for enabling SSO from the IVE to the supported application. For
more information, see:

“Configuring SAML” on page 245

“Configuring SAML SSO Profiles” on page 248

“Configuring an eTrust SiteMinder Server Instance” on page 174

“Email Client” on page 629
Multiple Sign-In Credentials Overview
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 the IVE 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 the IVE.
This section contains the following information about multiple sign-in credentials:

“Task Summary: Configuring Multiple Authentication Servers” on page 237

“Task Summary: Enabling SSO to Resources Protected by Basic Authentication”
on page 238

“Task Summary: Enabling SSO to Resources Protected by NTLM” on page 238

“Multiple Sign-In Credentials Execution” on page 240
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. For configuration instructions, see
“Defining an Authentication Server Instance” on page 133.
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
Multiple Sign-In Credentials Overview

237
Juniper Networks Secure Access Administration Guide
For configuration instructions, see “Creating an Authentication Realm” on
page 208.
3. (Optional) Specify password length restrictions for the secondary
authentication server using settings in the following pages of the admin
console:

Users > User Realms > Select Realm > Authentication Policy >
Password

Administrators > Admin Realms > Select Realm > Authentication
Policy > Password
For configuration instructions, see “Specifying Password Access Restrictions”
on page 63.
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 an IVE host name that ends with the same prefix as your protected
resource using settings in the System > Network > Overview page of the
admin console. (The IVE 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 the
IVE to submit credentials, create autopolicies that enable basic authentication
intermediation single sign-on, and create bookmarks to the selected resources
using 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 the IVE 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 proxies to protect. You may specify individual
resources on the server or the entire server.
Task Summary: Enabling SSO to Resources Protected by NTLM
NOTE: The IVE supports web proxies that perform NTLM authentication. However,
the following case is not supported: a proxy exists between the IVE and the backend server and the back-end server performs the NTLM authentication.
238

Multiple Sign-In Credentials Overview
Chapter 11: Single Sign-On
To enable single sign-on to Web servers, Windows file servers, and Web proxies that
are protected by NTLM, you must:
1. Specify an IVE host name that ends with the same suffix as your protected
resource using settings in the System > Network > Overview page of the
admin console. (The IVE 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 IVE 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 the IVE 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 proxies to protect. You may specify individual
resources on the server or the entire server.
Multiple Sign-In Credentials Overview

239
Juniper Networks Secure Access Administration Guide
Multiple Sign-In Credentials Execution
The following diagram illustrates the process that the IVE 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 34: Collecting and Submitting Credentials from Multiple Servers
Step 1: The IVE Collects the User’s Primary Credentials
When the user signs in to the IVE, the IVE prompts him to enter his primary server
credentials. The IVE saves these credentials to submit to the SSO resource later, if
necessary. Note that the IVE saves the credentials exactly as the user enters them—
it does not pre-pend or append them with additional information such as the user’s
domain.
Step 2: The IVE Collects or Generates the User’s Secondary Credentials
You may configure the IVE to either manually collect or automatically generate the
user’s secondary set of credentials. If you configure the IVE to:

240

Manually collect the user’s secondary credentials—The user must enter his
secondary credentials directly after entering his primary credentials.
Multiple Sign-In Credentials Overview
Chapter 11: Single Sign-On

Automatically generate the user’s credentials—The IVE submits the values
you specified in the administration console during setup. By default, the IVE
uses the <username> and <password> variables, which hold the username and
password 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 the IVE to infer the user’s Active Directory username but
require the user to manually enter his Active Directory password. When the IVE
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: The IVE Authenticates the Primary Credentials
After the IVE collects all required credentials, it authenticates the user’s first set of
credentials against the primary authentication server. Then:

If the credentials successfully authenticate, the IVE 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, timesensitive passwords, you may choose to not store user passwords using the IVE
session variable. For more information, see “Configuring a RADIUS Server
Instance” on page 160.

If the credentials do not successfully authenticate, the IVE denies the user
access to the IVE.
Step 4: The IVE Authenticates the Secondary Credentials
After authenticating the primary credentials, the IVE authenticates the secondary
credentials. Then:

If the credentials successfully authenticate, the IVE stores them in the
<username[2]> and <password[2]> session variables and allows the user access
to the IVE. You may also access these variables using the syntax
<username@SecondaryServer> and <password@SecondaryServer>.
NOTE: If you authenticate against a RADIUS server that accepts dynamic, timesensitive passwords, you may choose to not store user passwords using the IVE
session variable. For more information, see “Configuring a RADIUS Server
Instance” on page 160.
Multiple Sign-In Credentials Overview

241
Juniper Networks Secure Access Administration Guide

If the credentials do not successfully authenticate, the IVE does not save them.
Depending on how you configure your authentication realm, the IVE may allow
or deny the user access to the IVE if his secondary credentials do not
successfully authenticate.
NOTE: 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: The IVE Submits Credentials to an SSO-Enabled Resource
After the user successfully signs in to the IVE, 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, the IVE submits
different credentials. If the user is trying to access a:

Web SSO, Terminal Services, or Telnet/SSH resource—The IVE 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, the IVE submits the user-specified credentials.
NOTE: The IVE 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 the IVE to submit credentials from one of these types of
primary authentication servers, the IVE submits credentials from the user’s
secondary authentication server instead. If these credentials fail, the IVE 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—The IVE submits credentials to the backend
server or proxy that is protecting the Web or file resource. Note that you cannot
disable NTLM authentication through the IVE—If a user tries to access a
resource that is protected by NTLM, the IVE automatically intermediates the
authentication challenge and submits credentials in the following order:
a.
242

Multiple Sign-In Credentials Overview
(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, the IVE submits
the specified credentials.
Chapter 11: Single Sign-On
a.
Cached credentials—If the IVE does not submit administrator-specified
credentials or the credentials fail, the IVE determines whether it has stored
credentials for the specified user and resource in its cache. (See below for
information about when the IVE caches credentials.) If available, the IVE
submits its stored credentials.
b.
Primary credentials—If the IVE does not submit cached credentials or the
credentials fail, the IVE submits the user’s primary IVE credentials provided
that following conditions are true:
c.

The resource is in the same Intranet zone as the IVE (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 the IVE 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, the IVE determines
whether it has secondary credentials for the user. If available, the IVE
submits the user’s secondary IVE credentials provided that the conditions
described for primary credentials are true.
d. Last-entered credentials—If the IVE does not submit secondary
credentials or if the credentials fail, the IVE determines whether it has
stored credentials for the specified user and a different resource in its
cache. (See below for information about when the IVE caches credentials.)
If available, the IVE submits its stored credentials provided the conditions
described for primary credentials are true.
e.

User-specified credentials (prompt)—If the IVE does not submit lastentered credentials or if the credentials fail, the IVE prompts the user to
manually enter his credentials in the intermediate sign-in page. If the user
selects the Remember password? checkbox, the IVE caches the userspecified credentials and, if necessary, resubmits them when the user tries
to access the same resource again. Note that when the IVE caches these
credentials, it remembers the specific user and resource, even after the user
signs out of the IVE.
Resource protected by a Web server or Web proxy using basic
authentication—The IVE submits credentials in the following order to the
backend server or proxy that is protecting the Web resource:
a.
Cached credentials—If the IVE does not submit administrator-specified
credentials or the credentials fail, the IVE determines whether it has stored
credentials for the specified user and resource in its cache. (See above for
information about when the IVE caches credentials.) If available, the IVE
submits its stored credentials.
Multiple Sign-In Credentials Overview

243
Juniper Networks Secure Access Administration Guide
b.
c.
Primary credentials—If the IVE does not submit cached credentials or the
credentials fail, the IVE submits the user’s primary IVE credentials provided
that following conditions are true:

The resource is in the same Intranet zone as the IVE (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 the IVE 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, the IVE determines
whether it has secondary credentials for the user. If available, the IVE
submits the user’s secondary IVE credentials provided that the conditions
described for primary credentials are true.
d. Last-entered credentials—If the IVE does not submit secondary
credentials or if the credentials fail, the IVE determines whether it has
stored credentials for the specified user and a different resource in its
cache. (See below for information about when the IVE caches credentials.)
If available, the IVE submits its stored credentials provided the conditions
described for primary credentials are true.
e.
User-specified credentials (prompt)—If the IVE does not submit lastentered credentials or if the credentials fail, the IVE prompts the user to
manually enter his credentials in the intermediate sign-in page. If the user
selects the Remember password? checkbox, the IVE caches the userspecified credentials and, if necessary, resubmits them when the user tries
to access the same resource again. Note that when the IVE caches these
credentials, it remembers the specific user and resource, even after the user
signs out of the IVE.
NOTE:
244


The IVE does not support the multiple credential authentication mechanism
described in this section with the Email client and SAML SSO mechanisms.

You cannot define an anonymous server, certificate server, or eTrust
SiteMinder server as a secondary authentication server.

If you define an eTrust SiteMinder server as your primary authentication
server, you cannot define a secondary authentication server.

The IVE 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.
Multiple Sign-In Credentials Overview
Chapter 11: Single Sign-On
For more information about how the IVE uses multiple authentication within the
larger IVE authentication and authorization process, see “Policies, Rules &
Restrictions, and Conditions Evaluation” on page 53.
Configuring SAML
The IVE enables you to pass user and session state information between the IVE
and another trusted access management system that supports the Secure Access
Markup Language (SAML). SAML provides a mechanism for two disparate systems
to create and exchange authentication and authorization information using an XML
framework, minimizing the need for users to re-enter their credentials when
accessing multiple applications or domains1. The IVE supports SAML version 1.1.
SAML exchanges are dependent upon a trusted relationship between two systems
or domains. In the exchanges, one system acts as a SAML authority (also called an
asserting party or SAML responder) that asserts information about the user. The
other system acts as a relying party (also called a SAML receiver) that relies on the
statement (also called an assertion) provided by the SAML authority. If it chooses to
trust the SAML authority, the relying party authenticates or authorizes the user
based on the information provided by the SAML authority.
The IVE supports two SAML use case scenarios:

The IVE as the SAML authority—The user signs into a resource by way of the
IVE first, and all other systems are SAML receivers, relying on the IVE for
authentication and authorization of the user. Under this scenario, the IVE can
use either an artifact profile or a POST profile. For more information, see
“Configuring SAML SSO Profiles” on page 248.

The IVE as the SAML receiver—The user signs into another system on the
network first, and the IVE is the SAML receiver, relying on the other system for
authentication and authorization of the user.
For example, in the first scenario, an authenticated IVE user named John Smith
may try to access a resource protected by an access management system. When he
does, the IVE 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 IVE (and
therefore trust that the IVE 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 IVE.
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
IVE. The following process occurs:
1. The Secure Access Markup Language is developed by Security Services Technical Committee (SSTC) of the OASIS
standards organization. For a technical overview of SAML, see the OASIS web site:
http://www.oasis-open.org/committees/download.php/5836/sstc-saml-tech-overview-1.1-draft-03.pdf
Configuring SAML

245
Juniper Networks Secure Access Administration Guide
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 IVE, which can decide whether or not to link to
the reference.
3. If the IVE links to the reference, the portal sends a SOAP message containing
the SAML assertion (an XML message containing the user’s credentials) to the
IVE, which can then decide whether or not to allow the user access to the
requested resource.
4. If the IVE allows the user access, the IVE presents to the user the requested
resource.
5. If the IVE rejects the SAML assertion, or the user credentials, the IVE responds
to the user with an error message.
When configuring the IVE, 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 IVE can be either the
SAML authority or the SAML receiver. When acting as the SAML authority, the
IVE 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 IVE, the user is
seamlessly signed into the assertion consumer service using the username
contained in the statement.
When acting as the SAML receiver, the IVE 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 IVE must interpret, based on criteria that the IVE administrator has
specified in a SAML server instance definition. If the IVE chooses to trust the
asserting party, the IVE allows the user to sign in seamlessly using the
credentials contained in the SAML assertion.
246

Configuring SAML
Chapter 11: Single Sign-On

Access control authorization—In a SAML access control transaction, the IVE
asks an access management system whether the user has access. In this type of
transaction, the IVE 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 IVE user has sufficient access privileges, the user may access
the requested resource.
NOTE:

The IVE does not support attribute statements, which declare specific details
about the user (such as “John Smith is a member of the gold group”).

The IVE 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 IVE also allows you to
define users’ access rights to a URL using IVE-only mechanisms (Users >
Resource Profiles > Web Applications/Pages tab). If you define access
controls through the IVE as well as through a SAML authority, both sources
must grant access to a URL in order for a user to access it. For example, you
may configure an IVE 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 IVE 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 IVE receives an indeterminate response, it denies the user access.

The session timeouts on the IVE and your access management system may
not coordinate with one another. If a user’s access management system
session cookie times out before his IVE cookie (DSIDcookie) times out, then
single sign-on between the two systems is lost. The user is forced to sign in
again when he times out of the access management system.
For more information, see:

“Configuring SAML SSO Profiles” on page 248.

“Creating an Access Control Policy” on page 255

“Creating a Trust Relationship Between SAML-Enabled Systems” on
page 258

“Configuring SAML” on page 245

“Configuring a SAML Server Instance” on page 198

“Task Summary: Configuring SAML Through the IVE” on page 262
Configuring SAML

247
Juniper Networks Secure Access Administration Guide
Configuring SAML SSO Profiles
When enabling SSO transactions to a trusted access management system, you
must indicate whether the access management system should “pull” user
information from the IVE or whether the IVE 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 IVE, you may
choose to use an artifact or POST profile.
Creating an artifact 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 IVE, as shown in Figure 35.
Figure 35: Artifact profile
The IVE 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 IVE and tries to
access a protected resource on a Web server.
2. The IVE sends an HTTP or HTTPS GET request to the ACS—The IVE
intercepts the request and checks whether it has already performed the
necessary SSO operation to honor the request. If not, the IVE creates an
authentication statement and passes an HTTP query variable called an artifact
to the assertion consumer service.
An artifact profile is a base-64 encoded string that contains the source ID of the
source site (that is, a 20-byte string that references the IVE) and a randomlygenerated 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 IVE does not send a statement.
Also note that the IVE discards a handle after its first use to prevent the handle
from being used twice.)
248

Configuring SAML SSO Profiles
Chapter 11: Single Sign-On
3. The ACS sends a SAML request to the IVE—The assertion consumer service
uses the source ID sent in the previous step to determine the location of the
IVE. Then, the assertion consumer service sends a statement request wrapped
in a SOAP message to the following address on the IVE:
https://<IVEhostname>/dana-ws/saml.ws
The request includes the statement handle passed in the previous step.
NOTE: The IVE 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 IVE), 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 IVE sends an authentication statement to the ACS—The IVE uses the
statement handle in the request to find the correct statement in the IVE cache
and then sends the appropriate authentication statement back to the to the
assertion consumer service. The unsigned statement contains the user's
identity and the mechanism he used to sign into the IVE.
5. The ACS sends a cookie to the IVE—The assertion consumer service accepts
the statement and then it sends a cookie back to the IVE that enables the user’s
session.
6. The IVE sends the cookie to the Web server—The IVE caches the cookie to
handle future requests. Then the IVE 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 IVE to use artifact profiles, you must install the IVE’s
Web server certificate on the assertion consumer service (as explained in
“Configuring Certificates” on page 259).
To write a SAML SSO artifact profile resource policy:
1. In the admin console, navigate to Users > Resource Policies > Web.
2. If your administrator view is not already configured to show SAML policies,
make the following modifications:
a.
Click the Customize button in the upper right corner of the page.
b.
Select the SSO checkbox.
c.
Select the SAML checkbox below the SSO checkbox.
d. Click OK.
3. Select the SSO > SAML tab.
4. Click New Policy.
Configuring SAML SSO Profiles

249
Juniper Networks Secure Access Administration Guide
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. See
“Specifying Resources for a Resource Policy” on page 121 for more
information. To enable IP-based or case sensitivity matching for these
resources, see “Writing a Web Proxy Resource Policy” on page 457.
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 IVE performs a single-sign on
(SSO) request to the specified URL using the data specified in the SAML
SSO details section. The IVE makes the SSO request when a user tries to
access to a SAML resource specified in the Resources list.

Do NOT use SAML—The IVE 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 IVE
should use to contact the assertion consumer service (that is, the access
management server). For example, https://<hostname>:<port>/danana/auth/saml-consumer.cgi. (Note that the IVE 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 IVE (as explained in “Configuring Certificates”
on page 259).

Profile—Select Artifact to indicate that the assertion consumer service
should “pull” information from the IVE during SSO transactions.

Source ID—Enter the source ID for the IVE. If you enter a:

250

Configuring SAML SSO Profiles
Plain text string—The IVE converts, pads, or truncates it to a 20-byte
string.
Chapter 11: Single Sign-On

Base-64 encoded string—The IVE decodes it and ensures that it is 20
bytes.
If your access management system requires base-64 encoded source IDs,
you can create a 20 byte string and then use a tool such as OpenSSL to
base-64 encode it.
NOTE: The IVE identifier (that is, the source ID) must map to the following URL on
the assertion consumer service (as explained in “Configuring Trusted Application
URLs” on page 259): https://<IVEhostname>/dana-ws/saml.ws

Issuer—Enter a unique string that the IVE can use to identify itself when it
generates assertions (typically its host name).
NOTE: You must configure the assertion consumer service to recognize the IVE’s
unique string (as explained in “Configuring an Issuer” on page 259).
10. In the User Identity section, specify how the IVE and the assertion consumer
service should identify the user:


Subject Name Type—Specify which method the IVE 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 IVE
and the assertion consumer service.
Subject Name—Use the variables described in “System Variables and
Examples” on page 1018 to specify the username that the IVE 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 (as explained in “Configuring User Identity” on page 262).
11. In the Web Service Authentication section, specify the authentication method
that the IVE 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 IVE.
Configuring SAML SSO Profiles

251
Juniper Networks Secure Access Administration Guide

Certificate Attribute—Authenticate the assertion consumer service using
certificate attributes. Enter the attributes that the assertion consumer
service must send the IVE (one attribute per line). For example, cn=sales.
You must use values that match the values contained in the assertion
consumer service’s certificate.
NOTE: If you select this option, you must install the assertion consumer service’s
root CA on the IVE (as explained in “Configuring Certificates” on page 259).
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 IVE to evaluate them. Keep in mind that once the IVE 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.
Creating a POST Profile
When you choose to communicate using a POST profile (also called Browser/POST
profile), the IVE “pushes” authentication data to the access management system
using an HTTP POST command over an SSL 3.0 connection, as shown in Figure 36.
Figure 36: POST profile
The IVE and an access management (AM) system use the following process to pass
information:
1. The user tries to access a resource—A user is signed into the IVE and tries to
access a protected resource on a Web server.
2. The IVE posts a statement—The IVE intercepts the request and checks
whether it has already performed the necessary SSO operation to honor the
request. If not, the IVE 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 IVE uses to sign the statement.
252

Configuring SAML SSO Profiles
Chapter 11: 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 IVE that enables the
user’s session.
4. The IVE sends the cookie to the Web server—The IVE caches the cookie to
handle future requests. Then the IVE 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 IVE to use POST profiles, you must install the assertion
consumer service’s root CA on the IVE and determine which method the assertion
consumer service uses to trust the certificate (as explained in “Configuring
Certificates” on page 259).
To write a SAML SSO POST profile resource policy:
1. In the admin console, navigate to Users > Resource Policies > Web.
2. If your administrator view is not already configured to show SAML policies,
make the following modifications:
a.
Click the Customize button in the upper right corner of the page.
b.
Select the SSO checkbox.
c.
Select the SAML checkbox below the SSO checkbox.
d. Click OK.
3. Select the SSO > SAML tab.
4. Click New Policy.
5. On the SAML SSO Policy page, enter:
a.
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. See
“Specifying Resources for a Resource Policy” on page 121 for more
information. To enable IP-based or case sensitivity matching for these
resources, see “Writing a Web Proxy Resource Policy” on page 457.
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.
Configuring SAML SSO Profiles

253
Juniper Networks Secure Access Administration Guide

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 IVE performs a single-sign on
(SSO) request to the specified URL using the data specified in the SAML
SSO details section. The IVE makes the SSO request when a user tries to
access to a SAML resource specified in the Resources list.

Do NOT use SAML—The IVE 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 IVE
should use to contact the assertion consumer service (that is, the access
management server). For example, https://hostname/acs.

Profile—Select POST to indicate that the IVE should “push” information to
the assertion consumer service during SSO transactions.

Issuer—Enter a unique string that the IVE can use to identify itself when it
generates assertions (typically its host name).
NOTE: You must configure the assertion consumer service to recognize the IVE’s
unique string (as explained in “Configuring an Issuer” on page 259).

Signing Certificate—Specify which certificate the IVE should use to sign its
assertions.
10. In the User Identity section, specify how the IVE and the assertion consumer
service should identify the user:

254

Configuring SAML SSO Profiles
Subject Name Type—Specify which method the IVE 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 IVE
and the assertion consumer service.
Chapter 11: Single Sign-On

Subject Name—Use the variables described in “System Variables and
Examples” on page 1018 to specify the username that the IVE 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 (as explained in “Configuring User Identity” on page 262).
11. Cookie Domain—Enter a comma-separated list of domains to which we send
the SSO cookie.
12. Click Save Changes.
13. On the SAML SSO Policies page, order the policies according to how you want
the IVE to evaluate them. Keep in mind that once the IVE 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.
Creating an Access Control Policy
When enabling access control transactions to a trusted access management
system, the IVE and trusted access management system exchange information
using the method shown in Figure 37.
Figure 37: Access control policies
The IVE and an access management (AM) system use the following process to pass
information:
1. The user tries to access a resource—A user is signed into the IVE and tries to
access a protected resource on a Web server.
2. The IVE posts an authorization decision query—If the IVE has already made
an authorization request and it is still valid, the IVE 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 IVE 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.
Configuring SAML SSO Profiles

255
Juniper Networks Secure Access Administration Guide
3. The AM posts an authorization decision statement—The access management
system sends an HTTPS POST containing a SOAP message that contains the
authorization decision statement. The authorization decision statement
contains a result of permit, deny, or indeterminate.
4. The IVE sends the request to the Web browser—If the authorization decision
statement returns a result of permit, the IVE allows the user access. If not, the
IVE presents an error page to the user telling him that he does not have the
proper access permissions.
NOTE: If you configure the IVE to use access control transactions, you must install
the SAML Web service’s root CA on the IVE (as explained in “Configuring
Certificates” on page 259).
To write a SAML Access Control resource policy:
1. In the admin console, navigate to Users > Resource Policies > Web.
2. If your administrator view is not already configured to show SAML policies,
make the following modifications:
a.
Click the Customize button in the upper right corner of the page.
b.
Select the SAML ACL checkbox below the Access checkbox.
c.
Click OK.
3. Select the Access > SAML ACL tab.
4. On the SAML Access Control Policies page, click New Policy.
5. On the New Policy page, enter:
a.
A name to label this policy.
b.
A description of the policy (optional).
6. In the Resources section, specify the resources to which this policy applies. See
“Specifying Resources for a Resource Policy” on page 121 for more
information. To enable IP-based or case sensitivity matching for these
resources, see “Writing a Web Proxy Resource Policy” on page 457.
7. In the Roles section, specify:
256

Configuring SAML SSO Profiles

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.
Chapter 11: Single Sign-On
8. In the Action section, specify:

Use the SAML Access Control checks defined below—The IVE 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 IVE does not perform an access control
check.

Use Detailed Rules—To specify one or more detailed rules for this policy.
9. In the SAML Access Control Details section, specify:

SAML Web Service URL—Enter the URL of the access management
system’s SAML server. For example, https://hostname/ws.

Issuer—Enter the host name of the issuer, which in most cases is the host
name of the access management system.
NOTE: You must enter unique string that the SAML Web service uses to identify
itself in authorization assertions (as explained in “Configuring an Issuer” on
page 259).
10. In the User Identity section, specify how the IVE and the SAML Web service
should identify the user:


Subject Name Type—Specify which method the IVE and SAML Web service
should use to identify the user:

DN—Send the username in the format of a DN (distinguished name)
attribute.

Email Address—Send the username in the format of an email address.

Windows—Send the username in the format of a Windows domain
qualified username.

Other—Send the username in another format agreed upon by the IVE
and the SAML Web service.
Subject Name—Use the variables described in “System Variables and
Examples” on page 1018 to specify the username that the IVE 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 (as explained in “Configuring User Identity” on page 262).
11. In the Web Service Authentication section, specify the authentication method
that the SAML Web service should use to authenticate the IVE:

None—Do not authenticate the IVE.
Configuring SAML SSO Profiles

257
Juniper Networks Secure Access Administration Guide

Username—Authenticate the IVE using a username and password. Enter
the username and password that the IVE must send the Web service.

Certificate Attribute—Authenticate the IVE using a certificate signed by a
trusted certificate authority. If you have more than one certificate installed
on the IVE, 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 IVE Web server’s certificate on
the access management system’s Web server and determine which method the
SAML Web service uses to trust the certificate (as explained in “Configuring
Certificates” on page 259).
12. In the Options section, specify:

Maximum Cache Time—You can eliminate the overhead of generating an
authorization decision each time the user request the same URL by
indicating that the IVE must cache the access management system’s
authorization responses. Enter the amount of time the IVE should cache
the responses (in seconds).

Ignore Query Data—By default, when a user requests a resource, the IVE
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 IVE
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 IVE to evaluate them. Keep in mind that once the IVE
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.
Creating a Trust Relationship Between SAML-Enabled Systems
In order to ensure that SAML-enabled systems are only passing information
between trusted sources, you must create a trust relationship between the
applications that are sending and receiving information. To create a trust
relationship between the IVE and another SAML-enabled application, you must
configure the following types of information on each system:
258


“Configuring Trusted Application URLs” on page 259

“Configuring an Issuer” on page 259

“Configuring Certificates” on page 259

“Configuring User Identity” on page 262
Configuring SAML SSO Profiles
Chapter 11: Single Sign-On
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 IVE) needs to know the URL of the other system. (The IVE uses
the URL to initiate the transaction.) In other transactions (SSO transactions using
artifact profiles), you need to configure each system with the URL of the other.
Listed below are the different transaction types and the URLs you must configure
for each:

SSO transactions: Artifact profile—On the IVE, you must enter the URL of the
assertion consumer service. For example: https://hostname/acs
Also, you must enter the following URL for the IVE on the assertion consumer
service: https://<IVEhostname>/dana-ws/saml.ws

SSO transactions: POST profile—On the IVE, you must enter the URL of the
assertion consumer service. For example: https://hostname/acs

Access control transactions—On the IVE, you must enter the URL of the SAML
Web service. For example: https://hostname/ws
Configuring an Issuer
Before accepting a statement from another system, a SAML-enabled entity must
trust the issuer of the statement. You can control which issuers a system trusts by
specifying the unique strings of the trusted issuers during the system’s
configuration. (When sending a statement, an issuer identifies itself by including its
unique string in the statement. SAML-enabled applications generally use host
names to identify issuers, but the SAML standard allows applications to use any
string.) If you do not configure a system to recognize an issuer’s unique string, the
system will not accept that issuer’s statements.
Listed below are the different transaction types and the issuers you must configure
for each:

SSO transactions—You must specify a unique string on the IVE (typically its
host name) that it can use to identify itself and then configure the access
management system to recognize that string.

Access control transactions—You must specify a unique string on the access
management system (typically its host name) that it can use to identify itself
and then configure the IVE 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 IVE’s SAML transactions to use SSL (HTTPS). The following sections list
different transaction types and the certificate requirements for each.
Configuring SAML SSO Profiles

259
Juniper Networks Secure Access Administration Guide
Configuring SSO Transactions: Artifact Profile
Artifact profile transactions involve numerous communications back and forth
between the IVE and access management system. The methods you use to pass
data and authenticate the two systems affect which certificates you must install and
configure. Listed below are the different artifact profile configuration options that
require special certificate configurations:

All artifact profile transactions—Regardless of your artifact profile
configuration, you must install the certificate of the CA that signed the IVE Web
server’s certificate on the access management system. (The IVE 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 IVE’s 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 IVE. (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 IVE, you ensure that the IVE 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. For more information, see “Using Trusted Client CAs” on
page 738. 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 IVE to the access management
system, enter a URL that begins with HTTPS in the SAML Assertion Consumer
Service URL field during IVE 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 IVE. You
can install the root CA from the System > Configuration > Certificates
> Trusted Client CAs page in the admin console. For more information,
see “Using Trusted Client CAs” on page 738.

Specify which certificate values the IVE 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.
260

Configuring SAML SSO Profiles
Chapter 11: Single Sign-On
Configuring SSO Transactions: POST Profile
In a POST profile transaction, the IVE sends signed authentication statements to the
access management system. Generally, it sends them over an SSL connection
(recommended), but in some configurations, the IVE may send statements via a
standard HTTP connection. Listed below are the different POST profile
configuration options that require special certificate configurations:

All POST profile transactions—Regardless of your POST profile configuration,
you must specify which certificate the IVE 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. For more information,
see “Configuring SAML” on page 245. Then, you must install the IVE’s device
certificate on the access management system. You can download the IVE’s
certificate from the System > Configuration > Certificates > Device
Certificates > [Certificate] > Certificate Details page.

Sending POST data over an SSL connection (HTTPS)—If you choose to send
statements to the access management system using an SSL connection, you
must install the access management system’s root CA certificate on the IVE. (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 IVE, you
ensure that the IVE 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. For more information, see “Using Trusted Client CAs” on page 738. 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 IVE to the access management
system, enter a URL that begins with HTTPS in the SAML Assertion Consumer
Service URL field during IVE configuration. You may also need to enable SSL on
the access management system.
Configuring Access Control Transactions
In an access control transaction, the IVE posts an authorization decision query to
the access management system. To ensure that the access management system
responds to the query, you must determine which certificate options are required
by your configuration. Listed below are the different access control configuration
options that require special certificate configurations:

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 IVE. (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 IVE, you ensure
that the IVE 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. For more
information, see “Using Trusted Client CAs” on page 738.
Configuring SAML SSO Profiles

261
Juniper Networks Secure Access Administration Guide

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 IVE’s certificate. Optionally, you may also choose to accept
the certificate based on the following additional options:

Upload the IVE certificate’s public key to the access management system.

Validate the IVE using specific certificate attributes.
These options require that you specify which certificate the IVE 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. For more information, see “Configuring SAML SSO Profiles” on
page 248.
To determine how to configure your access management system to validate the
IVE’s 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 IVE
to pass the access management server a certificate. If you do not specify a trust
method, your access management system may accept authorization requests
from any system.
Configuring User Identity
In a trust relationship, the two entities must agree on a way to identify users. You
may choose to share a username across systems, select an LDAP or certificate user
attribute to share across systems, or hard-code a user ID. (For example, you may
choose to set the Subject Name field to “guest” to easily allow access across
systems.)
To ensure that the two systems are passing common information about users, you
must specify which information the IVE should pass using options in the User
Identity section of the Users > Resource Policies > Web > SAML SSO > [Policy]
> General page (for more information, see “Configuring SAML” on page 245) and
the Users > Resource Policies > Web > SAML ACL > [Policy] > General page of
the admin console. Choose a username or attribute that the access management
system will recognize.
Task Summary: Configuring SAML Through the IVE
To configure SAML through the IVE, you must:
1. Configure a Web resource policy for a URL through the Users > Resource
Policies > Web > SAML ACL and Users > Resource Policies > Web >
SAML SSO tabs in the admin console. For more instructions, see “Configuring
SAML” on page 245.
2. Within the policy, provide information about the IVE, the trusted access
management system, and the mechanism they should use to share
information, as explained in “Creating a Trust Relationship Between SAMLEnabled Systems” on page 258.
262

Configuring SAML SSO Profiles
Chapter 11: Single Sign-On
3. Give IVE users within a role access to the Web resource policy through the
Users > User Roles > Select Role > General tab of the admin console. For
instructions, see “Configuring General Role Options” on page 87.
Configuring SAML SSO Profiles

263
Juniper Networks Secure Access Administration Guide
264

Configuring SAML SSO Profiles
Chapter 12
Synchronizing User Records
The user record synchronization feature promotes a more consistent user
experience by allowing users to retain their bookmarks and individual preferences
regardless of which IVE they log in to.
User record synchronization relies on client-server pairings. The client is the Secure
Access appliance that users log in to start their remote access. Each client is
associated with one primary server and one backup server to store user record
data. Clients can be individual appliances or a node within a cluster.
A server in this instance is the Secure Access appliance that stores the user data
records. Each server can be configured to replicate its user record data to one or
more peer servers. Servers are identified by a user-defined logical name. The same
logical name can be assigned to more than one authentication server to let you
associate authentication servers of different types to the same user. For example,
SA1 is an ACE authentication server with user1 who creates a bookmark to
www.juniper.net. SA2 is an Active Directory authentication server with the same
user1. For the www.juniper.net bookmark to be transferred from SA1/ACE/user1 to
SA2/AD/user1 you would assign the logical name “Logical1” to both the ACE server
on SA1 and the Active Directory server on SA2.
NOTE: Cluster VIPs can not be used as the IP for synchronizing between clients
and peers servers.
As long as the logical name is the same, the authentication servers can be different
types and different server names and still be associated with a common user. The
username must be the same for user record data to be synchronized across the
servers. The logical 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

265
Juniper Networks Secure Access Administration Guide

Preferences

Persistent Cookies
User session data is not synchronized. Persistent cookies, if changed, are
synchronized when the user session terminates. All other modifications to the user
records are synchronized immediately. User records are stored in cache on the
client node prior to being pushed to the servers.
When a user logs in to a client, their data is pulled from the associated server. The
pull is performed in the background and does not delay the login process. Users
using browsers that do not support JavaScript must manually refresh the index
page for updated bookmarks and preferences to appear. For browsers that support
JavaScript, users may see a spinning progress indicator and their home page will
refresh automatically with updated bookmarks and preferences.
Clients and servers need not be installed with the same Secure Access software
version as long as they are using version 6.5 or later.
NOTE: User record synchronization uses port 17425. This port number is not
configurable. If you are deploying across a firewall, configure your firewall to
allow traffic on this port.
To set up user record synchronization, you perform the following tasks:
1. Enable user record synchronization for each participating client and server,
identify which ones are the client and which ones are the server and assign a
node name to each client and server.
2. Create a shared secret which is used to authenticate the client with the server
and the server to its peer servers.
3. On each server, define which clients and peers are allowed to communicate
with the server.
4. On each client, define the servers that handle records for each LAS server.
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.
266

Chapter 12: Synchronizing User Records
NOTE: User records may not synchronize if the time clocks on the IVE appliances
are not in sync. We recommend that you use the same NTP server for each node
participating in user record synchronization to keep the IVE times accurately
adjusted.
Enabling User Record Synchronization
The first step in enabling user record synchronizing is to define the node name and
the shared secret used to authenticate between the clients and the servers:
1. Select System > Configuration > User Record Synchronization > General.
2. Select the Enable User Record Synchronization checkbox.
3. Enter a unique node name. This name is used when associating a client with a
server and is different from the logical name assigned to a server. This node
name is also not the same as the cluster node name.
4. Enter the shared secret and confirm it.
The shared secret is the password used to authenticate the client with its
servers and the primary server with its peer servers. Use the same shared
secret for all clients and servers participating in user record synchronization.
5. Select whether this node is client only or if this node acts as both a client and
server.
6. Click Save Changes.
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.
Configuring the 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.
Enabling User Record Synchronization  267
Juniper Networks Secure Access Administration Guide
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.
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
(see “Enabling User Record Synchronization” on page 267) 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.
Table 15: Server Color Codes
Color
Description
Green
Connected
Yellow
Connecting
Gray
Not connected
Configuring the Client
To set up the client, you select the primary and backup server you want this client
to synchronize with:
268

Configuring the User Record Synchronization Server
Chapter 12: Synchronizing User Records
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. See Figure 15 on page 268.
Configuring the 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, the IVE 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 the IVE 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.
Configuring the Database

269
Juniper Networks Secure Access Administration Guide
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.

Enter the LAS name of the user records you want to export. If you leave
this field blank, all user records are exported. If you enter a LAS name, only
user records with the entered LAS name are exported.

To encrypt the exported data, select the Encrypt the exported data with
password checkbox and enter the password.

Click Export to export the user records from the specified source (cache or
database). You will be prompted where to save the file.
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 (see “Configuring the
Authentication Server” on page 267), 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.
270

Configuring the Database

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.
Part 3
Endpoint Defense
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.
By using the following endpoint defense components, you can manage and
provision a variety of endpoint checks all from within the IVE.

Host Checker—Host Checker uses technology based on the TNC architecture
and standards, to provide a comprehensive approach to assess the trust
worthiness of endpoints. Host Checker is a native IVE component that you can
use to perform endpoint checks on hosts that connect to the IVE. Host Checker
checks for third party applications, files, process, ports, registry keys, and
custom DLLs as well as the NetBIOS name, MAC address, or certificate of the
client machine and denies or enables access based on the results of the checks.
When properly licensed, you can also use Host Checker to download advanced
malware detection software directly to the user’s computer. 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. For more information, see “Host Checker” on page 273.
For example, you may choose to check for virus detection before allowing a
user access to any of the IVE realms, launch the software on the user’s system if
necessary, map the user to roles based on individual policies defined in your
own DLL, and then further restrict access to individual resources based on the
existence of spyware detection software.

271
Juniper Networks Secure Access Administration Guide

Cache Cleaner (Windows only)—Cache Cleaner is a native IVE component
that you can use to remove residual data, such as cookies, temporary files, or
application caches, from a user’s machine after an IVE session. Cache Cleaner
helps secure the user’s system by preventing subsequent users from finding
temporary copies of the files that the previous user was viewing and by
preventing Web browsers from permanently storing the usernames,
passwords, and Web addresses that users enter in Web forms. For more
information, see “Cache Cleaner” on page 341.
This section includes the following information about endpoint defense:
272


“Host Checker” on page 273

“Cache Cleaner” on page 341
Chapter 13
Host Checker
Host Checker is a client-side agent that performs endpoint checks on hosts that
connect to the IVE. You can invoke Host Checker before displaying an IVE sign-in
page to a user and when evaluating a role mapping rule or resource policy.
The TNC Architecture Within Host Checker
All Host Checker rules are implemented through IMCs (integrity measurement
collectors) and IMVs (integrity measurement verifiers) based on the TNC (Trusted
Network Computing) open architecture.I
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 IVE that are responsible for verifying a
particular aspect of an endpoint’s integrity.
The IVE and Host Checker manage the flow of information between the
corresponding pairs of IMVs and IMCs. Each IMV on the IVE 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. For
more information, see “Using third-party integrity Measurement Verifiers” on
page 303.
NOTE:

The IVE and Host Checker comply with the standards produced by the Trusted
Network Connect (TNC) subgroup of the Trusted Computing Group. For more
information about IMVs and IMCs, see www.trustedcomputinggroup.org.
The TNC Architecture Within Host Checker  273
Juniper Networks Secure Access Administration Guide
The IVE can check hosts for endpoint properties using a variety of rule types,
including rules that check for and install advanced malware protection; predefined
rules that check for antivirus software, firewalls, malware, spyware, specific
operating systems, third party DLLs, ports, processes, files, registry key settings, and
the NetBIOS name, MAC address, or certificate of the client machine.
Host Checker Overview
If the user’s computer does not meet any of the Host Checker policy requirements,
you can display a custom-made HTML remediation page to the user. This page can
contain your specific instructions as well as links to resources to help the user bring
his computer into compliance with each Host Checker policy.
This section contains the following information about Host Checker:

“Task Summary: Configuring Host Checker” on page 274

“Creating Global Host Checker Policies” on page 276

“Enabling the Secure Virtual Workspace” on page 332

“Implementing Host Checker Policies” on page 311

“Remediating Host Checker Policies” on page 316

“Defining Host Checker Pre-Authentication Access Tunnels” on page 321

“Specifying General Host Checker Options” on page 325

“Specifying Host Checker Installation Options” on page 327

“Using Host Checker Logs” on page 330
Task Summary: Configuring Host Checker
To configure a Host Checker policy, you must perform these tasks:
1. Create and enable Host Checker policies through the Authentication >
Endpoint Security > Host Checker page of the admin console, as explained in
“Creating Global Host Checker Policies” on page 276.
2. Configure additional system-level options through the Authentication >
Endpoint Security > Host Checker page of the admin console as necessary:

274

Host Checker Overview
If you want to display remediation information to users when 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, as explained in “Remediating Host
Checker Policies” on page 316.
Chapter 13: Host Checker

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, as explained in “Defining Host
Checker Pre-Authentication Access Tunnels” on page 321.

If you want to change the default Host Checker settings, configure them
through the Authentication > Endpoint Security > Host Checker page
of the admin console, as explained in “Specifying General Host Checker
Options” on page 325.
3. Determine at which levels within the IVE access management framework you
want to enforce the policies:

To enforce Host Checker policies when the user first accesses the IVE,
implement the policies at the realm level by using the Administrators >
Admin Realms > Select Realm > Authentication Policy > Host Checker
or the Users > User Realms > Select Realm > Authentication Policy >
Host Checker pages of the admin console.

To allow or deny users access to roles based on their compliance with Host
Checker policies, implement the policies at the role level by using the
Administrators > Admin Roles > Select Role > General > Restrictions
> Host Checker or the Users > User Roles > Select Role > General >
Restrictions > Host Checker pages of the admin console.

To map users to roles based on their compliance with Host Checker
policies, use custom expressions in the Administrators > Admin Realms
> Select Realm > Role Mapping or the Users > User Realms > Select
Realm > Role Mapping pages 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.
For more information, see “Configuring Host Checker Restrictions” on
page 314.
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.
For configuration instructions, see “Specifying Host Checker Installation
Options” on page 327.
Task Summary: Configuring Host Checker

275
Juniper Networks Secure Access Administration Guide
NOTE: Users must enable signed ActiveX components or signed Java applets
within their browsers in order for Host Checker to download, install, and launch
the client applications.
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 IVE appliance creates log files on your users’ systems and
writes to the file whenever Host Checker runs. For configuration instructions,
see “Using Host Checker Logs” on page 330.
If more than one valid IVE session exists from the same system and Host Checker is
used in those sessions, all sessions are terminated when a user signs out from one
of the sessions. To prevent this, turn off Host Checker for those sessions that do not
need Host Checker.
NOTE: If multiple administrators or end-users to a single IVE are signed in from the
same client system and at least one of them deploys Host Checker, unexpected
results may occur. For example, Host Checker may shut down, role privileges may
be lost and forced disconnections may occur.
Creating Global Host Checker Policies
In order to use Host Checker as a policy enforcement tool for managing endpoints,
you must create global Host Checker policies at the system level through the
Authentication > Endpoint Security > Host Checker page of the admin console,
and then implement the policies at the realm, role, and resource policy levels.
The IVE provides several mechanisms that you can use to enable, create, and
configure Host Checker policies:
276


Pre-defined policies (prevent in-network attacks or downloads malware
detection software)—The IVE 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 the IVE. 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 in accordance with your
specifications. For more information, see “Checking for Third-Party
Applications Using Pre-defined Rules (Windows Only)” on page 281.
Creating Global Host Checker Policies
Chapter 13: Host Checker

Custom rules (check for additional requirements)—In addition to the Predefined rules, 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 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 .

Check the NetBIOS name, MAC addresses, or certificate of the client
machine .

Assess the client operating system and application service packs to ensure
they are up to date .

Perform application and version checks to ensure that endpoints are
running the correct software .
For more information, see “Specifying Customized Requirements Using Custom
Rules” on page 290.

Custom integrated applications (implement through server API)—For
Windows clients, you can upload a third-party J.E.D.I. DLL to the IVE. For more
information, see “Enabling Customized Server-side Policies” on page 310.

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.
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 the IVE, and you can restrict or quarantine these endpoints
depending on your Host Checker policy configuration.

Adware

Dialers

Hijack

Spy Cookie
Creating Global Host Checker Policies

277
Juniper Networks Secure Access Administration Guide

Commercial System Monitor

System Monitor

Trojan Downloader

Trojan Phisher

Trojan Horse

Worm
EES can scan processes that are loaded in memory on endpoints and provide realtime 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 the IVE.
Endpoints must have access to the Internet for EES to successfully run, as live
signature updates must be permitted to download. Additionally, if you configure
default remediation roles you should ensure that endpoints that are directed to
remediation roles can access *.webroot.com.
You can configure the age of the database on the IVE 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 the IVE
and you have chosen to implement the option to check for signature age, the policy
will not pass if the signatures are too old. For example, if a user has not accessed
the endpoint for several days and the signatures are not up to date, the endpoint
cannot authenticate to the IVE. In this case, you can create a default remediation
role that allows limited access to the Internet for signature updates at
*.webroot.com.
EES antispyware functionality is available on Windows platforms (including Vista)
with Network Connect.
You configure EES on the Endpoint Security > Host Checker main page to ensure
that multiple policies are not created, and that the same policy is used across all
realms and roles for which you have enabled it. When you create a realm or a role,
you can enable EES restrictions in addition to any other Host Checker policies.
278

Creating Global Host Checker Policies
Chapter 13: Host Checker
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 Network Connect 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 installer and
approximately 12 MB for the signatures) followed by 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 endpoint takes a good deal of time. You should
warn end users to wait for the operation to complete.
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.
Any threat detected is automatically remediated by Host Checker and not reported.
If threats are not 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 anti-spyware:
1. In the admin console, choose Authentication > Endpoint Security > Host
Checker.
2. Under Options, select the Advanced Endpoint Protection: Malware
Protection tab.
3. Select the Enable Advanced Endpoint Protection: Malware Protection check
box.
4. Set the age of the signature definitions database by selecting the Signature
definitions should not be older than check box. Enter the frequency in days
(3 - 30). This function does not change the frequency of updates. This number
determines the maximum permissible age of signatures.
5. Click Save Changes.
When you create or configure realm or role Host Checker restrictions, you can
select EES to apply to that role or realm. See “Configuring Host Checker
Restrictions” on page 314.
Creating Global Host Checker Policies

279
Juniper Networks Secure Access Administration Guide
Enabling Connection Control 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 does not work on Windows
Vista or Windows 7.
The Host Checker connection control policy blocks all incoming TCP, UDP and
ICMP connections. This policy allows all outgoing TCP and Network Connect traffic,
as well as all connections to DNS servers, WINS servers, DHCP servers, proxy
servers, and the IVE.
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. The IVE 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, the IVE 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 using the options described in “Configuring Host Checker
Restrictions” on page 314.
NOTE: You must evaluate or enforce the connection control policy at the realm
level to make the policy effective on client computers.
Creating and Configuring New Client-side 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.
280

Creating and Configuring New Client-side Policies
Chapter 13: Host Checker
When creating the policies, you must define the policy name, and either enable predefined 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 using instructions in the
following sections:

“Checking for Third-Party Applications Using Pre-defined Rules (Windows
Only)” on page 281

“Specifying Customized Requirements Using Custom Rules” on page 290
5. Specify how Host Checker should evaluate multiple rules within the policy
using instructions in “Evaluating Multiple Rules in a Single Host Checker Policy”
on page 298.
6. (Recommended) Specify remediation options for users whose computers do
not meet the requirements specified in the policy. For instructions, see
“Configuring General Host Checker Remediation” on page 318. (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 using the
options described in “Configuring Host Checker Restrictions” on page 314.
Checking for Third-Party Applications Using Pre-defined 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.

Predefined: AntiVirus—Select this option to create a rule that checks for
the antivirus software that you specify, and to specify remediation options.
See “Configuring a Predefined Antivirus Rule with Remediation Options”
on page 283.
Checking for Third-Party Applications Using Pre-defined Rules (Windows Only)

281
Juniper Networks Secure Access Administration Guide

Predefined: Firewall—Select this option to create a rule that checks for the
firewall software that you specify, and to specify remediation options. See
“Configuring a Predefined Firewall Rule with Remediation Options” on
page 285.

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. See “Configuring
a Pre-defined Anti-Spyware Rule” on page 286.

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.) See
To create a Host Checker rule using Predefined Malware or Predefined OS Checks
rules:
1. In the admin console, choose Authentication > Endpoint Security > Host
Checker.
2. Create a new policy using instructions in “Creating and Configuring New Clientside Policies” on page 280 or click on an existing policy in the Policies section
of the page.
3. Under Rule Settings, choose one of the following options and click Add:

Predefined Malware

Predefined OS Checks
4. In the Add Predefined Rule page:
5. In the Rule Name field, enter an identifier for the rule.
6. 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.
282

Checking for Third-Party Applications Using Pre-defined Rules (Windows Only)
Chapter 13: Host Checker
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, the IVE initiates a new handshake to re-evaluate realm or role
assignments.
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. For more information about TNCC see “The TNC Architecture Within Host
Checker” on page 273.
8. Click Save Changes.
9. Optionally add additional rules to the policy, specify how Host Checker should
evaluate multiple rules within the policy, and define remediation options using
instructions in “Creating and Configuring New Client-side Policies” on
page 280.
NOTE: 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.
Configuring a Predefined Antivirus Rule with Remediation Options
You can configure antivirus remediation actions with Host Checker. You can
specify a requirement for the age (in days) of the last successful virus scan, and you
can specify that virus signatures installed on client machines should not be older
than a specified number of updates.
You can also monitor policies to ensure that logged-in endpoints maintain
compliance status, and remediate the endpoint to another role or realm depending
on the current status.
If a client attempts to log in, and the client machine does not meet the
requirements you specify, Host Checker can attempt to correct the deficiencies to
allow the client to successfully log in. With Host Checker antivirus remediation, you
can prompt the endpoint to download the latest virus signature files, turn on
antivirus protection, and initiate an antivirus scan.
All of the remediation options are not supported for all antivirus software vendors’
products. All available vendors and products that are supported are displayed when
you select the Require any supported product option button.
Alternately, you can select the Require specific products/vendors option button
and select either the Require any supported product from a specific vendor or
Require specific products check boxes, then add an available type to Selected
Types. The remediation options appear, and you can determine which remediation
options are available for specific products or vendors.
Checking for Third-Party Applications Using Pre-defined Rules (Windows Only)

283
Juniper Networks Secure Access Administration Guide
To configure a Predefined Antivirus rule:
1. In the admin console, choose Authentication > Endpoint Security > Host
Checker.
2. Create a new policy using instructions in “Creating and Configuring New Clientside Policies” on page 280 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 a 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. See “Configuring Virus Signature Version Monitoring and
Patch Assessment Data Monitoring” on page 288.
9. Select your antivirus vendor(s) and product(s) by using either the Require any
supported product or Require specific products/vendors option buttons.
Require any supported product allows you to check for any product (rather
than requiring you to select every product separately). This option button
reveals a list of products in the remediation section to allow you to enable
remediation options which are product specific.
Require specific products/vendors allows you to define compliance by allowing
any product by a specific vendor (for example, any Symantec product).
Require specific products provides functionality that allows you to select
individual products to define compliance.
After you select your vendor(s) and product(s), remediation options will appear
on the page.
For each of the following remediation actions:

284

Download latest virus definition files—obtains the latest available file for
the specified vendor from the vendor’s website
Checking for Third-Party Applications Using Pre-defined Rules (Windows Only)
Chapter 13: Host Checker

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, the IVE initiates a new handshake to re-evaluate realm or role
assignments.
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. For more information about TNCC see “The TNC Architecture Within Host
Checker” on page 273.
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 using
instructions in “Creating and Configuring New Client-side Policies” on
page 280.
Configuring a Predefined Firewall Rule with Remediation Options
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.
Checking for Third-Party Applications Using Pre-defined Rules (Windows Only)

285
Juniper Networks Secure Access Administration Guide
2. Create a new policy using instructions in “Creating and Configuring New Clientside Policies” on page 280 or click an existing policy in the Policies section of
the page.
3. Under Rule Settings, choose Predefined: Firewall and click Add.
4. Enter a 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 on 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, the IVE initiates a new handshake to re-evaluate realm or role
assignments.
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. For more information about TNCC see “The TNC Architecture Within Host
Checker” on page 273.
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 using
instructions in “Creating and Configuring New Client-side Policies” on
page 280.
Configuring a Pre-defined Anti-Spyware Rule
You can configure Host Checker to check for installed spyware on endpoints.
286

Checking for Third-Party Applications Using Pre-defined Rules (Windows Only)
Chapter 13: Host Checker
After you enforce the Host Checker rule, if an endpoint attempts to log in without
the required spyware, the Host Checker rule will fail.
The option is not supported for all spyware products. All available products are
displayed by using the Require any supported product or Require specific
products/vendors option buttons.
To configure a Host Checker Predefined Spyware rule:
1. In the admin console, choose Authentication > Endpoint Security > Host
Checker.
2. Create a new policy using instructions in “Creating and Configuring New Clientside Policies” on page 280 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 name for the firewall rule.
5. Select one of the following options:
6. Select the Require any supported product option button to check for any
product (rather than requiring you to select every product separately).
7. Select the Require specific products/vendors option button to specify the
spyware that you want to check for.
8. Choose either the Require any supported product from a specific vendor or
Require specific products to select your spyware.
Add your available spyware from Available Products to Selected Products.
9. 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, the IVE initiates a new handshake to re-evaluate realm or role
assignments.
10. Click Save Changes to save the spyware rule.
11. Optionally add additional rules to the policy, specify how Host Checker should
evaluate multiple rules within the policy, and define remediation options using
instructions in “Creating and Configuring New Client-side Policies” on
page 280.
Checking for Third-Party Applications Using Pre-defined Rules (Windows Only)

287
Juniper Networks Secure Access Administration Guide
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 the IVE and the
Juniper site. To use a proxy server, you enter the server’s IP address, port and
authentication credentials, if applicable.
To access the Juniper Networks staging site for updates, you must enter the
credentials for your Juniper Networks Support account.
To configure the IVE 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 the IVE 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.
288

Checking for Third-Party Applications Using Pre-defined Rules (Windows Only)
Chapter 13: 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 the IVE. For more information, see “Uploading Trusted Server CA
Certificates” on page 754.
To use a proxy server as the auto-update server:
1. Choose Authentication > Endpoint Security > Host Checker.
2. Click Virus signature version monitoring, or Patch Management Info
Monitoring.
3. Select Auto-update virus signatures list. or Auto-update Patch Management
data.
4. For Download path, leave the existing URL(s) of the staging site(s) where the
current list(s) are stored. The default URLs are the paths to the Juniper
Networks staging site:
https://download.juniper.net/software/av/uac/epupdate_hist.xml
https://download.juniper.net/software/hc/patchdata/patchupdate.dat
5. For Download interval, specify how often you want the IVE 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.
Checking for Third-Party Applications Using Pre-defined Rules (Windows Only)

289
Juniper Networks Secure Access Administration Guide
Specifying Customized Requirements Using Custom Rules
If the pre-defined client-side policies and rules that come with the IVE do not meet
your needs, 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.

Configure PatchLink rules.

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, choose Authentication > Endpoint Security > Host
Checker.
2. Create a new policy using instructions in “Creating and Configuring New Clientside Policies” on page 280 or click on an existing policy in the Policies section
of the page.
290

Specifying Customized Requirements Using Custom Rules
Chapter 13: Host Checker
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 the IVE 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.

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 the IVE considers the rule met. In the 3rd Party NHC Check
configuration page:
i.
Enter a name and vendor for the 3rd Party NHC Check rule
ii.
Enter the location of the DLL on client machines (path and file name).
iii. Click Save Changes.
NOTE: The 3rd Party NHC Check feature is primarily provided for backwards
compatibility. We recommend that you use IMCs and IMVs instead, as described
in “The TNC Architecture Within Host Checker” on page 273.
Specifying Customized Requirements Using Custom Rules

291
Juniper Networks Secure Access Administration Guide

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 the IVE. In
the Ports configuration page:
i.
Enter a name for the port rule.
ii.
Enter a comma delimited list (without spaces) of ports or port ranges,
such as: 1234,11000-11999,1235.
iii. Select Required to require that these ports are open on the client
machine or Deny to require that they are closed.
iv. 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, the IVE initiates a new handshake to
re-evaluate realm or role assignments.
v.

Click Save Changes.
Process—Use this rule type to control the software that a client may run
during a session. This rule type ensures that certain processes are running
or not running on the client machine before the user can access resources
protected by the IVE. In the Processes configuration page:
i.
Enter a name for the process rule.
ii.
Enter the name of a process (executable file), such as: good-app.exe.
NOTE: For Linux, Macintosh and Solaris systems, the process that is being detected
must be started using an absolute path.
You can use a wildcard character to specify the process name. For
example:
good*.exe
For more information, see “Using a Wildcard or Environment Variable
in a Host Checker Rule” on page 297.
iii. Select Required to require that this process is running or Deny to
require that this process is not running.
iv. Specify the MD5 checksum value of each executable file to which you
want the policy to apply (optional). For example, an executable may
have different MD5 checksum values on a desktop, laptop, or different
operating systems. On a system with OpenSSL installed—many
Macintosh, Linux and Solaris systems have OpenSSL installed by
default—you can determine the MD5 checksum by using this
command:
openssl md5 <processFilePath>
292

Specifying Customized Requirements Using Custom Rules
Chapter 13: Host Checker
v.

Click Save Changes.
File—Use this rule type to ensure that certain files are present or not
present on the client machine before the user can access the IVE. You may
also use file checks to evaluate the age and content (through MD5
checksums) of required files and allow or deny access accordingly. In the
Files configuration page:
i.
ii.
Enter a name for the file rule.
Enter the name of a file (any file type), such as: c:\temp\bad-file.txt or
/temp/bad-file.txt.
You can use a wildcard character to specify the file name. For
example:
*.txt
You can also use an environment variable to specify the directory path
to the file. (You cannot use a wildcard character in the directory path.)
Enclose the variable between the <% and %> characters. For example:
<%windir%>\bad-file.txt
For more information, see “Using a Wildcard or Environment Variable
in a Host Checker Rule” on page 297.
iii. Select Required to require that this file is present on the client
machine or Deny to require that this file is not present.
iv. Specify the minimum version of the file (optional). For example, if you
require notepad.exe to be present on the client, you can enter 5.0 in
the field. Host Checker accepts version 5.0 and above, of notepad.exe.
v.
Specify the maximum age (File modified less than n days) (in days)
for a file (optional). If the file is older than the specified number of
days, then the client does not meet the attribute check requirement.
NOTE: You can use the maximum age option to check the age of virus signatures.
Make sure you specify the path to a file in the File Name field whose timestamp
indicates when virus signatures were last updated, such as a virus signature
database or log file that updates each time the database updates. For example, if
you use TrendMicro, you may specify:
C:\Program Files\Trend Micro\OfficeScan Client\TmUpdate.ini.
Specifying Customized Requirements Using Custom Rules

293
Juniper Networks Secure Access Administration Guide
vi. Specify the MD5 checksum value of each file to which you want the
policy to apply (optional). On Macintosh, Linux and Solaris, you can
determine the MD5 checksum by using this command:
openssl md5 <filePath>
vii. 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, the IVE initiates a new handshake to re-evaluate
realm or role assignments.
viii. Click Save Changes.

Registry Setting (Windows only)—Use this rule type to control the
corporate PC images, system configurations, and software settings that a
client must have to access the IVE. This rule type ensures that certain
registry keys are set on the client machine before the user can access the
IVE. You may also use registry checks to evaluate the age of required files
and allow or deny access accordingly. In the Registry Settings
configuration page:
i.
Enter a name for the registry setting rule.
ii.
Select a root key from the drop-down list.
iii. Enter the path to the application folder for the registry subkey.
iv. Enter the name of the key’s value that you want to require (optional).
This name appears in the Name column of the Registry Editor.
v.
Select the key value’s type (String, Binary, or DWORD) from the dropdown list (optional). This type appears in the Type column of the
Registry Editor.
vi. Specify the required registry key value (optional). This information
appears in the Data column of the Registry Editor.
If the key value represents an application version, select Minimum
version to allow the specified version or newer versions of the
application. For example, you can use this option to specify version
information for an antivirus application to make sure that the client
antivirus software is current. The IVE uses lexical sorting to determine
if the client contains the specified version or higher. For example:
3.3.3 is newer than 3.3
4.0 is newer than 3.3
4.0a is newer than 4.0b
294

Specifying Customized Requirements Using Custom Rules
Chapter 13: Host Checker
4.1 is newer than 3.3.1
NOTE: If you specify only the key and subkey, Host Checker simply verifies the
existence of the subkey folder in the registry.
vii. 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, the IVE initiates a new handshake to
re-evaluate realm or role assignments.
You can configure registry setting remediation actions with Host
Checker. If a client attempts to login, and the client machine does not
meet the requirements you specify, Host Checker can attempt to
correct the discrepancies to allow the client to login.
viii. Select the check box for Set Registry value specified in criteria.
ix. Click Save Changes.

NetBIOS (Windows only, does not include Windows Mobile)—Use this rule
type to check the NetBIOS name of the client machine before the user can
access the IVE. In the NetBIOS configuration page:
i.
Enter a name for the NetBIOS rule.
ii.
Enter a comma-delimited list (without spaces) of NetBIOS names. The
name can be up to 15 characters in length. You can use wildcard
characters in the name and it is not case-sensitive. For example, md*,
m*xp and *xp all match MDXP.
iii. Select Required to require that NETBIOS name of the client machine
match one of the names you specify, or Deny to require that the name
does not match any name.
iv. Click Save Changes.

MAC Address (Windows only)—Use this rule type to check the MAC
addresses of the client machine before the user can access the IVE. In the
MAC Address configuration page:
i.
Enter a name for the MAC address rule.
ii.
Enter a comma-delimited list (without spaces) of MAC addresses in the
form XX:XX:XX:XX:XX:XX where the X’s are hexadecimal numbers.
For example:
00:0e:1b:04:40:29
You can use a * wildcard character to represent a two-character
section of the address. For example, you can use a * to represent the
“04”, “40”, and “29” sections of the previous example address:
00:0e:1b:*:*:*
Specifying Customized Requirements Using Custom Rules

295
Juniper Networks Secure Access Administration Guide
But you cannot use a * to represent a single character. For example,
the * in the following address is not allowed:
00:0e:1b:04:40:*9
iii. Select Required to require that a MAC address of the client machine
matches any of the addresses you specify, or Deny to require that the
all addresses do not match. A client machine will have at least one
MAC address for each network connection, such as Ethernet, wireless,
and VPN. This rule’s requirement is met if there is a match between
any of the addresses you specify and any MAC address on the client
machine.
iv. Click Save Changes.
NOTE: Since the MAC address is changeable on some network cards, this check
may not guarantee that a client machine meets the requirements of your Host
Checker policy.

Machine Certificate (Windows only)—Use this rule type to check that the
client machine is permitted access by validating the machine certificate
stored on the client machine, as explained in “Using Trusted Client CAs” on
page 738. In the Machine Certificate configuration page:
i.
Enter a name for the machine certificate rule.
ii.
From the Select Issuer Certificate list, select the certificate that you
want to retrieve from the user’s machine and validate. Or, select Any
Certificate to skip the issuer check and only validate the machine
certificate based on the optional criteria that you specify below.
iii. From the Optional fields (Certificate field and Expected value),
specify any additional criteria that Host Checker should use when
verifying the machine certificate.
iv. Click Save Changes.
NOTE:

If more than one certificate is installed on the client machine that matches the
specified criteria, The Host Checker client passes the first certificate it finds to
the IVE for validation.

5. Optionally add additional rules to the policy, specify how Host Checker should
evaluate multiple rules within the policy, and define remediation options using
instructions in “Creating and Configuring New Client-side Policies” on
page 280.
296

Specifying Customized Requirements Using Custom Rules
Chapter 13: Host Checker
Using a Wildcard or Environment Variable in a Host Checker Rule
You can use the following wildcards to specify a file name in a Custom File rule or a
process name in a Custom Process rule:
Table 16: Wildcard Characters for Specifying a File Name or Process Name
Wildcard Character
Description
Example
*
Matches any character
*.txt
?
Matches exactly one character
app-?.exe
In a Custom File rule for Windows, you can use the following environment
variables to specify the directory path to a file:
Table 17: Environment Variables for Specifying a Directory Path on Windows
Environment variable
Example Windows Value
<%APPDATA%>
C:\Documents and Settings\jdoe\Application Data
<%windir%>
C:\WINDOWS
<%ProgramFiles%>
C:\Program Files
<%CommonProgramFiles%>
C:\Program Files\Common Files
<%USERPROFILE%>
C:\Documents and Settings\jdoe
<%HOMEDRIVE%>
C:
<%Temp%>
C:\Documents and Settings \<user name>\Local
Settings\Temp
In a Custom File rule for Macintosh, Linux and Solaris, you can use the following
environment variables to specify the directory path to a file:
Table 18: Environment Variables for Specifying a Directory Path on Macintosh, Linux and
Solaris
Environment variable Example Macintosh Value
Example Linux and Solaris
Values
<%java.home%>
/System/Library/Frameworks/JavaVM /local/local/java/j2sdk1.4.1_02/
.framework/ Versions/1.4.2/Home
jre
<%java.io.tmpdir%>
/tmp
/tmp
<%user.dir%>
/Users/admin
/home-shared/cknouse
<%user.home%>
/Users/admin
/home/cknouse
NOTE: Although environment variables are formatted in the same way as Toolkit
Template directives, they are not interchangeable and you should not confuse
them.
Specifying Customized Requirements Using Custom Rules

297
Juniper Networks Secure Access Administration Guide
Evaluating Multiple Rules in a Single Host Checker Policy
If you choose to include multiple rules within a single client-side policy, you must
specify how Host Checker should evaluate those rules.
To specify requirements for multiple rules within a Host Checker policy:
1. In the admin console, choose Authentication > Endpoint Security > Host
Checker.
2. In the Policies section of the page, click on an existing policy that includes
multiple rules.
3. In the Require section, select one of the following options:

All of the above rules—Select this option to specify that the user’s
computer must return a success value for all of the policy’s rules to gain
access.

Any of the above rules—Select this option to specify that the user’s
computer must return a success value for any of the policy’s rules to gain
access.

Custom—Select this option to customize the rules that the user’s computer
must meet to gain access. Then, create the custom rule using instructions
in the following step.
4. (Custom expressions only) If you want to use alternative sets of rules in the
policy, combine rules with Boolean operators (AND, OR, NOT) using the
following guidelines:

Enter the name of the rules in the Rules expression text box.

Use the AND or && operator to require two rules or sets of rules to return a
true value.

Use the OR or || operator to require either of two rules or sets to return a
true value.

Use the NOT or ! operator to exclude a rule.

Use parenthesis to combine sets of rules.

When combining integrity measurement custom rules, you can use the key
words Allow, Deny, Isolate, and NoRecommendation. For example, you can
use the following expressions to require a personal firewall to run, and
require either of two possible antivirus products to run:
ZoneLabsFirewall AND (McAfeeAntivirus OR NortonAntivirus)
5. Click Save Changes.
298

Specifying Customized Requirements Using Custom Rules
Chapter 13: Host Checker
Configuring Patch Assessment Policies
You can configure Host Checker policies that check for Windows endpoint’s
operating system service pack, software version, or desktop application patch
version compliance.
Host Checker uses a list of the most current patch versions from the vendor for predefined rules in the Host Checker policy.
You obtain the most current patch version information from a staging site at Juniper
Networks. You can manually download and import the current list into the IVE, or
you can automatically import the current list from the Juniper Networks staging site
or your own staging site at the specified interval.
Checks can be based on one or more specified products or on specific patches,
though not in the same policy. For example, you could check for Internet Explorer
version 7 with one policy, and Patch MSOO-039: SSL Certificate Validation
Vulnerabilities with a second policy. Then, apply both policies to endpoints at the
role or realm level to ensure that the user has the latest browser version with a
specific patch. Additionally, you can specify the severity level of patches that you
wish to ignore for Microsoft products; for example, you could choose to ignore low
or moderate threats.
The IVE can send remediation instructions (e.g. a message describing what patches
or software are non-compliant, and a link to where the endpoint can obtain the
patch). The IVE does not auto-remediate in the event of a non-compliant endpoint.
However, you can choose to send the items to the client for manual remediation of
managed machines.
When an endpoint first connects to the IVE, the latest versions of the data files and
libraries of the IMC are downloaded to the host computer. The initial check takes 1020 seconds to run, depending on the link speed. If outdated, these files are
automatically updated at subsequent checks. If this is the first time the endpoint
has connected to an IVE with the patch assessment policy, and the connection is a
Layer 2 connection, the IMC required to run the Patch Assessment check cannot
download. In this case, you should configure a remediation role which displays
instructions to direct the user to retry with a Layer 3 connection or contact the
administrator.
Note that in non-English installations, the English version of local patches is
displayed.
Using a System Management Server
For Windows clients, you can use a System Management Server (SMS) to provide a
method for automatic updates to non-compliant software.
Endpoints configured with SMS for software management typically poll the server
for updates every fifteen minutes or longer. In a worst-case scenario, clients that are
not in compliance with existing Host Checker software requirements may have to
wait until the next update interval to login.
Using the SMS remediation feature, you can force the client to initiate the software
update immediately after the patch assessment check.
Specifying Customized Requirements Using Custom Rules

299
Juniper Networks Secure Access Administration Guide
If a user attempts to log in, and the endpoint does not have a required software
version for compliance with a Host Checker patch assessment policy, Host Checker
immediately notifies the client to poll the server for an immediate update. The
client receives notification that an SMS update has started.
To have the SMS update the client when notified, set the advertisement time on the
SMS to As soon as possible.

The IVE 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 IVE.

The IVE evaluates the results and sends reason strings and remediation
information to the client, including a message that directs the client to poll the
server for software advertisements immediately.

The SMS client queries the SMS server for software advertisements.

The server identifies what patches should be advertised to the client (this is
configured on the server, Host Checker does not interact with the server).

The SMS client receives the advertisement and applies the required patch(es).
You assign clients to a particular group or collection on the server, then the SMS
can advertise patches for that collection. You can configure roles on the IVE that
correspond to collections, and SMS can send the appropriate patches for a
particular role.
You must have the SMS client installed and configured correctly on endpoints, and
the SMS server must be reachable. In a Layer 2 network, Host Checker is
performed before the endpoint is connected to the network. Host Checker can
obtain the IP address of the SMS server configured for the client. If the endpoint is
out of compliance and remediation is necessary, Host Checker pings the server IP
address every 15 seconds until the server can be notified to update the client.
It is important as an administrator to inform users of the expected behavior if this
feature is enabled, as there is no notification to the user until SMS sends back the
advertisement.
To configure a patch assessment custom rule:
1. In the admin console, choose Authentication > Endpoint Security > Host
Checker.
2. Create a new policy using instructions in “Creating and Configuring New Clientside Policies” on page 280 or click on an existing policy in the Policies section
of the page.
3. Click the Windows tab.
4. Under Rule Settings, choose Custom: Patch assessment.
5. Click Add under Rule Settings. The Add Custom Rule:Patch assessment page
appears.
300

Specifying Customized Requirements Using Custom Rules
Chapter 13: Host Checker
6. Enter a name for the integrity measurement rule.
NOTE: If a selection that is not applicable is included in a policy, i.e. the endpoint
does not have the targeted software, the rule will be ignored and the check for that
particular selection will pass.
7. Select either Scan for specific products or Scan for specific patches.
If you select Scan for specific products you must further select either All
Products or Specific Products.
If you select All Products, Host Checker checks for all of the exposed patches
on the endpoint.
To configure a policy based on specific products:
a.
Choose the All Products option button.
b.
Optionally, select specific patches that you wish to ignore for all products
by clicking the Add button under Ignore following patches.
c.
Click Save Changes.
d. Optionally, for Microsoft products, clear the check boxes to determine the
severity level of the patches that you wish to ignore. For example, if you
wanted to check for only critical patches for the selections, clear the check
boxes for Important, Moderate, Low, and Unspecified.
e.
Click Save Changes.
If you select Specific Products, two new dialogs open. You can select from an
extensive listing of products and versions, and you can choose to ignore
specific patches.
For example, if you add Internet Explorer 6 to the Selected Products list, you
can choose to ignore any patches that you do not consider critical for the
product. You can further fine-tune the severity level of specific patches to be
ignored by clearing the severity check boxes for Microsoft products.
To configure a policy based on specific products:
a.
Choose the Specific Products option button.
b.
Select software from the Available products window and add to the
Selected products window.
c.
Click Save Changes.
d. Optionally, select specific patches that you wish to ignore for the chosen
products by clicking the Add button under Ignore following patches.
When you click the Add button, a new dialog opens, displaying all of the
available patches for the software you have selected.
Specifying Customized Requirements Using Custom Rules

301
Juniper Networks Secure Access Administration Guide
e.
Select specific patches that you wish to ignore from the Available patches
window and add to the Selected patches window.
f.
Click the Add button under Add.
When you click the Add button, the Ignore following patches window is
populated with the patches you have chosen.
g.
Optionally, clear the check boxes to determine the severity level of the
patches for Microsoft products that you wish to ignore. For example, if you
wanted to check only for critical patches for the selections, clear the check
boxes for Important, Moderate, Low, and Unspecified.
NOTE: The severity level check boxes only apply to Microsoft products. For other
vendors, such as Adobe, the Unspecified check box determines whether or not the
check will be run.
h. Click Save Changes.
The Scan for specific patches option allows you to choose from a list of all
available patches.
To configure a policy based on patches:
a.
Choose the Scan for specific patches option button.
When you select the Scan for specific patches option a new dialog opens,
allowing you to add specific patches.
b.
Click the Add button.
c.
Select specific patches that you wish to check for from the Available
patches window and add to Selected patches.
d. Click the Add button.
e.
Click Save Changes.
8. Click Save Changes.
9. To direct the IVE to notify the SMS server to update the client in the event of a
failed Patch Assessment rule, select Enable SMS patch update. SMS remediation
will be triggered each time Host Checker detects that an endpoint is not
compliant.
10. Click Save Changes.
You can display remediation information for users based on which
patch/version needs to be updated. For example, you can configure a reason
string to display information about a patch that is missing and specify a link to
take the user to the web page to get the patch.
302

Specifying Customized Requirements Using Custom Rules
Chapter 13: Host Checker
11. To display remediation information to users, select the Send Reason Strings
option under Remediation on the main Host Checker Policy page. For more
information about this option, see “Configuring General Host Checker
Remediation” on page 318.
Using third-party integrity Measurement Verifiers
The Trusted Network Connect (TNC) standard enables the enforcement of security
requirements for endpoints connecting to networks. The client-side components of
the TNC are the IMCs and the TNC-client (TNCC). The TNCC compiles the IMC
measurements and sends them to the server. At the server, there is a corresponding
set of components: the TNC-server (TNCS) and the IMVs. The TNCS manages the
messages between the IMVs and the IMCs and sends the recommendations, based
on the IMVs, to the policy engine. For more information about IMVs and IMCs, see
“The TNC Architecture Within Host Checker” on page 273.
The IVE and Host Checker comply with the standards produced by the TNC. For
more information about the TNC, IMVs and IMCs, see
www.trustedcomputinggroup.org.
You can configure Host Checker to monitor third-party TNC-compliant IMCs
installed on client computers. To do so, you must:
1. Run the Third-party Integrity Measurement Verifier (IMV) Server installer on
the system designated as the remote IMV server. Install the third-party IMVs
and create the server certificates. See “Configuring a Remote IMV Server” on
page 303.
2. Specify the remote IMV server so that the IVE can communicate with it. See
“Specifying the Remote IMV Server” on page 307.
3. Implement the Host Checker policy. See “Implementing the Third-Party IMV
Policy” on page 308.
Configuring a Remote IMV Server
During this step, you install third-party IMVs. Third-party IMVs are installed on the
remote IMV server, not on the IVE.
During this step, you also obtain a server certificate for the remote IMV server. You
import the trusted root CA certificate of the CA that generated the server certificate
onto the IVE. The IVE then authenticates with the remote IMV server through the
certificate. If you do not have a certificate authority, install and use OpenSSL to
generate a CA certificate.
To install and configure the server software:
1. In the admin console of the IVE, choose Maintenance > System > Installers
and download the Third-party Integrity Measurement Verifier (IMV) Server
installer.‘
2. Run the installer on the system designated as the remote IMV server.
Using third-party integrity Measurement Verifiers

303
Juniper Networks Secure Access Administration Guide
3. Install the third-party IMVs on the remote IMV server and the corresponding
IMCs on the client systems.
4. Generate a server certificate from a certificate authority for the remote IMV
server. The server’s certificate Subject CN value must contain the actual host
name or IP address of the remote IMV server. For more information on creating
certificates, see “Using Trusted Server CAs” on page 753.
The server certificate and the private key must be combined into a single
PKCS#12 file and encrypted with a password.
If you do not have a certificate authority, you can use the following steps to
create a CA and then create a server certificate for the remote IMV server.
NOTE: Install the full version of OpenSSL. The "light" version of OpenSSL will not
work.
Follow the steps below to set up OpenSSL:
i.
Download and install OpenSSL from this site:
http://www.slproweb.com/products/Win32OpenSSL.html
i.
At the Windows command prompt, type the following commands:
cd \openssl
md certs
cd certs
md demoCA
md demoCA\newcerts
edit demoCA\index.txt
ii.
Press the ALT-F keys and then the S key to save the file.
iii. Press the ALT-F keys and then the X key to exit the editor.
iv. At the Windows command prompt, type the following commands:
edit demoCA\serial
v.
Type the following in the document window: 01
vi. Press the ALT-F keys and then the S key to save the file.
vii. Press the ALT-F keys and then the X key to exit the editor.
viii. At the Windows command prompt, type the following command:
set path=c:\openssl\bin;%path%
Follow the steps below to create a CA key:
ix. To create a CA key, type the following command at the Windows
command prompt in the c:\openssl\certs directory:
304

Using third-party integrity Measurement Verifiers
Chapter 13: Host Checker
openssl genrsa -out ca.key 1024
The following output should appear:
Loading 'screen' into random state - done
Generating RSA private key, 1024 bit long modulus
........++++++
.++++++
e is 65537 (0x10001
Follow the steps below to create a CA Certificate:
i.
Type the following command at the Windows command prompt in the
c:\openssl\certs directory:
openssl req -new -x509 -days 365 -key ca.key -out
demoCA/cacert.pem
ii.
Enter the appropriate Distinguished Name (DN) information for the CA
certificate. You can leave some fields blank by entering a period.
For example:
Country Name: US
State or Province Name: CA
Locality Name: Sunnyvale
Organization Name: XYZ
Org. Unit Name: IT
Common Name: ic.xyz.com
Email Address: user@xyz.com
c.
To set up the CA, type the following command at the Windows command
prompt in the directory c:\openssl\certs:
copy ca.key demoCA
notepad demoCA.cnf
d. When prompted to create a new file, press the yes button.
e.
Type the following lines in the document, pressing the Enter key at the end
of each line.
[ca]
default_ca = demoCA
[demoCA]
dir = ./demoCA
database = $dir/index.txt
new_certs_dir = $dir/newcerts
certificate = $dir/cacert.pem
serial = $dir/serial
private_key = $dir/ca.key
default_days = 365
default_md = md5
policy = policy_any
email_in_dn = no
Using third-party integrity Measurement Verifiers

305
Juniper Networks Secure Access Administration Guide
name_opt = ca_default
cert_opt = ca_default
copy_extensions = none
[ policy_any ]
countryName = supplied
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
f.
Save the file and close notepad.
g.
Type the following command to generate an RSA private key for the
remote IMV server:
openssl genrsa –out rimvs_key.pem 1024
h. Type the following command to generate a CSR for the remote IMV server:
openssl req –new –key rimvs_key.pem –out rimvs_csr.pem
i.
Type the following lines:
Country Name:
State or Province Name:
Locality Name:
Organization Name:
Organizational Unit Name:
Common Name: [IPAddress]
Email Address:
A challenge password:
An optional company name:
You may enter any value you like for most fields, but the Common Name
field must contain the IP address of the machine running the remote IMV
server. This machine should have a static IP address.
j.
Type the following command to generate a certificate for the remote IMV
server:
openssl ca –config demoCA.cnf –in rimvs_csr.pem –out rimvs_cert.pem
k.
Type ‘y’ twice when prompted to generate the certificate. This certificate is
valid for 365 days by default. If you want a different certificate lifetime,
change the default_days parameter in the demoCA.cnf file, or use the –
days parameter to the openssl ca command to specify a different lifetime.
l.
Type the following command to place the remote IMV server key and
certificate in a PKCS#12 file (substitute your password):
openssl pkcs12 –export –in rimvs_cert.pem –inkey rimvs_key.pem –passout
pass:<password> -out rimvs_p12.pem
306

Using third-party integrity Measurement Verifiers
Chapter 13: Host Checker
5. On the remote IMV server, choose Programs > Juniper Networks > Remote
IMV Server > Remote IMV Server Configurator from the Start menu.
6. Under Client Info, click Add.
7. Configure the port to service SOAP requests from the IVE.
8. Enter the client’s IP address, the number of addresses to use, and the shared
secret used by both the IVE and the remote IMV server.
9. Change logging settings if you choose (log is generated in the install directory).
10. Browse and find the PKCS#12 file you generated in the filesystem.
11. Specify the password associated with the certificate.
12. In the admin console of the IVE, use the System > Configuration >
Certificates > Trusted Server CAs tab to import the trusted root CA certificate
of the CA that issued the certificate for the remote IMV server.
If you used OpenSSL to generate the Remote IMV Server’s server certificate is:
demoCA\cacert.pem.
If you did not use OpenSSL to generate this certificate, ensure that the file you
import has the CA certificate (not the root certificate).
13. Click Import Trusted Server CA and browse for the server certificate used on
the remote IMV server.
14. Add the new remote IMV server on the “Specifying the Remote IMV Server” on
page 307.
Specifying the Remote IMV Server
To specify the remote IMV server so that the IVE can communicate with it:
1. In the admin console, choose Authentication > Endpoint Security > Host
Checker.
2. Under Remote IMV, click New Server.
3. In the New Server page:
a.
Create a label for the server using the Name and (optional) Description
fields.
b.
In the Hostname field, enter either the IP address or host name as defined
in the server certificate.
c.
In the Port field, enter the unique port number the IVE uses to
communicate with the remote IMV server. Ensure that no other service is
using this port number.
The default port number is the same as the default https port number. If
you are running a web server on the same system as the Remote IMV
Server, enter a new port number in the Port field.
Using third-party integrity Measurement Verifiers

307
Juniper Networks Secure Access Administration Guide
d. In the Shared Secret field, enter the same shared secret used in the client
information entry on the remote IMV server.
e.
Click Save Changes
4. Under Remote IMV, click New IMV to specify the third-party IMV.
5. In the New IMV page:
a.
Create a label for the IMV using the Name and (optional) Description
fields.
b.
In the IMV Name field, enter the name of the IMV. This name must match
the “human readable name” in the IMV’s well-known registry key on the
remote IMV server. For more information about human readable names
and the well-known registry key, see www.trustedcomputinggroup.org.
c.
From the Primary Server pop-up menu, select the remote IMV server
where this IMV is installed.
d. (Optional) From the Secondary Server pop-up menu, select the secondary
remote IMV server where this IMV is installed. The secondary server acts as
a failover in case the primary server becomes unavailable.
The IVE continues to try to re-establish connection to the primary remote
IMV Server, and uses the primary Remote IMV Server on subsequent
handshakes once it becomes available.
e.
Click Save Changes.
6. Click Save Changes.
Implementing the Third-Party IMV Policy
To use Host Checker as a policy enforcement tool for managing endpoints, you
must create global Host Checker policies at the system level through the
Authentication > Endpoint Security > Host Checker page of the admin console,
and then implement the policies at the realm and role levels.
To implement the third-party IMV 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. Under Rule Settings, choose Custom: Remote IMV and click Add.
5. In the Add Custom Rule: Remote IMV page:
a.
308

In the Rule Name field, enter an identifier for the rule.
Using third-party integrity Measurement Verifiers
Chapter 13: Host Checker
b.
Under Criteria, select the third-party IMV to be associated with this rule.
c.
Click Save Changes.
6. Specify how Host Checker should evaluate multiple rules within the policy
using instructions in “Evaluating Multiple Rules in a Single Host Checker Policy”
on page 298.
7. (Recommended) Specify remediation options for users whose computers do
not meet the requirements specified in the policy. For instructions, see
“Configuring General Host Checker Remediation” on page 318.
8. Click Save Changes.
9. Implement the policy at the realm or role level using the options described in
“Configuring Host Checker Restrictions” on page 314.
Combining Multiple Integrity Measurement Rules with Custom
Expressions
You can combine multiple integrity measurement rules in a single Host Checker
policy, and each rule can return one of two results: Allow or Deny.
A Required rule will return Allow if it matches and Deny if it fails. A Deny rule will
return Deny if it matches and Allow if it fails. If you choose the Any of the above
rules option on the Host Checker policy, the rule will be satisfied if at least one of
the rules returns Allow. If you choose All of the above rules, then the rule will be
satisfied if all the rules return Allow. In either case, if the result of a compliance rule
cannot be completed for some reason, that rule will be considered to have failed.
Some third-party IMVs can also return an Isolate result. When using either the Any
of the above rules or All of the above rules option, an Isolate result is treated as
Deny. If you wish to treat Isolate results differently, you must choose the Custom
option to use the exact results of the rules in determining the final outcome. For
example, if you have two rules Sym1 and Mac1, you could use this custom
combination of rules:
(Sym1 == Isolate AND Mac1 == NoRecomendation) OR
(Sym1 == NoRecommendation AND Mac1 == Allow)
You can omit the Allow keyword in the custom expression. For example:
rule1 OR rule2
is equivalent to:
rule1 == Allow OR rule2 == Allow
Combining Multiple Integrity Measurement Rules with Custom Expressions  309
Juniper Networks Secure Access Administration Guide
Enabling Customized Server-side Policies
For Windows clients, you can create global Host Checker policies which take a
third-party J.E.D.I. DLL that you upload to the IVE and run on client machines.
NOTE: This feature is primarily provided for backwards compatibility. We
recommend that you use IMCs and IMVs instead, as described in “The TNC
Architecture Within Host Checker” on page 273.
Uploading a Host Checker Policy Package to the IVE
For the IVE to recognize a package definition file, you must:
1. Name the package definition file MANIFEST.HCIF and include it 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, 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 IVE using the
instructions in “Enabling Customized Server-side Policies” on page 310. You
can upload multiple policy packages to the IVE, each containing a different
MANIFEST.HCIF file.
NOTE: After you upload a Host Checker policy package to the IVE, you cannot
modify the package contents on the server. Instead, you must modify the package
on your local system and then upload the modified version to the IVE.
Host Checker creates tunnels for all of the tunnel definitions in all of the
MANIFEST.HCIF files, assuming the definitions are unique. To view the list of
pre-authentication access tunnel definition(s) for a policy package, click the
name of the policy package under 3rd Party Policy on the Host Checker
Configuration page. The IVE lists the tunnel definition(s) under Host Checker
Preauth Access Tunnels on the 3rd Party Policy page.
4. Implement the policy at the realm, role, or resource policy levels using the
options described in “Configuring Host Checker Restrictions” on page 314. 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 <PackageName>.<PolicyName>. For example, to enforce the FileCheck
policy in the myPestPatrol package, use myPestPatrol.FileCheck. For instructions,
see “Configuring Host Checker Restrictions” on page 314.
310

Combining Multiple Integrity Measurement Rules with Custom Expressions
Chapter 13: Host Checker
To enable a customized server-side Host Checker policy:
1. In the admin console, choose Authentication > Endpoint Security > Host
Checker.
2. Under Policies, click New 3rd Party Policy.
3. Enter a name to identify your zip file on the IVE.
4. Browse to the local directory where your zip file is located.
5. (Optional) Specify remediation instructions and actions for users whose
computers do not meet the requirements specified in the policy. For
instructions, see “Configuring General Host Checker Remediation” on
page 318.
6. Click Save Changes. The IVE adds the policies defined in your zip file to the list
of policies on the Host Checker page.
7. Implement the policies at the realm, role, or resource policy levels using the
options described in “Configuring Host Checker Restrictions” on page 314.
Implementing Host Checker Policies
After you create global policies through the Authentication > Endpoint Security
> Host Checker page of the admin console, you can restrict IVE and resource
access by requiring Host Checker in a:

Realm authentication policy—When administrators or users try to sign in to
the IVE or launch a Virtual Workspace session, the IVE evaluates the specified
realm’s authentication policy to determine if the pre-authentication
requirements include Host Checker. You can configure a realm authentication
policy to download Host Checker, launch Host Checker and enforce Host
Checker policies specified for the realm, or not require Host Checker. The user
must sign in using a computer that adheres to the Host Checker requirements
specified for the realm. If the user’s computer does not meet the requirements,
then the IVE denies access to the user unless you configure remediation actions
to help the user bring his computer into compliance. You can configure realmlevel restrictions through the Administrators > Admin Realms > SelectRealm
> Authentication Policy > Host Checker page or the Users > User Realms
> SelectRealm > Authentication Policy > Host Checker page of the admin
console.

Realm authentication policy—When administrators or users try to sign in to
the IVE, the IVE evaluates the specified realm’s authentication policy to
determine if the pre-authentication requirements include Host Checker. You
can configure a realm authentication policy to download Host Checker, launch
Host Checker and enforce Host Checker policies specified for the realm, or not
require Host Checker. The user must sign in using a computer that adheres to
the Host Checker requirements specified for the realm. If the user’s computer
does not meet the requirements, then the IVE denies access to the user unless
Implementing Host Checker Policies

311
Juniper Networks Secure Access Administration Guide
you configure remediation actions to help the user bring his computer into
compliance. You can configure realm-level restrictions through the
Administrators > Admin Realms > SelectRealm > Authentication Policy >
Host Checker page or the Users > User Realms > SelectRealm >
Authentication Policy > Host Checker page of the admin console. If you have
enabled EES, you can select this feature from any realm.

Role—When the IVE determines the list of eligible roles to which it can map an
administrator or user, it evaluates each role’s restrictions to determine if the
role requires that the user’s computer adheres to certain Host Checker policies.
If it does and the user's computer does not follow the specified Host Checker
policies, then the IVE does not map the user to that role unless you configure
remediation actions to help the user bring his computer into compliance. You
can configure role-mapping using settings in the Users > User Realms >
SelectRealm > Role Mapping page. You can configure role-level restrictions
through the Administrators > Admin Roles > SelectRole > General >
Restrictions > Host Checker page of the admin console or the Users > User
Roles> SelectRole > General > Restrictions > Host Checker page. If you
have enabled EES, you can select to implement this feature for any role.

Resource policy—When a user requests a resource, the IVE evaluates the
resource policy’s detailed rules to determine if the resource requires that the
user’s computer adheres to certain Host Checker policies. The IVE denies
access to the resource if the user's computer does not follow the specified Host
Checker policies unless you configure remediation actions to help the user
bring his computer into compliance. To implement Host Checker restrictions at
the resource policy level, use settings in the Users > Resource Policies >
SelectResource > SelectPolicy > Detailed Rules page.
You may specify that the IVE evaluate your Host Checker policies only when the
user first tries to access the realm, role, or resource that references the Host
Checker policy. Or, you may specify that the IVE periodically re-evaluate the
policies throughout the user’s session. If you choose to periodically evaluate Host
Checker policies, the IVE dynamically maps users to roles and allows users access
to new resources based on the most recent evaluation.
Executing Host Checker Policies
When the user tries to access the IVE, Host Checker evaluates its policies in the
following order:
1. Initial evaluation—When a user first tries to access the IVE sign-in page, Host
Checker performs an initial evaluation. Using the rules you specify in your
policies, Host Checker verifies that the client meets your endpoint
requirements and returns its results to the IVE. Host Checker performs an
initial evaluation regardless of whether you have implemented Host Checker
policies at the realm, role, or resource policy level.
If the user navigates away from the IVE sign-in page after Host Checker starts
running but before signing in to the IVE, Host Checker continues to run on the
user’s machine until the Host Checker process times out.
If the IVE does not receive a result from Host Checker for any reason (including
because the user manually terminated Host Checker), the IVE displays an error
and directs the user back to the sign-in page.
312

Implementing Host Checker Policies
Chapter 13: Host Checker
Otherwise, if the Host Checker process returns a result, the IVE goes on to
evaluate the realm level policies.
2. Realm-level policies—The IVE uses the results from Host Checker’s initial
evaluation to determine which realms the user may access. Then, the IVE
displays or hides realms from the user, only allowing him to sign into those
realms that you enable for the sign-in page, and if he meets the Host Checker
requirements for each realm. If the user cannot meet the Host Checker
conditions required by any of the available realms, the IVE does not display the
sign-in page. Instead, it displays an error stating the user has no access unless
you configure remediation actions to help the user bring his computer into
compliance.
Note that Host Checker only performs realm-level checks when the user first
signs into the IVE. If the state of the user’s system changes during his session,
the IVE does not remove him from the current realm or allow him access to a
new realm based on his new system state.
3. Role-level policies—After the user signs into a realm, the IVE evaluates rolelevel policies and maps the user to the role or roles if he meets the Host
Checker requirements for those role(s). Then, the IVE displays the IVE
homepage to the user and enables those options that the mapped role(s) allow.
If Host Checker returns a different status during a periodic evaluation, the IVE
dynamically remaps the user to roles based on the new results. If the user loses
rights to all available roles during one of the periodic evaluations, the IVE
disconnects the user’s session unless you configure remediation actions to help
the user bring his computer into compliance.
4. Resource-level policies—After the IVE allows the user to access the homepage,
the user may try to access a resource that is controlled by a resource policy.
When he does, the IVE determines whether or not to perform the action
specified in the resource policy based on the last status returned by Host
Checker.
If Host Checker returns a different status during a periodic evaluation, the new
status only impacts new resources that the user tries to access. For example, if
the user successfully initiates a Network Connect session and then fails his next
resource-level host check, he may continue to access the open Network
Connect session. The IVE only denies him access if he tries to open a new
Network Connect session. The IVE checks the last status returned by Host
Checker whenever the user tries to access a new Web resource or open a new
Secure Application Manager, Network Connect, or Secure Terminal Access
session.
With either a success or fail result, Host Checker remains on the client. Windows
users may manually uninstall the agent by running uninstall.exe in the directory
where Host Checker is installed. If you enable client-side logging through the
System > Log/Monitoring > Client Logs page, this directory also contains a log
file, which the IVE rewrites each time Host Checker runs.
Implementing Host Checker Policies

313
Juniper Networks Secure Access Administration Guide
If you enable dynamic policy evaluation for Host Checker (see “Understanding
Dynamic Policy Evaluation” on page 55), the IVE evaluates resource policies
implemented at the realm level whenever a user’s Host Checker status changes. If
you do not enable dynamic policy evaluation for Host Checker, the IVE 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.
For configuration instructions, see “Specifying General Host Checker Options” on
page 325.
Configuring Host Checker Restrictions
To specify Host Checker restrictions:
1. Navigate to: Authentication > Endpoint Security > Host Checker and
specify global options for Host Checker to apply to any user for whom Host
Checker is required in an authentication policy, a role mapping rule, or a
resource policy.
2. If you want to implement Host Checker at the realm level:
a.
b.
c.
Navigate to:

Administrators > Admin Realms > Select Realm > Authentication
Policy > Host Checker

Users > User Realms > Select Realm > Authentication Policy >
Host Checker
Choose one of the following options for either all available policies or for
individual policies listed in the Available Policies column:

Evaluate Policies—Evaluates without enforcing the policy on the client
and allows user-access. This option does not require Host Checker to
be installed during the evaluation process; however, Host Checker is
installed once the user signs in to the IVE.

Require and Enforce—Requires and enforces the policy on the client
in order for the user to log in to the specified realm. Requires that Host
Checker is running the specified Host Checker policies in order for the
user to meet the access requirement. Requires the IVE to download
Host Checker to the client machine. If you choose this option for a
realm’s authentication policy, then the IVE downloads Host Checker to
the client machine after the user is authenticated and before the user is
mapped to any roles in the system. Selecting this option automatically
enables the Evaluate Policies option.
Select the Allow access to realm if any ONE of the selected “Require and
Enforce” policies is passed check box if you do not want to require users
to meet all of the requirements in all of the selected policies. Instead, the
user can access the realm if he meets the requirements of any one of the
selected Host Checker policies.
3. If you want to implement Host Checker at the role level:
a.
314

Implementing Host Checker Policies
Navigate to:
Chapter 13: Host Checker
b.
c.

Administrators > Admin Roles > Select Role > General >
Restrictions > Host Checker

Users > User Roles > Select Role > General > Restrictions > Host
Checker
Choose one of the following options:

Allow all users — Does not require Host Checker to be installed in
order for the user to meet the access requirement.

Allow only users whose workstations meet the requirements
specified by these Host Checker policies — Requires that Host
Checker is running the specified Host Checker policies in order for the
user to meet the access requirement.
Select the Allow access to role if any ONE of the selected “Require and
Enforce” policies is passed check box if you do not want to require users
to meet all of the requirements in all of the selected policies. Instead, the
user can access the role if he meets the requirements of any one of the
selected Host Checker policies.
4. If you want to create role-mapping rules based on a user’s Host Checker status:
a.
Navigate to: Users > User Realms > Select Realm > Role Mapping.
b.
Click New Rule, select Custom Expressions from the Rule based on list,
and click Update. Or, to update an existing rule, select it from the When
users meet these conditions list.
c.
Click Expressions.
d. Write a custom expression for the role mapping rule to evaluate Host
Checker’s status using the hostCheckerPolicy variable. For help writing the
custom expressions, use tips in the Expressions Dictionary. Or, see
“Custom Expressions” on page 1013.
e.
In the ...then assign these roles section, select the roles that the IVE
should map users to when they meet the requirements specified in the
custom expression and click Add.
f.
Select the Stop processing rules when this rule matches if you want the
IVE to stop evaluating role mapping rules if the user successfully meets the
requirements defined in this rule.
5. If you want to implement Host Checker at the resource policy level:
a.
Navigate to: Users > Resource Policies > Select Resource > Select Policy
> Detailed Rules.
b.
Click New Rule or select an existing rule from the Detailed Rules list.
Implementing Host Checker Policies

315
Juniper Networks Secure Access Administration Guide
c.
Write a custom expression for the detailed rule to evaluate Host Checker’s
status using the hostCheckerPolicy variable. For help writing the custom
expressions, use tips in the Conditions Dictionary. Or, see “Custom
Expressions” on page 1013.
These options allow you to control which version of an application or service runs
on client machines.
Remediating Host Checker Policies
You can specify general remediation actions that you want Host Checker to take if
an endpoint does not meet the requirements of a policy. For example, you can
display a remediation page to the user that contains specific instructions and links
to resources to help the user bring their endpoint into compliance with Host
Checker policy requirements.
You can also choose to include a message to users (called a reason string) that is
returned by Host Checker or an integrity measurement verifier (IMV) and explains
why the client machine does not meet the Host Checker policy requirements.
For example, the user may see a remediation page that contains the following
custom instructions, a link to resources, and reason strings:
Your computer's security is unsatisfactory.
Your computer does not meet the following security requirements. Please follow
the instructions below to fix these problems. When you are done click Try Again. If
you choose to Continue without fixing these problems, you may not have access
to all of your intranet servers.
1. Symantec
Instructions: You do not have the latest signature files. Click here to download
the latest signature files.
Reasons: The AntiVirus Product Version is too low. The age of the Virus
Definitions is not acceptable.
For each Host Checker policy, you can configure two types of remediation actions:
316


User-driven—Using custom instructions, you can inform the user about the
failed policy and how to make his computer conform. The user must take
action to successfully re-evaluate the failed policy. For instance, you can create
a custom page that is linked to a policy server or Web page and enables the
user to bring his computer into compliance.

Automatic (system-driven)—You can configure Host Checker to automatically
remediate the user’s computer. For example, when the initial policy fails, you
can kill processes, delete files, or allow automatic remediation by an IMV (see
“The TNC Architecture Within Host Checker” on page 273). On Windows, you
can also call the HCIF_Module.Remediate () API function as part of a third-party
J.E.D.I. DLL. Host Checker does not inform users when performing automatic
actions. (You could, however, include information in your custom instructions
about the automatic actions.)
Remediating Host Checker Policies
Chapter 13: Host Checker
You can enable these remediation actions in both client-side and server-side
policies. For configuration instructions, see “Creating and Configuring New Clientside Policies” on page 280 or “Enabling Customized Server-side Policies” on
page 310.
Host Checker Remediation User Experience
Users may see the remediation page in the following situations:

Before the user signs in:

If you enable custom instructions for a policy that fails, the IVE displays the
remediation page to the user. The user has two choices:

Take the appropriate actions to make his computer conform to the
policy and then click the Try Again button on the remediation page.
Host Checker checks the user’s computer again for compliance with
the policy.

Leave his computer in its current state and click the Continue button
to sign in to the IVE. He cannot access the realm, role, or resource that
requires compliance with the failed policy.
NOTE: If you do not configure the IVE with at least one realm that allows access
without enforcing a Host Checker policy, the user must bring his computer into
compliance before signing into the IVE.


If you do not enable custom instructions for a policy that fails, Host
Checker does not display the remediation page to the user. Instead, the IVE
displays the sign-in page but does not allow the user to access any realms,
roles, or resources that have a failed Host Checker policy.
After the user signs in:

(Windows only) During a session, if a user’s Windows computer becomes
non-compliant with the requirements of a Host Checker policy, an icon
appears in the system tray along with a pop-up message that informs the
user of the non-compliance. The user can then click the pop-up message to
display the remediation page.

(Macintosh or Linux) During a session, if a user’s Macintosh or Linux
computer becomes non-compliant with the requirements of a Host
Checker policy, the IVE displays the remediation page to inform the user of
the non-compliance.
NOTE: If the user hides the remediation page by setting a user preference, he may
only continue using the secure gateway if you configure other realms and roles
that do not enforce a Host Checker policy.
Remediating Host Checker Policies

317
Juniper Networks Secure Access Administration Guide
Configuring General Host Checker Remediation
To specify remediation actions for a Host Checker policy:
1. In the admin console, choose Authentication > Endpoint Security > Host
Checker.
2. Create or enable Host Checker policies using instructions in either of the
following sections:

“Creating and Configuring New Client-side Policies” on page 280

“Enabling Customized Server-side Policies” on page 310
3. Specify the remediation actions that you want Host Checker to perform if a
user’s computer does not meet the requirements of the current policy:

Enable Custom Instructions—Enter the instructions you want to display to
the user on the Host Checker remediation page. You can use the following
HTML tags to format text and add links to resources such as policy servers
or web sites: <i>, <b>, <br>, <font>, and <a href>. For example:
You do not have the latest signature files.
<a href="www.company.com">Click here to download the latest signature
files.</a>
NOTE: For Windows clients, if you include in the instructions a link to an IVEprotected policy server, define a pre-authentication access tunnel. For information,
see “Specifying Host Checker Pre-Authentication Access Tunnel Definitions” on
page 322.

Enable Custom Actions—You can select one or more alternate policies
that you want Host Checker to evaluate if the user’s computer does not
meet the current policy requirements. The alternate policy must be either a
third-party policy that uses a J.E.D.I. package or a Secure Virtual
Workspace policy. For example, you can use a J.E.D.I. package to launch
an application if the user’s computer does not meet the current policy
requirements. Select the alternate policy in the HC Policies list and then
click Add.

Remediate—(Third party DLLs only) You can select this option to perform
remediation actions specified by means of the Remediate () API function in
a third-party J.E.D.I. DLL.
NOTE: The Remediate feature is primarily provided for backwards compatibility.
We recommend that you use IMCs and IMVs instead, as described in “The TNC
Architecture Within Host Checker” on page 273.

318

Remediating Host Checker Policies
Kill Processes—On each line, enter the name of one or more processes
you want to kill if the user’s computer does not meet the policy
requirements. You can include an optional MD5 checksum for the process.
(You cannot use wildcards in the process name.) For example:
Chapter 13: Host Checker
keylogger.exe
MD5: 6A7DFAF12C3183B56C44E89B12DBEF56

Delete Files—Enter the names of files you want to delete if the user’s
computer does not meet the policy requirements. (You cannot use
wildcards in the file name.) Enter one file name per line. For example:
c:\temp\bad-file.txt
/temp/bad-file.txt

Send reason strings—Select this option to display a message to users
(called a reason string) that is returned by Host Checker or integrity
measurement verifier (IMV) and explains why the client machine does not
meet the Host Checker policy requirements. This option applies to
predefined rules, custom rules, and to third-party IMVs that use extensions
in the Juniper Networks TNC SDK. For example, an antivirus IMV might
display the following reason string:
The AntiVirus Product Version is too low. The age of the Virus Definitions is not
acceptable.
NOTE: By sending reason strings, you are disclosing to users what the IMV is
checking on the client machine.
4. Click Save Changes.
Upgrading the Endpoint Security Assessment Plug-In
The Endpoint Security Assessment Plug-in (ESAP) on the IVE checks third-party
applications on endpoints for compliance with the pre-defined rules you configure
in a Host Checker policy. (See “Checking for Third-Party Applications Using Predefined Rules (Windows Only)” on page 281.) This plug-in is included in the IVE
system software package.
Juniper Networks frequently adds enhancements, bug fixes, and support for new
third-party applications to the plug-in. New plug-in releases are available
independently and more frequently than new releases of the IVE system software
package. If necessary, you can upgrade the plug-in on the IVE independently of
upgrading the IVE system software package.
You can upload up to four versions of the plug-in to the IVE, but the IVE uses only
one version at a time (called the active version). If necessary, you can rollback to a
previously active version of the plug-in.
To upgrade the Endpoint Security Assessment Plug-in:
1. Download the Endpoint Security Assessment Plug-in from the Juniper Networks
Customer Support Center to your computer:
a.
Open the following page:
https://www.juniper.net/customers/csc/software/ive/
b.
To access the Customer Support Center, enter a user name and password
for a Juniper Networks Support account.
Remediating Host Checker Policies

319
Juniper Networks Secure Access Administration Guide
c.
Click the ESAP link.
d. Click the ESAP Download Page link.
e.
Navigate to the ESAP release you want.
f.
Download the plug-in zip file to your computer.
2. Choose Authentication > Endpoint Security > Host Checker.
3. At the bottom of the Host Checker page under Manage Endpoint Security
Assessment Plug-In Versions:
a.
If you have previously uploaded four versions of the component software,
you must delete one of the versions before you can upload another one.
Select the version you want to delete and click Delete.
b.
If you want the IVE to actively begin using the new component software
immediately after you upload it, select the Set as active after upload
option.
c.
Click Browse, select the plug-in file you want to upload to the IVE, and click
OK.
d. Click Upload. While the IVE uploads and decrypts the plug-in .zip file, the
message “Loading...” appears in the plug-in list under Manage Endpoint
Security Assessment Plug-In Versions. If the IVE is a member of a cluster,
the IVE displays the message “Loading...” while the plug-in is transferred to
the other cluster nodes. After the plug-in is installed, the date and time of
the plug-in installation appears in the plug-in list.
320

Remediating Host Checker Policies
Chapter 13: Host Checker
e.
If you did not select the Set as active after upload option, activate the
plug-in you want to use by selecting the version in the plug-in list and
clicking Activate.
NOTE:

If you attempt to activate a version of the plug-in that does not support all of
the pre-defined rules already configured in all Host Checker policies, the IVE
does not allow activation of that plug-in version. For example, if a Host
Checker policy is configured to use a pre-defined rule to check for a version of
antivirus software, and you attempt to activate a plug-in version that does not
support that particular version of the antivirus software, the IVE does not
allow you to activate that plug-in version. To view the list of supported
products for a particular plug-in version, click the plug-in’s version number
under Manage Endpoint Security Assessment Plug-In Versions.

You can rollback to an older plug-in version after upgrading to a later version
by selecting the older version as the active version. But, if you modified any
Host Checker policies after upgrading to the later version, the rollback may
not succeed. Rollback is guaranteed to succeed only if the policies did not
change.

If you upgrade the IVE system software to a newer version, or you import a
user configuration file, the currently active plug-in version does not change. If
you want to use a different plug-in version after upgrading or importing a user
configuration file, you must manually activate that plug-in version.

If the IVE already has four versions of the plug-in installed when you upgrade
the IVE system software to a newer version, the IVE automatically deletes the
oldest plug-in version and installs, but does not activate, the plug-in included
with the new IVE system software.
Defining Host Checker Pre-Authentication Access Tunnels
If your policies require Host Checker rules or third-party J.E.D.I. DLLs to access a
policy server (or other resource) to check compliance before users are
authenticated, you can use one of the following methods to make the resource
available to the Host Checker Windows clients:

Deploy the policy server in a DMZ where Host Checker rules or third-party
J.E.D.I. DLLs can access the server directly instead of going through the
IVE—This deployment is the simplest solution because you do not have to
define a Host Checker pre-authentication access tunnel through the IVE
between clients and the policy server.

Deploy the policy server in a protected zone behind the IVE (Windows
only)—This deployment requires you to define a pre-authentication access
tunnel. A pre-authentication access tunnel enables Host Checker rules or thirdparty J.E.D.I. DLLs to access the IVE-protected policy server or resource before
the IVE authenticates users. To define a pre-authentication access tunnel, you
associate a loopback address (or host name) and port on the client with an IP
address and port on the policy server. You add one or more tunnel definitions
Defining Host Checker Pre-Authentication Access Tunnels

321
Juniper Networks Secure Access Administration Guide
to a MANIFEST.HCIF file, which you then upload to the IVE. You can upload
multiple MANIFEST.HCIF files to the IVE. For all third-party policies enabled on a
realm, Host Checker creates tunnels for all of the tunnel definitions in all of the
MANIFEST.HCIF files, assuming the definitions are unique. For configuration
instructions, see “Uploading a Host Checker Policy Package to the IVE” on
page 310.
While running on a Windows client, Host Checker listens for a connection on
each loopback address and port you specify in the tunnel definitions. The
connections can originate from the integrated Host Checker rules and from
client-side or server-side J.E.D.I. DLLs. Host Checker uses the preauthentication access tunnel(s) to forward the connections through the IVE to
the policy server(s) or other resource.
Figure 38: Host Checker Creates a Tunnel from a Client to a Policy Server Behind the IVE
NOTE: Host Checker pre-authentication access tunnels are supported on Windows
only.
Specifying Host Checker Pre-Authentication Access Tunnel Definitions
For Windows clients, you can define a pre-authentication access tunnel that
enables Host Checker methods or third-party J.E.D.I. DLLs to access an IVEprotected policy server (or other resource) before users are authenticated.
A definition for a Host Checker pre-authentication access tunnel configures access
to one policy server or other resource. Each tunnel definition consists of a pair of IP
addresses and ports: one loopback IP address and port on the client, and one IP
address and port on the policy server.
You specify one or more tunnel definition(s) in a Host Checker policy package
definition file. The package definition file, which must be named MANIFEST.HCIF,
defines the name of an interface DLL, the Host Checker policies defined in the DLL,
and the pre-authentication access tunnel definitions. Note that if you do not include
policies in your package, Host Checker simply enforces that the package has run on
the client. If you do declare policies through this file, they become available through
the admin console where you can implement them at the realm, role, and resource
policy levels.
322

Defining Host Checker Pre-Authentication Access Tunnels
Chapter 13: Host Checker
Within the MANIFEST.HCIF file, you must include one definition per line, with a
blank line between each definition, using the following format:
HCIF-Main: <DLLName>
HCIF-Policy: <PolicyName>
HCIF-IVE-Tunnel: <client-loopback>:port
<policy-server>:port
where:
<DLLName> is the name of the interface DLL, such as myPestPatrol.dll. Even if you
are not using an interface DLL, you must include a dummy DLL as a placeholder file
that has this exact name.
<PolicyName> is the name of a policy defined in the DLL, such as myFileCheck. You
can define multiple policies by using the HCIF-Policy statement for each policy. If
you are not using an interface DLL, you can use any policy name as a placeholder.
The syntax of a Host Checker tunnel definition is:
HCIF-IVE-Tunnel: <client-loopback>:port
<policy-server>:port
where:
<client-loopback> is a loopback address that begins with 127. and takes any of the
following forms:

An IP address and port that takes the form of 127.*.*.*:port. To avoid conflicts
with JSAM, do not use 127.0.0.1 with port 80, but you can use 127.0.0.1 with
other ports. For example: 127.0.0.1:3220

A host name that resolves to a loopback address that begins with 127. You can
use a local hosts file on each client computer or a DNS server to resolve the
loopback address.

A host name that does not resolve to a loopback address, or resolves to a nonloopback address. In these cases, Host Checker allocates a loopback address
and updates the local hosts file on the client with the mapping. Note that the
user must have administrator privileges in order for Host Checker to modify
the local hosts file. If the user does not have administrator privileges, Host
Checker cannot update the hosts file and cannot open the pre-authentication
access tunnel. In that case, Host Checker logs an error.
<policy-server> is the IP address or host name of the back-end policy server. The IVE
resolves the host name you specify.
For example, in the following tunnel definition, 127.0.0.1:3220 is the client
loopback address and port, and mysygate.company.com:5500 is the policy server
host name and port:
HCIF-IVE-Tunnel: 127.0.0.1:3220
mysygate.company.com:5500
Or you can use a host name for the client, as in this example:
Defining Host Checker Pre-Authentication Access Tunnels

323
Juniper Networks Secure Access Administration Guide
HCIF-IVE-Tunnel: mysygate.company.com:3220
mysygate.company.com:5500
Keep the following in mind when specifying tunnel definitions:

You must add a blank line between each line in the MANIFEST.HCIF file, and you
can use a semi-colon at the beginning of a line to indicate a comment. For
example:
HCIF-Main: myPestPatrol.dll
HCIF-Policy: myFileCheck
HCIF-Policy: myPortCheck
; Tunnel definitions
HCIF-IVE-Tunnel: 127.0.0.1:3220 mysygate.company.com:5500
HCIF-IVE-Tunnel: 127.1.1.1:3220 mysygate2.company.com:5500
HCIF-IVE-Tunnel: mysygate.company.com:3220 mysygate3.company.com:5500

Host Checker pre-authentication access tunnels are supported on Windows
only.

If <client-loopback> is a non-loopback address, then Host Checker cannot open
the pre-authentication access tunnel and logs an error instead.

If you use a loopback address other than 127.0.0.1 (such as 127.0.0.2 and
above), clients who are using Windows XP Service Pack 2 must install the XP
SP2 Hot Fix. See:
http://support.microsoft.com/default.aspx?scid=kb;en-us;884020
NOTE: If you are deploying a client-side or server-side third-party DLL, keep the
following in mind:
324


Unzip the server-side third-party DLL package and add the tunnel definitions
to the MANIFEST.HCIF file that contain the policies for the third-party DLL. (The
DLL must use the same <client-loopback> address and port or host name that
you specify in the MANIFEST.HCIF file.)

Since a pre-authentication access tunnel is open only while Host Checker is
running, a third-party DLL can access its IVE-protected policy server only
while Host Checker is running.

If a third-party DLL uses HTTPS to connect to its policy server via a host name
that resolves properly to the loopback address, no server certificate warnings
appear. However, if the third-party DLL connects explicitly via a loopback
address, then server certificate warnings do appear because the host name in
the certificate does not match the loopback address. (The developer of the
third-party DLL can configure the DLL to ignore these warnings.)
Defining Host Checker Pre-Authentication Access Tunnels
Chapter 13: Host Checker
Specifying General Host Checker Options
You can specify global options for Host Checker that apply to any user for whom
Host Checker is required in an authentication policy, a role mapping rule, or a
resource policy.
To specify general Host Checker options:
1. In the admin console, choose Authentication > Endpoint Security > Host
Checker.
2. Under Options:

In the Perform check every X minutes field, specify the interval at which
you want Host Checker to perform policy evaluation on a client machine. If
the client machine fails to meet the requirements of the Host Checker
policies required by a role or resource policy, then the IVE denies the
associated user requests.
For example, you may require that a user runs a specific third-party
antivirus application in order to map to Role A, which enables network
connections from an external location. If the user’s client machine is
running the required antivirus application when the user signs in to the
IVE, then the user maps to Role A and is granted all access features enabled
for Role A. If the antivirus application stops running during the user
session, however, the next time Host Checker runs, the user fails to meet
the security requirements for Role A and therefore loses all access
privileges for Role A.
When an end-user logs into a Realm, Host Checker performs an initial
policy check, regardless of whether or not the policy is enforced at the
Realm, Role, and/or Resource level. The initial policy check establishes a
start time. Host Checker evaluates policies at the frequency set by the
Perform check every X minutes option starting the clock at the initial
policy check. Although the frequency setting is set globally for all Host
Checker policy checking, it is not synchronized for all end-user clients
connected to the IVE. Each client performs its own initial policy check and
starts its own X minute countdown.
If you configure the authentication policy within a realm where Host
Checker enforces policies (versus installing), the enforcement occurs only
during the pre-authentication phase. After an end-user signs in and for the
duration of the user’s session, any subsequent Host Checker policy checks
have no impact on realm access, meaning that there is no concept of
removing an end-user session from a realm once an end-user successfully
authenticates into that realm.
Specifying General Host Checker Options  325
Juniper Networks Secure Access Administration Guide
If you configure a role restriction where Host Checker enforces policies, the
enforcement occurs just after authentication during role mapping. Role
restrictions are enforced periodically during the end-user session at an
interval specified using the Host Checker frequency setting. If the end-user
successfully passes the Host Checker evaluation during role mapping but
later fails X minutes after login, that specific user loses rights to that role. If
the end-user loses rights to all available roles due to Host Checker policy
evaluation, the end-user session is disconnected.
If you configure a resource-based policy rule where Host Checker enforces
policies, the enforcement occurs when the end-user attempts to access the
resource/backend server. For web resources, the Host Checker evaluation
occurs at each request. For SAM and STA resources, the Host Checker
evaluation occurs when the IVE activates the connection to the backend
application/server. For Network Connect access, the Host Checker
evaluation occurs when the IVE initiates Network Connect. Existing
connections of applications running by way of SAM, Telnet/SSH
connection, and Network Connect connections are not affected by further
Host Checker evaluations. Only new Web requests, new applications
across SAM, new instances of STA, and launching Network Connect are
affected. The Host Checker evaluation is based on the most recent policy
check that occurred X minutes ago. Example, if you configure the
frequency setting to Perform check every five minutes and the end-user
attempts to access a protected resource or attempts to launch Network
Connect four minutes after the last check, then the policy evaluation is
based on the state of the client machine four minutes ago, not at the
moment the end-user attempted to access the resource.
NOTE: If you enter a value of zero, Host Checker only runs on the client machine
when the user first signs into the IVE.


For the Client-side process, login inactivity timeout option, specify an
interval to control timing out in the following situations:

If the user navigates away from the IVE sign-in page after Host Checker
starts running but before signing in to the IVE, Host Checker continues
to run on the user’s machine for the interval you specify.

If the user is downloading Host Checker over a slow connection,
increase the interval to allow enough time for the download to
complete.
Select Perform dynamic policy reevaluation to automatically refresh the
roles of individual users by enabling dynamic policy evaluation for Host
Checker. Host Checker can trigger the IVE to evaluate resource policies
whenever a user’s Host Checker status changes. (If you do not select this
option, the IVE 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.) For more information, see “Dynamic
Policy Evaluation” on page 55.
3. Click Save Changes.
326

Specifying General Host Checker Options
Chapter 13: Host Checker
Specifying Host Checker Installation Options
If you implement any policy at the realm, role, or resource policy level that requires
Host Checker, you must provide a mechanism by which the IVE or the user can
install Host Checker on the client machine. Otherwise, when the IVE evaluates the
Host Checker policy, the user’s machine fails because the Host Checker client is not
available to return a success status.
You can use two methods to install Host Checker on a user’s system:

The IVE automatically installs Host Checker—Enable automatic installation
through the Users/Administrators > User Realms/Administrator Realms >
[Realm] > Authentication Policy > Host Checker page of the admin console.
(For configuration instructions, see “Configuring Host Checker Restrictions” on
page 314.) When you do, the IVE evaluates the realm-level option when the
user accesses the IVE sign-in page and then determines if the current version of
Host Checker is installed on the user’s machine. If Host Checker is not installed,
the IVE attempts to install it using either an ActiveX or a Java delivery method.
When a Windows user signs in to the IVE, the IVE attempts to install an ActiveX
control on the user’s system. If the IVE successfully installs the ActiveX control,
the control manages the installation of the Host Checker program.
If the IVE cannot install the ActiveX control because ActiveX is turned off on the
user’s system, the IVE attempts to install Host Checker using Java. For Linux
hosts, the IVE always uses the Java delivery method. The Java delivery method
requires only user privileges, but Java must be enabled on the user’s system.
For the Firefox browser on Linux, the Java runtime and plug-in must be
installed.
If y
NOTE: Due to some anomalies with Microsoft JVM, Host Checker may not install
and an error box appears. If this occurs, click Try Again. The subsequent
installation should succeed.
If the IVE cannot use the Java delivery method because Java is disabled on the
user’s system, the IVE displays a no-access error message.
NOTE: If Microsoft Vista is running on the user’s system, the user must click the
setup link that appears during the installation process to continue installing the
setup client and Host Checker. On all other Microsoft operating systems, the setup
client and Host Checker install automatically.
Specifying Host Checker Installation Options  327
Juniper Networks Secure Access Administration Guide

The user or administrator manually installs Host Checker (Windows only)—
Download the Host Checker installer from the Maintenance > System >
Installers page of the admin console and use it to manually install Host
Checker on the user’s system.
NOTE: To install Host Checker, users must have appropriate privileges, as
described in the Client-side Changes Guide on the Juniper Networks Customer
Support Center. If the user does not have these privileges, use the Juniper Installer
Service available from the Maintenance > System > Installers page of the
admin console to bypass this requirement.
Removing the Juniper ActiveX Control
If Microsoft Windows XP is running on the user’s system and you want to remove
the Juniper set-up ActiveX control:
1. Open Internet Explorer.
2. Click the Tools button and then click Internet Options.
3. Click Settings, then View Objects.
4. Select JuniperSetupSP1 and press Delete.
If Microsoft Vista is running on the user’s system and you want to remove the
Juniper set-up ActiveX control:
1. Open Internet Explorer.
2. Click the Tools button and then click Manage Add-ons.
3. In the Show list, click Downloaded ActiveX controls to display all ActiveX
controls.
4. Click JuniperSetupClient and then click Delete.
Using Host Checker with the GINA Automatic Sign-In Function
Using Host Checker in conjunction with the Windows Graphical Identification and
Authorization (GINA) sign-in function for Network Connect requires that you pay
particular attention to the type, level, and number of items to verify on the client
before granting or rejecting access to the IVE. Since the GINA sign-in function takes
place before Windows has completely launched on the client, and therefore, before
the user profile on Windows is created, we recommend you adopt the following
practices when creating Host Checker policies you plan to use for Windows clients
featuring the GINA sign-in function:

328

You can check system-level processes at both realm enforce and realm
evaluate. You can check user-level processes only at realm evaluate.
Specifying Host Checker Installation Options
Chapter 13: Host Checker

If you have user-level processes at realm evaluate, create a separate Network
Connect role featuring only system-level policy checks that can be performed
before Windows has completely launched on the client. Ensure that this role
allows connectivity to the Windows Domain infrastructure in your secure
network to support drive mapping, software updates, and group policies, for
example. Mapping your users to this role allows the GINA authentication to
complete. This role is in addition to the final role that you want the user to be
mapped.

Host Checker must be installed for the domain user that Network Connect
GINA uses for connection. Otherwise, this domain user can’t use GINA to login
if Host Checker is required
NOTE: Multiple sessions of Host Checker with GINA on the same computer is not
supported.
For more information on the GINA automatic sign-in function, see “Automatically
Signing into Network Connect using GINA” on page 643.
Automatically install Host Checker
To automatically install Host Checker on client computers:
1. In the admin console, choose Authentication > Endpoint Security > Host
Checker.
2. Under Options, select Auto-upgrade Host Checker if you want the IVE to
automatically download the Host Checker application to a client computer
when the version of Host Checker on the IVE is newer than the version
installed on the client. Here is a summary of what happens when the Autoupgrade Host Checker option is selected or not selected:

If Host Checker is not installed on the client computer, Host Checker is
installed automatically regardless of whether the Auto-upgrade Host
Checker option is selected or not selected.

If the Auto-upgrade Host Checker option is selected and a previous
version of Host Checker is installed, Host Checker is upgraded on the client
automatically.

If the Auto-upgrade Host Checker option is not selected and a previous
version of Host Checker is installed, Host Checker is not upgraded the
client automatically.
If you select the Auto-upgrade Host Checker option, note the following:

To install or upgrade Host Checker, users must have appropriate
privileges, as described in the Client-side Changes Guide on the Juniper
Networks Customer Support Center.

If a user uninstalls Host Checker and then signs in to an IVE for which
the Auto-upgrade Host Checker option is not enabled, the user no
longer has access to Host Checker.
Specifying Host Checker Installation Options  329
Juniper Networks Secure Access Administration Guide
3. Click Save Changes.
Manually install Host Checker
The Maintenance > System > Installers page of the admin console provides
several applications and a service for download. You can download an application
or service as a Windows executable file, which enables you to:

Distribute the file to client machines using software distribution tools. This
option enables you to install an application or service on client machines whose
users do not have Administrator privileges, which are required to install the
application or service.

Post the executable in a secure repository so that users with the proper
administrator right may download and install the appropriate version.

Download and execute a script that automatically retrieves the proper version
of the installer from an FTP server.
Using Host Checker Logs
Use the System > Log/Monitoring > Client Logs > Settings tab to enable clientside logging for the Host Checker. When you enable this option, the IVE writes a
client-side log to any client that uses Host Checker. The IVE appends to the log file
each time the feature is invoked during subsequent user sessions. This feature is
useful when working with the support team to debug problems with the respective
feature.
NOTE: Since these settings are global, the IVE writes a log file to all clients that use
the feature for which you enable client-side logging. Also, the IVE does not remove
client-side logs. Users need to manually delete log files from their clients. For
information about where the IVE installs log files, see the Client-side Changes Guide
on the Juniper Networks Customer Support Center.
To specify global client-side logging settings:
1. In the admin console, choose System > Log/Monitoring > Client Log >
Settings.
2. Select the desired features for which the IVE writes client-side logs.
3. Click Save Changes to save these settings globally.
NOTE: For new IVE 5.x systems, all options are disabled by default. If you upgrade
your IVE from a 3.x configuration, all log options are enabled by default.
330

Using Host Checker Logs
Chapter 13: Host Checker
Configuring Host Checker for Windows Mobile
You can configure Host Checker to enforce policies for handheld devices, such as
PDAs and smart phones, that run the Windows Mobile operating system.
NOTE: Currently only Windows Mobile versions 5 and 6 are supported.
Host Checker rules include checks for ports, processes, files, registry key settings,
operating system version, and certificates on the handheld device. You can also
load and use installed third-party IMCs to perform vendor-specific checks. Once the
policy is created, Host Checker deploys automatically when the user connects to
the IVE gateway.
Host Checker does not require any configuration on the handheld device itself.
When the server determines the device is out of compliance, Host Checker displays
a notification icon ( )in the system tray. Clicking this icon opens a browser page
that contains reasons for the compliance failure and remediation instructions.
Host Checker remains on the handheld device and does not need to be downloaded
each time the user connects to the gateway. When the gateway upgrades to a
newer version of Host Checker, the handheld device automatically updates the next
time the user connects to the gateway. To remove Host Checker from the handheld
device, use the Remove Programs applet in the Settings panel of the device.
Host Checker policies for Windows Mobile are configured through the
Authentication > Endpoint Security > Host Checker page of the admin console.
See “Specifying Customized Requirements Using Custom Rules” on page 290 for
instructions on configuring these policies.
Using Proxy Exceptions
IVE clients parse Internet Explorer’s static proxy exception list. We support most
exceptions that Internet Explorer supports with the following limitations:

For IP address exception, we support n.*.*.*, n.n.*.*, n.n.n.*. For example,
10.*.*.*, 10.10.*.*, 10.10.10.*, or 10.10.10.10. We do not support 10* or
10.*.10.* even though Internet Explorer may support them.

For string expression, we support specific strings such as my.company.net,or a
wild card at front of the string, for example, *.my.company.net or
*.company.net. We do not support *.company.*, *.company*, *.company.
*.com, *.net *.com and so forth.
Configuring Host Checker for Windows Mobile

331
Juniper Networks Secure Access Administration Guide
Enabling the Secure Virtual Workspace
The Secure Virtual Workspace guarantees the integrity of IVE session data on a
client machine running Windows 2000 or Windows XP by creating a protected
workspace on the client desktop. By enabling the Secure Virtual Workspace, you
ensure that any end-user signing in to your intranet must perform all interactions
within a completely protected environment. If the user’s applications and
interactions result in data being written to disk or to the registry, the Secure Virtual
Workspace encrypts that information. When the IVE session is complete, the Secure
Virtual Workspace destroys all information pertaining to itself or to the session, by
default. However, you can configure the state of this type of information to suit your
particular needs. For example, you might decide to allow data to persist across
Secure Virtual Workspace sessions.
The IVE follows the DoD 5220.M cleaning and sanitization standard for securely
deleting Secure Virtual Workspace data that is stored on the hard disk.
The Secure Virtual Workspace:

Removes workspace data and resources when the session ends.

Ensures that no browser Helper Objects latch onto an Internet Explorer process
before launching IE.

Prohibits desktop search products from intercepting Web traffic and indexing
the contents.

Enters all of its configuration and run-time operations in IVE logs.
The IVE hosts the Secure Virtual Workspace binary, which the client system
downloads from the IVE whenever a user connects. The Secure Virtual Workspace
creates a virtual file system and a virtual registry on the client.
You define and configure the applications that are allowed to run within the Secure
Virtual Workspace. For example, you can configure the following types of
application configurations:

Restrict launching of Internet Explorer and Outlook to the Secure Virtual
Workspace.

Restrict application installations and executions within a Secure Virtual
Workspace session. This ensures that even the application binaries are
completely removed from the client machine after the session ends.
NOTE: Secure Virtual Workspace does not work when IBM Sametime 7.5 is
running in the default desktop. IBM Sametime 7.5 automatically switches users to
the default desktop from the virtual workspace.
332

Enabling the Secure Virtual Workspace
Chapter 13: Host Checker
NOTE: For Windows Vista and later, certain processes, like regedit, require
elevated privileges. SVW does not currently allow the running of elevated privilege
processes.
Secure Virtual Workspace Features
The IVE implementation of the Secure Virtual Workspace:

Does not require the client desktop user to have administrator privileges to
download and run the Secure Virtual Workspace.

Supports the use of the Secure Virtual Workspace in conjunction with Host
Checker, which will automatically launch in the secure workspace, when
initiated.

Provides the Secure Virtual Workspace as a J.E.D.I. module, to allow you to
create Secure Virtual Workspace policies at the user role or realm level.
Secure Virtual Workspace Restrictions and Defaults
The Secure Virtual Workspace imposes certain restrictions on its use, and
establishes defaults, which you may be able to modify.

SVW does not support Cache Cleaner.

By default, a platform-specific browser is allowed to run in the SVW, unless
explicitly restricted by the administrator.

The IVE does not allow software applications that update the HKLM registry
entries on installation to operate within the SVW.

The IVE does not support the standard JSAM applications Outlook and Netbios
file browsing through SVW, since these applications require registry key
changes. However, the IVE does support the Citrix and Lotus Notes JSAM
standard applications through SVW.

By default, the IVE does not allow access to external storage or printing devices
by some applications running in the SVW. You can enable access to these
devices on a role or realm basis, if needed.

By default, end-users are unable to access network shares, unless you configure
access to network shares in the SVW policy.

If your end-users use firewalls or other applications that run in the kernel
space, they may experience problems when trying to download IVE client
components in SVW. Low-level administrative applications may display
message boxes requiring user interaction. If you set the option to allow
switching to the default or real desktop, the user may be able to dismiss the
message boxes. If the switching option is disabled, users may be unable to fix
the problem.

The Secure Virtual Workspace does not support 16-bit applications.
Enabling the Secure Virtual Workspace

333
Juniper Networks Secure Access Administration Guide

Some Windows keyboard shortcuts may not work properly inside an SVW
session.

To display the Windows Task Manager while in SVW, you cannot use the
standard keyboard shortcut Ctrl+Alt+Del. You must right-click on the
Windows taskbar (typically on the bottom of the screen, unless you have
moved it) to display a popup menu, from which you can select Task Manager.

If you set the Host Checker status update interval to a value of zero (0), Host
Checker will perform the status check once and then quit. If Host Checker
quits, SVW also quits. As a result, the end-user is unable to initiate an SVW
session. Set the Host Checker status update interval to a non-zero value.

SVW only scans for file system drives when the user first starts his session. If
the user starts a session and then adds a drive (such as a USB drive), he will not
be able to access the drive during that session.

The Logoff On Connect feature is not supported within SVW.
Configuring the Secure Virtual Workspace
You configure the Secure Virtual Workspace within the context of a Host Checker
policy and all Secure Virtual Workspace policies you define appear in a list at
Authentication > Endpoint Security > Secure Virtual Workspace.
NOTE: Because the Secure Virtual Workspace session data is stored on the enduser’s real desktop, you should implement the persistence feature only if each of
your end-users always uses the same client machine.
NOTE: No provision has been made to ensure that you cannot configure a sign-in
URL mapping to more than one realm configured with an SVW policy. If you
configure multiple mappings to more than one realm, the results are
unpredictable. You must explicitly configure the secure virtual desktop to allow
only one SVW policy to be evaluated at the user end.
Defining Secure Virtual Workspace Permissions
You can specify which devices and resources the end-user can access when using
the Secure Virtual Workspace.
To define a new Secure Virtual Workspace permissions policy:
1. In the admin console, choose Authentication > Endpoint Security > Secure
Virtual Workspace.
2. Click New Secure Virtual Workspace Policy.
3. Enter a name for the policy.
4. Under Permissions, check the appropriate checkboxes for the items to which
you want to grant permissions:
334

Enabling the Secure Virtual Workspace
Chapter 13: Host Checker

Printers—Select to allow end-user access to network printers.

Restricted View of Files—When Restricted View is set, only the directories
Documents and Settings, Program Files, and the Windows system folders
on the system drive (typically c:) are available within SVW.
NOTE: If you set the Restricted View of Files option, and your end-users configure
partitioned drives, they will be unable to access any applications or files residing
on any drive other than the system (c:) drive. If you allow your end-users to
partition drives, you should not use the Restricted View.

Removable Drives—Select to allow end-user access to removable drives
on the end-user’s client machine.
If an end-user installs a USB removable storage device he may experience
the two following behaviors, depending also on how you set this option:

If the user connects the USB device before initiating an SVW session,
the device will appear to be a fixed hard drive and the user will not be
able to read or write to the device during an SVW session, even when
you have set the Removable Drives option.

If the user connects the USB device after initiating an SVW session, the
device appears to be removable media and the user can access it, if
you have set the Removable Drives option when configuring SVW.

Network Share Access—Select to allow end-user access to network share
drives.

Switch to Real Desktop—Select to allow end-user to toggle between the
Secure Virtual Workspace and the end-user’s client desktop.

Desktop Persistence—Select to allow end-users to maintain a Secure
Virtual Workspace across client sessions on NTFS file systems only.
NOTE:

Desktop persistence and switching are not supported on FAT16 or FAT32 file
systems.

If you select this option, note that multiple users using the same password to
encrypt their SVW workspace on the same host could gain access to the
persistent data storage protected by that static password. We recommend that
your users employ strong password when securing their SVW persistent data
store on multi-user systems.

Virtual File Execution—Select to allow virtualized file applications to run
within a Secure Virtual Workspace environment. By default, downloading
an executable within Secure Virtual Workspace encrypts that executable
and prevents it from being run. Selecting this option allows executables to
be downloaded without encrypting them.
Enabling the Secure Virtual Workspace

335
Juniper Networks Secure Access Administration Guide
5. Continue to define the policy or click Save Changes.
Defining a Secure Virtual Workspace Application Policy
You can specify which applications the end-user can install or run when using the
Secure Virtual Workspace.
To define a new Secure Virtual Workspace application policy:
1. In the admin console, choose Authentication > Endpoint Security > Secure
Virtual Workspace.
2. Click New Secure Virtual Workspace Policy or click the hyperlinked name of
an existing Secure Virtual Workspace policy.
3. Enter a name for the policy.
4. Under Applications, select the checkboxes for the types of applications you
want to enable:
336


Control panel—Select to allow the end-user to access the Windows control
panel while in the Secure Virtual Workspace.

Run menu—Select to allow the end-user to access the Windows run menu
while in the Secure Virtual Workspace.

Registry editor—Select to allow the end-user to access the Windows
registry editor (regedt32.exe) while in the Secure Virtual Workspace.

Task manager—Select to allow the end-user to access the Windows Task
Manager (taskmgr.exe) and system processes while in the Secure Virtual
Workspace.

Command window—Select to allow the end-user to access the Windows
Command window (cmd.exe) and execute commands while in the Secure
Virtual Workspace.

Custom applications—You can identify custom applications that the enduser is allowed to run while in the Secure Virtual Workspace. For example,
you might include in-house applications, non-default browsers, and other
types of applications. Enter one application, including the .exe extension
per line in the multiline text box. You can also use the * wildcard for an
entire class of applications, and you can include an optional MD5 hash
value following the executable name and a comma, telnet.exe,0414ea8.

Applications to deny—You can identify applications you want to restrict
from end-user use while in the Secure Virtual Workspace. Enter one
application, including the extension for each executable per line in the
multiline text box.
Enabling the Secure Virtual Workspace
Chapter 13: Host Checker
NOTE:

Any custom application that is not listed in the Custom applications field is
denied by default.

If you add the same application to the Custom applications text box and to
the Applications to deny text box, the deny action takes precedence and
users will be denied access to the application SVW sessions. Be aware that this
can happen if you use wildcards to specify applications in both lists. For
example, if you specify *plore.exe in the allow list and iex*.exe in the deny list,
then iexplore.exe will be denied.
5. Continue to define the policy or click Save Changes.
After you define one or more Virtual Workspace policies, you must enable them as
Realm authentication policies at the user level, as described in “Implementing Host
Checker Policies” on page 311.
Defining a Secure Virtual Workspace Security Policy
You can specify encryption levels and can control the use of 3rd-party extensions in
Internet Explorer and Outlook.
To specify security options for a new Secure Virtual Workspace policy:
1. In the admin console, choose Authentication > Endpoint Security > Secure
Virtual Workspace.
2. Click New Secure Virtual Workspace Policy or click the hyperlinked name of
an existing Secure Virtual Workspace policy.
3. Enter a name for the policy.
4. Specify the type of AES encryption key the IVE uses to enable the Secure
Virtual Workspace on the client. The available options are 128, 192, and 256bit encryption keys.
5. Identify the IE or Outlook extensions you want to allow by including each
allowable DLL on a separate line in the IE/Outlook extensions to allow text
box. Any extension that is not listed is denied, by default.
These extensions are small applications that are passed into and out of the
Secure Virtual Workspace session.
6. Continue to define the policy or click Save Changes.
Defining Secure Virtual Workspace Environment Options
To specify environment options for a new Secure Virtual Workspace policy:
1. In the admin console, choose Authentication > Endpoint Security > Secure
Virtual Workspace.
Enabling the Secure Virtual Workspace

337
Juniper Networks Secure Access Administration Guide
2. Click New Secure Virtual Workspace Policy or click the hyperlinked name of
an existing Secure Virtual Workspace policy.
3. Enter a name for the policy.
4. Under Options, specify:

The maximum length of time (in minutes) a client’s Secure Virtual
Workspace session can remain idle before the connection to the IVE times
out.

The desktop wallpaper image (Optional).

The desktop background color (Optional).

The sign-in URL to use to access the SVW.
The available URLs include the default User sign-in URL and any URLs you
have defined in Authentication > Signing in > Sign-in Policies. The first
time SVW puts the user into the virtual workspace and initiates a browser,
it takes the user to the IVE using a sign-in URL. By default, this sign-in URL
is the same one that the user has entered to start their IVE session. You can
configure a different sign-in URL through this option.
NOTE: The IVE does not support host names that contain a wildcard, such as
*.host.com/[path].

The string to display in the toolbar title. By default, “SVW Title” is
displayed.

To allow users to hide the toolbar, select the Autohide Toolbar option.
When users choose to hide the toolbar (by clicking the thumbtack icon in
the toolbar), they must scroll to the top of their desktop in order to make
the toolbar reappear.
5. Continue to define the policy or click Save Changes.
Defining Secure Virtual Workspace Remediation Policy
To specify remediation options for a new Secure Virtual Workspace policy:
1. In the admin console, choose Authentication > Endpoint Security > Secure
Virtual Workspace.
2. Click New Secure Virtual Workspace Policy or click the hyperlinked name of
an existing Secure Virtual Workspace policy.
3. Enter a name for the policy.
4. Under Remediation, select remediation options for users whose computers do
not meet the requirements specified in the policy. For instructions, see
“Configuring General Host Checker Remediation” on page 318.
338

Enabling the Secure Virtual Workspace
Chapter 13: Host Checker
NOTE: If you do not create remediation instructions and the policy fails, your users
will not know why they cannot launch the Secure Virtual Workspace or access
local resources.

Enable Custom Instructions—Select to expand text box in which you can
enter custom instructions, using either text or HTML, that will be presented
to end-users when the Secure Virtual Workspace encounters a remediation
problem.

Enable Custom Actions—You can select one or more alternate policies
that you want Host Checker to evaluate if the user’s computer does not
meet the current policy requirements. The alternate policy must be either a
third-party policy that uses a J.E.D.I. package or another Secure Virtual
Workspace policy. For example, you can use a J.E.D.I. package to launch
an application if the user’s computer does not meet the current policy
requirements. Select the alternate policy in the HC Policies list and then
click Add.

Kill Processes—Select to open text box in which you enter application
processes and MD5 hash values for the processes you want killed. For
example:
Application.exe
MD5: 6A7DFAF12C3183B56C44E89B12DBEF56
MD5: 9S3AJ912CC3183B56C44E89B12DI2AC9

Delete Files—Select to open text box in which you can enter file names,
one per line, of files you want deleted.

Send reason strings—Select to send remediation information. For more
information about this option, see “Configuring General Host Checker
Remediation” on page 318.
5. Click Save Changes.
Enabling the Secure Virtual Workspace

339
Juniper Networks Secure Access Administration Guide
340

Enabling the Secure Virtual Workspace
Chapter 14
Cache Cleaner
Cache Cleaner is a Windows client-side agent that removes residual data, such as
temporary files or application caches, left on a user’s machine after an IVE session.
For example, when a user signs in to the IVE from an Internet kiosk and opens a
Microsoft Word document using a browser plug-in, Cache Cleaner can remove the
temporary copy of the Word file stored in the browser cache (Windows folder) when
the session terminates. By removing the copy, Cache Cleaner prevents other kiosk
users from finding and opening the Word document after the IVE user concludes
the session.
Cache Cleaner can also prevent Web browsers from permanently storing the
usernames, passwords, and Web addresses that users enter in Web forms. By
preventing browsers from improperly caching this information, Cache Cleaner
keeps confidential user information from being stored on untrusted systems.
NOTE: Cache cleaner does not currently support Secure Virtual Workspace (SVW).
This topic contains the following information about Cache Cleaner:

“Licensing: Cache Cleaner Availability” on page 341

“Setting Global Cache Cleaner Options” on page 342

“Implementing Cache Cleaner Options” on page 345

“Specifying Cache Cleaner Installation Options” on page 349

“Using Cache Cleaner Logs” on page 350
Licensing: Cache Cleaner Availability
Cache Cleaner is a standard feature on all Secure Access appliances—you do not
need a special license to use it.
Licensing: Cache Cleaner Availability

341
Juniper Networks Secure Access Administration Guide
Setting Global Cache Cleaner Options
When you enable Cache Cleaner, it clears all content downloaded through the IVE’s
Content Intermediation Engine from a user’s system. In addition, you can use
settings in the Authentication > Endpoint Security > Cache Cleaner page of the
admin console to clear content from the following places:

Specified hosts and domains—If you enable WSAM or JSAM, you may want to
configure Cache Cleaner to clear additional hosts and domains. When users
browse the Internet outside the IVE using WSAM or JSAM, Internet files appear
in their temporary Internet file folder. To delete these files using Cache Cleaner,
you must specify the appropriate hostname (for example, www.yahoo.com).

Specified files and folders—If you enable your users to access client-server
applications on their local systems, you may want to configure Cache Cleaner
to clear the temporary files and folders that the applications create on the users’
systems.
NOTE: If you configure Cache Cleaner to remove files from a directory, Cache
Cleaner clears all files, including those that the user has explicitly saved to the
directory and files that were in the directory prior to the IVE session.
To specify global Cache Cleaner options:
1. Select Authentication > Endpoint Security > Cache Cleaner in the admin
console.
2. Under Options:
342

a.
Specify how often Cache Cleaner runs in the Cleaner Frequency field. Valid
values range from 1 to 60 minutes. Each time Cache Cleaner runs, it clears
all content downloaded through the IVE’s Content Intermediation Engine
plus the browser cache, files, and folders you specify under the Browser
Cache and Files and Folders sections.
b.
Specify how often the IVE expects in the Status Update Frequency field.
Valid values range from 1 to 60 minutes.
c.
Specify an interval to control timing out for the Client-side process, login
inactivity timeout box in the following situations (valid values range from 5
to 60 minutes):
Setting Global Cache Cleaner Options

If the user navigates away from the IVE sign-in page after Cache
Cleaner starts running but before signing in to the IVE, Cache Cleaner
continues to run on the user’s machine for the interval you specify.

If the user is downloading Cache Cleaner over a slow connection,
increase the interval to allow enough time for the download to
complete.
Chapter 14: Cache Cleaner
d. Select the Disable AutoComplete of web addresses check box to prevent
the browser from using cached values to automatically fill in Web
addresses during the user’s IVE session. When you select this option, the
IVE sets the following Windows registry value to 0 during the user’s IVE
session:
HKEY_CURRENT_USER\Software\\Microsoft\\Windows\\CurrentVersion\\Ex
plorer\ AutoComplete.
Then, at the end of the session, the IVE restores the registry value to its
original setting.
e.
f.
Select the Disable AutoComplete of usernames and passwords check box
to prevent Internet Explorer from automatically filling in user credentials in
Web forms using cached values. Selecting this option also disables the
“Save Password?” prompt on Windows systems. When you select this
option, the IVE sets the following Windows registry values to 0:

HKEY_CURRENT_USER\Software\Microsoft\Internet
Explorer\Main\FormSuggest Passwords

HKEY_CURRENT_USER\Software\Microsoft\Internet
Explorer\Main\FormSuggest Passwords\FormSuggest PW Ask

HKEY_CURRENT_USER\SOFTWARE\Microsoft\
Windows\CurrentVersion\Internet Settings\ DisablePasswordCaching
Select the Flush all existing AutoComplete Passwords check box to clear
any cached passwords that Internet Explorer has cached on the user’s
system. When you select this option, the IVE sets the following Windows
registry value to 0:
HKEY_CURRENT_USER \Software\\Microsoft\\Internet Explorer\\
IntelliForms\\SPW
Then, select one of the following options:
g.

Select the For IVE session only option button to specify that the IVE
should restore the user’s cached passwords at the end of his IVE
session.

Select the Permanently option button to permanently delete the user’s
cached passwords.
Select the Empty Recycle Bin and Recent Documents list check box to
empty the recycle bin and clear the recent documents list. The entire
contents are removed, not just the files related to the user’s sessions.
h. Select the Uninstall Cache Cleaner at logout check box if you want the
IVE to uninstall Cache Cleaner from the client machine when a user’s
session ends.
Setting Global Cache Cleaner Options

343
Juniper Networks Secure Access Administration Guide
3. Under Browser Cache, enter one or more hostnames or domains (wildcards are
permitted). When a user session ends, Cache Cleaner removes any content in
the browser cache that originates from these servers. Cache Cleaner also
removes this content when it runs at the specified cleaner frequency interval.
Note that the IVE does not resolve hostnames, so enter all possible
representations of a server, such as its hostname, FQDN, and IP address.
4. Under Files and Folders:
a.
b.
Specify either:

The name of a file that you want Cache Cleaner to remove.

The complete directory path to a folder whose contents you want
Cache Cleaner to remove. If you specify a directory, select Clear
Subfolders to also clear the contents of any subdirectories within this
directory.
Select the Clear folders only at the end of session check box if you want
Cache Cleaner to clear directory contents only at the end of the user
session. Otherwise, Cache Cleaner also clears files and folders at the
specified cleaner frequency interval.
NOTE: When specifying files and folders to clear, note the following:

Cache Cleaner uses a cookie called DSPREAUTH to send the client’s status to
the IVE. If you delete this cookie from the user’s client, Cache Cleaner does
not work properly. To avoid problems, do not specify Internet Explorer
directories such as <userhome>\Local Settings\Temporary Internet Files\*
under File or folder path. Note that Cache Cleaner still clears all of the Internet
Explorer cache downloaded from the IVE host and the other hosts specified in
the Hostnames box, regardless of what directories you specify under Files and
Folders.

For the Firefox browser, Cache Cleaner clears only those directories you
specify under Files and Folders.
5. Click Save Changes to save these settings globally.
If more than one valid IVE session exists from the same system and Cache Cleaner
is used in those sessions, all sessions are terminated when a user signs out from
one of the sessions. To prevent this, turn off Cache Cleaner for those sessions that
do not need Cache Cleaner.
NOTE: If multiple administrators or end users to a single IVE are signed in from the
same client system and at least one of them deploys Cache Cleaner, unexpected
results may occur. For example, Cache Cleaner might shut down, role privileges
might be lost, and forced disconnections might occur.
344

Setting Global Cache Cleaner Options
Chapter 14: Cache Cleaner
Implementing Cache Cleaner Options
After you specify which hosts, domains, files, and folders to clear using settings in
the Authentication > Endpoint Security > Cache Cleaner page of the admin
console, you can restrict IVE and resource access by requiring Cache Cleaner in the
following options:

Realm authentication policy—When users try to sign in to the IVE, the IVE
evaluates the specified realm’s authentication policy to determine if the preauthentication requirements include Cache Cleaner. You can configure a realm
authentication policy to download Cache Cleaner, download and start running
Cache Cleaner, or not require Cache Cleaner. The user must sign in using a
computer that adheres to the Cache Cleaner requirements specified for the
realm. If the user’s computer does not meet the requirements, then the user is
denied access to the IVE. You can configure realm-level restrictions through the
Users > User Realms > Realm > Authentication Policy > Cache Cleaner page
of the admin console.

Role—When the IVE determines the list of eligible roles to which it can map an
administrator or user, it evaluates each role’s restrictions to determine if the
role requires Cache Cleaner to run on the user's workstation. If it does and the
user's machine is not already running Cache Cleaner, then the IVE does not
map the user to that role. You can control which roles the IVE maps a user to
by using settings in Users > User Realms > Select_Realm > Role Mapping.
Select or create a rule and then select Custom Expressions. You can configure
role-level restrictions through the Users > User Roles > Role > General >
Restrictions > Cache Cleaner page of the admin console.

Resource policy—When a user requests a resource, the IVE evaluates the
resource policy’s detailed rules to determine whether or not Cache Cleaner
needs to be installed or running on the user's workstation. The IVE denies
access to the resource if the user's machine does not meet the Cache Cleaner
requirement. You can implement Cache Cleaner restrictions at the resource
policy level through the Condition Field box of the Rules window. Select Users
> Resource Policies > Select_Resource > Select_Policy > Detailed Rules.
You may specify that the IVE evaluate your Cache Cleaner policies only when the
user first tries to access the realm, role, or resource that references the Cache
Cleaner policy. Or, you can use settings in the Authentication > Endpoint Security
> Cache Cleaner tab to specify that the IVE periodically re-evaluate the policies
throughout the user’s session. If you choose to periodically evaluate Cache Cleaner
policies, the IVE dynamically maps users to roles and allows users access to new
resources based on the most recent evaluation.
Executing Cache Cleaner
When the user tries to access the IVE, the IVE determine’s the client system’s
Cache Cleaner status and prompts it to start running using the following process:
1. Initial evaluation—When a user first tries to access the IVE sign-in page, the
IVE determines whether Cache Cleaner is running on the user’s machine. The
IVE performs this initial evaluation regardless of whether you have
implemented Cache Cleaner policies at the realm, role, or resource policy level.
Implementing Cache Cleaner Options

345
Juniper Networks Secure Access Administration Guide
If the user navigates away from the IVE sign-in page after Cache Cleaner starts
running but before signing in to the IVE, Cache Cleaner continues to run on the
user’s machine until the Cache Cleaner process times out.
If the IVE does not receive a Cache Cleaner status result for any reason
(including because the user failed to enter his credentials in the sign-in page),
the IVE displays an error and directs the user back to the sign-in page.
Otherwise, if the IVE Cache Cleaner process returns a status, the IVE goes on to
execute the realm-level policies.
2. Realm-level policies—The IVE uses the results from the initial evaluation to
determine which realms the user may access. Then, the IVE displays or hides
realms from the user, only allowing him to sign into those realms that you
enable for the sign-in page, and if he meets the Cache Cleaner requirements for
each realm. If the user cannot meet the Cache Cleaner conditions required by
any of the available realms, the IVE does not display the sign-in page. Instead,
it displays an error stating that the computer does not comply with the
endpoint policy.
Note that the IVE only performs realm-level Cache Cleaner checks when the
user first signs into the IVE. If the state of the user’s system changes during his
session, the IVE does not remove him from the current realm or allow him
access to a new realm based on his new system state.
3. Role-level policies—After the user signs into a realm, the IVE evaluates rolelevel policies and maps the user to the role or roles if he meets the Cache
Cleaner requirements for those role(s). Then, the IVE displays the IVE home
page to the user and enables those options that the mapped role(s) allow.
If Cache Cleaner returns a different status during a periodic evaluation, the IVE
dynamically remaps the user to roles based on the new results. If the end user
loses rights to all available roles during one of the periodic evaluations, the IVE
disconnects the user’s session.
4. Resource-level policies—Once the IVE allows the user to access the home
page, the user may try to access a resource that is controlled by a resource
policy. When he does, the IVE determines whether or not to perform the action
specified in the resource policy based on the last status returned by Cache
Cleaner.
If Cache Cleaner returns a different status during a periodic evaluation, the new
status only impacts new resources that the user tries to access. For example, if
a user successfully initiates a Network Connect session, and then fails his next
resource-level Cache Cleaner status check, he may continue to access the open
Network Connect session. The IVE only denies him access if he tries to open a
new Network Connect session. The IVE checks the last status returned by
Cache Cleaner whenever the user tries to access a new Web resource or open a
new Secure Application Manager, Network Connect, or Secure Terminal Access
session.
346

Implementing Cache Cleaner Options
Chapter 14: Cache Cleaner
5. Final clean-up—Cache Cleaner performs a final cleanup and restores registry
settings when:

The user explicitly signs out of the user session—When a user clicks Sign
Out on the IVE home page, Cache Cleaner performs a final cleanup and
then uninstalls itself from the user’s system.

The user session times out—When a user session times out, Cache
Cleaner performs a cleanup, and then if the user signs in again, Cache
Cleaner performs another cleanup. Cache Cleaner is aware of session
timeouts, because it periodically checks the validity of a session at the
interval you specify on the Authentication > Endpoint Security > Cache
Cleaner tab.
NOTE: When checking the validity of a user session, Cache Cleaner connects to the
IVE. This action may trigger warnings on personal firewalls. Users must permit
this traffic to ensure that Cache Cleaner functions correctly. Also note that users
with personal firewalls see a log entry every time Cache Cleaner clears the cache.

A client system restarts after an abnormal termination—If Cache
Cleaner terminates abnormally because of a system, session, or network
connection problem, Cache Cleaner performs a final cleanup and uninstalls
itself from the user’s system after the system restarts. Note that Cache
Cleaner cannot log data after it terminates. Also, all changes made to the
user’s registry settings after termination and before signing back in to the
IVE are lost.
With either a running or not running status, Cache Cleaner remains on the client.
Users may manually uninstall the agent by running uninstall.exe in the directory
where Cache Cleaner is installed. If you enable client-side logging through the
System > Log/Monitoring > Client Logs > Settings page, this directory also
contains a log file, which is rewritten each time Cache Cleaner runs. (Cache Cleaner
does not log entries to the standard IVE log, but can log data to the temporary
client-side text file. This encrypted log is deleted when Cache Cleaner uninstalls
itself.)
Specifying Cache Cleaner Restrictions
To specify Cache Cleaner restrictions:
1. Select Authentication > Endpoint Security > Cache Cleaner and specify
global options for Cache Cleaner to apply to any user for whom Cache Cleaner
is required in an authentication policy, a role mapping rule, or a resource
policy.
2. To implement Cache Cleaner at the realm level:
a.
Select Users > User Realms > Select Realm > Authentication Policy >
Cache Cleaner.
Implementing Cache Cleaner Options

347
Juniper Networks Secure Access Administration Guide
b.
Choose one of the following options:

Disable Cache Cleaner — Does not require Cache Cleaner to be
installed or running in order for the user to meet the access
requirement.

Just load Cache Cleaner — Does not require Cache Cleaner to be
running in order for the user to meet the access requirement but
ensures that it is available for future use. If you choose this option for a
realm’s authentication policy, then the IVE downloads Cache Cleaner
to the client machine after the user is authenticated and before the
user is mapped to any roles on the system.

Load and enforce Cache — Requires the IVE to download and run
Cache Cleaner in order for the user to meet the access requirement. If
you choose this option for a realm’s authentication policy, then the IVE
downloads Cache Cleaner to the client machine before the user may
access the IVE sign-in page.
3. To implement Cache Cleaner at the role level:
a.
b.
Select either:

Administrators > Admin Roles > Select_Role > General >
Restrictions > Cache Cleaner

Users > User Roles > Select_Role > General > Restrictions >
Cache Cleaner
Select the Enable Cache Cleaner check box. This option require Cache
Cleaner to be running in order for the user to meet the access requirement.
4. To create role-mapping rules based on a user’s Cache Cleaner status:
a.
Select Users > User Realms > Select_Realm > Role Mapping > Select or
Create Rule > Custom_Expression.
b.
Write a custom expression for the role mapping rule to evaluate Cache
Cleaner’s status using the cacheCleaner variable.
5. To implement Cache Cleaner at the resource policy level:
348

a.
Select Users > Resource Policies > Select Resource > Select Policy >
Detailed Rules > Select or Create Rule > Condition_Field
b.
Create a custom expression in a detailed rule.
Implementing Cache Cleaner Options
Chapter 14: Cache Cleaner
Specifying Cache Cleaner Installation Options
If you implement any policy at the realm, role, or resource policy level that requires
Cache Cleaner, you must provide a mechanism by which the IVE or the user can
install Cache Cleaner on the client machine. Otherwise, when the IVE evaluates the
Cache Cleaner policy, the user’s machine fails because the Cache Cleaner client is
not available.
Enable automatic installation through the Users > User Realms > Realm >
Authentication Policy > Cache Cleaner page of the admin console to allow the IVE
to attempt to install Cache Cleaner on the user’s system. When you do, the IVE
evaluates the realm-level option when the user accesses the IVE sign-in page and
then determines if the current version of Cache Cleaner is installed on the user’s
machine. If Cache Cleaner is not installed, the IVE attempts to install it using either
an ActiveX or a Java delivery method.
When a user signs in to the IVE, the IVE attempts to install an ActiveX control on
the user’s system. If the IVE successfully installs the ActiveX control, the control
manages the installation of the Cache Cleaner program.
If the IVE cannot install the ActiveX control because of the user’s lack of
administrator or power user privileges, or because ActiveX is turned off on the
user’s system, the IVE attempts to install Cache Cleaner using Java. The Java
delivery method requires only user privileges, but Java must be enabled on the
user’s system.
NOTE: If Microsoft Vista is running on the user’s system, the user must click the
setup link that appears during the installation process to continue installing the
setup client and Cache Cleaner. On all other Microsoft operating systems, the
setup client and Cache Cleaner install automatically.
If the IVE cannot use the Java delivery method because Java is disabled on the
user’s system, the IVE displays an error message informing the user that the user’s
system does not allow installation of ActiveX or Java applications, therefore some
of the access security functions are not able to run.
NOTE:

To install Cache Cleaner, users must have appropriate privileges, as described
in the Secure Access Client-Side Changes Guide on the Juniper Networks
Customer Support Center. If the user does not have these privileges, use the
Juniper Installer Service available from the Maintenance > System >
Installers page of the admin console to bypass this requirement.

Users must enable signed ActiveX components or signed Java applets within
their browsers in order for Host Checker to download, install, and launch the
client applications.
For information on removing the Juniper Networks ActiveX control, see “Removing
the Juniper ActiveX Control” on page 328.
Specifying Cache Cleaner Installation Options

349
Juniper Networks Secure Access Administration Guide
Using Cache Cleaner Logs
Select System > Log/Monitoring > Client Logs > Settings tab to enable clientside logging for the Cache Cleaner. When you enable this option, the IVE writes a
client-side log to any client that uses Cache Cleaner. The IVE appends to the log file
each time the feature is invoked during subsequent user sessions. This feature is
useful when working with the support team to debug problems with the respective
feature.
NOTE: Because these settings are global, the IVE writes a log file to all clients that
use the feature for which you enable client-side logging. Also, the IVE does not
remove client-side logs. Users need to manually delete log files from their clients.
For information about where the IVE installs log files, see the Secure Access ClientSide Changes Guide on the Juniper Networks Customer Support Center.
To specify global client-side logging settings:
1. Select System > Log/Monitoring > Client Logs > Settings in the admin
console.
2. Select the desired features for which the IVE writes client-side logs.
3. Click Save Changes to save these settings globally.
NOTE: For new IVE release 5.x systems, all options are disabled by default. If you
upgrade your IVE from a Release 3.x configuration, all log options are enabled by
default.
350

Using Cache Cleaner Logs
Part 4
Remote Access
This section contains the following information about configuring access to a
various applications, servers, and other resources using remote access mechanisms:

“Web Rewriting” on page 389

“File Rewriting” on page 465

“Secure Application Manager” on page 489

“Telnet/SSH” on page 543

“Terminal Services” on page 555

“Secure Meeting” on page 605

“Email Client” on page 629

“Network Connect” on page 637
This section also contains the following information about easily configuring access
to selected applications using resource profile templates available through the Web
rewriting feature:

“Hosted Java Applets Templates” on page 353

“Citrix Templates” on page 369

“Lotus iNotes Templates” on page 379

“Microsoft OWA Templates” on page 383

“Microsoft Sharepoint Templates” on page 387
Choosing a Remote Access Mechanism
The IVE 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 (as explained in “Can I Use the IVE to Secure Traffic to All of My
Company’s Applications, Servers, and Web Pages?” on page 27.
Choosing a Remote Access Mechanism

351
Juniper Networks Secure Access Administration Guide
For instance, if you want to secure access to Microsoft Outlook, you can use the
Secure Application Manager (SAM). The Secure Application Manager intermediates
traffic to client/server applications including Microsoft Outlook, Lotus Notes, and
Citrix. Or, if you want to secure access to your company Intranet, you can use the
Web rewriting feature. This feature uses the IVE’s Content Intermediation Engine to
intermediate traffic to Web-based applications and Web pages.
Table 19 briefly compares three of the IVE’s access mechanisms: Network Connect,
Windows Secure Application Manager (WSAM), and Java Secure Application
Manager (JSAM).
Table 19: Comparison of Remote Client Access Methods
352

Network Connect
WSAM
JSAM
Secure network-layer access.
Performs as virtual IPsec
enabled tunnel. Compatible
with client-side firewalls and
proxies.
Secure application-layer
access. Supports Win32
Transport Data Interface (TDI)
service installation.
Compatible with client-side
firewalls and proxies.
Secure application-layer
access. Java applet-based TCP
port forwarding for
provisioned enterprise hosts.
Compatible with client-side
firewalls and proxies.
Installation handled via
Active X control for Windows
and Java applet for Mac.
Installation handled via
Active X control, Java delivery,
and standalone installers.
Requires only a single Java
applet installed on the client
Provisioning requires a static
IP address pool allocated for
network resources or a DHCP
server present on the network.
Provisioning requires a list of
IP addresses, Windows
applications, and destination
hosts to be secured. Access
control dependent upon IP
addresses.
Provisioning requires a list of
hosts and ports at the group
level. Allows users option to
define client-server
applications and security
settings. Host names preferred
over IP addresses.
Supports Windows, Mac, and
Linux clients.
Supports Windows clients.
Supports Windows, Mac, and
Linux clients.
Choosing a Remote Access Mechanism
Chapter 15
Hosted Java Applets Templates
The IVE Java applet upload feature enables you to store the Java applets of your
choice directly on the IVE without employing a separate Web server to host them.
When you use this feature, you simply upload the applets to the IVE (along with
additional files that the applets reference) and create a simple Web page through
the IVE that references the files. Then, the IVE intermediates the Web page and Java
applet content using its Content Intermediation Engine.
This topic contains the following information about hosting Java applets on the IVE:

“Licensing: Hosted Java Applets Availability” on page 353

“Task Summary: Hosting Java Applets” on page 353

“Hosted Java Applets Overview” on page 354

“Defining Resource Profiles: Hosted Java Applets” on page 358

“Use case: Creating a Citrix JICA 9.5 Java Applet Bookmark” on page 364
NOTE: The IVE enables you to host Java applets using Web resource profile
templates (described in these topics) as well as through Terminal Services resource
profiles. For instructions on how to host Java applets through Terminal Services
resource profiles, see “Defining a Hosted Java Applet Autopolicy” on page 564.
Licensing: Hosted Java Applets Availability
The hosted Java applets feature is a standard feature on all Secure Access
appliances except the SA 700. If you are using an SA-700 appliance, you must
install a Core Clientless Access upgrade license to access the hosted Java applets
feature.
Task Summary: Hosting Java Applets
The IVE Java applet upload feature enables you to store the Java applets of your
choice directly on the IVE without employing a separate Web server to host them.
Licensing: Hosted Java Applets Availability

353
Juniper Networks Secure Access Administration Guide
To host Java applets on the IVE:
1. Specify which applets you want to upload, create IVE bookmarks that reference
the uploaded applets, and specify which roles can access the bookmarks using
settings in the Users > Resource Profiles > Web page of the admin console.
For instructions, see “Defining Resource Profiles: Hosted Java Applets” on
page 358.
2. (Optional.) To sign your Java applets, Select System > Configuration >
Certificates > Code-Signing Certificates in the admin console to upload the
Java certificate to the IVE. If you choose to skip this step, the user sees an
untrusted certificate warning each time he accesses the corresponding
bookmark. For instructions, see “Using Code-signing Certificates” on page 755.
3. (Optional.) To improve the performance of your Java applications:
a.
Select Enable Java instrumentation caching on the Maintenance >
System > Options page of the admin console. This option can improve the
performance of downloading Java applications. For more information, see
“Setting System Options” on page 704.
b.
After you finish configuring the IVE, cache your Java applet and access it as
an end user. This action eliminates the performance hit that occurs through
the intermediation engine when the first end user accesses the applet.
Hosted Java Applets Overview
The IVE Java applet upload feature enables you to store the Java applets of your
choice directly on the IVE without employing a separate Web server to host them.
When you use this feature, you simply upload the applets to the IVE (along with
additional files that the applets reference) and create a simple Web page through
the IVE that references the files. Then the IVE intermediates the Web page and Java
applet content using its Content Intermediation Engine.
354

Hosted Java Applets Overview
Chapter 15: Hosted Java Applets Templates
For example, you might want to use the IVE to intermediate traffic between an IBM
AS/400 system on your network and individual 5250 terminal emulators on your
users’ computers. To configure the IVE to intermediate this traffic, obtain the 5250
terminal emulator’s Java applet. Then you can upload this applet to the IVE and
create a simple Web page that references the applet. After you create the Web page
through the IVE, the IVE creates a corresponding bookmark that users can access
through their home pages.
NOTE:

You must have a good understanding of Java applets, Java applet parameters,
and HTML to use this feature.

For information about intermediating Java applets that are hosted on an
external server, see “Defining Resource Policies: External Java Applets” on
page 442.

Configuration options for the hosted Java applet feature have moved to the
Users > Resource Profiles > Web page in the admin console. If you are
upgrading the product from a version earlier than Release 5.3, the IVE
automatically creates resource profiles from your old resource policies. If your
old bookmark referenced multiple Java applets, the IVE creates a single
container archive for the applets and associates the archive with your new
resource profile.
The following topics contain information about uploading, enabling, and accessing
Java applets through the IVE:

“Uploading Java Applets To The IVE” on page 355

“Signing Uploaded Java Applets” on page 356

“Creating HTML Pages That Reference Uploaded Java Applets” on page 356

“Accessing Java Applet Bookmarks” on page 357
Uploading Java Applets To The IVE
You can use Java applets to intermediate traffic to various types of applications
through the IVE. For example, you can upload the 3270 applet, 5250 applet, or
Citrix Java applet to the IVE. These applets enable users to establish sessions to IBM
mainframes, AS/400s, and Citrix MetaFrame servers through terminal emulators.
(Note that to enable the Citrix Java ICA client through an IVE session, you must
upload multiple Citrix .jar and .cab files to the IVE. See “Use case: Creating a Citrix
JICA 9.5 Java Applet Bookmark” on page 364. Or, configure a Citrix Terminal
Services resource profile to host the Java applets, as explained in “Defining a Hosted
Java Applet Autopolicy” on page 564.)
The IVE enables you to upload individual .jar and .cab files or .zip, .cab, or .tar
archive files. Archive files can contain Java applets and files referenced by the
applets. Within the .zip, .cab, or .tar file, the Java applet must reside at the top level
of the archive. You can upload any number of files to the IVE as long as their
combined size does not exceed 100 MB.
Hosted Java Applets Overview

355
Juniper Networks Secure Access Administration Guide
To ensure compatibility with both Sun and Microsoft Java Virtual Machines (JVMs),
you must upload both .jar and .cab files to the IVE. (The Sun JVM uses .jar files,
whereas the Microsoft JVM uses .cab files.)
NOTE:

When you upload Java applets to the IVE, the IVE asks you to read a legal
agreement before it finishes installing the applets. Read this agreement
carefully—it obligates you to take full responsibility for the legality, operation,
and support of the Java applets that you upload.

You can only upload 100 MB of Java applets to the IVE. The IVE displays the
size of each applet that you upload to the IVE on the Java Applets page so you
can determine, if necessary, which applets you want to delete.

Uploading Java applets requires signed ActiveX or signed Java applets to be
enabled within the browser to download, install, and launch the client
applications.
You can upload Java applets to the IVE using resource profiles. For instructions, see
“Defining Resource Profiles: Hosted Java Applets” on page 358.
Signing Uploaded Java Applets
Unlike other Java applets that users can access through the IVE, you do not have to
create a separate code-signing policy for the Java applets that you upload to the IVE.
The IVE automatically signs (or re-signs) them using the appropriate code-signing
certificate. A code-signing certificate (also called an applet certificate) is a type of
server-side certificate that re-signs Java applets intermediated by the IVE, as
explained in “Using Code-signing Certificates” on page 755.
The IVE automatically signs (or resigns) your hosted Java applets with the codesigning certificate that you install through the System > Configuration >
Certificates > Code-signing Certificates page of the admin console. If you do not
install a code-signing certificate on the IVE, the IVE uses its self-signed applet
certificate to sign or re-sign the applets. In this case, users see an “untrusted
certificate issuer” warning whenever they access the Java applets through the IVE.
NOTE: The IVE re-instruments and re-signs your uploaded Java applets whenever
you change (that is, import, renew, or delete) the corresponding code-signing
certificate on the IVE.
Creating HTML Pages That Reference Uploaded Java Applets
When uploading a Java applet to the IVE, you must create a simple Web page that
references the applet. Users can access this Web page through a bookmark on their
IVE home pages or from external Web servers (as explained in “Accessing Java
Applet Bookmarks” on page 357).
356

Hosted Java Applets Overview
Chapter 15: Hosted Java Applets Templates
The Web page must contain a simple HTML page definition that references the
uploaded Java applet. The Web page can also contain any additional HTML and
JavaScript that you choose. The IVE can generate some of the Web page for you,
including the HTML page definition and the references to your Java applet. (Note,
however, that the IVE is not aware of all the applet-specific parameters that are
required by your applet—you must find and fill these parameters in yourself.) When
the IVE generates this HTML, it creates placeholders for any undefined values and
prompts you to fill in the necessary values.
You can create these Web pages through Java applet upload resource profiles. For
instructions, see “Defining Hosted Java Applet Bookmarks” on page 359.
Accessing Java Applet Bookmarks
Users can access the applets you upload to the IVE using two methods:

Bookmarks on the IVE end user console—When you create a Web page that
references your uploaded Java applets, the IVE creates a corresponding link to
the Web page and displays that link in the Bookmarks section of the IVE end
user console. Users who map to the appropriate role can simply click the link to
access the Java applet.

Links on external Web servers—Users can link to the Java applet bookmarks
from an external Web server by simply using the correct URLs. When the user
enters a bookmark’s URL (or clicks an external link that contains the URL), the
IVE prompts the user to enter his IVE username and password. If he properly
authenticates, the IVE allows him to access the bookmark. You can construct
the URL to the Java applet bookmark using the syntax described in either of the
following lines:
https://IVE_hostname/dana/home/launchwebapplet.cgi?bmname=bookmark
Name
https://IVE_hostname/dana/home/launchwebapplet.cgi?id=<resourceID>&bmna
me=bookmarkName
(You can determine the ID for a Java applet bookmark by accessing it through
the IVE home page and then extracting the ID from the Web browser’s address
bar.)
NOTE:

Although the IVE enables you to create multiple bookmarks with the same
name, we strongly recommend that you use a unique name for each. If
multiple bookmarks have the same name and a user accesses one of these
bookmarks using a URL that includes the bmname parameter, the IVE
randomly picks which of the identically named bookmarks to display to the
user. Also note that the bmname parameter is case-sensitive.

If you create links on external servers to Java applet bookmarks on the IVE
and you are using multiple customized sign-in URLs, some restrictions occur.
See the note in “Sign-In Policies” on page 223.
Hosted Java Applets Overview

357
Juniper Networks Secure Access Administration Guide
For information about creating bookmarks, see “Defining Hosted Java Applet
Bookmarks” on page 359.
Defining Resource Profiles: Hosted Java Applets
To create a hosted Java applet resource profile:
1. Select Users > Resource Profiles > Web in the admin console.
2. Click New Profile.
3. Select Hosted Java Applet from the Type list.
4. Enter a unique name and optionally a description for the resource profile.
5. Select the Java applet that you want to associate with the resource profile from
the Applet to use list. Or, if the applet that you want to use is not currently
available in the list, click Edit Applet. Then:
a.
Click New Applet to add an applet to this list. Or, select an existing applet
and click Replace (to replace an existing applet with a new applet) or
Delete (to remove an applet from the IVE).
NOTE:

If you replace an existing archive, make sure that the new applet archive
contains all of the necessary files for the applet to successfully launch and run.
If the associated HTML for the applet refers to files that do not exist in the new
archive, then the applet will not function correctly.

The IVE only allows you to delete applets that are not currently in use by a
Web or Terminal Services resource profile.
b.
Enter a name to identify the applet in the Name box (for new and replaced
applets only).
c.
Browse to the applet that you want to upload to the IVE. You can upload
applets (.jar or .cab files) or archives (.zip, .jar, and .tar files) that contain
applets and all of the resources that the applets need (for new and replaced
applets only).
d. Select the Uncompress jar/cab file check box if the file that you selected is
an archive that contains the applet (New and replaced applets only).
358

Defining Resource Profiles: Hosted Java Applets
Chapter 15: Hosted Java Applets Templates
e.
Click OK and then click Close Window.
NOTE: When you select an applet in the Java Applets dialog box, you are loading
third-party software onto the Juniper product. By clicking OK, you are agreeing to
the following terms on behalf of yourself (as purchaser of the equipment) or the
organization that purchased the Juniper product, as applicable.
By loading third party software onto the Juniper Networks product, you are
responsible for obtaining all rights necessary for using, copying, and/or distributing such software in or with the Juniper Networks product. Juniper is not responsible for any liability arising from use of such third party software and will not
provide support for such software. The use of third party software may interfere
with the proper operation of the Juniper Networks product and/or Juniper Networks software, and may void any warranty for the Juniper Networks product
and/or Juniper Networks software.
6. Use settings in the Autopolicy: Java Access Control section to enable access if
your Java applets need to make socket connections. For more detailed
instructions, see “Defining a Java Access Control Autopolicy” on page 407.
7. Click Save and Continue.
8. Select the roles to which the resource profile applies In the Roles tab and click
Add.
The selected roles inherit the autopolicies and bookmarks created by the
resource profile. If it is not already enabled, the IVE also automatically enables
the Web option in the Users > User Roles > Select_Role > General >
Overview page of the admin console and the Allow Java Applets option Users >
User Roles > Select_Role > Web > Options page of the admin console for all
of the roles you select.
9. Click Save Changes.
10. Create bookmarks in the Bookmarks tab using instructions in “Defining Hosted
Java Applet Bookmarks” on page 359.
Defining Hosted Java Applet Bookmarks
You must create bookmarks to your hosted Java applets to enable end users to
access the applets. For more information about resource profile bookmarks, see
“Defining Bookmarks” on page 110.
To configure hosted Java applet resource profile bookmarks:
1. Select Users > Resource Profiles > Web > Select Resource Profile >
Bookmarks in the admin console.
Defining Resource Profiles: Hosted Java Applets

359
Juniper Networks Secure Access Administration Guide
2. Click the appropriate link in the Bookmark column if you want to modify an
existing bookmark. Or, click New Bookmark to create an additional bookmark.
NOTE: Although it is generally easiest to create a resource profile session bookmark through the resource profile configuration page, you can choose to create
one through the user roles page as well if you have already created a resource profile. For instructions, see “Creating Hosted Java Applets Bookmarks Through the
User Roles Page” on page 361.
3. Enter a name and optionally a description for the bookmark. This information
displays on the IVE home page. (By default, the IVE names the bookmark the
same name as the corresponding resource profile.)
NOTE: We strongly recommend that you use a unique name for each bookmark to
make it clear to users which link they are accessing. See “Creating HTML Pages
That Reference Uploaded Java Applets” on page 356.
4. Click Generate HTML to create an HTML page definition that includes
references to your Java applets. Then, fill in any required attributes and
parameters using guidelines in the following topics:

“Required Attributes for Uploaded Java Applets” on page 362

“Required Parameters for Uploaded Java Applets” on page 363
If you are using HTML generated by the IVE, make sure to search the HTML
code for “__PLEASE_SPECIFY__” and update the code as necessary.
You can also add more HTML or JavaScript to this Web page definition. The IVE
rewrites all of the code that you enter in this field.
NOTE: Make sure to enter unique HTML in this field. If you create two bookmarks
with the same HTML code, the IVE deletes one of the bookmarks in the end-user
view. You will still be able to see both bookmarks, however, in the administrator
console.
360

Defining Resource Profiles: Hosted Java Applets
Chapter 15: Hosted Java Applets Templates
5. List those attributes in the Multi-Valued User Attributes box if your HTML code
contains attributes that may expand to multiple values (such as
userAttr.hostname or userAttr.ports), . When the user signs into the IVE, the IVE
evaluates these attributes and creates separate bookmarks as necessary based
on each of the individual values. If you use an attribute that expands to multiple
values, but do not enter that attribute in this box, the IVE creates a single
bookmark based on the attribute’s first value.
6. Under Display options, click Bookmark opens new window to enable the IVE
to automatically open the Web resource in a new browser window. Note that
this functionality applies only to role bookmarks and not bookmarks created by
users. Next, select the following options if you want to hide UI elements from
the user:

Do not display the browser address bar—Select this option to remove the
address bar from the browser window. This feature forces all Web traffic
through the IVE by precluding users in the specified role from typing a new
URL in the address bar, which circumvents the IVE.

Do not display the browser toolbar—Select this option to remove the
menu and toolbar from the browser. This feature removes all menus,
browsing buttons, and bookmarks from the browser window so that the
user browses only through the IVE.
7. Under Roles, specify the roles to which you want to display the bookmark if you
are configuring the bookmark through the resource profile pages:

ALL selected roles—Select this option to display the bookmark to all of the
roles associated with the resource profile.

Subset of selected roles—Select this option to display the bookmark to a
subset of the roles associated with the resource profile. Then select roles
from the ALL Selected Roles list and click Add to move them to the Subset
of selected roles list.
8. Click Save Changes.
Creating Hosted Java Applets Bookmarks Through the User Roles Page
It is generally easiest to create a hosted Java applets bookmark through the resource
profile configuration pages, as explained in previous topic. However, you can
choose to create a resource profile session bookmark through the user roles page
using the following instructions:
1. Select Users > Roles > Select_Role > Web > Bookmarks in the admin
console.
2. Click New Bookmark.
3. Select Pick a Web Resource Profile from the Type list, . (The IVE does not
display this option if you have not already created a hosted Java applet resource
profile.)
4. Select an existing resource profile.
Defining Resource Profiles: Hosted Java Applets

361
Juniper Networks Secure Access Administration Guide
5. Click OK. (If you have not already associated the selected role with the resource
profile, the IVE automatically makes the association for you. The IVE also
enables any access control policies for the role that are required by the resource
profile.)
6. If this role is not already associated with the selected resource profile, the IVE
displays an informational message. If you see this message, click Save Changes
to add this role to the resource profile’s list of roles and to update the profile’s
autopolicies as required. Then, repeat the previous steps to create the
bookmark.
7. Use instructions in “Defining Hosted Java Applet Bookmarks” on page 359 to
configure the bookmark’s settings.
NOTE: When you create a resource profile bookmark through the user roles page
(instead of the standard resource profiles page), the IVE only associates the
generated bookmark with the selected role. The IVE does not assign the bookmark
to all of the roles associated with the selected resource profile.
Required Attributes for Uploaded Java Applets
When you create a Java applets bookmark through the IVE, you must define the
following attributes and their corresponding values. If you use the Generate HTML
feature, the IVE populates some of this information for you and adds
PLEASE_SPECIFY to those attributes whose values you must specify. When
specifying attributes and their corresponding values, use the attribute=”value”
format.
NOTE: The IVE generates parameters that it knows are required. Note, however,
that the IVE is not aware of all the applet-specific parameters that are required by
your applet—you must find and fill in these parameters yourself.
Attributes that are required by the IVE include:

code—Indicates which class file to invoke in your Java applet. Use this value to
point to your Java applet’s main function. Example:
applet code="com.citrix.JICA"

codebase—Indicates where the Web browser can fetch the applet. Use the
<<CODEBASE>> variable, which points to the location on the IVE where the IVE
stores the Java applet. When entering a path to a file, note that <<CODEBASE>>
includes a trailing slash, which means the following example works:
<img src="<<CODEBASE>>path/to/file">
Whereas this example does not work:
<img src="<<CODEBASE>>/path/to/file">

archive—Indicates which archive file (that is, .jar, .cab, or .zip file) the Web
browser should fetch. Example:
362

Defining Resource Profiles: Hosted Java Applets
Chapter 15: Hosted Java Applets Templates
archive="JICAEngN.jar"
In addition to the required attributes listed earlier, you may also use the following
optional attributes when creating a Java applet bookmark:

name—Specifies a label for the Java applet. Example:
name="CitrixJICA"

host—Specifies, for terminal sessions, the server to which the IVE should
connect.

port—Specifies, for terminal sessions, the port to which the IVE should connect.

width and height—Indicates the size of the Java applet window. Example:
width="640" height="480"

align—Indicates the Java applet window’s alignment within the browser
window. Example:
align="top"
NOTE: When defining attributes and their corresponding values, note the
following:

We strongly recommend that you not include useslibrarycabbase parameter in
the HTML, because it causes the cab file to be permanently installed on the
user’s machine. If you later change a cab file on the IVE, all users will have to
manually delete the cab files on their machines to get the new version from
the IVE.

We do not support applet tags that are constructed through the document.write
function because the dynamic HTML interferes with the IVE's parser.

We do not support relative links to URLs, documents, or images in your HTML.
If you do, the links will break when the user tries to access them from the IVE
end user console. Instead, you should include absolute links. If you are linking
to a document or image included in your zip file, use the <<CODEBASE>>
variable to indicate that the IVE can find the file in zip archive uploaded to the
IVE. For example:
<img src="<<CODEBASE>>yourcompany_logo.gif" alt="YourCompany">
Required Parameters for Uploaded Java Applets
When you create a Java applets bookmark through the IVE, you must specify
parameters and values that the IVE should pass to the Java applet. These
parameters are completely applet-specific. When specifying parameters and their
corresponding values, use the following format:
<param name=”parameterName” value=”valueName”>
Defining Resource Profiles: Hosted Java Applets

363
Juniper Networks Secure Access Administration Guide
Where all of the text is literal except parameterName and valueName.
You can use IVE variables to pass values to the Java applet by enclosing the variable
names in double-brackets. For example, you might choose to pass the
<<username>> and <<password>> values to the Java applet. For a list of available
IVE variables, see “System Variables and Examples” on page 1018.
NOTE: When using the Java applet upload feature, if you include the <password>
token within the generated HTML, it appears as cleartext if you view the source in
the browser window that launches the applet. This behavior cannot be changed
because the IVE does not control how the Java applet processes the password. We
strongly discourage the use of the <<password>> token in the HTML code.
If you find a Web page that contains an applet that you want to use, go to the
demonstration site and view the source on the page that runs the Java applet.
Within the source, look at the applet tag. Pick out the code attribute in the source
and determine if it contains any special parameters that you need to pass to the
browser. In most cases, you should be able to copy and paste the code attribute and
its corresponding parameters directly into the HTML field for your IVE bookmark.
Note, however, that if a parameter references a resource on the local Web server,
you cannot copy and paste the reference into the IVE bookmark because the IVE
does not have access to the other Web server’s local resources. When copying and
pasting parameters from another source, always check the values of the
parameters.
Use case: Creating a Citrix JICA 9.5 Java Applet Bookmark
This topic discusses how to enable access to a Citrix Metaframe server through the
IVE using the 9.5 Java version of the Citrix ICA client (JICA).
NOTE:

In addition to the method described here, you can also use Terminal Services
resource profiles to host the Java versions of Citrix ICA clients on the IVE. For
instructions, see “Defining a Hosted Java Applet Autopolicy” on page 564.

The IVE supports several mechanisms for intermediating traffic between a
Citrix server and client, including the Terminal Services, JSAM, WSAM,
Network Connect, and hosted Java applets features. To determine which
mechanism works best for your environment, see “Comparing IVE Access
Mechanisms for Configuring Citrix” on page 370.
To enable the Citrix JICA 9.5 client using the Java applet upload feature:
1. Import code-signing certificates as explained in “Using Code-signing
Certificates” on page 755.
2. Download JICAcomponents.zip from the citrix.com downloads page.
364

Use case: Creating a Citrix JICA 9.5 Java Applet Bookmark
Chapter 15: Hosted Java Applets Templates
3. Create a hosted Java applet resource profile through the Users > Resource
Profiles > Web page of the admin console. When defining the resource profile:
a.
Upload the archived Citrix container file to the IVE.
b.
When uploading the applet, select the Uncompress jar/cab file check box
because the container file contains multiple jar and cab files.
c.
Specify any Metaframe servers to which these applets may connect.
d. Assign the resource profile to the appropriate roles.
(For detailed instructions, see “Defining Resource Profiles: Hosted Java Applets”
on page 358.)
4. Generate the Web page for the bookmark in the resource profile’s Bookmarks
tab. The IVE automatically inserts all of the .jar files into the corresponding Web
page. (JICA 95 supports only Sun JVM, so no cab files are present.) Then, specify
parameters for the Citrix client using the following examples as a guide. (Note
that the bookmark in “JICA 9.5 Applet Example” on page 365 can contain
references to the jar and cab files that are in the zip file.)
JICA 9.5 Applet Example
<html>
<head>
<title>jica95 Applet</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<!-Notes:
1) << CODEBASE >> is a system value that will get replaced at the time the applet is
launched. Please do not modify this value.
2) Please modify the remaining values as needed.
3) Please make sure all attribute names/values are enclosed in double quotes.
-->
<body>
<applet code="com.citrix.JICA"
codebase="<< CODEBASE >>"
archive="JICA-browseN.jar,JICA-cdmN.jar,JICA-clipboardN.jar,JICAconfigN.jar,JICA-coreN.jar,JICA-printerN.jar,JICA-seamlessN.jar,JICA-sicaN.jar,JICAzlcN.jar,JICAEngN.jar,cryptojN.jar,sslN.jar,JICA-audioN.jar"
width="640" height="480"
name="jica95" align="top">
<param name="code" value="com.citrix.JICA">
<param name="codebase" value="<< CODEBASE >>">
<param name="archive" value="JICA-browseN.jar,JICA-cdmN.jar,JICAclipboardN.jar,JICA-configN.jar,JICA-coreN.jar,JICA-printerN.jar,JICA-seamlessN.jar,JICAsicaN.jar,JICA-zlcN.jar,JICAEngN.jar,cryptojN.jar,sslN.jar,JICA-audioN.jar">
<param name="cabbase" value="">
<param name="name" value="jica95">
<param name="width" value="640">
<param name="height" value="480">
<param name="align" value="top">
<!-Please specify additional params here after the comment.
Use case: Creating a Citrix JICA 9.5 Java Applet Bookmark

365
Juniper Networks Secure Access Administration Guide
<param name="paramname" value="paramvalue">
-->
<param name="Address" value="__PLEASE_SPECIFY__">
<param name="Username" value="<< user >>">
<param name="password" value="<< password >>">
<param name="EncryptionLevel" value="1">
<param name="BrowserProtocol" value="HTTPonTCP">
</applet>
</body>
</html>
JICA 8.x Applet Example
The following sample includes generated HTML code for the 8.x JICA client, which
supported both Sun and MS JVMs:
<html>
<head>
<title>CitrixJICA Applet.</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<!-Notes:
1) << CODEBASE >> is a system value that will get
replaced at the time the applet is launched.
Please do not modify this value.
2) Please modify the remaining values as needed.
3) Please make sure all attribute names/values are
enclosed in double quotes.
-->
<body>
<applet code="com.citrix.JICA"
codebase="<< CODEBASE >>"
archive="JICAEngN.jar,JICA-sicaN.jar,cryptojN.jar,JICA-configN.jar,JICAcoreN.jar"
width="640" height="480"
name="CitrixJICA" align="top">
<param name="code" value="com.citrix.JICA">
<param name="codebase" value="<< CODEBASE >>">
<param name="archive" value="JICAEngN.jar,JICA-sicaN.jar,cryptojN.jar,JICAconfigN.jar,JICA-coreN.jar">
<param name="cabbase" value="cryptojM.cab,JICAconfigM.cab,JICAEngM.cab,JICA-sicaM.cab,JICA-coreM.cab">
<param name="name" value="CitrixJICA">
<param name="width" value="640">
<param name="height" value="480">
<param name="align" value="top">
<!-Please specify additional params here after the comment.
<param name="paramname" value="paramvalue">
-->
<param name="Address" value="__PLEASE_SPECIFY__">
<param name="Username" value="<< user >>">
<param name="password" value="<< password >>">
<param name="EncryptionLevel" value="1">
<param name="BrowserProtocol" value="HTTPonTCP">
366

Use case: Creating a Citrix JICA 9.5 Java Applet Bookmark
Chapter 15: Hosted Java Applets Templates
</applet>
</body>
</html>
Use case: Creating a Citrix JICA 9.5 Java Applet Bookmark

367
Juniper Networks Secure Access Administration Guide
368

Use case: Creating a Citrix JICA 9.5 Java Applet Bookmark
Chapter 16: Citrix Templates
Chapter 16
Citrix Templates
The IVE supports several mechanisms for intermediating traffic between a Citrix
server and client, including the Juniper Networks Citrix Terminal Services proxy,
JSAM, WSAM, Network Connect, and the hosted Java applets feature.
The Citrix Web template enables you to easily configure access to a Citrix server
using the Juniper Networks Citrix Terminal Services proxy, JSAM, or WSAM. The
Citrix Web template is a resource profile that controls access to Citrix applications
and configures Citrix settings as necessary. Citrix Web templates significantly
reduce your configuration time by consolidating configuration settings into one
place and by prepopulating a variety of resource policy settings for you depending
on the type of Citrix setup you select.
You should use the Citrix Web template if you have the Citrix Web Interface already
installed in your environment or if you are using a Web server to host your ICA files.
See “Resource Profiles” on page 103.
This topic contains the following information about Citrix templates:

“Citrix Web Template Overview” on page 369

“Comparing IVE Access Mechanisms for Configuring Citrix” on page 370

“Creating Resource Profiles Using Citrix Web Applications” on page 372
Citrix Web Template Overview
Because of their highly simplified configurations, templates are the ideal Citrix
configuration method if you want to deliver ActiveX or Java applets from a thirdparty Web server through the IVE.
Citrix Web templates simplify your configuration by automatically detecting
whether the Citrix Web client or the Citrix Java applet is being used and employing
the appropriate IVE access mechanism accordingly. For instance, if you have
configured the Citrix Web Interface to deliver a Java client, the IVE automatically
uses its Java rewriting engine to tunnel traffic. If you have configured the Citrix Web
Interface to deliver an ActiveX client, the IVE uses its Citrix Terminal Services
feature, JSAM, or WSAM (depending on the option you select) to tunnel traffic.
We strongly recommend using Citrix templates instead of the traditional role and
resource policy configuration options available through the IVE.
NOTE: We do not support saving a Citrix application shortcut to the desktop
through the IVE when the loopback IP address is running on the client. Doubleclicking this shortcut returns an error as it does not use WSAM or JSAM.
Citrix Web Template Overview

369
Juniper Networks Secure Access Administration Guide
Comparing IVE Access Mechanisms for Configuring Citrix
The IVE supports several mechanisms for intermediating traffic between a Citrix
server and client, including the Citrix Terminal Services proxy, JSAM, WSAM,
Network Connect, and the hosted Java applets feature.
The following tables describe the differences when using the Citrix Terminal
Services proxy, JSAM, and WSAM to access Citrix:

Table 20 describes key differences when accessing a Citrix Metaframe Server
thought a Citrix Web Interface server. The descriptions in this table focus on
configuring Citrix Terminal Services, JSAM, and WSAM through Web resource
profile templates (Select Users > Resource Profiles > Web, click New Profile
and select Citrix Web interface/JICA from the Type list.)

Table 21 describes key differences when accessing a Citrix Metaframe Server
without using a Citrix Web Interface server. The descriptions in this table focus
on configuring Citrix Terminal Services, JSAM, and WSAM through standard
resource profiles (Select Users > Resource Profiles > SAM or Terminal
Services.)
NOTE: If you want to configure access to a Citrix Metaframe server though a Citrix
Web Interface server, you must use Web resource profile templates. If you want to
configure access to a Citrix Metaframe server without using a Citrix Web Interface
server, you must use a standard Citrix Terminal Services or WSAM resource profile
or role.
370

Comparing IVE Access Mechanisms for Configuring Citrix
Chapter 16: Citrix Templates
Table 20: Accessing the Citrix Web Interface Server using Web Resource Profile Templates
Requirement
Terminal Services
JSAM
WSAM
User experience
1. The user clicks a Citrix Web
Interface bookmark in the
Web Bookmarks section of
the IVE end user console.
1. The user launches JSAM.
1. The user launches WSAM.
2. The user clicks a Citrix Web 2. The user clicks a Citrix Web
Interface bookmark in the
Interface bookmark in the
Web Bookmarks section of
Web Bookmarks section of
2. The user is taken to the Citrix
the IVE end user console.
the IVE end user console.
Web Interface (WI) sign-in
3. The user is taken to the Citrix 3. The user is taken to the Citrix
page (assuming you do not
Web Interface (WI) sign-in
Web Interface (WI) sign-in
configure FORM POST SSO).
page (assuming you do not
page (assuming you do not
3. Once the user signs into the
configure FORM POST SSO).
configure FORM POST SSO).
WI portal (either manually or 4. Once the user signs into the 4. Once the user signs into the
automatically through SSO),
WI portal (either manually or
WI portal (either manually or
he is taken to the Citrix WI
automatically through SSO),
automatically through SSO),
portal page, which contains
he is taken to the Citrix WI
he is taken to the Citrix WI
the list of published
portal page, which contains
portal page, which contains
applications in icon form.
the list of published
the list of published
4. When the user clicks the
published application, the
Juniper Networks Citrix
Terminal Services (CTS)
proxy launches and the ICA
traffic is tunneled through
the Juniper Networks CTS
proxy.
applications in icon form.
applications in icon form.
5. When the user clicks the
published application, the
ICA traffic is tunneled
through JSAM.
5. When the user clicks the
published application, the
ICA traffic is tunneled
through WSAM.
Not supported on Mac and
Accessing published
applications from Mac or Linux.
Linux
Supported on Mac and Linux.
Not supported on Mac and
Linux.
Configuring ports
The IVE automatically monitors
all traffic on port 1494 if
session reliability is turned off
on the server. The IVE monitors
port 2598 if session reliability is
turned on. You do not need to
specify which ports to monitor
or which applications to
intermediate.
You must specify which ports
the IVE monitors. This enables
you to access published
applications that use ports
other than 1494.
You do not need to specify
which ports to monitor or
which applications to
intermediate. WSAM works in
app mode and monitors all
traffic coming from certain
Citrix executables.
Administrator privileges
If a Citrix Web client is not
installed on the user’s desktop,
administrator privileges are
required.
If a Citrix Web client is not
installed on the user’s desktop,
administrator privileges are
required.
Requires administrator
privileges to install WSAM.
This is a limitation of the
installation of the Citrix client.
To install and run the Juniper
Networks Citrix Terminal
Services proxy client,
administrator privileges are not
required.
This is a limitation of the
installation of the Citrix client.
To run JSAM, administrator
privileges are not required.
Modifying host file
Does not require modification
of the etc/hosts file.
Does not require modification
of the etc/hosts file.
Does not require modification
of the etc/hosts file.
More information
“Creating Resource Profiles
Using Citrix Web Applications”
on page 372
“JSAM Overview” on page 512
“WSAM Overview” on page 491
Comparing IVE Access Mechanisms for Configuring Citrix

371
Juniper Networks Secure Access Administration Guide
Table 21: Accessing Non-Citrix Web Interface Servers Using Standard IVE Access Mechanisms
Requirement
Terminal Services
JSAM
WSAM
User experience
The user launches the
1. JSAM auto-launches when
1. WSAM auto-launches when
published application by
the user signs into the IVE or
the user signs into the IVE or
clicking the bookmark or icon
the user launches JSAM
the user launches WSAM
in the Terminal Services section
manually.
manually.
of the IVE end user console.
2. The user launches the
2. The user launches the
published application using
published application using
standard methods such as
standard methods such as
the Windows Start menu or a
the Windows Start menu or a
desktop icon.
desktop icon.
Macintosh and Linux users
Accessing published
applications from Mac or cannot access published
applications from a Citrix
Linux
Metaframe server.
Macintosh and Linux users can Macintosh and Linux users
access published applications
cannot access published
from a Citrix Metaframe server. applications from a Citrix
Metaframe server.
Admin configuration
You can specify which ports the
IVE intermediates. Or, if you do
not configure this information,
the IVE automatically monitors
ports 1494 and 2598.
You cannot configure Citrix as a
standard application. Instead,
you need to create a custom
JSAM application, provide the
server names of all Metaframe
servers, and specify which
ports the IVE monitors. This
enables you to use applications
such as Citrix Secure Gateways
(CSGs) and published
applications that use ports
other than 1494.
Administrator privileges
If a Citrix Web client is not
installed on the user’s desktop,
administrator privileges are
required.
Requires administrator
Requires administrator
privileges to run JSAM because privileges to install WSAM.
etc/hosts file modifications are
required.
You must specify which ports
and applications the IVE
monitors. This enables you to
use applications such as Citrix
Secure Gateways (CSGs) and
published applications that use
ports other than 1494.
This is a limitation of the
installation of the Citrix client.
To install and run the Juniper
Networks Citrix Terminal
Services proxy client,
administrator privileges are not
required.
Modifying host file
Does not require modification
of the etc/hosts file.
Requires modification of the
etc/hosts file.
Does not require modification
of the etc/hosts file.
More information
“Terminal Services” on
page 555
“JSAM Overview” on page 512
“WSAM Overview” on page 491
Creating Resource Profiles Using Citrix Web Applications
The Citrix Web template enables you to easily configure Citrix access using the
Juniper Networks Citrix Terminal Services proxy, JSAM, or WSAM.
To create a resource profile using the Citrix template:
372

Creating Resource Profiles Using Citrix Web Applications
Chapter 16: Citrix Templates
1. Select Users > Resource Profiles > Web in the admin console.
2. Click New Profile.
3. Select Citrix Web Interface/JICA from the Type list.
4. Enter a unique name and optionally a description for the Citrix resource profile.
5. Enter the URL of the Web server that hosts your ICA files in the Web Interface
(NFuse) URL field. Use the format: [protocol://]host[:port][/path]. For instance,
enter the URL of an NFuse server, the Web interface for a Citrix Metaframe
Presentation Server, or a Web server from which the IVE can download Citrix
Java applets or Citrix cab files. (The IVE uses the specified URL to define the
default bookmark for the Citrix resource profile.) You may enter a directory URL
or a file URL. For detailed guidelines on how to format Web resources, see
“Defining Base URLs” on page 398.
6. Specify which type of Citrix implementation you are using in your environment
by selecting one of the following options:

Java ICA Client with Web Interface (NFuse)—Select this option if you have
deployed the Citrix Web Interface for MPS (that is, NFuse) to deliver Java
ICA clients.

Java ICA Client without Web Interface (NFuse)—Select this option if you
have deployed a generic Web server to deliver Java ICA clients.

Non-Java ICA Client with Web Interface (NFuse)—Select this option if you
have deployed the Citrix Web Interface for MPS (that is, NFuse) to use any
of the different clients (Java, ActiveX, local).

Non-Java ICA Client without Web Interface (NFuse)—(Read only) If you
have deployed a non-Java ICA client without the Citrix Web Interface for
MPS (that is, NFuse), you cannot create a Citrix resource profile through
this template. Instead, click the client application profile link beneath this
option. The link brings you to the Client Application Profiles page, where
you can create a SAM resource profile. For instructions, see “Specifying
Applications and Servers for WSAM to Secure” on page 498.
7. From the Web Interface (NFuse) version list, select which Citrix version you
are using. (The IVE uses this value to pre-populate the Forms POST SSO values
in your single sign-on autopolicy. For more information, see “Specifying
Remote SSO Autopolicy Options” on page 403.)
8. Specify the Metaframe Servers to which you want to control access in the
MetaFrame servers area. Then click Add. When specifying servers, you can
enter wildcards or IP ranges.
The IVE uses the values that you enter to automatically create a corresponding
resource policy that enables access to the necessary resources:

If you select either Java ICA Client with or without Web Interface, the IVE
creates a corresponding Java ACL resource policy that enables Java applets
to connect to the specified Metaframe servers.
Creating Resource Profiles Using Citrix Web Applications

373
Juniper Networks Secure Access Administration Guide

If you select Non-Java ICA Client with Web Interface, and then you select
ICA client connects over WSAM or JSAM (below), the IVE creates a
corresponding SAM resource policy that enables users to access the
specified Metaframe servers.

If you select Non-Java ICA Client with Web Interface, and then you select
ICA client connects over CTS, the IVE creates corresponding Terminal
Services and Java resource policies that enable users to access the specified
Metaframe servers.
9. (Java ICA clients only.) If you deployed Citrix using a Java ICA Client, select the
Sign applets with uploaded code-signing certificate(s) check box to re-sign
the specified resources using the certificate uploaded through the System >
Configuration > Certificates > Code-signing Certificates page of the admin
console. (For instructions, see “Using Code-signing Certificates” on page 755.)
When you select this option, the IVE uses all of the “allow” values that you enter
in the resource profile’s Web access control autopolicy to automatically create a
corresponding code-signing resource policy. Within this policy, the IVE uses the
specified Web resources to create a list of trusted servers.
10. (Non-Java ICA clients only) If you have deployed Citrix using a non-Java ICA
Client with a Web interface, you must use the Juniper Networks Citrix Terminal
Services proxy, Secure Application Manager, or Network Connect to secure
traffic to your Metaframe servers instead of the Content Intermediation Engine.
To secure traffic through Network Connect, see instructions in “Network
Connect” on page 637.
To secure traffic through the Juniper Citrix Terminal Services proxy or the
Secure Application Manager, select one of the following options in the ICA
Client Access section:

ICA client connects over CTS Client—Select this option to secure your
Citrix traffic through the IVE Citrix Terminal Services client (if your users
are using Active X clients) or Java rewriting engine (if your users are using
Java clients). (When you select this option, the IVE automatically enables
the Terminal Services option on the Users > User Roles > Select_Role >
General > Overview page of the admin console.)
NOTE: If you are using a third-party Web server such as your company’s Intranet
server to deliver the ICA file, make sure the Content-Type of the HTTP Response
header is application/x-ica. Only then does the IVE automatically intermediate the
ICA file and launch its Citrix Terminal Services client to tunnel the traffic.
NOTE: If you select this option, we recommend that you disable Citrix client
downloads through the Citrix Web Interface. Otherwise, users could inadvertently
start two different windows downloading two versions of the Citrix client
simultaneously–one through the IVE (which automatically attempts to download
the Citrix client if one is not present on the user’s computer) and one through the
Citrix Web Interface.
374

Creating Resource Profiles Using Citrix Web Applications
Chapter 16: Citrix Templates

ICA client connects over WSAM—Select this option to secure traffic using
WSAM. (When you select this option, the IVE automatically enables the
Secure Application Manager option on the Users > User Roles >
Select_Role > General > Overview page of the admin console.)

ICA client connects over JSAM—Select this option to secure traffic using
JSAM. Then, configure the following options:
i.
Number of Servers/Applications—Enter the lesser of the following two
numbers: maximum number of Citrix servers in your environment or
the maximum number of published applications that a user can open
simultaneously. For instance, if your environment contains one server
and five published applications, enter 1 in this field. Or, if your
environment contains 20 servers and 10 published applications, enter
10 in this field. The maximum value this field accepts is 99.
ii.
Citrix Ports—Specify the ports on which the Metaframe servers listen.
(When you select the ICA client connects over JSAM option, the IVE
automatically enables the Secure Application Manager option on the Users
> User Roles > Select_Role > General > Overview page of the admin
console.)
NOTE: You cannot enable WSAM and JSAM for the same role. Therefore, if you try
to create a Citrix resource profile that uses one of these access mechanisms (for
instance, JSAM) and another profile associated with role already uses the other
access mechanism (for instance, WSAM), the IVE does not enable the new access
mechanism (JSAM) for the role. Also note that you can only use WSAM or JSAM to
configure access to one Citrix application per user role.
11. (Non-Java ICA Client with Web Interface only.) If you want to allow users to
access local resources such as printers and drives through their Citrix Web
Interface sessions, select the Configure access to local resources check box.
Then, select from the following options:

Select Connect printers if you want to enable the user to print information
from the terminal server to his local printer.

Select Connect drives if you want to enable the user to copy information
from the terminal server to his local client directories.
Creating Resource Profiles Using Citrix Web Applications

375
Juniper Networks Secure Access Administration Guide

Select Connect COM Ports if you want to enable communication between
the terminal server and devices on the user’s serial ports.
NOTE:

To control access to local resources exclusively through your Citrix Metaframe
server settings, clear the Configure access to local resources check box.
When you clear the option, the Metaframe server settings take effect. Or, if
you want to selectively override Citrix Metaframe server settings for the
bookmark, select the Configure access to local resources check box and then
specify the local resources to which you want to enable or disable access. Note
that if you enable access to a local resource through the IVE, however, you still
must enable access to it through the Metaframe server as well.

When you enable local resources through the terminal server, each user can
only access his own local resources. For instance, user 1 cannot see user 2’s
local directories.
12. Select the Autopolicy: Web Access Control check box to create a policy that
allows or denies users access to the resource specified in the Web Interface
(NFuse) URL field. (By default, the IVE automatically creates a policy for you
that enables access to the resource and all of its subdirectories.) For more
detailed instructions, see “Defining a Web Access Control Autopolicy” on
page 400.
13. If you selected one of the Web interface options above, update the SSO policy
created by the Citrix template. Select the Autopolicy: Single Sign-on check
box. (Single sign-on autopolicies configure the IVE to automatically pass IVE
data such as usernames and passwords to the Citrix application. The IVE
automatically adds the most commonly used values to the single sign-on
autopolicy based on the Citrix implementation you choose.)
When you select single sign-on, the WIClientInfo and WINGSession cookies are
prepopulated automatically in addition to the POST Resource and URL. For
more detailed instructions, see “Specifying Remote SSO Autopolicy Options” on
page 403.
Or, if you selected the non-Web interface option, you may optionally create
your own single sign-on autopolicy using instructions in “Defining a Single SignOn Autopolicy” on page 401.
14. Click Save and Continue.
15. Select the roles in the Roles tab to which the Citrix resource profile applies and
click Add.
The selected roles inherit the autopolicies and bookmarks created by the Citrix
resource profile. If it is not already enabled, the IVE also automatically enables
the Web option in the Users > User Roles > Select_Role > General >
Overview page of the admin console and the Allow Java Applets option in the
Users > User Roles > Select_Role > Web > Options page of the admin
console for all of the roles you select.
16. Click Save Changes.
376

Creating Resource Profiles Using Citrix Web Applications
Chapter 16: Citrix Templates
17. (Optional.) In the Bookmarks tab, modify the default bookmark created by the
IVE and/or create new ones using instructions in “Defining a Web Bookmark”
on page 414. (By default, the IVE creates a bookmark to the Web interface
(NFuse) URL defined in the Web Interface (NFuse) URL field and displays it to all
users assigned to the role specified in the Roles tab.)
Creating Resource Profiles Using Citrix Web Applications

377
Juniper Networks Secure Access Administration Guide
378

Creating Resource Profiles Using Citrix Web Applications
Chapter 17: Lotus iNotes Templates
Chapter 17
Lotus iNotes Templates
A Lotus iNotes template is a resource profile that controls access to the Web
application and configures iNotes settings as necessary. Lotus iNotes templates
significantly reduce your configuration time by consolidating settings into one place
and by prepopulating a variety of resource policy settings for you depending on the
type of setup you select. (For more information about resource profile templates,
see “Resource Profiles” on page 103.)
The IVE supports intermediating traffic to Lotus iNotes through a Web rewriting
resource profile template, JSAM, WSAM, and Network Connect. This topic describes
how to configure access using the Web rewriting template. The prepopulated values
vary depending on the version of iNotes you select and are based on the most
common deployment of the servers.
For more information about the JSAM and WSAM configuration features, see
“Secure Application Manager” on page 489. For more information about the
Network Connect configuration feature, see “Network Connect” on page 637.
To create a resource profile using the Lotus iNotes template:
1. Select Users > Resource Profiles > Web in the admin console.
2. Click New Profile.
3. Select the Lotus Notes version from the Type list.
4. Enter a unique name and optionally a description for the Lotus Notes resource
profile.
5. Enter the URL of the Lotus iNotes resource to which you want to control access
in the Base URL box. Use the format: [protocol://]host[:port][/path]. The IVE
uses the specified URL to define the default bookmark for the Lotus iNotes
resource profile. You may enter a directory URL or a file URL. For detailed
guidelines on how to format Web resources, see “Defining Base URLs” on
page 398.
6. Under iNotes setting, select Allow caching on client to let Web browsers store
non-user data, such as Javascript and CSS files, on a user’s machine. Select
Minimize caching on client to allow the IVE to send a cache-control:no-store
header or a cache-control:no-cache header based on the user’s Web browser and
content type. This is the same as smart caching. See “Defining Resource
Policies: Caching” on page 438.

379
Juniper Networks Secure Access Administration Guide
The Allow caching on client option caches content that the backend iNotes
server typically caches. This caching option improves performance by using the
cached content instead of retrieving the content from the server the next time
the page displays. The Minimize caching on client option provides security by
sending a cache-control:no-store header or a cache-control:no-cache header to
either not store content or to re-validate the cached content each time it is
requested. With both caching option, you can choose to either allow or prevent
the uploading or downloading of attachments.
7. Select the Prevent download of attachments check box to prohibit users from
downloading attachments to their systems. Select the Prevent upload of
attachments check box (available only for Lotus iNotes 6.5 and Lotus iNotes 7)
to prevent users from transmitting (uploading) attachments to the IVE.
8. Select the Autopolicy: Web Access Control check box to create a policy that
allows or denies users access to the Web resource (and all of its subdirectories)
listed in the Resource field.
a.
In the Resource box, specify the Web server or HTML page to which you
want to control access using the format: [protocol://]host[:port][/path]. For
detailed guidelines, see “Defining Web Resources” on page 399.
b.
From the Action list, select Allow to enable access to the specified resource
or Deny to block access to the specified resource.
c.
Click Add.
9. Select the Autopolicy: Caching check box to specify the resources to which this
policy applies in the Resource box. To create the caching autopolicy, follow the
instructions in “Defining a Caching Autopolicy” on page 404.
NOTE: The correct caching resource policy must be configured to allow end users
to open and save e-mail attachments of different document types in iNotes. For
example, if the caching policy is set to Smart, end users cannot save .htm or .html
attachments to disk.
10. Select the Autopolicy: Web Compression check box to create a policy that
specify which types of Web data the IVE should and should not compress.
a.
In the Resources field, specify the resources to which this policy applies.
For detailed guidelines, see “Defining Web Resources” on page 399.
b.
Select one of the following options from the Action list:
c.
380


Compress—The IVE compresses the supported content types from the
specified resource.

Do not compress—The IVE does not compress the supported content
types from the specified resource.
Click Add.
Chapter 17: Lotus iNotes Templates
11. Select the Autopolicy: Single Sign-On check box to pass IVE data such as the
username and password to the Lotus iNotes application. To create the single
sign-on autopolicy, follow the instructions in “Defining a Single Sign-On
Autopolicy” on page 401.
12. Click Save and Continue.
13. Select the roles to which the Lotus iNotes resource profile applies in the Roles
tab and click Add.
The selected roles inherit the autopolicies and bookmarks created by the Lotus
iNotes resource profile. If it is not already enabled, the IVE also automatically
enables the Web option in the Users > User Roles > Select Role > General >
Overview page of the admin console.
14. Click Save Changes.
15. (Optional.) In the Bookmarks tab, modify the default bookmark created by the
IVE and/or create new ones using instructions in “Defining a Web Bookmark”
on page 414.

381
Juniper Networks Secure Access Administration Guide
382

Chapter 18: Microsoft OWA Templates
Chapter 18
Microsoft OWA Templates
A Microsoft Outlook Web Access (OWA) template is a resource profile that controls
access to the application and configures OWA settings as necessary. OWA
templates significantly reduce your configuration time by consolidating
configuration settings into one place and by prepopulating a variety of resource
policy settings for you depending on the type of setup you select. (For more
information about resource profile templates, see “Resource Profiles” on page 103.)
The IVE supports intermediating traffic to Microsoft OWA through a Web rewriting
resource profile template, JSAM, WSAM, and Network Connect. This topic describes
how to configure access using the Web rewriting template. The prepopulated values
vary depending on the version of OWA you select and are based on the most
common deployment of the servers.
For more information about the JSAM and WSAM configuration features, see
“Secure Application Manager” on page 489. For more information about the
Network Connect configuration feature, see “Network Connect” on page 637.
To create a resource profile using the Microsoft OWA template:
1. Select Users > Resource Profiles > Web Applications/Pages in the admin
console.
2. Click New Profile.
3. Select Microsoft OWA 2000, Microsoft OWA 2003 or Microsoft OWA 2007
from the Type list.
4. Enter a unique name and optionally a description for the Citrix resource profile.
5. Enter the URL of the OWA resource to which you want to control access In the
Base URL box. Use the format: [protocol://]host[:port][/path]. The IVE uses the
specified URL to define the default bookmark for the OWA resource profile. You
may enter a directory URL or a file URL. For detailed guidelines on how to
format Web resources, see “Defining Base URLs” on page 398.
6. Under OWA settings select the following options,
a.
(OWA 2000 and OWA 2003.) Select Allow caching on client to let Web
browsers store non-user data, such as Javascript and CSS files, on a user’s
machine.
The Allow caching on client option caches content the backend OWA server
typically caches. This caching option improves performance by using the
cached content instead of retrieving the content from the server the next
time the page displays.

383
Juniper Networks Secure Access Administration Guide
b.
(OWA 2000 and OWA 2003.) Select Minimize caching on client to allow
the IVE to send a cache-control:no-store header or a cache-control:no-cache
header (do not store content or revalidate the cached content each time it
is requested) based on the user’s Web browser and content type. This is the
same as smart caching.
c.
(OWA 2007.) Select Managed Device to cache files. If you configure a Form
post SSO, the trusted parameter is set to 4. This indicates the end user’s
device is private.
d. (OWA 2007.) Select Unmanaged Device to not cache files. If you configure
a Form post SSO, the trusted parameter is set to 0. This indicates the end
user’s device is public.
NOTE: If it is necessary to download an attachment, the file is cached even though
you select Unmanaged Device.
e.
Select Prevent download of attachments to prohibit users from
downloading attachments to their systems.
f.
Select Prevent upload of attachments to prevent users from transmitting
(uploading) attachments to the IVE.
7. Under Autopolicy: Web Access Control, create a policy that allows or denies
users access to the Web resource (and all of its subdirectories) listed in the
Resource field.
a.
Specify the Web server or HTML page to which you want to control access
in the Resource field. Use the format: [protocol://]host[:port][/path]. For
detailed guidelines, see “Defining Web Resources” on page 399.
b.
Select Allow to enable access to the specified resource or Deny to block
access to the specified resource from the Action list.
c.
Click Add.
8. Under Autopolicy: Caching, specify the resources to which this policy applies in
the Resource box. To create the caching autopolicy, follow the instructions in
“Defining a Caching Autopolicy” on page 404.
NOTE: The correct caching resource policy must be configured to allow end users
to open and save e-mail attachments of different document types in OWA. For
example, if the caching policy is set to Smart, end users cannot save .htm or .html
attachments to disk.
9. Under Autopolicy: Web Compression, create a policy that specifies which types
of Web data the IVE should and should not compress.
384

a.
Specify the resources to which this policy applies in the Resources box. For
detailed guidelines, see “Defining Web Resources” on page 399.
b.
Select one of the following options from the Action list:
Chapter 18: Microsoft OWA Templates
c.

Compress—The IVE compresses the supported content types from the
specified resource.

Do not compress—The IVE does not compress the supported content
types from the specified resource.
Click Add.
10. Select the Autopolicy: Single Sign-On check box to pass IVE data such as the
username and password to the OWA application. To create the single sign-on
autopolicy, follow the instructions in “Defining a Single Sign-On Autopolicy” on
page 401.
11. Click Save and Continue.
12. Select the roles to which the resource profile applies in the Roles tab and click
Add.
The selected roles inherit the autopolicies and bookmarks created by the
Microsoft OWA resource profile. If it is not already enabled, the IVE also
automatically enables the Web option in the Users > User Roles > Select _Role
> General > Overview page of the admin console.
13. Click Save Changes.
14. (Optional.) Modify the default bookmark created by the IVE in the Bookmarks
tab, and/or create new ones using instructions in “Defining a Web Bookmark”
on page 414.

385
Juniper Networks Secure Access Administration Guide
386

Chapter 19: Microsoft Sharepoint Templates
Chapter 19
Microsoft Sharepoint Templates
A Microsoft Sharepoint template is a resource profile that controls access to the
application and configures Sharepoint settings as necessary. Microsoft Sharepoint
templates significantly reduce your configuration time by consolidating
configuration settings into one place and by pre-populating a variety of resource
policy settings for you depending on the type of setup you select. For more
information about resource profile templates, see “Resource Profiles” on page 103.
The IVE supports intermediating traffic to Microsoft Sharepoint through a Web
rewriting resource profile template, JSAM, WSAM, and Network Connect. This topic
describes how to configure access using the Web rewriting template.
NOTE: In the current release, we support sending contact information from
Sharepoint to your Outlook client through the Content Intermediation Engine
(Web rewriting feature). Transferring the contact information to the backend
Exchange server requires WSAM, JSAM, or Network Connect. To import contact
information into the Sharepoint server from your Outlook client, first export your
contacts and then upload them to the Sharepoint server.
For more information about the JSAM and WSAM configuration features, see
“Secure Application Manager” on page 489. For more information about the
Network Connect configuration feature, see “Network Connect” on page 637.
To create a resource profile using the Microsoft Sharepoint template:
1. Select Users > Resource Profiles > Web in the admin console.
2. Click New Profile.
3. Select Microsoft Sharepoint from the Type list.
4. Enter a unique name and optionally a description for the Sharepoint resource
profile.
5. Enter the URL of the Sharepoint resource to which you want to control access in
the Base URL field. Use the format: [protocol://]host[:port][/path]. The IVE uses
the specified URL to define the default bookmark for the Sharepoint resource
profile. You may enter a directory URL or a file URL. For detailed guidelines on
how to format Web resources, see “Defining Base URLs” on page 398.
6. Under Sharepoint Settings, select Allow in-line editing of documents within
explorer view to allow users to modify files displayed in the explorer view.
a.
Enter the URL to the Explorer View page, and then click Add. Do not enter
a value that resolves to non-Explorer View URLs (such as http://*:*). Doing
so might cause Explorer View to not launch.

387
Juniper Networks Secure Access Administration Guide
b.
Order the resources in your list, if appropriate, by selecting the check box
next to an item and then using the up and down arrows to move it to the
correct place in the list.
c.
Enter the number of minutes a persistent cookie resides on a user’s
computer before it expires in the Persistent cookie timeout box.
NOTE: Do not confuse this timeout option with Max. Session Length, which
determines the number of minutes an active nonadministrative user session may
remain open before ending. For more information on Max. Session Length, see
“Specifying Session Options” on page 89.
7. Under Autopolicy: Web Access Control, create a policy that allows or denies
users access to the Web resource (and all of its subdirectories) listed in the
Resource box.
a.
Specify the Web server or HTML page to which you want to control access
in the Resource box. Use the format: [protocol://]host[:port][/path]. For
detailed guidelines, see “Defining Web Resources” on page 399.
b.
Select Allow to enable access to the specified resource or Deny to block
access to the specified resource from the Action list.
c.
Click Add.
8. (Optional.) Click Show ALL autopolicy types to create additional autopolicies
that fine-tune access to the resource. Then, create the autopolicies using
instructions in the following topics:

“Defining a Single Sign-On Autopolicy” on page 401

“Defining a Caching Autopolicy” on page 404

“Defining a Rewriting Autopolicy” on page 409

“Defining a Web Compression Autopolicy” on page 413
9. Click Save and Continue.
10. Select the roles to which the resource profile applies in the Roles tab, and click
Add.
The selected roles inherit the autopolicies and bookmarks created by the
Microsoft Sharepoint resource profile. If it is not already enabled, the IVE also
automatically enables the Web option in the Users > User Roles > Select Role
> General > Overview page of the admin console.
11. Click Save Changes.
12. (Optional.) Modify the default bookmark created by the IVE in the Bookmarks
tab or create new ones using instructions in “Defining a Web Bookmark” on
page 414.
388

Chapter 20
Web Rewriting
The IVE Web rewriting feature enables you to intermediate Web URLs through the
Content Intermediation Engine. You can intermediate URLs on the World Wide
Web or on your corporate Intranet.
This section contains the following information about intermediating Web content:

“Licensing: Web Rewriting Availability” on page 390

“Task summary: Configuring the Web Rewriting Feature” on page 390

“Web URL Rewriting Overview” on page 392

“Defining Resource Profiles: Custom Web Applications” on page 397

“Defining Role Settings: Web URLs” on page 416

“Defining Resource Policies: Overview” on page 423

“Defining Resource Policies: Web Access” on page 425

“Defining Resource Policies: Single Sign-On” on page 426

“Defining Resource Policies: Caching” on page 438

“Defining Resource Policies: External Java Applets” on page 442

“Defining Resource Policies: Rewriting” on page 445

“Defining Resource Policies: Web Compression” on page 455

“Defining Resource Policies: Web Proxy” on page 457

“Defining Resource Policies: HTTP 1.1 Protocol” on page 460

“Defining Resource Policies: Cross-Domain Access (XMLHttpRequest Calls)” on
page 461

“Defining Resource Policies: General Options” on page 463

“Managing Resource Policies: Customizing UI Views” on page 463

389
Juniper Networks Secure Access Administration Guide
Licensing: Web Rewriting Availability
Web rewriting is a standard feature on all Secure Access appliances except the SA
700. If you are using an SA-700 appliance, you must install a Core Clientless Access
upgrade license in order to access baseline Web rewriting features. Note, however,
that the following advanced Web rewriting features are not available on the SA 700,
even if you have the Core Clientless Access upgrade license:

Remote SSO

WSAM & JSAM rewriting policies (available through Web application resource
profiles)

Non-Java ICA rewriting options (available through Citrix templates)
Task summary: Configuring the Web Rewriting Feature
NOTE: When intermediating content through the content intermediation engine,
we recommend that the GMT time on both the IVE and the backend web
application server be the same. This prevents any premature expiration of cookies
if the IVE time later than the web application server time.
To configure the Web rewriting feature:
1. Create resource profiles that enable access to Web sites, create supporting
autopolicies (such as single sign-on and Java access control policies) as
necessary, include bookmarks that link to the Web sites, and assign the policies
and bookmarks to user roles using settings in the Web Applications Resource
Profiles page (Users > Resource Profiles > Web) of the admin console. For
instructions, see:

“Defining Resource Profiles: Custom Web Applications” on page 397

“Defining Role Settings: Web URLs” on page 416
We recommend that you use resource profiles to configure Web rewriting (as
described above). However, if you do not want to use resource profiles, you can
configure Web rewriting using role and resource policy settings in the following
pages of the admin console instead:
390

a.
Create resource policies that enable access to Web sites using settings in
the Users > Resource Policies> Web > Web ACL page of the admin
console. For instructions, see “Defining Resource Policies: Web Access” on
page 425.
b.
As necessary, create supporting resource policies (such as single sign-on
and Java access control policies) using settings in the Users > Resource
Policies> Select Policy Type pages of the admin console. For instructions,
see:
Licensing: Web Rewriting Availability
Chapter 20: Web Rewriting
c.

“Defining Resource Policies: Single Sign-On” on page 426

“Defining Resource Policies: Caching” on page 438

“Defining Resource Policies: External Java Applets” on page 442

“Defining Resource Policies: Rewriting” on page 445

“Defining Resource Policies: Web Compression” on page 455

“Defining Resource Policies: Web Proxy” on page 457

“Defining Resource Policies: HTTP 1.1 Protocol” on page 460
Determine which user roles may access the Web sites that you want to
intermediate, and then enable Web access for those roles through the
Users > User Roles > Select Role > General > Overview page of the
admin console. For instructions, see “Configuring General Role Options” on
page 87.
d. Create bookmarks to your Web sites using settings in the Users > User
Roles > Select Role > Web > Bookmarks page of the admin console. For
instructions, see “Defining Role Settings: Web URLs” on page 416.
e.
As necessary, enable Web general options that correspond to the types of
Web content you are intermediating (such as Java) using settings in the
Users > User Roles > Select Role > Web > Options page of the admin
console. For instructions, see “Specifying General Web Browsing Options”
on page 419.
2. After enabling access to Web applications or sites using Web rewriting resource
profiles or roles and resource policies, you can modify general role and
resource options in the following pages of the admin console:
a.
(Optional) Set additional Web browsing options (such as allowing users to
create their own bookmarks or enabling hostname masking) Users > User
Roles > Select Role > Web > Options page of the admin console. For
instructions, see “Specifying General Web Browsing Options” on page 419.
NOTE: Even if you enable hostname masking, links corresponding to protocols not
rewritten by the IVE are not obfuscated. For example, ftp://xyz.juniper.net and
file://fileshare.juniper.net/filename are not obfuscated. By not obfuscating the
hostname, users can still access these resources.
Task summary: Configuring the Web Rewriting Feature  391
Juniper Networks Secure Access Administration Guide
b.
(Optional) Set additional Web options for individual resources (such as
enabling the IVE to match IP addresses to host names) using settings in the
Users > Resource Policies> Web > Options page of the admin console.
For instructions, see “Defining Resource Policies: General Options” on
page 463.
NOTE: Certain Web rewriting features (such as passthrough proxy and SSO to
NTLM resources) require additional configuration. For more information, see the
appropriate configuration instructions.
Web URL Rewriting Overview
When you intermediate standard Web content through the IVE, you can create
supplemental policies that “fine-tune” the access requirements and processing
instructions for the intermediated content. You can create these supplemental
policies through resource profiles (recommended) or resource policies.
Standard Web rewriting policy types include:
392

Web URL Rewriting Overview

Web access control—Web access policies control which Web resources users
can access in order to connect to the Internet, intranet, or extranet. For
configuration instructions, see “Defining a Web Access Control Autopolicy” on
page 400 (recommended) or “Defining Resource Policies: Web Access” on
page 425.

Single sign-on—Single sign-on policies enable you to automatically pass user
credentials to a Web application. You can configure single sign-on policies to
intercept basic authentication and NTLM challenges or post the credentials and
headers that you specify to the Web application, as explained in “Remote SSO
Overview” on page 393. For configuration instructions, see “Defining a Single
Sign-On Autopolicy” on page 401 (recommended) or “Defining Resource
Policies: Single Sign-On” on page 426.

Caching—Caching policies control which Web content the IVE caches on a
user’s machine. For configuration instructions, see “Defining a Caching
Autopolicy” on page 404 (recommended) or “Defining Resource Policies:
Caching” on page 438.

Java—Java policies control to which servers and ports Java applets can connect.
These policies also specify trusted servers for which the IVE resigns content.
For configuration instructions, see “Defining a Java Access Control Autopolicy”
on page 407 (recommended) or “Defining Resource Policies: External Java
Applets” on page 442.

Rewriting—Rewriting policies specify resources that the IVE should not
intermediate, minimally intermediation (as explained in “Passthrough Proxy
Overview” on page 394), or only intermediate selectively. For configuration
instructions, see “Defining a Rewriting Autopolicy” on page 409
(recommended) or “Defining Resource Policies: Rewriting” on page 445.
Chapter 20: Web Rewriting

Web compression—Web compression policies specify which types of Web
data the IVE should and should not compress, as explained in “Compression”
on page 995. For configuration instructions, see “Defining a Web Compression
Autopolicy” on page 413 (recommended) or “Defining Resource Policies: Web
Compression” on page 455.

Web proxy—(Resource policies only) Web proxy resource policies specify Web
proxy servers for which the IVE should intermediate content. Note that the IVE
intermediates both forward and backwards proxies, but only enables single
sign-on to trusted proxies. For configuration instructions, see “Defining
Resource Policies: Web Proxy” on page 457.

Launch JSAM—(Resource policies only) Launch JSAM policies specify URLs for
which the IVE automatically launches J-SAM on the client. This feature is useful
if you enable applications that require J-SAM but do not want to require users to
run J-SAM unnecessarily. For configuration instructions, see “Automatically
Launching JSAM” on page 538.

Protocol—(Resource policies only) Protocol resource policies enable or disable
HTTP 1.1 protocol support on the IVE. For configuration instructions, see
“Defining Resource Policies: HTTP 1.1 Protocol” on page 460.

Options— (Resource policies only) You can enable IP based matching for
hostnames as well as case-sensitive matching for path and query strings in
Web resources through resource policy options. For configuration instructions,
see “Defining Resource Policies: General Options” on page 463.
Remote SSO Overview
The Remote Single Sign-On (SSO) feature enables you to specify the URL sign-in
page of an application to which you want the IVE to post a user’s credentials,
minimizing the need for users to re-enter their credentials when accessing multiple
back-end applications. You may also specify additional forms values and custom
headers (including cookies) to post to an application’s sign-in form.
Remote SSO configuration consists of specifying Web resource policies:

Form POST policy—This type of Remote SSO policy specifies the sign-in page
URL of an application to which you want to post IVE data and the data to post.
This data can include the user’s primary or secondary IVE username and
password (as explained in “Multiple Sign-In Credentials Overview” on
page 237) as well as system data stored by system variables (described in
“System Variables and Examples” on page 1018). You can also specify whether
or not users can modify this information.

Headers/Cookies policy—This type of Remote SSO policy specifies resources,
such as customized applications, to which you can send custom headers and
cookies.
Web URL Rewriting Overview  393
Juniper Networks Secure Access Administration Guide
If a user’s IVE credentials differ from those required by the back-end application,
the user can alternatively access the application:

By signing in manually—The user can quickly access the back-end application
by entering his credentials manually into the application’s sign-in page. The
user may also permanently store his credentials and other required
information in the IVE through the Preferences page as described below, but is
not required to enter information in this page.

Specifying the required credentials on the IVE—The user must provide the
IVE with his correct application credentials by setting them through the
Preferences page. Once set, the user must sign out and sign back in to save his
credentials on the IVE. Then, the next time the user clicks the Remote SSO
bookmark to sign in to the application, the IVE sends the updated credentials.
NOTE: Use the Remote SSO feature to pass data to applications with static POST
actions in their HTML forms. It is not practical to use Remote SSO with
applications that employ frequently changing URL POST actions, time-based
expirations, or POST actions that are generated at the time the form is generated.
For information about configuring Remote SSO:

“Defining a Single Sign-On Autopolicy” on page 401 (recommended method)

“Writing a Remote SSO Form POST Resource Policy” on page 434

“Writing a Remote SSO Headers/Cookies Resource Policy” on page 436
Passthrough Proxy Overview
The passthrough proxy feature enables you to specify Web applications for which
the IVE performs minimal intermediation. Unlike traditional reverse proxy
functionality, which also rewrites only selective parts of a server response but
requires network changes as well as complex configuration, this feature only
requires that you specify application servers and the way in which the IVE receives
client requests to those application servers:
394

Web URL Rewriting Overview

Via an IVE port—When specifying an application for the passthrough proxy to
intermediate, you specify a port on which the IVE listens for client requests to
the application server. When the IVE receives a client request for the
application server, it forwards the request to the specified application server
port. When you choose this option, you must open traffic to the specified IVE
port on your corporate firewall.

Via virtual host name—When specifying an application for the passthrough
proxy to intermediate, you specify an alias for the application server host
name. You need to add an entry for this alias in your external DNS server that
resolves to the IVE. When the IVE receives a client request for the alias, it
forwards the request to the port you specify for the application server.
Chapter 20: Web Rewriting
This option is useful if your company has restrictive policies about opening
firewall ports to either internal servers or servers in the DMZ. When using this
option, we recommend that each host name alias contains the same domain
substring as your IVE host name and that you upload a wild card server
certificate to the IVE in the format: *.domain.com.
For example, if your IVE is iveserver.yourcompany.com, then a host name alias
should be in the format appserver.yourcompany.com and the wild card
certificate format would be *.yourcompany.com. If you do not use a wild card
certificate, then a client’s browser issues a certificate name check warning
when a user browses to an application server, because the application server
host name alias does not match the certificate domain name. This behavior
does not prevent a user from accessing the application server, however.
NOTE: When you configure passthrough proxy to work in virtual host name mode,
users must use the IVE host name that you specify through the System >
Network > Overview page of the admin console when signing into the IVE. They
cannot access use passthrough proxy if they sign into the IVE using its IP address.
Just as with the Content Intermediation Engine, the passthrough proxy option
offers increased security relative to the Secure Application Manager, because when
enabled for an application, the IVE allows the client to send only layer-7 traffic
directed to fixed application ports to the enterprise network. Use this option to
enable the IVE to support applications with components that are incompatible with
the Content Intermediation Engine, such as Java applets in Oracle e-business suite
applications or applets that run in an unsupported Java Virtual Machine (JVM).
NOTE:

Passthrough proxy URLs must be host names. Paths of host names are not
supported.

Juniper Networks strongly recommends that you not mix passthrough proxy
Port mode and passthrough proxy Host mode.

The passthrough proxy option works only for applications that listen on fixed
ports and where the client does not make direct socket connections.

To use passthrough proxy with Oracle E-Business applications, you must
install a real certificate on the IVE and you must configure Oracle Forms to
use the Forms Listener Servlet mode.

The following advanced features of the IVE framed toolbar are not available in
passthrough proxy: bookmark current page, display the original URL, display
the favorite bookmarks.
Web URL Rewriting Overview  395
Juniper Networks Secure Access Administration Guide
Task Summary: Configuring Passthrough Proxy
To configure the Web rewriting feature:
1. Create resource profiles that enable access to Web applications, create
supporting Web rewriting autopolicies that enable passthrough proxy, include
bookmarks that link to the Web applications, and assign the policies and
bookmarks to user roles using settings in the Users > Resource Profiles>
Web page of the admin console. For instructions, see “Defining Resource
Profiles: Custom Web Applications” on page 397.
Alternatively, you can:
a.
Create resource policies that enable access to Web applications using
settings in the Users > Resource Policies> Web > Web ACL page of the
admin console. For instructions, see “Defining Resource Policies: Web
Access” on page 425.
b.
Create supporting Web rewriting resource policies that enable passthrough
proxy using settings in the Users > Resource Policies> Web > Web ACL
page of the admin console. For instructions, see “Defining Resource
Policies: Rewriting” on page 445.
c.
Determine which user roles may access the Web applications that you
want to intermediate with passthrough proxy, and then enable Web access
for those roles through the Users > User Roles > Select Role > General
> Overview page of the admin console. For instructions, see “Configuring
General Role Options” on page 87.
d. Create bookmarks to your Web sites using settings in the Users > User
Roles > Select Role > Web > Bookmarks page of the admin console. For
instructions, see “Defining Role Settings: Web URLs” on page 416.
2. If your passthrough proxy resource policy enables the IVE to receive client
requests through an IVE port, open traffic to the specified port in your
corporate firewall. Or, if your policy enables requests through a virtual host
name:
396

Web URL Rewriting Overview
a.
Add an entry for each application server host name alias in your external
DNS that resolves to the IVE.
b.
Define the IVE name and host name through the System > Network >
Internal Port page of the admin console. For instructions, see “Configuring
Network Settings” on page 686.
c.
Upload a wildcard certificate to the IVE through the System >
Configuration > Certificates > Device Certificates page of the admin
console. Or, upload multiple certificates and associate a virtual port with
each certificate using settings in the same page. For instructions, see
“Importing an Existing Root Certificate and Private Key” on page 731 and
“Associating a Certificate With a Virtual Port” on page 736.
Chapter 20: Web Rewriting
Examples of Using Passthrough Proxy
If your IVE is iveserver.yourcompany.com and you have an Oracle server at
oracle.companynetwork.net:8000, you could specify the following application
parameters when specifying an IVE port:
Server: oracle.companynetwork.net
Port: 8000
IVE port: 11000
When the IVE receives Oracle client traffic sent to
iveserver.yourcompany.com:11000, it forwards the traffic to
oracle.companynetwork.net:8000.
Or, if you want to specify a host name alias, you could configure the application
with these parameters:
Server: oracle.companynetwork.net
Port: 8000
IVE alias: oracle.yourcompany.com
When the IVE receives Oracle client traffic sent to oracle.yourcompany.com, it
forwards the traffic to oracle.companynetwork.net:8000
Defining Resource Profiles: Custom Web Applications
A custom Web application resource profile is a resource profile that controls access
to a Web application, Web server, or HTML page. (For more information about
resource profiles, see “Resource Profiles” on page 103.)
To create a custom Web application resource profile:
1. Select Users > Resource Profiles > Web in the admin console.
2. Click New Profile.
3. From the Type list, choose Custom.
NOTE: For information about the other options available from the Type list, see
the following sections:

“Hosted Java Applets Templates” on page 353

“Citrix Templates” on page 369

“Lotus iNotes Templates” on page 379

“Microsoft OWA Templates” on page 383

“Microsoft Sharepoint Templates” on page 387
4. Enter a unique name and optionally a description for the resource profile.
Defining Resource Profiles: Custom Web Applications  397
Juniper Networks Secure Access Administration Guide
5. In the Base URL field, enter the URL of the Web application or page for which
you want to control access using the format: [protocol://]host[:port][/path]. For
detailed guidelines, see “Defining Base URLs” on page 398. (The IVE uses the
specified URL to define the default bookmark for the resource profile.)
6. In the Autopolicy: Web Access Control section, create a policy that allows or
denies users access to the resource specified in the Base URL field. (By default,
the IVE automatically creates a policy for you that enables access to the Web
resource and all of its sub-directories.) For more detailed instructions, see
“Defining a Web Access Control Autopolicy” on page 400.
7. (Optional) Click Show ALL autopolicy types to create additional autopolicies
that fine-tune access to the resource. Then, create the autopolicies using
instructions in the following sections:

“Defining a Single Sign-On Autopolicy” on page 401

“Defining a Caching Autopolicy” on page 404

“Defining a Java Access Control Autopolicy” on page 407

“Defining a Rewriting Autopolicy” on page 409

“Defining a Web Compression Autopolicy” on page 413
8. Click Save and Continue.
9. In the Roles tab, select the roles to which the resource profile applies and click
Add.
The selected roles inherit the autopolicies and bookmarks created by the
resource profile. If it is not already enabled, the IVE also automatically enables
the Web option in the Users > User Roles > Select Role > General >
Overview page of the admin console for all of the roles you select.
10. Click Save Changes.
11. (Optional) In the Bookmarks tab, modify the default bookmark created by the
IVE and/or create new ones using instructions in “Defining a Web Bookmark”
on page 414. (By default, the IVE creates a bookmark to the base URL defined
in the Base URL field and displays it to all users assigned to the role specified in
the Roles tab.)
Defining Base URLs
When creating a Web resource profile, you must use the following format when
defining base URLs:
[protocol://]host[:port][/path]
Within this format, the components are:

398

Protocol (required)—Possible values: http:// and https://. Note that you cannot
use special characters within the protocol.
Defining Resource Profiles: Custom Web Applications
Chapter 20: Web Rewriting

Host (required)—Possible values:

DNS Hostname—For example: www.juniper.com

IP address—You must enter the IP address in the format: a.b.c.d. For
example: 10.11.149.2. You cannot use special characters in the IP address.

Ports (optional)—You must use the delimiter “:” when specifying a port. For
example: 10.11.149.2/255.255.255.0:*

Path (optional)—When specifying a path for a base URL, the IVE does not allow
special characters. If you specify a path, you must use the “/” delimiter. For
example, http://www.juniper.net/sales.
Defining Web Resources
When creating a Web resource profile (for example, in “Defining Resource Profiles:
Custom Web Applications” on page 397), you must use the following format when
defining resources for autopolicies:
[protocol://]host[:ports][/path]
Within this format, the four components are:

Protocol (required)—Possible values: http:// and https://. Note that you cannot
use special characters within the protocol.

Host (required)—Possible values:

DNS Hostname—For example: www.juniper.com
You may use the following special characters allowed in the hostname:
Table 22: DNS hostname special characters
*
Matches ALL characters.
%
Matches any character except dot (.)
?
Matches exactly one character

IP address/Netmask—You must enter the IP address in the format: a.b.c.d
You may use one of two formats for the netmask:

Prefix: High order bits

IP: a.b.c.d
For example: 10.11.149.2/24 or 10.11.149.2/255.255.255.0
You cannot use special characters in the IP address or netmask.

Ports (optional)—You must use the delimiter “:” when specifying a port. For
example: 10.11.149.2/255.255.255.0:*
Defining Resource Profiles: Custom Web Applications  399
Juniper Networks Secure Access Administration Guide
Table 23: Port possible values
*
Matches ALL ports; you cannot use any other special characters
port[,port]*
A comma-delimited list of single ports. Valid port numbers are [165535].
[port1]-[port2]
A range of ports, from port1 to port2, inclusive.
NOTE: You can mix port lists and port ranges, such as: 80,443,8080-8090
If the port is missing, then the default port 80 is assigned for http, 443 for https.

Path (optional)—When specifying a path for a Web access control autopolicy,
you may use a * character, meaning ALL paths match. (The IVE does not
support any other special characters.) If you specify a path, you must use the
“/” delimiter. For example:

http://www.juniper.net/sales

http://www.juniper.net:80/*

https://www.juniper.net:443/intranet/*
Defining a Web Access Control Autopolicy
Web access policies control which Web resources users can access in order to
connect to the Internet, intranet, or extranet. When defining a custom Web
resource profile, you must enable a corresponding Web access control autopolicy
that enables access to the profile’s primary resource. The IVE simplifies the process
for you by automatically creating an autopolicy that allows access to the Web
resource and all of its sub-directories.
If necessary, you may choose to modify this default autopolicy or create
supplementary Web access control autopolicies that control access to additional
resources. For instance, your IT department may use one server to store Web pages
for your company intranet (http://intranetserver.com) and another server to store
the images that the Web pages reference (http://imagesserver.com). In this case,
you can create two Web access control autopolicies that enable access to both
servers so that your users can access both your Web pages and the corresponding
images.
To create a new Web access control autopolicy:
1. Create a custom Web application resource profile, as explained in the following
sections:

“Defining Resource Profiles: Custom Web Applications” on page 397

“Defining Role Settings: Web URLs” on page 416
2. If available, click the Show ALL autopolicy types button to display the
autopolicy configuration options.
400

Defining Resource Profiles: Custom Web Applications
Chapter 20: Web Rewriting
3. If it is not already enabled, select the Autopolicy: Web Access Control
checkbox.
4. In the Resource field, specify the Web server or HTML page to which you want
to control access using the format: [protocol://]host[:ports][/path]. For detailed
guidelines, see “Defining Web Resources” on page 399.
5. From the Action list, choose Allow to enable access to the specified resource or
Deny to block access to the specified resource.
6. Click Add.
7. Click Save Changes.
Defining a Single Sign-On Autopolicy
Single sign-on policies enable you to automatically pass user credentials to the Web
application specified in your policy, as explained in “Single Sign-On” on page 235.
Single sign-on autopolicies also intermediate the data that you pass.
NOTE: For information about configuring advanced SSO options that are not
available through resource profiles, including disabling intermediation for
specified resources or using SAML for individual resources, see “Defining Resource
Policies: Single Sign-On” on page 426.
To create a single sign-on (SSO) autopolicy:
1. Create a Web resource profile, as explained in the following sections:

“Defining Resource Profiles: Custom Web Applications” on page 397

“Defining Role Settings: Web URLs” on page 416
2. If available, click the Show ALL autopolicy types button to display the
autopolicy configuration options.
3. Select the Autopolicy: Single Sign-On checkbox.
4. Select a single sign-on method and configure the corresponding SSO options:
NOTE: SSO options require you to select credentials. If you have not already done
so, define the credentials using the Resource Policies > Web > General page
prior to defining your SSO autopolicy.

Disable SSO—Disables single sign-on.

Basic Auth—Enables the IVE to intermediate the challenge/response
sequence during basic authentication and use the credentials it collects to
sign into a protected resource within the same Intranet zone. This option
does not apply to Citrix resource profiles.
Defining Resource Profiles: Custom Web Applications  401
Juniper Networks Secure Access Administration Guide

NTLM—Enables the IVE to intermediate the challenge/response sequence
during NTLM authentication and use the credentials it collects to sign into a
protected resource within the same Intranet zone. This option does not
apply to Citrix resource profiles.
NOTE: Web rewriting and file browsing both support NTLM v1 and NTLM v2.

Kerberos—Enables the IVE to intermediate the challenge/response
sequence during Kerberos authentication and use the credentials it collects
to sign into a protected resource within the same Intranet zone.

Constrained Delegation—Enables authentication of users by Kerberos
after their identity has been verified using a non-Kerberos authentication
method. For example, suppose a user authenticates with RADIUS and
enters their passcode (typically PIN and tokencode). When accessing a
service, the user may be challenged again because the PIN is not
recognized. With constrained delegation, the administrator sets up
passwords for constrained delegation users. The users do not need to know
this password. When accessing the same HTTP service, the IVE now
fetches the ticket on behalf of the user without challenging the user.

Remote SSO—Enables the IVE to post the data that you specify (including
IVE usernames, passwords, and system data stored by variables) to Web
applications. This option also enables you specify custom headers and
cookies to post to Web applications. For detailed configuration
instructions, see “Specifying Remote SSO Autopolicy Options” on
page 403.
5. Click Save Changes.
Specifying Basic Authentication, NTLM or Kerberos SSO Autopolicy
Options
To configure basic authentication, NTLM or Kerberos SSO autopolicy options:
1. Create an SSO autopolicy and choose Basic Auth, NTLM or Kerberos as
explained in “Defining a Single Sign-On Autopolicy” on page 401.
2. In the Resource field, specify the resources to which this policy applies. For
detailed guidelines, see “Defining Web Resources” on page 399.
NOTE: When entering a resource in this field, note that:
402


If you want the IVE to automatically post values to a specific URL when an
end-user clicks on an IVE bookmark, the resource that you enter here must
exactly match the URL that you specify in the Base URL field of the resource
profile.

If you want the IVE to automatically submit IVE user credentials to other Web
sites within the same Intranet zone, the host name that you enter here must
end in the DNS suffix configured in the System > Network > Overview page
of the admin console.
Defining Resource Profiles: Custom Web Applications
Chapter 20: Web Rewriting
3. Select the credentials to use. If this pull-down menu is blank, no credentials are
defined in the SSO General tab. For more information, see “Defining the Basic,
NTLM and Kerberos Resources” on page 426.
4. (NTLM only) Select the Fallback to NTLM V1 option to fallback to NTLM V1 if
NTLM V2 fails. If you do not select this option, the IVE falls back only to NTLM
V2. An intermediation page appears if SSO fails.
5. (Kerberos only) Select the Fallback to NTLM V2 only option to fallback only to
NTLM V2 if kerberos fails. If you do not select this option, a Kerberos
intermediation page appears if Kerberos SSO fails.
6. (Constrained delegation only) Select the Fallback to Kerberos option fallback to
Kerberos if constrained delegation fails. If you do not select this option, an error
page appears if SSO fails.
Specifying Remote SSO Autopolicy Options
To configure remote SSO autopolicy options:
1. Create an SSO autopolicy through a custom Web resource profile and choose
Remote SSO, as explained “Defining a Single Sign-On Autopolicy” on page 401.
2. If you want to perform a form POST when a user makes a request to the
resource specified in the Resource field, select the POST the following data
checkbox. Then:
a.
In the Resource field, specify the application’s sign-in page, such as:
http://my.domain.com/public/login.cgi. The IVE does not accept wildcard
characters in this field.
NOTE: If you want the IVE to automatically post values to a specific URL when an
end-user clicks on an IVE bookmark, the resource that you enter here must
exactly match the URL that you specify in the Base URL or Web Interface (NFuse)
URL field of the resource profile.
b.
In the Post URL field, specify the absolute URL where the application posts
the user’s credentials, such as: http://yourcompany.com/login.cgi. You can
determine the appropriate URL using a TCP dump or by viewing the
application’s sign-in page source and searching for the POST parameter in
the FORM tag.
c.
Optionally specify the user data you want to post and user modification
permissions.
To specify user data to post, enter data in the following fields and click
Add:

Label—The label that appears on a user’s Preferences page in the IVE.
This field is required if you either enable or require users to modify
data to post to back-end applications.

Name—The name to identify the data of the Value field. (The back-end
application should expect this name.)
Defining Resource Profiles: Custom Web Applications  403
Juniper Networks Secure Access Administration Guide

Value—The value to post to the form for the specified Name. You can
enter static data, a system variable (see “System Variables and
Examples” on page 1018 for a list of valid variables), or IVE session
variables containing username and password values (see “Multiple
Sign-In Credentials Overview” on page 237 for more information).

User modifiable? setting—Set to Not modifiable if you do not want
the user to be able to change the information in the Value field. Set to
User CAN change value if you want the user to have the option of
specifying data for a back-end application. Set to User MUST change
value if users must enter additional data in order to access a back-end
application. If you choose either of the latter settings, a field for data
entry appears on the user’s Advanced Preferences page in the IVE.
This field is labeled using the data you enter in the User label field. If
you enter a value in the Value field, this data appears in the field but is
editable.
d. Select the Deny direct login for this resource checkbox if you do not want
allow users to manually enter their credentials in a sign-in page. (Users
may see a sign-in page if the form POST fails.)
e.
Select the Allow multiple POSTs to this resource checkbox if you want
the IVE to send POST and cookie values to the resource multiple times if
required. If you do not select this option, the IVE does not attempt single
sign-on when a user requests the same resource more than once during the
same session.
3. If you want to post header data to the specified URL when a user makes a
request to a resource specified in the Resource field, select the Send the
following data as request headers checkbox. Then:
a.
In the Resource section, specify the resources to which this policy applies.
See “Defining Web Resources” on page 399 for more information.
b.
Optionally specify the header data to post by entering data in the following
fields and clicking Add:

Header name—The text for the IVE to send as header data.

Value—The value for the specified header.
4. Click Save Changes.
Defining a Caching Autopolicy
Caching policies control which Web content the IVE caches on a user’s machine.
NOTE: For information about configuring advanced caching options not available
through resource profiles, including specifying the maximum allowable image size
for cached content, see “Defining Resource Policies: Caching” on page 438. For
information about recommended caching settings for OWA and Lotus Notes
applications, see “Creating OWA and Lotus Notes Caching Resource Policies” on
page 441.
404

Defining Resource Profiles: Custom Web Applications
Chapter 20: Web Rewriting
To create a Web caching autopolicy:
1. Create a custom Web application resource profile, as explained in the following
sections:

“Defining Resource Profiles: Custom Web Applications” on page 397

“Defining Role Settings: Web URLs” on page 416
2. If available, click the Show ALL autopolicy types to display the autopolicy
configuration options.
3. Select the Autopolicy: Caching checkbox.
4. In the Resource field, specify the resources to which this policy applies. For
detailed guidelines, see “Defining Web Resources” on page 399.
5. In the Action field, select one of the following options:

Smart—Select this option to allow the IVE to send a cache-control:no-store
header or a cache-control:no-cache header based on the user’s Web browser
and content type.
When you select this option, the IVE makes media files and zip files work
properly by removing their origin server's cache-control headers. For
example, the following logic searches for “msie” or “windows-media-player”
in user-agent headers in order to remove cache or cache-control:no-store
response headers and make the files cacheable:
(if content type has "audio/x-pn-realaudio" OR
if content type begins with "video/" OR
if content type begins with "audio/" OR
if content type is "application/octet-stream" and the file extension begins
with "rm" or "ram"
)
If the IVE finds “msie” or “windows-media-player” in the user-agent header
and any of the following apply:

Request is for Flash, .xls, .pps, .ppt files

Content-type is application/, text/rtf, text/xml, model/

Origin server sends a content-disposition header
then IVE sends the cache-control:no-store header and removes the origin
server's cache-control header.
Defining Resource Profiles: Custom Web Applications  405
Juniper Networks Secure Access Administration Guide
In all other cases, the IVE adds the pragma:no-cache or cache-control:nostore response headers.
NOTE: Citrix .ica and QuickPlace files get some special treatment. Citrix .ica files
get cache-control:private only when smart caching is enabled. QuickPlace files that
do not match a specified rule files (which takes precedence) get CCNS and cachecontrol:private.
Also note that if you select this option, enable GZIP compression, and try to access
a text file attachment using Domino Web Access 6.5 through Internet Explorer,
you cannot open the attachment. To enable text attachments, you must either
install the Internet Explorer 323308 patch or enable the No Store option.

No-Store—Select this option to deliver attachments to Internet Explorer
without saving them to the disk. (The browser temporarily writes files to
the disk, but immediately removes them once it has opened the file in the
browser.) When you select this option, the IVE removes the origin server's
cache-control header and adds a cache-control:no-store response header if
the user-agent string sent by the browser contains “msie” or “windowsmedia-player.”
This option might slow browsing by causing repeated content fetches,
which can cause performance issues on very slow connections.

No-Cache—Select this option to prevent the user’s browser from caching
files to the disk. When you select this option, the IVE adds the standard
HTTP pragma:no-cache header and cache-control:no-cache (CCNC) header
(HTTP 1.1) to response files. Also, the IVE does not forward the origin
server's caching headers, such as age, date, etag, last-modified, expires.
NOTE: When no-cache headers are present on certain types of attachments (PDF,
PPT, streaming files), Internet Explorer does not properly render the documents
because the rendering process requires the browser to temporarily writes these
files to cache.

Unchanged—The IVE forwards the origin server's caching headers as is.
NOTE: When using Citrix published applications through the Web interface, the
Web interface server may send a Cache-Control:no-cache in the response header of
the .ica file. Because the caching header is not removed when using the
Unchanged setting, .ica files are not downloaded to the client PC. To resolve this,
use the Smart caching option.
6. Click Add.
7. Click Save Changes.
406

Defining Resource Profiles: Custom Web Applications
Chapter 20: Web Rewriting
Defining a Java Access Control Autopolicy
A Java access control autopolicy defines the list of servers and ports to which Java
applets can connect, as explained in “Using Code-signing Certificates” on page 755.
This autopolicy also specifies which resources the IVE signs using the code-signing
certificate that you upload to the IVE.
When you enable Java access control using this autopolicy, the IVE automatically
enables the Allow Java applets option on the Users > User Roles > Select Role >
Web > Options page of the admin console.
NOTE:

For information about configuring advanced Java options that are not
available through resource profiles, including preventing Java applets from
connecting to servers that you specify, see “Defining Resource Policies:
External Java Applets” on page 442.

For information about hosting Java applets directly on the IVE, see “Hosted
Java Applets Templates” on page 353.
To create a Java access control autopolicy:
1. Create a custom Web application resource profile, as explained in “Defining
Resource Profiles: Custom Web Applications” on page 397.
2. Click Show ALL autopolicy types.
3. Select the Autopolicy: Java Access Control checkbox.
4. In the Resource field, specify the server resources to which this policy applies
using the format: host:[ports]. (By default, the IVE populates this field with the
server specified in your resource profile’s base URL.) For more detailed
instructions, see “Defining a Server to Which Java Applets Can Connect” on
page 408.
5. Select one of the following options from the Action list:

Allow socket access—To enable Java applets to connect to the servers
(and optionally ports) in the Resource list.

Deny socket access—To prevent Java applets from connecting to the
servers (and optionally ports) in the Resource list.
6. Click Add.
7. Select the Sign applets with code-signing certificate checkbox to resign the
specified resources using the certificate uploaded through the System >
Configuration > Certificates > Code-signing Certificates page of the admin
console. (The IVE uses the imported certificate to sign the server resources that
you specify in the Resources field.)
8. Click Save Changes.
Defining Resource Profiles: Custom Web Applications  407
Juniper Networks Secure Access Administration Guide
Defining a Server to Which Java Applets Can Connect
When defining servers to which Java applets can connect, you must use the
following format:
host[:ports]
Within this format, the two components are:

Host (required)—Possible values:

DNS Hostname—For example: www.juniper.com
You may use the following special characters allowed in the hostname:
Table 24: DNS Hostname Special Characters
*
Matches ALL characters.
%
Matches any character except dot (.)
?
Matches exactly one character

IP address/Netmask—You must enter the IP address in the format: a.b.c.d.
You may use one of two formats for the netmask:

Prefix: High order bits

IP: a.b.c.d
For example: 10.11.149.2/24 or 10.11.149.2/255.255.255.0
You cannot use special characters in the IP address or netmask.

Ports—You must use the delimiter “:” when specifying a port. For example:
10.11.149.2/255.255.255.0:*
Table 25: Port Possible Values
*
Matches ALL ports; you cannot use any other special characters
port[,port]*
A comma-delimited list of single ports. Valid port numbers are [165535].
[port1]-[port2]
A range of ports, from port1 to port2, inclusive.
NOTE: You can mix port lists and port ranges, such as: 80,443,8080-8090.
408

Defining Resource Profiles: Custom Web Applications
Chapter 20: Web Rewriting
Defining a Rewriting Autopolicy
By default, the IVE intermediates all user requests to Web hosts—unless you have
configured the IVE to serve requests to certain hosts using a different mechanism,
such as the Secure Application Manager. Rewriting autopolicies enable you to “finetune” the default options by changing which mechanisms the IVE should use to
rewrite Web data and defining resources that you want to minimally rewrite or not
rewrite at all.
NOTE: For information about configuring advanced rewriting options not available
through resource profiles, including specifying ActiveX parameters that the IVE
should rewrite, see “Defining Resource Policies: Rewriting” on page 445.
To create a rewriting autopolicy:
1. Create a custom Web application resource profile, as explained in “Defining
Resource Profiles: Custom Web Applications” on page 397.
2. Click Show ALL autopolicy types.
3. Select the Autopolicy: Rewriting Options checkbox.
4. Select one of the following options:

Passthrough Proxy—Select this option to specify Web applications for
which the Content Intermediation Engine performs minimal
intermediation (as explained in “Passthrough Proxy Overview” on
page 394). For detailed configuration instructions, see “Specifying
Passthrough Proxy Autopolicy Options” on page 410.

No rewriting (use WSAM)—Select this option to intermediate content
using WSAM instead of the Content Intermediation Engine. (For
information about WSAM, see “WSAM Overview” on page 491.) Then,
specify the application server for which you want to intermediate content.
(At minimum, you need to click Add in order to intermediate content to
and from the server that the IVE extracts from the Web access control
policy.) For detailed configuration instructions, see “Specifying WSAM
Rewriting Autopolicy Options” on page 411.

No rewriting (use JSAM)—Select this option to intermediate content using
JSAM instead of the Content Intermediation Engine. (For information about
JSAM, see “JSAM Overview” on page 512.) Then, specify the application
server for which you want to intermediate content.(At minimum, you need
to click Add in order to intermediate content to and from the server that
the IVE extracts from the Web access control policy.) For detailed
configuration instructions, see “Specifying JSAM Rewriting Autopolicy
Options” on page 412.
Defining Resource Profiles: Custom Web Applications  409
Juniper Networks Secure Access Administration Guide

No rewriting—Select this option to automatically create a selective
rewriting policy for the autopolicy’s URL, thereby configuring the IVE not
intermediate any content to and from the resource. For example, you may
choose this option if you do not want the IVE to intermediate traffic from
Web sites that reside outside of the corporate network, such as yahoo.com.
If you select this option, you do not have to configure any additional
rewriting settings.
Specifying Passthrough Proxy Autopolicy Options
To configure passthrough proxy autopolicy options:
1. Create an rewriting autopolicy and select Passthrough Proxy, as explained in
“Defining a Rewriting Autopolicy” on page 409.
2. Choose the way in which you want to enable the passthrough proxy feature:

Use virtual hostname—If you choose this option, specify a host name
alias for the application server. When the IVE receives a client request for
the application server host name alias, it forwards the request to the
specified application server port in the Base URL field.

Use IVE port—If you choose this option, specify a unique IVE port in the
range 11000-11099. The IVE listens for client requests to the application
server on the specified IVE port and forwards any requests to the
application server port specified in the Base URL field.
NOTE:

The corresponding URL for the resource profile must specify the application
server host name and the port used to access the application internally. You
cannot enter a path for the base URL.

In order to make Sharepoint work successfully through the IVE, you must
select the Override automatic cookie handling checkbox in Internet
Explorer under Tools Internet options > Privacy > Advanced Privacy
Settings if the following conditions true:

You select the Use virtual hostname option during Pass Through Proxy
configuration.

The virtual hostname that you specify in your Sharepoint configuration is
different from the hostname that you configure through IVE setup (that is,
if the domains are different).

You enable persistent cookies through the Users > User Roles > Select
Role > General > Session Options page of the admin console.
3. Select the Rewrite XML checkbox if you want the IVE to rewrite URLs
contained within XML content. If this option is disabled, the IVE passes the
XML content “as is” to the server.
410

Defining Resource Profiles: Custom Web Applications
Chapter 20: Web Rewriting
4. Select the Rewrite external links checkbox if you want the IVE to rewrite all
the URLs presented to the proxy. If this option is disabled, the IVE rewrites only
those URLs where the hostname is configured as part of the passthrough proxy
policy.
5. Select the Block cookies from being sent to the browser checkbox if you
want the IVE to block cookies destined for the client’s browser. The IVE stores
the cookies locally and sends them to applications whenever they are
requested.
6. Select the Host-Header forwarding checkbox if you want the IVE to pass the
hostname as part of the host header instead of the actual host identifier.
NOTE: The Host-Header forwarding option is only valid in passthrough proxy
Virtual hostname mode.
7. Click Save Changes.
8. If you select:

Use virtual hostname, you must also:
i.
Add an entry for each application server host name alias in your
external DNS that resolves to the IVE.
ii.
Upload a wildcard server certificate to the IVE (recommended). For
more information about wildcard certificates, see “Associating a
Certificate With a Virtual Port” on page 736.
iii. Define the IVE name and host name in the Network Identity section of
the System > Network > Internal Port tab.

Use IVE port, you must also open traffic to the IVE port you specified for
the application server in your corporate firewall.
NOTE: If your application listens on multiple ports, configure each application port
as a separate passthrough proxy entry with a separate IVE port. If you intend to
access the server using different host names or IP addresses, configure each of
those options separately; in this case, you can use the same IVE port.
Specifying WSAM Rewriting Autopolicy Options
To configure WSAM rewriting autopolicy options:
1. Create an rewriting autopolicy and select No rewriting (use WSAM), as
explained in “Defining a Rewriting Autopolicy” on page 409.
2. In the Destination field, specify resources for which WSAM secures
client/server traffic between the client and the IVE. By default, the IVE extracts
the correct server from the Web access control policy. You may choose to use
this server as-is, modify it, and/or add new servers to the list.
Defining Resource Profiles: Custom Web Applications  411
Juniper Networks Secure Access Administration Guide
When specifying a server, specify the host name (the wild cards '*' or '?' are
accepted) or an IP/netmask pair. Specify multiple ports for a host as separate
entries.
3. Click Add.
4. Click Save Changes.
When you intermediation through WSAM using this autopolicy, the IVE
automatically enables the Secure Application Manager option on the Users >
User Roles > Select Role > General > Overview page of the admin console.
Specifying JSAM Rewriting Autopolicy Options
To configure JSAM rewriting autopolicy options:
1. Create an rewriting autopolicy and select No rewriting (use JSAM), as
explained in “Defining a Rewriting Autopolicy” on page 409.
2. In the Server Name field, enter the DNS name of the application server or the
server IP address.
3. In the Server Port field, enter the port on which the remote server listens for
client connections.
For example, to forward Telnet traffic from a remote machine, specify port 23
for both the client port (on which JSAM listens) and the server port (on which
the Telnet server listens).
NOTE: To enable drive mapping to this resource, enter 139 as the server port.
4. In the Client Loopback IP field, provide a static loopback address. If you do not
provide a static IP loopback address, the IVE assigns an IP loopback address
dynamically. For more information about static loopback addresses, see “JSAM
Overview” on page 512.
5. In the Client Port field, enter the port on which JSAM should listen for client
application connections.
Typically, the local port value is the same value as the server port; the local port
value usually only differs for Linux or Macintosh users who want to add
applications for port forwarding that use ports under 1024.
NOTE: To enable drive mapping to this resource, enter 139 as the server port.
You may configure more than one application on a single port, such as
app1.mycompany.com, app2.mycompany.com, app3.mycompany.com. Either you
assign a static loopback address or the IVE assigns a dynamic loopback address
(127.0.1.10, 127.0.1.11, 127.0.1.12) to each application. JSAM then listens on
these multiple loopback addresses on the specified port. For example, when
there is traffic on 127.0.1.12 on the specified port, the IVE forwards the traffic
to the app3.mycompany.com destination host.
412

Defining Resource Profiles: Custom Web Applications
Chapter 20: Web Rewriting
6. Select Launch JSAM to automatically start JSAM when the IVE encounters the
Base URL.
7. Click Add.
8. Click Save Application or Save + New.
Defining a Web Compression Autopolicy
Web compression autopolicies specify which types of Web data the IVE should and
should not compress. For example, since javascript does not work when
compressed, you might use this feature to specify that the IVE should not compress
javascript data going to and from an email server by entering the following
resource: http://owa.juniper.net/*.js. For more information about how the IVE
compresses data, see “Compression” on page 995.
NOTE: In order to properly compress data, you must enable compression at the
system level as well as creating compression autopolicies. To enable compression,
use settings in the Maintenance > System > Options page of the admin
console. For instructions, see “Enabling Compression at the System Level” on
page 997.
To create a Web compression autopolicy:
1. Create a custom Web application resource profile, as explained in the following
sections:

“Defining Resource Profiles: Custom Web Applications” on page 397

“Defining Role Settings: Web URLs” on page 416
2. If available, click the Show ALL autopolicy types button to display the
autopolicy configuration options.
3. Select the Autopolicy: Web compression checkbox.
4. In the Resource field, specify the resources to which this policy applies. For
detailed guidelines, see “Defining Web Resources” on page 399.
5. Select one of the following options from the Action list:

Compress—The IVE compresses the supported content types from the
specified resource.

Do not compress—The IVE does not compress the supported content
types from the specified resource.
6. Click Add.
7. Click Save Changes.
Defining Resource Profiles: Custom Web Applications  413
Juniper Networks Secure Access Administration Guide
Defining a Web Bookmark
When you create a Web resource profile, the IVE automatically creates a bookmark
that links to the primary URL or domain that you specified in the resource profile.
The IVE enables you to modify this bookmark as well as create additional
bookmarks within the same domain.
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 IVE 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:

“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.
NOTE: When configuring bookmarks, note that:

You can only assign bookmarks to roles that you have already associated with
the resource profile—not all of the roles defined on the IVE. To change the list
of roles associated with the resource profile, use settings in its Roles tab.

Bookmarks simply control which links the IVE 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.

You cannot create bookmarks that link to additional URLs and domains
defined through Web access control autopolicies.
For more information about resource profile bookmarks, see “Defining Bookmarks”
on page 110.
To configure Web resource profile bookmarks:
414

Defining Resource Profiles: Custom Web Applications
Chapter 20: Web Rewriting
1. If you want to create a resource profile bookmark through the standard
resource profiles page:
a.
Navigate to the Users > Resource Profiles > Web > Select Resource
Profile > Bookmarks page in the admin console.
b.
Click the appropriate link in the Bookmark column if you want to modify
an existing bookmark. Or, click New Bookmark to create an additional
bookmark.
Alternatively, if you want to create a resource profile bookmark through the
user roles page:
a.
Navigate to the Users > User Roles > Select Role > Web > Bookmarks
page in the admin console.
b.
Click New Bookmark.
c.
From the Type list, choose Pick a Web Resource Profile. (The IVE does not
display this option if you have not already created a Web resource profile.)
d. Select an existing resource profile.
e.
Click OK. (If you have not already associated the selected role with the
resource profile, the IVE automatically makes the association for you. The
IVE also enables any access control policies for the role that are required by
the resource profile.)
f.
If this role is not already associated with the selected resource profile, the
IVE displays an informational message. If you see this message, click Save
Changes to add this role to the resource profile’s list of roles and to update
the profile’s autopolicies as required. Then, repeat the previous steps to
create the bookmark.
NOTE: When you create a resource profile bookmark through the user roles page
(instead of the standard resource profiles page), the IVE only associates the
generated bookmark with the selected role. The IVE does not assign the
bookmark to all of the roles associated with the selected resource profile.
2. Optionally change the name and description of the bookmark. (By default, the
IVE populates names the bookmark using the resource profile name.)
3. In the URL field, add a suffix to the URL if you want to create links to subsections of the domain defined in the primary resource profile. For information
about system variables and attributes that you can include in the bookmark,
see “Using System Variables in Realms, Roles, and Resource Policies” on
page 1027.
NOTE: Make sure to enter a unique URL in this field. If you create two bookmarks
with the same URL, the IVE deletes one of the bookmarks from the end-user view.
You will still be able to see both bookmarks, however, in the administrator
console.
Defining Resource Profiles: Custom Web Applications  415
Juniper Networks Secure Access Administration Guide
4. Under Options, select the Bookmark opens in new window checkbox if want
to enable the IVE to automatically open the Web resource in a new browser
window. Next, select:

Do not display browser address bar—Select this option to remove the
address bar from the browser window. This feature forces all Web traffic
through the IVE by precluding users in the specified role from typing a new
URL in the address bar, which circumvents the IVE.

Do not display browser toolbar—Select this option to remove the menu
and toolbar from the browser. This feature removes all menus, browsing
buttons, and bookmarks from the browser window so that the user
browses only through the IVE.
5. If you are configuring the bookmark through the resource profile pages, under
Roles, specify the roles to which you want to display the bookmark:

ALL selected roles—Select this option to display the bookmark to all of the
roles associated with the resource profile.

Subset of selected roles—Select this option to display the bookmark to a
subset of the roles associated with the resource profile. Then select roles
from the ALL Selected Roles list and click Add to move them to the Subset
of selected roles list.
6. Click Save Changes.
Defining Role Settings: Web URLs
You can use two different methods to create Web bookmarks:

Create bookmarks through existing resource profiles (recommended)—
When you select this method, the IVE automatically populates the bookmark
with key parameters (such as the Web interface (NFuse) URL) using settings
from the resource profile. Additionally, while you are creating the associated
resource profile, the IVE guides you through the process of creating any
required policies to enable access to the bookmark. For configuration
instructions, see “Creating Bookmarks Through Existing Resource Profiles” on
page 417.

Create standard bookmarks—When you select this option, you must manually
enter all bookmark parameters during configuration. Additionally, you must
enable access to the Web feature and create resource policies that enable
access to the Web sites defined in the bookmark (as explained in “Task
summary: Configuring the Web Rewriting Feature” on page 390). For
configuration instructions, see “Creating Standard Web Bookmarks” on
page 418.
This section contains information about configuring bookmarks using both of these
methods. This section also contains information about defining general role-level
settings for the Web rewriting feature. For configuration instructions, see
“Specifying General Web Browsing Options” on page 419.
416

Defining Role Settings: Web URLs
Chapter 20: Web Rewriting
Creating Bookmarks Through Existing Resource Profiles
To associate a bookmark with an existing resource profile:
1. Navigate to the Users > User Roles > Select Role > Web > Bookmarks page
of the admin console.
2. Click New Bookmark.
3. From the Type list, choose Pick a Web Resource Profile.
NOTE: The IVE does not display this option if have not already created a Web
resource profile.
4. Select an existing resource profile.
5. Click OK. (If you have not already associated the selected role with the resource
profile, the IVE automatically makes the association for you.)
6. Optionally change the name and description of the bookmark. (By default, the
IVE populates names the bookmark using the resource profile name.)
7. In the URL field, add a suffix to the URL if you want to create links to subsections of the domain defined in the primary resource profile. For information
about system variables and attributes that you can include in the bookmark,
see “Using System Variables in Realms, Roles, and Resource Policies” on
page 1027.
NOTE: Make sure to enter a unique URL in this field. If you create two bookmarks
with the same URL, the IVE deletes one of the bookmarks from the end-user view.
You will still be able to see both bookmarks, however, in the administrator
console.
8. Under Options, select the Bookmark opens in new window checkbox if want
to enable the IVE to automatically open the Web resource in a new browser
window. Next, select:

Do not display browser address bar—Select this option to remove the
address bar from the browser window. This feature forces all Web traffic
through the IVE by precluding users in the specified role from typing a new
URL in the address bar, which circumvents the IVE.

Do not display browser toolbar—Select this option to remove the menu
and toolbar from the browser. This feature removes all menus, browsing
buttons, and bookmarks from the browser window so that the user
browses only through the IVE.
9. Click Save Changes or Save + New to add another.
Defining Role Settings: Web URLs

417
Juniper Networks Secure Access Administration Guide
Creating Standard Web Bookmarks
NOTE: Information in this section is provided for backwards compatibility. We
recommend that you configure access to Web URLs and servers through resource
profiles instead, since they provide a simpler, more unified configuration method.
For more information, see “Defining Resource Profiles: Custom Web Applications”
on page 397 and “Defining Role Settings: Web URLs” on page 416.
Use the Bookmarks tab to create bookmarks that appear on the welcome page for
users mapped to this role. You can create two types of bookmarks through this
page:

Web URL bookmarks—These bookmarks link the user to Web URLs on the
World Wide Web or on your corporate Intranet. When you create Web
bookmarks, you can insert the user’s IVE username in the URL path to provide
single sign-on access to back-end Web applications. For Web bookmark
configuration instructions, see the instructions that follow.

Java applet bookmarks—These bookmarks link the user to a Java applets that
you upload to the IVE through the Users > Resource Profiles > Web >
Hosted Java Applets page of the admin console. For Java applet bookmark
configuration instructions, see “Defining Resource Profiles: Hosted Java
Applets” on page 358.
When you create either of these bookmark types, the corresponding links appear
on the welcome page for users mapped to this role.
To create a bookmark to a Web resource:
1. In the admin console, choose Users > User Roles > Role > Web >
Bookmarks.
2. Click New Bookmark.
3. Select Standard.
4. Enter a name and description for the bookmark (optional). This information
displays on the IVE home page instead of the URL.
5. Enter the URL to bookmark. If you want to insert the user’s username, enter
<username> at the appropriate place in the URL. For information about
additional system variables and attributes that you can include in the
bookmark, see “Using System Variables in Realms, Roles, and Resource
Policies” on page 1027.
NOTE: Make sure to enter a unique URL in this field. If you create two bookmarks
with the same URL, the IVE deletes one of the bookmarks from the end-user view.
You will still be able to see both bookmarks, however, in the administrator
console.
418

Defining Role Settings: Web URLs
Chapter 20: Web Rewriting
6. Under Auto-allow, click Auto-allow Bookmark to enable the IVE to
automatically create a corresponding Web access resource policy. Note that
this functionality applies only to role bookmarks and not bookmarks created by
users. Next, select:“Defining Role Settings: Web URLs” on page 416

Only this URL to allow users to access only the URL.

Everything under this URL to allow the user to access any path under the
URL.
NOTE: You may not see the Auto-allow option if you are using a new installation
or if an administrator hides the option. For more information on this option, see
“Setting System Options” on page 704.
7. Under Display options, click Open bookmark in a new window to enable the
IVE to automatically open the Web resource in a new browser window. Note
that this functionality applies only to role bookmarks and not bookmarks
created by users. Next, select:

Do not display the URL address bar if you want to remove the address
bar from the browser window. This feature forces all Web traffic through
the IVE by precluding users in the specified role from typing a new URL in
the address bar, which circumvents the IVE.

Do not display the menu and the toolbar to remove the menu and
toolbar from the browser. This feature removes all menus, browsing
buttons, and bookmarks from the browser window so that the user
browses only through the IVE.
8. Click Save Changes or Save + New to add another.
Specifying General Web Browsing Options
The IVE enables you to configure a wide-variety of Web browsing options for a user
role. This section includes instructions for configuring basic Web browsing options
and advanced Web browsing options.
Configuring Basic Web Browsing Options
To configure basic Web browsing options for a role:
1. In the admin console, choose Users > User Roles > RoleName > Web >
Options.
2. Select User can type URLs in IVE browse bar if you want to enable users to
enter URLs on the welcome page and browse to Internet sites.
3. Select User can add bookmarks if you want to enable users to create personal
Web bookmarks on the IVE welcome page.
4. Select Mask hostnames while browsing if you want the IVE to obscure the
target resources in the URLs to which users browse. When you select this
option, the IVE masks IP addresses and host names in the user’s:
Defining Role Settings: Web URLs

419
Juniper Networks Secure Access Administration Guide

Web browser address bar (when the user navigates to a page)

Web browser status bar (when a user hovers over a hyperlink)

HTML source files (when the user chooses to View Source)
The host name encoding feature (also called host name obfuscation or URL
obfuscation) prevents casual observers from noting the URL of an internal
resource by obscuring the target server within the URL without masking the full
path name, target file, or port number. For example, if a user navigates to
www.msn.com without selective rewriting or host name encoding enabled, the
IVE displays an un-obscured URL in his Web browser’s address bar:
http://www.msn.com/
If you then enable selective rewriting, the IVE might display the following URL:
https://mycompanyserver.com/,DanaInfo=www.msn.com,SSO=U+
If you then enable host name encoding, and the same user navigates to the
same site, he sees a URL in which the host name (www.msn.com) is obscured:
https://i5.asglab.juniper.net/,DanaInfo=.awxyCqxtGkxw,SSO=U+
Host name encoding uses a lightweight reversible algorithm so that users can
bookmark encoded URLs. (The IVE can translate the encoded URL and resolve
it back to the original URL.) For compatibility, previously created bookmarks to
unmasked URLs continue to work when host name encoding is enabled.
NOTE:

If you enable selective rewriting and host name encoding, the IVE only
obscures the host names and IP addresses of those servers that you have
chosen to rewrite using the selective rewrite feature.

Links not rewritten by the IVE are not obscured. For example, the rewriter
does not intermediate ftp, rtsp, mms and mailto links and therefore the host
names in these links are not masked. This is required to pass security audits.

If you enable the framed toolbar and host name encoding, the IVE does not
obscure host names that the user enters in the framed toolbar’s browse field.

The IVE does not obscure host names and IP addresses in log entries,
including host name encoding log entries.
5. Click Save Changes.
Configuring Advanced Web Browsing Options
To configure advanced Web browsing options for a role:
1. In the admin console, choose Users > User Roles > RoleName > Web >
Options.
420

Defining Role Settings: Web URLs
Chapter 20: Web Rewriting
2. Select the View advanced options checkbox.
3. Select Allow Java applets if you want to enable users to browse to Web pages
containing client-side Java applets. The IVE server appears to the application
server as a browser over SSL. The IVE transparently handles any HTTP requests
and TCP connections initiated by a Java applet and handles signed Java applets.
If you enable this feature, users can launch Java applets and run applications
that are implemented as client-side Java applets, such as the Virtual Computing
(VNC) Java client, Citrix NFuse Java client, WRQ Reflections Web client, and
Lotus WebMail. For more information, see “Defining a Java Access Control
Autopolicy” on page 407.
4. Select Allow Flash content to enable the IVE to intermediate Flash content
through its Content Intermediation Engine. Note that IVE provides limited
support for ActionScript 2.0 and Flash Remoting, and does not support
XMLSocket connections.
5. Select Persistent cookies to enable users to customize their browsing
experiences by enabling them to keep persistent cookies. By default, the IVE
flushes Web cookies that are stored during a user session. A user can delete
cookies through the Advanced Preferences page if you enable this option.
6. Select Unrewritten pages open in new window to configure the IVE to open
content in a new browser window when a user access a un-rewritten Web
page. Opening content in a new windows can help remind users that they still
have a secure session. When a user request is made to a resource to which this
option applies, the IVE displays a page that contains a link to the requested
resource and directs the users to click on the link. This link opens the resource
in a new browser window and the page from which the request originates
continues to display in the IVE.
If you un-check this box, users might not realize that their IVE session is still
active and that to return to the IVE, they need to use the browser’s Back
button. Users must return to the IVE to sign out. If they simply close the
browser window, their sessions remain active until the session time limit
expires.
7. Select Allow browsing untrusted SSL Web servers to enable users to access
untrusted Web sites through the IVE. Untrusted Web sites are those whose
server certificates are not installed through the System > Configuration >
Certificates > Trusted Servers CAs tab of the admin console. For more
information, see “Using Trusted Server CAs” on page 753.
NOTE: If a web page has internal references to files within a SCRIPT tag and these
files are hosted on different HTTPS servers that have SSL certificates not trusted
by the IVE, the web page does not render correctly. In these cases, the Warn
users about the certificate problems option must be disabled.
Defining Role Settings: Web URLs

421
Juniper Networks Secure Access Administration Guide
If you enable this option, you can specify what choices the IVE gives users
when they navigate to an untrusted Web site:

Warn users about the certificate problems—If enabled, the IVE displays a
warning to the user when he first accesses an untrusted Web site telling
him why the site’s certificate is untrusted and allowing him to either
continue or cancel. If the user chooses to continue after the IVE displays a
warning, the IVE does not display any more warnings for that site during
the current IVE session.
NOTE: If you select the Warn users about the certificate problems option and the
user accesses non-HTML content (such as images, js, and css) served from a
different SSL server than the HTML page, the page containing the links may not
display correctly. You can avoid this problem either by deselecting this option or
by uploading a valid production SSL certificate on the servers that serve the nonHTML content.

Allow users to bypass warnings on a server-by-server basis—If enabled,
the IVE allows the user to suppress all further warnings for an untrusted
Web site. If a user chooses this option, he never sees a warning for this site
again, provided that he accesses it from the current IVE or cluster.
NOTE: If you choose to allow users to access untrusted Web sites without seeing a
warning, the IVE still logs a message to the user access log whenever a user
navigates to an untrusted site. Also note that if a user chooses to suppress
warnings, he can clear the persistent settings of the untrusted Web sites using the
Delete Passwords option in the System > Preferences > Advanced tab in the
end user console.
8. Select Rewrite file:// URLs to configure the IVE to rewrite file:// URLs so that
they are routed through the IVE’s file browsing CGI.
9. Select Rewrite links in PDF files to configure the IVE to rewrite hyperlinks in
PDFs.
10. Under HTTP Connection Timeout, accept the default value or set the duration
to tell the IVE how long to wait for a response from an HTTP server before
timing out and closing the connection. Use values from 30 to 1800 seconds.
NOTE: Higher timeout values might exhaust IVE resources if applications do not
close connections properly or take too long to close the connections. Unless an
application requires a higher timeout value, we recommend accepting the default
value.
11. Click Save Changes.
422

Defining Role Settings: Web URLs
Chapter 20: Web Rewriting
Defining Resource Policies: Overview
When you enable the Web access feature for a role, you need to create resource
policies that specify which resources a user can access, whether or not the IVE
needs to rewrite the content requested by the user, and caching, applet, or single
sign-on requirements. For every Web request, the IVE first evaluates the rewriting
policies you configure1. If the user’s request is to a resource specified as “don’t
rewrite” due to either a selective rewriting or passthrough proxy resource policy,
then the IVE forwards the user’s request to the appropriate back-end resource.
Otherwise, the IVE continues to evaluate those resource policies corresponding to
the request, such as Java resource policies for a request to fetch a Java applet. After
matching a user’s request to a resource listed in a relevant policy, the IVE performs
the action specified for the resource.
You can create resource policies through the standard interface (as described in this
section) or through resource profiles (recommended method).
When writing a Web resource policy, you need to supply key information:

Resources—A resource policy must specify one or more resources to which the
policy applies. When writing a Web policy, you need to specify Web servers or
specific URLs, as explained in the section that follows.

Roles—A resource policy must specify the roles to which it applies. When a
user makes a request, the IVE determines what policies apply to the role and
then evaluates those policies that correspond to the request.

Actions—Each type of resource policy performs a certain action, which is either
to allow or deny a resource or to perform or not perform some function, such
as rewrite content, re-sign an applet, or post Web data. You can also write
detailed rules that apply more conditions to a user request. See “Writing a
Detailed Rule” on page 126.
The IVE platform’s engine that evaluates resource policies requires that the
resources listed in a policy’s Resources list follow a canonical format, as explained
in “Specifying Resources for a Resource Policy” on page 121.
This section outlines special considerations you must consider when specifying a
Web resource using the canonical format.
Canonical Format:
[protocol://]host[:ports][/path]
The four components are:

Protocol (optional)—Possible values: http and https (case-insensitive)
If the protocol is missing, then both http and https are assumed. If a protocol is
specified, then the delimiter “://” is required. No special characters are
allowed.
1. If you do not configure “rewriting” resource policies, then the IVE continues the evaluation process using the
policies that apply to the user request.
Defining Resource Policies: Overview

423
Juniper Networks Secure Access Administration Guide

Host (required)—Possible values:

DNS Hostname—For example: www.juniper.com
Special characters allowed are described in the following table:
Table 26: DNS Hostname Special Characters
*
Matches ALL characters
%
Matches any character except dot (.)
?
Matches exactly one character

IP address/Netmask—The IP address needs to be in the format: a.b.c.d
The netmask can 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.

Ports—You must specify a port when specifying IP/netmask as a resource. The
port is optional when specifying a DNS host name. If a port is specified, then
the delimiter “:” is required. For example: 10.11.149.2/255.255.255.0:*
Table 27: 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 [165535].
[port1]-[port2]
A range of ports, from port1 to port2, inclusive.
NOTE: You can mix port lists and port ranges, such as: 80,443,8080-8090
If the port is missing, then the default port 80 is assigned for http, 443 for https.

424

Path (optional)—If the path is missing, then star (*) is assumed, meaning ALL
paths match. If a path is specified, then the delimiter “/” is required. No other
special characters are supported. For example:

http://www.juniper.com:80/*

https://www.juniper.com:443/intranet/*

*.yahoo.com:80,443/*

%.danastreet.net:80/share/users/<username>/*
Defining Resource Policies: Overview
Chapter 20: Web Rewriting
Defining Resource Policies: Web Access
Web access resource policies control which Web resources users can access in
order to connect to the Internet, intranet, or extranet. You can deny or allow access
to Web resources by URL or IP range. For URLs, you can use the “*” and “?”
wildcards to efficiently specify multiple host names and paths. For resources that
you specify by host name, you can also choose either HTTP, HTTPS, or both
protocols.
To write a Web Access resource policy:
1. In the admin console, choose Users > Resource Policies > Web > Web ACL.
2. On the Web Access Policies page, click New Policy.
3. On the New Policy page, enter:
a.
A name to label this policy.
b.
A description of the policy (optional).
4. In the Resources section, specify the resources to which this policy applies. See
“Specifying Resources for a Resource Policy” on page 121 for more
informatio