Juniper Networks Secure Access Administration Guide 8 5.5 IVEAdmin
User Manual: 8
Open the PDF directly: View PDF .
Page Count: 918
Download | |
Open PDF In Browser | View PDF |
Juniper Networks Secure Access Administration Guide Release 5.5 Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408-745-2000 www.juniper.net Part Number: 55A031207 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 © 2006, Juniper Networks, Inc. All rights reserved. Printed in USA. Juniper Networks Secure Access Administration Guide, Release 5.5 Writers: Paul Battaglia, Gary Beichler, Claudette Hobbart, Mark Smallwood Editor: Claudette Hobbart 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 23 What is the IVE?............................................................................................. 23 What can I do with the IVE?........................................................................... 25 Can I use the IVE to secure traffic to all of my company’s applications, servers, and Web pages?................................................................... 25 Can I use my existing servers to authenticate IVE users? ......................... 27 Can I fine-tune access to the IVE and the resources it intermediates?...... 27 Can I create a seamless integration between the IVE and the resources it intermediates? .................................................................................. 28 Can I use the IVE to protect against infected computers and other security concerns?.......................................................................................... 29 Can I ensure redundancy in my IVE environment?.................................. 29 Can I make the IVE interface match my company’s look-and-feel?.......... 29 Table of Contents vii Juniper Networks Secure Access Administration Guide Can I enable users on a variety of computers and devices to use the IVE?... 30 Can I provide secure access for my international users? .......................... 30 How do I start configuring the IVE?................................................................ 31 Part 2 Access management framework Chapter 3 General access management 35 Licensing: Access management availability....................................................35 Policies, rules & restrictions, and conditions overview ................................... 35 Accessing authentication realms.............................................................. 36 Accessing user roles ................................................................................ 37 Accessing resource policies...................................................................... 37 Policies, rules & restrictions, and conditions evaluation ................................. 38 Dynamic policy evaluation ............................................................................. 40 Understanding dynamic policy evaluation ............................................... 40 Understanding standard policy evaluation ............................................... 41 Enabling dynamic policy evaluation ........................................................ 42 Configuring security requirements .................................................................42 Specifying source IP access restrictions ................................................... 43 Specifying browser access restrictions..................................................... 44 Specifying certificate access restrictions .................................................. 47 Specifying password access restrictions................................................... 48 Specifying Host Checker access restrictions............................................. 49 Specifying Cache Cleaner access restrictions ........................................... 49 Specifying limits restrictions.................................................................... 49 Chapter 4 User roles 51 Licensing: User roles availability .................................................................... 52 User role evaluation ....................................................................................... 52 Permissive merge guidelines ................................................................... 53 Configuring user roles .................................................................................... 54 Configuring general role options.............................................................. 55 Configuring role restrictions .................................................................... 56 Specifying role-based source IP aliases ....................................................57 Specifying session options ....................................................................... 57 Specifying customized UI settings............................................................ 60 Defining default options for user roles ..................................................... 64 Customizing user roles UI views..................................................................... 66 Chapter 5 Resource profiles 71 Licensing: Resource profile availability........................................................... 72 Task summary: Configuring resource profiles ................................................ 72 Resource profile components......................................................................... 72 Defining resources................................................................................... 75 Defining autopolicies ............................................................................... 76 Defining roles .......................................................................................... 77 Defining bookmarks ................................................................................ 78 Resource profile templates............................................................................. 79 viii Table of Contents Table of Contents Chapter 6 Resource policies 81 Licensing: Resource policies availability ......................................................... 82 Resource policy components ......................................................................... 82 Specifying resources for a resource policy ............................................... 83 Resource policy evaluation............................................................................. 86 Creating detailed rules for resource policies ................................................... 87 Writing a detailed rule ............................................................................. 88 Customizing resource policy UI views ............................................................ 89 Chapter 7 Authentication and directory servers 91 Licensing: Authentication server availability................................................... 92 Task summary: Configuring authentication servers........................................ 92 Defining an authentication server instance ....................................................93 Defining an authentication server instance.............................................. 94 Modifying an existing authentication server instance .............................. 94 Configuring an anonymous server instance ................................................... 94 Anonymous server restrictions ................................................................ 95 Defining an anonymous server instance.................................................. 95 Configuring an ACE/Server instance............................................................... 96 Defining an ACE/Server instance ............................................................. 97 Generating an ACE/Agent configuration file ............................................. 98 Configuring an Active Directory or NT Domain instance ................................ 99 Defining an Active Directory or Windows NT domain server instance...100 Multi-domain user authentication ..........................................................102 Active Directory and NT group lookup support ......................................104 Configuring a certificate server instance........................................................... 105 Configuring an LDAP server instance ...........................................................106 Defining an LDAP server instance .........................................................107 Configuring LDAP search attributes for meeting creators ......................110 Monitoring and deleting active user sessions .........................................110 Enabling LDAP password management .................................................111 Configuring a local authentication server instance .......................................115 Defining a local authentication server instance......................................115 Creating user accounts on a local authentication server.........................117 Managing user accounts ........................................................................118 Delegating user administration rights to end-users ................................119 Configuring an NIS server instance ..............................................................120 Configuring a RADIUS server instance .........................................................120 User experience for RADIUS users.........................................................121 Configuring the IVE to work with a RADIUS server ................................122 Enabling RADIUS accounting.................................................................125 Configuring an eTrust SiteMinder server instance ........................................133 eTrust SiteMinder overview ...................................................................134 Configuring SiteMinder to work with the IVE .........................................138 Configuring the IVE to work with SiteMinder .........................................144 Debugging SiteMinder and IVE issues ....................................................156 Configuring a SAML Server instance.............................................................156 Using the artifact profile and the POST profile.......................................157 Creating a new SAML Server instance....................................................161 Chapter 8 Authentication realms 165 Licensing: Authentication realms availability................................................166 Creating an authentication realm .................................................................166 Table of Contents ix Juniper Networks Secure Access Administration Guide Defining authentication policies ...................................................................168 Creating role mapping rules .........................................................................169 Specifying role mapping rules for an authentication realm ....................170 Customizing user realm UI views .................................................................178 Chapter 9 Sign-in policies 181 Licensing: Sign-in policies and pages availability..........................................183 Task summary: Configuring sign-in policies .................................................183 Configuring sign-in policies ..........................................................................183 Defining user sign in policies .................................................................183 Defining meeting sign-in policies...........................................................185 Enabling and disabling sign-in policies ..................................................186 Specifying the order in which sign-in policies are evaluated ..................187 Configuring sign-in pages .............................................................................187 Configuring standard sign-in pages........................................................188 Chapter 10 Single sign-on 191 Licensing: Single sign-on availability ............................................................191 Single sign-on overview ...............................................................................191 Multiple sign-in credentials overview ...........................................................193 Task Summary: Configuring multiple authentication servers .................193 Task Summary: Enabling SSO to resources protected by basic authentication .................................................................................194 Task Summary: Enabling SSO to resources protected by NTLM.............194 Multiple sign-in credentials execution ....................................................196 Configuring SAML ........................................................................................201 Configuring SAML SSO profiles ....................................................................204 Creating an artifact profile .....................................................................204 Creating a POST profile .........................................................................208 Creating an access control policy...........................................................211 Creating a trust relationship between SAML-enabled systems ...............214 Part 3 Endpoint defense Chapter 11 Host Checker 223 Licensing: Host Checker availability .............................................................224 Task summary: Configuring Host Checker ...................................................224 Creating global Host Checker policies ..........................................................226 Enabling pre-defined client-side policies (Windows only) ......................227 Creating and configuring new client-side policies ..................................231 Enabling customized server-side policies ...............................................242 Enabling the Secure Virtual Workspace........................................................244 Secure Virtual Workspace features ........................................................245 Secure Virtual Workspace restrictions and defaults ...............................245 Configuring the Secure Virtual Workspace.............................................246 Implementing Host Checker policies ............................................................251 Executing Host Checker policies ............................................................252 Configuring Host Checker restrictions....................................................253 Remediating Host Checker policies ..............................................................255 Host Checker remediation user experience ...........................................256 x Table of Contents Table of Contents Configuring Host Checker remediation ..................................................257 Defining Host Checker pre-authentication access tunnels ............................258 Specifying Host Checker pre-authentication access tunnel definitions ...259 Specifying general Host Checker options .....................................................262 Specifying Host Checker installation options................................................264 Removing the Juniper ActiveX Control...................................................265 Using Host Checker with the GINA automatic sign-in function...............266 Automatically install Host Checker ........................................................266 Manually install Host Checker................................................................267 Using Host Checker logs...............................................................................267 Chapter 12 Cache Cleaner 269 Licensing: Cache Cleaner availability............................................................269 Setting global Cache Cleaner options ...........................................................270 Implementing Cache Cleaner options ..........................................................273 Executing Cache Cleaner .......................................................................273 Specifying Cache Cleaner restrictions ....................................................275 Specifying Cache Cleaner installation options ..............................................277 Using Cache Cleaner logs .............................................................................278 Part 4 Remote access Chapter 13 Web rewriting 281 Licensing: Web rewriting availability............................................................282 Task summary: Configuring the Web rewriting feature ................................282 Web URL rewriting overview .......................................................................283 Remote SSO overview ...........................................................................285 Passthrough-proxy overview..................................................................286 Defining resource profiles: Custom Web applications ..................................288 Defining base URLs ...............................................................................290 Defining a Web access control autopolicy..............................................290 Defining Web resources ........................................................................291 Defining a single sign-on autopolicy ......................................................292 Defining a caching autopolicy................................................................296 Defining a Java access control autopolicy ..............................................298 Defining a rewriting autopolicy..............................................................300 Defining a Web compression autopolicy................................................304 Defining a Web bookmark.....................................................................305 Defining resource profiles: Citrix Web applications......................................307 Defining resource profiles: Microsoft OWA ..................................................311 Defining resource profiles: Lotus iNotes .......................................................313 Defining resource profiles: Microsoft Sharepoint..........................................315 Defining role settings: Web URLs .................................................................316 Creating bookmarks through existing resource profiles .........................317 Creating standard Web bookmarks .......................................................317 Specifying general Web browsing options .............................................319 Defining resource policies: Overview ...........................................................322 Defining resource policies: Web access........................................................324 Defining resource policies: Single sign-on ....................................................325 Writing a Basic Authentication or NTLM Intermediation resource policy326 Table of Contents xi Juniper Networks Secure Access Administration Guide Writing a remote SSO Form POST resource policy ................................328 Writing a remote SSO Headers/Cookies resource policy ........................330 Defining resource policies: Caching..............................................................332 Writing a caching resource policy ..........................................................332 Creating OWA and Lotus Notes caching resource policies .....................335 Specifying general caching options........................................................335 Defining resource policies: External Java applets .........................................336 Writing a Java access control resource policy ........................................336 Writing a Java code signing resource policy...........................................338 Defining resource policies: Rewriting ...........................................................339 Creating a selective rewriting resource policy ........................................340 Creating a pass-through proxy resource policy ......................................342 Creating a custom header resource policy .............................................344 Creating an ActiveX parameter resource policy .....................................346 Restoring the default IVE ActiveX resource policies ...............................348 Creating rewriting filters ........................................................................349 Defining resource policies: Web compression ..............................................349 Writing a Web compression resource policy..........................................350 Defining an OWA compression resource policy.....................................351 Defining resource policies: Web proxy.........................................................351 Writing a Web proxy resource policy.....................................................351 Specifying Web proxy servers ...............................................................353 Defining resource policies: HTTP 1.1 protocol..............................................354 Defining resource policies: General options..................................................355 Managing resource policies: Customizing UI views.......................................356 Chapter 14 Hosted Java applets 357 Licensing: Hosted Java applets availability ...................................................357 Task Summary: Hosting Java applets ...........................................................357 Hosted Java applets overview.......................................................................358 Uploading Java applets to the IVE ..........................................................359 Signing uploaded Java applets ...............................................................360 Creating HTML pages that reference uploaded Java applets...................361 Accessing Java applet bookmarks ..........................................................361 Defining resource profiles: Hosted Java applets............................................362 Defining a hosted Java applet bookmark ...............................................363 Use case: Creating a Citrix JICA 8.0 Java applet bookmark...........................368 Chapter 15 File rewriting 371 Licensing: File rewriting availability .............................................................371 Defining resource profiles: File rewriting......................................................371 Defining file resources ...........................................................................373 Defining a file access control autopolicy ................................................374 Defining a file compression autopolicy ..................................................374 Defining a single sign-on autopolicy (Windows only) .............................375 Defining a file bookmark .......................................................................376 Defining role settings: Windows resources...................................................378 Creating advanced bookmarks to Windows resources...........................379 Creating Windows bookmarks that map to LDAP servers......................380 Defining general file browsing options ..................................................381 Defining resource policies: Windows file resources......................................381 Canonical format: Windows file resources.............................................382 Writing a Windows access resource policy ............................................383 xii Table of Contents Table of Contents Writing a Windows SSO resource policy................................................384 Writing a Windows compression resource policy ..................................386 Defining general file writing options ......................................................387 Defining role settings: UNIX/NFS file resources ............................................387 Creating advanced bookmarks to UNIX resources .................................388 Defining general file browsing options ..................................................389 Defining resource policies: UNIX/NFS file resources .....................................389 Canonical format: UNIX/NFS file resources............................................390 Writing UNIX/NFS resource policies.......................................................391 Writing a Unix/NFS compression resource policy ..................................392 Defining general file writing options ......................................................393 Chapter 16 Secure Application Manager 395 Licensing: Secure Application Manager availability ......................................396 Task Summary: Configuring WSAM .............................................................396 W-SAM overview..........................................................................................397 Securing client/server traffic using WSAM .............................................397 Antivirus and VPN client application compatibility ................................400 Launching Network Connect during a WSAM session ............................401 Debugging WSAM issues .......................................................................401 Defining resource profiles: WSAM................................................................401 Creating WSAM client application resource profiles...............................402 Creating WSAM destination network resource profiles ..........................403 Defining role settings: WSAM.......................................................................404 Specifying applications and servers for WSAM to secure .......................405 Specifying applications that need to bypass WSAM ...............................407 Specifying role-level WSAM options.......................................................408 Downloading WSAM applications ..........................................................410 Defining resource policies: WSAM................................................................410 Specifying application servers that users can access..............................410 Specifying resource level WSAM options ...............................................412 Using the W-SAM launcher...........................................................................413 Running scripts manually ......................................................................414 Running scripts automatically................................................................415 Task Summary: Configuring JSAM................................................................416 J-SAM overview ............................................................................................417 Using JSAM for client/server communications .......................................418 Linux and Macintosh support ................................................................426 Standard application support: MS Outlook.............................................427 Standard application support: Lotus Notes.............................................428 Standard application support: Citrix Web Interface for MetaFrame (NFuse Classic)............................................................................................430 Custom application support: Citrix published applications configured from the native client ..............................................................................431 Custom application support: Citrix secure gateways ..............................434 Defining resource profiles: JSAM ..................................................................435 Defining role settings: JSAM .........................................................................439 Specifying applications for JSAM to secure ............................................439 Specifying role level JSAM options .........................................................442 Defining resource policies: JSAM ..................................................................443 Automatically launching JSAM ...............................................................443 Specifying application servers that users can access..............................445 Specifying resource level JSAM options..................................................447 Table of Contents xiii Juniper Networks Secure Access Administration Guide Chapter 17 Telnet/SSH 449 Licensing: Telnet/SSH availability .................................................................450 Task summary: Configuring the Telnet/SSH feature .....................................450 Defining resource profiles: Telnet/SSH .........................................................450 Defining a Telnet/SSH resource profile bookmark..................................452 Defining role settings: Telnet/SSH ................................................................454 Creating advanced session bookmarks ..................................................454 Configuring general Telnet/SSH options.................................................455 Defining resource policies: Telnet/SSH .........................................................456 Writing Telnet/SSH resource policies .....................................................457 Matching IP addresses to host names ....................................................458 Chapter 18 Terminal Services 461 Licensing: Terminal Services availability ......................................................461 Task Summary: Configuring the Terminal Services feature ..........................461 Terminal Services overview .........................................................................463 Terminal Services user experience ........................................................463 Terminal Services execution ..................................................................464 Configuring Citrix to support ICA load balancing ...................................467 Comparing IVE access mechanisms for configuring Citrix .....................469 Defining resource profiles: Terminal Services .............................................470 Defining a Windows profile or Citrix profile using default ICA settings ..470 Defining a Citrix profile using a custom ICA settings .............................476 Defining role settings: Terminal Services .....................................................480 Creating advanced Terminal Services session bookmarks .....................481 Creating links from an external site to a terminal services session bookmark 485 Specifying general Terminal Services options ........................................487 Defining resource policies: Terminal Services ..............................................489 Configuring Terminal Services resource policies ....................................489 Specifying the Terminal Services resource option..................................490 Chapter 19 Secure Meeting 493 Licensing: Secure Meeting availability ..........................................................493 Task Summary: Configuring Secure Meeting ................................................494 Secure Meeting overview .............................................................................495 Scheduling meetings..............................................................................496 Sending notification emails ...................................................................497 Joining meetings....................................................................................498 Attending meetings ...............................................................................500 Conducting meetings.............................................................................500 Presenting meetings ..............................................................................501 Creating instant meetings and support meetings...................................501 Defining role settings: Secure Meeting .........................................................503 Enabling and configuring Secure Meeting ..............................................503 Permissive merge guidelines for Secure Meeting ...................................506 Specifying authentication servers that meeting creators can access ......507 Defining resource policies: Secure Meeting ..................................................508 Troubleshooting Secure Meeting ..................................................................511 Monitoring Secure Meeting ..........................................................................512 xiv Table of Contents Table of Contents Chapter 20 Email Client 513 Licensing: Email Client availability ...............................................................514 Email Client overview ..................................................................................514 Choosing an email client .......................................................................514 Working with a standards-based mail server .........................................515 Working with the Microsoft Exchange Server ........................................515 Working with Lotus Notes and the Lotus Notes Mail Server ...................517 Defining role settings: Email Client ..............................................................517 Defining resource policies: Email Client .......................................................518 Chapter 21 Network Connect 521 Licensing: Network Connect availability.......................................................523 Task Summary: Configuring Network Connect.............................................523 Network Connect overview ..........................................................................524 Network Connect execution ..................................................................525 Network Connect Connection Profiles with support for multiple DNS settings ...........................................................................................530 Provisioning your network for Network Connect ...................................531 Client-side logging .................................................................................532 Network Connect proxy support............................................................532 Network Connect Quality of Service ......................................................533 Network Connect Multicast Support.......................................................533 Defining role settings: Network Connect ......................................................534 Defining resource policies: Network Connect ...............................................536 Defining Network Connect access control policies.................................537 Defining Network Connect logging policies............................................538 Creating Network Connect connection profiles......................................539 Defining Network Connect split tunneling policies.................................544 Use case: Network Connect resource policy configuration .....................546 Defining system settings: Network Connect .................................................547 Specifying IP filters................................................................................547 Downloading the Network Connect installer..........................................548 Network Connect Installation Process Dependencies.............................549 Network Connect Un-installation Process Dependencies .......................551 Using the Network Connect Launcher (NC Launcher) ...................................552 Troubleshooting Network Connect errors.....................................................553 nc.windows.app.23792 .........................................................................553 Version conflict on downgrade ..............................................................554 Part 5 System management Chapter 22 General system management 557 Licensing: System management availability .................................................557 Task summary: Configuring management capabilities .................................558 Configuring network settings .......................................................................558 Bonding ports ........................................................................................559 Configuring general network settings ....................................................559 Configuring internal and external ports .................................................561 Configuring SFP ports............................................................................563 Configuring the Management Port .........................................................564 Table of Contents xv Juniper Networks Secure Access Administration Guide Configuring VLANs ................................................................................565 Configuring virtual ports ........................................................................566 Task Summary: Defining Subnet Destinations Based on Roles ..............568 Configuring static routes for network traffic ..........................................569 Creating ARP caches..............................................................................570 Specifying host names for the IVE to resolve locally ..............................571 Specifying IP filters................................................................................571 Using central management features.............................................................571 Modifying Central Management dashboard graphs................................572 Configuring system utilities ..........................................................................574 Reviewing system data..........................................................................574 Upgrading or downgrading the IVE .......................................................575 Setting system options ..........................................................................575 Downloading application installers ........................................................577 Configuring licensing, security, and NCP......................................................580 Entering or upgrading IVE licenses ........................................................580 Activating and deactivating emergency mode .......................................586 Setting security options .........................................................................587 Configuring NCP and JCP.......................................................................589 Installing a Juniper software service package.........................................590 Configuring and using the Management Port ...............................................591 Configuring Management Port network settings ....................................592 Adding static routes to the management route table .............................593 Assigning certificate to Management Port..............................................593 Controlling administrator sign-in access ................................................594 Signing in over the Management Port....................................................595 Setting role-mapping rules using custom expressions............................595 Troubleshooting the Management Port..................................................596 Using the Management Port on a cluster ...............................................597 Importing configurations to a system with the Management Port enabled .. 597 Chapter 23 Certificates 599 Licensing: Certificate availability ..................................................................600 Using device certificates...............................................................................600 Importing certificates into the IVE .........................................................601 Downloading a device certificate from the IVE ......................................603 Creating a certificate signing request (CSR) for a new certificate ...........604 Using intermediate server CA certificates ..............................................605 Using multiple IVE device certificates ....................................................605 Using trusted client CAs ...............................................................................607 Enabling trusted client CAs....................................................................608 Enabling client CA hierarchies ...............................................................614 Enabling CRLs .......................................................................................615 Enabling OCSP ......................................................................................619 Using trusted server CAs ..............................................................................621 Uploading trusted server CA certificates ................................................621 Renewing a trusted server CA certificate ...............................................622 Deleting a trusted server CA certificate..................................................622 Viewing trusted server CA certificate details ..........................................623 Using code-signing certificates .....................................................................623 Additional considerations for SUN JVM users.........................................625 Task Summary: Configuring the IVE to sign or re-sign java applets .......625 Importing a code-signing certificate.......................................................626 xvi Table of Contents Table of Contents Chapter 24 System archiving 627 Licensing: System archiving availability .......................................................627 Archiving IVE binary configuration files .......................................................628 Creating local backups of IVE configuration files ..........................................630 Importing and exporting IVE configuration files...........................................632 Exporting a system configuration file ....................................................632 Importing a system configuration file ....................................................633 Exporting local user accounts or resource policies .................................634 Importing local user accounts or resource policies.................................635 Importing and exporting XML configuration files .........................................635 Creating and modifying XML instances .................................................637 Referential integrity constraints.............................................................641 Mapping the XML instance to UI components .......................................642 XML import modes................................................................................643 Downloading the schema file ................................................................645 Strategies for working with XML instances ............................................646 XML Import/Export use cases ................................................................650 Importing to a system with the Management Port.................................656 Pushing configurations from one IVE to another ..........................................656 Defining the target IVEs.........................................................................657 Pushing the configuration settings .........................................................658 Chapter 25 Logging and monitoring 663 Licensing: Logging and monitoring availability.............................................663 Logging and Monitoring overview ................................................................664 Log file severity levels............................................................................665 Custom filter log files.............................................................................666 Dynamic log filters ................................................................................666 Viewing and deleting user sessions........................................................666 Configuring the Log Monitoring features ......................................................668 Configuring events, user access, admin access, IDP sensor, and NC packet logs 668 Creating, resetting, or saving a dynamic log query ................................669 Specifying which events to save in the log file .......................................670 Creating, editing, or deleting log filters ..................................................672 Creating custom filters and formats for your log files ............................672 Monitoring the IVE as an SNMP agent..........................................................673 Viewing system statistics .............................................................................679 Enabling client-side logs...............................................................................679 Enabling client-side logging and global options......................................680 Enabling client-side log uploads.............................................................681 Viewing uploaded client-side logs ..........................................................682 Viewing general status .................................................................................683 Viewing system capacity utilization .......................................................683 Specifying time range and data to display in graphs..............................684 Configuring graph appearance...............................................................684 Viewing critical system events...............................................................685 Downloading the current service package .............................................685 Editing the system date and time ..........................................................685 Monitoring active users ................................................................................686 Viewing and cancelling scheduled meetings.................................................687 Table of Contents xvii Juniper Networks Secure Access Administration Guide Chapter 26 Troubleshooting 689 Licensing: Troubleshooting availability.........................................................689 Simulating or tracking events.......................................................................690 Simulating events that cause a problem ................................................690 Tracking events using policy tracing ......................................................692 Recording sessions.......................................................................................694 Creating snapshots of the IVE system state ..................................................695 Creating TCP dump files...............................................................................696 Testing IVE network connectivity.................................................................697 Address Resolution Protocol (ARP) ........................................................697 Ping .......................................................................................................697 Traceroute .............................................................................................698 NSlookup ...............................................................................................698 Running debugging tools remotely...............................................................699 Creating debugging logs ...............................................................................699 Monitoring cluster nodes..............................................................................700 Configuring group communication monitoring on a cluster .........................701 Configuring network connectivity monitoring on a cluster ...........................702 Chapter 27 Clustering 705 Licensing: Clustering availability ..................................................................706 Task summary: Deploying a cluster .............................................................706 Creating and configuring a cluster................................................................707 Defining and initializing a cluster...........................................................708 Joining an existing cluster......................................................................710 Configuring cluster properties ......................................................................712 Deploying two nodes in an Active/Passive cluster..................................712 Deploying two or more units in an Active/Active cluster........................714 Synchronizing the cluster state ..............................................................715 Configuring cluster properties................................................................718 Managing and configuring clusters...............................................................720 Adding multiple cluster nodes ...............................................................720 Managing network settings for cluster nodes.........................................721 Upgrading clustered nodes ....................................................................721 Upgrading the cluster service package ...................................................722 Deleting a cluster...................................................................................723 Restarting or rebooting clustered nodes ................................................723 Admin console procedures ....................................................................724 Monitoring clusters ................................................................................725 Troubleshooting clusters........................................................................726 Serial console procedures.............................................................................728 Chapter 28 Delegating administrator roles 733 Licensing: Delegated administration role availability....................................734 Creating and configuring administrator roles ...............................................734 Creating administrator roles ..................................................................735 Modifying administrator roles................................................................735 Deleting administrator roles ..................................................................736 Specifying management tasks to delegate....................................................736 Delegating system management tasks...................................................737 Delegating user and role management ..................................................737 Delegating user realm management ......................................................738 Delegating administrative management ................................................739 xviii Table of Contents Table of Contents Delegating resource policy management ...............................................741 Delegating resource profile management ..............................................742 Defining general system administrator role settings ....................................743 Defining default options for administrator roles ....................................743 Managing general role settings and options ...........................................743 Specifying access management options for the role ..............................744 Specifying general session options ........................................................744 Specifying UI options.............................................................................745 Delegating access to IVS systems ..........................................................746 Chapter 29 Instant Virtual System (IVS) 747 Licensing: IVS availability.............................................................................748 Deploying an IVS .........................................................................................748 Virtualized IVE architecture ...................................................................750 Signing in to the root system or the IVS .......................................................751 Signing-in using the sign-in URL prefix ..................................................751 Signing-in over virtual ports...................................................................753 Signing-in over a VLAN interface ...........................................................754 Navigating to the IVS .............................................................................754 Determining the subscriber profile...............................................................754 IVS Configuration Worksheet.................................................................754 Administering the root system ..............................................................756 Configuring the root administrator ........................................................757 Provisioning an IVS ......................................................................................757 Understanding the provisioning process ......................................................758 Configuring sign-in ports ..............................................................................760 Configuring the external port.................................................................760 Configuring a virtual port for sign-in on the external port ......................761 Configuring a virtual port for sign-in on the internal port.......................761 Configuring a Virtual Local Area Network (VLAN).........................................762 Configuring VLANs on the virtualized IVE..............................................763 Adding static routes to the VLAN route table .........................................764 Deleting a VLAN ....................................................................................765 Loading the certificates server......................................................................766 Creating a virtual system (IVS profile) ..........................................................766 Creating a new IVS profile .....................................................................766 Signing in directly to the IVS as an IVS administrator...................................768 Configuring role-based source IP aliasing .....................................................769 Associating roles with VLANs and the source IP address........................770 Configuring virtual ports for a VLAN ......................................................770 Associating roles with source IP addresses in an IVS .............................770 Configuring policy routing rules on the IVS ..................................................771 Routing Rules ........................................................................................772 Overlapping IP address spaces ..............................................................773 Define Resource policies........................................................................773 Clustering a virtualized IVE ..........................................................................773 Configuring DNS for the IVS.........................................................................774 Accessing a DNS server on the MSP network.........................................775 Accessing a DNS server on a subscriber company intranet....................775 Configuring Network Connect for use on a virtualized IVE ...........................777 Configuring the Network Connect connection profile ............................777 Configuring Network Connect on backend routers ................................777 Configuring a centralized DHCP server ........................................................780 Configuring authentication servers...............................................................782 Table of Contents xix Juniper Networks Secure Access Administration Guide Rules governing access to authentication servers ..................................782 Configuring authentication on a RADIUS server.....................................783 Configuring authentication on Active Directory .....................................783 Delegating administrative access to IVS systems..........................................784 Accessing standalone installers ....................................................................784 Performing export and import of IVS configuration files ..............................785 Exporting and importing the root system configuration ........................785 Monitoring subscribers.................................................................................787 Suspending subscriber access to the IVS................................................787 Troubleshooting VLANs................................................................................788 Performing TCPDump on a VLAN..........................................................788 Using commands on a VLAN (Ping, traceroute, NSLookup, ARP) ...........789 IVS use cases................................................................................................789 Policy routing rules resolution use case for IVS......................................789 Configuring a global authentication server for multiple subscribers .......795 Configuring a DNS/WINS server IP address per subscriber ....................795 Configuring access to Web applications and Web browsing for each subscriber .......................................................................................796 Configuring file browsing access for each subscriber .............................797 Setting up multiple subnet IP addresses for a subscriber’s end-users.....798 Configuring multiple IVS systems to allow access to shared server........799 Chapter 30 IVE and IDP Interoperability 801 Licensing: IDP availability ............................................................................802 Deployment scenarios .................................................................................802 Configuring the IVE to Interoperate with an IDP ..........................................803 Configuring IDP connections .................................................................803 Identifying and managing quarantined users manually .........................807 Part 6 System services Chapter 31 IVE serial console 811 Licensing: Serial console availability.............................................................811 Connecting to an IVE appliance’s serial console...........................................811 Rolling back to a previous system state........................................................812 Rolling back to a previous system state through the admin console ......813 Rolling back to a previous system state through the serial console ........813 Resetting an IVE appliance to the factory setting .........................................814 Performing common recovery tasks ............................................................817 Chapter 32 Customizable admin and end-user UIs 819 Licensing: Customizable UI availability ........................................................819 Customizable admin console elements overview .........................................819 Customizable end-user interface elements overview....................................821 Chapter 33 Secure Access 6000 823 Standard hardware ......................................................................................823 Secure Access 6000 field-replaceable units ..................................................824 xx Table of Contents Table of Contents Chapter 34 Secure Access FIPS 827 Licensing: Secure Access FIPS availability ....................................................827 Secure Access FIPS execution ......................................................................828 Creating administrator cards........................................................................829 Administrator card precautions .............................................................830 Deploying a cluster in an Secure Access FIPS environment..........................830 Creating a new security world......................................................................832 Creating a security world on a stand-alone IVE......................................833 Creating a security world in a clustered environment ............................834 Replacing administrator cards ...............................................................834 Recovering an archived security world.........................................................835 Importing a security world into a stand-alone IVE............................... 836 Importing a security world into a cluster ...............................................837 Chapter 35 Compression 839 Licensing: Compression availability .............................................................839 Compression execution................................................................................839 Supported data types ...................................................................................840 Enabling compression at the system level....................................................841 Creating compression resource profiles and policies ....................................842 Chapter 36 Multi-language support 843 Licensing: Multi-language support availability ..............................................844 Encoding files ..............................................................................................844 Localizing the user interface.........................................................................844 Localizing custom sign-in and system pages ................................................845 Chapter 37 Handheld devices and PDAs 847 Licensing: Handheld and PDA support availability .......................................848 Task summary: Configuring the IVE for PDAs and handhelds ......................848 Defining client types ....................................................................................849 Enabling WSAM on PDAs.............................................................................851 Part 7 Supplemental information Appendix A Writing custom expressions 855 Licensing: Custom expressions availability...................................................855 Custom expressions .....................................................................................855 Wildcard matching ................................................................................859 DN variables and functions....................................................................859 System variables and examples ...................................................................860 Using system variables in realms, roles, and resource policies.....................869 Using multi-valued attributes .................................................................870 Specifying fetch attributes in a realm ....................................................871 Specifying the homeDirectory attribute for LDAP ..................................872 Table of Contents xxi Juniper Networks Secure Access Administration Guide 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 For information on how to write and implement solutions through Host Checker client and server APIs, and for information about how to check for specific third-party solutions through Host Checker, refer to the J.E.D.I. Solution 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 xxiv Conventions 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. About This Guide Table 2: Text conventions (except for command syntax) 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. 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 23 1 Juniper Networks Secure Access Administration Guide 2 Chapter 1 Initial Verification and Key Concepts This section describes the tasks designed to follow initially installing and configuring your IVE. The contents in this section assume that you have already followed the Task Guide in the admin console to update your software image and 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 IVE user sign-in page. To verify user accessibility: 1. In the admin console, choose Authentication > Auth. Servers. 2. Select System Local. 3. Select the Users tab. 4. Click New. 5. On the New Local User page, enter “testuser1” as the username and a password, and then click Save Changes. The IVE creates the testuser1 account. 6. In another browser window, 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. When prompted with the security alert to proceed without a signed certificate, click Yes. If the user sign-in page appears, you have successfully connected to your IVE appliance. Verifying user accessibility 3 Juniper Networks Secure Access Administration Guide Figure 1: User Sign-in Page 7. On the sign-in page, enter the username and password you created for the user account and then click Sign In to access the IVE home page for users. Figure 2: User Home Page (default) 8. In the browser Address field, enter the URL to an internal Web server 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. 4 Verifying user accessibility Chapter 1: Initial Verification and Key Concepts Figure 3: Example Internal Web Page with Browsing Toolbar 9. On the IVE home page, enter the URL to your external corporate site and click Browse. The IVE opens the Web page in the same browser window, so use the browsing toolbar to return to the IVE home page. 10. On the IVE home page, click Browsing > Windows Files to browse available Windows file shares or Browsing > UNIX/NFS Files to browse 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 create 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 pre-configured with one user role called “Users.” This pre-defined 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 Users > User Roles page. NOTE: After you enable an access feature for a role (on the Users > User Roles > Role Name page), configure the appropriate corresponding options that are accessible from the access feature’s configuration tab. To define a user role: 1. In the admin console, choose Users > User Roles. 2. On the Roles page, click New Role. 3. On the New Role page, enter “Test Role” in the Name field and then click Save Changes. Wait for the IVE to display the General > Overview page for Test Role. 4. On the Overview page, select the Web checkbox under Access features and then click Save Changes. 5. Choose Web > Options. 6. Select the User can type URLs in the IVE browser bar checkbox, and then click Save Changes. 6 Creating a test scenario to learn IVE concepts and best practices Chapter 1: Initial Verification and Key Concepts 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. Figure 4: Users > User Roles > New Role page Creating a test scenario to learn IVE concepts and best practices 7 Juniper Networks Secure Access Administration Guide Figure 5: Users > User Roles > Test Role > General > Overview 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 pre-configured with two types of resource policies: 8 Web Access—The pre-defined 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 pre-defined 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. Creating a test scenario to learn IVE concepts and best practices Chapter 1: Initial Verification and Key Concepts 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. You can access the default Web and file resource policies on the Users > Resource Policies > Web > Access and Users > Resource Policies > Files > Access > Windows pages. To define a resource profile: 1. In the admin console, choose Users > Resource Profiles > Web > Web Applications/Pages. 2. On the Web Applications Resource Profile page, click New Profile. 3. On the New Web Applications Resource Profile page: a. In the Type field, keep the default option (Custom) b. In the Name field, enter “Test Web Access” c. In the Base URL field, enter “http://www.google.com” d. In the Autopolicy: Web Access Control section, select the checkbox next to the default policy created by the IVE (http://www.google.com:80/*) and choose Delete. e. In the Autopolicy: Web Access Control section, enter “http://www.google.com” in the Resource field, select Deny from the Action list, and click Add. f. Click Save and Continue. 4. In the Roles tab: a. Select “Test Role” in the Available Roles field and click Add to move it to the Selected Roles field. 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. Note that 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. Creating a test scenario to learn IVE concepts and best practices 9 Juniper Networks Secure Access Administration Guide Figure 6: Users > Resource Profiles > Web > Web Applications/Pages > New Profile 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 pre-configured with one local authentication server for users called “System Local.” This pre-defined 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. 10 Creating a test scenario to learn IVE concepts and best practices Chapter 1: Initial Verification and Key Concepts You can view the default local authentication server on the Authentication > Auth. 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. In the admin console, choose Authentication > Auth. Servers. 2. On the Authentication Servers page, choose Local Authentication from the New list and then click New Server. 3. On the New Local Authentication page, enter “Test Server” in the Name field 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. 5. On the New Local User page, enter “testuser2” in the Username field, enter a password, and then click Save Changes to create the user’s account in the Test Server authentication server. After completing these steps, you have created an authentication server that contains one user account. This user can sign in to an authentication realm that uses the Test Server authentication server. 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. Creating a test scenario to learn IVE concepts and best practices 11 Juniper Networks Secure Access Administration Guide Figure 7: Authentication > Auth. Servers > New Server Figure 8: Authentication > Auth. Servers > Test Server > Users > New 12 Creating a test scenario to learn IVE concepts and best practices Chapter 1: Initial Verification and Key Concepts Figure 9: Authentication > Auth. Servers > Test Server > Users 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. 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 in order 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. Creating a test scenario to learn IVE concepts and best practices 13 Juniper Networks Secure Access Administration Guide The IVE is pre-configured with one user realm called “Users.” This pre-defined 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 Users > User Realms page. To define an authentication realm: 1. In the admin console, choose User Realms. 2. On the User Authentication Realms page, click New. 3. On the New Authentication Realm page: a. In the Name field, enter: Test Realm b. Under Servers, choose “Test Server” from the Authentication list. c. Click Save Changes. Wait for the IVE to notify you that the changes are saved and to display the realm’s configuration tabs. 4. On the Role Mapping tab, click New Rule. 5. On the Role Mapping Rule page: a. Under Rule: If username..., enter “testuser2” in the value field. b. Under ...then assign these roles, select “Test Role” in the Available Roles field and click Add to move it to the Selected Roles field. c. 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. 14 Creating a test scenario to learn IVE concepts and best practices Chapter 1: Initial Verification and Key Concepts Figure 10: Users > User Realms > New Realm Creating a test scenario to learn IVE concepts and best practices 15 Juniper Networks Secure Access Administration Guide Figure 11: Users > User Realms > Test Server > New Rule Defining a sign-in policy A sign-in policy is a system rule that specifies: A URL at which 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 to which the sign-in policy applies All Secure Access and Secure Access FIPS IVEs are pre-configured 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 users 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 create in “Defining an authentication realm” on page 13. 16 Creating a test scenario to learn IVE concepts and best practices Chapter 1: Initial Verification and Key Concepts You can view the default user sign-in policy on the Authentication > Authentication > Signing In Policies 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. The default sign-in policy applies to all users. You can modify the URL to the IVE user sign-in page by adding to the path, such as “*/employees,” but you cannot create additional sign-in policies unless you purchase the Advanced license for your IVE. To define a sign-in policy: 1. In the admin console, choose Authentication > Signing in > Sign-in Policies. 2. On the Sign-in Policies page, click */. 3. On the */ page: a. In the Sign-in URL field, enter “test” after “*/.” b. Under Authentication realm, select User picks from a list of authentication realms, and then select “Test Realm” in the Available Roles field and click Add to move it to the Selected Realms field. (Repeat this process for the Users role if it is not already in the Selected Realms field.) c. Click Save Changes. After completing these steps, you have finished modifying the default users sign-in policy. Optional: 1. Choose Authentication > Authentication > Signing In Pages, and then click New Page. 2. On the New Sign-In Page page, enter “Test Sign-in Page” in the Name field, enter “#FF0000” (red) in the Background color field, and then click Save Changes. 3. Choose Authentication > Authentication > Signing In Policies, and then click New URL. 4. On the New Sign-in Policy page, enter “*/test/” in the Name field, select Default Sign-in Page in the Sign-in Page field, and click Save Changes. 5. Choose Authentication > Authentication > Signing In Policies, and then click */test/ under User URLs. 6. On the */test/ page, choose “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. Creating a test scenario to learn IVE concepts and best practices 17 Juniper Networks Secure Access Administration Guide Figure 12: Authentication > Authentication > Signing In Policies > */ Figure 13: Authentication > Authentication > Signing In Policies > */test/ — Using New 18 Creating a test scenario to learn IVE concepts and best practices Chapter 1: Initial Verification and Key Concepts Sign-in Page Using the test scenario The test scenario enables you to: Access the user console using the modified default sign-in policy Sign in as the user created in Test Server to the Test Realm Test your Web browsing capabilities, which are dependent upon the proper configuration of Test Role and Test Web Access To use the test scenario: 1. In a browser, enter the machine’s URL followed by “/test” to access the user sign-in page. The URL is in the format: https://a.b.c.d/test, where a.b.c.d is the machine IP address you entered in the serial console during initial configuration. When prompted with the security alert to proceed without a signed certificate, click Yes. If the user sign-in page appears, you have successfully connected to your IVE appliance. Creating a test scenario to learn IVE concepts and best practices 19 Juniper Networks Secure Access Administration Guide 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. 2. On the sign-in page, enter the username and password you created for the user account in Test Server, specify “Test Realm” in the Realm field, and then click Sign In to access the IVE home page for users. 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. Figure 15: User Home Page 20 Creating a test scenario to learn IVE concepts and best practices Chapter 1: Initial Verification and Key Concepts 3. In the browser Address field, 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. 4. On the IVE home page, enter “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. Figure 16: Example Error Message for Denied Resource 5. Return to the IVE home page, click Sign Out, and then return to the user sign-in page. 6. Enter the credentials for testuser1, specify the Users realm, and then click Sign In. 7. On the IVE home page, enter “www.google.com” and click Browse. The IVE opens the Web page in the same browser window. 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). Creating a test scenario to learn IVE concepts and best practices 21 Juniper Networks Secure Access Administration Guide 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: Administrator roles .Administrators — This built-in role permits administrators to manage all aspects of the IVE. The administrator user you create in 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. NOTE: You need the Advanced license in order to create additional administrator roles. 22 Administrators local authentication server — The Administrators 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 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 Admin Users realm to the .Administrators role. The administrator account you create in the serial console is part of the Admin Users realm. */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 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 email clients, hosted servers, and more from outside your trusted network using just a Web browser. This section contains the following information about the IVE: “What is the IVE?” on page 23 “What can I do with the IVE?” on page 25 “How do I start configuring the IVE?” on page 31 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 via 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 email servers, start a secured layer three tunnel, or schedule or attend a secure online meeting.1 1. These capabilities depend upon the Juniper Networks Secure Access product and upgrade options you have purchased. What is the IVE? 23 Juniper Networks Secure Access Administration Guide Figure 17: The IVE working within a LAN You can configure a Juniper Networks Secure Access appliance to: 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’ ability to access individual applications. Assess the security status of your users’ computers by checking for endpoint defense tools such as current antivirus software, firewalls, and security patches. You can then allow or deny users access to the appliance, resource types, or individual resources based on the computer’s security status. The 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. Since 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. 24 What is the IVE? Chapter 2: Introduction to the IVE 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 sections 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 25 “Can I use my existing servers to authenticate IVE users?” on page 27 “Can I fine-tune access to the IVE and the resources it intermediates?” on page 27 “Can I create a seamless integration between the IVE and the resources it intermediates?” on page 28 “Can I use the IVE to protect against infected computers and other security concerns?” on page 29 “Can I ensure redundancy in my IVE environment?” on page 29 “Can I make the IVE interface match my company’s look-and-feel?” on page 29 “Can I enable users on a variety of computers and devices to use the IVE?” on page 30 “Can I provide secure access for my international users?” on page 30 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? 25 Juniper Networks Secure Access Administration Guide The IVE includes remote access mechanisms that intermediate the following types of traffic: 26 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 feature to intermediate this type of content. The Secure Application Manager 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. Email 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 279. 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 91. 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 multi-layered approach to protect the IVE and your resources: 1. First, you can perform pre-authentication 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, he can access the IVE end-user home page. Otherwise, the IVE does not enable him 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? 27 Juniper Networks Secure Access Administration Guide 3. After the IVE successfully assigns a user to a realm, the appliance maps him 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 he 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 above), but add a resource policy detailed rule that requires users to meet additional criteria in order 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 in order 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 33. 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 enduser 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 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. During IVE configuration, you can enable SSO by specifying user credentials that you want the IVE to pass to the intermediated resources. For more information, see “Single sign-on” on page 191. 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. 28 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 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 which creates 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 221. For more information about integrating the IVE with IDP, see “IVE and IDP Interoperability” on page 801. 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 off-line, 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 or Round-Robin DNS. 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 off-line, 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 look like one of your standard company Web pages or applications. What can I do with the IVE? 29 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 28. 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 administration 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 819. 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 847. 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 endusers. For more information about localization, see “Multi-language support” on page 843. 30 What can I do with the IVE? Chapter 2: Introduction to the IVE How do I start configuring the IVE? To enable users to start using your Secure Access appliance, you must complete the following basic steps: 1. Plug in the appliance, connect it to your network, and configure its initial system and network settings. This quick and easy process is detailed in the 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 administration 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 in order to sign into the IVE. d. Define a sign-in policy that specifies the URL that users must access in order 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 administration console that quickly walks you through this process. To access this task guide, click the Guidance link. 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. How do I start configuring the IVE? 31 Juniper Networks Secure Access Administration Guide 32 How do I start configuring the IVE? Part 2 Access management framework The IVE protects resources by using the following access management mechanisms: Authentication realm—Resource accessibility begins with the authentication realm. An authentication realm specify 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). This section contains the following information about the IVE access management framework: “General access management” on page 35 “User roles” on page 51 “Resource profiles” on page 71 “Resource policies” on page 81 “Authentication and directory servers” on page 91 “Authentication realms” on page 165 33 Juniper Networks Secure Access Administration Guide 34 “Sign-in policies” on page 181 “Single sign-on” on page 191 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. This section contains the following information about the access management framework: “Licensing: Access management availability” on page 35 “Policies, rules & restrictions, and conditions overview” on page 35 “Policies, rules & restrictions, and conditions evaluation” on page 38 “Dynamic policy evaluation” on page 40 “Configuring security requirements” on page 42 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). Licensing: Access management availability 35 Juniper Networks Secure Access Administration Guide This section contains the following information about access management policies, rules, restrictions, and conditions: “Accessing authentication realms” on page 36 “Accessing user roles” on page 37 “Accessing resource policies” on page 37 Accessing authentication realms Resource accessibility begins with the authentication realm. An authentication realm is 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 91. 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 168. 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 91. 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 169. 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, then 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. For more information, see “Authentication realms” on page 165. 36 Policies, rules & restrictions, and conditions overview Chapter 3: General access management 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. For more information, see “User roles” on page 51. 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. 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: “Resource policies” on page 81 Policies, rules & restrictions, and conditions overview 37 Juniper Networks Secure Access Administration Guide “Resource profile components” on page 72 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. 38 Policies, rules & restrictions, and conditions evaluation Chapter 3: General access management 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. 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 52. 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 86. 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. Policies, rules & restrictions, and conditions evaluation 39 Juniper Networks Secure Access Administration Guide 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 “Dynamic policy evaluation” on page 40. NOTE: If you enable dynamic policy evaluation, the IVE performs additional checks beyond the ones mentioned here. For more information, see “Dynamic policy evaluation” on page 40. 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 40 “Understanding standard policy evaluation” on page 41 “Enabling dynamic policy evaluation” on page 42 Understanding dynamic policy evaluation During dynamic policy evaluation, the IVE evaluates the following types of resource policies: 40 Dynamic policy evaluation Windows Secure Application Manager Java Secure Application Manager Network Connect Telnet/SSH Terminal services (Windows and Citrix) Java Access Chapter 3: General access management 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. 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. (For more information, see “Policies, rules & restrictions, and conditions evaluation” on page 38.) If you do 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 42. Dynamic policy evaluation 41 Juniper Networks Secure Access Administration Guide 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: 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. 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 686. 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 262. Configuring security requirements An IVE makes it easy to specify security requirements for administrators and users through the options and features described in the following sections: 42 “Specifying source IP access restrictions” on page 43 “Specifying browser access restrictions” on page 44 “Specifying certificate access restrictions” on page 47 “Specifying password access restrictions” on page 48 “Specifying Host Checker access restrictions” on page 49 Configuring security requirements Chapter 3: General access management “Specifying Cache Cleaner access restrictions” on page 49 Specifying source IP access restrictions 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: 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 Configuring security requirements 43 Juniper Networks Secure Access Administration Guide 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 checkbox 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. 44 Configuring security requirements Chapter 3: General access management 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: 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 Configuring security requirements 45 Juniper Networks Secure Access Administration Guide 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 ** where start (*) is an optional character used to match any character and 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 substring Deny to prevent users from using a browser that has a user-agent header containing the 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 46 Configuring security requirements Chapter 3: General access management *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: 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. Configuring security requirements 47 Juniper Networks Secure Access Administration Guide 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 111. 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. 48 Configuring security requirements Chapter 3: General access management Specifying Host Checker access restrictions For information about restricting a user’s access to the IVE, a role, or a resource based on his Host Checker status, see “Implementing Host Checker policies” on page 251. 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 273. 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. Configuring security requirements 49 Juniper Networks Secure Access Administration Guide 50 Configuring security requirements 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 email 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 is an entity that 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 Administrators > Admin Roles page of 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 Users > User Roles page of the admin console. This section includes the following information about roles: “Licensing: User roles availability” on page 52 “User role evaluation” on page 52 “Configuring user roles” on page 54 “Customizing user roles UI views” on page 66 51 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 diagram. A detailed description of each step follows after the diagram. Figure 19: Security checks performed by the IVE 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: 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” option is configured. If so, then the engine jumps to step 5. 52 Licensing: User roles availability Chapter 4: User roles 2. The IVE evaluates the next rule on the authentication realm’s Role Mapping tab according to the process in the previous step and 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. For more information, see “Dynamic policy evaluation” on page 40. 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 to 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 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 53 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 role enables the Roaming Session feature, then the IVE merges the netmasks to formulate a greater netmask for the session. When merging two roles 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 on the Users > User Roles > Select Role > Web > Options page. 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: 54 Configuring user roles “Configuring general role options” on page 55 “Configuring role restrictions” on page 56 “Specifying role-based source IP aliases” on page 57 “Specifying session options” on page 57 “Specifying customized UI settings” on page 60 “Defining default options for user roles” on page 64 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. To create individual user accounts, you must add the users through the appropriate authentication server (not the role). For instructions, see “Creating user accounts on a local authentication server” on page 117 for local authentication servers. Or for instructions on how to create users on third-party servers, see the documentation that comes with that product. Configuring general role options Use the Overview 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, choose Users > User Roles > RoleName > 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 64. Role-specific options include: VLAN/Source IP—Select this option to apply the settings configured in the General > VLAN/Source IP tab to the role. For more information, see “Specifying role-based source IP aliases” on page 57. Session Options—Select this option to apply the settings in the General > Session Options tab to the role. For more information, see “Specifying session options” on page 57. UI Options—Select this option to apply the settings in the General > UI Options tab to the role. For more information, see “Specifying customized UI settings” on page 60. 4. Under Access features, check the features you want to enable for the role. Options include: Web—For more information, see “Web rewriting” on page 281 Configuring user roles 55 Juniper Networks Secure Access Administration Guide Files (Windows or UNIX/NFS version)—For more information, see “File rewriting” on page 371 Secure Application Manager (Windows version or Java version)—For more information, see “Secure Application Manager” on page 395 Telnet/SSH—For more information, see “Telnet/SSH” on page 449 Terminal Services—For more information, see “Terminal Services” on page 461 Meetings—For more information, see “Secure Meeting” on page 493 Email Client—For more information, see “Email Client” on page 513 Network Connect—For more information, see “Network Connect” on page 521 5. Click Save Changes to apply the settings to the role. Configuring role restrictions Use the Restrictions 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. For more information, see “General access management” on page 35. 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, choose Users > User Roles > RoleName > 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: 56 Configuring user roles “Specifying source IP access restrictions” on page 43 “Specifying browser access restrictions” on page 44 “Specifying certificate access restrictions” on page 47 “Specifying password access restrictions” on page 48 “Specifying Host Checker access restrictions” on page 49 “Specifying Cache Cleaner access restrictions” on page 49 Chapter 4: User roles Specifying role-based source IP aliases Use the VLAN/Source IP tab 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 561 and “Configuring virtual ports” on page 566. To specify a source IP alias for the role: 1. In the admin console, choose Users > User Roles > RoleName > General > VLAN/Source IP. 2. Select the VLAN you want to use from the VLAN drop-down menu, 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 this drop-down menu, 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 drop-down menu. 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 Use the Session tab to specify session time limits, roaming capabilities, session and password persistency, request follow-through options, and idle timeout application activity. Check the Session Options checkbox on the Overview tab to enable these settings for the role. Configuring user roles 57 Juniper Networks Secure Access Administration Guide To specify general session options: 1. In the admin console, choose Users > User Roles > RoleName > General > Session Options. 2. Under Session Lifetime, specify values for: Idle Timeout—Specify the number of minutes a non-administrative user session may remain idle before ending. The minimum is 5 minutes. The default idle session limit is ten minutes, which means that if a user’s session is inactive for ten minutes, the IVE ends the user session and logs the event in the system log (unless you enable session timeout warnings described below). Max. Session Length—Specify the number of minutes an active nonadministrative user session may remain open before ending. The minimum is 6 minutes. The default time limit for a user session is sixty 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 re-enter 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: If you are using Secure Meeting, you can configure meeting session limits through the Users > Resource Policies > Meetings page of the admin console. For more information, see “Defining resource policies: Secure Meeting” on page 508. 3. Under Enable session timeout warning: a. Select Enabled to notify non-administrative users when they are about to reach a session or idle timeout limit. These warnings prompt users to take the appropriate action when they are close to exceeding their session limits or idle timeouts, helping them save any in-progress form data that would otherwise be lost. Users approaching the idle timeout limit are prompted to reactivate their session. Users approaching the session time limit are prompted to save data. For example, an IVE user may unknowingly reach the idle timeout set for his role while using an email client configured to work with the IVE, because the IVE does not receive data while the user composes email. 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 email. 58 Configuring user roles Chapter 4: User roles b. Check the Display sign-in page on max session time out checkbox 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 this 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. This 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—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. However, some browsers may have vulnerabilities that can allow malicious code to steal user cookies. A malicious user could then use a stolen IVE session cookie to sign in to the IVE. Limit to subnet—To limit the roaming session to the local subnet specified in the Netmask field. 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—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. 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. Configuring user roles 59 Juniper Networks Secure Access Administration Guide 6. Under Persistent password caching, select Enabled to allow cached passwords to persist across sessions for a role. The IVE supports NTLM 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. 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 emails) 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: You must also enable client-side logs on the System > Log/Monitoring > Client Logs > Settings page to completely enable this option for the user. For more information, see “Enabling client-side logs” on page 679. 10. Click Save Changes to apply the settings to the role. Specifying customized UI settings Use the UI Options 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. Check the UI Options checkbox on the Overview tab to enable custom settings for the role; otherwise, the IVE uses the default settings. Personalization settings including 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. Choose Users > User Roles > RoleName > General > UI Options. 2. Under Header, specify a custom logo and alternate background color for the header area of the IVE welcome page (optional): 60 Configuring user roles Click the Browse button and locate your custom image file. The Current appearance displays the new logo only after you save your changes. Chapter 4: User roles 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 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 updates immediately. Type the hexidecimal number for the Text color or click the Color Palette icon and pick the desired color. The Current appearance updates immediately. 4. Under Start page, specify the start page 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. 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/. 5. Under Bookmarks Panel Arrangement, arrange the panels as you want to display them on the user's bookmarks page: a. Select the name of a panel 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. Configuring user roles 61 Juniper Networks Secure Access Administration Guide 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: 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. 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: 62 Configuring user roles Show the browsing toolbar—Select this option to display the browsing toolbar. Chapter 4: User roles Toolbar type—Select the type of browsing toolbar you want to display: Standard—Users can move this toolbar 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. 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. 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 drop-down 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. Configuring user roles 63 Juniper Networks Secure Access Administration Guide 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 disable the User can add bookmarks option on the Users > User Roles > RoleName > Web > Options page, the IVE does not display the Bookmark this Page and Bookmark Favorites buttons on the browsing toolbar regardless of whether or not you select the Enable "Add Bookmark" link and Enable "Bookmark Favorites" link options.) 9. Under Personalized greeting, specify a greeting and notification message on the IVE Bookmarks page (optional): Select Enabled to display the personalized greeting. The IVE displays the username if the full name is not configured. Select Show notification message 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: , ,
, , and . 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. 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 869. 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. Choose 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 options include, but are not limited to: Session options 64 Configuring user roles Session lifetime—Define the idle timeout and maximum session length in minutes. Chapter 4: User roles Session timeout warning—Determine if warning and login page display. Roaming session—Define level of mobility access. Persistent session—Define state across browser instances. Cookie state at session termination—Define cookie state. Persistent password caching—Define password state across sessions. Browser request follow-through—Define response to browser session expiration. Basic authentication intermediation—Define intermediation of authentication. Idle timeout application activity—Define IVE response to application session activity. Cache Cleaner frequency—Define frequency of Cache Cleaner checking. UI options Header Sub-headers Start page Bookmarks panel arrangement Help page User toolbar Browsing toolbar Personalized greeting Defining default options for user roles To define the default options for all user roles: 1. Choose 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 55 and “Customizing messages” on page 66. 4. Click Save Changes. These become the new defaults for all new user roles. Configuring user roles 65 Juniper Networks Secure Access Administration Guide NOTE: If you do not want user roles to see the copyright notice, you can also deselect the option in the Default Settings 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. 2. In the Roles page, click Default Options. 3. Select the Custom Messages tab. 4. Select the language you want to use from the drop down menu. 5. Enter your text in the Custom Message field, below the default message you want to override. 6. Click Save Changes. 7. Repeat the process to create messages in additional languages. Customizing user roles UI views 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. Navigate to Users > User Roles. 2. Select an option from the View menu at the top of the page. For information about these options, see Table 3. 3. Select one of the following options from the for list: 66 Customizing user roles UI views 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 checkboxes in the Role list. Chapter 4: User roles 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 checkmarks) 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. 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.) Customizing user roles UI views 67 Juniper Networks Secure Access Administration Guide Table 3: View menu options Option Description 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. 68 Customizing user roles UI views ACL Resource Policies: Web Displays the Web resource policies that are associated with the specified roles. Includes the type, name, description, action, and resources for each policy. Also displays links you can use to access the corresponding policy configuration pages. ACL Resource Policies: Files (Windows) Displays the Windows file resource policies that are associated with the specified roles. Includes the type, name, description, action, and resources for each policy. Also displays links you can use to access the corresponding policy configuration pages. ACL Resource Policies: Files (UNIX) Displays the UNIX file resource policies that are associated with the specified roles. Includes the type, name, description, action, and resources for each policy. Also displays links you can use to access the corresponding policy configuration pages. ACL Resource Policies: SAM Displays the JSAM and WSAM resource policies that are associated with the specified roles. Includes the type, name, description, action, and resources for each policy. Also displays links you can use to access the corresponding policy configuration pages. 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. Chapter 4: User roles Table 3: View menu options Option Description Resource Profiles: Files (Windows) Displays the Windows file resource profiles that are associated with the specified roles. Includes the name, bookmarks, and supporting policies for each profile. Also displays links you can use to access the corresponding resource profile configuration pages. Resource Profiles: Files (UNIX) Displays the UNIX file resource profiles that are associated with the specified roles. Includes the name, bookmarks, and supporting policies for each profile. Also displays links you can use to access the corresponding resource profile configuration pages. Resource Profiles: SAM Client Applications Displays the JSAM and WSAM application resource profiles that are associated with the specified roles. Includes the name, bookmarks, and supporting policies for each profile. Also displays links you can use to access the corresponding resource profile configuration pages. Resource Profiles: SAM WSAM destinations Displays the WSAM destination resource profiles that are associated with the specified roles. Includes the name, bookmarks, and supporting policies for each profile. Also displays links you can use to access the corresponding resource profile configuration pages. Resource Profiles: Telnet/SSH Displays the Telnet/SSH resource profiles that are associated with the specified roles. Includes the name, bookmarks, and supporting policies for each profile. Also displays links you can use to access the corresponding resource profile configuration pages. Resource Profiles: Terminal Services Displays the Terminal Services resource profiles that are associated with the specified roles. Includes the name, bookmarks, and supporting policies for each profile. Also displays links you can use to access the corresponding resource profile configuration pages. Customizing user roles UI views 69 Juniper Networks Secure Access Administration Guide 70 Customizing user roles UI views 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 72 “Task summary: Configuring resource profiles” on page 72 “Resource profile components” on page 72 “Resource profile templates” on page 79 71 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 54. 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 72. Resource profile components Resource profiles contain the following components: 72 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 75. 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 76. 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 77. 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 78. 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 73 Juniper Networks Secure Access Administration Guide Figure 20: Using roles and resource policies to configure resources 74 Resource profile components Chapter 5: Resource profiles Figure 21: 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 288 pages; Java applets that are stored on third party servers Hosted java applet Java applets that you upload directly to the IVE “Defining resource profiles: Hosted Java applets” on page 362 File browsing Windows and UNIX/NFS servers, shares, and file paths “Defining resource profiles: File rewriting” on page 371 SAM client application Client/server applications “Defining resource profiles: WSAM” on page 401 and “Defining resource profiles: JSAM” on page 435 WSAM destination Destination networks or servers “Defining resource profiles: WSAM” on page 401 Telnet/SSH Telnet or SSH servers “Defining resource profiles: Telnet/SSH” on page 450 Resource profile components 75 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” on page 470 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 521. When defining resources, you can use IVE variables, such asto 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/ 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. 76 Resource profile components Chapter 5: Resource profiles 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. 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. Resource profile components 77 Juniper Networks Secure Access Administration Guide 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. 78 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 “Defining resource profiles: Citrix Web applications” on page 307. Lotus Notes—For more information, see “Defining resource profiles: WSAM” on page 401 and “Defining resource profiles: JSAM” on page 435. Microsoft Outlook—For more information, see “Defining resource profiles: WSAM” on page 401 and “Defining resource profiles: JSAM” on page 435. NetBIOS file browsing—For more information, see “Defining resource profiles: WSAM” on page 401 and “Defining resource profiles: JSAM” on page 435. Resource profile templates 79 Juniper Networks Secure Access Administration Guide 80 Resource profile templates Chapter 6 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 Secure Meeting and 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 Meeting Resource Policies—The Secure Meeting resource policy allows you to enable various features such as email notifications, session limits, daylight savings adjustments, and color-depth settings. 81 Juniper Networks Secure Access Administration Guide Secure Email Client Resource Policies—The Secure Email Client access resource policy allows you to enable or disable email client support. 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 71. This section provides the following information: “Licensing: Resource policies availability” on page 82 “Resource policy components” on page 82 “Resource policy evaluation” on page 86 “Creating detailed rules for resource policies” on page 87 “Customizing resource policy UI views” on page 89 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: 82 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 83. 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 6: 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 87. 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 575. 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. Resource policy components 83 Juniper Networks Secure Access Administration Guide If a host name in a policy’s Resources list is not fully qualified, such as “juniper” is specified instead of “intranet.juniper.net”, then the engine performs the evaluation as-is; no further qualification for the host name is performed. 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. 84 Resource policy components DNS Hostname—For example: www.juniper.com Chapter 6: 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]. [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 If the port is missing, then the default port 80 is assigned for http, 443 for https. If a port is specified, then the delimiter “:” is required. For example: .danastreet.net:5901-5910 10.10.149.149:22,23 tcp://10.11.0.10:80 udp://10.11.0.10:* NOTE: If you configure IPsec enforcement for an that has multiple interfaces in the source zone, the configures a unique IKE gateway, VPN, and tunnel policy for each interface. To distinguish between the tunnel policies, the displays the name of the vpn for each tunnel policy in the VPN column on the page after you click Save Changes. Resource policy components 85 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 22: 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 52.) 86 Resource policy evaluation Chapter 6: 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, Secure Meeting, 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 87). 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 40. 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 Secure Meeting and Email Client access features each have one policy that applies globally. For these two 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 87 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. In the Action section, configure the action you want to perform if the user request matches a resource in the Resource list (optional). Note that the action specified on the General tab is carried over by default. b. In the Resources section, specify any of the following (required): 88 Creating detailed rules for resource policies The same or a partial list of the resources specified on the General tab. Chapter 6: Resource policies c. 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 860 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 855 for syntax and variable information. Note that custom expressions are available only with the Advanced license. NOTE: You can use the 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. Customizing resource policy UI views 89 Juniper Networks Secure Access Administration Guide 90 Customizing resource policy UI views Chapter 7 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 91. 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 92 91 Juniper Networks Secure Access Administration Guide “Task summary: Configuring authentication servers” on page 92 “Defining an authentication server instance” on page 93 “Configuring an anonymous server instance” on page 94 “Configuring an ACE/Server instance” on page 96 “Configuring an Active Directory or NT Domain instance” on page 99 “Configuring a certificate server instance” on page 105 “Configuring an LDAP server instance” on page 106 “Configuring a local authentication server instance” on page 115 “Configuring an NIS server instance” on page 120 “Configuring a RADIUS server instance” on page 120 “Configuring an eTrust SiteMinder server instance” on page 133 “Configuring a SAML Server instance” on page 156 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 and is only available on other Secure Access appliances with an Advanced license. 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: 92 Licensing: Authentication server availability Chapter 7: Authentication and directory servers 1. Set up your authentication/authorization server using instructions from the provider. 2. Create an instance of the server starting at the Authentication > Authentication > Auth. Servers page in the admin console. 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 166. 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 117. 5. Password management only: set up password management options using instructions in “Enabling LDAP password management” on page 111. 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 96. LDAP protocol—Choose LDAP Server. For more information, see “Configuring an LDAP server instance” on page 106. 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 115. 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 91. Defining an authentication server instance 93 Juniper Networks Secure Access Administration Guide This section contains the following information about authentication servers: “Defining an authentication server instance” on page 94 “Modifying an existing authentication server instance” on page 94 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 168. 6. If you are configuring the local authentication server, define local user accounts. For instructions, see “Configuring a local authentication server instance” on page 115. 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. 94 Configuring an anonymous server instance Chapter 7: 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 95 “Defining an anonymous server instance” on page 95 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 166. When creating role mapping rules through the Users > User Realms > Role Mapping tab (as explained in “Creating role mapping rules” on page 169), 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, see “Specifying limits restrictions” on page 49. 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 95 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 168. 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: 96 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 7: 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 98. This section contains the following information about ACE/Servers: “Defining an ACE/Server instance” on page 97 “Generating an ACE/Agent configuration file” on page 98 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 98. 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. 4. Specify a name to identify the server instance. Configuring an ACE/Server instance 97 Juniper Networks Secure Access Administration Guide 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 98, and remove the check from the Sent Node Secret checkbox. 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 168. 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 686. 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: a. Click the Sent Node Secret checkbox to uncheck it. b. Sign in to the admin console and choose Authentication > Auth. Servers. 98 Configuring an ACE/Server instance Chapter 7: 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 checkbox 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 checkbox on the ACE server. 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 checkboxes 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 99 Juniper Networks Secure Access Administration Guide See “Creating role mapping rules” on page 169 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 checkboxes 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 checkboxes.For more information, see “Defining resource policies: UNIX/NFS file resources” on page 389. 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. 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 100 “Multi-domain user authentication” on page 102 “Active Directory and NT group lookup support” on page 104 Defining an Active Directory or Windows NT domain server instance To define an Active Directory or Windows NT Domain server: 1. In the admin console, choose Authentication > Auth. Servers. 2. Do one of the following: To create a new server instance on the 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. 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. 100 Configuring an Active Directory or NT Domain instance Chapter 7: Authentication and directory servers 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 checkbox 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 checkbox to get group information from all trusted domains within a forest. 10. 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. Configuring an Active Directory or NT Domain instance 101 Juniper Networks Secure Access Administration Guide 11. Under Authentication Protocol, specify which protocol the IVE should use during authentication. 12. 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. 13. 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) 14. Click Save Changes. If you are creating the server instance for the first time, the Settings and Users tabs appear. 15. Specify which realms should use the server to authenticate and authorize administrators and users. For more information, see “Creating an authentication realm” on page 166. 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 686. 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. 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. 102 Configuring an Active Directory or NT Domain instance Chapter 7: Authentication and directory servers 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 . 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. 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. Configuring an Active Directory or NT Domain instance 103 Juniper Networks Secure Access Administration Guide Two variables, and , 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: 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. 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: 104 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. Configuring an Active Directory or NT Domain instance Chapter 7: Authentication and directory servers 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. 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. Configuring a certificate server instance 105 Juniper Networks Secure Access Administration Guide 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 860. NOTE: If you choose a certificate attribute with more than one value, the IVE uses the first matched value. For example, if you enter 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 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 686. 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. 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 47. Configuring an LDAP server instance The IVE supports two LDAP-specific authentication options: 106 Unencrypted, in which the IVE sends the username and password to the LDAP Directory Service in clear, simple text. Configuring an LDAP server instance Chapter 7: Authentication and directory servers 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 107 “Configuring LDAP search attributes for meeting creators” on page 110 “Monitoring and deleting active user sessions” on page 110 “Enabling LDAP password management” on page 111 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. 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. Configuring an LDAP server instance 107 Juniper Networks Secure Access Administration Guide 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 to search LDAP checkbox 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 111. 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= or cn= Include 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. 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: 108 Configuring an LDAP server instance Base DN at which to begin searching for user groups. Chapter 7: Authentication and directory servers 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) 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. 17. Specify which realms should use the server to authenticate and authorize administrators and users. For more information, see “Defining authentication policies” on page 168. 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 380. Configuring an LDAP server instance 109 Juniper Networks Secure Access Administration Guide 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 686. 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 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. 110 Configuring an LDAP server instance Chapter 7: 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. This section includes the following topics with information about the LDAP password management feature: “Task summary: Enabling LDAP password management” on page 111 “Supported LDAP directories and servers” on page 112 “Supported LDAP password management functions” on page 113 Task summary: Enabling LDAP password management To enable password management through the IVE, you must: 1. Install a UPG-Password Management Integration license or the Advanced license through the System > Configuration > Licensing page of the admin console. 2. Create an instance of the LDAP server through the Authentication> Auth. Servers page of the admin console. Configuring an LDAP server instance 111 Juniper Networks Secure Access Administration Guide 3. Associate the LDAP server with a realm through the Administrators/Users > User Realms > [Realm] > General page of the admin console. 4. 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 Generic LDAP directories, such as IBM Secure Directory and 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. Microsoft Active Directory 112 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 113, 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. Configuring an LDAP server instance Chapter 7: Authentication and directory servers Sun iPlanet When you select the User must change password after reset option on the iPlanet server, you must also reset the user’s password before this function takes effect. This is a limitation of iPlanet. General The 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. When authenticating against a generic LDAP server, such as IBM Secure Directory, the IVE only supports authentication and allowing users to change their passwords. Table 7: Supported password management functions Function Active Directory iPlanet Novell eDirectory Generic Authenticate user unicodePwd Allow user to change password if licensed and if enabled Server tells us in bind response (uses ntSecurityDescriptor) userPassword userPassword userPassword If passwordChange == ON If passwordAllowChange == TRUE Yes Log out user after password change Yes 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 (IVE displays warning if less than 14 days) 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" Configuring an LDAP server instance 113 Juniper Networks Secure Access Administration Guide Table 7: Supported password management functions (Continued) Function Active Directory iPlanet Novell eDirectory Honor "password history" Server tells us in bind response Server tells us in bind response Server tells us in bind response Generic 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. 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. 114 Configuring an LDAP server instance Chapter 7: Authentication and directory servers 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 168. This section contains the following information about local authentication servers: “Defining a local authentication server instance” on page 115 “Creating user accounts on a local authentication server” on page 117 “Managing user accounts” on page 118 “Delegating user administration rights to end-users” on page 119 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: 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. Configuring a local authentication server instance 115 Juniper Networks Secure Access Administration Guide 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 checkbox 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 checkbox 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 checkbox 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. Enable the Password must be different from username checkbox if the password cannot equal the username (optional). g. Enable the New passwords must be different from previous password checkbox 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 checkbox if you want users to be able to change their passwords (optional). b. Enable the Force password change after _ days checkbox 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. 116 Configuring a local authentication server instance Chapter 7: Authentication and directory servers c. Enable the Prompt users to change their password _ days before current password expires checkbox 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 48 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 database to which you want to add a user account. 3. Select the Users tab and click New. 4. Enter a username and user’s full name. Note: Do not include “~~” in a username. If you want to change a user’s username after creating the account, you must create an entirely new account. 5. Enter and confirm the 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. Configuring a local authentication server instance 117 Juniper Networks Secure Access Administration Guide 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 his or her 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 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. Managing user accounts To manage a local user account: 1. In the admin console, choose Authentication > Auth. Servers. 2. Click the appropriate server link in the Authentication/Authorization Servers list. 3. Select the Users tab. 4. Perform any of the following tasks: Enter a username in the Show users named field and click Update to search for a specific user. Alternatively, you can use an asterisk (*) as a wildcard, where * represents any number of zero or more characters. For example, if you want to search for all usernames that contain the letters jo, enter *jo* in the Show users named field. The search is case-sensitive. To display the entire list of accounts again, either enter * or delete the field’s contents and click Update. 118 Enter a number in the Show N users field and click Update to control the number of users displayed on the page. Configuring a local authentication server instance Chapter 7: Authentication and directory servers Click the checkbox next to individual users and click Delete to terminate their IVE sessions. Delegating user administration rights to end-users User administrators can manage local authentication servers. User administrators cannot manage realms or role mappings. Therefore, we recommend enabling the User Admin feature only if the authentication realm’s role mapping rules permit “unmatched” users (*) to sign in to the IVE so the user administrator can successfully add new users without administrator interference. (When the role mappings are automatic, the user administrator does not need the administrator to manually map the new users to a role.) To delegate user administration rights to an end-user: 1. In the admin console, choose Authentication > Auth. Servers. 2. Select the local authentication server instance that you want the user administrator to manage, and then click the Admin Users tab. NOTE: User administrators can only administer local authentication servers. 3. Enter the Username of the user who you want to manage accounts for the selected authentication server. This user does not need to be added as a local user on the server that she manages. NOTE: Be careful when entering the user administrator’s username—it must match exactly. 4. Select the Authentication Realm that the user administrator maps to when she signs in to the IVE. 5. Click Add. The IVE adds the new user administrator to the User Admins list using the format: username@servername. 6. If the specified user administrator maps to multiple realms, optionally repeat steps 3-5 for each realm so that she may manage the server regardless of which account she uses to sign in to the IVE. 7. To revoke a user’s administration rights, select her name from the User Admins list and click Remove. 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 a local authentication server instance 119 Juniper Networks Secure Access Administration Guide 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. 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 168. 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 686. 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. 120 Configuring an NIS server instance Chapter 7: Authentication and directory servers 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 Steelbelted-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: “User experience for RADIUS users” on page 121 “Configuring the IVE to work with a RADIUS server” on page 122 “Enabling RADIUS accounting” on page 125 User experience for RADIUS users The user experience varies depending on whether you are using a 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. Configuring a RADIUS server instance 121 Juniper Networks Secure Access Administration Guide 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 23: CASQUE authentication Challenge/Response page with CASQUE player Configuring the IVE to work with a 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 122 “Configuring the RADIUS server to recognize the IVE” on page 124 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: 122 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. Configuring a RADIUS server instance Chapter 7: Authentication and directory servers 3. At the top of the Radius Server page, specify a name to identify the server instance. 4. Specify the name or IP address of the RADIUS server. 5. Enter the authentication port value for the RADIUS server. Typically this port is 1812, but some legacy servers might use 1645. 6. 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. 7. Enter the accounting port value for the RADIUS server. Typically this port is 1813, but some legacy servers might use 1646. 8. 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. 9. Enter the interval of time for the IVE to wait for a response from the RADIUS server before timing out the connection. 10. Enter the number of times for the IVE to try to make a connection after the first attempt fails. 11. 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 193. 12. 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 13. 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 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.” Configuring a RADIUS server instance 123 Juniper Networks Secure Access Administration Guide b. 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 860. 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: c. logs the user’s IVE username to the accounting server. logs the user’s IVE realm to the accounting server. 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. 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 133. 14. Add a custom challenge expression (optional). Three types of challenge expressions exist with each automatically set to its pre-populated default. The custom option allows the administrator to configure the actual string pattern to match for any of the three modes. To add a custom expression, select the Custom radio button under the appropriate challenge expression type, and add a custom expression in the associated text box. NOTE: When using CASQUE authentication, specify:([0-9a-zA-Z/+=]+): as the custom expression for the Generic Login Challenge Expression. 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, authorize, or account for administrators and users. For more information, see “Defining authentication policies” on page 168. NOTE: For information about monitoring and deleting the sessions of users from this server who are currently signed, see “Monitoring active users” on page 686. Configuring the RADIUS server to recognize the IVE You need to configure the RADIUS server to recognize the IVE by specifying: 124 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. Configuring a RADIUS server instance Chapter 7: Authentication and directory servers 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 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 Configuring a RADIUS server instance 125 Juniper Networks Secure Access Administration Guide Table 9: Attributes common to both start and stop messages (Continued) Attribute Description 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 Description Acct-Authentic (45) 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 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 126 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. Configuring a RADIUS server instance Chapter 7: Authentication and directory servers 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 FramedProtocol of ARAP. Includes password information that the NAS must send to the user in an ARAP feature flags packet. ARAP-Password Present in an Access-Request packet containing a Framed-Protocol of ARAP. Only one of User-Password, CHAP-Password, or ARAP-Password must be included in an Access-Request, or one or more EAP-Messages. ARAP-Security Identifies the ARAP Security Module to be used in an Access-Challenge packet. ARAP-Security-Data Contains a security module challenge or response, and is in Access-Challenge and Access-Request packets. ARAP-Zone-Access Indicates how to use the ARAP zone list for the user. Access-Accept Provides specific configuration information necessary to begin delivery of service to the user. Access-Challenge To send the user a challenge requiring a response, the RADIUS server must respond to the Access-Request by transmitting a packet with the Code field set to 11 (Access-Challenge). Access-Reject If any value of the received Attributes is not acceptable, then the RADIUS server must transmit a packet with the Code field set to 3 (Access-Reject). 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. Configuring a RADIUS server instance 127 Juniper Networks Secure Access Administration Guide Table 12: RADIUS role mapping attributes (Continued) 128 Attribute Description 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. 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. Configuring a RADIUS server instance Chapter 7: Authentication and directory servers Table 12: RADIUS role mapping attributes (Continued) Attribute Description 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-IPv6-Pool Contains the name of an assigned pool used to assign an IPv6 prefix for the user. Framed-IPv6-Route Routing information to be configured for the user on the NAS. Framed-IPX-Network The IPX Network number to be configured for the user. Framed-MTU The Maximum Transmission Unit to be configured for the user, when it is not negotiated by some other means (such as PPP). Framed-Pool The name of an assigned address pool used to assign an address for the user. Framed-Protocol The framing to be used for framed access. Framed-Route Routing information to be configured for the user on the NAS. Framed-Routing The routing method for the user, when the user is a router to a network. Idle-Timeout Sets the maximum number of consecutive seconds of idle connection allowed to the user before termination of the session or prompt. Keep-Alives Use SNMP instead of keep-alives. Login-IP-Host Indicates the system with which to connect the user, when the Login-Service Attribute is included. Configuring a RADIUS server instance 129 Juniper Networks Secure Access Administration Guide Table 12: RADIUS role mapping attributes (Continued) 130 Attribute Description 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. 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. Configuring a RADIUS server instance Chapter 7: Authentication and directory servers Table 12: RADIUS role mapping attributes (Continued) Attribute Description 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. 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. Configuring a RADIUS server instance 131 Juniper Networks Secure Access Administration Guide Table 12: RADIUS role mapping attributes (Continued) 132 Attribute Description 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. 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. Configuring a RADIUS server instance Chapter 7: Authentication and directory servers Table 12: RADIUS role mapping attributes (Continued) Attribute Description Tunnel-Start Marks the establishment of a tunnel with another node. Tunnel-Stop Marks the destruction of a tunnel to or from another node. Tunnel-Type The tunneling protocol(s) to be used (in the case of a tunnel initiator) or the tunneling protocol in use (in the case of a tunnel terminator). User-Name The name of the user to be authenticated. User-Password The password of the user to be authenticated, or the user's input following an Access-Challenge. 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. 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. 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 136). Configuring an eTrust SiteMinder server instance 133 Juniper Networks Secure Access Administration Guide 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 145). 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 137). This topic includes the following information about eTrust SiteMinder servers: “eTrust SiteMinder overview” on page 134 “Configuring SiteMinder to work with the IVE” on page 138 “Configuring the IVE to work with SiteMinder” on page 144 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: 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 148), 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: 134 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 149). 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. Configuring an eTrust SiteMinder server instance Chapter 7: Authentication and directory servers 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 150). 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 151). NOTE: 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. 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. 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 135 Juniper Networks Secure Access Administration Guide Authentication using various authentication schemes Within SiteMinder, an authentication scheme is a way to collect user credentials and determine the identity of a user. You may create different authentication schemes and associate different protection levels with each. For example, you may create two schemes—one that authenticates users based solely on the users’ client-side certificates and provides them a low protection level, and a second that uses ACE SecurID token authentication and provides users a higher protection level. The 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 607. 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: 136 “Creating a SiteMinder authentication scheme for the IVE” on page 139 “Configuring the IVE to work with multiple authentication schemes” on page 144 Configuring an eTrust SiteMinder server instance Chapter 7: Authentication and directory servers 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 134. 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 152. 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 139. 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: 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 137 Juniper Networks Secure Access Administration Guide 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 134). 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 142. 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 139 2. “Creating a SiteMinder authentication scheme for the IVE” on page 139 3. “Creating a SiteMinder domain for the IVE” on page 141 4. “Creating a SiteMinder realm for the IVE” on page 141 5. “Creating a rule/response pair to pass usernames to the IVE” on page 142 6. “Creating a SiteMinder policy under the domain” on page 144 138 Configuring an eTrust SiteMinder server instance Chapter 7: Authentication and directory servers 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 141) and when configuring the IVE (as explained in “Agent Name, Secret” on page 147). 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 147). 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. Configuring an eTrust SiteMinder server instance 139 Juniper Networks Secure Access Administration Guide 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 141). 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 137). 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 607. 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 141. 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. 140 Configuring an eTrust SiteMinder server instance Chapter 7: Authentication and directory servers 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 144. 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 141). 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 141. Configuring an eTrust SiteMinder server instance 141 Juniper Networks Secure Access Administration Guide 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 139. 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 147). 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 139). 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 141) 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 141) 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. 142 Configuring an eTrust SiteMinder server instance Chapter 7: Authentication and directory servers 2. Expand the domain that you created for the IVE (as explained in “Creating a SiteMinder domain for the IVE” on page 141). 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 139). 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 141). 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 139). 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. Configuring an eTrust SiteMinder server instance 143 Juniper Networks Secure Access Administration Guide 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 142.) 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 154. 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 144 “Configuring the IVE to grant users different protected resources” on page 145 “Defining an eTrust SiteMinder server instance” on page 146 “Defining a SiteMinder realm for automatic sign-in” on page 155 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 139. 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 146. 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 166. 144 Configuring an eTrust SiteMinder server instance Chapter 7: Authentication and directory servers 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 183. 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 141. 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 146. 3. Specify which IVE realm should use the IVE instance of the SiteMinder policy server. For instructions, see “Creating an authentication realm” on page 166. 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. Configuring an eTrust SiteMinder server instance 145 Juniper Networks Secure Access Administration Guide Select the IVE realm that you specified should use the SiteMinder policy server. For instructions, see“Configuring sign-in policies” on page 183. 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 166. 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 143.) 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 154. 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 686. 146 Configuring an eTrust SiteMinder server instance Chapter 7: Authentication and directory servers 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 139. 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 141. 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 (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. Configuring an eTrust SiteMinder server instance 147 Juniper Networks Secure Access Administration Guide 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: 148 Configuring an eTrust SiteMinder server instance Chapter 7: Authentication and directory servers 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 137 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 148. 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 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. Configuring an eTrust SiteMinder server instance 149 Juniper Networks Secure Access Administration Guide 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= 33554433&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 150, 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 150, the protocol is HTTP. 150 Configuring an eTrust SiteMinder server instance Chapter 7: Authentication and directory servers 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 150, 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 150, the path is: /siteminderagent/forms/login.fcc Parameters Post parameters to be sent when a user signs in. Common SiteMinder variables that you can use include _ _USER_ _, _ _PASS_ _, and _ _TARGET_ _. These variables are replaced by the username and password entered by the user on the Web agent’s sign-in page and by the value specified in the Target field. These are the default parameters for login.fcc—if you have made customizations, you may need to change these parameters. Delegate authentication to a standard agent Choose this option if you want to delegate authentication to a standard agent. When the user accesses the 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 139. 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. Configuring an eTrust SiteMinder server instance 151 Juniper Networks Secure Access Administration Guide 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 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. 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 137. 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 139. ** 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. 152 Configuring an eTrust SiteMinder server instance Chapter 7: Authentication and directory servers Table 13: eTrust SiteMinder configuration options (Continued) Option Description 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 Option Description Poll Interval Enter the interval at which IVE polls the Siteminder policy server to check for a new key. 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 150 or the Automatic sign-in option described in “Automatic Sign-In” on page 148. 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 Validate cookie every that period, the IVE assumes that its cached cookie is valid rather than re-validating it against the policy server. If you do not select this option, N seconds 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. Enable Session Grace Period, Configuring an eTrust SiteMinder server instance 153 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 143), 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 166.) 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. 154 Configuring an eTrust SiteMinder server instance Chapter 7: 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 169. You can also use the following syntax to reference a SiteMinder user attribute cookie in a custom expression for a role mapping rule: userAttr. 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 146. 4. Click Save Changes. 5. Configure the realm, as described in “Creating an authentication realm” on page 166, 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 checkbox. 9. Choose the realm you just configured from the user authentication realm list. 10. Click Save Changes. Configuring an eTrust SiteMinder server instance 155 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. 156 Configuring a SAML Server instance Chapter 7: 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 157. 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 158. 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 157 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. 158 Configuring a SAML Server instance Chapter 7: 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:// ?TARGET= … Configuring a SAML Server instance 159 Juniper Networks Secure Access Administration Guide In the preceding sample, consists of the host name, port number, and path components of the inter-site transfer URL at the source and where 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: 302 Location : http:// ? In the preceding sample, provides the host name, port number, and path components of an assertion consumer URL at the destination site and where = …TARGET= …SAMLart= … consists of one target description, which must be included in the component. At least one SAML artifact must be included in the SAML 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 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:// ? In the preceding sample, provides the host name, port number, and path components of an assertion consumer URL at the destination site. = …TARGET= …SAMLart= … 160 Configuring a SAML Server instance Chapter 7: Authentication and directory servers A single target description MUST be included in the component. At least one SAML artifact MUST be included in the component; multiple SAML artifacts MAY be included. If more than one artifact is carried within , 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 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. . 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 161 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 , 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 156. 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 162 or for the POST profile as described in “Configuring the SAML server instance to use the POST profile” on page 162. 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 161. 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 161. 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. 162 Configuring a SAML Server instance Chapter 7: 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 163 Juniper Networks Secure Access Administration Guide 164 Configuring a SAML Server instance Chapter 8 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 91. 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 91. 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 168. 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 169. This section contains the following information about authentication realms: “Licensing: Authentication realms availability” on page 166 “Creating an authentication realm” on page 166 “Defining authentication policies” on page 168 “Creating role mapping rules” on page 169 “Customizing user realm UI views” on page 178 165 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: When your 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. 166 Licensing: Authentication realms availability Chapter 8: 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 193), 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 Netegrity 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 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. 8. If you want to use dynamic policy evaluation for this realm (as explained in “Dynamic policy evaluation” on page 40), 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 167 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 169. b. Configure an authentication policy for the realm as described in “Defining authentication policies” on page 168. 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. 168 Defining authentication policies Chapter 8: 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 43 “Specifying browser access restrictions” on page 44 “Specifying certificate access restrictions” on page 47 “Specifying password access restrictions” on page 48 “Specifying Host Checker access restrictions” on page 49 “Specifying Cache Cleaner access restrictions” on page 491 “Specifying limits restrictions” on page 49 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 169 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 51. For more information about specifying role mapping rules, see “Specifying role mapping rules for an authentication realm” on page 170. 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 172. 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: 170 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 8: 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 172). 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 171 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 53. 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: 172 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 8: 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 855. 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 170), 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 24: Server Catalog > Attributes tab — Adding an attribute for LDAP Creating role mapping rules 173 Juniper Networks Secure Access Administration Guide Figure 25: Attribute added in Server Catalog is available for role mapping rule 174 Creating role mapping rules Chapter 8: Authentication realms Figure 26: Server Catalog > Groups tab — Adding LDAP groups Creating role mapping rules 175 Juniper Networks Secure Access Administration Guide Figure 27: Server Catalog > Groups tab — Adding Active Directory groups 176 Creating role mapping rules Chapter 8: Authentication realms Figure 28: Server Catalog > Expressions tab — Adding a custom expression Creating role mapping rules 177 Juniper Networks Secure Access Administration Guide Figure 29: Custom expression added in Server Catalog is available for role mapping 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: 178 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 8: 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 checkboxes in the Authentication Realm list. 4. Click Update. Customizing user realm UI views 179 Juniper Networks Secure Access Administration Guide 180 Customizing user realm UI views Chapter 9 Sign-in policies Sign-in policies define the URLs that users and administrators can use to access to the IVE and the sign-in pages that they see. The IVE comes with two sign-in policies—one for users and one for administrators. When configuring these policies, you associate each with the appropriate 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. If you have an Advanced license, 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. 181 Juniper Networks Secure Access Administration Guide When defining sign-in policies, you may use different host names (such as partners.yourcompany.com and employees.yourcompany.com) or different paths (such as yourcompany.com/partners and yourcompany.com/employees) to differentiate between URLs. NOTE: If a user attempts to sign in while there is another active user session with the same sign-in credentials, the 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= . 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: 182 “Licensing: Sign-in policies and pages availability” on page 183 “Task summary: Configuring sign-in policies” on page 183 “Configuring sign-in policies” on page 183 “Configuring sign-in pages” on page 187 Chapter 9: 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 and are only available on all other Secure Access products by special license: 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 181. This section contains the following information about sign-in policies: “Defining user sign in policies” on page 183 “Defining meeting sign-in policies” on page 185 “Specifying the order in which sign-in policies are evaluated” on page 187 “Enabling and disabling sign-in policies” on page 186 Defining user sign in policies To create or configure administrator or user sign-in policies: Licensing: Sign-in policies and pages availability 183 Juniper Networks Secure Access Administration Guide 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 / where is the host name of the IVE, and 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 within the specified realm(s) should use the sign-in page, enter */admin. To specify that all end-user URLs within the specified realm(s) should use the sign-in page, enter */. 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 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 signin pages” on page 188. 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: 184 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 9: 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 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 / where is the host name of the IVE, and 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 Configuring sign-in policies 185 Juniper Networks Secure Access Administration Guide 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: 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 188. 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 checkbox 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. 186 Configuring sign-in policies Chapter 9: Sign-in policies 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: 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: Configuring sign-in pages 187 Juniper Networks Secure Access Administration Guide 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 188. 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. 188 Configuring sign-in pages Chapter 9: Sign-in policies 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: , ,
, , and . 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. 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.) 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 189 Juniper Networks Secure Access Administration Guide 190 Configuring sign-in pages Chapter 10 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 191 “Single sign-on overview” on page 191 “Multiple sign-in credentials overview” on page 193 “Configuring SAML” on page 201 “Configuring SAML SSO profiles” on page 204 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 and are only available on all other Secure Access products by special license. 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 285. Licensing: Single sign-on availability 191 Juniper Networks Secure Access Administration Guide 192 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 201. 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 292. 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 99. 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 133. 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 461. You may also pass a username to the Telnet/SSH server, as explained in “Terminal Services” on page 461. 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 513. Chapter 10: 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 193. 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 201 “Configuring SAML SSO profiles” on page 204 “Configuring an eTrust SiteMinder server instance” on page 133 “Email Client” on page 513 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 193 “Task Summary: Enabling SSO to resources protected by basic authentication” on page 194 “Task Summary: Enabling SSO to resources protected by NTLM” on page 194 “Multiple sign-in credentials execution” on page 196 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 93. 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 193 Juniper Networks Secure Access Administration Guide For configuration instructions, see “Creating an authentication realm” on page 166. 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 48. 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 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.) 194 Multiple sign-in credentials overview Chapter 10: Single sign-on 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 195 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 30: 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: 196 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 10: 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 theand 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 and 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 120. 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 and session variables and allows the user access to the IVE. You may also access these variables using the syntax and . 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 120. Multiple sign-in credentials overview 197 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 (which submits the user’s primary credentials to the resource) or (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. 198 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 10: 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 199 Juniper Networks Secure Access Administration Guide 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. NOTE: 200 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 10: 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 38. 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 204. 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 201 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. 202 Configuring SAML Chapter 10: 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 204. “Creating an access control policy” on page 211 “Creating a trust relationship between SAML-enabled systems” on page 214 “Configuring SAML” on page 201 “Configuring a SAML Server instance” on page 156 “Task Summary: Configuring SAML through the IVE” on page 218 Configuring SAML 203 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 31. Figure 31: 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.) 204 Configuring SAML SSO profiles Chapter 10: 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:// /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 215). 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 205 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 83 for more information. To enable IP-based or case sensitivity matching for these resources, see “Writing a Web proxy resource policy” on page 351. 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/acs. (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 215). 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: 206 Configuring SAML SSO profiles Plain text string—The IVE converts, pads, or truncates it to a 20-byte string. Chapter 10: 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 215): https:// /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 215). 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 860 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 218). 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 207 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 215). 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 32. Figure 32: 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. 208 Configuring SAML SSO profiles Chapter 10: 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 215). 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 83 for more information. To enable IP-based or case sensitivity matching for these resources, see “Writing a Web proxy resource policy” on page 351. 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 209 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 215). 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: 210 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 10: Single sign-on Subject Name—Use the variables described in “System variables and examples” on page 860 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 218). 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 33. Figure 33: 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 211 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 215). 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 83 for more information. To enable IP-based or case sensitivity matching for these resources, see “Writing a Web proxy resource policy” on page 351. 7. In the Roles section, specify: 212 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 10: 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 215). 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 860 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 218). 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 213 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 215). 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: 214 “Configuring trusted application URLs” on page 215 “Configuring an issuer” on page 215 “Configuring certificates” on page 215 “Configuring user identity” on page 218 Configuring SAML SSO profiles Chapter 10: 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:// /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 215 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 607. 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 607. 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. 216 Configuring SAML SSO profiles Chapter 10: 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 201. 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 607. 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 607. Configuring SAML SSO profiles 217 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 > Access > SAML ACL > [Policy] > General page in the admin console. For more information, see “Configuring SAML SSO profiles” on page 204. 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 > SSO > SAML > [Policy] > General page (for more information, see “Configuring SAML” on page 201) and the Users > Resource Policies > Web > Access > 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 > Access > SAML ACL and Users > Resource Policies > Web > SSO > SAML tabs in the admin console. For more instructions, see “Configuring SAML” on page 201. 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 214. 218 Configuring SAML SSO profiles Chapter 10: 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 55. Configuring SAML SSO profiles 219 Juniper Networks Secure Access Administration Guide 220 Configuring SAML SSO profiles Part 3 Endpoint defense Juniper Networks has developed the Juniper Endpoint Defense Initiative (J.E.D.I.) to provide a comprehensive solution to assess the trust worthiness of SSL VPN endpoints. J.E.D.I. uses a layered approach to address the full range of risks that endpoints can pose to your enterprise network. Using J.E.D.I. components, you can secure the systems of users inside and outside your network before allowing them to connect to your IVE appliance. J.E.D.I. components include: Host Checker—Host Checker (also called native Host Check and policy-based enforcement) 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 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 223. Host Check Client Interface (Windows only)—The Host Check Client Interface is an API that allows you to run your own DLLs using Host Checker. Through the interface, you can prompt Host Checker to run a DLL that you already installed on the user’s system or distributed as part of a corporate OS image, including programs that check compliance with corporate images, antivirus software, and personal firewall clients. Host Checker runs the specified DLL when a user signs into the IVE, and then bases its subsequent actions on the success or failure result that the DLL returns. For example, you may deny a user access to the IVE if the client check software fails. For more information, see the J.E.D.I. Solution Guide available on the Juniper Networks Customer Support Center. Host Check Server Integration Interface (Windows only)—The Host Check Server Integration Interface is an API that allows you to tightly integrate a J.E.D.I. compliant system with the IVE. Like the Host Check Client Interface, you can use the Host Check Server Integration Interface to prompt Host Checker to run third-party software on the client, including host integrity scans, malware detectors, and virtual environments. With this interface, you may also 221 Juniper Networks Secure Access Administration Guide specify with granularity what Host Checker should do based on the result of the diverse policy checks that the third-party applications conduct. You can invoke these policies to dynamically map users to realms, roles, and resources based on the results of individual policies contained in your software package. For more information, see the J.E.D.I. Solution Guide available on the Juniper Networks Customer Support Center. 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 269. Using these endpoint defense components, you can develop a layered protection approach, managing and provisioning a variety of endpoint checks all from within the IVE. 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. Then, you may use Cache Cleaner to remove residual files and clear the user’s application cache once the user has terminated the IVE session. This section includes the following information about endpoint defense: 222 “Host Checker” on page 223 “Cache Cleaner” on page 269 Chapter 11 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 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, and specific operating systems from a wide variety of industry leaders; and custom rules that check for certain third party DLLs, ports, processes, files, and registry key settings. 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: “Licensing: Host Checker availability” on page 224 “Task summary: Configuring Host Checker” on page 224 “Creating global Host Checker policies” on page 226 “Enabling the Secure Virtual Workspace” on page 244 “Implementing Host Checker policies” on page 251 “Remediating Host Checker policies” on page 255 “Defining Host Checker pre-authentication access tunnels” on page 258 “Specifying general Host Checker options” on page 262 “Specifying Host Checker installation options” on page 264 “Using Host Checker logs” on page 267 223 Juniper Networks Secure Access Administration Guide Licensing: Host Checker availability Host Checker is a standard feature on all Secure Access appliances. You do not need a special license to use the baseline Host Checker features. However, note that Host Checker custom expressions, Host Checker detailed rules, Host Checker remediation, and other features may not be available on the SA 700 and are only available on all other Secure Access products by special license. Additionally, in order to support more than 25 users with the advanced endpoint defense malware detection policies, you must buy an upgrade license. Task summary: Configuring Host Checker To configure Host Checker, 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 226. 2. Configure additional system-level options through the Authentication > Endpoint Security > Host Checker page of the admin console as necessary: 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 255. 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 258. 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 262. 3. Determine at which levels within the IVE access management framework you want to enforce the policies: 224 Licensing: Host Checker availability 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. Chapter 11: Host Checker 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 253. 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 264. 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 267. Task summary: Configuring Host Checker 225 Juniper Networks Secure Access Administration Guide 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: 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 Advanced Endpoint Defense: Malware Protection policies download malware protection software to client computers before users sign into the IVE. Note that these policies only work on Windows systems. For more information, see “Enabling pre-defined client-side policies (Windows only)” on page 227. Pre-defined rules (check for third party applications)—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 in order 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 232. Custom rules (check for additional requirements)—If the pre-defined clientside 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 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. For more information, see “Specifying customized requirements using custom rules” on page 236. 226 Creating global Host Checker policies Chapter 11: Host Checker Custom integrated applications (implement through server API)—For Windows clients, you can define Host Checker server-side policies using the Host Check Server Integration Interface (API) and zip up the policies into a third-party integration package. The IVE recognizes the policies when you upload your third-party integration package to the IVE. For more information about creating these policies, see the J.E.D.I. Solution Guide available on the Juniper Networks Customer Support Center. For information about enabling the server-side policies that you create, see “Enabling customized server-side policies” on page 242. 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 pre-defined client-side policies (Windows only) 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. For more information, see “Enabling connection control policies” on page 228. The advanced endpoint defense malware detection policies download Whole Security’s Confidence Online software to client computers. This software protects users from malicious software such as worms, viruses, key logger software, screen capture software, and trojan horses. For more information, see “Enabling advanced malware protection policies” on page 228. NOTE: The connection control and advanced endpoint defense malware detection policies only work on Windows systems. The connection control policy is not supported on Windows 98 systems. Creating global Host Checker policies 227 Juniper Networks Secure Access Administration Guide Enabling connection control policies The pre-defined connection control Host Checker policy prevents attacks on Windows client computers from other infected computers on the same physical network. The Host Checker connection control policy blocks all incoming TCP 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. The IVE does not support the Host Checker connection control policy on Windows 98 client computers. 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 253. NOTE: You must evaluate or enforce the connection control policy at the realm level to make the policy effective on client computers. Enabling advanced malware protection policies If you are properly licensed, you can enable advanced endpoint defense malware detection policies through Host Checker. These policies download and run Whole Security Confidence Online software on your users’ computers. This software scans for malicious programs, including: 228 Trojan horses—Hackers write trojan horses to remotely administer an infected machine. Trojan horses almost always install themselves on a user’s computer without the authorized user’s knowledge. Creating global Host Checker policies Chapter 11: Host Checker Key logger software—Hackers write key logger software to eavesdrop on a user by capturing and logging his typed keystrokes. Key logger software installs itself on a user’s computer without the authorized user’s knowledge. Monitoring applications—Monitoring applications are end-user software applications that monitor and record user activity. Users typically install this software themselves to monitor the activity of children, spouses, and other users who share their computers. Remote controls—Remote control applications are commercial applications such as VNC that offer easy remote access to an authorized user for computer administration activities. To use the Whole Security malware protection software, you need to enable the Advanced Endpoint Defense Malware Detection option at the system level and enforce it at the realm, role, and/or resource policy levels. You do not need to create or configure advanced endpoint defense malware detection policies—Host Checker creates them for you when you enable the option at the system level. Note that we recommend that you require and enforce an advanced endpoint defense malware detection policy at the realm level so that Host Checker can download the Confidence Online software to your users’ computers and check for potential threats before they sign in to the IVE, but after their Windows logon. Once Confidence Online begins running, it continues to scan for and block threats throughout the user’s IVE session. NOTE: Each user’s computer must be able to access the Whole Security site (update.wholesecurity.com) so that Confidence Online can periodically download the latest definition files. To enable and configure advanced endpoint defense malware detection policies: 1. In the admin console, choose Authentication > Endpoint Security > Host Checker. 2. Under Options, select the Enable Advanced Endpoint Defense: Malware Protection checkbox. 3. Select the Enable Silent Enforcement of Signature Scan checkbox if you do not want Confidence Online to notify users when it blocks trojan horse, key logger software, and other applications that it deems malicious. (Note that Confidence Online accesses a Whole Security server on a daily basis in order to keep its list of malicious applications current.) Creating global Host Checker policies 229 Juniper Networks Secure Access Administration Guide 4. Select the Enable User Control over disabling Behavior Blocker checkbox if you want to enable users to choose whether or not to block monitoring applications, remote control software, and other potentially legitimate applications. If you select this option, users can view and control blocked applications through a Confidence Online icon in their system trays. (For more information, see the Confidence Online end-user help system.) If you do not select this option, Confidence Online simply blocks these applications without user interaction. NOTE: Category 1 and Category 2 Signature Scans—Restricted users, power users, and administrators can install and run the scanning feature in Confidence Online. The scanning feature is supported on Windows 98 SE, Windows ME, Windows NT4, Windows 2000, and Windows XP systems. Behavior Blocker—Only administrators can install and run the behavior blocker feature in Confidence Online. The behavior blocker feature is supported on Windows 2000 and Windows XP systems. 5. Click Save Changes. The IVE enables the following advanced endpoint defense malware detection policies: Advanced Endpoint Defense: Malware Protection.Behavior Blocker— This policy is created by Whole Security. It enables the Confidence Online behavior blocker software to block keystroke logger software, screen capture software, and other applications that try to eavesdrop on user sessions. Advanced Endpoint Defense: Malware Protection.Category One Threats (Trojan Horses and Key Loggers)—This policy is created by Whole Security. It enables the Confidence Online software to block trojan horse programs, spyware, malware, and other malicious applications. Advanced Endpoint Defense: Malware Protection.Category Two Threats (Monitoring Applications and Remote Controls)—This policy is created by Whole Security. It enables the Confidence Online software to block monitoring applications, remote control software, and other potentially legitimate applications. Each of these policies includes remediation instructions that display a message to users if they do not pass the specified policy. The message tells the users to follow instructions in the pop-up window to remediate their machines. 6. Implement the advanced endpoint defense malware detection policies at the realm, role, or resource policy levels using the options described in “Configuring Host Checker restrictions” on page 253. (You must at least evaluate or enforce a advanced endpoint defense malware detection policy at the realm level to make the policy effective on client computers.) 230 Creating global Host Checker policies Chapter 11: Host Checker NOTE: When enforcing advanced endpoint defense malware detection policies, note that: You cannot modify these policies—only enable or disable them. Also, since you cannot modify these policies, the IVE does not display them in the Policies section of the Authentication > Endpoint Security > Host Checker page with other configurable policies. If your concurrent user licenses for the IVE and Whole Security do not match, you are constrained by the lesser of the two licenses. For example, if you have a license that allows 100 concurrent IVE users and another license that allows for 50 concurrent Whole Security users, this constraint allows only 50 concurrent users to access an IVE enabled with Advanced Endpoint Defense Malware Protection policies. If you have licensed GINA and Whole Security, you should be aware that GINA runs prior to the user’s Windows logon, and the download of the Whole Security Confidence Online software occurs after the user signs in to Windows. Therefore, Whole Security does not perform its stated malware protection until after Windows logon. If you are using Network Connect, Host Checker, GINA, and Whole Security, but the end-user is not in user mode when their system tries to initiate Host Checker, the end-user may receive errors. Make certain you have configured the system to start GINA prior to the Windows logon, and Whole Security after Windows logon. NOTE: The Whole Security Confidence Online feature supported by Host Checker cannot be localized currently. For more information about localizing the IVE, see “Localizing the user interface” on page 844. 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, and registry keys. When creating the policies, you must define the policy name, enable pre-defined rules, or create custom rules that run the specified checks. Optionally, you can specify how Host Checker should evaluate multiple rules within a single policy. When creating the policies, you must define the policy name, and either enable pre-defined rules, or create custom rules that run the specified checks. Optionally, you can specify how Host Checker should evaluate multiple rules within a single policy. To create a standard client-side policy: 1. In the admin console, choose Authentication > Endpoint Security > Host Checker. 2. Under Policies, click New. Creating global Host Checker policies 231 Juniper Networks Secure Access Administration Guide 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 232 “Specifying customized requirements using custom rules” on page 236 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 242. 6. (Recommended) Specify remediation options for users whose computers do not meet the requirements specified in the policy. For instructions, see “Configuring Host Checker remediation” on page 257. (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 253. 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 in order to ensure that the integrated third party applications that you specify are running on your users’ computers in accordance with your specifications. To create an integrated third-party application policy using pre-defined 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 231 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: 232 Predefined: AntiVirus—Select this option to create a rule that checks for the antivirus software that you specify. Predefined: Firewall—Select this option to create a rule that checks for the firewall software that you specify. Predefined: Malware—Select this option to create a rule that checks for the malware protection software that you specify. Creating global Host Checker policies Chapter 11: Host Checker Predefined: Spyware—Select this option to create a rule that checks for the spyware protection software that you specify. Predefined: OS Checks—Select this option to create a rule that checks for the Windows operating systems and minimum service pack versions that you specify. (Any service pack whose version is greater than or equal to the version you specify satisfies the policy.) 4. In the Add Predefined Rule page: In the Rule Name field, enter an identifier for the rule. Under Criteria, choose the specific application versions 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. (Antivirus policies only) Select Specify age in days to configure this Host Checker policy to require a maximum acceptable age of the virus definition files. For Maximum age of definition files, specify the maximum number of days. (Antivirus policies only) Select Virus signatures must be up to date to configure this Host Checker policy to require current virus signatures on the client computer. To enable this functionality in the policy, you must also manually or automatically import the current virus signature list on the Authentication > Endpoint Security > Host Checker page. (See “Configuring virus signature version monitoring” on page 234.) Click Save Changes. 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 231. 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. Creating global Host Checker policies 233 Juniper Networks Secure Access Administration Guide Configuring virus signature version monitoring You can configure Host Checker to monitor and verify that the virus signatures installed on client computers are up to date. Host Checker uses a list of the current virus signatures from the vendor(s) you specify for pre-defined antivirus rules in a Host Checker policy. If a client computer does not have the current virus signatures installed, the Host Checker policy fails. You can obtain the current virus signatures list 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 a specified interval. For example, you might want to manually download and import the current virus signatures list from a network server or local drive if you want to first test the list, or if the IVE is unable to automatically access the Juniper Networks staging site. Or, you can manually download the current list to a local staging site on your internal network, and then automatically import the list from that internal staging site. To configure virus signature version monitoring: 1. While adding a pre-defined antivirus rule on the Authentication > Endpoint Security > Host Checker > Select Policy > Add Predefined Rule: Antivirus page, select the Virus signatures must be up to date option. (See “Checking for third-party applications using pre-defined rules (Windows only)” on page 232.) 2. Choose Authentication > Endpoint Security > Host Checker. 3. Click Virus signature version monitoring. 4. To configure the IVE to automatically import the current virus signatures list: a. Select Auto-update virus signatures list. b. For Download path, enter the URL of the staging site where the current virus signatures list is stored. You can specify the URL of the Juniper Networks staging site or your own staging site. The default URL is the path to the Juniper Networks staging site: https://download.juniper.net/software/av/uac/avupdate.dat c. For Download interval, specify how often you want the IVE to automatically import the current virus signatures list. d. If the staging site is password protected, enter the credentials in Username and Password. To access the Juniper Networks staging site, you must enter the credentials for a Juniper Networks Support account. You can also use basic HTTP authentication to protect and access your own staging site. 5. To manually import the current virus signatures list: a. 234 Creating global Host Checker policies Download the virus signatures list from the staging site to a network server or local drive on your computer. Chapter 11: Host Checker b. Under Manually import virus signatures list, click Browse, select the virus signatures list, and then click OK. 6. Click Save Changes. NOTE: If you use your own staging site for storing the current virus signatures list, 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 621. 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 232.) 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. c. Click the ESAP link. d. 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. Creating global Host Checker policies 235 Juniper Networks Secure Access Administration Guide 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. 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. 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: 236 Configure Host Checker to check for custom DLLs that perform customized client-side checks. Creating global Host Checker policies Chapter 11: Host Checker 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. NOTE: You can only check for registry keys and custom third-party DLLs 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 231 or click on an existing policy in the Policies section of the page. 3. Click the tab that corresponds to the operating system for which you want to specify Host Checker options—Windows, Mac, or Linux. 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. 4. Under Rule Settings, choose one of the following options and click Add. The Add Custom Rule page for the rule type appears. 3rd Party NHC Check (Windows only)—Use this rule type to specify the location of a custom DLL that you write with the Host Check Client Interface. 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. (For information about creating a custom DLL using the Host Check Client Interface, see the J.E.D.I. Solution Guide on the Juniper Networks Customer Support Center.) 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. Creating global Host Checker policies 237 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. 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. 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 241. 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 and Linux systems have OpenSSL installed by default—you can determine the MD5 checksum by using this command: openssl md5 v. 238 Creating global Host Checker policies Click Save Changes. Chapter 11: Host Checker 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 241. 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. vi. Specify the MD5 checksum value of each file to which you want the policy to apply (optional). On Macintosh and Linux, you can determine the MD5 checksum by using this command: openssl md5 vii. Click Save Changes. Creating global Host Checker policies 239 Juniper Networks Secure Access Administration Guide Registry Setting (Windows only)—Use this rule type to control the corporate PC images, system configurations, and software settings that a client must have in order 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 4.1 is newer than 3.3.1 vii. Click Save Changes. NOTE: If you specify only the key and subkey, Host Checker simply verifies the existence of the subkey folder in the registry. 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 231. 240 Creating global Host Checker policies Chapter 11: 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 15: 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 16: 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 \ \Local Settings\Temp In an Custom File rule for Macintosh and Linux, 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 Macintosh and Linux Environment variable Example Macintosh Value Example Linux Value <%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. Creating global Host Checker policies 241 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 in order 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 in order to gain access. Custom—Select this option to customize the rules that the user’s computer must meet in order 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) using the following guidelines: Enter the name of the rules in the Rules expression text box. Use the AND operator to require two rules or sets of rules to return a true value. Use the OR operator to require either of two rules or sets to return a true value. Use parenthesis to combine sets of rules. For example, you can use the following expression 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. Enabling customized server-side policies For Windows clients, you can create global Host Checker policies which take a J.E.D.I. DLL that you upload to the IVE and run it on client machines. For more information about creating these policies, see the J.E.D.I. Solution Guide on the Juniper Networks Customer Support Center. 242 Creating global Host Checker policies Chapter 11: Host Checker Uploading a Host Checker policy package to the IVE In order 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 242. 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 253. 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 . . For example, to enforce the FileCheck policy in the myPestPatrol package, use myPestPatrol.FileCheck. For instructions, see “Configuring Host Checker restrictions” on page 253. 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. Creating global Host Checker policies 243 Juniper Networks Secure Access Administration Guide 5. (Optional) Specify remediation instructions and actions for users whose computers do not meet the requirements specified in the policy. For instructions, see “Configuring Host Checker remediation” on page 257. 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 253. 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: 244 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. Enabling the Secure Virtual Workspace Chapter 11: Host Checker 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. 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. 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. Enabling the Secure Virtual Workspace 245 Juniper Networks Secure Access Administration Guide 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. 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 > Host Checker. 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 > Host Checker. 2. Under Policies, click New Secure Virtual Workspace Policy. 3. Under Permissions, check the appropriate checkboxes for the items to which you want to grant permissions: Printers—Select to allow end-user access to network printers. Restricted View of Files—When Restricted View is set, only the directories Documents and Settings, Program Files, and the Windows system folders on the system drive (typically c:) are available within SVW. NOTE: If you set the Restricted View of Files option, and your end-users configure partitioned drives, they will be unable to access any applications or files residing on any drive other than the system (c:) drive. If you allow your end-users to partition drives, you should not use the Restricted View. 246 Enabling the Secure Virtual Workspace Chapter 11: Host Checker 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. 4. 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 > Host Checker. 2. Under Policies, click New Secure Virtual Workspace Policy or click the hyperlinked name of an existing Secure Virtual Workspace policy. 3. Under Applications, select the checkboxes for the types of applications you want to enable: Enabling the Secure Virtual Workspace 247 Juniper Networks Secure Access Administration Guide 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. 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. 4. 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 251. 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. 248 Enabling the Secure Virtual Workspace Chapter 11: Host Checker To specify security options for a new Secure Virtual Workspace policy: 1. In the admin console, choose Authentication > Endpoint Security > Host Checker. 2. Under Policies, click New Secure Virtual Workspace Policy or click the hyperlinked name of an existing Secure Virtual Workspace policy. 3. 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 256byte encryption keys. 4. 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. 5. 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 > Host Checker. 2. Under Policies, click New Secure Virtual Workspace Policy or click the hyperlinked name of an existing Secure Virtual Workspace policy. 3. 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. 4. Specify the desktop wallpaper image (Optional). 5. Specify the desktop background color (Optional). 6. Specify 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]. 7. Continue to define the policy or click Save Changes. Enabling the Secure Virtual Workspace 249 Juniper Networks Secure Access Administration Guide Defining Secure Virtual Workspace remediation policy To specify remediation options for a new Virtual Workspace policy: 1. In the admin console, choose Authentication > Endpoint Security > Host Checker. 2. Under Policies, click New Secure Virtual Workspace Policy or click the hyperlinked name of an existing Secure Virtual Workspace policy. 3. Under Remediation, select remediation options for users whose computers do not meet the requirements specified in the policy. For instructions, see “Configuring Host Checker remediation” on page 257. 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. Evaluate Other Policies—Select to open list boxes that allow you to choose other existing Host Checker policies to be evaluated when initiating the Secure Virtual Workspace. Remediate—Select to apply remediation rules. 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. 4. Click Save Changes. 250 Enabling the Secure Virtual Workspace Chapter 11: Host Checker 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, 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 realm-level restrictions through the Administrators > Admin Realms > SelectRealm > Authentication Policy > Host Checker page or the Users > User Realms > SelectRealm > Authentication Policy > Host Checker page of the admin console. Role—When 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. 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. Implementing Host Checker policies 251 Juniper Networks Secure Access Administration Guide 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. 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. 252 Implementing Host Checker policies Chapter 11: 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. If you enable dynamic policy evaluation for Host Checker (see “Dynamic policy evaluation” on page 40), 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 262. 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. Navigate to: Administrators > Admin Realms > Select Realm > Authentication Policy > Host Checker Users > User Realms > Select Realm > Authentication Policy > Host Checker b. Choose one of the following options for either all available policies or for individual policies listed in the Available Policies column: Evaluate Policies—Evaluates without enforcing the policy on the client and allows user-access. This option does not require Host Checker to be installed during the evaluation process; however, Host Checker is installed once the user signs in to the IVE. Implementing Host Checker policies 253 Juniper Networks Secure Access Administration Guide c. 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 checkbox 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. Navigate to: Administrators > Admin Roles > Select Role > General > Restrictions > Host Checker Users > User Roles > Select Role > General > Restrictions > Host Checker b. Choose one of the following options: c. 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 checkbox 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. 254 Implementing Host Checker policies Click Expressions. Chapter 11: Host Checker 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 855. 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. 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 855. These options allow you to control which version of an application or service runs on client machines. Remediating Host Checker policies When defining a Host Checker policy, you can specify remediation actions that you want Host Checker to take if a user’s computer does not meet the requirements of the policy. For example, you can display a remediation page to the user that contains your specific instructions and links to resources to help the user bring his computer into compliance with the Host Checker policy requirements. For example, the user may see the following remediation page that contains custom instructions and a link to resources: 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. For each Host Checker policy, you can configure two types of remediation actions: Remediating Host Checker policies 255 Juniper Networks Secure Access Administration Guide 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, you can kill processes, delete files, or launch an alternate policy when the initial policy fails. On Windows, you can also call the HCIF_Module.Remediate () API function as part of a 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.) 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 231 or “Enabling customized server-side policies” on page 242. 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. After the user signs in: 256 Remediating Host Checker policies 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. (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. Chapter 11: Host Checker (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. Configuring 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 231 “Enabling customized server-side policies” on page 242 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: , ,
, , and . For example: You do not have the latest signature files. Click here to download the latest signature files. 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 259. Remediating Host Checker policies 257 Juniper Networks Secure Access Administration Guide Evaluate other policies—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. For example, if a user attempts to access the IVE from an outside client computer such as a kiosk, you can use this option to evaluate an alternate policy that requires the user to access the IVE in a Sygate Virtual Desktop environment. Select the alternate policy in the HC Policies list and then click Add. NOTE: If you configure an alternate policy to use its own alternate policy, Host Checker does not evaluate that “second-level” alternate policy for the current policy. In other words, Host Checker only evaluates one alternate policy per transaction. 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. For more information, see the J.E.D.I. Solution Guide on the Juniper Networks Customer Support Center. Kill Processes—On each line, enter the name of one or more processes you want to kill if the user’s computer does not meet the policy requirements. You can include an optional MD5 checksum for the process. (You cannot use wildcards in the process name.) For example: keylogger.exe MD5: 6A7DFAF12C3183B56C44E89B12DBEF56 Delete Files—Enter the names of files you want to delete if the user’s computer does not meet the policy requirements. (You cannot use wildcards in the file name.) Enter one file name per line. For example: c:\temp\bad-file.txt /temp/bad-file.txt 4. Click Save Changes. 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: 258 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. Defining Host Checker pre-authentication access tunnels Chapter 11: Host Checker 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 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 243. 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 34: 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. Defining Host Checker pre-authentication access tunnels 259 Juniper Networks Secure Access Administration Guide 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. 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:HCIF-Policy: HCIF-IVE-Tunnel: :port :port where: 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. 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: :port :port where: 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. is the IP address or host name of the back-end policy server. The IVE resolves the host name you specify. 260 Defining Host Checker pre-authentication access tunnels Chapter 11: Host Checker 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: 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 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 Defining Host Checker pre-authentication access tunnels 261 Juniper Networks Secure Access Administration Guide NOTE: If you are deploying a client-side or server-side third-party DLL, keep the following in mind: 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 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.) For more information on third-party DLLs, see the J.E.D.I. Solution Guide on the Juniper Networks Customer Support Center. 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. 262 Specifying general Host Checker options Chapter 11: Host Checker 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. 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: Specifying general Host Checker options 263 Juniper Networks Secure Access Administration Guide 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. NOTE: If you configure the Client-side process, login inactivity timeout option for both Host Checker and Cache Cleaner, the IVE uses the larger of the two timeout settings. 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 40. 3. Click Save Changes. 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 253.) 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. 264 Specifying Host Checker installation options Chapter 11: Host Checker 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 Macintosh and 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. NOTE: If Microsoft Vista is running on the user’s system, the user must click the setup link that appears during the installation process to continue installing the setup client and Host Checker. On all other Microsoft operating systems, the setup client and Host Checker install automatically. The user or administrator manually installs Host Checker (Windows only)— Download the Host Checker installer from the Maintenance > System > Installers page of the admin console and use it to manually install Host Checker on the user’s system. NOTE: To install Host Checker, users must have appropriate privileges, as described in the Client-side Changes Guide on the Juniper Networks Customer Support Center. If the user does not have these privileges, use the Juniper Installer Service available from the Maintenance > System > Installers page of the admin console to bypass this requirement. Removing the Juniper ActiveX Control 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. Specifying Host Checker installation options 265 Juniper Networks Secure Access Administration Guide 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: You can check system-level processes at both realm enforce and realm evaluate. You can check user-level processes only at realm evaluate. If you have user-level processes at realm evaluate, create a separate Network Connect role featuring only system-level policy checks that can be performed before Windows has completely launched on the client. Ensure that this role allows connectivity to the Windows Domain infrastructure in your secure network to support drive mapping, software updates, and group policies, for example. Mapping your users to this role allows the GINA authentication to complete. This role is in addition to the final role that you want the user to be mapped. NOTE: For more information on the GINA automatic sign-in function, see “Automatically signing into Network Connect using GINA” on page 527. 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: 266 Specifying Host Checker installation options Chapter 11: Host Checker On Windows, the user must have administrator privileges in order for the IVE to automatically install the Host Checker application on the client. For more information, see the Client-side Changes Guide on the Juniper Networks Customer Support Center. If a user uninstalls Host Checker and then signs in to an IVE for which the Auto-upgrade Host Checker option is not enabled, the user no longer has access to Host Checker. 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. Using Host Checker logs 267 Juniper Networks Secure Access Administration Guide 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. 268 Using Host Checker logs Chapter 12 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. This section contains the following information about Cache Cleaner: “Licensing: Cache Cleaner availability” on page 269 “Setting global Cache Cleaner options” on page 270 “Implementing Cache Cleaner options” on page 273 “Specifying Cache Cleaner installation options” on page 277 “Using Cache Cleaner logs” on page 278 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 269 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: Specified hosts and domains—If you enable WSAM or JSAM, you may want to configure Cache Cleaner to clear additional hosts and domains. When a user browses the Internet outside the IVE using WSAM or JSAM, Internet files appear in his temporary Internet file folder. To delete these files using Cache Cleaner, you must specify the appropriate host name (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. In the admin console, choose Authentication > Endpoint Security > Cache Cleaner. 2. Under Options: a. In the Cleaner Frequency field, specify how often Cache Cleaner runs. Valid values range from 1-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 in the Browser Cache and Files and Folders sections below. b. In the Status Update Frequency field, specify how often the IVE expects Cache Cleaner to update itself. Valid values range from 1-60 minutes. For the Client-side process, login inactivity timeout option, specify an interval to control timing out in the following situations: 270 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. Chapter 12: Cache Cleaner If the user is downloading Cache Cleaner over a slow connection, increase the interval to allow enough time for the download to complete. NOTE: If you configure the Client-side process, login inactivity timeout option for both Host Checker and Cache Cleaner, the IVE uses the larger of the two timeout settings. c. Select the Disable AutoComplete of web addresses checkbox 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. d. Select the Disable AutoComplete of usernames and passwords checkbox 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: e. 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 checkbox 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: f. Select For IVE session only to specify that the IVE should restore the user’s cached passwords at the end of his IVE session. Select Permanently to permanently delete the user’s cached passwords. Select the Uninstall Cache Cleaner at logout checkbox if you want the IVE to uninstall Cache Cleaner from the client machine when a user’s session ends. Setting global Cache Cleaner options 271 Juniper Networks Secure Access Administration Guide 3. Under Browser Cache, enter one or more host names 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 host names, so enter all possible representations of a server, such as its host name, FQDN, and IP address. 4. Under Files and Folders: a. Specify either: the name of a file that you want Cache Cleaner to remove or the complete directory path to a folder whose contents you want Cache Cleaner to remove. If you specify a directory, select Clear Subfolders to also clear the contents of any subdirectories within this directory. b. Select the Clear folders only at the end of session checkbox 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 \Local Settings\Temporary Internet Files\* in the Files and Folders field. 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 field, 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. 272 Setting global Cache Cleaner options Chapter 12: 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 a: 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|Create Rule > Custom Expression. 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. To implement Cache Cleaner restrictions at the resource policy level, navigate to: Users > Resource Policies > Select Resource > Select Policy > Detailed Rules > Select|Create Rule > Condition Field. 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 may 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 273 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 homepage 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 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 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 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. 274 Implementing Cache Cleaner options Chapter 12: 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 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 due to 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. Navigate to: 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. If you want to implement Cache Cleaner at the realm level: a. Navigate to: Users > User Realms > Select Realm > Authentication Policy > Cache Cleaner Implementing Cache Cleaner options 275 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. If you want to implement Cache Cleaner at the role level: a. Navigate to: Administrators > Admin Roles > Select Role > General > Restrictions > Cache Cleaner Users > User Roles > Select Role > General > Restrictions > Cache Cleaner b. Check the Enable Cache Cleaner option. Requires Cache Cleaner to be running in order for the user to meet the access requirement. 4. If you want to create role-mapping rules based on a user’s Cache Cleaner status: a. Navigate to: Users > User Realms > Select Realm > Role Mapping > Select|CreateRule > CustomExpression b. Write a custom expression for the role mapping rule to evaluate Cache Cleaner’s status using the cacheCleaner variable. 5. If you want to implement Cache Cleaner at the resource policy level: a. Navigate to: Users > Resource Policies > Select Resource > Select Policy > Detailed Rules > Select|Create Rule > Condition Field b. Create a custom expression in a detailed rule. 276 Implementing Cache Cleaner options Chapter 12: 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 due to 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 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 ActiveX control, see “Removing the Juniper ActiveX Control” on page 265. Specifying Cache Cleaner installation options 277 Juniper Networks Secure Access Administration Guide Using Cache Cleaner logs Use the 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: 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 Logs > 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. 278 Using Cache Cleaner logs Part 4 Remote access 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 25. 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 18 briefly compares three of the IVE’s access mechanisms: Network Connect, Windows Secure Application Manager (WSAM), and Java Secure Application Manager (JSAM). Table 18: Comparison of remote client access methods 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. Requires only a single Java Installation handled via Active X control, Java delivery, applet installed on the client and standalone installers. 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. This section contains the following information about remote access mechanisms: “Web rewriting” on page 281 279 Juniper Networks Secure Access Administration Guide 280 “Hosted Java applets” on page 357 “File rewriting” on page 371 “Secure Application Manager” on page 395 “Telnet/SSH” on page 449 “Terminal Services” on page 461 “Secure Meeting” on page 493 “Email Client” on page 513 “Network Connect” on page 521 Chapter 13 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 282 “Task summary: Configuring the Web rewriting feature” on page 282 “Web URL rewriting overview” on page 283 “Defining resource profiles: Custom Web applications” on page 288 “Defining resource profiles: Citrix Web applications” on page 307 “Defining resource profiles: Microsoft OWA” on page 311 “Defining resource profiles: Lotus iNotes” on page 313 “Defining resource profiles: Microsoft Sharepoint” on page 315 “Defining role settings: Web URLs” on page 316 “Defining resource policies: Overview” on page 322 “Defining resource policies: Web access” on page 324 “Defining resource policies: Single sign-on” on page 325 “Defining resource policies: Caching” on page 332 “Defining resource policies: External Java applets” on page 336 “Defining resource policies: Rewriting” on page 339 “Defining resource policies: Web compression” on page 349 “Defining resource policies: Web proxy” on page 351 “Defining resource policies: HTTP 1.1 protocol” on page 354 281 Juniper Networks Secure Access Administration Guide “Defining resource policies: General options” on page 355 “Managing resource policies: Customizing UI views” on page 356 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 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 Users > Resource Profiles> Web Application Pages page of the admin console. For instructions, see: “Defining resource profiles: Custom Web applications” on page 288 “Defining resource profiles: Citrix Web applications” on page 307 We recommend that you use resource profiles to configure Web rewriting (as described above). However, if you do not want to use resource profiles, you can configure Web rewriting using role and resource policy settings in the following pages of the admin console instead: a. Create resource policies that enable access to Web sites using settings in the Users > Resource Policies> Web > Access > Web ACL page of the admin console. For instructions, see “Defining resource policies: Web access” on page 324. 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: 282 Licensing: Web rewriting availability “Defining resource policies: Single sign-on” on page 325 “Defining resource policies: Caching” on page 332 Chapter 13: Web rewriting c. “Defining resource policies: External Java applets” on page 336 “Defining resource policies: Rewriting” on page 339 “Defining resource policies: Web compression” on page 349 “Defining resource policies: Web proxy” on page 351 “Defining resource policies: HTTP 1.1 protocol” on page 354 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 55. 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 316. 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 319. 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 319. 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 355. NOTE: Certain Web rewriting features (such as pass-through 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. Web URL rewriting overview 283 Juniper Networks Secure Access Administration Guide Standard Web rewriting policy types include: 284 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 290 (recommended) or “Defining resource policies: Web access” on page 324. 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 285. For configuration instructions, see “Defining a single sign-on autopolicy” on page 292 (recommended) or “Defining resource policies: Single sign-on” on page 325. 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 296 (recommended) or “Defining resource policies: Caching” on page 332. 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 298 (recommended) or “Defining resource policies: External Java applets” on page 336. Rewriting—Rewriting policies specify resources that the IVE should not intermediate, minimally intermediation (as explained in “Passthrough-proxy overview” on page 286), or only intermediate selectively. For configuration instructions, see “Defining a rewriting autopolicy” on page 300 (recommended) or “Defining resource policies: Rewriting” on page 339. Web compression—Web compression policies specify which types of Web data the IVE should and should not compress, as explained in “Compression” on page 839. For configuration instructions, see “Defining a Web compression autopolicy” on page 304 (recommended) or “Defining resource policies: Web compression” on page 349. 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 351. 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 443. 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 354. Chapter 13: Web rewriting 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 355. 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 193) as well as system data stored by system variables (described in “System variables and examples” on page 860). You can also specify whether or not users can modify this information. Headers/Cookies policy—This type of Remote SSO policy specifies resources, such as customized applications, to which you can send custom headers and cookies. If a user’s 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 292 (recommended method) “Writing a remote SSO Form POST resource policy” on page 328 “Writing a remote SSO Headers/Cookies resource policy” on page 330 Web URL rewriting overview 285 Juniper Networks Secure Access Administration Guide Passthrough-proxy overview The pass-through 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: Via an IVE port—When specifying an application for the pass-through 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 pass-through 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. 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 pass-through 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 pass-through proxy if they sign into the IVE using its IP address. 286 Web URL rewriting overview Chapter 13: Web rewriting Just as with the Content Intermediation Engine, the pass-through 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: Pass-through proxy URLs must be host names. Paths of host names are not supported. Juniper Networks strongly recommends that you not mix pass-through proxy Port mode and pass-through proxy Host mode. The pass-through proxy option works only for applications that listen on fixed ports and where the client does not make direct socket connections. To use pass-through 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. Task summary: Configuring pass-through proxy To configure the Web rewriting feature: 1. Create resource profiles that enable access to Web applications, create supporting Web rewriting autopolicies that enable pass-through 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 Application Pages page of the admin console. For instructions, see “Defining resource profiles: Custom Web applications” on page 288. Alternatively, you can: a. Create resource policies that enable access to Web applications using settings in the Users > Resource Policies> Web > Access > Web ACL page of the admin console. For instructions, see “Defining resource policies: Web access” on page 324. b. Create supporting Web rewriting resource policies that enable pass-through proxy using settings in the Users > Resource Policies> Web > Rewriting > Web ACL page of the admin console. For instructions, see “Defining resource policies: Rewriting” on page 339. c. Determine which user roles may access the Web applications that you want to intermediate with pass-through 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 55. Web URL rewriting overview 287 Juniper Networks Secure Access Administration Guide 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 316. 2. If your pass-through 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: 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 558. 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 601 and “Associating a certificate with a virtual port” on page 606. Examples of using pass-through 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 71.) 288 Defining resource profiles: Custom Web applications Chapter 13: Web rewriting To create a custom Web application resource profile: 1. Navigate to the Users > Resource Profiles > Web Applications/Pages page in the admin console. 2. Click New Profile. 3. Enter a unique name and optionally a description for the resource profile. 4. 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 290. (The IVE uses the specified URL to define the default bookmark for the resource profile.) 5. 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 290. 6. (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 292 “Defining a caching autopolicy” on page 296 “Defining a Java access control autopolicy” on page 298 “Defining a rewriting autopolicy” on page 300 “Defining a Web compression autopolicy” on page 304 7. Click Save and Continue. 8. 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. 9. Click Save Changes. 10. (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 305. (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 resource profiles: Custom Web applications 289 Juniper Networks Secure Access Administration Guide Defining base URLs When creating a Web resource profile, you must use the following format when defining base URLs: [protocol://]host[:port][/path] Within this format, the components are: Protocol (required)—Possible values: http:// and https://. Note that you cannot use special characters within the protocol. Host (required)—Possible values: DNS Hostname—For example: www.juniper.com IP address—You must enter the IP address in the format: a.b.c.d. For example: 10.11.149.2. You cannot use special characters in the IP address. Ports (optional)—You must use the delimiter “:” when specifying a port. For example: 10.11.149.2/255.255.255.0:* Path (optional)—When specifying a path for a base URL, the IVE does not allow special characters. If you specify a path, you must use the “/” delimiter. For example, http://www.juniper.net/sales. 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: 290 “Defining resource profiles: Custom Web applications” on page 288 “Defining resource profiles: Citrix Web applications” on page 307 “Defining resource profiles: Microsoft OWA” on page 311 “Defining resource profiles: Lotus iNotes” on page 313 Defining resource profiles: Custom Web applications Chapter 13: Web rewriting “Defining resource profiles: Microsoft Sharepoint” on page 315 2. If available, click the Show ALL autopolicy types button to display the autopolicy configuration options. 3. If it is not already enabled, select the Autopolicy: Web Access Control checkbox. 4. In the Resource field, specify the Web server or HTML page to which you want to control access using the format: [protocol://]host[:ports][/path]. For detailed guidelines, see “Defining Web resources” on page 291. 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 Web resources When creating a Web resource profile (for example, in “Defining resource profiles: Custom Web applications” on page 288), 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 19: 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. Defining resource profiles: Custom Web applications 291 Juniper Networks Secure Access Administration Guide Ports (optional)—You must use the delimiter “:” when specifying a port. For example: 10.11.149.2/255.255.255.0:* Table 20: 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 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 191. 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 325. 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 288 “Defining resource profiles: Citrix Web applications” on page 307 “Defining resource profiles: Lotus iNotes” on page 313 “Defining resource profiles: Microsoft Sharepoint” on page 315 2. If available, click the Show ALL autopolicy types button to display the autopolicy configuration options. 292 Defining resource profiles: Custom Web applications Chapter 13: Web rewriting 3. Select the Autopolicy: Single Sign-On checkbox. 4. Select a single sign-on method and configure the corresponding SSO options: 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. For detailed configuration instructions, see “Specifying basic authentication or NTLM SSO autopolicy options” on page 293. (This option does not apply to Citrix resource profiles.) 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. For detailed configuration instructions, see “Specifying basic authentication or NTLM SSO autopolicy options” on page 293. (This option does not apply to Citrix resource profiles.) 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 294. 5. Click Save Changes. Specifying basic authentication or NTLM SSO autopolicy options To configure basic authentication or NTLM SSO autopolicy options: 1. Create an SSO autopolicy and choose Basic Auth or NTLM, as explained in “Defining a single sign-on autopolicy” on page 292. 2. In the Resource field, specify the resources to which this policy applies. For detailed guidelines, see “Defining Web resources” on page 291. NOTE: When entering a resource in this field, note that: 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. 3. Select one of the following Action options: Use system credentials—The IVE intermediates the challenge/response sequence, caches the credentials it collects, and uses them to enable single sign-on based on any system credentials you have previously configured on the IVE. Defining resource profiles: Custom Web applications 293 Juniper Networks Secure Access Administration Guide Use predefined credentials—The IVE intermediates the challenge/response sequence, caches the credentials it collects, and uses them to enable single sign-on. When you select this option, you must also specify the following intermediation credential parameters: Username—Specifies the SSO user name that the IVE uses to validate sign-in credentials. Password—Specifies the SSO password that the IVE uses to validate sign-in credentials. You may use a static password (such as “open_sesame”) or variable password (such as ) to validate sign-in credentials. (NTLM only) Domain—Specifies the domain name. Disable SSO—The IVE disables automatic SSO authentication for this user role and, instead, prompts the user for sign-in credentials. 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 292. Or, create a custom Citrix resource profile and choose Autopolicy: Single Sign on as explained in “Defining resource profiles: Citrix Web applications” on page 307. 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://yourcompany.com. 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: 294 Defining resource profiles: Custom Web applications Chapter 13: Web rewriting 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.) 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 860 for a list of valid variables), or IVE session variables containing username and password values (see “Multiple sign-in credentials overview” on page 193 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 291 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 resource profiles: Custom Web applications 295 Juniper Networks Secure Access Administration Guide 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 332. For information about recommended caching settings for OWA and Lotus Notes applications, see “Creating OWA and Lotus Notes caching resource policies” on page 335. 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 288 “Defining resource profiles: Microsoft OWA” on page 311 “Defining resource profiles: Lotus iNotes” on page 313 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 291. 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: 296 Request is for Flash, .xls, .pps, .ppt files Content-type is application/, text/rtf, text/xml, model/ Defining resource profiles: Custom Web applications Chapter 13: Web rewriting 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. 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 are always cacheable and get cache-control:private as well. 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 does not add the pragma:no-cache or cachecontrol:no-store response headers and forwards the origin server's caching headers. 6. Click Add. 7. Click Save Changes. Defining resource profiles: Custom Web applications 297 Juniper Networks Secure Access Administration Guide 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 623. 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 336. For information about hosting Java applets directly on the IVE, see “Hosted Java applets” on page 357. 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 288. 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 299. 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. 298 Defining resource profiles: Custom Web applications Chapter 13: Web rewriting 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 21: DNS hostname special characters * Matches ALL characters. % Matches any character except dot (.) ? Matches exactly one character IP address/Netmask—You must enter the IP address in the format: a.b.c.d. You may use one of two formats for the netmask: Prefix: High order bits IP: a.b.c.d For example: 10.11.149.2/24 or 10.11.149.2/255.255.255.0 You cannot use special characters in the IP address or netmask. Ports—You must use the delimiter “:” when specifying a port. For example: 10.11.149.2/255.255.255.0:* Table 22: Port possible values * Matches ALL ports; you cannot use any other special characters port[,port]* A comma-delimited list of single ports. Valid port numbers are [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. Defining resource profiles: Custom Web applications 299 Juniper Networks Secure Access Administration Guide 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 339. To create a rewriting autopolicy: 1. Create a custom Web application resource profile, as explained in “Defining resource profiles: Custom Web applications” on page 288. 2. Click Show ALL autopolicy types. 3. Select the Autopolicy: Rewriting Options checkbox. 4. Select one of the following options: 300 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 286). For detailed configuration instructions, see “Specifying passthrough proxy autopolicy options” on page 301. No rewriting (use WSAM)—Select this option to intermediate content using WSAM instead of the Content Intermediation Engine. (For information about WSAM, see “W-SAM overview” on page 397.) 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 302. No rewriting (use JSAM)—Select this option to intermediate content using JSAM instead of the Content Intermediation Engine. (For information about JSAM, see “J-SAM overview” on page 417.) 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 303. Defining resource profiles: Custom Web applications Chapter 13: Web rewriting 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. 5. Click Save Changes. Specifying pass-through proxy autopolicy options To configure pass-through proxy autopolicy options: 1. Create an rewriting autopolicy and select Passthrough Proxy, as explained in “Defining a rewriting autopolicy” on page 300. 2. Choose the way in which you want to enable the pass-through 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. Defining resource profiles: Custom Web applications 301 Juniper Networks Secure Access Administration Guide 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 pass-through 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 pass-through 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 606. 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 pass-through 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 300. 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. 302 Defining resource profiles: Custom Web applications Chapter 13: Web rewriting 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 300. 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 “J-SAM overview” on page 417. 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. Defining resource profiles: Custom Web applications 303 Juniper Networks Secure Access Administration Guide 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 839. 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 841. 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 288 “Defining resource profiles: Microsoft OWA” on page 311 “Defining resource profiles: Lotus iNotes” on page 313 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 291. 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. 304 Defining resource profiles: Custom Web applications Chapter 13: Web rewriting 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 78. To configure Web resource profile bookmarks: Defining resource profiles: Custom Web applications 305 Juniper Networks Secure Access Administration Guide 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 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 869. 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. 306 Defining resource profiles: Custom Web applications Chapter 13: Web rewriting 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 resource profiles: Citrix Web applications A 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 pre-populating a variety of resource policy settings for you depending on the type of Citrix setup you select. Due to their highly simplified configurations, templates are the ideal Citrix configuration method if you want to deliver ActiveX or Java applets from a third party Web server through the IVE or if you are using the Citrix fat clients. We strongly recommend using Citrix templates instead of the traditional role and resource policy configuration options available through the IVE. Other Citrix configuration methods available through the IVE include Network Connect, hosted Java applets, and Terminal Services. Use hosted Java applets if you want to deliver Citrix Java applets directly from the IVE instead of a third party Web server (as explained in “Hosted Java applets” on page 357), or use Terminal Services if you want to deliver the Citrix client directly from the IVE instead of a third party Web server (as explained in “Terminal Services” on page 461). Defining resource profiles: Citrix Web applications 307 Juniper Networks Secure Access Administration Guide For more information about resource profile templates, see “Resource profiles” on page 71. NOTE: You cannot use Citrix templates in conjunction with Network Connect. To create a resource profile using the Citrix template: 1. Navigate to the Users > Resource Profiles > Web Applications/Pages page 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. In the Web Interface (NFuse) URL field, enter the URL of the Citrix resource to which you want to control access using 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 servers 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 290. 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 Citrix using Java ICA clients and the Citrix Web Interface for MPS (i.e., NFuse). Java ICA Client without Web Interface (NFuse)—Select this option if you have deployed Citrix using Java ICA clients without the Citrix Web Interface for MPS (i.e., NFuse). Non-Java ICA Client with Web Interface (NFuse)—Select this option if you have deployed Citrix using non-Java ICA clients and the Citrix Web Interface for MPS (i.e., NFuse). 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 (i.e., 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 405. 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 294.) 308 Defining resource profiles: Citrix Web applications Chapter 13: Web rewriting 8. In the MetaFrame servers section, specify the Metaframe Servers to which you want to control access and 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. For instance, if you choose a Java ICA client option above, the IVE creates a corresponding Java ACL resource policy that enables Java applets to connect to the specified Metaframe servers. If you choose the non-Java ICA client option above, the IVE creates a corresponding SAM resource policy that enables users to access the specified Metaframe servers. 9. (Java ICA clients only) If you have deployed Citrix using a Java ICA Client, 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. (For instructions, see “Using code-signing certificates” on page 623.) 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 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 521. To secure traffic through the Secure Application Manager, select one of the following options in the ICA Client Access section: ICA client connects over WSAM—Select this option to secure traffic using WSAM instead of the Content Intermediation Engine. ICA client connects over JSAM—Select this option to secure traffic using JSAM instead of the Content Intermediation Engine. When you select this option, the IVE automatically launches JSAM when a user connects to the Web interface server that you define. After you select ICA client connects over JSAM, configure the following options: i. Number of Metaframe servers—Specify the number of Metaframe servers in your environment so the IVE can provision the correct number of loopback IP addresses for your configuration. (For instance, if you have five Metaframe servers and two ports, the IVE opens ten loopback IP addresses.) For more information about loopback addresses, see “Assigning IP loopback addresses to servers” on page 421. ii. Citrix Ports—Specify the ports on which the Metaframe servers listen. Defining resource profiles: Citrix Web applications 309 Juniper Networks Secure Access Administration Guide When you enable intermediation through WSAM or JSAM using these options, 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. In the Autopolicy: Web Access Control section, 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 sub-directories.) For more detailed instructions, see “Defining a Web access control autopolicy” on page 290. 12. If you selected one of the Web interface options in above, update the SSO policy created by the Citrix template in the Autopolicy: Single Sign on section. (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.) At minimum, you need to select the Autopolicy: Single Sign on checkbox, double-click the Value in the Domain column, fill in the appropriate domain, and click the check mark on the right side of the column. For more detailed instructions, see “Specifying remote SSO autopolicy options” on page 294. 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 292. 13. Click Save and Continue. 14. In the Roles tab, select the roles 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 Users > User Roles > Select Role > Web > Options page of the admin console for all of the roles you select. 15. Click Save Changes. 310 Defining resource profiles: Citrix Web applications Chapter 13: Web rewriting 16. (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 305. (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.) Defining resource profiles: Microsoft OWA 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 pre-populating a variety of resource policy settings for you depending on the type of setup you select. The pre-populated values vary depending on the version of OWA you select and are based on the most common deployment of the servers. To create a resource profile using the Microsoft OWA template: 1. Navigate to the Users > Resource Profiles > Web Applications/Pages page in the admin console. 2. Click New Profile. 3. Select Microsoft OWA 2000 or Microsoft OWA 2003 from the Type list. 4. Enter a unique name and optionally a description for the Citrix resource profile. 5. In the Base URL field, enter the URL of the OWA resource to which you want to control access using 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 290. 6. 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 cachecontrol:no-cache header based on the user’s Web browser and content type. This is the same as smart caching. The Allow caching on client option caches content 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. 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 Prevent download of attachments to prohibit users from downloading attachments to their systems. Select Prevent upload of attachments to prevent users from transmitting (uploading) attachments to the IVE. Defining resource profiles: Microsoft OWA 311 Juniper Networks Secure Access Administration Guide 8. In the Autopolicy: Web Access Control section, create a policy that allows or denies users access to the Web resource (and all of its sub-directories) listed in the Resource field. a. in the Resource field, 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 291. b. From the Action list, choose Allow to enable access to the specified resource or Deny to block access to the specified resource. c. Click Add. 9. In the Autopolicy: Caching section, specify the resources to which this policy applies in the Resource field. To create the caching autopolicy, follow the instructions in “Defining a caching autopolicy” on page 296. 10. In the Autopolicy: Web Compression section, 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 291. b. Select one of the following options from the Action list: 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. 11. Select the Autopolicy: Single Sign-On checkbox 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 292. 12. Click Save and Continue. 13. 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 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. 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 305. 312 Defining resource profiles: Microsoft OWA Chapter 13: Web rewriting Defining resource profiles: Lotus iNotes 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 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. The pre-populated values vary depending on the version of iNotes you select and are based on the most common deployment of the servers. To create a resource profile using the Lotus iNotes template: 1. Navigate to the Users > Resource Profiles > Web Applications/Pages page 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. In the Base URL field, enter the URL of the Lotus iNotes resource to which you want to control access using 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 290. 6. 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 cachecontrol:no-cache header based on the user’s Web browser and content type. This is the same as smart caching. For more information, see “Defining resource policies: Caching” on page 332. The Allow caching on client option caches content 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 Prevent download of attachments to prohibit users from downloading attachments to their systems. Select Prevent upload of attachments (available only for Lotus iNotes 6.5 and Lotus iNotes 7) to prevent users from transmitting (uploading) attachments to the IVE. Defining resource profiles: Lotus iNotes 313 Juniper Networks Secure Access Administration Guide 8. In the Autopolicy: Web Access Control section, create a policy that allows or denies users access to the Web resource (and all of its sub-directories) listed in the Resource field. a. in the Resource field, 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 291. b. From the Action list, choose Allow to enable access to the specified resource or Deny to block access to the specified resource. c. Click Add. 9. In the Autopolicy: Caching section, specify the resources to which this policy applies in the Resource field. To create the caching autopolicy, follow the instructions in “Defining a caching autopolicy” on page 296. 10. In the Autopolicy: Web Compression section, 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 291. b. Select one of the following options from the Action list: 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. 11. Select the Autopolicy: Single Sign-On checkbox 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 292. 12. Click Save and Continue. 13. In the Roles tab, select the roles to which the Lotus iNotes resource profile applies 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 305. 314 Defining resource profiles: Lotus iNotes Chapter 13: Web rewriting Defining resource profiles: Microsoft Sharepoint 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. NOTE: In the current release, we support sending contact information from Sharepoint to your Outlook client through the rewriter. Transferring the contact information to the backend Exchange server requires WSAM, JSAM, or Network Connect. To import contact information into the Sharepoint server from your Outlook client, first export your contacts and then upload them to the Sharepoint server. To create a resource profile using the Microsoft Sharepoint template: 1. Navigate to the Users > Resource Profiles > Web Applications/Pages page 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. In the Base URL field, enter the URL of the Sharepoint resource to which you want to control access using 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 290. 6. In the Sharepoint Settings section, select Allow in-line editing of documents within explorer view to allow users to modify files displayed in the explorer view. a. Under Explorer View URL, click Add and enter the URL to the explorer view page. b. To order the resources in the list, select the checkbox next to an item and then use the up and down arrows to move it to the correct place in the list. c. In the Persistent cookie timeout field, enter the number of minutes a persistent cookie resides on a user’s computer before it expires. Do not confuse this timeout field with Max. Session Length which determines the number of minutes an active non-administrative user session may remain open before ending. For more information on Max. Session Length, see “Specifying session options” on page 57. Defining resource profiles: Microsoft Sharepoint 315 Juniper Networks Secure Access Administration Guide 7. In the Autopolicy: Web Access Control section, create a policy that allows or denies users access to the Web resource (and all of its sub-directories) listed in the Resource field. a. in the Resource field, 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 291. b. From the Action list, choose Allow to enable access to the specified resource or Deny to block access to the specified resource. 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 sections: “Defining a single sign-on autopolicy” on page 292 “Defining a caching autopolicy” on page 296 “Defining a rewriting autopolicy” on page 300 “Defining a Web compression autopolicy” on page 304 9. Click Save and Continue. 10. 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 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) 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 305. Defining role settings: Web URLs You can use two different methods to create Web bookmarks: 316 Defining role settings: Web URLs 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 317. Chapter 13: Web rewriting 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 282). For configuration instructions, see “Creating standard Web bookmarks” on page 317. 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 319. 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. Click Save Changes or Save + New to add another. 7. (Optional) to change the properties of the bookmark, click the link in the Resource column of the role page. Then, click the bookmark link in the resource profile page and update the bookmark’s settings using instructions in “Defining a Web bookmark” on page 305. 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 288 and “Defining resource profiles: Citrix Web applications” on page 307. 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: Defining role settings: Web URLs 317 Juniper Networks Secure Access Administration Guide 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 362. 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. Enter a name and description for the bookmark (optional). This information displays on the IVE home page instead of the URL. 4. Select Web URL. 5. Enter the URL to bookmark. If you want to insert the user’s username, enter 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 869. 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. 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 316 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 575. 318 Defining role settings: Web URLs Chapter 13: Web rewriting 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: 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/ Defining role settings: Web URLs 319 Juniper Networks Secure Access Administration Guide 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. 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. 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 298. 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. 320 Defining role settings: Web URLs Chapter 13: Web rewriting 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 621. 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. Defining role settings: Web URLs 321 Juniper Networks Secure Access Administration Guide 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. 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 pass-through 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). 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. 322 Defining resource policies: Overview Chapter 13: Web rewriting 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 88. 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 83. 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. Host (required)—Possible values: DNS Hostname—For example: www.juniper.com Special characters allowed are described in the following table: Table 23: 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 Defining resource policies: Overview 323 Juniper Networks Secure Access Administration Guide 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 24: 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. 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/ /* 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 > Access > Web ACL. 2. On the Web Access Policies page, click New Policy. 3. On the New Policy page, enter: a. 324 Defining resource policies: Web access A name to label this policy. Chapter 13: Web rewriting 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 83 for more information. To enable IP-based or case sensitivity matching for these resources, see “Defining resource policies: General options” on page 355. 5. 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. 6. In the Action section, specify: Allow access—To grant access to the resources specified in the Resources list. Deny access—To deny access to the resources specified in the Resources list. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 7. Click Save Changes. 8. On the Web Access 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. For an example Web resource policy, see the figures in “Defining resource policies: Overview” on page 322. Defining resource policies: Single sign-on Single sign-on policies enable you to automatically pass user credentials to the Web application specified in your policy. You can configure single sign-on policies to intercept basic authentication and NTLM challenges, display an intermediate sign-in page to collect credentials for the Web resource, and then rewrite the credentials along with the entire challenge/response sequence. Or, you can post the credentials and headers that you specify to the Web application. Defining resource policies: Single sign-on 325 Juniper Networks Secure Access Administration Guide This section contains the following instructions for creating single sign-on resource policies: “Writing a Basic Authentication or NTLM Intermediation resource policy” on page 326 “Writing a remote SSO Form POST resource policy” on page 328 “Writing a remote SSO Headers/Cookies resource policy” on page 330 Writing a Basic Authentication or NTLM Intermediation resource policy Basic Authentication or NTLM Intermediation resource policies enable you to control NTLM intermediation on the IVE. If a user accesses a Web resource that sends a basic authentication challenge, the IVE can intercept the challenge, display an intermediate sign-in page to collect credentials for the Web resource, and then rewrite the credentials along with the entire challenge/response sequence. To write a Basic Authentication or NTLM Intermediation resource policy: 1. In the admin console, navigate to Users > Resource Policies > Web. 2. If your administrator view is not already configured to show SSO 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 Basic Auth/NTLM checkbox below the SSO checkbox. d. Click OK. 3. Select the SSO > Basic Auth/NTLM tab. 4. On the Basic Auth and NTLM policies page, click New Policy. 5. On the New Policy page, enter a name to label this policy (required) and 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 83 for more information. To enable IP-based or case sensitivity matching for these resources, see “Defining resource policies: General options” on page 355. 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 Users > User Roles > Role > Web > Bookmarks page of the admin console. 7. In the Roles section, specify: 326 Policy applies to ALL roles—To apply this policy to all users. Defining resource policies: Single sign-on Chapter 13: Web rewriting 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: Basic—This option specifies that the IVE use the Basic Authentication Intermediation method to control SSO behavior. Enable Intermediation—When you select this option, you must also specify the type of Basic Authentication Intermediation: Use System Credentials for SSO, Use Specified Credentials for SSO, or Disable SSO. These three options are described under the NTLM item, below. 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. Use System Credentials for SSO—The IVE intermediates the challenge/response sequence, caches the credentials it collects, and uses them to enable single sign-on based on any system credentials you have previously configured on the IVE. Use Specified Credentials for SSO—The IVE intermediates the challenge/response sequence, caches the credentials it collects, and uses them to enable single sign-on. When you select this option, you must also specify the following Intermediation credential parameters: Username—Specifies the SSO user name that the IVE uses to validate sign-in credentials. Variable password—Specifies the SSO variable password that the IVE uses to validate sign-in credentials. The variable password is the text, “ ” and means that the IVE uses the user’s sign-in password as the authentication method when presenting credentials for SSO. Defining resource policies: Single sign-on 327 Juniper Networks Secure Access Administration Guide Password—Specifies the static SSO password that the IVE uses to validate sign-in credentials. For example, you can specify a password like “open_sesame” that the IVE automatically presents to the authentication server when intermediating user credentials. Domain—Specifies the domain name. Use the variable if you are using an LDAP server. The IVE populates this variable with the domain name. If left blank, the IVE sends the domain returned from the NTLM challenge to the server as part of the NTLM response. Disable SSO—The IVE disables automatic SSO authentication for this user role and, instead, prompts the user for sign-in credentials. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 9. Click Save Changes. 10. On the Basic Auth and NTLM 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. For an example Web resource policy, see the figures in “Defining resource policies: Overview” on page 322. Writing a remote SSO Form POST resource policy Remote SSO Form POST resource policies specify Web applications to which the IVE posts data. This data can include a user’s IVE username and password, as well as system data stored by system variables. For more information, see “Remote SSO overview” on page 285. To write a remote SSO Form POST resource policy: 1. In the admin console, navigate to Users > Resource Policies > Web. 2. If your administrator view is not already configured to show SSO 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 Form Post checkbox below the SSO checkbox. d. Click OK. 3. Select the SSO> Form Post tab. 4. On the Form POST Policies page, click New Policy. 328 Defining resource policies: Single sign-on Chapter 13: Web rewriting 5. On the New Policy page, enter a name to label this policy (required) and a description of the policy (optional). 6. In the Resources section, specify the application’s sign-in page, such as: http://yourcompany.com. See “Specifying resources for a resource policy” on page 83 for more information. To enable IP-based or case sensitivity matching for these resources, see “Defining resource policies: General options” on page 355. 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 Users > User Roles > Role > Web > Bookmarks page of the admin console. 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: Perform the POST defined below—The IVE performs a form POST with the user data specified in the POST details section to the specified URL when a user makes a request to a resource specified in the Resources list. Do NOT perform the POST defined below—The IVE does not perform a form POST with the user data specified in the POST details section. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 9. In the POST details section: In the POST to 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. (The IVE does not accept wildcard characters in this field.) Check Deny direct login for this resource if you do not want users to be able to access the URL directly. 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. Defining resource policies: Single sign-on 329 Juniper Networks Secure Access Administration Guide Specify the user data to post and user modification permission: User 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.) 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 860 for a list of valid variables), or IVE session variables containing username and password values (see “Multiple sign-in credentials overview” on page 193 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. 10. Click Save Changes. 11. On the Form POST 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. For an example Web resource policy, see the figures in “Defining resource policies: Overview” on page 322. Writing a remote SSO Headers/Cookies resource policy Remote SSO Headers/Cookies resource policies specify customized Web applications to which the IVE posts custom headers and cookies. For more information, see “Remote SSO overview” on page 285. NOTE: When creating a Headers/Cookies policy, note that the IVE does not parse or “understand” the headers that you enter in this section. For instance, if you add an Accept-Encoding: gzip or Accept-Encoding:deflate header, it does not mean that the IVE can handle gzip content or deflated content. To write a remote SSO Headers/Cookies resource policy: 1. In the admin console, navigate to Users > Resource Policies > Web. 330 Defining resource policies: Single sign-on Chapter 13: Web rewriting 2. If your administrator view is not already configured to show SSO 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 Headers/Cookies checkbox below the SSO checkbox. d. Click OK. 3. Select the SSO > Headers/Cookies tab. 4. On the Headers/Cookies 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 83 for more information. To enable IP-based or case sensitivity matching for these resources, see “Defining resource policies: General options” on page 355. 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: Append headers as defined below—The IVE posts the user data specified in the POST details section to the specified URL when a user makes a request to a resource specified in the Resources list. Do NOT append headers as defined below—The IVE does not post the user data specified in the POST details section to the specified URL when a user makes a request to a resource specified in the Resources list. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 9. In the Headers and values section, specify the: Header name—The text for the IVE to send as header data. Defining resource policies: Single sign-on 331 Juniper Networks Secure Access Administration Guide Value—The value for the specified header. NOTE: If you need to forward a cookie to a backend server, you must set the Header Name field to "Cookie" and the Value field to "CookieName=CookieValue". 10. Click Save Changes. 11. On the Headers/Cookies 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. For an example Web resource policy, see the figures in “Defining resource policies: Overview” on page 322. Defining resource policies: Caching Caching resource policies control which Web content is cached on a user’s machine. This section contains the following information about caching policies: “Writing a caching resource policy” on page 332 “Creating OWA and Lotus Notes caching resource policies” on page 335 “Specifying general caching options” on page 335 Writing a caching resource policy To write a Web Caching resource policy: 1. In the admin console, navigate to Users > Resource Policies > Web. 2. If your administrator view is not already configured to show caching policies, make the following modifications: a. Click the Customize button in the upper right corner of the page. b. Select the Caching checkbox. c. Select the Policies checkbox below the Caching checkbox. d. Click OK. 3. Select the Caching > Policies tab. 4. On the Web Caching Policies page, click New Policy. 332 Defining resource policies: Caching Chapter 13: Web rewriting 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 “Writing a detailed rule” on page 88 for more information. To enable IP-based or case sensitivity matching for these resources, see “Defining resource policies: General options” on page 355. 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, select one of the following options: Smart Caching (send headers appropriate for content and browser)— 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 policies: Caching 333 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 are always cacheable and get cache-control-private as well. 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 Don't Cache (send "Cache Control: No Store") option. Don't Cache (send "Cache Control: 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 “windows-media-player.” This option might slow browsing by causing repeated content fetches, which can cause performance issues on very slow connections. Alternatively, you can specify a policy that allows certain kinds of content to be cached, such as images that do not exceed a specified size limit. Don't Cache (send "Pragma: 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 cachecontrol: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 (do not add/modify caching headers)—The IVE does not add the pragma:no-cache or cache-control:no-store response headers and forwards the origin server's caching headers. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 9. Click Save Changes. 10. On the Web Caching 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. 334 Defining resource policies: Caching Chapter 13: Web rewriting For an example Web resource policy, see the figures in “Defining resource policies: Overview” on page 322. Creating OWA and Lotus Notes caching resource policies The following tables include examples of some of the content types that the IVE supports with the Outlook Web Access (OWA) and Lotus iNotes applications. Additionally, it specifies the cache control directives that you must implement in Microsoft Internet Explorer in order to support opening and saving the specified content types. Note that for performance reasons, we recommend creating caching policies for everything in the iNotes directory. Table 25: OWA caching resource policies Attachment type To open the attachment, use: To save the attachment, use: zip Cache Smart caching ppt Smart caching Smart caching doc Smart caching Smart caching xls Smart caching Smart caching pdf Smart caching Smart caching txt Cache Cache control: No store html Smart caching Cache control: No store Table 26: iNotes caching resource policies Attachment type To open the attachment, use: To save the attachment, use: zip Cache control: No store Cache control: No store ppt Cache control: No store Cache control: No store doc Smart caching Smart caching xls Cache control: No store Cache control: No store pdf Cache control: No store Cache control: No store txt Cache control: No store Cache control: No store html Cache control: No store Cache control: No store other file types Cache control: No store Cache control: No store Specifying general caching options You can use caching options to specify the maximum image file size that is cached on a client. If the content-type header from the origin server begins with "image/" and the content-length header specifies a size less than the maximum size configured for this option, then the IVE passes along the origin server's caching headers. Otherwise, the IVE treats the request as though caching is disabled. To specify caching options: 1. In the admin console, navigate to Users > Resource Policies > Web. Defining resource policies: Caching 335 Juniper Networks Secure Access Administration Guide 2. If your administrator view is not already configured to show caching policies, make the following modifications: a. Click the Customize button in the upper right corner of the page. b. Select the Caching checkbox. c. Select the Options checkbox below the Caching checkbox. d. Click OK. 3. Select the Caching > Options tab. 4. On the Caching Options page, specify a maximum allowable image size in the Clients should cache all images less than field. 5. Click Save Changes. Defining resource policies: External Java applets This section contains the following information about rewriting Java applets on an external server: “Writing a Java access control resource policy” on page 336 “Writing a Java code signing resource policy” on page 338 NOTE: For information about hosting Java applets directly on the IVE, see “Hosted Java applets” on page 357. Writing a Java access control resource policy Java access control resource policies control to which servers and ports Java applets can connect. To write a Java 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 java policies, make the following modifications: a. Click the Customize button in the upper right corner of the page. b. Select the Java checkbox. c. Select the Access Control checkbox below the Java checkbox. d. Click OK. 3. Select the Java > Access Control tab. 336 Defining resource policies: External Java applets Chapter 13: Web rewriting 4. On the Java Access 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 83 for more information. To enable IP-based or case sensitivity matching for these resources, see “Defining resource policies: General options” on page 355. 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: Allow socket access—To enable Java applets to connect to the servers (and optionally ports) in the Resources list. Deny socket access—To prevent Java applets from connecting to the servers (and optionally ports) in the Resources list. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 9. Click Save Changes. 10. On the Java Access 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. 11. (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 575. b. After you finish configuring the IVE, cache your Java applet and access it as end-user. This action eliminates the performance hit that occurs through the intermediation engine when the first end-user accesses the applet. Defining resource policies: External Java applets 337 Juniper Networks Secure Access Administration Guide For an example Web resource policy, see the figures in “Defining resource policies: Overview” on page 322. Writing a Java code signing resource policy Java code signing resource policies specify how the IVE rewrites Java applets. By default, when the IVE intermediates a signed Java applet, it re-signs the applet with its own certificate, which is not chained to a standard root certificate. When a user requests an applet that performs potentially high-risk tasks, such as accessing network servers, the user’s browser displays a security warning that the root is not a trusted root. To forestall this warning, you can import a code-signing certificate that the IVE uses to re-sign applets that it intermediates. For more information about code-signing certificates, see “Using code-signing certificates” on page 623. When configuring Java code signing resource policies, enter the servers from which you trust applets. You can enter a server IP address or domain name. The IVE only re-signs applets served by a trusted server. If a user requests an applet from server not on the list, the IVE does not use the imported production certificates to sign the applet, which means the user is prompted by the browser with a security warning. For Sun JVM users, the IVE additionally checks that the root CA of the original applet certificate is on its list of trusted root certificate authorities. To write a Java code signing resource policy: 1. In the admin console, navigate to Users > Resource Policies > Web. 2. If your administrator view is not already configured to show java policies, make the following modifications: a. Click the Customize button in the upper right corner of the page. b. Select the Java checkbox. c. Select the Code-Signing checkbox below the Java checkbox. d. Click OK. 3. Select the Java > Code-Signing tab. 4. On the Java Signing 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 83 for more information. To enable IP-based or case sensitivity matching for these resources, see “Defining resource policies: General options” on page 355. 7. In the Roles section, specify: 338 Policy applies to ALL roles—To apply this policy to all users. Defining resource policies: External Java applets Chapter 13: Web rewriting 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: Resign applets using applet certificate—To enable Java applets to connect to the servers (and optionally ports) in the Resources list. Resign applets using default certificate—To prevent Java applets from connecting to the servers (and optionally ports) in the Resources list. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 9. Click Save Changes. 10. On the Java Signing 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. For an example Web resource policy, see the figures in “Defining resource policies: Overview” on page 322. Defining resource policies: Rewriting Rewriting resource policies control which Web data the IVE rewrites or does not rewrite through the Content Intermediation Engine. This section contains the following information about creating rewriting resource policies: “Creating a selective rewriting resource policy” on page 340 “Creating a pass-through proxy resource policy” on page 342 “Creating a custom header resource policy” on page 344 “Creating an ActiveX parameter resource policy” on page 346 “Restoring the default IVE ActiveX resource policies” on page 348 “Creating rewriting filters” on page 349 Defining resource policies: Rewriting 339 Juniper Networks Secure Access Administration Guide Creating a selective rewriting resource policy Selective rewriting resource policies enable you to define a list of hosts for which you want the IVE to intermediate content as well as exceptions to this list. 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. Create a selective rewriting policy if you do not want the IVE to intermediate traffic from Web sites that reside outside of the corporate network, such as yahoo.com, or if you do not want the IVE to intermediate traffic for client/server applications you have deployed as Web resources, such as Microsoft OWA (Outlook Web Access). To write a selective rewriting resource policy: 1. In the admin console, navigate to Users > Resource Policies > Web. 2. If your administrator view is not already configured to show rewriting policies, make the following modifications: a. Click the Customize button in the upper right corner of the page. b. Select the Rewriting checkbox. c. Select the Selective Rewriting checkbox below the Rewriting checkbox. d. Click OK. 3. Select the Rewriting > Selective Rewriting tab. 4. On the Web Rewriting 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 83 for more information. To enable IP-based or case sensitivity matching for these resources, see “Defining resource policies: General options” on page 355. 7. In the Roles section, specify: 340 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. Defining resource policies: Rewriting Chapter 13: Web rewriting 8. In the Action section, specify: Rewrite content—The IVE intermediates all Web content from the resources specified in the Resources list.1 Rewrite content as...—The IVE intermediates all Web content from the resources specified in the Resources list and rewrites the content as if it were the file type specified in the drop-down list.1 The available options are: HTML—Rewrite content as Hypertext Markup Language (HTML) XML—Rewrite content as Extensible Markup Language (XML) Javascript—Rewrite content as Java scripting language VBScript—Rewrite content as Virtual Basic scripting language CSS—Rewrite content as Cascading Style Sheets XSLT—Rewrite content as XML Style Sheets Flash—Rewrite content as Shockwave Flash DTD—Rewrite content as Document Type Definitions (DTD) HTC—Rewrite content as HTML component Don’t rewrite content: Redirect to target Web server—The IVE does not intermediate Web content from the resources specified in the Resources list and automatically redirects the request to the target Web server. This is the default option for all rewrite resource policies that you create. If you select this option, you might want to specify that the IVE open the unrewritten pages in a new window using options in “Defining resource policies: General options” on page 355. NOTE: Do not select this option if the specified content needs to access resources inside your corporate network. For instance, if you specify that the IVE should not rewrite a particular file, and that file calls another file within your network, the user will see an error. 1. New IVE appliances come with an Initial Rewrite Policy that rewrites all content for all roles. Defining resource policies: Rewriting 341 Juniper Networks Secure Access Administration Guide Don’t rewrite content: Do not redirect to target Web server—The IVE retrieves the content from the original Web server, but does not modify it. This is useful in cases where users may not be able to reach the original server, thus disabling redirection. (For example, if the Web server is not accessible from the public internet because it resides behind a firewall.) NOTE: The Don’t rewrite content: Do not redirect to target Web server option allows users to download data from network resources via the IVE, but bypasses the IVE rewriting engine in the process. We recommend you use this feature only when rewriting signed Java applets—not other content types. For other content types such as HTML and Javascript, use the Don’t rewrite content: Redirect to target Web server option to download an applet via the IVE, thus enabling direct connections to network resources. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 9. Click Save Changes. 10. On the Web Rewriting 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. For an example Web resource policy, see the figures in “Defining resource policies: Overview” on page 322. Creating a pass-through proxy resource policy Pass-through proxy resource policies specify Web applications for which the IVE performs minimal intermediation, as explained in “Passthrough-proxy overview” on page 286. To create a pass-through proxy resource policy, you need to specify two things: Which Web application to intermediate with the pass-through proxy How the IVE listens for client requests to the application server To write a pass-through proxy resource policy: 1. In the admin console, navigate to Users > Resource Policies > Web. 2. If your administrator view is not already configured to show rewriting policies, make the following modifications: a. Click the Customize button in the upper right corner of the page. b. Select the Rewriting checkbox. c. Select the Passthrough Proxy checkbox below the Rewriting checkbox. d. Click OK. 3. Select the Rewriting > Passthrough Proxy tab. 342 Defining resource policies: Rewriting Chapter 13: Web rewriting 4. On the Passthrough Proxy Policies page, click New Application. 5. On the New Passthrough Application page, enter: a. A name to label this policy. b. A description of the policy (optional). 6. In the URL field, specify the application server host name and the port used to access the application internally. Note that you cannot enter a path in this field. 7. Choose the way in which you want to enable the pass-through 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 URL field. NOTE: If you choose this option, you must also define the IVE name and host name in the Network Identity section of the System > Network > Internal Port tab. 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. 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 URL field. 8. In the Action section, specify the method for the IVE to use to intermediate traffic: Rewrite XML—If you select this option, the IVE rewrites URLs contained within XML content. If you disable this option, the IVE passes the XML content “as is” to the server. Rewrite external links—If you select this option, the IVE rewrites all URLs. If you disable this option, the IVE rewrites only those URLs that contain a hostname specified in the pass-through proxy policy. Defining resource policies: Rewriting 343 Juniper Networks Secure Access Administration Guide Block cookies from being sent to the browser—If you select this option, the IVE blocks cookies destined for the client’s browser. The IVE stores the cookies locally and sends them to applications whenever they are requested. Host-Header forwarding—If you select this option, the IVE passes the hostname as part of the host header instead of the actual host identifier. NOTE: The Host-Header forwarding option is only valid in pass-through proxy Virtual Host mode. 9. Click Save Changes. 10. On the Pass-through Proxy Policies page, order the policies according to how you want the IVE to evaluate them. Keep in mind that once the IVE matches the application requested by the user to an application specified in a policy’s (or a detailed rule’s) Resource list, it performs the specified action and stops processing policies. 11. 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 606. Use IVE port, 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 pass-through 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. For an example Web resource policy, see the figures in “Defining resource policies: Overview” on page 322. Creating a custom header resource policy By default, the IVE rewriting engine only sends selected custom headers to browsers (clients) and backend servers. You can use custom header resource policies, however, to allow or deny custom headers for specific resources. NOTE: Note that custom header resource policies do not control standard HTTP headers such as Content-Type. 344 Defining resource policies: Rewriting Chapter 13: Web rewriting To write a custom header resource policy: 1. In the admin console, navigate to Users > Resource Policies > Web. 2. If your administrator view is not already configured to show rewriting policies, make the following modifications: a. Click the Customize button in the upper right corner of the page. b. Select the Rewriting checkbox. c. Select the Custom Headers checkbox below the Rewriting checkbox. d. Click OK. 3. Select the Rewriting > Custom Headers tab. 4. On the Custom Header 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 83 for more information. To enable IP-based or case sensitivity matching for these resources, see “Defining resource policies: General options” on page 355. 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: Allow Custom Headers—Select this option to prevent the IVE from blocking the headers to browsers (clients) and backend servers. Deny Custom Headers—Select this option to use the default custom header behavior on the IVE. When you select this option, the IVE blocks custom headers for added security. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 9. Click Save Changes. Defining resource policies: Rewriting 345 Juniper Networks Secure Access Administration Guide 10. On the Web Rewriting 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. For an example Web resource policy, see the figures in “Defining resource policies: Overview” on page 322. Creating an ActiveX parameter resource policy When the IVE rewrites a Web page, it does not rewrite the ActiveX controls that are embedded in the Web page. However, you can create resource policies specifying that the IVE should rewrite the URL and host name parameters that are passed by the Web page to the Active X controls. To configure these resource policies, you must obtain the following information: Class ID—Web pages generally use a class ID to embed an ActiveX control. A class ID is a unique, constant string that uniquely identifies an ActiveX control. You can determine what an ActiveX object's class ID is using Internet Explorer 6: Select Tools > Internet Options, click Settings, and then click View Objects. Select the ActiveX object, right-click, and select Properties. The ActiveX object’s ID is highlighted. Language—Web pages can use either static or dynamic HTML (that is, by using JavaScript) to embed an Active X control. When a Web page uses static HTML, the IVE can rewrite the specified ActiveX parameters on the IVE itself while it intermediates traffic, since all of the required information passes between the user's browser and the application's Web server. When a Web page uses dynamic HTML to embed an ActiveX control, however, the page frequently pulls information from the client and then generates HTML to embed the ActiveX control. Therefore, the IVE needs to run script in the user's browser in order to obtain the information it needs to rewrite the specified ActiveX parameters. Parameter type—When configuring the IVE to rewrite a parameter, you must determine whether the parameter is a URL or host name. The IVE does not support any other parameter types. Parameter name—You must specify the name of the parameter that you want the IVE to rewrite. You can find the parameters by searching for the param tag within an object tag. For example, you might find a flash movie embedded in a page using the following code: When configuring the corresponding resource policy, you should enter movie in the Parameter name field because movie refers to the URL requires rewriting. Frequently, pages contain multiple param tags, but not all of them require rewriting. In this example, the quality parameter does not require rewriting. 346 Defining resource policies: Rewriting Chapter 13: Web rewriting To write an ActiveX parameter rewriting resource policy: 1. In the admin console, navigate to Users > Resource Policies > Web. 2. If your administrator view is not already configured to show rewriting policies, make the following modifications: a. Click the Customize button in the upper right corner of the page. b. Select the Rewriting checkbox. c. Select the ActiveX Parameter Rewriting checkbox below the Rewriting checkbox. d. Click OK. 3. Select the Rewriting > ActiveX Parameter Rewriting tab. 4. On the ActiveX Parameter Rewriting Policies page, click New Policy. 5. On the New Policy page, enter: a. The class ID of the ActiveX control that you want to control with the policy. b. A description of the policy (optional). 6. In the Parameters section, specify the ActiveX parameters that you want to control with the policy and the corresponding actions. Possible actions include: Rewrite URL and response (Static HTML only)—The IVE rewrites the specified URL parameter on the IVE. The IVE also rewrites any response from the Web server requesting the URL. Note that you should select this option if the Web page embeds the ActiveX control using only static HTML. Rewrite URL and response (Static and dynamic HTML)—The IVE rewrites the specified URL on the client in addition to rewriting on the IVE. The IVE also rewrites any response from the Web server requesting the URL. Note that you should select this option if the Web page embeds the ActiveX control using dynamic HTML. Rewrite URL (Static HTML only)—The IVE rewrites the specified URL parameter on the IVE. Note that you should select this option if the Web page embeds the ActiveX control using only static HTML. Rewrite URL (Static and dynamic HTML)—The IVE rewrites the specified URL on the client in addition to rewriting on the IVE. Note that you should select this option if the Web page embeds the ActiveX control using dynamic HTML. Rewrite hostname (Static HTML only)—The IVE rewrites the specified host name parameter on the IVE. Note that you should select this option if the Web page embeds the ActiveX control using only static HTML. Defining resource policies: Rewriting 347 Juniper Networks Secure Access Administration Guide Rewrite hostname (Static and dynamic HTML)—The IVE rewrites the specified host name on the client in addition to rewriting on the IVE. Note that you should select this option if the Web page embeds the ActiveX control using dynamic HTML. Do not rewrite—The IVE does not rewrite any of the ActiveX component’s parameters. 7. Click Save Changes. For an example Web resource policy, see the figures in “Defining resource policies: Overview” on page 322. Restoring the default IVE ActiveX resource policies The IVE comes with several predefined resource policies for rewriting the parameters of commonly used ActiveX objects. If you choose to delete any of these policies and then want to restore them later, you can recreate them using the following table as a guideline. Table 27: Predefined resource policies Description Class ID Parameter Action Citrix NFuse xginen_EmbeddedApp object 238f6f83-b8b4-11cf-877100a024541ee3 ICAFile Rewrite URL and response (Static HTML only) OrgPlus OrgViewer DCB98BE9-88EE-4AD0-9790- URL 2B169E8D5BBB Rewrite URL and response (Static HTML only) Quickplace 05D96F71-87C6-11D3-9BE400902742D6E0 GeneralURL Rewrite URL and response (Static and dynamic HTML) General_ServerName Rewrite host name (Static and dynamic HTML) FullURL Rewrite URL and response (Static and dynamic HTML) iNotes Discussion 5BDBA960-6534-11D3-97C700500422B550 B20D9D6A-0DEC-4d76-9BEF- B20D9D6A-0DEC-4d76-9BEF- ServerURL 175896006B4A 175896006B4A Error URL Rewrite URL and response (Static HTML only) Rewrite URL and response (Static HTML only) Citrix NFuse Elite 2E687AA8-B276-4910-BBFB4E412F685379 ServerURL Rewrite URL and response (Static HTML only) WebPhotos LEAD 00120000-B1BA-11CE-ABC6F5B2E79D9E3F BitmapDataPath Rewrite URL and response (Static and dynamic HTML) Shockwave Flash D27CDB6E-AE6D-11cf-96B8444553540000 Src Rewrite URL and response (Static and dynamic HTML) Movie Rewrite URL and response (Static and dynamic HTML) iNotes Blue 348 3BFFE033-BF43-11d5-A27100A024A51325 Defining resource policies: Rewriting General_URL Rewrite URL and response (Static and dynamic HTML) General_ServerName Rewrite host name (Static and dynamic HTML) Chapter 13: Web rewriting Table 27: Predefined resource policies (Continued) Description Class ID Parameter Action Tabular Data Control 333C7BC4-460F-11D0-BC040080C7055A83 DataURL Rewrite URL (Static HTML only) Windows Media Player 6BF52A52-394A-11D3-B15300C04F79FAA6 URL Rewrite URL and response (Static HTML only) FlowPartPlace 4A266B8B-2BB9-47db-9B0E6226AF6E46FC URL Rewrite URL and response (Static HTML only) HTML Help adb880a6-d8ff-11cf-937700aa003b7a11 Item1 Rewrite URL and response (Static and dynamic HTML) MS Media Player 22d6f312-b0f6-11d0-94ab0080c74c7e95 FileName Rewrite URL and response (Static HTML only) CSV Files Handler 333c7bc4-460f-11d0-bc040080c7055a83 DataURL Rewrite URL and response (Static HTML only) Special ActiveX control for Microsoft OWA D801B381-B81D-47a7-8EC4EFC111666AC0 mailboxUrl Rewrite URL and response (Static HTML only) FlowPartPlace1 639325C9-76C7-4d6c-9B4A523BAA5B30A8 Url Rewrite URL and response (Static HTML only) scriptx print control 5445be81-b796-11d2-b931002018654e2e Path Rewrite URL and response (Static HTML only) 94F40343-2CFD-42A1-A7744E7E48217AD4 94F40343-2CFD-42A1-A7744E7E48217AD4 HomeViewURL Rewrite URL and response (Static HTML only) Microsoft License Manager 5220cb21-c88d-11cf-b34700aa00a28331 LPKPath Rewrite URL and response (Static HTML only) Domino 7 beta 2 UploadControl E008A543-CEFB-4559-912FC27C2B89F13B General_URL Rewrite URL and response (Static and dynamic HTML) General_ServerName Rewrite host name (Static and dynamic HTML) General_URL Rewrite URL and response (Static and dynamic HTML) General_ServerName Rewrite host name (Static and dynamic HTML) iNotes 1E2941E3-8E63-11D4-9D5A00902742D6E0 ActiveCGM F5D98C43-DB16-11CF-8ECA- FileName 0000C0FD59C7 Rewrite URL and response (Static HTML only) 00130000-B1BA-11CE-ABC6F5B2E79D9E3F 00130000-B1BA-11CE-ABC6F5B2E79D9E3F Rewrite URL and response (Static and dynamic HTML) BitmapDataPath Creating rewriting filters Only use the Rewriting Filters tab when instructed to do so by the Juniper Networks Support team. Defining resource policies: Web compression This section contains the following information about defining compression resource policies: “Writing a Web compression resource policy” on page 350 Defining resource policies: Web compression 349 Juniper Networks Secure Access Administration Guide “Defining an OWA compression resource policy” on page 351 Writing a Web compression resource policy The IVE comes pre-equipped with one Web compression policy (*:*/*) which compresses all applicable Web data. You can enable this policy through the Users > Resource Policies > Web > Compression pages of the admin console. To write a Web compression resource policy: 1. In the admin console, navigate to Users > Resource Policies > Web. 2. If your administrator view is not already configured to show compression policies, make the following modifications: a. Click the Customize button in the upper right corner of the page. b. Select the Compression checkbox. c. Click OK. 3. Select the Compression tab. 4. On the Web Compression 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 URLs to which this policy applies. See “Specifying resources for a resource policy” on page 83 for more information. To enable IP-based or case sensitivity matching for these resources, see “Defining resource policies: General options” on page 355. 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: 350 Compress—The IVE compresses the supported content types from the specified resource. Defining resource policies: Web compression Chapter 13: Web rewriting Do not compress—The IVE does not compress the supported content types from the specified resource. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 9. Click Save Changes. Defining an OWA compression resource policy Due to caching issues with OWA, the IVE comes with the following built-in resource policies specifying that the IVE should not compress Javascript or CSS files that are routed through OWA: 1. Do Not Compress *:*/exchWeb/controls/*.css (all roles) 2. Do Not Compress *:*/exchWeb/controls/*.js (all roles) 3. Do Not Compress *:*/exchWeb/*/controls/*.css (all roles) 4. Do Not Compress *:*/exchWeb/*/controls/*.js (all roles) In the last two policies, a wildcard (*) is included in the path to account for different OWA build versions. Juniper Networks recommends that you do not change the compression resource policies for OWA unless absolutely necessary. Defining resource policies: Web proxy 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 a proxy when you use these tabs to configure the proxy and thereby specify that you trust it. For more information, see “Single sign-on” on page 191. This section contains the following information about Web proxy resource policies: “Writing a Web proxy resource policy” on page 351 “Specifying Web proxy servers” on page 353 Writing a Web proxy resource policy To write a Web proxy resource policy: 1. In the admin console, navigate to Users > Resource Policies > Web. 2. If your administrator view is not already configured to show Web proxy policies, make the following modifications: a. Click the Customize button in the upper right corner of the page. Defining resource policies: Web proxy 351 Juniper Networks Secure Access Administration Guide b. Select the Web Proxy checkbox. c. Select the Policies checkbox below the Web Proxy checkbox. d. Click OK. 3. Select the Web Proxy > Policies tab. 4. On the Web Proxy 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 83 for more information. To enable IP-based or case sensitivity matching for these resources, see “Defining resource policies: General options” on page 355. 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: Access Web resources directly—The IVE intermediates the user’s request to a back-end server and the server’s response to the user for requests made to a resource specified in the Resources list. Access Web resources through a Web proxy—Specify a Web proxy server in the drop-down list that you have defined in the Users > Resource Policies > Web > Web Proxy > Servers tab. See “Defining resource policies: Web proxy” on page 351 to define Web proxy servers. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 9. Click Save Changes. 10. On the Web Proxy 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. 352 Defining resource policies: Web proxy Chapter 13: Web rewriting For an example Web resource policy, see the figures in “Defining resource policies: Overview” on page 322. Specifying Web proxy servers You can direct all Web requests made through the IVE to a Web proxy rather than using the IVE to connect directly to Web servers. This feature can be useful if your network security policy requires this configuration or if you want to use a caching Web proxy to improve performance. To specify servers for Web proxy resource policies: 1. In the admin console, navigate to Users > Resource Policies > Web. 2. If your administrator view is not already configured to show Web proxy policies, make the following modifications: a. Click the Customize button in the upper right corner of the page. b. Select the Web Proxy checkbox. c. Select the Servers checkbox below the Web Proxy checkbox. d. Click OK. 3. Select the Web Proxy > Servers tab. 4. Under Web Proxy Servers, enter the name or IP address of the Web proxy server and the port number at which the proxy server listens, and then click Add. 5. Repeat this step to specify additional Web proxy servers. Defining resource policies: Web proxy 353 Juniper Networks Secure Access Administration Guide Defining resource policies: HTTP 1.1 protocol Protocol resource policies enable or disable HTTP 1.1 protocol support between the IVE and backend servers. The IVE supports chunked Transfer-Encoding, gzip and deflate Content-Encoding, connection persistence, and caching headers such as IfModified-Since, If-None-Match, If-Unmodified-Since and If-Match. The IVE supports range requests with partial content when you select the Don’t rewrite content: Do not redirect to target web server selective rewrite option. NOTE: For a detailed description of the HTTP 1.1 protocol, refer to the Hyptertext Transfer Protocol -- HTTP 1.1 specification from the World Wide Web Consortium. The IVE only communicates with network servers using HTTP 1.1 if the client also communicates using HTTP 1.1. If the client uses HTTP 1.0, the IVE communicates with backend servers using HTTP 1.0, regardless of whether or not HTTP 1.1 is enabled. If you want to use HTTP 1.1 for a specific resource, enable HTTP 1.1 for that policy and ensure that the new policy appears above the default in the list of configured policies. You should add the HTTP 1.1 policy to the top of the policy list because the policy evaluation engine evaluates policies from top to bottom, stopping when it encounters a match. For more information, see “Resource policy evaluation” on page 86. The IVE comes with a default policy that disables HTTP 1.1 for all resources. If you want to use HTTP 1.1 for all resources, either redefine the “*:*/*” policy or create a new policy enabling HTTP 1.1 and move it to the top of your policy list. If you delete this default policy (and any other policies that disable HTTP 1.1), the IVE uses HTTP 1.0 for all resources To write an HTTP 1.1 protocol resource policy: 1. In the admin console, navigate to Users > Resource Policies > Web. 2. If your administrator view is not already configured to show protocol policies, make the following modifications: a. Click the Customize button in the upper right corner of the page. b. Select the Protocol checkbox. c. Click OK. 3. Select the Protocol tab. 4. On the Web Protocol Policies page, click New Policy. 354 Defining resource policies: HTTP 1.1 protocol Chapter 13: Web rewriting 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 URLs to which this policy applies. See “Specifying resources for a resource policy” on page 83 for more information. To enable IP-based or case sensitivity matching for these resources, see “Defining resource policies: General options” on page 355. 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: Disable HTTP 1.1—The IVE automatically communicates with backend servers via the HTTP 1.0 protocol. Enable HTTP 1.1—The IVE automatically communicates with backend servers using the HTTP 1.1 protocol as long as the client also communicates using the HTTP 1.1 protocol. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 9. Click Save Changes. Defining resource policies: General options When you enable the Web resource policy options described in this section, the IVE compiles a list of host names specified in the Resources field of each Web resource policy. The IVE then applies the enabled options to this comprehensive list of host names. To specify Web resource options: 1. In the admin console, navigate to Users > Resource Policies > Web. 2. If your administrator view is not already configured to show Web options, make the following modifications: a. Click the Customize button in the upper right corner of the page. Defining resource policies: General options 355 Juniper Networks Secure Access Administration Guide b. Select the Options checkbox. c. Click OK. 3. Select the Options tab. 4. Select IP based matching for Hostname based policy resources if you want the to IVE look up IP address corresponding to each host name specified in a Web resource policy. When a user tries to access a server by specifying an IP address rather than the host name, the IVE compares the IP to its cached list of IP addresses to determine if a host name matches an IP. If there is a match, then the IVE accepts the match as a policy match and applies the action specified for the resource policy. NOTE: This option does not apply to host names that include wildcards and parameters. 5. Select Case sensitive matching for the Path and Query string components in Web resources if you want to require users to enter a case-sensitive URL to a resource. For example, use this option when passing username or password data in a URL. 6. Click Save Changes. Managing resource policies: Customizing UI views You can control which Web resource policy configuration pages the IVE displays so that you only have to view those pages that you actually use. Or, if you have a new IVE installation, you can use these settings to display additional pages (since the IVE only displays the most commonly used resource policy pages to new users). To control which Web resource policy configuration pages the IVE displays: 1. Navigate to Users > Resource Policies > Web > Policy Type. 2. Click the Customize View button in the upper right corner of the console: 3. In the Customize View dialog box, specify which Web resource policies you want to display in the admin console. You may manually select individual checkboxes, click All Pages to display all Web resource policy configuration pages, or click Common Pages to display the most commonly used Web resource policy configuration pages. (Note that the IVE does not allow you to hid the Web Access Policies page.) 4. Click OK. 356 Managing resource policies: Customizing UI views Chapter 14 Hosted 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. 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 section contains the following information about hosting Java applets on the IVE: “Licensing: Hosted Java applets availability” on page 357 “Task Summary: Hosting Java applets” on page 357 “Hosted Java applets overview” on page 358 “Defining resource profiles: Hosted Java applets” on page 362 “Use case: Creating a Citrix JICA 8.0 Java applet bookmark” on page 368 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 in order 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, as explained in “Hosted Java applets overview” on page 358. Licensing: Hosted Java applets availability 357 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 > Hosted Java Applets page of the admin console. For instructions, see “Defining resource profiles: Hosted Java applets” on page 362. 2. If you choose to sign your Java applets, use settings in the System > Configuration > Certificates > Code-Signing Certificates page of the admin console to upload the Java certificate to the IVE (optional). 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 623. 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 575. b. After you finish configuring the IVE, cache your Java applet and access it as 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. 358 Hosted Java applets overview Chapter 14: Hosted Java applets 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: Please note the following: 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 336. Configuration options for the hosted Java applet feature have moved to the Users > Resource Profiles > Web > Hosted Java Applets page in the admin console. If you are upgrading the product from a pre-5.3 version, 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 sections contain information about uploading, enabling, and accessing Java applets through the IVE: “Uploading Java applets to the IVE” on page 359 “Signing uploaded Java applets” on page 360 “Creating HTML pages that reference uploaded Java applets” on page 361 “Accessing Java applet bookmarks” on page 361 “Use case: Creating a Citrix JICA 8.0 Java applet bookmark” on page 368 Uploading Java applets to the IVE 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. You can then use these 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. For more information, see “Use case: Creating a Citrix JICA 8.0 Java applet bookmark” on page 368.) Hosted Java applets overview 359 Juniper Networks Secure Access Administration Guide 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. 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. 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. 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 362. 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 resigns) 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 623. 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 resign 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. 360 Hosted Java applets overview Chapter 14: Hosted Java applets 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 361). 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 this 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 place holders 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 a hosted Java applet bookmark” on page 363. 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:// /dana/home/launchWebapplet.cgi?bmname= https:// /dana/home/launchWebapplet.cgi?id= &b mname= Hosted Java applets overview 361 Juniper Networks Secure Access Administration Guide (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. For more information, see the note in “Sign-in policies” on page 181. For information about creating bookmarks, see “Defining a hosted Java applet bookmark” on page 363. Defining resource profiles: Hosted Java applets To create a hosted Java applet resource profile: 1. Navigate to the Users > Resource Profiles > Hosted Java Applet page in the admin console. 2. Click New Profile. 3. Enter a unique name and optionally a description for the resource profile. 4. In the Upload Applet Resources section: a. 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. b. Select the Expand uploaded archive checkbox if the actual Java applet is archived within the file you specified above. 5. If your Java applets need to make socket connections, use settings in the Autopolicy: Java Access Control section to enable access. For more detailed instructions, see “Defining a Java access control autopolicy” on page 298. 6. Click Save and Continue. 7. When the following upload agreement appears, read it and click OK if you accept its terms: 362 Defining resource profiles: Hosted Java applets Chapter 14: Hosted Java applets You are about to load third party software onto the Juniper product. Before you do, you must read and agree to the following terms on behalf of yourself (as the purchaser of the equipment) or the organization that purchased the Juniper product, as applicable. By loading the third party software onto the Juniper product, you are responsible for obtaining all rights necessary for using, copying, and/or distributing such software in or with the Juniper 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 product and/or Juniper software, and may void any warranty for the Juniper product and/or software. Click on the OK button if you agree and wish to continue. 8. Read the details in the Upload Status dialog box and click OK when it is done. Once you accept the agreement, the IVE rewrites and signs the Java content, which may cause delay (depending on the size of the applet). 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 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. 10. Click Save Changes. 11. In the Bookmarks tab, create bookmarks using instructions in “Defining a hosted Java applet bookmark” on page 363. Defining a hosted Java applet bookmark You must create bookmarks to your hosted Java applets in order to enable endusers to access the applets. For more information about resource profile bookmarks, see “Defining bookmarks” on page 78. To configure hosted Java applet resource profile bookmarks: 1. If you want to create a resource profile bookmark through the standard resource profiles page: a. Navigate to the Users > Resource Profiles > Web > Hosted Java Applets > 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: Defining resource profiles: Hosted Java applets 363 Juniper Networks Secure Access Administration Guide a. Navigate to the Users > Roles > Select Role > Web > Bookmarks page in the admin console. b. Click New Bookmark. c. From the Type list, choose Pick an Applet Resource Profile. (The IVE does not display this option if you have not already created a hosted Java applet 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. 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 in order to make it clear to users which link they are accessing. For more information, see “Creating HTML pages that reference uploaded Java applets” on page 361. 3. 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 sections: 364 “Required attributes for uploaded Java applets” on page 365 “Required parameters for uploaded Java applets” on page 367 Defining resource profiles: Hosted Java applets Chapter 14: Hosted Java applets You can also add any additional HTML or JavaScript that you choose 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. 4. 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. 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. 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: Defining resource profiles: Hosted Java applets 365 Juniper Networks Secure Access Administration Guide 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 < > 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 < > includes a trailing slash, which means the following example works: Whereas this example does not work: archive—Indicates which archive file (that is, .jar, .cab, or .zip file) the Web browser should fetch. Example: archive="JICAEngN.jar" width and height—Indicates the size of the Java applet window (optional). Example: width="640" height="480" name—Specifies a label for the Java applet (optional). Example: name="CitrixJICA" align—Indicates the Java applet window’s alignment within the browser window (optional). Example: align="top" 366 Defining resource profiles: Hosted Java applets Chapter 14: Hosted Java applets NOTE: When defining attributes and their corresponding values, please 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 in order 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 < > variable to indicate that the IVE can find the file in zip archive uploaded to the IVE. For example: 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: 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 < > and < > values to the Java applet. For a list of available IVE variables, see “System variables and examples” on page 860. 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/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/paste the reference into the IVE bookmark since the IVE does not have access to the other Web server’s local resources. When copy/pasting parameters from another source, always check the values of the parameters. Defining resource profiles: Hosted Java applets 367 Juniper Networks Secure Access Administration Guide Use case: Creating a Citrix JICA 8.0 Java applet bookmark This section discusses how to enable access to a Citrix Metaframe server through the IVE using the 8.0 Java version of the Citrix ICA client (JICA). To enable the Citrix JICA 8.0 client using the Java applet upload feature: 1. Import code-signing certificates as explained in “Using code-signing certificates” on page 623. 2. Zip up the following .jar and .cab files into a single archive: JICA-configN.jar JICA-coreN.jar JICA-configM.cab JICA-coreM.cab (You can find these files on the Citrix Web site.) 3. Create a hosted Java applet resource profile through the Users > Resource Profiles > Web > Hosted Java Applets page of the admin console. When defining the resource profile: a. Upload the archived Citrix container file to the IVE. b. Select the Expand uploaded archive checkbox since 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 362.) 4. In the resource profile’s Bookmarks tab, generate the Web page for the bookmark. The IVE automatically inserts all of the .jar and .cab files into the corresponding Web page. Then, specify parameters for the Citrix client using the following example as a guide. (Note that the bookmark below can contain references to the jar and cab files that are in the zip file.) CitrixJICA Applet. Use case: Creating a Citrix JICA 8.0 Java applet bookmark 369 Juniper Networks Secure Access Administration Guide 370 Use case: Creating a Citrix JICA 8.0 Java applet bookmark Chapter 15 File rewriting A file resource profile controls access to resources on Windows server shares or Unix servers. This section contains the following information about configuring file writing options: “Licensing: File rewriting availability” on page 371 “Defining resource profiles: File rewriting” on page 371 “Defining role settings: Windows resources” on page 378 “Defining resource policies: Windows file resources” on page 381 “Defining role settings: UNIX/NFS file resources” on page 387 “Defining resource policies: UNIX/NFS file resources” on page 389 Licensing: File rewriting availability File 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 file rewriting features. Defining resource profiles: File rewriting A file resource profile controls access to resources on Windows server shares or Unix servers. (For more information about resource profiles, see “Resource profiles” on page 71.) To create a file rewriting resource profile: 1. Navigate to the Users > Resource Profiles > Files page in the admin console. 2. Click New Profile. 3. From the Type list, select Windows or Unix. 4. Enter a unique name and optionally a description for the resource profile. (This name becomes the default bookmark’s name.) Licensing: File rewriting availability 371 Juniper Networks Secure Access Administration Guide 5. Enter the resource to which you want to control access. Note that the format of the resource varies depending on which type of resource profile you are creating: Windows—Enter the server name or IP address, share name, and optionally the path that you want to control access to in the Server/share field. When entering the resource, use the format: \\server[\share[\path]]. Unix—Enter the server name or IP address and optionally the path that you want to control access to in the Server field. When entering the resource, use the format: server[/path] For detailed guidelines, see “Defining file resources” on page 373. (The IVE uses the specified directory to define the default bookmark for the resource profile.) 6. In the Autopolicy: Windows File Access Control section or the Autopolicy: Unix Access Control section, create a policy that allows or denies users access to the resource specified the previous step. (At minimum, you need to click Add in order to use the access control policy that the IVE automatically creates for you. This policy allows access to the specified directory and all of its subdirectories.) For more detailed instructions, see “Defining a file access control autopolicy” on page 374. 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 file compression autopolicy” on page 374 “Defining a single sign-on autopolicy (Windows only)” on page 375 NOTE: For information about specifying encoding options for Window or Unix resources, see “Encoding files” on page 844. (Encoding is an advanced option that currently you can only configure through resource policies.) 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 Files, Windows option or the Files, UNIX/NFS 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. 372 Defining resource profiles: File rewriting Chapter 15: File rewriting 11. (Optional) In the Bookmarks tab, modify the default bookmark created by the IVE and/or create new ones using instructions in “Defining a file bookmark” on page 376. (By default, the IVE creates a bookmark to the resource defined in the Windows or Unix field and displays it to all users assigned to the role specified in the Roles tab.) Defining file resources When creating a file resource profile (as explained in “Defining resource profiles: File rewriting” on page 371), you must use the following formats when defining a resource policy’s primary resource as well as its autopolicy resources. Windows resources: \\server[\share[\path]] Unix resources: server[/path] Within these formats, the three components are: Server (required)—Possible values: Hostname—You may use the system variablewhen defining the hostname. IP address—The IP address needs to be in the format: a.b.c.d The leading two back slashes are required for Windows, non-Nfs resources. Share (required, Windows only)—The system variable is allowed. Note that when the IVE tries to connect to a Windows file share, it connects to ports 445 and 139. Path (optional)—Special characters allowed include: Table 28: Path special characters * Matches any character. Note that you cannot use the * wildcard character when defining a resource profile’s primary resource (that is, the Server/share field for Windows resources or the Server field for Unix resources). % Matches any character except slash (/) ? Matches exactly one character Valid Windows resources include: \\juniper.com\dana \\10.11.0.10\share\web \\10.11.254.227\public\test.doc Defining resource profiles: File rewriting 373 Juniper Networks Secure Access Administration Guide Valid Unix resources include: juniper.com/dana 10.11.0.10/share/web 10.11.254.227/public/test.doc Defining a file access control autopolicy File access control policies specify resources on your file servers that users may access. When defining a file resource profile, you must create a corresponding 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 directory specified in the Server/share field (Windows) or the Server field (Unix) and all of its sub-directories. To enable this autopolicy, you simply need to select it and click Add. If necessary, you may choose to modify this default autopolicy or create supplementary file access control autopolicies that allow or deny access to additional resources. To create a new file access control autopolicy: 1. Create a file resource profile, as explained in “Defining resource profiles: File rewriting” on page 371. 2. If it is not already enabled, select the Autopolicy: Windows File Access Control checkbox or the Autopolicy: Unix Access Control checkbox. 3. In the Resource field, specify the resource to which this policy applies using the format: \\server[\share[\path]] for Windows resources and \\server[\path] for Unix resources. For detailed guidelines, see “Defining file resources” on page 373. 4. From the Action list, select one of the following options: Allow—Select this option to enable access to the specified resource. Read-only—Select this option to allow users to view but not edit the specified resource. Deny—Select this option to block access to the specified resource. 5. Click Add. 6. Click Save Changes. Defining a file compression autopolicy Compression autopolicies specify which types of file data the IVE should compress when you enable GZIP compression through the Maintenance > System > Options page of the admin console. For more information, see “Compression execution” on page 839. 374 Defining resource profiles: File rewriting Chapter 15: File rewriting To create a file compression autopolicy: 1. Create a file resource profile, as explained in “Defining resource profiles: File rewriting” on page 371. 2. Click Show ALL autopolicy types. 3. Select the Autopolicy: Windows File Compression checkbox or the Autopolicy: Unix File Compression checkbox. 4. In the Resource field, specify the resource to which this policy applies using the format: \\server[\share[\path]] for Windows resources and \\server[\path] for Unix resources. For detailed guidelines, see “Defining file resources” on page 373. 5. In the Action field, select one of the following options: Compress—Select this option to compress data from the specified resource. Do not compress—Select this option to disable compression for the specified resource. For a list of the types of data the IVE compresses, see “Supported data types” on page 840. 6. Click Add. Defining a single sign-on autopolicy (Windows only) Single sign-on (SSO) autopolicies configure the IVE to automatically submit credentials to a Windows share or directory so that the user does not have to reenter his credentials, as explained in “Single sign-on” on page 191. To create a Windows SSO autopolicy: 1. Create a Windows file resource profile, as explained in “Defining resource profiles: File rewriting” on page 371. 2. Click Show ALL autopolicy types. 3. Select the Autopolicy: Windows Server Single Sign-On checkbox. 4. In the Resource field, specify the resource to which this policy applies using the format: \\server[\share[\path]]. For detailed guidelines, see “Defining file resources” on page 373. Defining resource profiles: File rewriting 375 Juniper Networks Secure Access Administration Guide 5. Select one of the following options: Use predefined credentials—Select this option if you want to specify credentials to pass to the Windows share or directory. Then: i. In the Username field, enter variable (such as ) or a static username (such as administrator) to submit to the Windows share or directory. When entering a variable, you may also include a domain. For example, yourcompany.net\ . ii. Enter an IVE variable (such as ) in the Variable Password field or enter a static password in the Variable field. Note that the IVE masks the password you enter here with asterisks. When entering static credentials, note that the IVE file browsing server maintains the connections open to a server share, however, so connecting to a different folder on the same share using a different account may not work reliably. If the specified credentials fail, the IVE may submit alternative credentials, as explained in “Multiple sign-in credentials overview” on page 193. Disable SSO—Select this option if you do not want the IVE to automatically submit credentials to the specified Windows share or directory. 6. Click Save Changes. Defining a file bookmark When you create a file resource profile, the IVE automatically creates a bookmark that links to the primary resource 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. NOTE: When configuring bookmarks, note that: 376 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, if you enable access to a Windows directory but do not create a bookmark to that directory, users can access the directory through Windows Explorer. You cannot create bookmarks that link to additional servers defined through file access control autopolicies. If you use a bookmark to reference a file shortcut, note that the IVE only displays bookmarks with shortcuts to files or folders on a network share such as \\server5\share\users\jdoe\file.txt. However, the IVE does not display bookmarks with shortcuts to local directories such as C:\users\jdoe\file.txt. Defining resource profiles: File rewriting Chapter 15: File rewriting For more information about resource profile bookmarks, see “Defining bookmarks” on page 78. To configure file resource profile bookmarks: 1. If you want to create a resource profile bookmark through the standard resource profiles page: a. Navigate to the Users > Resource Profiles > Files > 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 > Files > Windows Bookmarks|Unix Bookmarks page in the admin console. b. Click New Bookmark. c. From the Type list, choose File Resource Profile. (The IVE does not display this option if have not already created a file 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.) Defining resource profiles: File rewriting 377 Juniper Networks Secure Access Administration Guide 3. In the File Browsing Path field, add a suffix to the resource if you want to create links to sub-directories of the resource 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 869. NOTE: Make sure to enter a unique server and path in this field. If you create two bookmarks that contain the same concatenated server and path string, 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. 4. In the Appearance section, choose one of the following options: Appear as bookmark on homepage and in file browsing—Select this option if you want the bookmark to appear both on a user’s welcome page and when browsing network files. Appear in file browsing only—Select this option if you want the bookmark to appear only when users are browsing network files. 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: Windows resources You can use two different methods to create Windows file bookmarks: 378 Create bookmarks through existing resource profiles (recommended)— When you select this method, the IVE automatically populates the bookmark with key parameters (such as the primary server and share) 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 “Defining a file bookmark” on page 376. Create standard bookmarks—When you select this option, you must manually enter all bookmark parameters during configuration. Additionally, you must enable access to the file browsing at the role level and create resource policies that enable access to the servers defined in the bookmark. For configuration instructions, see “Creating advanced bookmarks to Windows resources” on page 379. Defining role settings: Windows resources Chapter 15: File rewriting You can create Windows bookmarks that appear on the welcome page for users mapped to this role. You can insert the user’s IVE username in the URL path to provide quick access to the user’s network directories. When IVE users are browsing files on a Dfs server, the Dfs server uses the site configuration data stored in Active Directory to return Dfs referrals to the IVE in the right order. Referrals to closer servers are put higher in the list than referrals to servers that are farther away. Clients try referrals in the order in which they are received. If a request comes from a client which resides in a subnet which is not in this list, the server will not know where the client is coming from and will return the list of referrals to the customer in an arbitrary order. This could potentially cause the Dfs requests from the IVE (acting as the client in this case) to access a server much farther away. In turn, this could cause serious delays, especially if the IVE attempts to access a server which is unreachable from the subnet which the IVE resides in. If the IVE is installed on a subnet which is not in the Dfs server's list, the Dfs administrator may use the “Active Directory Sites and Services” tool on the domain controller to add the IVE's subnet to the appropriate site. This section contains the following information about defining bookmarks and rolelevel settings for Windows file browsing resources: “Creating advanced bookmarks to Windows resources” on page 379 “Creating Windows bookmarks that map to LDAP servers” on page 380 “Defining general file browsing options” on page 381 Creating advanced bookmarks to Windows resources NOTE: Information in this section is provided for backwards compatibility. We recommend that you configure access to Windows shares and directories through resource profiles instead, since they provide a simpler, more unified configuration method. For more information, see “Defining resource profiles: File rewriting” on page 371. To create a bookmark to a Windows resource: 1. In the admin console, choose Users > User Roles > RoleName > Files > Windows Bookmarks. 2. Click New Bookmark and then browse to or enter the server and share name. Specify a path to further restrict access. If you want to insert the user’s username, enter at the appropriate place in the path. 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 869. If you specify a name and description for the bookmark, this information displays on the IVE home page instead of the server/share. Defining role settings: Windows resources 379 Juniper Networks Secure Access Administration Guide NOTE: You may not bookmark a Windows server. You must specify both the server and share name. Make sure to enter a unique server and path in this field. If you create two bookmarks that contain the same concatenated server and path string, 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. 3. For Appearance, choose either: Appear as bookmark on homepage and in file browsing if you want the bookmark to appear both on a user’s welcome page and when browsing network files. Appear in file browsing only if you want the bookmark to appear only when browsing network files. 4. For Access, click Enable auto-allow access to this bookmark if you want the IVE to automatically create a corresponding Windows Access resource policy. Note that this functionality applies only to role bookmarks and not bookmarks created by users. Next, select: Read-write access to enable users to save files on the server. Note that users cannot upload files greater than 500 MB to the server. Include sub-folders to enable users to view files in directories below the specified bookmark path. 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 575. 5. Click Save Changes or Save + New to add another. Creating Windows bookmarks that map to LDAP servers To create a bookmark that automatically maps to a user’s LDAP home directory: 1. Create an LDAP server instance, as described in “Defining an LDAP server instance” on page 107. 2. Add the LDAP attribute homeDirectory to the Server Catalog. 3. Configure a realm and bind LDAP as the authentication server, as described in “Defining an LDAP server instance” on page 107. 4. Configure role-mapping rules, as needed. 380 Defining role settings: Windows resources Chapter 15: File rewriting 5. Create a Windows bookmark using instructions in one of the following sections: “Defining a file bookmark” on page 376 “Creating advanced bookmarks to Windows resources” on page 379 During configuration, specify in the bookmark. 6. Click Save Changes. Defining general file browsing options To specify general Windows file browsing options: 1. In the admin console, choose Users > User Roles > RoleName > Files > Options. 2. Under Windows Network Files, specify which options to enable for users: User can browse network file shares—If enabled, users can view and create bookmarks to resources on available Windows file shares. User can add bookmarks—If enabled, users can view and create bookmarks to resources on available Windows file shares. 3. Click Save Changes. Defining resource policies: Windows file resources When you enable the File access feature for a role, you need to create resource policies that specify which Windows and UNIX/NFS resources a user may access, as well as the encoding to use when communicating with Windows and NFS file shares. When a user makes a file request, the IVE evaluates the resource policies corresponding to the request, such as Windows access resource policies for a request to fetch an MS Word document (.doc file). 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 File 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 File policy, you need to specify File servers or specific shares. 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. Defining resource policies: Windows file resources 381 Juniper Networks Secure Access Administration Guide 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 allow a user to write to a directory. You can also write detailed rules that apply more conditions to a user request. See “Writing a detailed rule” on page 88. The IVE engine that evaluates resource policies requires that the resources listed in a policy’s Resources list follow a canonical format. This section contains the following information about writing UNIX/NFS file resource policies: “Canonical format: Windows file resources” on page 382 “Writing a Windows access resource policy” on page 383 “Writing a Windows SSO resource policy” on page 384 “Writing a Windows compression resource policy” on page 386 “Defining general file writing options” on page 387 Canonical format: Windows file resources NOTE: Information in this section is provided for backwards compatibility. We recommend that you configure access to Windows file servers through resource profiles instead, since they provide a simpler, more unified configuration method. For more information, see “Defining resource profiles: File rewriting” on page 371. When writing a resource policy for a Windows file resource, you need to understand the following canonical format. Canonical format: \\server[\share[\path]] The three components are: Server (required)—Possible values: Hostname—The system variable may be used. IP address—The IP address needs to be in the format: a.b.c.d The leading two back slashes are required. 382 Share (optional)—If the share is missing, then star (*) is assumed, meaning ALL paths match. The system variable is allowed. Defining resource policies: Windows file resources Chapter 15: File rewriting Path (optional)—Special characters allowed include: Table 29: Path special characters * Matches any character % Matches any character except slash (/) ? Matches exactly one character If the path is missing, then slash (/) is assumed, meaning only top-level folders are matched. For example: \\%.danastreet.net\share\ \* \\*.juniper.com\dana\* \\10.11.0.10\share\web\* \\10.11.254.227\public\%.doc Writing a Windows access resource policy NOTE: Information in this section is provided for backwards compatibility. We recommend that you configure access to Windows file servers through resource profiles instead, since they provide a simpler, more unified configuration method. For more information, see “Defining resource profiles: File rewriting” on page 371. To write a Windows access resource policy: 1. In the admin console, choose Users > Resource Policies > Files > Access > Windows. 2. On the Windows File 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 “Canonical format: Windows file resources” on page 382 for more information. 5. 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. Defining resource policies: Windows file resources 383 Juniper Networks Secure Access Administration Guide 6. In the Action section, specify: Allow access—To grant access to the resources specified in the Resources list. Check Read-only to prevent users from saving files on the server. Deny access—To deny access to the resources specified in the Resources list. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 7. Click Save Changes. 8. On the Windows File Access 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. If you want to write a File resource policy that enables you to specify credentials for the IVE to submit to a file server when a user request matches a resource in the Resource list, you can use the following procedure to do so. You can also configure the IVE to prompt users for credentials. Writing a Windows SSO resource policy NOTE: Information in this section is provided for backwards compatibility. We recommend that you configure access to Windows file servers through resource profiles instead, since they provide a simpler, more unified configuration method. For more information, see “Defining resource profiles: File rewriting” on page 371. To write a Windows credentials resource policy: 1. In the admin console, choose Users > Resource Policies > Files > SSO > Windows. 2. On the Windows Credentials 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 “Canonical format: Windows file resources” on page 382 for more information. 5. In the Roles section, specify: 384 Policy applies to ALL roles—To apply this policy to all users. Defining resource policies: Windows file resources Chapter 15: File rewriting 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. 6. In the Action section, specify: Use static credentials—This option enables you to specify static administrator credentials that the IVE submits to resources specified in the Resources list at the folder and file level. The IVE file browsing server maintains the connections open to a server\share, however, so connecting to a different folder on the same share using a different account may not work reliably. If the specified credentials fail, the IVE may submit alternative credentials, as explained in “Single sign-on” on page 191. Note that the IVE masks the password you enter here with asterisks. Use variable credentials—This option enables you to specify variable administrator credentials that the IVE submits to resources specified in the Resources list at the folder and file level. Note that you may enter IVE variables such as and in these fields as well as a domain. For example: yourcompany.net\ . If the specified credentials fail, the IVE may submit alternative credentials, as explained in “Single sign-on” on page 191. Prompt for user credentials—If a file share on a resource specified in the Resources list requires credentials, then IVE intermediates the challenge by presenting an authentication challenge in the IVE. The user needs to enter the credentials for the share that he is trying to access. If the specified credentials fail, the IVE denies the user access to the resource. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 7. Click Save Changes. 8. On the Windows File Access 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. Defining resource policies: Windows file resources 385 Juniper Networks Secure Access Administration Guide Writing a Windows compression resource policy NOTE: Information in this section is provided for backwards compatibility. We recommend that you configure compression through resource profiles instead, since they provide a simpler, more unified configuration method. For more information, see “Defining a file compression autopolicy” on page 374. Compression policies specify which types of file data the IVE should compress when you enable GZIP compression through the Maintenance > System > Options page of the admin console. For more information, see “Compression execution” on page 839. The IVE comes pre-equipped with two file compression policies (*:*/*) which compress all applicable file data. You may enable these policies through the Resource Policies > Files > Compression pages of the admin console. To write a Windows file compression resource policy: 1. In the admin console, choose Resource Policies > Files > Compression. 2. Select the Windows tab. 3. Click New Policy. 4. On the New Policy page, enter: a. A name to label this policy. b. A description of the policy (optional). 5. In the Resources section, specify the resources to which this policy applies. See “Specifying resources for a resource policy” on page 83 for more information. 6. 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. 7. In the Action section, specify: 386 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. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. Defining resource policies: Windows file resources Chapter 15: File rewriting 8. Click Save Changes. Defining general file writing options You can specify File resource options that apply to your File resource policies. When you enable a File resource policy option, the IVE compiles a list of host names specified in the Resources field of each File resource policy. The IVE then applies the enabled options to this comprehensive list of host names. To specify resource options for Windows file servers: 1. In the admin console, choose Users > Resource Policies > Files > Options. 2. Select: IP based matching for Hostname based policy resources—The IVE looks up the IP address corresponding to each host name specified in a File resource policy. When a user tries to access a server by specifying an IP address rather than the host name, the IVE compares the IP to its cached list of IP addresses to determine if a host name matches an IP. If there is a match, then the IVE accepts the match as a policy match and applies the action specified for the resource policy. NOTE: This option does not apply to host names that include wildcards and parameters. Allow NTLM V1—Select this option to fall back to NTLM version 1 authentication if Kerberos authentication of administrator credentials fails. 3. Click Save Changes. Defining role settings: UNIX/NFS file resources You can use two different methods to create Unix file 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 server) 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 “Defining a file bookmark” on page 376. Create standard bookmarks—When you select this option, you must manually enter all bookmark parameters during configuration. Additionally, you must enable access to the file browsing at the role level and create resource policies that enable access to the servers defined in the bookmark. For configuration instructions, see “Creating advanced bookmarks to UNIX resources” on page 388. Defining role settings: UNIX/NFS file resources 387 Juniper Networks Secure Access Administration Guide You can create Unix bookmarks that appear on the welcome page for users mapped to this role. You can insert the user’s IVE username in the URL path to provide quick access to the user’s network directories. This section contains the following information about defining bookmarks and rolelevel settings for Unix file browsing resources: “Creating advanced bookmarks to UNIX resources” on page 388 “Defining general file browsing options” on page 389 Creating advanced bookmarks to UNIX resources NOTE: Information in this section is provided for backwards compatibility. We recommend that you configure access to Unix servers through resource profiles instead, since they provide a simpler, more unified configuration method. For more information, see “Defining resource profiles: File rewriting” on page 371. You can create UNIX/NFS bookmarks that appear on the IVE home page. You can insert the user’s IVE username in the URL path to provide quick access to the user’s network directories. To create a bookmark to a UNIX/NFS resource: 1. In the admin console, choose Users > User Roles > RoleName > Files > UNIX Bookmarks. 2. Click New Bookmark and then enter the server host name or IP address and the path to the share. If you want to insert the user’s username, enter at the appropriate place in the path. If you specify a name and description for the bookmark, this information displays on the IVE home page instead of the server/path. NOTE: Make sure to enter a unique server and path in this field. If you create two bookmarks that contain the same concatenated server and path string, 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. 3. For Appearance, choose either: 388 Appear as bookmark on homepage and in file browsing if you want the bookmark to appear both on a user’s welcome page and when browsing network files. Appear in file browsing only if you want the bookmark to appear only when browsing network files. Defining role settings: UNIX/NFS file resources Chapter 15: File rewriting 4. For Access, click Enable auto-allow access to this bookmark if you want the IVE to automatically create a corresponding UNIX/NFS resource policy. Note that this functionality applies only to role bookmarks and not bookmarks created by users. Next, select: Read-write access to enable users to save files on the server. Note that users cannot upload files greater than 500 MB to the server. Include sub-folders to enable users to view files in directories below the specified bookmark path. 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 575. 5. Click Save Changes or Save + New to add another. Defining general file browsing options To specify general file browsing options: 1. In the admin console, choose Users > User Roles > RoleName > Files > Options. 2. Under UNIX Network Files, specify which options to enable for users: User can browse network file shares—If enabled, users can view and create bookmarks to resources on available UNIX file shares. User can add bookmarks—If enabled, users can view and create bookmarks to resources on available UNIX file shares. Allow automount shares—If enabled, users access to automount shares specified on a NIS server. 3. Click Save Changes. Defining resource policies: UNIX/NFS file resources When you enable the File access feature for a role, you need to create resource policies that specify which Windows and UNIX/NFS resources a user may access, as well as the encoding to use when communicating with Windows and NFS file shares. When a user makes a file request, the IVE evaluates the resource policies corresponding to the request, such as Windows access resource policies for a request to fetch an MS Word document (.doc file). 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). Defining resource policies: UNIX/NFS file resources 389 Juniper Networks Secure Access Administration Guide When writing a File 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 File policy, you need to specify File servers or specific shares. 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 allow a user to write to a directory. You can also write detailed rules that apply more conditions to a user request. See “Writing a detailed rule” on page 88. The IVE engine that evaluates resource policies requires that the resources listed in a policy’s Resources list follow a canonical format. This section contains the following information about writing UNIX/NFS file resource policies: “Canonical format: UNIX/NFS file resources” on page 390 “Writing UNIX/NFS resource policies” on page 391 “Writing a Unix/NFS compression resource policy” on page 392 “Defining general file writing options” on page 393 Canonical format: UNIX/NFS file resources When writing a resource policy for a UNIX/NFS file resource, you need to understand the following canonical format. Canonical format: server[/path] The two components are: Server (required)—Possible values: Hostname—The system variable may be used. IP address—The IP address needs to be in the format: a.b.c.d The leading two back slashes are required. Path (optional)—Special characters allowed include: Table 30: Path special characters 390 * Matches any character % Matches any character except back slash (\) Defining resource policies: UNIX/NFS file resources Chapter 15: File rewriting Table 30: Path special characters (Continued) Matches exactly one character ? If the path is missing, then back slash (\) is assumed, meaning only top-level folders are matched. For example: %.danastreet.net/share/users/ /* *.juniper.com/dana/* 10.11.0.10/web/* 10.11.254.227/public/%.txt Writing UNIX/NFS resource policies NOTE: Information in this section is provided for backwards compatibility. We recommend that you configure access to Unix file servers through resource profiles instead, since they provide a simpler, more unified configuration method. For more information, see “Defining resource profiles: File rewriting” on page 371. To write a UNIX/NFS resource policy: 1. In the admin console, choose Users > Resource Policies > Files > Access > Unix/NFS. 2. On the Unix/NFS File 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 “Canonical format: UNIX/NFS file resources” on page 390 for more information. 5. 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. 6. In the Action section, specify: Allow access—To grant access to the resources specified in the Resources list. Check Read-only to prevent users from saving files on the server. Defining resource policies: UNIX/NFS file resources 391 Juniper Networks Secure Access Administration Guide Deny access—To deny access to the resources specified in the Resources list. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 7. Click Save Changes. 8. On the Unix/NFS File Access 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. Writing a Unix/NFS compression resource policy NOTE: Information in this section is provided for backwards compatibility. We recommend that you configure access to Unix file servers through resource profiles instead, since they provide a simpler, more unified configuration method. For more information, see “Defining resource profiles: File rewriting” on page 371. Compression policies specify which types of file data the IVE should compress when you enable GZIP compression through the Maintenance > System > Options page of the admin console. For more information, see “Compression execution” on page 839. The IVE comes pre-equipped with two file compression policies (*:*/*) which compress all applicable file data. You may enable these policies through the Resource Policies > Files > Compression pages of the admin console. To write a Unix/NFS file compression resource policy: 1. In the admin console, choose Resource Policies > Files > Compression. 2. Select the Unix/NFS tab. 3. Click New Policy. 4. On the New Policy page, enter: a. A name to label this policy. b. A description of the policy (optional). 5. In the Resources section, specify the resources to which this policy applies. See “Specifying resources for a resource policy” on page 83 for more information. 6. In the Roles section, specify: 392 Policy applies to ALL roles—To apply this policy to all users. Defining resource policies: UNIX/NFS file resources Chapter 15: File rewriting 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. 7. In the Action section, specify: 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. Use Detailed Rules—To specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 8. Click Save Changes. Defining general file writing options You can specify File resource options that apply to your File resource policies. When you enable a File resource policy option, the IVE compiles a list of host names specified in the Resources field of each File resource policy. The IVE then applies the enabled options to this comprehensive list of host names. To specify options for UNIX/NFS resources: 1. In the admin console, choose Users > Resource Policies > Files > Options. 2. Select: IP based matching for Hostname based policy resources—The IVE looks up the IP address corresponding to each host name specified in a File resource policy. When a user tries to access a server by specifying an IP address rather than the host name, the IVE compares the IP to its cached list of IP addresses to determine if a host name matches an IP. If there is a match, then the IVE accepts the match as a policy match and applies the action specified for the resource policy. NOTE: This option does not apply to host names that include wildcards and parameters. Case sensitive matching for the Path component in File resources— Select this option to require users to enter a case-sensitive URL to an NFS resource. Use this option when passing username or password data in a URL. Defining resource policies: UNIX/NFS file resources 393 Juniper Networks Secure Access Administration Guide NOTE: This option does not apply to Windows servers. Allow NTLM V1—Select this option to fall back to NTLM version 1 authentication if Kerberos authentication of administrator credentials fails. 3. Click Save Changes. 394 Defining resource policies: UNIX/NFS file resources Chapter 16 Secure Application Manager The Secure Application Manager option provides secure, application-level remote access to enterprise servers from client applications. You may deploy two versions of the Secure Application Manager: Windows version (W-SAM)—The Windows version of the Secure Application Manager is a Windows-based solution that enables you to secure traffic to individual client/server applications and application servers. Java version (J-SAM)—The Java version of the Secure Application Manager provides support for static TCP port client/server applications, including enhanced support for Microsoft MAPI, Lotus Notes, and Citrix NFuse. J-SAM also provides NetBIOS support, which enables users to map drives to specified protected resources. This section contains the following information about Secure Application Manager: “Licensing: Secure Application Manager availability” on page 396 “Task Summary: Configuring WSAM” on page 396 “W-SAM overview” on page 397 “Defining resource profiles: WSAM” on page 401 “Defining role settings: WSAM” on page 404 “Defining resource policies: WSAM” on page 410 “Using the W-SAM launcher” on page 413 “Task Summary: Configuring JSAM” on page 416 “J-SAM overview” on page 417 “Defining resource profiles: JSAM” on page 435 “Defining role settings: JSAM” on page 439 “Defining resource policies: JSAM” on page 443 395 Juniper Networks Secure Access Administration Guide Licensing: Secure Application Manager availability The Secure Application Manager features (WSAM and JSAM) are not available on the SA 700 appliance. Task Summary: Configuring WSAM This section provides high-level WSAM configuration steps. These steps do not account for preliminary IVE configuration steps such as specifying the IVE’s network identity or adding user IDs to the IVE. To configure WSAM: 1. Create resource profiles that enable access to client/server applications or destination networks, create supporting autopolicies as necessary, and assign the policies to user roles using settings in the Users > Resource Profiles> SAM pages of the admin console. For instructions, see “Defining resource profiles: WSAM” on page 401. We recommend that you use resource profiles to configure WSAM (as described above). However, if you do not want to use resource profiles, you can configure WSAM using role and resource policy settings in the following pages of the admin console instead: a. Enable access to WSAM at the role-level using settings in the Users > User Roles > Role > General > Overview page of the admin console. For instructions, see “Configuring user roles” on page 54. b. Specify which client/server applications and servers WSAM should intermediate using settings in the Users > User Roles > SAM > Applications page of the admin console. For instructions, see “Specifying applications and servers for WSAM to secure” on page 405. c. Specify which application servers users can access through WSAM using settings in the Users > Resource Policies > SAM > Access page of the admin console. For instructions, see “Specifying application servers that users can access” on page 410. 2. After enabling access to client/server applications and/or destination networks using WSAM 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) Configure role-level options such as whether the IVE should automatically launch and upgrade WSAM using settings in the Users > User Roles > SAM > Options page of the admin console. For instructions, see “Specifying resource level WSAM options” on page 412. b. (Optional) Control IP based hostname matching at the resource level using settings in the Users > Resource Policies > SAM > Options page of the admin console. For instructions, see “Specifying resource level WSAM options” on page 412. 396 Licensing: Secure Application Manager availability Chapter 16: Secure Application Manager 3. Ensure that an appropriate version of WSAM is available to remote clients using settings in the Maintenance > System > Installers page of the admin console. For instructions, see “Downloading application installers” on page 577. 4. If you want to enable or disable client-side logging for WSAM, configure the appropriate options through the System > Configuration > Security > Client-side Logs tab of the admin console. For instructions, see “Enabling client-side logs” on page 679. W-SAM overview WSAM is a Windows-based solution that enables you to secure traffic to individual client/server applications such as Lotus Notes, Microsoft Outlook, Citrix, and NetBIOS file browsing as well as application servers. You can download and launch WSAM using an ActiveX control hosted on the IVE, a Java delivery mechanism, or the W-SAM launcher pre-installed on the client. You can also enable WSAM on handheld/PDA devices. For specific information regarding configuration and support for PDAs, see “Enabling WSAM on PDAs” on page 851. This section contains the following information about WSAM: “Securing client/server traffic using WSAM” on page 397 “Antivirus and VPN client application compatibility” on page 400 “Launching Network Connect during a WSAM session” on page 401 “Debugging WSAM issues” on page 401 Securing client/server traffic using WSAM The following diagram illustrates how WSAM secures client-server traffic. A description of each of the steps follows the diagram. W-SAM overview 397 Juniper Networks Secure Access Administration Guide Figure 35: Windows Secure Application Manager 1. The user invokes WSAM through his IVE session. The user can invoke WSAM automatically or manually. If you configure WSAM to auto-launch, the user invokes WSAM simply by signing into the IVE. Or, if you or the user disables the auto-launch option, the user can manually invoke WSAM by clicking its link on the IVE home page. (If you enable auto-launch, users can override the setting through the Preferences > Applications page of the end-user console.) 2. If WSAM is not already installed on the user’s system, the IVE downloads it to the user’s machine. The delivery mechanism then installs the W-SAM software on the client machine. WSAM delivery mechanisms include: ActiveX control—This primary software delivery mechanism controls all W-SAM installation functions. It downloads from the IVE when a user launches WSAM from the IVE home page. Java delivery—The IVE appliance provides this secondary delivery mechanism if the IVE fails to download or upgrade the ActiveX control due to browser restrictions. As with the ActiveX control, the Java delivery mechanism controls all W-SAM installation functions. 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 W-SAM. On all other Microsoft operating systems, the setup client and W-SAM install automatically. For information on removing the Juniper ActiveX control, see “Removing the Juniper ActiveX Control” on page 265. 398 W-SAM overview Chapter 16: Secure Application Manager Scriptable W-SAM Launcher—This tool enables users to launch W-SAM manually from a command line or automatically from a batch file, an application that performs a shell call, or a Win32 service. To use this mechanism, you need to distribute the launcher to users, as described in “Downloading application installers” on page 577. Users can then invoke WSAM through a command prompt window using the command line arguments described in “Using the W-SAM launcher” on page 413. Or, an application or script may launch W-SAM by passing parameters to the launcher. (For example, a PC batch-file script can invoke the W-SAM launcher when the computer boots.) NOTE: For information about the directories in which the WSAM delivery mechanisms run, files they install on the user’s computer, log file locations, the rights that users must have in order to run each of these delivery mechanisms, and browser settings users must enable, see the Client-side Changes Guide on the Juniper Networks Customer Support Center. The IVE feeds role and client information defined on the server to the WSAM client machine during WSAM initialization. (If the filtering policies change, the client machine does not reflect those changes until the next sign-in session. Any changes to the IVE server access control rules take effect immediately.) 3. The WSAM client installs a Layered Service Provider (LSP) or Transport Driver Interface (TDI) driver on the client to secure application traffic. (If the traffic originates from a Windows 98 or Windows Millennium system, WSAM uses an LSP mechanism. If the traffic originates from a Windows 2000 or Windows XP system, WSAM uses a TDI mechanism.) The WSAM status window icon appears in the system tray. Users can double-click this icon to see the current session status and a list of applications and hosts specified for WSAM to intermediate. 4. The user launches an application or requests data from a server that you have configured through WSAM. When the client application or the process tries to connect to the resource, WSAM intercepts the request. WSAM intercepts TCP and UDP connection calls from applications and DNS queries for destination server host names. 5. WSAM forwards the host name of the client application or destination server to the IVE over SSL. 6. The IVE resolves the host name against the DNS server. 7. The IVE returns up to 8 resolved IP addresses of the target host to WSAM. W-SAM overview 399 Juniper Networks Secure Access Administration Guide 8. WSAM automatically configures a port-forwarding channel using a preprovisioned localhost IP address. NOTE: If you enable the Persistent Session option on the Users > User Roles > Role > General > Session Options tab, the IVE caches the username and password in the persistent session cookie after the first successful authentication. This poses a potential security risk since the W-SAM launcher uses the information stored in the persistent session cookie for all subsequent sign-in attempts during the existing session even if you terminate the W-SAM connection. For more information about persistent sessions, see “Specifying session options” on page 57. Users may experience problems waiting for the Secure Application Manager to fully load if they enable pop-up blockers through their Web browsers. This problem occurs because a pop-up window alerting users to accept the Secure Application Manager plug-in may appear in the background (behind the Web browser window) where users cannot see it. Antivirus and VPN client application compatibility Table 31 shows the compatibility of several antivirus and VPN client applications with W-SAM and Windows 98 and Windows Millennium. Table 31: WSAM for Windows 98 and Windows Millennium compatibility Software Version Compatible? Norton AntiVirus 2003 Yes Norton AntiVirus 2004 Yes Norton AntiVirus Professional 2004 Yes Norton AntiVirus Corporate Edition 8.0 Yes McAfee 7.0 No McAfee 8.0 Yes NOTE: If a conflict exists between WSAM and one of the third-party applications on Windows 98 or Windows Millennium, the IVE blocks the download and displays an error message detailing the conflict. Table 32 shows the compatibility of several antivirus and VPN client applications with W-SAM for Windows 2000 and Windows XP. Table 32: WSAM for Windows 2000 and Windows XP compatibility Software Version File-sharing disabled File-sharing enabled Norton AntiVirus 2003 Yes Yes Norton AntiVirus 2004 Yes Yes Norton AntiVirus Professional 2004 Yes No Yes Yes Norton AntiVirus Corporate Edition 8.0 400 W-SAM overview Chapter 16: Secure Application Manager Table 32: WSAM for Windows 2000 and Windows XP compatibility (Continued) Software Version File-sharing disabled File-sharing enabled Trend Micro PC-cillin 2004 No Yes TheGreenBow Personal Firewall 2.5 Yes Yes Launching Network Connect during a WSAM session Users can launch Network Connect while signed in to the IVE via WSAM. If they do, however, the Network Connect installer automatically terminates the WSAM session prior to launching Network Connect. During the process, the IVE prompts users with a warning message informing them that they are about to terminate their WSAM session in favor of launching Network Connect. To deal with situation, we recommend that you give users as much access to network resources through Network Connect as through WSAM. If you do, when the users choose to launch Network Connect (simultaneously terminating WSAM), they will still be able to access the same network resources. For more information, refer to “Launching Network Connect during a Windows Secure Application Manager session” on page 529. Debugging WSAM issues You can use the Secure Application Manager dialog box on the an end-user’s system to view the WSAM status and a variety of details about the user’s session. For instance, the Secure Application Manager dialog box displays the applications and servers that WSAM is configured to secure, event logs and Winsock data for the user’s session, and various system diagnostics and performance data. This information can help you or a Juniper Networks Support representative debug any problems your users may encounter. To access the Secure Application Manager dialog box, users simply need to double-click the WSAM icon on their Windows task bars: For more information about viewing information in the Secure Application Manager dialog box, see the end-user help system available from the Help link in the IVE end-user console. Defining resource profiles: WSAM You can create two types of WSAM resource profiles: WSAM application resource profiles—These resource profiles configure WSAM to secure traffic to a client/server application. When you create a WSAM application resource profile, the WSAM client intercepts requests from the specified client applications to servers in your internal network. Defining resource profiles: WSAM 401 Juniper Networks Secure Access Administration Guide WSAM destination network resource profiles—These resource profiles configure WSAM to secure traffic to a server. When you create a WSAM destination network resource profile, the WSAM client intercepts requests from processes running on the client that are connecting to the specified internal hosts. For more information about resource profiles, see “Resource profiles” on page 71. For more information about WSAM, see “W-SAM overview” on page 397. NOTE: When creating WSAM resource profiles, note that the resource profiles do not contain bookmarks. To access the applications and servers that WSAM intermediates, users must first launch WSAM and then launch the specified application or server using standard methods (such as the Windows Start menu or a desktop icon). For information about automatically launching WSAM when the user signs into the IVE, see “Specifying role-level WSAM options” on page 408. When you enable JSAM or WSAM through Web rewriting autopolicies in the Users > Resource Profiles > Web Applications/Pages page of the admin console, the IVE automatically creates JSAM or WSAM autopolicies for you. You can only view these SAM policies through the appropriate Web resource profile—not through the SAM resource profile pages of the admin console. For more information, see “Defining a rewriting autopolicy” on page 300. For tips on configuring PDA applications through WSAM, see “Enabling WSAM on PDAs” on page 851. Creating WSAM client application resource profiles When you create a WSAM application resource profile, the WSAM client intercepts requests from the specified client applications to servers in your internal network. To create a WSAM application resource profile: 1. Navigate to the Users > Resource Profiles > SAM > Client Applications page in the admin console. 2. Click New Profile. 3. From the Type list, choose WSAM. 4. From the Application list, select one of the following options: 402 Defining resource profiles: WSAM Custom—When you select this option, you must manually enter your custom application’s executable file name (such as telnet.exe). Additionally, you may specify this file’s path and MD5 hash of the executable file (although it is not required that you specify the exact path to the executable). If you enter an MD5 hash value, WSAM verifies that the checksum value of the executable matches this value. If the values do not match, WSAM notifies the user that the identity of the application could not be verified and does not forward connections from the application to the IVE. Chapter 16: Secure Application Manager Lotus Notes—When you select this option, WSAM intermediates traffic from the Lotus Notes fat client application. Microsoft Outlook—When you select this option, WSAM intermediates traffic from the Microsoft Outlook application. NetBIOS file browsing—When you select this option, WSAM intercepts NetBIOS name lookups in the TDI drivers on port 137. Citrix—When you select this option, WSAM intermediates traffic from Citrix applications. NOTE: You can only use WSAM to configure access to a standard application once per user role. For instance, you can enable one configuration of Microsoft Outlook and one configuration of Lotus Notes for the “Users” role. 5. Enter a unique name and optionally a description for the resource profile. The IVE displays this information in the Client Application Sessions section of the IVE end-user home page. 6. In the Autopolicy: SAM Access Control section, create a policy that allows or denies users access to the server that hosts the specified application: a. If it is not already enabled, select the Autopolicy: SAM Access Control checkbox. b. In the Resource field, specify the application server to which this policy applies. You can specify the server as a host name or an IP/netmask pair. You may also include a port. c. From the Action list, select Allow to enable access to the specified server or Deny to block access to the specified server. d. Click Add. 7. Click Save and Continue. 8. In the Roles tab, select the roles to which the resource profile applies and click Add. The selected roles inherit the autopolicy created by the resource profile. If it is not already enabled, the IVE also automatically enables the SAM option in the Users > User Roles > Select Role > General > Overview page of the admin console for all of the roles you select. 9. Click Save Changes. Creating WSAM destination network resource profiles When you create a WSAM destination network resource profile, the WSAM client intercepts requests from processes running on the client to internal hosts. Defining resource profiles: WSAM 403 Juniper Networks Secure Access Administration Guide To create a WSAM destination network resource profile: 1. Navigate to the Users > Resource Profiles > SAM > WSAM Destinations page in the admin console. 2. Click New Profile. 3. Enter a unique name and optionally a description for the resource profile. 4. In the WSAM Destinations section, specify which servers you want to secure using WSAM and click Add. You can specify the servers as host name or IP/netmask pairs. You may also include a port. For information about system variables and attributes you can use in this field, see “Using system variables in realms, roles, and resource policies” on page 869. 5. Select the Create an access control policy allowing SAM access to this server checkbox to enable access to the server specified in the previous step (enabled by default). 6. Click Save and Continue. 7. In the Roles tab, select the roles to which the resource profile applies and click Add. The selected roles inherit the autopolicy created by the resource profile. If it is not already enabled, the IVE also automatically enables the SAM option in the Users > User Roles > Select Role > General > Overview page of the admin console for all of the roles you select. 8. Click Save Changes. Defining role settings: WSAM This section contains the following information about configuring role-level settings for WSAM: 404 Defining role settings: WSAM “Specifying applications and servers for WSAM to secure” on page 405 “Specifying applications that need to bypass WSAM” on page 407 “Specifying role-level WSAM options” on page 408 “Downloading WSAM applications” on page 410 Chapter 16: Secure Application Manager Specifying applications and servers for WSAM to secure NOTE: Information in this section is provided for backwards compatibility. We recommend that you secure traffic using WSAM resource profiles instead, since they provide a simpler, more unified configuration method. For more information, see “Defining resource profiles: WSAM” on page 401. Use the Applications tab to specify applications and servers for which WSAM secures traffic. When WSAM downloads to a client PC, it contains the information you configure on the Applications tab for the role. After a user launches the Secure Application Manager, WSAM intercepts requests from client applications to servers in your internal network and requests from processes running on the client to internal hosts. You define these resources on the Applications tab by configuring two lists: WSAM supported applications list—This list contains applications for which you want WSAM to secure client/server traffic between the client and the IVE. WSAM allowed servers list—This list contains hosts for which you want WSAM to secure client/server traffic between the client and the IVE. Specifying applications for WSAM to secure To specify applications for which WSAM secures client/server traffic between the client and the IVE: 1. In the admin console, choose Users > User Roles > Select Role> SAM > Applications. 2. Click Add Application. 3. Enter the name of the application and, optionally, a description. This information displays in the Client Application Sessions section of the IVE enduser home page. 4. From the Type list, choose one of the following options: Standard—If you select this option, choose one the following applications from the Application Parameters section: Citrix—When you select this option, WSAM intermediates traffic from Citrix applications. Lotus Notes—When you select this option, WSAM intermediates traffic from the Lotus Notes fat client application. Microsoft Outlook/Exchange—When you select this option, WSAM intermediates traffic from the Microsoft Outlook application. Defining role settings: WSAM 405 Juniper Networks Secure Access Administration Guide NetBIOS file browsing—When you select this option, WSAM intercepts NetBIOS name lookups in the TDI drivers on port 137. NOTE: Note that in order to access a share using WSAM with NetBIOS, you need to explicitly specify the server’s NetBIOS name (alphanumeric string up to 15 characters) in two places: on the Add Server page and in a SAM resource policy. (Wildcards are currently not supported.) Alternatively, you can enable the Autoallow application servers option on the SAM > Options tab, and then the IVE automatically creates a SAM resource policy that allows access to this server. Custom—Select this option to specify a custom client/server application. Then: i. In the Filename field, specify the name of the file’s executable file. ii. Optionally specify the file’s path and MD5 hash of the executable file. If you enter an MD5 hash value, WSAM verifies that the checksum value of the executable matches this value. If the values do not match, WSAM notifies the user that the identity of the application could not be verified and does not forward connections from the application to the IVE. 5. Click Save Changes or Save + New. 6. Configure a WSAM resource policy to specify to which enterprise resources (based on IP address/port combination) the IVE may send the application. Specifying servers for WSAM to secure To specify servers for which WSAM secures client/server traffic between the client and the IVE: 1. In the admin console, choose Users > User Roles > Select Role > SAM > Applications. 2. Click Add Server. 3. Enter the name of the server and, optionally, a description. 4. Specify the server’s host name (the wild cards '*' or '?' are accepted) or an IP/netmask pair. Specify multiple ports for a host as separate entries. For information about system variables and attributes you can use in this field, see “Using system variables in realms, roles, and resource policies” on page 869. 5. Click Save Changes or Save + New. 6. Configure a WSAM resource policy to specify to which enterprise resources (based on IP address/port combination) the IVE may send a server request. Alternatively, you can enable the Auto-allow application servers option on the SAM > Options tab, and then the IVE automatically creates a SAM resource policy that allows access to the specified server. Note that you need to enable this option before specifying the application or server; otherwise, you need to create a SAM resource policy. 406 Defining role settings: WSAM Chapter 16: Secure Application Manager Specifying applications that need to bypass WSAM The WSAM client comes pre-configured with a list of “passthrough” applications bypass WSAM. The WSAM client does not secure traffic for these applications. In addition to bypassing these pre-defined applications, you may also specify additional applications on the IVE server that should bypass WSAM. NOTE: WSAM does not bypass applications on Pocket PCs and other handheld devices. This section includes the following information about WSAM bypass applications: “Specifying bypass applications” on page 407 “Default bypass applications” on page 407 Specifying bypass applications Use the Applications tab to specify applications on the IVE server for which WSAM does not secure traffic. These “passthrough” applications bypass WSAM. To specify applications for WSAM to secure: 1. In the admin console, choose Users > User Roles > Select Role > SAM > Applications. 2. Select the Add Bypass Application button. The New Bypass Application page displays. 3. Name the application and provide a description (optional). 4. Provide the file name (required). 5. Enter the absolute path to the application (optional). 6. Select Save Changes to add the bypass application to the list or Save + New to save the bypass application and create another bypass application. Default bypass applications The WSAM client is pre-configured to bypass WSAM processing for the following applications: apache.exe apache* licadmin.exe vni.exe lmgrd.exe TNSLSNR.EXE ORACLE.EXE Defining role settings: WSAM 407 Juniper Networks Secure Access Administration Guide Agntsrvc.exe ONRSD.EXE Pagntsrv.exe ENCSVC.EXE Agntsvc.exe sqlplus.exe sqlplusw.exe EiSQLW.exe Sqlservr.exe Sqlmangr.exe inetinfo.EXE svchost.exe LSASS.EXE CSRSS.EXE WINLOGON.EXE SERVICES.EXE spoolsv.exe hostex32.exe xstart.exe idsd.exe dsTermServ.exe dsCitrixProxy.exe dsNcService.exe dsNetworkConnect.exe Specifying role-level WSAM options To specify WSAM options at the role level: 1. In the admin console, choose Users > User Roles > Select Role > SAM > Options. 2. If it is not already enabled, select the Windows SAM option at the top of the page. 408 Defining role settings: WSAM Chapter 16: Secure Application Manager 3. Under Secure Application Manager options, configure the following options: Auto-launch Secure Application Manager—If you enable this option, the IVE automatically launches the Secure Application Manager when a user signs in. If you do not select this option, users must manually start the Secure Application Manager from the Client Applications Sessions section of the IVE end-user home page. NOTE: Although you configure the Secure Application Manager to automatically launch when users sign into the IVE, users can override this setting through the Preferences > Applications page of the IVE end-user console. If you or the enduser disables WSAM from automatically launching, users need to manually start the Secure Application Manager by clicking its link on the IVE home page. Auto-allow application servers—If you enable this option, the IVE automatically creates a SAM resource policy that allows access to the server specified in the WSAM application and server lists. 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 575. 4. Under Windows SAM Options, configure the following options: Auto-uninstall Secure Application Manager—If you enable this option, the IVE automatically un-installs the Secure Application Manager after users sign off. Prompt for username and password for intranet sites—If you enable this option, the IVE requires users to enter their sign-in credentials before connecting to sites on your internal network. This option changes Internet Explorer’s intranet zone setting so that Internet Explorer prompts the user for network sign-in credentials whenever the user wants to access an intranet site. Auto-upgrade Secure Application Manager—If you enable this option, the IVE automatically downloads the Secure Application Manager to a client machine when the version of Secure Application Manager on the IVE is newer than the version installed on the client. If you select this option, note the following: The user must have Administrator privileges in order for the IVE to automatically install Secure Application Manager on the client. If a user un-installs Secure Application Manager and then signs in to an IVE for which the Auto-upgrade Secure Application Manager option is not enabled, the user no longer has access to Secure Application Manager. Defining role settings: WSAM 409 Juniper Networks Secure Access Administration Guide Session start script and Session end script—If you want to run a batch, application, or Win32 service file when the WSAM session starts or ends, enter the name and path for the file. For example, if you want to terminate an application and then restart it, you may use PSKILL.exe (an third-party utility that terminates processes on local or remote systems). NOTE: If you enable the Session start script option or Session end script option, note the following: You must either install the specified file on your end-user’s computers or specify a path on an accessible network directory. To ensure that the IVE can locate a file on different platforms, you can use Windows variables, such as in a path such as %WINDIR%\system32\log. The file must invoke the WSAM launcher using the appropriate command-line options, as described in “Using the W-SAM launcher” on page 413. 5. Click Save Changes. Downloading WSAM applications To download Windows Secure Application Manager applications, go to the Maintenance > System > Installers tab. For more information about downloading WSAM applications, see “Downloading application installers” on page 577. Defining resource policies: WSAM This section contains the following instructions for configuring WSAM resource policies: “Specifying application servers that users can access” on page 410 “Specifying resource level WSAM options” on page 412 Specifying application servers that users can access NOTE: Information in this section is provided for backwards compatibility. We recommend that you secure traffic using WSAM resource profiles instead, since they provide a simpler, more unified configuration method. For more information, see “Defining resource policies: WSAM” on page 410. When you enable the Secure Application Manager access feature for a role, you need to create resource policies that specify which application servers a user may access. These policies apply to both the Java version and Windows version of the Secure Application Manager (J-SAM and W-SAM, respectively). When a user makes a request to an application server, the IVE evaluates the SAM resource policies. If the IVE matches a user’s request to a resource listed in a SAM policy, the IVE performs the action specified for the resource. 410 Defining resource policies: WSAM Chapter 16: Secure Application Manager When writing a SAM 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 SAM policy, you need to specify application servers to which a user may connect. 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. SAM resource policies apply to users requests made through either version, J-SAM or W-SAM. Actions—A Secure Application Manager resource policy either allows or denies access to an application server. You can create resource policies through the standard interface (as described in this section) or through resource profiles (recommended method). 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 83. To write a Secure Application Manager resource policy: 1. In the admin console, choose Users > Resource Policies > SAM > Access. 2. On the Secure Application Manager 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 application servers to which this policy applies. 5. In the Roles section, specify: Policy applies to ALL roles—Choose this option to apply this policy to all users. Policy applies to SELECTED roles—Choose this option 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—Choose this option 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. 6. In the Action section, specify: Allow socket access—Choose this option to grant access to the application servers specified in the Resources list. Defining resource policies: WSAM 411 Juniper Networks Secure Access Administration Guide Deny socket access—Choose this option to deny access to the application servers specified in the Resources list. Use Detailed Rules—Choose this option to specify one or more detailed rules for this policy. See “Writing a detailed rule” on page 88 for more information. 7. Click Save Changes. 8. On the Secure Application Manager 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. Specifying resource level WSAM options Use the Options tab to specify the SAM resource option to match IP addresses to host names specified as resources in your SAM resource policies. When you enable this option, the IVE looks up IP addresses corresponding to each host name specified in a SAM resource policy. When a user tries to access a server by specifying an IP address rather than the host name, the IVE compares the IP to its cached list of IP addresses to determine if a host name matches an IP. If there is a match, then the IVE accepts the match as a policy match and applies the action specified for the resource policy. When you enable this option, the IVE compiles a list of host names specified in the Resources field of each SAM resource policy. The IVE then applies the option to this comprehensive list of host names. NOTE: This option does not apply to host names that include wildcards and parameters. To specify the SAM resource option: 1. In the admin console, choose Users > Resource Policies > SAM > Options. 2. Select IP based matching for Hostname based policy resources. When you select this option, the IVE looks up the IP address corresponding to each host name specified in a Secure Application Manager resource policy. When a user tries to access a server by specifying an IP address rather than the host name, the IVE compares the IP to its cached list of IP addresses to determine if a host name matches an IP. If there is a match, then the IVE accepts the match as a policy match and applies the action specified for the resource policy. 3. Click Save Changes. 412 Defining resource policies: WSAM Chapter 16: Secure Application Manager Using the W-SAM launcher The W-SAM launcher is a tool that signs a user into the IVE and then downloads and launches W-SAM. The launcher provides a command-line interface that a script or application can call. For example, you can write an application that calls the W-SAM executable when needed. To use the W-SAM launcher, you need to: 1. Write a script, batch file, service, or application that calls the W-SAM launcher using command line arguments. You need to distribute this file to each client PC that requires it. For more information, see “Running scripts manually” on page 414 and “Running scripts automatically” on page 415. 2. Download the W-SAM launcher from Maintenance > System > Installers page of the admin console and then distribute it to your users. Use the command-line arguments in Table 33 to invoke the W-SAM launcher. Table 33: W-SAM Command Line Arguments Argument Action -start Initiates the W-SAM connection. -stop Terminates the W-SAM connection. -signout Terminates the WSAM connection and IVE user session. -version Displays W-SAM version information and then exits. -help Displays available arguments. -noupgrade Cancels automatic upgrade of W-SAM software. -reboot Automatically reboots if prompted by an upgrade. If reboot flag is not set, W-SAM exits and does not reboot during an upgrade. Be sure to set the reboot flag if W-SAM is operating automatically on a remote PC. -u Specifies the user name. -p Specifies the password for authentication. -loginscript file Specifies the location and name of the script file to run when W-SAM launches. This command takes precedence over a script file specified on the Users > User Roles > Select Role > SAM > Options page. -postscript file Specifies the location and name of the script file to run when W-SAM exits. This command takes precedence over a script file specified on the Users > User Roles > Select Role > SAM > Options page. -u Specifies the sign-in URL for the IVE. -r Specifies the realm to which the IVE submits the user’s credentials. -verbose Prompts users for input through dialog boxes. Table 34 lists the possible codes the W-SAM launcher returns when it exits. Using the W-SAM launcher 413 Juniper Networks Secure Access Administration Guide Table 34: Application Return Codes Code Description 0 Success 1 Invalid Arguments 2 Could Not Connect. 3 Invalid Credentials 4 Role Not Specified (credentials map to multiple roles) 5 Pre-authentication Error (Host Checker or Cache Cleaner did not load) 6 Installation Failed 7 Reboot Required (if ‘-reboot’ not specified) 8 Unable to perform a required software upgrade 10 The IVE does not support this feature 12 Failed to authenticate the client certificate 100 Unable to stop the Secure Application Manager 101 Unable to start the Secure Application Manager due to a software conflict caused by another Layered Service Provider Running scripts manually Users may manually specify scripts to run when a W-SAM session begins or ends using the following command-line arguments. NOTE: If you specify scripts to run through the Users > User Roles > Select Role > SAM > Options page of the admin console, the configured script does not run if a user manually invokes W-SAM using the launcher and specifies a different script. To manually launch a script after a W-SAM session begins: At a command prompt, enter -loginscript file followed by a system variable or script file name and location. To manually launch a script after a W-SAM session ends: At a command prompt, enter -postscript file followed by a system variable and the script file name and location. NOTE: Place system variables, file paths, and file names in quotes Precede and append system variables with a percent sign (%) For example: -loginscript file “%program files:%\Internet Explorer\IEXPLORER.EXE” 414 Using the W-SAM launcher Chapter 16: Secure Application Manager Running scripts automatically You may automatically run a script when WSAM starts or stops by entering the script path and name in the Session start script field or Session end script field on the Users > User Roles > Select Role > SAM > Options page of the admin console, as described in “Specifying role-level WSAM options” on page 408. This section includes an example batch file that you can automatically launch. Batch file example The following example demonstrates how to use the W-SAM launcher to invoke W-SAM. This sample batch file generates error messages when W-SAM launches: SamLauncher –start –url %1 –user %2 –password %3 –realm %4 if errorlevel 1 goto error_invalid_args if errorlevel 2 goto error_connect if errorlevel 3 goto error_credentials if errorlevel 4 goto error_role if errorlevel 5 goto error_preauth if errorlevel 6 goto error_install if errorlevel 7 goto error_reboot :error_invalid_args @echo invalid arguments goto done :error_connect @echo could not connect goto done :error_credentials @echo invalid credentials goto done :error_role @echo invalid role goto done :error_preauth @echo pre auth version checking goto done :error_install @echo install failed goto done :error_reboot @echo reboot required goto done :error_success Using the W-SAM launcher 415 Juniper Networks Secure Access Administration Guide @echo Secure Application Manager has started goto done :done Win32 API example CHAR szCmd = “SamLauncher.exe –stop”; DWORD dwExitCode = 0; STARTUPINFO si; PROCESS_INFORMATION pi; ZeroMemory(&si, sizeof(si)); si.cb = sizeof(si); ZeroMemory(&pi, sizeof(pi)); if (!CreateProcess(NULL, szCmd, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi)) { printf( "CreateProcess(%s) failed %d", szCmd, GetLastError()); return -1; } WaitForSingleObject(pi.hProcess, 20000); GetExitCodeProcess(&pi.hProcess, &dwExitCode); CloseHandle(pi.hProcess); CloseHandle(pi.hThread); printf(“SamLauncher return %d\n”, dwExitCode); return 0; NOTE: If you are using Windows Vista, open the command window as an administrator user. Standard output from the SamLauncher.exe does not display if the command window is opened by a user without administrator privileges. Task Summary: Configuring JSAM This section provides high-level JSAM configuration steps. These steps do not account for preliminary IVE configuration steps such as specifying the IVE’s network identity or adding user IDs to the IVE. To configure JSAM: 1. Create resource profiles that enable access to client/server applications, create supporting autopolicies as necessary, and assign the policies to user roles using settings in the Users > Resource Profiles> SAM pages of the admin console. For instructions, see “Defining resource profiles: JSAM” on page 435. We recommend that you use resource profiles to configure JSAM (as described above). However, if you do not want to use resource profiles, you can configure JSAM using role and resource policy settings in the following pages of the admin console instead: a. 416 Task Summary: Configuring JSAM Enable access to JSAM at the role-level using settings in the Users > User Roles > Select Role > General > Overview page of the admin console. For instructions, see “Configuring user roles” on page 54. Chapter 16: Secure Application Manager b. Specify which client/server applications JSAM should intermediate using settings in the Users > User Roles > SAM > Applications page of the admin console. For instructions, see “Specifying applications for JSAM to secure” on page 439. c. Specify which application servers users can access through JSAM using settings in the Users > Resource Policies > SAM > Access page of the admin console. For instructions, see “Specifying application servers that users can access” on page 445. 2. After enabling access to client/server applications using JSAM 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) Configure role-level options such as whether the IVE should automatically launch JSAM using settings in the Users > User Roles > SAM > Options page of the admin console. For instructions, see “Specifying role level JSAM options” on page 442. b. (Optional) Control IP based hostname matching at the resource level using settings in the Users > Resource Policies > SAM > Access page of the admin console. For instructions, see “Specifying application servers that users can access” on page 445. 3. If you want to enable or disable client-side logging for JSAM, configure the appropriate options through the System > Configuration > Security > Client-side Logs tab of the admin console. For instructions, see “Enabling client-side logs” on page 679. 4. If you have multiple internal domains, such as company-a.com and companyb.com, add DNS domains to the IVE using settings in the System > Network > Overview page of the admin console so that names such as app1.companya.com and app2.company-b.com resolve correctly. 5. If a remote user’s PC is set up to use a Web proxy in Internet Explorer, configure the client machine to bypass the proxy server when the user launches applications that need to connect to the Secure Application Manager. For instructions, see “Configuring a PC that connects to the IVE through a proxy Web server” on page 420. 6. Enable JSAM to associate IP loopback addresses with application servers on specific ports either by enabling JSAM to edit the hosts file on your users’ systems (as explained in “Resolving host names to localhost” on page 424) or by creating an external DNS to route client application traffic to the J-SAM applet (as explained in “Configuring external DNS servers and user machines” on page 425). J-SAM overview The Java version of the Secure Application Manager provides support for static TCP port client/server applications, including enhanced support for Microsoft MAPI, Lotus Notes, and Citrix NFuse. J-SAM also provides NetBIOS support, which enables users to map drives to specified protected resources. J-SAM overview 417 Juniper Networks Secure Access Administration Guide J-SAM works well in many network configurations but does not support dynamic port TCP-based client/server applications, server-initiated connections, or UDP traffic. For information about the operating systems, Web browsers, and JVMs on which Juniper Networks supports JSAM, see the Supported Platforms Document on the Juniper Networks Customer Support Center. This section contains the following information about JSAM: “Using JSAM for client/server communications” on page 418 “Linux and Macintosh support” on page 426 “Standard application support: MS Outlook” on page 427 “Standard application support: Lotus Notes” on page 428 “Standard application support: Citrix Web Interface for MetaFrame (NFuse Classic)” on page 430 “Custom application support: Citrix published applications configured from the native client” on page 431 “Custom application support: Citrix secure gateways” on page 434 Using JSAM for client/server communications J-SAM provides secure port forwarding by directing client application traffic to the J-SAM applet running on a client machine. To the client application running on the local machine, J-SAM appears as the application server. To the application server in your network, the IVE appears as the client application. The following diagram illustrates the interaction between a client application and its server via the IVE. (This figure assumes that the user specified a localhost IP address as the server in the client application.) Figure 36: Java Secure Application Manager 418 J-SAM overview Chapter 16: Secure Application Manager 1. The user starts a client application listed in the Client Application Sessions section of the IVE end-user home page. 1 The application resolves the remote server to localhost. 2. The client application connects to J-SAM running on the user's machine and starts sending requests. 3. J-SAM encapsulates and forwards all client requests to the IVE over SSL. 4. The IVE un-encapsulates the client data and forwards it to the specified application server. 5. The application server responds with data to the IVE server. 6. The IVE encapsulates and forwards the response from the application server to J-SAM over SSL. 7. J-SAM un-encapsulates the application server data and forwards it to the client application. For more information about how JSAM executes, see “Assigning IP loopback addresses to servers” on page 421. 1. Windows 98 operating system only—If the “Close on Exit” property is disabled in the DOS box that opens during the JSAM boot process (for executing the “restore.bat” process), the DOS box does not close after the batch file has completed execution. The user must manually close the DOS box before the JSAM boot process can complete. J-SAM overview 419 Juniper Networks Secure Access Administration Guide For more information about how JSAM executes, see “Assigning IP loopback addresses to servers” on page 421. NOTE: If a remote user’s PC is set up to use a Web proxy in Internet Explorer, you must configure the client machine to bypass the proxy server when the user launches applications that need to connect to the Secure Application Manager. See “Configuring a PC that connects to the IVE through a proxy Web server” on page 420. J-SAM allocates 20-30 MB of RAM when running (the exact amount of memory depends on the Java Virtual Machine (JVM) used) and, if caching is enabled, may leave a .jar file on the client machine. For more information about files left by JSAM on client machines, see the Client-side Changes Guide on the Juniper Networks Customer Support Center. Users may experience problems waiting for the Secure Application Manager to fully load if they enable pop-up blockers through their Web browsers. This problem occurs because a pop-up window alerting users to accept the Secure Application Manager plug-in may appear in the background (behind the Web browser window) where users cannot see it. When launching applications through JSAM, Juniper Networks supports configuration of 1200 unique IP/port combinations on Windows and Mac and 800 unique IP/port combinations on Linux. Note that this limit is based on IP/port combinations, not applications (which may listen on more than one IP address and port). Juniper Networks determined these numbers by testing on Windows XP and Windows 2000 machines using default JRE memory settings. Configuring a PC that connects to the IVE through a proxy Web server If a remote user’s PC is set up to use a Web proxy in Internet Explorer, you must configure the client machine to bypass the proxy server and contact the Secure Application Manager instead. To configure a PC that connects to the IVE through a Web proxy in Internet Explorer: 1. From the Internet Explorer Tools menu, choose Internet Options. 2. On the Connections tab, click the LAN Settings button. 3. Under Proxy server, click the Advanced button. 4. Under Exceptions, enter the addresses for which you do not want to use a proxy server. Enter all addresses (host names and localhost) that the client application uses when connecting through the Secure Application Manager. For example: If your application server is app1.company.com, enter the following exceptions: app1;app1.company.com;127.0.0.1 420 J-SAM overview Chapter 16: Secure Application Manager If your Exchange Server is exchange.company.com, enter the following exceptions: exchange;exchange.company.com;127.0.0.1 Assigning IP loopback addresses to servers For JSAM to function, it must listen on loopback addresses for client requests to network application servers. The IVE assigns these unique IP loopback address to each application server that you specify for a given port. For example, if you specify: app1.mycompany.com, app2.mycompany.com. app3.mycompany.com,... for a single port, the IVE assigns a unique IP loopback address to each application: 127.0.1.10, 127.0.1.11, 127.0.1.12,... When the IVE installs J-SAM on a user’s machine, J-SAM listens on the loopback addresses (on the corresponding client port specified for the application server) for client requests to network application servers. You can configure the IVE to dynamically assign these loopback addresses, or you can configure static loopback addresses yourself through the admin console (as explained in “Using static loopback addresses” on page 422). You must enable these associations between IP loopback addresses and applications servers on a specific port in one of two ways: Allow the IVE to edit the hosts file on the client system with IP loopback assignments. The IVE makes a copy of the current hosts file and then creates a new hosts file with the IP loopback assignments. When the user ends the session, the IVE deletes the new hosts file and restores the original hosts file. If the client system shuts down unexpectedly, the hosts file still points the client to loopback addresses for outside connections. Settings in the hosts file are returned to their original state when the client system reboots. Users must have the proper privileges on their machines in order for the IVE to edit the hosts file. For more information, see “Resolving host names to localhost” on page 424. Create an external DNS to route client application traffic to the J-SAM applet. For more information, see“Configuring external DNS servers and user machines” on page 425. For more information about loopback addresses, see: “Using static loopback addresses” on page 422 “Determining the IVE-assigned loopback address” on page 422 J-SAM overview 421 Juniper Networks Secure Access Administration Guide “IP loopback address considerations when merging roles” on page 424 Using static loopback addresses Using an external DNS server with dynamic loopback addresses requires an administrator to update the DNS settings each time the J-SAM application configuration changes. On the other hand, configuring an external DNS server using static loopback addresses provides administrators with the highest degree of configuration control. For example, consider the following IP loopback assignments: app1.mycompany.com - 127.0.1.10 app2.mycompany.com - 127.0.1.11 app3.mycompany.com - 127.0.1.12 If you configure an external DNS server using dynamic loopback address assignments and you delete the first application server, the address assignments change: app2.mycompany.com - 127.0.1.10 app3.mycompany.com - 127.0.1.11 With static IP loopback addresses in an external DNS, deleting the first application server does not affect the IP loopback assignments for the remaining application servers: app2.mycompany.com - 127.0.1.11 app3.mycompany.com - 127.0.1.12 You can assign static IP loopback addresses when creating a JSAM custom resource profile through the Users > Resource Profiles > SAM > Client Applications page of the admin console or when enabling JSAM applications through the Users > User Roles > Select Role > SAM > Applications page of the admin console. If you assign a static IP loopback address while creating a new application, the IVE checks the address for conflicts against other configured applications in the same role. If another application uses the same address, the IVE displays an error message prompting you to enter a different IP address. NOTE: Static IP loopback addresses apply only to application servers configured by an administrator. The IVE assigns dynamic IP loopback addresses for user-defined application servers. If the administrator does not assign an IP loopback address to an application server, the IVE assigns a dynamic address. Determining the IVE-assigned loopback address Users cannot modify the corporate DNS server for applications they add for port forwarding. If you allow users to specify applications for J-SAM to proxy, users need to configure a client application to use the localhost address assigned by the IVE where they typically enter the server host name. 422 J-SAM overview Chapter 16: Secure Application Manager The Details pane of the J-SAM browser window displays the loopback IP address assigned by the IVE along with the port specified by the user. To determine what IP address the IVE assigns to an application specified through the Client Applications IVE page, a user must restart the Secure Application Manager after adding the application. The loopback address assigned to the application appears on the Details pane of the Secure Application Manager browser window, as shown in Figure 37. Figure 37: Details pane of the Java Secure Application Manager (J-SAM) In the client application, the user needs to enter the IVE-assigned loopback address as the application server. For example, if a user wants to access a telnet server behind your corporate firewall, the user needs to follow these steps: 1. In the Client Application Sessions section of the IVE end-user home page, click the Item Properties icon, then click Add Application 2. On the Add Application page, specify: The server’s fully qualified domain name or IP address in the Remote Server field, such as terminalserver.juniper.com. The port on which J-SAM should listen for client traffic to the server in the Client Port field, such as 3389. The port on which the remote server should listen for traffic from the client application (J-SAM) in the Server Port field, such as 3389. 3. Click Add to save the information. 4. Close the Secure Application Manager browser window. 5. In the Client Application Sessions section of the IVE end-user home page, click Start to restart the Secure Application Manager. 6. In the Secure Application Manager browser window, click Details. 7. On the Details tab, look at which loopback address the IVE assigned to the remote server, such as 127.0.1.18. J-SAM overview 423 Juniper Networks Secure Access Administration Guide 8. In the client application, such as Remote Desktop Connection, specify the loopback address in the configuration field for the server. This field appears in different places for different applications. Users may enter this information through a setup wizard or other configuration dialog. IP loopback address considerations when merging roles If you plan to merge two or more roles, you may encounter IP loopback address conflicts. Keep the following points in mind when merging roles: If two or more roles map to the same application and each mapping contains a different static IP loopback address, all of the static IP loopback addresses remain unchanged. If two or more roles map to the same application and only one role uses a static IP loopback address, J-SAM uses only the static IP loopback address and binds to only one statically defined socket on the client. If two or more roles map to the same application using dynamic IP loopback addresses, only one dynamic IP loopback address is used. The application listener binds to only one dynamically assigned socket on the client. If you use the same host name in multiple roles, either use the same static IP loopback address, or dynamic addresses for all the applications. If you use different host names associated with the same loopback address and port combination, JSAM cannot distinguish between the two different hosts at the back-end and, hence, cannot accurately direct IP traffic bound for those hosts. Resolving host names to localhost For JSAM to successfully intermediate traffic, a client application on the user’s machine needs to resolve the application server to the client localhost. This process enables J-SAM to capture and securely port forward the data intended for the application server via the IVE. J-SAM can perform automatic host-mapping, in which it edits the client’s hosts file, to map application servers to localhost. (You can enable automatic host-mapping through the Users > User Roles > Select Role > SAM > Options page of the admin console.) In order for J-SAM to edit a user’s hosts file, the user must have the appropriate authority on the client machine: 424 J-SAM overview Windows users using the FAT file system may belong to any user group. For Exchange MAPI support, however, users must have at least Power User privileges on their machines. Windows users using the NTFS file system must have Administrator privileges on their machines. Linux (RedHat) users must launch the browser that will launch J-SAM as root. Macintosh users must supply the Administrator password when prompted by J-SAM. Chapter 16: Secure Application Manager If users do not have the appropriate privileges on their machines, J-SAM cannot automatically edit the hosts file, preventing host name resolution to localhost. Alternatives for users who do not have the appropriate privileges are: You configure your external DNS server to resolve application servers to localhost. If you configure your external DNS server to use a localhost address instead of the application server host name, remote users need to configure the order in which their machine searches DNS servers to start with the corporate DNS. For more information, see “Configuring external DNS servers and user machines” on page 425. You relax the permissions on the etc directory and the etc\hosts file to enable J-SAM to make the necessary modifications. Users configure a client application to use the localhost address assigned by the IVE where they typically specify the application server host name in the client application. See “Determining the IVE-assigned loopback address” on page 422 for more information. Configuring external DNS servers and user machines Client applications must resolve server host names to JSAM, which proxies data between a client and a server. On Windows PCs, server host names are stored in the hosts file. To intercept data using JSAM, the server names in the hosts file need to resolve to the local machine (localhost) so that the IVE can intermediate the traffic. The recommended process for mapping application servers to a user’s local PC is to enable the automatic host-mapping option, which enables the IVE to automatically modify the PC hosts file to point application servers to the localhost for secure port forwarding. For the IVE to perform automatic host-mapping, however, PC users must have the proper privileges on their machines (as explained in “Resolving host names to localhost” on page 424). If your PC users do not have these privileges, you must ensure that your internal application server names resolve externally to a PC’s localhost by adding entries to your external Internet-facing DNS server such as: 127.0.0.1 app1.company-a.com 127.0.0.1 app2.company-b.com 127.0.0.1 exchange1.company-a.com 127.0.0.1 exchange1.company-b.com If the client application uses an unqualified name for the application server, users need to specify DNS suffixes so that the PC can attach the suffix and contact your external DNS server for name resolution. For example, an MS Outlook client typically has an unqualified name for an MS Exchange server. In order for the qualified name to resolve to 127.0.0.1, users need to specify the appropriate DNS suffixes on their PCs. Adding domain names does not affect other operations on the PC, including use of the client application from within the enterprise. To configure a user PC with DNS suffixes (Windows 2000): 1. From the Windows Start menu, choose Settings > Network and Dial-up Connections > Local Area Connection and then choose Properties. J-SAM overview 425 Juniper Networks Secure Access Administration Guide 2. Select Internet Protocol (TCP/IP) and then click Properties. 3. Click Advanced and then click the DNS tab. 4. Click Append these DNS suffixes and then click Add. 5. Add your enterprise’s internal domains as additional DNS suffixes. For information about configuring your external DNS server using static loopback addresses, see “Using static loopback addresses” on page 422. Linux and Macintosh support Linux users do not have access to ports below 1024 unless they are signed into their machines as root. Macintosh users do not have access to ports below 1024 unless they supply the Administrator password when prompted by J-SAM. To support applications that run on privileged ports (ports below 1024), such as a telnet application: Users may launch the browser that will launch J-SAM as root. You or the user may specify a client port number equal to or greater than port 1024 when enabling client applications. For example, if you specify 2041 for the client port and 23 for the server port for a telnet application, the command to run the application is: telnet loopbackIP 2041 where loopbackIP is the loopback IP address assigned to the application server by the IVE. J-SAM listens on port 2041 for traffic from the telnet application and forwards it to the IVE. The IVE then forwards the traffic to port 23 on the destination server. For information about determining the IVE-assigned loopback address, see “Determining the IVE-assigned loopback address” on page 422. NOTE: Due to the design of the Sun JVM code, Macintosh users cannot relaunch JSAM within the same Safari user session. In order to re-launch JSAM, the user must exit Safari and then launch JSAM again. 426 J-SAM overview Chapter 16: Secure Application Manager Standard application support: MS Outlook Remote users can use the Microsoft Outlook client on their PCs to access email, their calendars, and other Outlook features through the IVE. Versions of MS Outlook currently supported are MS Outlook 2000 and MS Outlook 2002. This ability does not require changes to the Outlook client and does not require a network layer connection, such as VPN. NOTE: Refer to the Supported Platforms Document on the Juniper Networks Customer Support Center for details on operating system support and dependencies. See the Client-side Changes Guide for details about registry changes made by JSAM. Also, note that the IVE does not support Outlook through SVW, since Outlook applications require HKLM registry key changes. For more information, see “Enabling the Secure Virtual Workspace” on page 244. In order for this feature to work for remote users, the network settings of the user's PC must resolve the name of the Exchange Servers embedded in the Outlook client to the local PC (127.0.0.1, the default localhost IP address). We recommend that you configure the IVE to automatically resolve Exchange server host names to the localhost by temporarily updating the hosts file on a client computer through the automatic host-mapping option. Client/server communication using J-SAM The following diagram describes the interactions between the Outlook client and an Exchange Server via the IVE. This figure assumes that the IVE is configured to perform automatic host-mapping. Figure 38: Java Secure Application Manager and Enhanced MS Exchange Support Figure 38 shows the IVE configured to use automatic host-mapping for the MS Outlook client. 1. The user starts the MS Outlook client. Outlook tries to contact the Exchange Server exchange1.yourcompany.com. The IVE resolves the Exchange Server host name to 127.0.0.1 (localhost) through temporary changes to the hosts file. J-SAM overview 427 Juniper Networks Secure Access Administration Guide 2. Outlook connects to the Secure Application Manager running on the user's PC and then starts sending requests for email. 3. The Secure Application Manager encapsulates and forwards all the requests from the Outlook client to the IVE over SSL. 4. IVE un-encapsulates the client data and looks in the MAPI request to find the target Exchange Server. The request is then forwarded to the target server. 5. Each request in the MAPI protocol encodes the target server for the request. When MAPI requests arrive from the Secure Application Manager, the IVE server looks in each of them and dispatches them to the appropriate target server. This process works transparently even if there are multiple Exchange Servers. 6. The Exchange Server responds to the IVE with email data. 7. The IVE encapsulates and forwards the response from the Exchange Server to the Secure Application Manager over SSL. 8. The Secure Application Manager un-encapsulates the information sent from the IVE and forwards the normal MAPI response from the Exchange Server to the Outlook client. Standard application support: Lotus Notes Remote users can use the Lotus Notes client on their PCs to access email, their calendars, and other features through the IVE. This ability does not require a network layer connection, such as a VPN. NOTE: See the Supported Platforms Document on the Juniper Networks Customer Support Center for details on operating system support and dependencies. Client/server communication using J-SAM In order for this feature to work for remote users, they need to configure the Lotus Notes client to use “localhost” as their location setting (that is, their Home Location, Remote Location, or Travel Location setting). The Secure Application Manager then picks up connections requested by the Lotus Notes client. The following diagram describes the interactions between the Lotus Notes client and a Lotus Notes Server via the IVE. 428 J-SAM overview Chapter 16: Secure Application Manager Figure 39: Java Secure Application Manager and Enhanced Lotus Notes Support Figure 39 shows the Lotus Notes client location value to be configured to the localhost. 1. The user starts the Lotus Notes client with the location setting. The client uses the HTTP Tunnel proxy setting for its location setting. Note that you must set the HTTP Tunnel proxy setting to use localhost (or 127.0.0.1) as the proxy address and 1352 as the proxy port. 2. The Lotus Notes client connects to the Secure Application Manager and starts sending requests for email. 3. The Secure Application Manager encapsulates and forwards requests from the Lotus Notes client to IVE over SSL. 4. The IVE un-encapsulates the client data and looks in the Lotus Notes request to find the target Lotus Notes Server. The request is then forwarded to the target server. Each request in the Lotus Notes protocol encodes the target server for the request. When Lotus Notes requests arrive from the application proxy, the IVE server obtains the target server information from the requests and dispatches the requests to the appropriate target server. Thus, this feature works transparently even if there are multiple Lotus Notes Servers accessed by a single user. Note that you must create JSAM ACLs on the IVE that enable access to these target servers. 5. The Lotus Notes Server responds with email data to the IVE. 6. The IVE encapsulates and forwards the response from the Lotus Notes Server to the Secure Application Manager over SSL. 7. The Secure Application Manager un-encapsulates the information sent from the IVE and forwards the normal response from the Lotus Notes Server to the Lotus Notes client. J-SAM overview 429 Juniper Networks Secure Access Administration Guide Configuring the Lotus Notes client Before a remote user can connect from Lotus Notes to a Lotus Notes Server through the IVE, the user must edit the Lotus Notes client to set a Location document Proxy field to the PC’s localhost port. The Location document edited should be the one used for remote access, such as the Remote Location or Travel Location setting. Setting the Proxy field to the PC’s localhost port enables the IVE to connect to multiple Lotus Notes Servers, including those set up as pass-through servers. You should use the following configuration in these cases: JSAM is configured to use Lotus Notes as a standard application. The Lotus Notes client can connect to multiple Lotus Notes servers. To configure a Lotus Notes client for use with the IVE: 1. From the Lotus Notes client, choose File > Mobile > Locations. 2. Select the Location used for remote access and then click Edit Location. 3. In the Basics tab, click the Proxy icon. 4. In the Proxy Server Configuration box, enter the following in the HTTP Tunnel field: 127.0.0.1:1352 5. Click OK. Standard application support: Citrix Web Interface for MetaFrame (NFuse Classic) Remote users can use the Citrix Web Interface for MetaFrame server to access a variety of applications via the IVE. This process does not require any alterations to the user permissions on the client. 430 J-SAM overview Chapter 16: Secure Application Manager After a user browses to a Citrix Web Interface for MetaFrame server and selects an application, the server sends an ICA file to the client. When the IVE rewrites the ICA file, it replaces host names and IP addresses with pre-provisioned loopback IP addresses. The ICA client then sends application requests to one of the loopback IP addresses. The Secure Application Manager encapsulates the data and sends it to the IVE. The IVE un-encapsulates the data and sends it to the appropriate MetaFrame server using port 1494 or 2598 (depending on the client). NOTE: JSAM does not automatically launch when Embedded Applications are set to “Auto” in the Citrix Web Interface for MetaFrame console. In these cases, we recommend that you configure JSAM to automatically launch after the user signs into the IVE. Otherwise, end-users must manually launch JSAM before using Citrix Web Interface for MetaFrame. If a user attempts to use the server discovery feature and then attempts to use application discovery, the application discovery process fails. To resolve this particular situation, shut down and restart Citrix Program neighborhood. The IVE serves as an alternative to deploying the Citrix Secure Gateway (CSG). To use the applet-mode of the Java client, make sure to enable Java applet support on the Users > User Roles > Select Role > Web > Options page of the admin console. If you set the Network Protocol setting in the Citrix Program Neighborhood client to TCP/IP, the IVE does not support the application through JSAM since the TCP/IP setting produces UDP traffic. Custom application support: Citrix published applications configured from the native client When enabling Citrix published applications on the Citrix native client through the IVE, you must complete the steps outlined in the following sections. 1. “Specifying custom applications on JSAM to port forward” on page 432 2. “Configuring the Citrix Metaframe server for published applications” on page 433 J-SAM overview 431 Juniper Networks Secure Access Administration Guide 3. “Configuring the Citrix client for published applications” on page 433 NOTE: These instructions assume that you are not using the Citrix Web Interface for Citrix Presentation Server (formerly known as Nfuse server). For information about presentation servers, see “Standard application support: Citrix Web Interface for MetaFrame (NFuse Classic)” on page 430. These instructions do not cover how to configure the standard Citrix application option. (For standard Citrix application instructions, use settings in the Users > Resource Profiles > Web > Web Applications/Pages page of the admin console.) You can enable both the standard Citrix application and the custom Citrix application—these settings do not impact each other. Specifying custom applications on JSAM to port forward When configuring JSAM to work with published applications, you must open 2 ports—ports 80 and 1494. Each opened port creates a connection through JSAM to the Citrix Metaframe server. To specify published applications for JSAM to port forward: 1. Add a custom application through JSAM using the instructions in “Defining resource profiles: JSAM” on page 435. When adding the custom application, keep the following settings in mind: Server name—For published applications, you must enter the Metaframe server’s fully qualified DNS name, not its IP address. Server port—For published applications, enter 80 and 1494. (Create one entry for port 80 and another for port 1494.) If you have multiple Metaframe servers, you must configure all of them on the same ports. Client port—For published applications, enter 80 and 1494. (Create one entry for port 80 and another for port 1494.) 2. If you have multiple internal domains, such as company-a.com and companyb.com, add DNS domains to the IVE using settings in the System > Network > Overview page of the admin console so that names such as app1.companya.com and app2.company-b.com resolve correctly. 3. If a remote user’s PC is set up to use a Web proxy in Internet Explorer, configure the client machine to bypass the proxy server when the user launches applications that need to connect to the Secure Application Manager. For instructions, see “Configuring a PC that connects to the IVE through a proxy Web server” on page 420. 4. Enable JSAM to associate IP loopback addresses with application servers on specific ports either by enabling JSAM to edit the hosts file on your users’ systems (as explained in “Resolving host names to localhost” on page 424) or by creating an external DNS to route client application traffic to the J-SAM applet (as explained in “Configuring external DNS servers and user machines” on page 425). 432 J-SAM overview Chapter 16: Secure Application Manager Configuring the Citrix Metaframe server for published applications When enabling Citrix published applications through the IVE, you must enable the XML service DNS address resolution on the metaframe server. The following instructions describe how to do this on Metaframe XP To configure the Citrix metaframe server to work with the IVE: 1. Open the Citrix Management Console. 2. Right-click on the name of your server farm and click Properties. 3. Select the MetaFrame Settings tab. 4. Select the Enable XML Service DNS address resolution checkbox. 5. Click OK. Configuring the Citrix client for published applications When enabling Citrix published applications through the IVE, you must create an ICA connection on each Citrix client using the instructions that follow. To configure the Citrix client to work with the IVE: 1. Open the Citrix Program Neighborhood and choose the Add ICA Connection option. 2. In the Add New ICA Connection wizard, select the connection type that your computer uses to communicate. 3. In the next screen: a. Enter a description of the new ICA Connection. b. Select TCP/IP + HTTP as the network protocol. c. Select Published Application. d. Click Server Location, and then: i. Deselect the Use Default checkbox. ii. Click Add in the Locate Server or Published Application dialog box. iii. Confirm that HTTP/HTTPS is selected from the Network Protocol list. iv. Enter the metaframe server DNS in the Add Server Location Address dialog box. v. Enter 80 in the port field. vi. Click OK in the Add Server Location Address dialog box and the Locate Server or Published Application dialog box. a. Select an application from the Published Application list. J-SAM overview 433 Juniper Networks Secure Access Administration Guide 4. Enter information in the remaining wizard screens as prompted. Custom application support: Citrix secure gateways When enabling Citrix secure gateways (CSGs) through the IVE, you must complete the steps outlined in the following sections: 1. Disable Citrix NFuse as a standard application through the Users > Resource Profiles > Web > Web Applications/Pages page of the admin console. NOTE: You cannot enable the Citrix NFuse standard application and Citrix Secure Gateways (CSGs) custom applications through JSAM on the same IVE. 2. Specify applications for JSAM to port forward by adding a custom application through JSAM. Use the instructions in “Defining resource profiles: JSAM” on page 435. When adding the custom application, keep the following settings in mind: Server name—For CSGs, you must enter the Citrix secure gateway server’s fully qualified DNS name, not its IP address. Server port—For CSGs, enter 443. If you have multiple Citrix secure gateway servers, you must configure all of them on the same port. Client port—For CSGs, enter 443. (Create one entry for port 80 and another for port 443.) 3. If you have multiple internal domains, such as company-a.com and companyb.com, add DNS domains to the IVE using settings in the System > Network > Overview page of the admin console so that names such as app1.companya.com and app2.company-b.com resolve correctly. 4. If a remote user’s PC is set up to use a Web proxy in Internet Explorer, configure the client machine to bypass the proxy server when the user launches applications that need to connect to the Secure Application Manager. For instructions, see “Configuring a PC that connects to the IVE through a proxy Web server” on page 420. 5. Enable JSAM to associate IP loopback addresses with application servers on specific ports either by enabling JSAM to edit the hosts file on your users’ systems (as explained in “Resolving host names to localhost” on page 424) or by creating an external DNS to route client application traffic to the J-SAM applet (as explained in “Configuring external DNS servers and user machines” on page 425). 6. Setup your Citrix Secure Gateway and confirm that it works on your desktop. 7. Add a bookmark to the end-users’ IVE home page that points to the list of Citrix secure gateway servers and use the IVE’s Selective Rewrite feature to turn off rewriting for the URL. Or, if you do not want to create a bookmark through the IVE, simply instruct users to access the URL using their Web browser’s address bar instead of the IVE address bar. 434 J-SAM overview Chapter 16: Secure Application Manager Defining resource profiles: JSAM JSAM resource profiles configure JSAM to secure traffic to a client/server application. When you create a JSAM application resource profile, the JSAM client tunnels network traffic generated by the specified client applications to servers in your internal network. For more information about resource profiles, see “Resource profiles” on page 71. For more information about JSAM, see “J-SAM overview” on page 417. NOTE: When creating JSAM resource profiles, note that the resource profiles do not contain bookmarks. Therefore, end-users will not see a link for the configured application in the end-user interface. To access the applications and servers that JSAM intermediates, users must first launch JSAM and then launch the specified application using standard methods (such as the Windows Start menu or a desktop icon). For information about automatically launching JSAM when the user signs into the IVE, see “Specifying role level JSAM options” on page 442. Also note that when you enable JSAM or WSAM through rewriting autopolicies for Web resource profiles, the IVE automatically creates JSAM or WSAM autopolicies for you. You can only view these SAM policies through the appropriate Web resource profile—not through the SAM resource profile pages of the admin console. For more information, see “Defining a rewriting autopolicy” on page 300. To create a JSAM application resource profile: 1. Navigate to the Users > Resource Profiles > SAM > Client Applications page in the admin console. 2. Click New Profile. 3. From the Type list