Check Point UserAuthority Guide

NGX (R60)

For additional technical information about Check Point products, consult Check Points SecureKnowledge at

http://support.checkpoint.com/kb/
See the latest version of this document in the User Center at

http://www.checkpoint.com/support/technical/documents/docs_r60.html

Part No.: 700358 April 13, 2005

 2003-2005 Check Point Software Technologies Ltd.

All rights reserved. This product and related documentation are protected by copyright and distributed under licensing restricting their use, copying, distribution, and decompilation. No part of this product or related documentation may be reproduced in any form or by any means without prior written authorization of Check Point. While every precaution has been taken in the preparation of this book, Check Point assumes no responsibility for errors or omissions. This publication and features described herein are subject to change without notice.

RESTRICTED RIGHTS LEGEND:

Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19.

TRADEMARKS:
2003-2005 Check Point Software Technologies Ltd. All rights reserved. Check Point, Application Intelligence, Check Point Express, the Check Point logo, AlertAdvisor, ClusterXL, Cooperative Enforcement, ConnectControl, Connectra, CoSa, Cooperative Security Alliance, Eventia, Eventia Analyzer, FireWall-1, FireWall-1 GX, FireWall-1 SecureServer, FloodGate-1, Hacker ID, IMsecure, INSPECT, INSPECT XL, Integrity, InterSpect, IQ Engine, Open Security Extension, OPSEC, Policy Lifecycle Management, Provider-1, Safe@Home, Safe@Office, SecureClient, SecureKnowledge, SecurePlatform, SecuRemote, SecureXL Turbocard, SecureServer, SecureUpdate, SecureXL, SiteManager-1, SmartCenter, SmartCenter Pro, Smarter Security, SmartDashboard, SmartDefense, SmartLSM, SmartMap, SmartUpdate, SmartView, SmartView Monitor, SmartView Reporter, SmartView Status, SmartViewTracker, SofaWare, SSL Network Extender, Stateful Clustering, TrueVector, Turbocard, UAM, User-to-Address Mapping, UserAuthority, VPN-1, VPN-1 Accelerator Card, VPN-1 Edge, VPN-1 Pro, VPN-1 SecureClient, VPN-1 SecuRemote, VPN-1 SecureServer, VPN-1 VSX, VPN-1 XL, Web Intelligence, ZoneAlarm, ZoneAlarm Pro, Zone Labs, and the Zone Labs logo, are trademarks or registered trademarks of Check Point Software Technologies Ltd. or its affiliates. All other product names mentioned herein are trademarks or registered trademarks of their respective owners. The products described in this document are protected by U.S. Patent No. 5,606,668, 5,835,726, 6,496,935 and 6,850,943 and may be protected by other U.S. Patents, foreign patents, or pending applications.

THIRD PARTIES:
Entrust is a registered trademark of Entrust Technologies, Inc. in the United States and other countries. Entrusts logos and Entrust product and service names are also trademarks of Entrust Technologies, Inc. Entrust Technologies Limited is a wholly owned subsidiary of Entrust Technologies, Inc. FireWall-1 and SecuRemote incorporate certificate management technology from Entrust. Verisign is a trademark of Verisign Inc. The following statements refer to those portions of the software copyrighted by University of Michigan. Portions of the software copyright 1992-1996 Regents of the University of Michigan. All rights reserved. Redistribution and use in source and binary forms are permitted provided that this notice is preserved and that due credit is given to the University of Michigan at Ann Arbor. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. This software is provided as is without express or implied warranty. Copyright Sax Software (terminal emulation only). The following statements refer to those portions of the software copyrighted by Carnegie Mellon University. Copyright 1997 by Carnegie Mellon University. All Rights Reserved. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of CMU not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission.CMU DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL CMU BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. The following statements refer to those portions of the software copyrighted by The Open Group. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND

NONINFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. The following statements refer to those portions of the software copyrighted by The OpenSSL Project. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/). THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The following statements refer to those portions of the software copyrighted by Eric Young. THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Copyright 1998 The Open Group. The following statements refer to those portions of the software copyrighted by Jean-loup Gailly and Mark Adler Copyright (C) 1995-2002 Jean-loup Gailly and Mark Adler. This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. The following statements refer to those portions of the software copyrighted by the Gnu Public License. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. The following statements refer to those portions of the software copyrighted by Thai Open Source Software Center Ltd and Clark Cooper Copyright (c) 2001, 2002 Expat maintainers. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. GDChart is free for use in your applications and for chart generation. YOU MAY NOT redistribute or represent the code as your own. Any re-distributions of the code MUST reference the author, and include any and all original documentation. Copyright. Bruce Verderaime. 1998, 1999, 2000, 2001. Portions copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Cold Spring Harbor Laboratory. Funded under Grant P41RR02188 by the National Institutes of Health. Portions copyright 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Boutell.Com, Inc. Portions relating to GD2 format copyright 1999,

Check Point Software Technologies Ltd.

U.S. Headquarters: 800 Bridge Parkway, Redwood City, CA 94065, Tel: (650) 628-2000 Fax: (650) 654-4233, info@CheckPoint.com International Headquarters: 3A Jabotinsky Street, Ramat Gan, 52520, Israel, Tel: 972-3-753 4555 Fax: 972-3-575 9256, http://www.checkpoint.com

2000, 2001, 2002 Philip Warner. Portions relating to PNG copyright 1999, 2000, 2001, 2002 Greg Roelofs. Portions relating to gdttf.c copyright 1999, 2000, 2001, 2002 John Ellson (ellson@graphviz.org). Portions relating to gdft.c copyright 2001, 2002 John Ellson (ellson@graphviz.org). Portions relating to JPEG and to color quantization copyright 2000, 2001, 2002, Doug Becker and copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, Thomas G. Lane. This software is based in part on the work of the Independent JPEG Group. See the file README-JPEG.TXT for more information. Portions relating to WBMP copyright 2000, 2001, 2002 Maurice Szmurlo and Johan Van den Brande. Permission has been granted to copy, distribute and modify gd in any context without fee, including a commercial application, provided that this notice is present in user-accessible supporting documentation. This does not affect your ownership of the derived work itself, and the intent is to assure proper credit for the authors of gd, not to interfere with your productive use of gd. If you have questions, ask. "Derived works" includes all programs that utilize the library. Credit must be given in user-accessible documentation. This software is provided "AS IS." The copyright holders disclaim all warranties, either express or implied, including but not limited to implied warranties of merchantability and fitness for a particular purpose, with respect to this code and accompanying documentation. Although their code does not appear in gd 2.0.4, the authors wish to thank David Koblas, David Rowley, and Hutchison Avenue Software Corporation for their prior contributions. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http:/ /www.apache.org/licenses/LICENSE-2.0 The curl license COPYRIGHT AND PERMISSION NOTICE Copyright (c) 1996 - 2004, Daniel Stenberg, <daniel@haxx.se>.All rights reserved. Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder. The PHP License, version 3.0 Copyright (c) 1999 - 2004 The PHP Group. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name "PHP" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact group@php.net. 4. Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission from group@php.net. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo" 5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License. 6. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes PHP, freely available from <http://www.php.net/>". THIS SOFTWARE IS PROVIDED BY THE PHP DEVELOPMENT TEAM ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE PHP DEVELOPMENT TEAM OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN

CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the PHP Group. The PHP Group can be contacted via Email at group@php.net. For more information on the PHP Group and the PHP project, please see <http:// www.php.net>. This product includes the Zend Engine, freely available at <http:// www.zend.com>. This product includes software written by Tim Hudson (tjh@cryptsoft.com). Copyright (c) 2003, Itai Tzur <itzur@actcom.co.il> All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistribution of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Neither the name of Itai Tzur nor the names of other contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Copyright 2003, 2004 NextHop Technologies, Inc. All rights reserved. Confidential Copyright Notice Except as stated herein, none of the material provided as a part of this document may be copied, reproduced, distrib-uted, republished, downloaded, displayed, posted or transmitted in any form or by any means, including, but not lim-ited to, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of NextHop Technologies, Inc. Permission is granted to display, copy, distribute and download the materials in this doc-ument for personal, non-commercial use only, provided you do not modify the materials and that you retain all copy-right and other proprietary notices contained in the materials unless otherwise stated. No material contained in this document may be "mirrored" on any server without written permission of NextHop. Any unauthorized use of any material contained in this document may violate copyright laws, trademark laws, the laws of privacy and publicity, and communications regulations and statutes. Permission terminates automatically if any of these terms or condi-tions are breached. Upon termination, any downloaded and printed materials must be immediately destroyed. Trademark Notice The trademarks, service marks, and logos (the "Trademarks") used and displayed in this document are registered and unregistered Trademarks of NextHop in the US and/or other countries. The names of actual companies and products mentioned herein may be Trademarks of their respective owners. Nothing in this document should be construed as granting, by implication, estoppel, or otherwise, any license or right to use any Trademark displayed in the document. The owners aggressively enforce their intellectual property rights to the fullest extent of the law. The Trademarks may not be used in any way, including in advertising or publicity pertaining to distribution of, or access to, materials in this document, including use, without prior, written permission. Use of Trademarks as a "hot" link to any website is prohibited unless establishment of such a link is approved in advance in writing. Any questions concerning the use of these Trademarks should be referred to NextHop at U.S. +1 734 222 1600.

U.S. Government Restricted Rights The material in document is provided with "RESTRICTED RIGHTS." Software and accompanying documentation are provided to the U.S. government ("Government") in a transaction subject to the Federal Acquisition Regulations with Restricted Rights. The Government's rights to use, modify, reproduce, release, perform, display or disclose are restricted by paragraph (b)(3) of the Rights in Noncommercial Computer Software and Noncommercial Computer Soft-ware Documentation clause at DFAR 252.227-7014 (Jun 1995), and the other restrictions and terms in paragraph (g)(3)(i) of Rights in DataGeneral clause at FAR 52.227-14, Alternative III (Jun 87) and paragraph (c)(2) of the Commer-cial Computer Software-Restricted Rights clause at FAR 52.227-19 (Jun 1987). Use of the material in this document by the Government constitutes acknowledgment of NextHop's proprietary rights in them, or that of the original creator. The Contractor/ Licensor is NextHop located at 1911 Landings Drive, Mountain View, California 94043. Use, duplication, or disclosure by the Government is subject to restrictions as set forth in applicable laws and regulations. Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty THE MATERIAL IN THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTIES OF ANY KIND EITHER EXPRESS OR IMPLIED. TO THE FULLEST EXTENT POSSIBLE PURSUANT TO THE APPLICABLE LAW, NEXTHOP DISCLAIMS ALL WARRAN-TIES, EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON INFRINGEMENT OR OTHER VIOLATION OF RIGHTS. NEITHER NEXTHOP NOR ANY OTHER PROVIDER OR DEVELOPER OF MATERIAL CONTAINED IN THIS DOCUMENT WARRANTS OR MAKES ANY REPRESEN-TATIONS REGARDING THE USE, VALIDITY, ACCURACY, OR RELIABILITY OF, OR THE RESULTS OF THE USE OF, OR OTHER-WISE RESPECTING, THE MATERIAL IN THIS DOCUMENT. Limitation of Liability UNDER NO CIRCUMSTANCES SHALL NEXTHOP BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSE-QUENTIAL DAMAGES, INCLUDING, BUT NOT LIMITED TO, LOSS OF DATA OR PROFIT, ARISING OUT OF THE USE, OR THE INABILITY TO USE, THE MATERIAL IN THIS DOCUMENT, EVEN IF NEXTHOP OR A NEXTHOP AUTHORIZED REPRESENTATIVE HAS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IF YOUR USE OF MATERIAL FROM THIS DOCUMENT RESULTS IN THE NEED FOR SERVICING, REPAIR OR CORRECTION OF EQUIPMENT OR DATA, YOU ASSUME ANY COSTS THEREOF. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE LIMITATION OR EXCLUSION MAY NOT FULLY APPLY TO YOU. Copyright ComponentOne, LLC 1991-2002. All Rights Reserved. BIND: ISC Bind (Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")) Copyright 1997-2001, Theo de Raadt: the OpenBSD 2.9 Release

Table Of Contents
Chapter 1 Introduction
The Need for UserAuthority 11 Web Access Management (WebAccess) 11 Identity-based Access Control for Outbound Connections via VPN-1 Pro Gateway 13 Underlying Concept and Advantage 13 Typical Deployments 14 UserAuthority for Enterprise Web Applications Deployment 14 Business to Consumer (B2C) Deployment 18 UserAuthority SSO for VPN-1 Pro Deployment 20 OPSEC Protocols 21 UserAuthority Management Model 21 How to Use this Guide 22

Chapter 2

UserAuthority Deployments and Installation

Overview 23 Deployments 25 UserAuthority for Enterprise Web Applications 25 UserAuthority WebAccess Deployment 27 Terms in UserAuthority WebAccess Configuration 29 Workflow 31 Test Your Deployment 32 B2C 32 Workflow 36 Test Your Deployment 37 Outbound Access Control 38 Workflow 39 Test Your Deployment 39 Adding an SSO Rule 39 Citrix MetaFrame or Windows Terminal Services 42 Workflow 43 Test Your Deployment 43 Adding an SSO Rule for Citrix MetaFrame or Windows Terminal Services 44 Combining the Deployments 45 Workflow 47 Test Your Deployment 48 Installation and Configuration 49 Installing and Configuring UAS on VPN-1 Pro 49 Installing the UserAuthority License 49 Installing UAS on the VPN-1 Pro Gateway 50 Configuring the UAS 55 Installing and Configuring the UAS on the Windows DC 61

Table of Contents 3

Installing the UAS 61 Configuring UAS Properties 65 Configuring SecureAgent Automatic Installation 68 Installing and Configuring UserAuthority WAPS 70 Installing UserAuthority WAPS 71 Configuring UserAuthority WAPS 72 Configuring UserAuthority WAPS in SmartDashboard 75 Installing and Configuring the UserAuthority WAPI 80 Configuring UserAuthority WAPI in SmartDashboard 83 Configuring Common Suffix Domains 83 Configuring Virtual Hosts 84 Configuring a Basic Web SSO Rule 85 Configuring UserAuthority WebAccess Application Settings 87 Configuring the Single Sign-On Effect 89 Configuring the Insert Header Effect 90 Defining Authentication Domains 92 Setting Up SSL Terminating Certificates on your UserAuthority WAPS Installation 94

Chapter 3

Web SSO
The Challenge 97 The UserAuthority Solution 98 SSO Types for Web Applications 100 Achieving User Identity 101 Internal Users 101 Identification using the NTLM Authentication Protocol 102 Identification of Users on a Citrix or Terminal Services 103 Remote Users with a VPN Client 104 Remote Users without a VPN Client 105 Mapping User Identity to Application Information by UserAuthority 106 Using a Header for Authentication 108 Special Scenarios 108 Web SSO with an Internal Proxy 108 For security reasons, WAPS does not accept forward connections from all proxies. 109 Workflow 110 Test Your Deployment 110 Web SSO with Citrix 110 Workflow 110 Web SSO with more than one Web site 110 Workflow 111 Test Your Deployment 111 Web SSO with Manual Identity Sharing 111 Workflow 112 Test Your Deployment 112 Configuration 112 UserAuthority WebAccess SSO for Web Application Authentication 113 SSO for HTTP Basic Authentication 113 SSO for HTML Form Authentication 113 Providing User Identity Web Applications with no Authentication Requirements 114

Configuring Manual UserAuthority Settings 114 Manually Updating User Credentials 115 Disabling UserAuthority WebAccess for Specific IP Addresses 115 Configuring Integrated Windows Authentication 116 Troubleshooting the Establish a Trust Procedure 119 Troubleshooting the NTLM Procedure 120 Ensuring that all Local Web pages are Recognized as Intranet Sites 120 Configuring Multiple Web Sites in SmartDashboard 122 Advanced Configuration 124 Configuring UserAuthority WebAccess to Recognize Cache Proxy Users 124 Configuring Manual Identity Sharing Options 125 Creating UAS Groups 127

Chapter 4

Authorization for Web Applications

The Challenge 129 The UserAuthority Access Control Solution 130 Access Control Policy 131 Creating Security and Authorization Rules 131 Access Control Enforcement 132 Access Control Scenarios 134 User Groups with Different Authorization Levels 134 Enforcing SSL Encryption on Connections 136 Configuration 137 Defining Web Sites 138 Defining Advanced Web Site Options 141 Advanced Properties 141 Custom Rejection Policy 144 Access Control with SSO-Only Web Site 145 Defining URLs 145 Defining Security and Authorization Rules 146 Defining a Basic Access Control Policy 147 Security Rules 148 Authorization Rules 150 Advanced Configuration in SmartDashboard 152 UserAuthority WebAccess Advanced Configurations Window 153 Defining Operation Objects and Groups 154 Defining Trust Objects and Groups 159 Creating a Trust Object 159 Trust Object Parameters 160

Chapter 5

Outbound Access Control

The Challenge 167 The UserAuthority Solution 168 Identification using SecureAgent 170 Identity Sharing 170 Using Outbound Access Control with Web SSO 171 Workflow 171 Retrieving Windows Groups with UserAuthority 171
Table of Contents 5

Outbound Access Control using Citrix Terminals as TIP 172 Scenario - An Organization using Multiple Windows DCs 172 Workflow 173 Test Your Deployment 174 Scenario - An Organization Using Multiple Domains 174 Workflow 175 Test Your Deployment 175 Configurations 176 Adding Additional Windows DCs 176 Workflow 176 Outbound Access Control on Citrix or Windows Terminals 176 Configuring UserAuthority Domain Equality 177

Chapter 6

User Management in UserAuthority

Overview 181 Managing Users and Groups 182 Users in UserAuthority 182 User Groups in UserAuthority 182 Using a Local Check Point Database 183 Using an External Database 183 Using the Windows User Identity 184 Users in the Windows Domain 184 Configuring UserAuthority to Recognize Windows User Groups 184

Chapter 7

Web Security Features

Overview 187 Broken Access Control 188 Broken Account and Session Management 189 Remote Administration Flaws 191 Web Server and Application Misconfiguration 193

Chapter 8

Auditing in UserAuthority
Overview 195 Using Logs for Auditing 196 Auditing Outbound Traffic Using UserAuthority Outbound Access Control 198 Displaying the Resource Name in the Information Field 200 Auditing Web Access Using UserAuthority WebAccess 201 Auditing User Requests 203 Auditing UserAuthority WebAccess Authorization Rejections 204 Other UserAuthority WebAccess Logs 205 Configuring UserAuthority for Auditing 206 Configuring Auditing of Requests for External Resources 206 Configuring Auditing for UserAuthority WebAccess 206 Configuring Rejection Policy Logs 207 Configuring Auditing of Requests for URLs Outside the Policy Scope 208 Configuring SSO Abuse Tracking 209 Customizing Logs 210

Disabling Specific Log Entries 211 Customizing Specific Log Entries 212 Eliminating Logging of Graphics Files 213

Chapter 9

High Availability and Load Balancing

Overview 215 High Availability 215 Load Balancing 216 High Availability and Load Balancing in UserAuthority 216 Using Multiple UserAuthority WebAccess Servers 216 Using UserAuthority WAPS Clusters 216 Configuring WebAccess Cluster 218 Workflow 218 Creating a New Server Group 218 Creating a Logical Server Object 219 Defining a Security Policy for the UserAuthority WAPS Cluster Server Group 221 Using Multiple Windows DCs 222 Using a VPN-1 Pro Cluster 222 Using VPN-1 Pro Clusters 222 Synchronizing the Credentials Manager 222 Automatic Synchronization 223 Using the db_sync Script 223

Chapter 10

UserAuthority CLIs
UAS 226 uas debug 226 uas drv 226 uas reconf 227 uas d 227 uas kill 227 uas ver 227 netsod 228 netsod debug 228 netsod drv 228 netsod d 229 netsod kill 229 netsod simple 229 netsod simple kill 229 netsod ver 230 uas 230 cpstop 230 cpstart 231 cprestart 231 uagstop 231 uagstart 232 wastop 232 wastart 232 service wa_proxy 232
Table of Contents 7

sysconfig 233 remote_wa_admin 233 wac_ver 234 ver 234 uainfo 234

Chapter 11

UserAuthority OPSEC APIs

Overview 237 Programming Model 237 Defining a UAA Client 240 Client Server Configuration 240 OPSEC UserAuthority API Overview 241 UAA Client Application Structure 242 Event Handling 243 Requests 243 Key Assertions 244 Request Assertions 245 Replies 247 Connection-Based Vs. IP-Based Information in Queries 249 UAA Assertions Structure Functions 250 Processing Error Codes 250 Session Management 250 Function Calls 251 Session Management 251 uaa_new_session 251 uaa_end_session 252 Assertions Management 252 uaa_assert_t_create 252 uaa_assert_t_add 252 uaa_assert_t_duplicate 253 uaa_assert_t_destroy 253 uaa_assert_t_compare 254 uaa_asser_t_n_elements 254 Managing Queries 254 uaa_send_query 254 uaa_abort_query 255 Managing Updates 256 uaa_send_update 256 Managing Authentication Requests 256 uaa_send_authenticate_request 256 Assertions Iteration 257 uaa_assert_t_iter_create 257 uaa_assert_t_iter_get_next 258 uaa_assert_t_iter_reset 259 uaa_assert_t_iter_destroy 259 Managing UAA Errors 259 uaa_error_str 259 Debugging 260

uaa_print_assert_t 260 Event Handlers 260 UAA_QUERY_REPLY Event Handler 261 UAA_UPDATE_REPLY Event Handler 262 UAA_AUTHENTICATE_REPLY Event Handler 263

Chapter 12

Monitoring the UserAuthority Environment

Overview 265 System Monitoring 266 Monitoring the System Status 266 UAS 267 UserAuthority WebAccess 268 Using UAS and UserAuthority WebAccess Logs for System Monitoring 269 Using UAS Logs 270 Monitoring Example: UAS is Offline 272 User Monitoring 273 Monitoring User Activities 273 Monitoring Example: Successful Access to a Web Application 275 Monitoring Example: SecureAgent Cannot Provide User Identity 276

Chapter 13

Troubleshooting UserAuthority
Overview 279 General Problems 280 Why is the service not available? 280 Symptom 280 Problem 280 Solutions 280 Why is there a proxy error? 281 Symptom 281 Problem 282 Solutions 282 Why are users not authorized to view the page? 282 Symptom 282 Problem 282 Solutions 282 Why is there no established SIC? 283 Symptom 283 Problem 283 Solutions 283 Why are users not authorized access when the policy is installed? 285 Symptom 285 Problem 285 Solutions 285 Why are there no logs in SmartView Tracker? 286 Symptom 286 Problem 286 Solutions 286 User-Related Problems 286
Table of Contents 9

Why is the service not available to the user? 286 Symptom 286 Problem 286 Solutions 287 Why cant the user sign in with a specific user name? 287 Symptom 287 Problem 287 Solutions 288 Why does SecureAgent not identify the user? 288 Symptom 288 Problem 288 Solutions 288 Why do users receive a pop-up even when signed into the domain? 291 Symptom 291 Problem 291 Solutions 291

Appendix A

Integrating UserAuthority with Meta IP

Overview 293 Required Components 293 Preliminary Steps 294 Windows DC Configuration 294 VPN-1 Pro Policy Configuration 294 DHCP Server Configuration 296

Appendix B

Glossary
Acronyms and Abbreviations 301

10

CHAPTER

Introduction
In This Chapter
The Need for UserAuthority Underlying Concept and Advantage Typical Deployments OPSEC Protocols UserAuthority Management Model How to Use this Guide page 11 page 13 page 14 page 21 page 21 page 22

The Need for UserAuthority

In todays business environment, enterprises need to provide employees, partners and customers with the ability to access and work with many different applications and services. It is important that access to these applications be simple and convenient, and, at the same time, secure, reliable, and easy to manage. UserAuthority is able to leverage the security needs of your existing or new environment to higher levels. UserAuthority can improve access control management in your enterprise in two major ways: Web Access Management and identity-based access control for outbound connections via the VPN-1 Pro gateway.

Web Access Management (WebAccess)

This solution provides the following functionalities and benefits: Web Single Sign On (SSO): UserAuthority allows users to access all Web applications with a single identity. There is no need for users to remember and enter different credentials for each Web application accessed.

11

The Need for UserAuthority

Authorization: UserAuthority provides authorization on the application level. Each user is assigned (through a User Group) specific access privileges for each application. Privileges can determine: The types of access that a user is granted for a specific Web application (e.g., read only, read/write, or no access at all). How a user can access an application (e.g., using a specific authentication method or using encryption). From which locations a user can access a Web application (e.g., from the local network only, both remotely and locally, or via remote access only). Strong authentication paradigm: UserAuthority can provide stronger authentication methods on the application level than the basic types of authentication implemented in Web applications (e.g.,VPN-1 Pro authentication, Secure ID, RADIUS, TACAC). Auditing: UserAuthority can generate logs that show user activity. These logs can be used to track user activity, for system analysis, and for legal purposes. Increased Security: The UserAuthority WebAccess Proxy Server (WAPS) allows all authentication and authorization activities to be moved from the systems Web servers to a different machine located in a safe DMZ. In that way, the Web application can be located in an internal segment and receive only authenticated requests. Convenience: On the administrator level A single management method can be used for different systems in a network. This prevents the confusion of having a different type of management for every system. On the user level UserAuthority can eliminate the need for users to authenticate each time they access a different Web application using different credentials and authentication methods. Reduced costs: UserAuthority can reduce the need for users to contact the enterprises help desk because they have forgotten the password or username for specific applications. Reduced development and maintenance costs: There is no need for programmers to make changes to an applications code; the non-intrusive mechanism provides all the functionality without the need to change the code of the applications. Deploying UserAuthority in an enterprise is simple and fast and does not require structural changes in your organization, such as migrating user databases and changing your user repository for various applications. In addition, because UserAuthority uses the same management tools and GUI as VPN-1 Pro, most administrators are already familiar with its operation.

12

Identity-based Access Control for Outbound Connections via VPN-1 Pro Gateway

Centralized management: A single central management function is used to manage all access control and auditing functions for all Web applications in a network. High availability and load balancing: UserAuthority supports the use of clusters to ensure maximal system availability. In addition, clusters help to balance the load between Web servers in a network with heavy traffic.

Identity-based Access Control for Outbound Connections via VPN-1 Pro Gateway
UserAuthority can provide access control to external resources at the network level (Internet or other services outside the perimeter gateway). Through VPN-1 Pro gateways, firewall authentication can be configured in the security policy to supply such demand (Client, Session authentications). The major difference with UserAuthority is the benefit of SSO to those authentications, eliminating the need for the user to re-authenticate. UserAuthority enables the user to be identified transparently via the gateway without human intervention. This functionality is also known as UserAuthority SSO for VPN-1 Pro or Outbound SSO.

Underlying Concept and Advantage

One of the greatest advantages of UserAuthority is its ability to extract the user identity from a Trusted Identification Point (TIP). UserAuthority establishes a trust relationship with TIPs on the network to ensure that it is receiving trusted information. UserAuthority TIPs include: Windows logons to Domain Controllers VPN-1 Pro authentication (SecureRemote/SecureClient) or any other authentications to the gateways) MS Terminal Services/Citrix MetaFrame servers UserAuthority WebAccess authentication services Once a user is logged on to a network (no matter where or how they logged on), the user identity is used to provide SSO thereby enabling authentication to any Web-based application on the users behalf. The users identity is also used for access control and auditing purposes. Extracting the user identity from the TIP enables the following benefits: Once a user is logged on to the system and identified by UserAuthority, there is no need to authenticate again, even when accessing a Web application. Pure SSO, requiring only the initial network log on to a TIP. No other authentication is required.
Chapter 1 Introduction 13

Typical Deployments

Utilization of existing authentication in the network environment to retrieve user identification, without requiring the end user to identify to an additional identification mechanism. Integration of network level authentication with Web applications. Deployment does not require any changes to Web applications.

Typical Deployments
This section describes three common types of deployments, and the particular benefits of integrating UserAuthority into each of the deployment types. A detailed description of the various UserAuthority deployment types, and how they are set up and implemented, is presented in Chapter 2, UserAuthority Deployments and Installation. The first and the second deployment examples illustrate Web Access Management scenarios. The last one illustrates identity-based access control for outbound connections via a VPN-1 Pro gateway.

UserAuthority for Enterprise Web Applications Deployment

This deployment typically includes both local and remote users who access various Web applications. The deployment contains various Web servers, a firewall, and both local and remote clients. FIGURE 1-1 illustrates this deployment without UserAuthority.

14

UserAuthority for Enterprise Web Applications Deployment

FIGURE 1-1

Enterprise with Web Applications Deployment without UserAuthority

In this deployment, each Web server must provide a means for user authentication. This can become complicated and might not meet the needs of the enterprise. The drawbacks of this type of deployment include: An administrator cannot control user activities or audit them. An administrator must manage multiple user databases with different authentication means and passwords, or users must authenticate themselves each time they access a different Web server or Web application. The inability to accommodate a need to authorize different users to carry out different activities. For example, when dealing with employee information, the enterprise authorizes HR managers to have read/write access, lets only the CEO read the information, and forbids any other users from accessing this information. In this deployment, access rights must be configured individually in each application, according to each separate applications method for configuring access rights. The inability to accommodate a need to perform various actions in different ways. For example, if the authorized user tries to carry out an action from home, the user might be a required to carry out the action using a VPN tunnel, however this is not required when the user carries out the same action from the local network.
Chapter 1 Introduction 15

Typical Deployments

No auditing or different auditing for some users.

Enterprise with Web Applications Deployment with UserAuthority

FIGURE 1-2 shows this same type of deployment with UserAuthority.

FIGURE 1-2

Two UserAuthority components have been added in this deployment; the UserAuthority Server installed on the VPN-1 Pro gateway and the WAPS. UserAuthority eliminates the need for multiple authentications by users. This is carried out by the UserAuthority Server and WebAccess, working with the VPN-1 Pro component on the gateway and the Windows Domain Controller (DC). In this example, a users Web requests go to the WAPS. UserAuthority WebAccess queries various components to retrieve the users identity. FIGURE 1-2 indicates four areas that can be queried for user identity in this deployment. Windows DC: UserAuthority WebAccess queries the Windows DC to get the users identity through Windows Integrated Authentication (NTLM protocol). VPN tunnel encryption: Remote users who sign on using a VPN client send encrypted information that contains the users identity. UserAuthority WebAccess recognizes requests that come over a VPN tunnel and queries VPN-1 Pro for the user identity based on the information provided. VPN-1 Pro: In some cases there is manual identification to VPN-1 Pro. In this case, user identification is retrieved from the User list in VPN-1 Pro.

16

UserAuthority for Enterprise Web Applications Deployment

UserAuthority WebAccess: Users who did not sign on to a network through the Windows DC or a VPN tunnel might not be recognized by UserAuthority WebAccess. In this case the user is prompted to manually authenticate to UserAuthority WebAccess the first time a Web application is requested. Authentication is carried out against the user database on the VPN-1 Pro gateway with the UserAuthority Server.

These four areas constitute Trusted Identification Points (TIPs) because a trust has been established with each of these components (the VPN-1 Pro, Windows DC, and UserAuthority WebAccess) so that UserAuthority WebAccess knows it is receiving trusted information. For more information on setting up a trust relationship between components in the system, see Chapter 2, UserAuthority Deployments and Installation. UserAuthority also supports retrieving the user identity on Citrix or Windows terminal systems. In this case, the UserAuthority Server is also installed on the Citrix MetaFrame server or Windows Terminal Services. UserAuthority is able to retrieve the user identity from information provided by the users client connection to the server, even though a user is not identified directly in a terminal configuration. For more information on Citrix or Windows terminal deployments, see Chapter 2, UserAuthority Deployments and Installation. UserAuthoritys ability to automatically identify users in this deployment is used to provide: Web SSO: Web SSO takes the user identity and matches it to specific credentials for a requested Web application. These credentials are inserted automatically into the applications authentication page on behalf of the user. This is all done transparently, so that the user does not have to sign on to individual applications. The sign on that is performed when the user first signs on to the system is the only sign on that is necessary. For more information, see Chapter 3, Web SSO. Web application authorization: UserAuthority uses the identity that was retrieved from a TIP to match users to defined User Groups. These groups grant users specific access to Web applications. Users are granted or denied access based on the defined criteria. For more information, see Chapter 4, Authorization for Web Applications. Unified Authorization and Authentication policy: A single policy can be used to handle all authentication and authorization to Web servers from anywhere. Reduced need for authentication: Most users can be identified without authentication (e.g., LAN users, VPN users). Single auditing system: One system monitors all user activities, regardless of how many Web servers are in the deployment.

Chapter 1

Introduction

17

Typical Deployments

Improved authentication and security: UserAuthority improves authentication and security methods by: Using strong authentication methods for access to your system. Allowing only identified and authorized requests to be sent by the proxy to the Web server.

Business to Consumer (B2C) Deployment

Many enterprises offer services to customers through the Internet. One example is a health maintenance organization that provides customers with the ability to view their medical records online. FIGURE 1-3 shows a B2C deployment without UserAuthority.
FIGURE 1-3 B2C Deployment without UserAuthority WebAccess

In this deployment, users access the Web servers directly. This does not allow the enterprise to control customer actions when they sign on. This control is very important because the information provided to customers is very sensitive. Only authorized users should be able to access the information, and customers should only be able to access their own information.

18

Business to Consumer (B2C) Deployment

By installing UserAuthority Server and UserAuthority WebAccess, an enterprise can easily: Allow only known users to carry out various requests and access specific applications. Authorize specific users to carry out specifically defined operations. Provide unified access, authentication, and authorization to different Web services and Web servers. Implement a secure method of authentication within the enterprise. FIGURE 1-4 shows a B2C deployment that utilizes the features of UserAuthority WebAccess.
FIGURE 1-4 B2C Deployment with UserAuthority WebAccess

In this deployment we have added the UserAuthority Server installed on the VPN-1 Pro gateway and the WAPS.

Chapter 1

Introduction

19

Typical Deployments

WAPS provides additional advantages to B2C deployments: Requests can be distributed to multiple Web servers according to the Web servers content. This is important because a request that originates outside the network is not sent directly to a Web server that contains sensitive content. The WAPS sits in a protected segment (such as a DMZ) and then transfers the requests to the correct Web server only after they have been authorized. UserAuthority WebAccess can personalize a home page by inserting personal information on the page. When a user accesses an enterprises Web site, the user is greeted and possibly given personal instructions. UserAuthority WebAccess does this by inserting the users identification information into a header that provides the personal information to the Web page. This identity is kept between servers and services. UserAuthority can be smoothly integrated with VPN-1 Pro. There is no need to change VPN-1 Pro policy by opening special ports for UserAuthority WebAccess communication. For more information, see Chapter 4, Authorization for Web Applications.

UserAuthority SSO for VPN-1 Pro Deployment

UserAuthority can provide authorization to external resources at the network level. Most enterprises already use VPN-1 Pro authentication rules that require client or session authentication to external resources. UserAuthority expands on this by providing SSO to the VPN-1 Pro as well as auditing capabilities.
FIGURE 1-5 SSO for VPN-1 Pro Deployment

UserAuthority eliminates the need for a user to authenticate each time an external resource is accessed. This is done by using the information on the Windows DC to identify the user. When the user requests an external resource, the UserAuthority Server on the VPN-1 Pro gateway queries the UserAuthority Server installed in a Windows DC. The UserAuthority Server on the Windows DC sends a query to a desktop application called SmartAgent, which identifies the user according to the Windows DC identification that was used at sign-on.
20

UserAuthority SSO for VPN-1 Pro Deployment

This information is sent back to the UserAuthority Server on the VPN-1 Pro gateway to provide authentication on behalf of the user. In this way, the user is automatically authenticated each time without the need to re-authenticate each time a request for external resources is made. This scenario is illustrated in FIGURE 1-5. UserAuthority can be also configured to create logs each time a user requests an external resource. This provides information on how users are accessing external resources. Logs can provide various types of information, such as whether users are violating enterprise policy or whether there are communications problems when trying to access external resources. UserAuthority extends the capabilities of VPN-1 Pro authentication by providing SSO, which eliminates the need for users to authenticate to VPN-1 Pro and provides auditing capabilities for requests to external resources. For more information, see Chapter 5, Outbound Access Control.

OPSEC Protocols
UserAuthority supports all Check Point Open Platform for Security (OPSEC) standards. OPSEC provides a single integration framework by using the OPSEC Software Development Kit (SDK) for integration with Check Point VPN-1 Pro. OPSEC APIs provide solutions for third-party and in-house integration. The UAA (UserAuthority) API set can be used to create a single authorization solution for any application. For example, an enterprise might want to use a single user identification for applications that are not Web-based (such as a client installation) in addition to their Web applications. The UAA OPSEC API enables the integration of any application that requires authentication and authorization, and provides all UserAuthority benefits to the application. Integration can be easily programmed by in-house programmers using the OPSEC APIs. In addition, it is possible to turn to an OPSEC partner to develop a solution for the enterprise. OPSEC partners are a group of professional programmers who use the OPSEC standard. For information on the OPSEC UAA API set, see Chapter 11, UserAuthority OPSEC APIs.

UserAuthority Management Model

Granular administration of UserAuthority allots different administrators or managers various privileges. Work can be divided between administrators according to their specialties.

Chapter 1

Introduction

21

How to Use this Guide

The three types of administrators who administer UserAuthority are: Security Administrator: This administrator is usually the main VPN-1 Pro administrator and is responsible for all security issues in the enterprise. The Security Administrator can monitor and enforce security requirements on the Web server. This provides two advantages: The administrator can set enforcement not only per machine, but according to a specific URL. Because the policy is enforced on the Web server, not the VPN-1 Pro, it is enforced for requests that do not pass through the VPN-1 Pro gateway. Web Security Administrator: This person is responsible for all or most parts of the Web site security as well as the overall security issues related to Web-based applications. This administrator can set rules that have to do with all Web-based security issues, but should not have access to other security issues. These rules are defined in the Web Access tab in Check Points SmartDashboard. Application Manager: This administrator is responsible for specific applications on the Web server. Unlike the Web security administrator, the Application Manager can only change policy for specific URLs as defined in the Web Access tab.

How to Use this Guide

This guide provides step-by-step instructions for configuring UserAuthority. In order to assist you in the deployment of UserAuthority, this guide contains various scenarios that suit the deployments of most enterprises. These scenarios are followed by detailed workflows that can be used to help with your deployment. You can also combine the deployments and workflows described in this guide to best suit the deployment in your enterprise. Please note that Chapter 2 provides the foundation for the deployment of UserAuthority in its most basic form. Subsequent chapters elaborate on these deployments. In addition some configurations have been excluded from these deployments. These configurations can easily be added once your network has been deployed with User Authority.

22

CHAPTER

UserAuthority Deployments and Installation

In This Chapter
Overview Deployments Installation and Configuration page 23 page 25 page 49

Overview
This chapter describes typical UserAuthority deployments and how to install and configure the UserAuthority Server (UAS) and WebAccess components used in the deployments. The following deployments are described in this chapter: UserAuthority for Enterprise Web Applications. This deployment is used when an enterprise wants to implement Web Single Sign-On (SSO). This type of SSO enables users to access multiple Web applications without having to be authenticated each time an application is accessed. For more information on Web SSO, see Chapter 3, Web SSO. Business to Consumer (B2C). This deployment is used when the enterprise needs to implement authorization for Web applications and/or when using a single authentication method for many applications.

23

Overview

In this deployment, an enterprise has many users accessing the network from the Internet. Administrators need to provide specific access rights for each user. Users can be assigned access to specific applications, at specific times, using a specific authentication scheme, and may have different capabilities (such as read-only access). The B2C deployment allows these rights to be easily assigned and managed. For more information, see Chapter 4, Authorization for Web Applications. Outbound Access Control. This deployment is used to provide authorization of users when they access external resources and for monitoring users requests to access external resources. In this deployment, an administrator defines rules that allow users on an internal network to access external systems (for example, Internet or external subnets) without having to repeatedly authenticate to the VPN-1 Pro gateway. In other words, UserAuthority is configured to eliminate the need to authenticate to VPN-1 Pro each time a request for an external resource is made. In addition, each time a request to access an external resource is made, a log entry is created. The administrator can configure UserAuthority to make these logs available, so the administrator can view a list of user activities. For more information, see Chapter 5, Outbound Access Control. UserAuthority installed on Citrix MetaFrame or Windows Terminal Services. This deployment also provides user authorization, auditing and Web SSO. The main difference between this deployment and the Enterprise with Web Applications deployment is that the client computers are connected to a Citrix MetaFrame or Windows Terminal Services. In this case, all users access applications from the same source (the terminal), which has only one IP address. UserAuthority uses port information to get the user identity in order to authorize and/or authenticate the user.

Although each of these deployments can adequately serve an enterprise, it is possible to combine them to create the deployment that best fits the enterprises network. Combining the Deployments on page 45 describes how various components of the deployments can be integrated. The deployments described in this chapter are presented as follows: a general workflow for each process is described; the necessary components for the deployment are given; detailed step-by-step procedures are then described. This chapter also explains how to carry out the basic installations and configurations for the UAS, WebAccess Proxy Server (WAPS), and other components that are necessary to carry out the deployments described in this chapter. The configurations described are the simplest configurations necessary to deploy UserAuthority. In most cases, additional

24

UserAuthority for Enterprise Web Applications

configuration is not required, however, in complex networks, more advanced configurations are possible. These configurations are described in later chapters of this book.

Deployments
In This Section
UserAuthority for Enterprise Web Applications B2C Outbound Access Control Citrix MetaFrame or Windows Terminal Services Combining the Deployments page 25 page 32 page 38 page 42 page 45

This section presents some typical deployments to assist a network administrator in determining the most suitable type of deployment for the enterprises network. This section also describes how the elements in each deployment complement one another and how they can be combined.

UserAuthority for Enterprise Web Applications

This section describes UserAuthority deployment in an Enterprise with Web applications. The users in this example include employees or members of the enterprise, who can access the network from inside the enterprise and/or remotely (with or without a VPN client). In this deployment, UserAuthority: Provides SSO to users, which improves the security and convenience of accessing the enterprise Web application. Enforces security and authorization rules for your organization, which allows only authorized and secure access to the enterprise Web applications. When a user accesses a Web application, WebAccess retrieves the user identity, decides whether the request is authorized, and performs SSO. A network security administrator does not have to search for individual security solutions for each application because Check Points security is transparently integrated with the application. For more information, see Chapter 3, Web SSO.

Chapter 2

UserAuthority Deployments and Installation

25

Deployments

The following components are required for this deployment: UAS installed on the VPN-1 Pro module WAPS installed and located in the DMZ (or segment separated from the local network) or the WebAccess Plug-In (WAPI) installed on each Web server VPN-1 Pro management installed on a gateway or other server SmartDashboard installed on a gateway or other server. At least one Web server Windows Domain Controller (DC) Local Internet Explorer client Remote computer client (with or without VPN client) For information on installing the various components, see For information on installing the various components, see Workflow on page 31. FIGURE 2-1 illustrates the deployment for an enterprise with Web applications.
FIGURE 2-1 Sample Deployment for an Enterprise with Web Applications

In this deployment, when a user requests access to a Web application, the request is routed to the WAPS.

26

UserAuthority for Enterprise Web Applications

UserAuthority WebAccess then queries one or more TIPs to identify the user as follows: VPN-1 Pro gateway: Users who access a network through a VPN tunnel authenticate through the VPN-1 Pro gateway. Windows DC: If the client computers are in a Windows Domain and UAS on the VPN-1 Pro gateway cannot identify the user, WAPS mediates its internal authentication protocol (NTLM) with the Windows DC, enabling WAPS to obtain the user identity that was provided to the Windows Domain in the login process. Citrix or Windows Terminal Services deployments: UAS was on the VPN-1 Pro gateway obtains the user identification from UAS installed on the Terminal Services. UserAuthority WebAccess: In cases where User identity cannot be obtained from another Trusted Identification Point (TIP), authentication takes place according to VPN-1 Pro policy. For more information, see Achieving User Identity on page 101. After identification, WebAccess uses the identity information to: Provide SSO: Credentials required by an application are injected into the applications authentication page on behalf of the user. These credentials are stored in the UserAuthority Credentials Manager. Web SSO is performed in a non-intrusive way that does not require any changes to the key application code. For more information on defining SSO in WebAccess, see Web SSO. Provide authorization: UserAuthority WebAccess matches the identity information to the rules defined in the WebAccess rule base. These rules determine whether the user is authorized to view or work on the requested Web application. For more information, see Chapter 4, Authorization for Web Applications. UserAuthority WebAccess Deployment WebAccess can be deployed in two ways.
UserAuthority WebAccess Proxy Serer (WAPS)

WAPS is deployed on a dedicated machine. All requests for applications on the Web servers in the protected segment of the network are sent to the WAPS. The advantage to this type of deployment is that the WAPS is deployed in a DMZ or similar restricted zone in the LAN. Users requesting access to an application are not allowed to enter an enterprises protected zone before being authenticated and authorized by the WAPS.

Chapter 2

UserAuthority Deployments and Installation

27

Deployments

The WAPS is deployed as a reverse proxy. A reverse proxy is a proxy for the server. In this case the client requests the IP of the proxy, which forwards the request to the WAPS. If the users request is authorized, it is forwarded to the appropriate Web server, which provides the requested Web application. The WAPS has the following security advantages: Authentication takes place outside the enterprises trusted zone. No access is permitted to the trusted zone if the requesting client is not authenticated or authorized. The network is protected from attack because authorization is carried out in a protected zone (DMZ). All outside access is through standard HTTP and HTTPS ports. A client computer only has access to the local network through the WAPS. All authentication is centralized, eliminating the need to configure authentication on each individual Web server in the network and greatly reducing costs. Security can be provided easily because it is necessary to strengthen security at one central point only, and not at multiple points throughout the network. Other advantages of the WAPS include: The WAPS is easy to maintain because it supports multiple Web servers with only one installation. The WAPS supports all Web servers (not only IIS). The WAPS supports Integrated Windows Authentication.
UserAuthority WebAccess Plug-In (WAPI)

WAPI is deployed directly on the Web server that hosts the Web applications. In this case, the request is sent directly to the Web server with the requested Web application and WAPI is configured to intercept all requests so they can be authenticated and authorized. Deploying the WAPI can be advantageous in networks with only a few Web servers. Because the requests are sent directly to the actual Web server, an additional server is not necessary. The WAPI must be configured individually for each Web server. In a network with a large number of Web servers, the WAPI must be installed on each one. This requires a greater amount of effort in terms of initial configuration and maintenance (for example, upgrades). FIGURE 2-2 shows a deployment with the WAPS. This scenario has one Web server, which is located in the DMZ.

28

UserAuthority for Enterprise Web Applications

FIGURE 2-2

Sample Deployment for an Enterprise with an Internal Web Application using UserAuthority WAPI

Note - The WAPI is available for IIS servers only. For other servers, you must use the UserAuthority WAPS.

Note - The WAPI deployment is best used when there is only one Web server or there is no access to the enterprises Web applications from outside the network. The WAPI does not support Integrated Windows Authentication.

Terms in UserAuthority WebAccess Configuration When you install WebAccess, a set of configuration options must be defined. These options are displayed as part of the installation process. Most of the configurations are the same for both the WAPS and the WAPI. However, for the WAPS, you must also configure virtual hosts. Common Suffix Domains are configured when there is more than one Web server in the deployment.
Virtual Hosts

A virtual host is a Web server that holds the Web applications. When you deploy the WAPS, you create a virtual host that defines how internal Web servers are assigned. (For information on how to configure virtual hosts, see Configuring Virtual Hosts on page 84).
Chapter 2 UserAuthority Deployments and Installation 29

Deployments

The network administrator defines the IP address of the server that is published (the WAPS) and maps it to the Web server that holds the pages that are requested (the virtual host). In cases where more than one Web server is used, a different virtual host is defined for each Web server. It is also possible to define rules so that requests to the proxy can be made through SSL and requests to the Web servers are sent by ordinary HTTP. Because the client request is sent directly to the WAPS, the user only sees the address of the WAPS. Any information on the address or IP of the actual page the client requested remains hidden. This is advantageous for security because the requester does not receive information about the original server, which might contain additional sensitive information. FIGURE 2-3 shows an example of the use of virtual hosts.
FIGURE 2-3 Virtual Hosts

In FIGURE 2-3, the following servers are defined using the common suffix .myEnterprise.com: Webserver 1 is defined as webserver1.myEnterprise.com so that all requests to this domain arrive at the proxy and are sent to 10.10.5.2 according to the virtual host definition. Webserver 2 is defined as webserver2.myEnterprise.com so that all requests to this domain arrive at the proxy and are sent to 10.10.5.3 according to the virtual host definition.
Common Suffix Domain

Common Suffix Domains are configured when there is more than one Web server in the deployment. The Common Suffix Domain is the last part of the domain. For example, in the domain a.myEnterprise.com, the suffix domain is myEnterprise.com. Where there is more than one Web server (for example, a.myEnterprise.com and b.myEnterprise.com), the Common Suffix Domain (shared by both domains) is .myEnterprise.com.
30

UserAuthority for Enterprise Web Applications

When a user is identified, UserAuthority WebAccess places a cookie on the client. The cookie contains encoded information that includes the user identity key. The cookie is sent to the Web server for each request and UserAuthority WebAccess uses the cookie identity key to recognize the user making the request. A cookie is sent by the browser if the requested domain includes the cookies domain. UserAuthority WebAccess uses the Common Suffix Domain to make the cookie available to all Web servers in the deployment. When you define a Common Suffix Domain, all domains in the deployment will have the same suffix as is defined in the Common Suffix Domain. In the Common Suffix Domain configuration, you can also define how to handle requests that do not have the common suffix. Workflow The following workflow shows the steps needed to deploy UserAuthority in an enterprise with Web applications. To carry out the deployment: 1 2 Install the UAS on the VPN-1 Pro gateway (see Installing and Configuring UAS on VPN-1 Pro on page 49). Install the WAPS on a separate server. Make sure to configure a virtual host and then indicate a Common Suffix Domain for all the Web servers in the deployment. Make sure to configure WebAccess in SmartDashboard as well. OR If you are deploying the WAPI, install it on each Web server in your deployment. For information on UserAuthority WebAccess installation and configuration, see Installing and Configuring UserAuthority WAPS on page 70 or Installing and Configuring the UserAuthority WAPI on page 80. Configure the deployment to trust Windows Domain as an Identification Point. A If you deploy the WAPS, configure Integrated Windows Authentication (see Configuring Integrated Windows Authentication on page 116. If you deploy the WAPI, install a UAS on the Windows DC, and configure automatic SecureAgent installations (see Installing and Configuring the UAS on the Windows DC on page 61). B If your network includes Citrix/Terminal Services users you need to install a UAS on the Citrix/Terminal Services. See Installing and Configuring the UAS on the Windows DC on page 61. The installation and configuration are the same. You do not need to configure SecureAgent.

Chapter 2

UserAuthority Deployments and Installation

31

Deployments

4 5

Install a basic UserAuthority WebAccess policy. see Configuring a Basic Web SSO Rule on page 85. Manage users in VPN-1 Pro by defining at least one user in a user database and/or connecting to an existing LDAP server. For more information on creating databases, see the instruction guides provided with the database software and hardware. For more information, see Chapter 6, User Management in UserAuthority.

Test Your Deployment 1 Enter your Web site in such a way that you will be recognized by a TIP (for example, from the local network or from SecureClient/SecureRemote). If your application uses HTML form authentication, the application login page should be displayed with a UserAuthority widget. If your application uses basic authentication, a UserAuthority update page should be displayed. Enter your credentials. Close your Web browser. Enter the Web application again in such a way that you will be recognized by a TIP. You automatically enter the application without seeing the login page.
Note - If a WebAccess Authentication page is displayed, a problem has occurred in the identification process. If you wish to test your deployment without TIP identification, see Test Your Deployment on page 37.

2 3 4

B2C
A Business to Customer (B2C) deployment is used by enterprises that offer special services to customers, clients or agents through the Internet. A typical example is a company that sells books or toys and has customers who access the network from the Internet. Security is important in this case because the company database might contain sensitive information, such as customer financial details. It is important that only users authorized to receive specific information can get that information, and only that information. In this deployment, the client computers belong to users who do not belong to the enterprise. They do not have a VPN client, therefore identification is usually carried out by UserAuthority WebAccess. UserAuthority provides two advantages in this type of deployment:

32

B2C

External Authorization Point: The remote users identification is captured by UserAuthority WebAccess. Thereafter, UserAuthority WebAccess performs authentication to the Web application on behalf of the user. Single Sign-On: Users are authorized without having to authenticate to each application that they request, and only authorized users can access the enterprises Web applications.

Authorization policy answers the following criteria: Who can do what and when it can be done. How a Web site or application can be accessed. A network administrator first sets an authorization policy in UserAuthority that determines who can access applications, which applications they can access, and how they can access them (i.e., read-only access or full access). It is also possible to determine when a user has read-only access or even when they cannot access the application. The authorization policy determines how an application is accessed, for example, whether access can be made over a non-secure connection or only over an SSL-secured connection. UserAuthority provides the means to implement authorization policy on an application level. This means that users can only access those applications to which they are specifically given access. Therefore, not all users who have permission to cross the WAPS can access the same information. This is important for enterprises that provide sensitive information, such as personal medical information or bank account information. Users can sign on and gain access to the network, but depending on their authorization rights, they can only gain access to their own information. For more information on Authorization for Web Applications, see Chapter 4, Authorization for Web Applications. The following components are required for this deployment: UAS installed on a VPN-1 Pro module. (A third-party firewall gateway can be used, in this case the VPN-1 Pro module is installed on the same machine as UserAuthority WebAccess. See FIGURE 2-5.) WAPS installed and located in a DMZ (or segment separate from the local network) or WAPI installed on each Web server. (For a description of WAPS and WAPI and the differences between them, see UserAuthority WebAccess Deployment on page 27). VPN-1 Pro management installed on a gateway or other server. SmartDashboard installed on a gateway or other server. At least one Web server.
Chapter 2 UserAuthority Deployments and Installation 33

Deployments

An internal network if necessary for maintaining the Web site.

For information on installing the various components, see Workflow on page 31. FIGURE 2-4 shows a B2C deployment with multiple Web servers and WAPS located in the DMZ:
FIGURE 2-4 B2C Deployment

In this deployment, remote users connect to the system through UserAuthority WebAccess. FIGURE 2-4 shows the system deploying the WAPS in the DMZ. It is also possible to deploy a WAPI on each of the Web servers. In this case, a separate WAPS is not necessary. The WAPS configuration is recommended because fewer UserAuthority WebAccess installations are necessary, and it assures that no user can access the applications Web servers without being authenticated. For more information on the advantages of deploying both types of UserAuthority WebAccess, see UserAuthority WebAccess Deployment on page 27.

34

B2C

For security reasons, the WAPS is typically located on a segment separate from the Web servers. This is usually in a DMZ, however, the network administrator can deploy the network in whatever configuration best fits the enterprise. This includes configurations where the WAPS is deployed on the same segment as the Web servers. Security is achieved by defining VPN-1 Pro policy so that all access to the network passes through UserAuthority WebAccess. UserAuthority WebAccess authenticates the client using a defined authentication process. The first time a user accesses the system, an HTML authentication page is displayed requesting the user credentials. For the remainder of the session, UserAuthority WebAccess remembers the user identity. It is also possible to configure the network so that a user does not have to enter credentials for successive sessions, if logging on from the same client. A B2C deployment can be deployed with a third-party (non-Check Point) firewall. In this case, the VPN-1 Pro module is installed as a secure server on the same computer as the UAS and WebAccess. FIGURE 2-5 shows how UserAuthority is deployed when using a third-party firewall:
FIGURE 2-5 B2C Deployment with Third-Party Firewall Gateway

Chapter 2

UserAuthority Deployments and Installation

35

Deployments

In the B2C deployment, the following takes place: 1 2 3 The user accesses the companys Web resources using a Web browser. When the user accesses a Web resource for the first time, the VPN-1 Pro allows the request to arrive at UserAuthority WebAccess, which asks for the users identity. UserAuthority WebAccess queries the UAS on the VPN-1 Pro gateway for the users identity. If UserAuthority already knows the users identity (from a TIP, such as a VPN tunnel or Windows domain), the identity is passed back to UserAuthority WebAccess for authorization. If the identity is unknown, UserAuthority WebAccess sends an authentication page and requests the users identification information. UserAuthority WebAccess then matches the user against the defined UserAuthority WebAccess rules. Users who match the defined rules are authorized to access the requested Web resource and are provided with SSO. For more information on configuring authorization rules, see Chapter 4, Authorization for Web Applications.

4 5

Workflow To carry out the deployment: 1 Install the UAS on the VPN-1 Pro gateway. (If you are using a third-party firewall, install UAS on the same computer as UserAuthority WebAccess.) For more information, see Installing and Configuring UAS on VPN-1 Pro on page 49. Install the WAPS on a separate server. Make sure to configure a virtual host and then indicate a Common Suffix Domain for all the Web servers in the deployment. OR If you are deploying the WAPI, install it on each Web server in your deployment. Make sure to configure WebAccess in SmartDashboard as well. For information on UserAuthority WebAccess installation and configuration, see Installing and Configuring UserAuthority WAPS on page 70 or Installing and Configuring the UserAuthority WAPI on page 80. Install a default UserAuthority WebAccess policy, see Configuring a Basic Web SSO Rule on page 85. Manage users in VPN-1 Pro by defining at least one user in a user database and/or connecting to an existing LDAP server. For more information on creating databases, see the instruction guides provided with the database software and hardware. For more information, see Chapter 6, User Management in UserAuthority.

3 4

36

B2C

Test Your Deployment 1 Enter your Web site. A WebAccess authentication page is received.
WebAccess Authentication Page FIGURE 2-6

Enter the credentials for the WebAccess User. If your application uses HTML form authentication, the application login page is received with a UserAuthority widget. Enter your credentials for the application Close your Web browser. Enter your Web site. A WebAccess authentication page is received. Enter the credentials for the WebAccess User. You automatically enter the application without seeing the login page.

3 4 5 6

Chapter 2

UserAuthority Deployments and Installation

37

Deployments

Outbound Access Control

Outbound Access Control deployment is used to provide authorization and auditing for users accessing external resources. When clients access the Internet from inside a local network, UserAuthority captures authentication information from a TIP (for example, VPN-1 Pro, Windows DC), which eliminates the need to authenticate to VPN-1 Pro in order to achieve identity-level authorization and auditing. Outbound Access Control deployment provides: Single Sign-On to VPN-1 Pro for local clients by eliminating the need to authenticate each time the user goes through VPN-1 Pro Auditing capabilities by providing a log of each user request to an external resource Authorization capabilities The following components are required for the deployment: UAS installed on the VPN-1 Pro module. UAS installed on at least one Windows DC. VPN-1 Pro management installed on a gateway or other server. SecureAgent installed on each client. This installation is performed automatically when a client signs on to the Windows Domain. For information on installing the various components, see Workflow on page 39. For more information on Outbound Access Control, see Chapter 5, Outbound Access Control. For information on installing VPN-1 Pro, the management applications, or SmartDashboard, see the Check Point SmartCenter Guide. FIGURE 2-7 shows a deployment that provides Outbound Access Control.
FIGURE 2-7 Outbound Access Control Deployment

In this deployment, the following takes place: 1

38

The user signs on to the Windows DC, and logs into the client host.

Outbound Access Control

2 3 4

When the user accesses an external resource for the first time, the VPN-1 Pro module queries the user identity through the UAS on the module. The query is then forwarded to the UAS on the Windows DC. The UAS on the Windows DC checks the client credentials through the SecureAgent module on the client desktop.

For more information about Single Sign-On for VPN-1 Pro, see Chapter 5, Outbound Access Control. Workflow To carry out the deployment: 1 2 3 4 Install the UAS on the machine with the VPN-1 Pro gateway (see Installing and Configuring UAS on VPN-1 Pro on page 49). Install the UAS on the Windows DC (see Installing and Configuring the UAS on the Windows DC on page 61). Configure the system to automatically install SecureAgent (see Configuring SecureAgent Automatic Installation on page 68). From the SmartDashboard SSO Rule on page 39).
Security

tab, configure an SSO rule (see Adding an

Test Your Deployment Try to access an external resource. Make sure that you can enter the resource without getting an authentication request from the VPN-1 Pro. Adding an SSO Rule In this deployment, you must establish SSO for VPN-1 Pro users accessing external resources. This section describes how to configure an SSO rule. This configuration is carried out in the SmartDashboard. For more information on using SmartDashboard, see the Check Point SmartCenter Guide. To create an SSO rule: 1 2 3 From SmartDashboard, click the Click the
Add Rule Security

tab.

button in the tool bar to add a blank rule line.

In the new rule, right click the Source field to add a source. Click Add Users Access and select the Users Group that you want to use for this rule. For a basic SSO rule, you can keep the Any default.

Chapter 2

UserAuthority Deployments and Installation

39

Deployments

4 5 6 7 8

Right click the Destination field, and add a destination. This is the destination to which the rule will apply. For a basic SSO rule, you can keep the Any default. Right click the VPN field to enter the VPN match conditions. For a basic SSO rule, you can keep the Any Traffic default. Right click the Service field to determine the types of services that apply to this rule. For a basic SSO rule, you can keep the Any default. Right click the Action field and then click for this deployment. Double click the window.
Action Client Auth

from the menu to create SSO

field to display the

Client Authentication Action Properties

FIGURE 2-8

Client Authentication Action Properties Window - General Tab

In the

Sign On Method

area, click

Single Sign On.

10 Click the Limits tab and set the timeout to determine how long a session lasts. It is recommended to keep the default timeout limit of 30 minutes. If you do not want UserAuthority to count the time that a user is working, select the Refreshable timeout checkbox.

40

Outbound Access Control

FIGURE 2-9

Client Authentication Action Properties Window - Limits Tab

11 In the Number of Sessions Allowed area, set the number of connections that can be made before querying for user identity. It is recommended to enter 1 for security reasons, however some Web sites that use HTTP 1.0 protocol count sessions for each link that is clicked, therefore it may be best to use a higher number to save system resources. 12 Click
OK

to close the window and return to the SmartDashboard

Security

tab.

13 In the Security tab, right click the Track field to select how you want to keep track of user requests in the system. It is recommended to select Log to provide auditing capabilities. 14 In the Security tab, right click the Install on field and select Add from the drop-down menu, and select the location where the policy is installed. For a basic SSO rule, you can keep the Policy Targets default. 15 Click
Install

on the toolbar to install the policy.

Chapter 2

UserAuthority Deployments and Installation

41

Deployments

The following is an example of an SSO policy in the SmartDashboard:

FIGURE 2-10 Basic SSO Rule

Citrix MetaFrame or Windows Terminal Services

This deployment is intended for networks where the local host clients are, or include, Citrix MetaFrame Server or Windows Terminal Services. This deployment provides authorization and auditing capabilities for the users signing on to a Citrix or Windows terminal. In this deployment, the UAS is installed on the MetaFrame Server or Terminal Services. UAS on the Terminal Services identifies the user for each outbound request from the server. This can be used for auditing and authorization. This deployment can be used by any of the enterprises listed in the deployments described in this chapter.
This deployment can be used in combination with non-terminal computers or with Web SSO scenarios. For more information on combining the basic deployments, see Combining the Deployments on page 45.

The following components are required for this deployment: UAS installed on the VPN-1 Pro module UAS installed on the Citrix MetaFrame Server or Terminal Services VPN-1 Pro management For information on installing the various components see Workflow on page 43. For more information on Outbound Access Control, see Chapter 5, Outbound Access Control. For information on installing VPN-1 Pro, the management applications, or SmartDashboard, see the Check Point SmartCenter Guide.

42

Citrix MetaFrame or Windows Terminal Services

FIGURE 2-11 shows UserAuthority deployed in a Citrix or Windows Terminal Services system.
FIGURE 2-11 Citrix MetaFrame or Windows Terminal Services Deployment

In this deployment: 1 2 3 The user signs on to the Citrix MetaFrame Server or the Terminal Services, and logs into the client host. When the user accesses an external resource for the first time, the VPN-1 Pro module queries for the user identity through the UAS on the module. The query is then forwarded to UAS on the Citrix MetaFrame Server or the Terminal Services. The user is identified and the identification information is forwarded to VPN-1 Pro to authorize and audit the request.

Workflow To carry out the deployment: 1 2 3 4 Install the UAS on the machine with the VPN-1 Pro gateway (see Installing and Configuring UAS on VPN-1 Pro on page 49). Install the UAS on the Citrix MetaFrame Server or Terminal Services (see Installing and Configuring the UAS on the Windows DC on page 61). From the SmartDashboard Security tab, configure an SSO rule (see Adding an SSO Rule for Citrix MetaFrame or Windows Terminal Services on page 44). Save the policy in SmartDashboard and install the firewall policy on the VPN-1 Pro gateway where UserAuthority installed.

Test Your Deployment Try to get an external resource. Attempt to enter the resource without getting an authentication request from the VPN-1 Pro.

Chapter 2

UserAuthority Deployments and Installation

43

Deployments

Adding an SSO Rule for Citrix MetaFrame or Windows Terminal Services An SSO rule for Citrix MetaFrame or Windows Terminal Service is created in the same way as for Outbound Access Control, except that the SSO rule must be applied through session authentication instead of client authentication. This is because the browser and other applications are on the server and many different clients may be using them. This section describes how to configure an SSO rule. This configuration is carried out in the SmartDashboard. For more information on using SmartDashboard see the Check Point SmartCenter Guide. To create an SSO rule: 1 2 3 4 5 6 7 8 From SmartDashboard, click the Click the
Add Rule Security

tab.

button in the tool bar to add a blank rule line.

Source

In the new rule, right click the you can keep the Any default.

field to add a source. For a basic SSO rule,

Right click the Destination field, and add a destination. This is the destination to which the rule will apply. For a basic SSO rule, you can keep the Any default. Right click the VPN field to enter the VPN match conditions. For a basic SSO rule, you can keep the Any Traffic default. Right click the Service field to determine the types of services that apply to this rule. For a basic SSO rule, you can keep the Any default. Right click the Action field and then click SSO for this deployment. Double click the window.
Action Session Auth

from the menu to create

field to display the

Session Authentication Action Properties

44

Combining the Deployments

FIGURE 2-12 Session Authentication Action Properties Window

Select the
OK

Single Sign On

checkbox.
Security

10 Click

to close the window and return to the SmartDashboard

tab.

11 Right click the Track field in the rule line to select how you want to keep track of user requests in the system. It is recommended to select Log to provide auditing capabilities. 12 Right click the Install on field in the rule line and from the Add the drop-down menu, select where the policy is installed. For a basic SSO rule, you can keep the Policy Targets default. 13 Click
Install

on the toolbar to install the policy.

Combining the Deployments

In many enterprises, it is necessary to deploy the system for both Web SSO and Outbound Access Control. It is also possible to have a combination of desktop PCs and Citrix or Terminal desktops. The deployments described in this chapter can be combined to provide a deployment that best fits the computers and users in your enterprise. A typical combined deployment is the same as the deployment for an enterprise with Web applications, with the addition of a Windows DC with the UAS and SecureAgent installed on all the desktops.

Chapter 2

UserAuthority Deployments and Installation

45

Deployments

If there are any Citrix or Terminal machines in the network, you must also install the UAS on the Citrix MetaFrame Server or the Terminal Services. If only Citrix or Terminal machines are used, there is no need to use a Windows DC. You must also include at least one Web server in the deployment and install UserAuthority WebAccess and the VPN-1 Pro gateway. The following example is for a network that includes both desktop PCs and Citrix or Terminal machines. This deployment includes both Web SSO and Outbound Access Control options. The following components are required for this deployment: UAS installed on the VPN-1 Pro module WAPS installed and located in the DMZ (or segment separate from the local network) or WAPI installed on each Web server VPN-1 Pro management installed on a gateway or other server SmartDashboard installed on a gateway or other server At least one Web server Local client computers with SecureAgent installed Remote computers with a VPN client such as SecuRemote or SecureClient Remote computers without a VPN client UAS installed on the Window DC and/or UAS installed on the Citrix MetaFrame Server or Terminal Services For information on installing the various components, see Workflow on page 329. For information on installing VPN-1 Pro, the management applications, or SmartDashboard, see the Check Point SmartCenter Guide. FIGURE 2-13 shows a combined deployment:

46

Combining the Deployments

FIGURE 2-13 Combined Deployment

In this deployment, the following takes place: 1 2 The user signs on in one of the ways described in the previous deployments. When the user accesses a resource for the first time, the appropriate module (VPN-1 Pro or UserAuthority WebAccess depending on the resource) queries the UAS for the user identity. The UAS identifies the user through a trusted identity point (Windows DC, VPN-1 Pro, UserAuthority WebAccess, Terminal Services). Once the identity is known, the appropriate module can carry out the requested service (for example, SSO, authorization, auditing).

3 4

For further information, see the other deployments described in this chapter. Workflow To carry out the deployment: 1 Install the UAS on the VPN-1 Pro gateway (see Installing and Configuring UAS on VPN-1 Pro on page 49).

Chapter 2

UserAuthority Deployments and Installation

47

Deployments

Install the WAPS on a separate server. Make sure to configure a virtual host and then indicate a Common Suffix Domain for all the Web servers in the deployment (for example, myEnterprise.com). Make sure to configure WebAccess in the SmartDashboard as well. OR If you are deploying the WAPI, install it on each Web server in your deployment. For information on UserAuthority WebAccess installation and configuration, see Installing and Configuring UserAuthority WAPS on page 70 or Installing and Configuring the UserAuthority WAPI on page 80. Install the UAS on the Windows DC (if you are using any desktop PCs) and/or Install the UAS on the Citrix MetaFrame Server or Terminal Services (if you are using any Citrix or Terminal machines). See Installing and Configuring the UAS on the Windows DC on page 61. If you install UserAuthority on the Windows DC, configure the system to automatically install SecureAgent on the client hosts. Manage users in VPN-1 Pro by defining at least one user in the internal database or LDAP server.

4 5

Test Your Deployment Test the various components of your deployment as described in Test Your Deployment on page 32, Test Your Deployment on page 37, and Test Your Deployment on page 43.

48

Installing and Configuring UAS on VPN-1 Pro

Installation and Configuration

In This Section
Installing and Configuring UAS on VPN-1 Pro Installing and Configuring the UAS on the Windows DC Installing and Configuring UserAuthority WAPS Installing and Configuring the UserAuthority WAPI Configuring Virtual Hosts page 49 page 61 page 70 page 80 page 84

This section provides step-by-step directions for the installations and configurations necessary to deploy UserAuthority.

Installing and Configuring UAS on VPN-1 Pro

The following components are required to install the UAS on the firewall gateway: VPN-1 Pro module installed on a gateway or other server VPN-1 Pro management installed on a gateway or other server SmartDashboard For information on how to use and install these products, see the appropriate Check Point user guide. The installation process comprises the following steps: Install the UserAuthority License Install the UAS software on the VPN-1 Pro gateway Configure the UAS Configure UAS domain equality Installing the UserAuthority License UserAuthority requires a license per client (user), not per server. You can retrieve a license from the Check Point User Center at www.checkpoint.com/usercenter after the software is purchased. Licences can be stored and maintained in the SmartUpdate repository. For more information on SmartUpdate, see the Check Point SmartCenter Guide. Licenses created in the Check Point User Center include: IP address: IP address of the computer for which the license is intended. Certificate Key: A string of twelve alphanumeric characters.
Expiration date

Chapter 2

UserAuthority Deployments and Installation

49

Installation and Configuration

SKU/Features:

The character string that defines an individual license. The string for UserAuthority is: CPUA-UAU-*-NG, where * is the number of licenses (i.e., the number of users).

The license can be installed using the Check Point Configuration tool. The validation code supplied by the Check Point User Center should be compared with the validation code calculated in the Check Point Configuration Tool. These strings should be identical. For information on using the Check Point Configuration tool to install a license, see the Check Point SmartCenter Guide. Installing UAS on the VPN-1 Pro Gateway
Windows

Before installing the UAS, be sure that SVN Foundation and VPN-1 Pro are installed. If they are not installed, see the instructions in the Check Point SmartCenter Guide. To install UAS on a Windows gateway: 1 Insert the Wrapper CD and then run the Wrapper. The Installation window is displayed.
Welcome

50

Installing and Configuring UAS on VPN-1 Pro

FIGURE 2-14 Installation Welcome Window

Click

Next

to display the End-Users License Agreement (EULA).

Chapter 2

UserAuthority Deployments and Installation

51

Installation and Configuration

FIGURE 2-15 End Users License Agreement

3 4 5

Read the End-Users License Agreement (EULA) and then click The next installation window is displayed.

Yes

to accept it.
Next.

Select Check Point Enterprise for the type of installation, and then click next installation window is displayed. Select
UserAuthority

The

from the list of CheckPoint products.

Note - If the VPN-1 Pro module and other gateway components are not installed, you can install them at the same time by selecting them in the Product Selection list. If already installed, the checkbox is selected and grayed as shown in FIGURE 1-16.

52

Installing and Configuring UAS on VPN-1 Pro

FIGURE 2-16 Product Selection

6 7 8 9

Click

Next

to start the

Install Shield

and follow the on-screen instructions.

UserAuthority,

Browse to a folder where you want to install in the default folder. At the end of the installation, click
OK.

or click

Next

to install

If VPN-1 Pro is already installed on the machine, then this is the end of the installation. Restart your computer to finish the installation. After the restart, you must add the UserAuthority license (see Installing the UserAuthority License on page 49). OR, If VPN-1 Pro is not installed, the License window is displayed. If your license is not listed in the window, you must install a license to continue (see Installing the UserAuthority License on page 49).

Chapter 2

UserAuthority Deployments and Installation

53

Installation and Configuration

10 Click Next. If there are no other Check Point installations on the computer, you must enter information in the Key Hit Session and the Secure Internal Communication (SIC) windows. If other applications are already installed, skip to step 11 on page 54. A Click Next, if there are no other Check Point installations on the computer, the Key Hit Session window is displayed. Follow the directions in the window and then click Next. B The Secure Internal Communication window is displayed. Enter a password key in the Activation Key field and then enter it again in the Confirm Activation Key field to confirm it. Be sure to remember your key, you need to enter it in the SmartDashboard configuration.
Note - If you have already installed VPN-1 Pro, you do not need to configure the Key Hit session or SIC. If these windows are displayed on the computer, skip these steps.

11 Click 12 Click

Finish. OK.

The

Thank you for using

message is displayed.

13 Remove the CD and then click

UNIX/Linux-based Platforms

Finish

to restart the computer.

The following software should be installed before installing UAS: Check Point SVN Foundation (most current version) Check Point VPN-1 Pro (most current version). For information on installing VPN-1 Pro, see the Check Point SmartCenter Guide. To install UserAuthority on a UNIX/Linux-based machine: 1 2 Insert the Wrapper (package) in the machines CD drive. Turn on the machine (the machine should be configured to boot from the CD drive). Follow the on-screen instructions. For information on the configurations necessary for the installation, including establishing SIC, see the section on Windows on page 332. Although the GUI interface is different, the procedure is the same. Note that if you have already installed the VPN-1 Pro, establishing SIC is not necessary. Use the Check Point Configuration Tool to install a license on the SmartCenter machine (see Installing the UserAuthority License on page 49). For information on the Check Point Configuration Tool, see the Check Point SmartCenter Guide.

54

Installing and Configuring UAS on VPN-1 Pro

Configuring the UAS You now need to configure UAS using SmartDashboard. For more information on SmartDashboard, see the Check Point SmartCenter Guide. FIGURE 2-17 shows the SmartDashboard in the Tree pane.
Main

window with the

Network Objects

tree

FIGURE 2-17 SmartDashboard Network Objects

To configure the UAS: 1 2 From the SmartDashboard Policy menu, select Properties window is displayed. In the Tree pane, click window.
UserAuthority Global Properties.

The

Global

to display the

UserAuthority Properties

Chapter 2

UserAuthority Deployments and Installation

55

Installation and Configuration

FIGURE 2-18 Global Properties Window (UserAuthority Properties)

Select the Display Web Access view checkbox. This displays the Web Access tab in SmartDashboard. If your deployment does not include the WAPS, this step is optional. Click OK. Create a new network object. (Carry out this step only if a network object for the VPN-1 Pro gateway has not already been created. If a network object has already been created, skip to step 6 on page 58): A In the SmartDashboard Network Objects tree, right click Network Objects. From the shortcut menu, select New > Check Point > Gateway. The Check Point Gateway window is displayed. B In the Name field, enter the name of the firewall gateway where the UAS is installed.

56

Installing and Configuring UAS on VPN-1 Pro

C Enter the IP address for the firewall gateway in the D From the
Version

IP Address

field.

drop-down list, select

NG with Application Intelligence.

E From the list of Check Point products, select UserAuthority Server. (You may have to scroll down the list to find UserAuthority Server.)
Note - If you did not select Display Web Access view in step 3 and you are not using UserAuthority WebAccess in your deployment, ignore the error message displayed. If you are using UserAuthority WebAccess in your deployment and a UserAuthority WebAccess error message is displayed, go to step 3 to and select Display Web Access view in the User Authority tab of the Global Properties window.

Establish SIC: A In the Secure Internal Communication area of the Check Point Gateway window, click Communication to display the Communication window.

FIGURE 2-19 Communication window

B In the Activation Key field, enter the Activation Key that you created when you configured the SIC Policy (see Installing UAS on the VPN-1 Pro Gateway on page 50, step B on page 54). C Enter the Activation Key again in the
Confirmation

field.

Chapter 2

UserAuthority Deployments and Installation

57

Installation and Configuration

D Click Initialize. If the operation is successful, the words Trust state field.

Trust established

are displayed in the

Note - If the SIC operation is not successful, click Reset and reset the SIC on the UAS. Try again. Verify that you are entering the correct SIC Activation Key.

E Click 6

Close

to return to the

Check Point Gateway

window.

Add UAS to an existing VPN-1 Pro network object. If you added a network object and initiated SIC in step 4 and step 5, then skip to step 7 on page 59. A Double click the VPN-1 Pro network object in the the Tree pane.
Network Objects

tree in

B From the list of Check Point products, select UserAuthority Server. (You may have to scroll down the list to find UserAuthority Server.) UserAuthority is displayed in the Tree pane of the Check Point Gateway window. The Check Point Gateway window should resemble FIGURE 2-20.

58

Installing and Configuring UAS on VPN-1 Pro

FIGURE 2-20 Check Point Gateway Window

Click UserAuthority Server in the Tree pane of the Check Point Gateway window to open the UserAuthority host window. Leave the default Automatic Configuration chaining option selected. This automatically sets up your deployment for chaining. For information on advanced chaining options, see Web SSO with Manual Identity Sharing on page 111. The UserAuthority Server window should resemble FIGURE 2-21.

Chapter 2

UserAuthority Deployments and Installation

59

Installation and Configuration

FIGURE 2-21 Shared Identity Options

Click

OK

to close the window.

For information on the manual chaining options, see Configuring Manual Identity Sharing Options on page 125.

60

Installing and Configuring the UAS on the Windows DC

Installing and Configuring the UAS on the Windows DC

For deployments where the Windows DC is used to identify clients on the network, you need to install the UAS as a stand alone module on the Windows DC. The UAS is used for administration and enforcement of user authentication for the enterprises network.
Note - The UAS can be installed on any computer in the domain.

The following components are required for this installation: VPN-1 Pro module installed on a gateway or other server VPN-1 Pro management installed on a gateway or other server SmartDashboard UAS installed on a VPN-1 Pro gateway The following steps are required to install and configure the UAS on the Windows DC: Install UAS Configure SIC policy Configure SecureAgent automatic installation Configure the UAS properties Add an SSO rule Installing the UAS
Note - This installation automatically includes the Secure Virtual Network (SVN) Foundation.

To install the UAS: 1 2 Insert the Wrapper CD and then run the Wrapper. The Installation window is displayed. Click
Next. Welcome

The End-Users License Agreement (EULA) is displayed.

Chapter 2

UserAuthority Deployments and Installation

61

Installation and Configuration

FIGURE 2-22 Licence Agreement

3 4 5 6

Read the End-Users License Agreement (EULA) and then click The next installation window is displayed.

Yes

to accept it.
Next.

Select Check Point Enterprise/Pro as the type of installation, and then click The next installation window is displayed. Select
New Installation

and click

Next.

The next installation window is displayed.

Select UserAuthority from the list of Check Point products. Clear all other checkboxes.

62

Installing and Configuring the UAS on the Windows DC

FIGURE 2-23 Product Selection for UserAuthority on the Windows DC

7 8

Click Next to start the Install Shield. A list of the products you selected to install is displayed. UserAuthority should be the only product listed. Follow the on-screen instructions. You should be aware of the following: The SVN Foundation is installed automatically. If you are installing UAS on a Citrix or Terminal Services (not on a Windows DC), select Citrix/Terminal Services in the Setup Type window.

Chapter 2

UserAuthority Deployments and Installation

63

Installation and Configuration

FIGURE 2-24 Setup Type

Click

Next,

the next window is displayed.

UserAuthority,

10 Browse to the folder in which you want to install install in the default folder. 11 At the end of the installation, click
OK.

or click

Next

to

The

License

window is displayed.
Next

12 You do not need a license for UAS on the Windows DC. Click Yes when the warning You have no licenses is displayed. 13 The Key HIt click Next.
Session

and then click

window is displayed. Follow the on-screen instructions and

14 The Secure Internal Communication (SIC) window is displayed. Enter a password key in the Activation Key field and then enter it again in the Confirm Activation Key field. Be sure to remember your key, you will need to enter it in the SmartDashboard configuration. 15 The
Thank you for using...

message is displayed. Click

Finish

OK.

16 Remove the CD and then click

to restart the computer.

64

Installing and Configuring the UAS on the Windows DC

17 If you installed the UAS on another machine in the Windows Domain instead of on the Windows DC, you need to configure the uatcs-acl.txt file. A Open the uatcs-acl.txt file in Windows WordPad. B Edit the following file parameters: [hostname]: The host name of the UAS [ipaddress]: The IP address of the UAS [port]: The UAS UDP source port (this should always be 19195) The following is an example of a uatcs-acl.txt file configured to accept queries from a Windows DC with the name DC, IP address 10.0.0.2, and port number 19195.
# #hostname # DC ipaddress 10.0.0.2 port 19195

C Save and close the file. Configuring UAS Properties You need to configure the UAS using SmartDashboard. For more information on how to use SmartDashboard or if it is not installed on the management server, see the Check Point SmartCenter Guide. FIGURE 2-25 shows the SmartDashboard in the Tree pane.
Main

window with the

Network Objects

tree

Chapter 2

UserAuthority Deployments and Installation

65

Installation and Configuration

FIGURE 2-25 SmartDashboard Network Objects

To configure the UAS: 1 Create a new network object: A In the SmartDashboard Network Objects tree, right click Network Objects. From the shortcut menu, select New > Check Point > Host. The Check Point Host window is displayed. B In the Name field, enter the name of the Windows DC (or other computer in the domain) where UAS is installed. C Enter the IP address for the Windows DC in the D From the
Version IP Address

field.

drop-down list, select

NG with Application Intelligence.

E From the list of Check Point products, select UserAuthority Server. (You may have to scroll down the list to find UserAuthority Server.)
Note - In the event that an alert about the UserAuthority WebAccess rule base is displayed, ignore it and continue.

66

Installing and Configuring the UAS on the Windows DC

Establish SIC: A In the Secure Internal Communication area of the Check Point Host window, click Communication to display the Communication window.

FIGURE 2-26 Communication Window

B In the Activation Key field, enter the Activation Key that you created when you configured the SIC Policy (see Installing the UAS on page 61, step 14 on page 64). C Enter the Activation Key again in the
Confirmation

field. are displayed in the

D Click Initialize. If the operation is successful, the words Trust state field.

Trust established

Note - If the SIC operation is not successful, then click Reset and rest the SIC on the UAS and on the Windows DC. Try again. Verify that you are entering the correct SIC Activation Key.

E Click Close to return to the Check Point Host window. The Windows DC Host window should resemble FIGURE 2-27.

Chapter 2

UserAuthority Deployments and Installation

67

Installation and Configuration

FIGURE 2-27 New Windows DC Window

3 4

Click

OK

to close the

Check Point Host

window.

Save and install the policy on the VPN-1 Pro where the UAS is installed.

Configuring SecureAgent Automatic Installation UserAuthority can be configured to automatically install SecureAgent on the client at startup using a Windows logon script. The logon scripts must be in a Windows DC folder called NETLOGON Share. If you installed the UAS on another machine in the Domain instead of on the Windows DC, copy the files listed in TABLE 2-1 on page 69 to the NETLOGON directory on the Windows DC.

68

Installing and Configuring the UAS on the Windows DC

If a logon script exists, modify it so that it also runs instuac.bat. If there is no logon script, perform one of the following procedures. On Windows 2000 with Active Directory: 1 2 3 4 5 6 From the
Control Panel,

double click

Administrative Tools.

Double click

Active Directory Users and Computers. Properties

In the Tree pane, right click a user name and then click The Properties window is displayed. Click the In the Click
Profile

from the menu.

tab. field, enter uatcs.bat.

Logon script OK

to close the window.

FIGURE 2-28 User Profile Login Script

On Windows NT: 1 2 3 4 5 6 7 From the

Control Panel,

double click

Administrative Tools.

Double click

User Manager for Domains.

Select the name of a user. From the In the In the Click

User

menu, select

Properties

to display the
Profile

User Properties

window.

User Properties Logon script OK

window, click the

tab.

field, enter uatcs.bat.

to close the window.

The following files are installed in the NETLOGON share folder:

TABLE 2-1

NETLOGON Share Files

Instuac.exe uatc.exe

The SecureAgent installation and uninstall program. The SecureAgent executable.

Chapter 2

UserAuthority Deployments and Installation

69

Installation and Configuration

TABLE 2-1

NETLOGON Share Files

uatcs.bat uatcs_uninstall.bat uatcs-acl.txt

A batch file that runs instuac.exe with some parameters to install SecureAgent. A batch file that runs instuac.exe to uninstall SecureAgent. An access list that determines to which UASes the SecureAgent responds.

You can also adjust the SecureAgent installation mode. By default, uatcs.bat installs SecureAgent with a GUI, a log file and a shortcut to the Start menu. You can make changes to the file using the following parameters.
TABLE 2-2

uatcs.bat Parameters

/help or/? /norun /shortcut /uninstall /uatcfile <filename> <args>

Displays the usage. Do not run after installation. Installs a shortcut in the Uninstalls SecureAgent. Installs <filename>. Passes specific arguments to the SecureAgent executable file (see following parameters). Runs SecureAgent with the icon displayed in the task bar system tray. Prints system information into a SecureAgent log file (uatc.log). The file is located in the same directory as SecureAgent. Stops SecureAgent. Does not perform Windows DC auto-discovery. (This option should not be selected because it allows SecureAgent to accept queries from any source.)
Start

menu.

/icon

/debug

/kill /nodiscover

Installing and Configuring UserAuthority WAPS

Check Point UserAuthority WebAccess is used for the administration and enforcement of authorization access policies (Web Access policies) for Web applications. You need to install UserAuthority WebAccess if your deployment includes Web-based applications. After you complete the installation, configure the UserAuthority WebAccess properties.
70

Installing and Configuring UserAuthority WAPS

Installing UserAuthority WAPS The WAPS is installed in a DMZ or separate network segment for most deployments. You can have more than one WAPS. The following components are required for this installation: VPN-1 Pro module installed on a gateway or other server VPN-1 Pro management installed on the gateway or other server SmartDashboard UAS installed on a VPN-1 Pro module For more information on how to install these components, see the Check Point SmartCenter Guide. For more information on how to install the UAS, see Installing and Configuring UAS on VPN-1 Pro on page 49. To install WAPS: 1 2 Insert the SmartSuite CD ROM. Turn off the computer.
Note - Be sure to insert the CD-ROM before turning on your computer. The computer should be configured to boot from the CD-ROM drive.

Turn on the computer. The following message is displayed:

Welcome to Check Point NG with Application Intelligence

Press Enter to start the installation. A message is displayed indicating that the installation is taking place, and then the SecurePlatform Installation page is displayed. Follow the on-screen instructions. Use the Tab key to move between fields and the Enter key to make selections.
Warning - Installing the SmartPlatform (UserAuthority WAPS) replaces all contents on your computer.

5 6

When prompted to indicate the type of system to install, select

WebAccess.

Select Enterprise only if you are installing UserAuthority WebAccess and VPN-1 Pro together. For more information on VPN-1 Pro installation, see the appropriate Check Point user guide.

Chapter 2

UserAuthority Deployments and Installation

71

Installation and Configuration

7 8

Enter the correct IP address for your server and the netmask. Select All contents on your computer are replaced. At the end of the installation, remove the CD ROM and select computer. When prompted, log in and configure the WAPS.
OK

OK

to install.

to restart the

Tip - To ensure that you load the correct version, allow the computer to select the product version by default when rebooting.

Configuring UserAuthority WAPS After you install the WAPS and reboot the computer, you must configure the WAPS. To configure the WAPS you must: configure the IP address for the WAPS configure the WAPS host name configure the computer domain configure the Domain Name Servers (DNS Servers) configure the SIC to establish trust with other Check Point products on the network configure the Virtual Hosts configure the Common Suffix Domain

To configure WAPS: 1 2 At the prompt, type sysconfig and then press

Enter.

Type 1 and then press Enter to open the Network Interfaces menu where you enter the computers IP addresses. Follow the on-screen instructions to Configure the interfaces. From this submenu, you must Set the interface network addresses. (You do not have to configure additional parameters.) Return to the main menu. Type 2 and then press Enter to configure the routing table of the WAPS. Follow the instructions on the submenus and enter the routing rules for the WAPS. When finished, return to the main menu.
Tip - To ensure that you load the correct version, allow the computer to select the product version, by default, when rebooting.

72

Installing and Configuring UserAuthority WAPS

Note - If this is the first time you enter the WAPS, you must change the default password before you begin the configuration.

Type 3 and then press Enter to type a Host name for the computer. Follow the instructions in the submenus and enter the host name. When finished, return to the main menu. Type 4 and then press Enter to type a Domain name for the computer. Follow the instructions in the submenus and enter the domain name. When finished, return to the main menu.
Note - The domain name must be no longer than 100 characters. This is the domain that will be used to define a cross domain between websites.

Type 5 and then press Enter to type the Domain name servers IP addresses. These are the name servers used to resolve domain names into IP addresses. Follow the instructions in the submenus and enter domain name servers. Repeat the step as many times as necessary to enter additional servers. When finished, return to the main menu. Type 7 and then press Enter to enter the Product configuration. If this is your first configuration, you are instructed to install the UserAuthority WAPS. Type y and then Enter. Follow the directions on the screen: Do not add a new license. You do not need a license on the WAPS. When prompted, make random keystrokes until you hear a beep or see the words Thank You. Type a SIC key number. You must type it again to confirm. Be sure to remember your key, you will need to enter it in the SmartDashboard configuration. Start the installed products. Return to the main menu. Type 8 and then press Enter to enter the Proxy Configuration. Type 1 and then press Enter to configure Virtual Hosts. Follow the directions in the Virtual hosts configuration submenu to configure the virtual host. This configures virtual hosts

Chapter 2

UserAuthority Deployments and Installation

73

Installation and Configuration

(i.e., the Web servers that has the actual Web applications being requested). Requests are resolved and forwarded to a virtual host based on the rules that are configured in this menu. You can configure one or more virtual hosts. The virtual host configuration includes setting the following parameters: virtual host name local virtual path remote URL SSL support (only SSL, no SSL, both regular HTTP and SSL) For more information on configuring virtual hosts, see the section Configuring Virtual Hosts on page 84. 9 In Proxy Configuration menu, type 2 to enter the Advanced configuration submenu to enter the Common Suffix Domain name in the cp_ua_plugin.ini. This must be done if there is more than one Web server in the deployment. A Select 3, Edit WebAccess advanced settings to open the cp_ua_plugin.ini. file. B When prompted, type
yes

to confirm that you want to modify the file.

C Scroll to the SHARE_USER_IDENTITY_ACROSS_DOMAINS section. D Change the SHARE_USER_IDENTITY_ACROSS_DOMAINS section to read as follows: Enable=True (default value is false)
domain_suffix=.myEnterprise.com

Where myEnterprise.com is the common domain suffix for your Web servers. You must type the (.) before the suffix. default_domain=www.myEnterprise.com (this is the fully qualified domain name that all requests that do not match the Common Suffix Domain are redirected to). E In the Domain List, type the name of a second domain to where you want to redirect specific requests. This is necessary for requests that do not contain the full domain name. For example if you want requests to a to go to a.myEnterprise.com then type:
a=a.myEnterprise.com

F Save the file and close it. 10 Return to the main menu. When prompted, restart the WAPS to complete the configuration.

74

Installing and Configuring UserAuthority WAPS

Configuring UserAuthority WAPS in SmartDashboard You must configure the WAPS using SmartDashboard. For more information on how to use SmartDashboard or if it is not installed on the management server, see the Check Point SmartCenter Guide. To configure the UserAuthority WebAccess in SmartDashboard: 1 2 From SmartDashboard window is displayed. In the Tree pane, click displayed.
Policy

menu, select The

Global Properties.

The

Global Properties

UserAuthority.

UserAuthority Properties

window is

FIGURE 2-29 Global Properties Window (UserAuthority Properties)

Chapter 2

UserAuthority Deployments and Installation

75

Installation and Configuration

3 4

Select the Display SmartDashboard.

Web Access view

checkbox. This displays the

Web Access

tab in

Create a new network object: A In the SmartDashboard Network Objects tree, right click Network Objects. From the shortcut menu, select New >Check Point > Host. The Check Point Host window is displayed. B In the
Name

field, enter the name of the UserAuthority WAPS computer.

IP Address

C Enter the IP address for the UserAuthority WAPS in the D From the
Version

field.

drop-down list, select

NG with Application Intelligence.

E From the list of Check Point products, select UserAuthority WebAccess. (You may have to scroll down the list to find UserAuthority WebAccess.)
Note - In the event that an alert about the UserAuthority WebAccess rule base is displayed, ignore it and continue.

Establish SIC: A In the Secure Internal Communication area of the Check Point Host window, click Communication to display the Communication window.

FIGURE 2-30 Communication Window

76

Installing and Configuring UserAuthority WAPS

B In the Activation Key field, enter the Activation Key that you created when you configured the SIC Policy (see Configuring UserAuthority WAPS step 7 on page 73). C Enter the Activation Key again in the
Confirmation

field. are displayed in the

D Click Initialize. If the operation is successful, the words Trust state field.

Trust established

Note - If the SIC operation is not successful, click Reset and reset the SIC on the WebAccess machine. Try again. Verify that you are entering the correct SIC Activation Key.

E Click 6

Close

to return to the

Check Point Host

window.
UserAuthority WebAccess

Select the UserAuthority Check Point WebAccess tab. The tab is displayed.

Chapter 2

UserAuthority Deployments and Installation

77

Installation and Configuration

FIGURE 2-31 UserAuthority WebAccess Tab

From the User Authority Server drop-down list, select the VPN-1 Pro gateway on which the UAS is installed. The WebAccess Host window should resemble FIGURE 2-32.

78

Installing and Configuring UserAuthority WAPS

FIGURE 2-32 Check Point Host Window for the WAPS Object

8 9

Click Click

OK.

The new host is displayed in the

Network Objects

tree.

Install Policy

on the toolbar to install the policy. tab.

10 Go to the

WebAccess

11 Install the policy on WebAccess. A Right-click a Web site. B In the URL tree select of the installation.
Install.

A window is displayed that shows the progress

Chapter 2

UserAuthority Deployments and Installation

79

Installation and Configuration

C Click

Close

upon completion of the installation process.

Your SmartDashboard configuration is complete. You should now define a UserAuthority WebAccess policy in the WebAccess tab of SmartDashboard. For details on how define a basic UserAuthority WebAccess policy, see Configuring a Basic Web SSO Rule on page 85. For more information on the rule bases needed to define UserAuthority WebAccess rules, see Configuring UserAuthority WebAccess Application Settings on page 87.

Installing and Configuring the UserAuthority WAPI

The UserAuthority WAPI can only be installed on a Microsoft IIS Web Server. The following Windows software is required to install the UserAuthority WAPI: Windows NT Server SP5, Windows 2000, or Windows 2000 Server Microsoft IIS 4.0 or 5.0 The following Check Point software is also required: VPN-1 Pro module installed on a gateway or other server VPN-1 Pro management installed on a gateway or other server SmartDashboard UAS installed on a VPN-1 Pro module For more information on how to install these components, see the Check Point SmartCenter Guide. For more information on how to install the UAS, see Installing and Configuring UAS on VPN-1 Pro on page 49. To install UserAuthority WAPI: 1 Stop the IIS Web Server: In the Windows Start menu, point to Settings and then click Control Panel. Double click Administrative Tools and then double click Internet Services Manager. In the Internet Information Services control panel, right click the name of the Web server (in the tree at the left of the control panel) and then click Restart IIS. The the Start/Stop/Reboot window is displayed. Select Stop Internet Services on <name of computer>. Click OK.

80

Installing and Configuring the UserAuthority WAPI

FIGURE 2-33 Start/Stop/Reboot window

Insert the CD. When the CD contents window opens on your computer, double click Install SVN Foundation and Follow the on-screen instructions to install SVN Foundation Package for FP 3. Close the SVN Foundation installation wizard. Double click the UserAuthority WebAccess icon and follow the on-screen instructions to install UserAuthority WAPI. The Installation Welcome window is displayed. In the Licenses window, click UserAuthority WAPI).
Next

4 5

(you do not need a license for the

The Key Hit Session window is displayed. Follow the on-screen instructions and click Next when finished.

Chapter 2

UserAuthority Deployments and Installation

81

Installation and Configuration

FIGURE 2-34 Key Hit Window

In the Secure Internal Communication window, enter a SIC key number. Enter it again in the next field to confirm. Be sure to remember your key, you will need to enter it in the SmartDashboard configuration. Click
Finish

7 8

and then restart the computer.

Look at the Web sites you have on the IIS and make sure that the UserAuthority Directory in each one has anonymous access permissions. A To open the IIS, select
Start > Settings > Control Panel > Administrative Tools >Internet Services Manager.

B Double-click on your Web site. The Web sites directories are displayed. C Right-click on the UserAuthority directory and select pop-up menu.
Properties

from the

82

Installing and Configuring the UserAuthority WAPI

D In the Access and Authentication Control section of the click Edit. E In the Authentication checkbox. F Click G Click
OK OK Methods

Directory Security

tab,

window, select the

Anonymous access

to close the to close the

Authentication Methods

window. window.

UserAuthority Properties

H Repeat steps B-G for each Web site on the Web server. Configuring UserAuthority WAPI in SmartDashboard The process for configuring the UserAuthority WAPI in SmartDashboard is the same as for the WAPS. For details, see Configuring UserAuthority WAPI in SmartDashboard on page 83. Configuring Common Suffix Domains 1 2 3 Find the Checkpoint/NG/Conf directory and open the cp_ua_plugin.ini file. Scroll to the SHARE_USER_IDENTITY_ACROSS_DOMAINS section. Change the SHARE_USER_IDENTITY_ACROSS_DOMAINS section to read as follows: Enable=True (default value is false)
postfix=.myEnterprise.com

Where myEnterprise.com is the common domain suffix (postfix) for your Web servers. You must type the (.) before the suffix. target=www.myEnterprise.com (this is the fully qualified domain name that all requests that do not match the Common Suffix Domain are redirected to). 4 From the command line run:
cpstop cpstart

Chapter 2

UserAuthority Deployments and Installation

83

Installation and Configuration

Configuring Virtual Hosts

Reverse proxy rules define how external users can gain access to internal sites. A virtual host is a reverse proxy rule that defines how the proxy forwards requests to the internal Web servers. Virtual host configuration allows a network administrator to define one set of rules for access to the reverse proxy server and another set of rules for access from the reverse proxy server to the internal Web server. For example, you can specify SSL encryption for external proxy access but internally pass an HTTP request to the Web server over port 80. Virtual hosts can also be used to map all internal Web servers to one domain (with different prefixes) or to multiple domains. For example, two Web servers (server1 and server2) can be mapped to www.myEnterprise.com/server1 and to www.myEnterprise.com/server2 or to server1.myEnterprise.com/ and
server2.myEnterprise.com/.

To define a virtual host: 1 2 3 4 Log in to the WAPS. Run sysconfig. Select 8 for Proxy Configuration, then select 1 for Virtual Hosts Configuration. Select Add New Virtual Host. When adding a Virtual Host you must specify: Virtual Server Name: The external domain that you publish externally, which resolves the DNS to the reverse proxy. This name can be unique for each internal server or one name can be defined for all the Web servers. Incoming IP Range: If the WAPS has more than one IP, each virtual host can be associated with one of the IPs to reduce load on one IP address. The incoming IP range allows you to specify the IP address that is associated with the virtual host. Virtual local path: To distinguish between two servers set on the same domain (for example, www.mycompany.com/server1 and www.mycompany.com/server2), specify a different prefix (the Virtual local path) for each server. A user request to www.mycompany.com/server1 is sent to server1 and a request to www.mycompany.com/server2, is sent to server2. The local path is the prefix after the Virtual server name (for example, server1).

84

Configuring a Basic Web SSO Rule

Remote URL:

The internal server identity to which the request should be sent by the proxy. It can be a server name or an IP address. If it is a server name, the proxy should be configured to resolve the server name. Some examples of possible values are:
http://10.10.10.2/ http:/server1:8080 http://server2/specificDir/

Select from three possible values: Yes: the proxy can resolve requests over HTTPS only No: the proxy can resolve requests over HTTP only Both: the proxy can resolve requests over HTTP and HTTPS. Default Host: when a request arrives to the WAPS for a domain that has not been specified in the Virtual host, specify a default host to which the request will be sent if no other rule matches the request. 5 6 7 Repeat step 4 to add additional virtual hosts, as required. Return to the main menu and restart the WAPS when prompted. Exit sysconfig.

Listen On SSL Port:

Configuring a Basic Web SSO Rule

UserAuthority WebAccess policy is configured by creating rules in SmartDashboard. To create Web SSO you add a special effect for each application. These effects are configured in the Application Settings rule base (see FIGURE 2-35). These effects impact the operations that are carried out after a user is identified. Before you configure UserAuthority WebAccess policy, make sure that you have installed and configured UserAuthority WebAccess and that you have enabled the UserAuthority WebAccess tab in SmartDashboard.
Note - This is a basic configuration that includes only one Web site and performs only SSO (without Access Control). For configuration with more than one Web site, see Web SSO with more than one Web site on page 110. For Web sites with Access Control, see Chapter 4, Authorization for Web Applications.

To configure Web SSO policy: 1 2 Click the Create a

Web Access

tab. Object (that represents a Web site in your system):

New > SSO Only Web

Check Point Web site

A From the URL Tree, right click Web Sites and then select Site. The Web Site Properties window is displayed.
Chapter 2

UserAuthority Deployments and Installation

85

Installation and Configuration

B Enter a name for the URL. (This will be the name of the Web site in SmartDashboard.) C Click
Add

to open the

WebAccess installed workstations

window.

D Select the UserAuthority WebAccess computer to be the UserAuthority WebAccess enforcement module. E Click F Click 3 4 5 6
Add OK

and then click

OK

to close the window. window.

to exit the

WebAccess Properties

Select the URL that you created to accept SSO. In the SmartDashboard window. Click the
Create Rule WebAccess

tab, click in the

Application Settings - Effects

button in the tool bar to create a new Rule line.

In the Effects field, select Single Sign On or Insert Header. For Web SSO, you can choose one of two effects: Single Sign-On: This provides the ability to provide user credentials to an application by injecting them in a pop-up or an HTTP form. Insert Header : This adds a header to the request so that the application authenticates the user without any application-based sign on. Right click the Scope field and select information on defining the Scope.
Here and Below.

7 8

See TABLE 2-3 for

Right click the Operation field, and select Add. Select an operation from the Add Object window. Click OK to return to the WebAccess tab. For information on creating Operation Objects, see Defining Operation Objects and Groups on page 154. In the Track field, right click and select Log if you want to track all UserAuthority WebAccess operations for the selected URL.

10 Define an authentication domain for the Web site, as described in Defining Authentication Domains on page 92. 11 Configure the effect that you configured in step 6. For instructions on how to configure SSO, see Configuring the Single Sign-On Effect on page 89. For information on configuring Insert Header, see Configuring the Insert Header Effect on page 90. 12 Install the policy on WebAccess.

86

Configuring a Basic Web SSO Rule

A Right-click a Web site. B In the URL tree select of the installation.

Install.

A window is displayed that shows the progress

C Click Close upon completion of the installation process FIGURE 2-35 shows the Applications Settings:
FIGURE 2-35 SmartDashboard Application Settings

Configuring UserAuthority WebAccess Application Settings In order to create Web SSO, you only need to set a basic policy. If you want to carry out additional types of configuration, TABLE 2-3 describes the options available in Application Settings rules.
TABLE 2-3

SmartDashboard WebAccess Application Settings

Field
Scope

Description The scope column indicates which URLs the Application Settings effect. To change the scope of a rule, right click the Scope column and select one of the following from the menu: Here & Below: All URLs below this node are effected by the settings. Here: Only this URL is effected by the settings. Where defined?: Where the rule is defined. Edit Exceptions: Check the URL to which the rule must apply.

Chapter 2

UserAuthority Deployments and Installation

87

Installation and Configuration

TABLE 2-3 Operation

SmartDashboard WebAccess Application Settings

Operations describe the intent of the request, such as Read, Write or Delete. Operations are defined as Operations Objects. For information on creating Operations, see Defining Operation Objects and Groups on page 154. To select an operation: Right click the Operation field and select an Operation from the Add Object window displayed. Click OK to close the window. If you have not defined Operations, no Operations are displayed in the Add Object window. For information on how to define and create Operations Objects, see Defining Operation Objects and Groups on page 154. To enable SSO, you select Single Sign On or Insert Header from the shortcut menu. To select SSO: Right click the Effects field. Select Single Sign On or Insert Header. For information on the options in the Effects menu, see Configuring UserAuthority WebAccess Application Settings on page 87. You can select no tracking or choose to create a log. A log provides one line in the fwlog for every UserAuthority WebAccess request. To enable logs: Right-click the Track field and select Log from the drop-down list.

Effects

Track

88

Configuring a Basic Web SSO Rule

Configuring the Single Sign-On Effect If you selected Single Sign On as the effect when you configured the rule, then you must select the type of Single Sign-On and carry out some other simple configurations. To configure Single Sign-On: 1 Double click displayed.
Single Sign On

in the

Effects

field. The

Single Sign On

window is

FIGURE 2-36 Single Sign On Window

Select the type of Single Sign-On to use with this Web application: Basic: Web Server authentication (use this if the Web applications authentication is a basic pop-up). HTML: Form-based authentication (use this if the Web application accepts HTML forms for authentication). From the Authentication domain drop-down list, select the authentication domain where authentication is to be carried out for applications that share the same authentication credentials. For information on creating and configuring authentication domains, see Defining Authentication Domains on page 92. If you have not created an authentication domain, the drop-down list is empty. In the Application Name field, enter the name of the application. This is the name of the application that is presented to the user first signing on to the application. Click the
None Log: Track

4 5

tab and indicate the type of tracking to use for this Web site:
Log

Creates log files. You must indicate window, see TABLE 2-3.

in the

Application Settings Effect

Chapter 2

UserAuthority Deployments and Installation

89

Installation and Configuration

For information on reading the information contained in the logs, see Chapter 12, Monitoring the UserAuthority Environment. Popup alert: Causes a pop-up with tracking information to be displayed each time the Web site is accessed. Configuring the Insert Header Effect If you selected Insert Header as the effect when you configured the rule, then you must configure the header parameters. To configure Insert Header: 1 Double click displayed.
Insert Header

in the

Effects

field. The

Insert Header

window is

FIGURE 2-37 Insert Header Window

Click

Add.

The

Insert Header Add Parameters

window is displayed.

90

Configuring a Basic Web SSO Rule

FIGURE 2-38 Insert Header Add Parameters Window

3 4

Enter a

Parameter name.

Select the required type of parameter value: Constant value: This is used if the parameter has a fixed value. Dynamic Value: This is used when the parameter value changes according to the current connection to the Web site. Select a dynamic value from the drop-down list, as follows: Source IP: The source IP address. Destination IP: The destination IP address. Destination Port: The destination port. Source Port: The source port. User: The user identity that is achieved at the trusted identity point. Group: LDAP or internal group. Encryption: VPN or SSL. Schema: The Check Point schema. SCV: The SecuRemote/SecureClient status. Client IP: The true IP (if passing through NAT). Click OK to close the Insert Header Add Parameters window. The window closes and the Insert Header window displays the added parameter in the list. Add as many additional parameters as necessary, then click Header window.
OK

5 6

to close the

Insert

Chapter 2

UserAuthority Deployments and Installation

91

Installation and Configuration

Defining Authentication Domains

User credentials enable access to applications by mapping names and passwords for the application. An Authentication Domain represents a set of stored credentials for one or more users. For more information on Authentication Domains, see Mapping User Identity to Application Information by UserAuthority on page 106. To define an authentication domain: 1 In SmartDashboard, select Manage > User Authority > The UA Authentication Domains window is displayed.
UA Authentication Domains.

FIGURE 2-39 UA Authentication Domains Window

The UA Authentication Domains window has the following buttons: New: Creates a new authentication domain. Remove: Removes the selected authentication domain. Edit: Allows you to make changes to the selected authentication domain. 2 To create a new authentication domain, click New > UA Authentication Domain. The UA Authentication Domain Properties window is displayed.

92

Defining Authentication Domains

FIGURE 2-40 UA Authentication Domain Properties Window

Enter the following information in the UA Authentication Domain Properties window: Name: The Authentication Domain name. Comment: Descriptive text. This text is displayed at the bottom of the Authentication Domain window and relates to the Authentication Domain selected. Color: Select the color of the Authentication Domain. Add application servers that can access the Authentication Domain: A Click
Add.

The

Add Application Server

window is displayed.

Chapter 2

UserAuthority Deployments and Installation

93

Installation and Configuration

FIGURE 2-41 Add Application Server Window

B Select a UserAuthority WebAccess from the Web Agent drop-down list. C Leave the D Leave the
Permissions

UserAuthority WebAccess/Other

set to

Full Access. All.

Users Groups

set to

E Click OK to return to the UA Authentication Domain Properties window. The new application server is entered in the Application Server Access List, which displays the application servers that can access this particular Authentication Domain, as well as which Group the application server can access and with what permissions. 5 6 Leave the
Administrators User Group

set to

All.

Click OK to close the window and return to the UA Authentication Domains window. The new authentication domain is added to the list.

Setting Up SSL Terminating Certificates on your UserAuthority WAPS Installation

To set up SSL Terminating Certificates on your WAPS Installation: 1 2 Login to a Secure Platform WAPS in expert mode. Create an RSA private key for your Apache server (Triple-DES encrypted and PEM formatted) using the command:
$ openssl genrsa -des3 -out server.key 1024

94

Setting Up SSL Terminating Certificates on your UserAuthority WAPS Installation

Backup this server.key file and record the pass-phrase you used to enter at a secure location. You can view the details of this RSA private key using the command:
$ openssl rsa -noout -text -in server.key

Although it is not recommended, you can create a decrypted PEM version of this RSA private key using the command:
$ openssl rsa -in server.key -out server.key.unsecure

Create a Certificate Signing Request (CSR) with the server RSA private key (output will be PEM formatted) using the command:
$ openssl req -new -key server.key -out server.csr

Make sure you enter the Fully Qualified Domain Name (FQDN) of the server when OpenSSL prompts you for the CommonName. For example, when you generate a CSR for a Web site which will be later accessed via https://www.foo.dom/,
enter www.foo.dom.

You can view the details of this CSR using the command:
$ openssl req -noout -text -in server.csr

You now have to send this Certificate Signing Request (CSR) to a Certifying Authority (CA) for signing, after which you receive a real Certificate that can be used for Apache. In this step you have the CSR signed by a commercial CA such as Verisign or Thawte. You then have to post the CSR into a Web form, pay for the signing and await the signed Certificate which you then store in a server.crt file. For more information on commercial CAs refer to the following locations: Verisign
http://digitalid.verisign.com/server/apacheNotice.htm

Thawte Consulting
http://www.thawte.com/certs/server/request.html

CertiSign Certificadora Digital Ltda.

http://www.certisign.com.br

IKS GmbH
http://www.iks-jena.de/produkte/ca/

Uptime Commerce Ltd.

http://www.uptimecommerce.com

BelSign NV/SA
http://www.belsign.be

You can view the details of the received Certificate using the command:
$ openssl x509 -noout -text -in server.crt

Chapter 2

UserAuthority Deployments and Installation

95

Installation and Configuration

You now have two files: server.key and server.crt, which you must set under: $WADIR/apache/conf/ssl.crt. These can be used as follows inside your WebAccess httpd.conf file which can be accessed from the sysconfig > proxy configuration > advanced options: Change the values of the following two parameters to their new relevant values
SSLCertificateFile /<PATH Location>/server.crt SSLCertificateKeyFile /<PATH Location>/server.key

8 9

Delete the server.csr file as it is no longer needed. If you want to use the certificate only for a specific Web site you must define the following two lines in the relevant SSL-based virtual host in the httpd.conf file: A Find the relevant virtual host in the list of virtual hosts after the line # BeginWebAccessDefaultVirtualHostsSSL. B Move the entire virtual host before the above line. C Insert the following two lines to the moved virtual host:
SSLCertificateFile /<PATH Location>/server.crt SSLCertificateKeyFile /<PATH Location>/server.key
Note - After performing these steps this virtual host must be modified manually. Any change using the Virtual hosts menu in sysconfig will not work on this virtual host!

For more information on SSL see http://www.modssl.org/docs/2.8.

96

CHAPTER

Web SSO
In This Chapter
The Challenge The UserAuthority Solution SSO Types for Web Applications Achieving User Identity Mapping User Identity to Application Information by UserAuthority Configuration Advanced Configuration page 97 page 98 page 100 page 101 page 106 page 112 page 124

The Challenge
In an enterprise, multiple users may be working with Internet resources at any given time, including: local users, who connect directly to the local network remote users, who connect from a remote location with SecureClient/SecuRemote users from outside the enterprise, who access the local intranet from a remote computer without any pre-installed authentication software These diverse users need to access the local intranet easily while still ensuring network security. For this reason, Web applications must identify and authenticate users whenever and from wherever they access a local intranet resource. Most users access multiple intranet resources, and each resource has an authentication process. For example, a user who wants to order supplies using the enterprises requisitions Web application must authenticate to the application before being granted access. In the same work session, the same user might have to authenticate to an

97

The UserAuthority Solution

additional Web application, e.g., the budget management application, to verify that funds are available for the purchase. The need to constantly provide credentials in order to be authenticated for each application can be frustrating and time-consuming. UserAuthority provides Web Single Sign-On (SSO), eliminating the need for the user to repeatedly submit his/her credentials. SSO provides one-time authentication for all Web applications, which remains valid for subsequent access attempts.

The UserAuthority Solution

UserAuthority provides Web SSO for any Web application without the need to make any modifications to the application. UserAuthority provides SSO for all users (remote, VPN and local). UserAuthority obtains the user identity from a Trusted Identification Point (TIP), such as the Windows Domain Controller (DC), the VPN-1 Pro gateway or UserAuthority WebAccess. This identity is then used to find and automatically submit the proper user credentials to the Web applications requested by the user. For example, in FIGURE 3-1, users sign on from different locations. WebAccess queries the UserAuthority Server (UAS) on the first TIP for identification. If the user cannot be identified at the initial TIP, other TIPs are queried until the user is identified. If the user cannot be identified through a TIP, UserAuthority WebAccess provides an authentication page to the user, where the user is prompted to enter his/her authentication details in order to be authenticated. For more information on identifying a user, see Achieving User Identity on page 101.

98

FIGURE 3-1

Web SSO for Users in Multiple Locations

Other applications to which a user sends requests might require different authentication procedures. UserAuthority uses the Credentials Manager to match the users identity with the credentials needed to authenticate the user for the specific Web application requested. The users identity is held in the UserAuthority Credentials Manager together with the users specific application credentials. When the user requests a Web application, UserAuthority WebAccess queries the Credentials Manager on the UAS to find the correct credentials for the requested application based on the users identity. It then enters the credentials into the applications authentication page on behalf of the user, eliminating the need for the user to authenticate to each application requested. For example, a users identity may be: Username: Bill Password: jkb8fll However, Bills credentials for the companys billing application may be: Username: BillK Password: bk88

Chapter 3

Web SSO

99

SSO Types for Web Applications

The Credentials Manager maps the users identity, Bill, to the billing application credentials, BillK (and the password bk88), and UserAuthority WebAccess uses them to authenticate the user to the billing application. User involvement in this process is minimal. In most cases, the user can enter a network and access Web applications without having to authenticate at all, because UserAuthority obtains the user identity from a TIP and authenticates to the requested applications on behalf of the user. In the few cases where authentication is necessary, this is limited to the first access attempt. UserAuthority authenticates on behalf of the user for any subsequent attempts to access Web applications. Web SSO is initiated by UserAuthority WebAccess, which tries to access the Web applications for the user and submit the credentials. UserAuthority WebAccess carries this out according to policies that are defined by an administrator and are configured in the SmartDashboard. Web SSO flow is therefore based on three steps: Retrieval of the user identity from the most appropriate resource. Mapping the UserAuthority identity to the user credentials required by the requested Web application. Using these credentials to authenticate to the Web application on behalf of the user.

SSO Types for Web Applications

SSO is achieved by authenticating the user for applications with the user credentials that are held in the Credentials Manager. Web applications can use several authentication methods. UserAuthority currently supports the following methods: Basic authentication: In basic HTTP authentication, a user provides a username and password in a standard Windows pop-up. These user credentials are inserted into the standard HTTP header and passed to the application for authentication. HTML forms authentication: In form-based authentication, user credentials are provided using an HTML form instead of sending the information in the HTTP header. The user enters credentials in the form and then submits the form to the application for authentication using the HTML POST command. HTTP headers: In this method special HTTP headers are inserted into the reply. These headers contain the users credentials for the requested application. No authentication: Some Web applications do not require any special authentication. In this case, UserAuthority can supply the user identity to the application for personalization purposes (e.g., the user name is displayed in the corner of the Web page). This is done by inserting the user identity into an HTTP header.

100

Internal Users

UserAuthority supports all of these authentication methods by mapping the credentials held in the UserAuthority Credentials Manager in the appropriate manner. For example, if an application supports basic HTTP authentication, UserAuthority WebAccess injects the name and password into the applications pop-up. If the application supports HTML forms, the information is injected into the applications HTML authentication form. This is done transparently and the user does not have to directly enter credentials to access the application. For more information on how UserAuthority maps the information to the Web application, see Mapping User Identity to Application Information by UserAuthority on page 106.

Achieving User Identity

The first step in providing user access to a network is to identify the user. User identity is achieved at a TIP. The most common TIPs are: VPN-1 Pro gateway Windows DC UserAuthority WebAccess Citrix/Microsoft Terminal Services The following scenarios are presented to show how the TIPs are queried to achieve a users identity.

In This Section
Internal Users Identification using the NTLM Authentication Protocol Identification of Users on a Citrix or Terminal Services Remote Users with a VPN Client Remote Users without a VPN Client page 101 page 102 page 103 page 104 page 105

Internal Users
Internal users are usually known to the network and can be identified by the Windows DC. (In enterprises using Citrix or Windows Terminal Services, internal users are identified by UAS on the Citrix MetaFrame Server or the Terminal Services.) The methods used to identify and authenticate an internal user include: NTLM: This is a Windows authentication protocol (NT LAN manager) that allows the browser to provide the users identity. (Only Internet Explorer supports out-of -the-box NTLM.)
Chapter 3 Web SSO 101

Achieving User Identity

UAS on a Citrix MetaFrame/Terminal Services: Users accessing the network from a terminal are identified by the UAS on the Citrix MetaFrame. SecureAgent: SecureAgent is installed on a users PC (desktop or laptop) and is used to provide the users ID. This solution is generally used for non-HTTP protocols.

Identification using the NTLM Authentication Protocol The following figure illustrates how user identity is captured using the NTLM protocol. In this case, the TIP is the Windows DC.
FIGURE 3-2 User Identification using the NTLM Authentication Protocol

The user request for a Web application is sent to the WebAccess Proxy Server (WAPS).
Note - The NTLM protocol is supported only on the

WAPS.

The WAPS queries the UAS on the VPN-1 Pro module for the user identification. The UAS tries to find the user identity, as explained in the next two sections.

102

Internal Users

3 4

If the UAS on the VPN-1 Pro module is unable to identify the user, the WAPS queries the users computer (local client) for the users credentials. Local clients on a Windows domain contain identification information for the user. If the client does not have its identification configured correctly or if the user is not signed on correctly, a standard Windows NTLM pop-up is displayed. The user is requested to enter credentials in the pop-up so they can be sent to UserAuthority WAPS. UserAuthority WAPS queries the Windows DC with the credentials it receives from the user. The Windows DC checks its Active Directory or NTLM database to match the users credentials. The Windows DC sends an encrypted message back to the WAPS confirming the identity. The WAPS updates the UAS.
Note - You must establish a trust relation between the Windows DC and WAPS. Trust is established so that the WAPS accepts any information from the Windows DC and the Windows DC accepts any information from the proxy.

Identification of Users on a Citrix or Terminal Services Identification of users on a Citrix or Terminal Services system is similar to the identification of users in a Windows domain. In this case, however, the TIP is a UAS on the MetaFrame Server or Windows Terminal Services. FIGURE 3-3 illustrates how a user on a Citrix or Terminal Services is identified.
FIGURE 3-3 User Identification on a Citrix or Terminal Services

Chapter 3

Web SSO

103

Achieving User Identity

1 2 3

The user signs on to the Citrix or Terminal Services with UAS installed. The user requests a Web application on the network. The request goes from the terminal to UserAuthority WebAccess. Based on the request connection information (source IP, destination IP, source port, destination port and protocol), UserAuthority WebAccess queries the UAS on the VPN-1 Pro gateway for the users identity. The UAS on the VPN-1 Pro gateway queries the UAS on the Citrix or Windows terminal, which provides the users identity. The users identity is sent to UserAuthority WebAccess.

4 5

Remote Users with a VPN Client

Users remotely accessing the internal network with a VPN client, such as SecuRemote or SecureClient, are identified by VPN-1 Pro. Each time a user connects to the internal network, a VPN tunnel is created. This tunnel is used to encrypt the data that travels between the network and the remote computer, ensuring that the user can work on the network safely and privately. The TIP in this scenario is a VPN-1 Pro gateway. This identification is read by the UAS on the VPN-1 Pro gateway, which can send the user identity to UserAuthority WebAccess. Once the user is identified, HTTP requests can be made to UserAuthority WebAccess and the UAS can provide the necessary identity. FIGURE 3-4 illustrates the identification process for a remote user accessing the network using a VPN client.
FIGURE 3-4 User Identification through a VPN Tunnel

104

Remote Users without a VPN Client

1 2

A request is sent to UserAuthority WebAccess on the VPN tunnel through VPN-1 Pro. Based on the request connection information (source IP, destination IP, source port, destination port and protocol), UserAuthority WebAccess queries the UAS on the VPN-1 Pro gateway for the users identity. The UAS can identify the user based on the users VPN identification. The UAS sends the users identity to UserAuthority WebAccess. The request is sent to the Web Server with the appropriate credentials.

3 4

Remote Users without a VPN Client

Remote users signing on to the network without a VPN client are not immediately identified. When a user accesses the network, UserAuthority WebAccess receives the request and queries the UAS on the VPN-1 Pro gateway for the user identity. Because the users identity was not included with the request, the UAS cannot identify the user. UserAuthority WebAccess sends the user an authentication page. After the user authenticates, the user identity is kept so that subsequent HTTP requests can be made to UserAuthority WebAccess without further authentication. FIGURE 3-5 illustrates the identification process for a remote user accessing the network without a VPN client.
FIGURE 3-5 Remote User Identification without a VPN Client

Chapter 3

Web SSO

105

Mapping User Identity to Application Information by UserAuthority

A remote user without SecuRemote/SecureClient connects to an internal network from any computer (with or without SSL). The request goes through VPN-1 Pro to UserAuthority WebAccess. UserAuthority WebAccess sends an authentication page to the user. User credentials are verified against the UAS. UserAuthority WebAccess proxies the HTTP request to the Web Server.

2 3 4

Mapping User Identity to Application Information by UserAuthority

After the user is identified, UserAuthority WebAccess must be able to provide the user access on the application level. Each application that is accessed by a user requires a specific sign-on to determine the users identity and access rights. Web SSO eliminates the need for the user to sign on to each application by providing the user credentials to the application. In order for this to take place the application must: recognize the user accept the users credentials UserAuthority uses the Credentials Manager to provide user credentials to each application. Because applications require different credentials, the Credentials Manager is used to map the users identity to each users credentials for each application so that the correct user credentials are provided to each application. For example, when Bill requests access to an enterprises billing application, the UserAuthority identifies Bill as Bill (his UserAuthority identity). It then finds the table with Bills application credential information. It sees that Bill is known to the Billing Application as BillK. It then injects the information into the Billing Applications authentication page to authenticate Bill on his behalf.
TABLE 3-1

Credentials Mapping Web Application Password User Name Last Updated

UserAuthority ID

Bill

Billing Application

bk88

BillK

Wednesday, October 31, 2003 2:17:31 PM

The Credentials Manager has a set of tables holding a users application credentials. This table indicates: The authentication information required by each application (username, password, other authentication requirements such as a second password or domain name). When the application credentials were last updated.

106

Remote Users without a VPN Client

The Credentials Manager tables can be filled automatically or manually. They are filled automatically when a user accesses an application for the first time. In this case, if no information was entered into the Credentials Manager, the table is empty and the user must authenticate to the application. After authentication, the user credentials are automatically entered into the Credentials Manager table. The next time the user accesses the application, the Credentials Manager will find the correct credentials and inject them automatically into the applications authentication page. UserAuthority also enables mapping to be configured manually by both the user and administrator. This allows manual selection of how information is provided to each application. A user or administrator can access the tables through a Web browser and update all credential information. An administrator can make changes in information for any user in the network. The network administrator can also block access to manual configuration to individual users for security reasons. For more information on manual mapping, see Configuring Manual UserAuthority Settings on page 114. UserAuthority saves the credentials for each application under an Authentication Domain. Each application with different credentials and authentication methods (e.g., basic or Form) has its own Authentication Domain. Applications that share the same credentials and authentication methods can be in the same Authentication Domain. For example, if an enterprise has three billing applications and each one requires the same authentication information, an administrator can create an authentication domain. The three billing applications are then entered into the authentication domain. When a user accesses any one of these applications, the Credentials Manager finds the user credentials for the Billing authentication domain and enters the credentials into the authentication page of the requested application. This helps to better organize and save resources in the Credentials Manager. For information on how to create and configure authentication domains, see Defining Authentication Domains on page 92.
Note - For HTML authentication, applications must have both the same credentials and the same authentication script.

FIGURE 3-6 shows the Credentials Manager mapping flow:

Chapter 3

Web SSO

107

Using a Header for Authentication

FIGURE 3-6

Credentials Manager Mapping Flow

Using a Header for Authentication

Applications may sometimes be configured to accept users without injecting their credentials into the applications sign on page. UserAuthority inserts a header into the request that identifies the user according to their UserAuthority identity. In some cases, the applications programming code might be altered to accept the header. Some applications work this way to integrate with third-party SSO applications, such as UserAuthority. For information on how to configure UserAuthority to insert a header to create SSO, see Providing User Identity Web Applications with no Authentication Requirements on page 114.

Special Scenarios
In This Section
Web SSO with an Internal Proxy Web SSO with Citrix Web SSO with more than one Web site Web SSO with Manual Identity Sharing page 108 page 110 page 110 page 111

Web SSO with an Internal Proxy

Some networks include an internal (cache) proxy. A cache proxy is used to provide more efficient access to the Internet. The proxy intercepts and sends a request to a Web server for the client. The requested Web site is returned to the proxy, which holds the IP address for the application in cache memory. The next time someone requests the same site, the proxy can send the Web page to the requester without having to fetch it from the Web server again. This allows the requested Web site to arrive faster.

108

Web SSO with an Internal Proxy

When the request is made to a Web Server on a network with UserAuthority, the cache proxy forwards the request to UserAuthority WebAccess. UserAuthority WebAccess cannot see the original connection information, and therefore cannot identify the user. This problem is solved by using information stored in a special header field in the forwarded request. This problem is solved by configuring WAPS to recognize a connection that was forwarded by a proxy between the client and Web Access. In this case, when the proxy forwards the request, it inserts a field in the header that identifies the client. There are two such types of fields: x-forwarded-for: This is used for connections that contain the IP address of the previous client. Prev-Connection: For connections that contain the clients entire connection. Because there is more information, this is a more trusted process than x-forwarded-for. The following is an example of the prev-connection header: Header Name: Prev-Connection Header Value: <Source IP>-<Source port>-<Destination IP>-<Destination
port> - <protocol>

Example:
Prev-Connection: 212.10.140.81-4502-192.168.10.3-80 - HTTP

FIGURE 3-7 shows how UserAuthority WebAccess gets the header information from the cache proxy, and then uses it to identify the original user.
FIGURE 3-7 Identification of User Accessing a Network through an Internal Proxy

For security reasons, WAPS does not accept forward connections from all proxies. You must indicate the IP addresses that are trusted proxies in the cp_ua_plugin.ini file in the $UAGDIR/conf directory. For more information, see Configuring UserAuthority WebAccess to Recognize Cache Proxy Users on page 124.

Chapter 3

Web SSO

109

Special Scenarios

Workflow To set up a deployment using Web SSO with an Internal Proxy: 1 Follow steps 1-3 of the workflow for UserAuthority for Enterprise Web Applications in UserAuthority WebAccess uses the Common Suffix Domain to make the cookie available to all Web servers in the deployment. When you define a Common Suffix Domain, all domains in the deployment will have the same suffix as is defined in the Common Suffix Domain. In the Common Suffix Domain configuration, you can also define how to handle requests that do not have the common suffix. on page 31 OR steps 1-2 of the workflow for B2C deployment in Workflow on page 36. Configure your trusted proxies. See Configuring UserAuthority WebAccess to Recognize Cache Proxy Users on page 124.

Test Your Deployment Open a browser that goes through your trusted proxy. You should be identified by UserAuthority only if you can be identified by a TIP when browsing without the proxy. You should not see the WebAccess authentication page.

Web SSO with Citrix

When users access Web applications from a Citrix or Terminal Services, the user identity cannot be derived from the machine. This is because many users connect to Web applications from the same machine. In this case, the UAS installed on the Terminal Services can get the users identity based on identifying outgoing connections from the Terminal Services. No special configuration is required. Workflow The workflow scenario for Web SSO with Citrix is described in Chapter 2, UserAuthority Deployments and Installation. For information on how to implement a Citrix deployment, see Citrix MetaFrame or Windows Terminal Services on page 42.

Web SSO with more than one Web site

In some networks there is more than one Web site. In this case UserAuthority WebAccess must be configured to provide SSO, even if a user accesses a different Web server in subsequent requests for Web applications. When configuring UserAuthority in this scenario, two factors must be considered.

110

Web SSO with Manual Identity Sharing

Sharing the user identity between the Web servers:

UserAuthority handles this by keeping a user identity key as a session cookie on the users computer. Setting the appropriate policy for each Web site: UserAuthority WebAccess must be configured to use the correct policy for each Web site. This means that you must define a separate Web site object for each Web site.

Workflow Use the following workflow to set up multiple Web sites: 1 Follow steps 1-3 of the workflow for UserAuthority for Enterprise Web Applications in Workflow on page 31 OR steps 1-2 of the workflow for B2C deployment in Workflow on page 36. If your deployment consists only of UserAuthority WebAccess Plug-In (WAPI) installed on each Web server, and each Web server contains only one Web site: Install a basic UserAuthority policy on each of the Web sites. See Configuring a Basic Web SSO Rule on page 85). If your deployment consists of UserAuthority WAPS or UserAuthority WAPI with more than one Web site on the server: A Configure a basic UserAuthority WebAccess policy for each Web site object. (Do not install the policy.) Perform steps 1-10 from Configuring a Basic Web SSO Rule on page 85). B Distinguish between the Web sites configured on the same WebAccess module. See Configuring Multiple Web Sites in SmartDashboard on page 122. Test Your Deployment To test this deployment, perform one of the following tests for each Web server configured: Test Your Deployment on page 32. Test Your Deployment on page 37.

Web SSO with Manual Identity Sharing

Identity sharing is one of the most important functions of the UAS. Identity sharing is the ability of one UAS to get information from another UAS. When setting up UserAuthority with basic configuration, by default the automatic identity sharing feature is set. This automatically configures the system to find the user identity by querying all relevant UASes until the user identification is found.
Chapter 3 Web SSO 111

Configuration

In some cases it may be necessary to manually set the identity sharing options. For example, when two firewalls are used and the UAS at the external gateway terminates the VPN tunnel and authenticates the remote users. However, UserAuthority WebAccess is connected to an internal gateway. In the case of automatic identity sharing, UserAuthority WebAccess queries the internal gateway for the users identity, and does not receive an answer. To get the users identity, manual identity sharing must be configured to query the external gateway for the users identity. For information on fine-tuning the identity sharing options, see Configuring Manual Identity Sharing Options on page 125. The following figure illustrates a manual identity sharing scenario:
FIGURE 3-8 Manual Identity Sharing Scenario

Workflow 1 Deploy UserAuthority according to the needs of the enterprise. Follow all of the steps of the appropriate workflow in the deployments described in Chapter 2, UserAuthority Deployments and Installation. Configure manual identity sharing. See Configuring Manual Identity Sharing Options on page 125.

Test Your Deployment 1 2 Open a VPN connection to the external gateway (via SecureClient or SecureRemote). Browse to a Web application protected by WebAccess. You should be identified automatically without getting the WebAccess authentication page.

Configuration
In This Section
UserAuthority WebAccess SSO for Web Application Authentication Configuring Manual UserAuthority Settings page 113 page 114

112

UserAuthority WebAccess SSO for Web Application Authentication

Configuring Integrated Windows Authentication Disabling UserAuthority WebAccess for Specific IP Addresses Configuring Multiple Web Sites in SmartDashboard

page 116 page 115 page 122

This section describes the special configurations necessary to implement Web SSO. Before you begin configuring your network for Web SSO, you need to deploy UserAuthority on the network. You might also need to carry out some of the basic configurations before performing the Web SSO configurations described in this section.

UserAuthority WebAccess SSO for Web Application Authentication

In order to configure UserAuthority WebAccess SSO, you must first deploy the environment as described in Chapter 2, UserAuthority Deployments and Installation. The applications authentication method determines the type of UserAuthority SSO used for the authentication. SSO for HTTP Basic Authentication
Workflow

Follow steps 1-3 of the workflow for UserAuthority for Enterprise Web Applications in Workflow on page 31 OR steps 1-2 of the workflow for B2C deployment in Workflow on page 36. Install a basic UserAuthority WebAccess policy. Configure the effect to be Single Sign On, and configure the Single Sign On effect to work with Basic authentication. See Configuring a Basic Web SSO Rule on page 85.

Test Your Deployment

To test this deployment, perform one of the following procedures: Test Your Deployment on page 32. Test Your Deployment on page 37. SSO for HTML Form Authentication UserAuthority works so that the user never sees the authentication page again. This requires an authentication form to be in a separate URL. This form only contains the user credentials (only constant fields). The authentication form must have a Password input field and be submitted by the Post method for UserAuthority to be able to detect it.

Chapter 3

Web SSO

113

Configuration

Workflow

Follow steps 1-3 of the workflow for UserAuthority for Enterprise Web Applications in Workflow on page 31 OR steps 1-2 of the workflow for B2C deployment in Workflow on page 36. Install a basic UserAuthority WebAccess policy. Configure the effect to be Sign On, and configure the Single Sign On effect to work with HTML authentication. See Configuring a Basic Web SSO Rule on page 85.
Single

Test Your Deployment

To test this deployment, perform one of the following procedures: Test Your Deployment on page 32. Test Your Deployment on page 37. Providing User Identity Web Applications with no Authentication Requirements If your Web application does not require authentication, you can use UserAuthority to get the users identification for personalization purposes.
Workflow

Follow steps 1-3 of the workflow for UserAuthority for Enterprise Web Applications in Workflow on page 31 OR steps 1-2 of the workflow for B2C deployment in Workflow on page 36. Install a basic UserAuthority WebAccess policy. Configure the effect to be Header. See Configuring a Basic Web SSO Rule on page 85.
Insert

Test Your Deployment

1 2

Browse to your Web application. Verify that the application has the inserted header information (the test is unique to the application).

Configuring Manual UserAuthority Settings

End users can keep track of their credentials with the UserAuthority Administration table for users. This table is available through the Web browser and is HTML-based. The user table shows applications for the user who is signed on.

114

Disabling UserAuthority WebAccess for Specific IP Addresses

Manually Updating User Credentials To update your own credentials: 1 In your Web browser, enter the name of any Web application protected by WebAccess followed by: /UserAuthority/sign_on_central.waphp and press Enter. The UserAuthority Administration table is displayed. In this page you can do the following: Enter an application by choosing the link with the application name. Reset your credentials by selecting reset in the row for the application for which you want to reset the credentials. An Enter button appears and you can enter new credentials. Enter new credentials by pressing the Enter button. The Sign-On page appears and UserAuthority learns your new credentials. View new credentials by choosing the Sign on info link. The time and date when the credentials were last updated is displayed in the last column.

Disabling UserAuthority WebAccess for Specific IP Addresses

You can configure UserAuthority WebAccess so that some clients can access the network without being subject to UserAuthority WebAccess rules. This is done in two steps: Determine the Disable_WebAccess_Behavior. Enter the list of IP addresses to be disabled. To disable IP addresses from UserAuthority WebAccess: 1 Open the WebAccess configuration file cp_ua_plugin.ini and do one of the following: From the WAPS machine, type sysconfig. Then select 8 for Proxy Configuration > 2 for Advanced Configuration > 3 to open the
cp_ua_plugin.ini file

OR From the WAPI machine, browse to the installation folder and then to NG\Conf. The default folder is c:\ProgramFiles\CheckPoint\NG\Conf. Open the file. 2 3 4 Open the
UserAuthority WebAccess Configuration File (cp_ua_plugin.ini).

Scroll to the PASS_THROUGH section. Find the line:

Mode =

Chapter 3

Web SSO

115

Configuration

Type one of the following (if one of the following is already entered, delete it and type your selection): Closed: If this line is entered, UserAuthority WebAccess is active for all requests except for those from the IP addresses in the IPs = line. Open: UserAuthority WebAccess is not active for any requests except for those from the IP addresses in the IPs = line Find the line:
IPs =

6 7

Type the IP for the clients you want to disable from UserAuthority WebAccess. If there is more than one IP, separate the addresses with a comma (,). Use an asterisk (*) in the IP address to indicate wild cards (for example if you want all IP addresses that begin with 191, then type 191.* in the IPs line). Make sure to remove the semi-colon (;) at the beginning of the line. Save the file and close it. From SmartDashboard install the policy on WebAccess. Right-click a Web site in the URL tree and choose Install. A progress window is displayed. At the end of the installation process, click Close.

8 9

Some reasons for exempting specific clients from UserAuthority WebAccess authorization are: Troubleshooting: You can disable UserAuthority WebAccess to check whether a network problem is related to UserAuthority WebAccess. Users with special status: You might want to give certain managers or administrators unrestricted access to the Web server. Special Services: Servers or clients with special services may interrupt the UserAuthority WebAccess service if they need to be cleared by UserAuthority WebAccess policy. Staging: Good for deployment to specific subnets.

Configuring Integrated Windows Authentication

UserAuthority can use Integrated Windows Authentication to get the user identity from a Windows DC. When a user is signed on to the Windows domain, Internet Explorer (IE) automatically uses a built-in authentication method to identify the user. In this case, IE identifies the user so that UserAuthority SecureAgent does not have to be installed on the client desktops. In addition, the UAS does not have to be installed on the Windows DC.

116

Configuring Integrated Windows Authentication

In order to use Integrated Windows authentication you must: Establish trust between a Windows DC and the WAPS. Configure the WAPS to identify the user with NTLM. To configure UserAuthority to use Integrated Windows Authorization:
Note - Internet Explorer sends user identity to local intranet addresses only. In some cases, when accessing a Web page on the LAN using an IP address or fully qualified domain name (FQDN), the Web page requested is not recognized as a local intranet address by IE. In this case, the Integrated Windows Authentication does not work and users are prompted to authenticate when accessing one of these sites. To properly configure IE to recognize local intranet addresses, see Ensuring that all Local Web pages are Recognized as Intranet Sites on page 120.

Warning - You must allow an nbsession between the WAPS and the Windows DC. To do so add a security rule that enables the service nbsession between the WAPS and the Windows DC.

In order to use Integrated Windows authentication you must: Establish trust between a domain and the proxy machine. Configure the WAPS to identify the user with NTLM. To configure UserAuthority to use Integrated Windows Authorization: On the Windows DC machine (for Windows 2000 and later): 1 2 3 4 5 6 1 2 3 Select
Start > Settings > Control Panel. Administrative Tools

Double click Computers.

and then double click

ActiveDirectory Users and

In the console tree, right click

Computers

and then select

New > Computer.

Give the computer the same name as the WAPS computer. Make sure you select Allow pre-Windows 2000 computers to user this account. Click Close
OK. Active Directory.

On the WAPS: Run sysconfig. Select Proxy Configuration (8) Select Advanced Configuration (2)

Chapter 3

Web SSO

117

Configuration

4 5

Select Configure Integrated Windows Identification (1). Configure all the fields (i.e., Windows DCs). To use a browser other than Microsoft Internet Explorer, you must allow basic authentication when integrated Windows authentication is not available. A Select 1 and then y to enable Integrated Windows Authentication. B Select Basic Authentication Fallback when integrated Windows authentication is not available (2) and then type Y to confirm. C Configure the Windows domain to which the WAPS machine is going to authenticate. D Configure the primary Windows DC (dont use the FQDN). Give only the computers name without the domain (e.g., domaincontroller and not domaincontroller.domain.com) E For Windows NT systems, configure the backup DC.

118

Configuring Integrated Windows Authentication

F Select Establish a trust with the domain. Follow the instructions in the following file:
UserAuthority WebAccess - Integrated Windows(tm) authentication These options allow WebAccess to use E's built in Integrated Windows(tm) Authentication for the purpose of Identifying the user. | | 1. Enable Integrated Windows(tm) authentication (yes) | 2. Allow basic authentication when integrated Windows(tm) Authentication is not available (yes) | 4. Set Windows (tm)domain name (UALABDC2) | 4. Set Primary Domain Controller (ualab2) | 5. Set Backup Domain Controller (none) | 6. Establish a trust with the Domain Controller. | 7. Return to previous menu --------------------------------------Which type of operation would you like to perform? [7] 6 This wizard will help you establish a trust between this host and the domain controller. Before you proceed please read the WebAccess documentation for additional steps that may be required. (y/n)? [n] y Please enter the Primary Domain Controller's Windows computer name Note: This name must appear in the DNS server. [ualab2] Please enter the name of the domain you want to join. [UALABDC2] DC_DOMAIN Please enter a username of a user that has sufficient administrative privileges to join the domain.[user] Administrator Running > net rpc join -S ualab2

-U Administrator -W UALABDC2

2003/10/06 14:50:34 : change_trust_account_password: Changed Password: Joined domain UALABDC2. Press Enter to continue ...

Return to the main menu and restart the WAPS, when prompted.

Troubleshooting the Establish a Trust Procedure This section desribes how to troubleshoot the Establish a Trust procedure. 1 Check connectivity to the Domain controller. Check ping and that ports 137-139 are enabled on the firewall.

Chapter 3

Web SSO

119

Configuration

If the reply is access denied try to remove previous references to any computer, having the WAPS IP, if it is defined on the domain controller. You can check as follows on the Domain Controller machine: A Select
Start > Settings > Control Panel. Administrative Tools

B Double click

and then double click

ActiveDirectory

Users and Computers.

C In the console tree, right click the WAPS IP. 3 Retry establishing the trust .

Computers

and delete any computer having

Troubleshooting the NTLM Procedure This section desribes how to troubleshoot the NTLM procedure. 1 2 Login in expert mode. Examine /etc/samba/smb.conf file.For domain ualab and domain controller uadc the files should look like:
workgroup = ualab password server = uadc security = domain winbind uid = 10000-20000 winbind gid = 10000-20000 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

[global]

3 4 5

Kill the winbindd process - killall winbindd Start the winbindd in debug mode: winbindd I Use the command line utility ntlm_auth. ntlm_auth username=username
domain=domain

Ensuring that all Local Web pages are Recognized as Intranet Sites In some cases, when accessing a Web page on the LAN using an IP address or fully qualified domain name (FQDN), the Web page requested is not recognized as a local Intranet site by Internet Explorer, and therefore, the Integrated Windows Authentication does not work and users are prompted to authenticate when accessing one of these sites.

120

Configuring Integrated Windows Authentication

An administrator can configure/update the list of local Intranet sites via Internet Explorer on the client machine or on the Windows DC. If configured on the client, the procedure must be performed on each client. If configured on the Windows DC machine, the configuration is automatically applied for all users that logon to the Windows Domain. To add *.domain.com or the appropriate IP address range on the local client: 1 2 3 In Internet Explorer Click the
Security Tools

menu, click

Internet Options.

tab, and then click

Local intranet,

and then click

Sites.

Click Advanced, and then type: *.domain.com or an IP address range (for example, 157.54.100-200.*) in the Add this Web site to the zone box, where domain.com is the name for your company and top-level domain. Click
Add,

4 5

and then repeatedly click

OK

until the

Internet Options

window closes.

If you are using IE 5.0 or earlier, you will need to restart the computer.

To add *.domain.com or the appropriate IP address range using an automatic configuration script on the DC:
Warning - This procedure requires you to make changes to the Windows registry. Be sure that you understand how to use the registry before carrying out this procedure. If you use the registry incorrectly, you might cause damage requiring you to reinstall the operating system. Check Point does not take responsibility for any problems caused by changing the registry.

For each domain that should be included in the Local intranet zone, add a domain.com key to the following registry key under either HKEY_CURRENT_USER (for a currently logged-on user only) or HKEY_LOCAL_MACHINE (for all users on the local computer):
Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains
Note - Security zones settings are stored in the HKEY_CURRENT_US registry key. Because this key is dynamically loaded for each user, the settings for one user do not affect the settings of another. The local machine settings will only be used if the following key is present and it has a dword value of 1:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersio n\Internet Settings Security_HKLM_only

With this key enabled, machine settings are used instead of user settings.

Add a DWORD value named * (the asterisk character) to the it to 1.

domain.com

key and set

Chapter 3

Web SSO

121

Configuration

For each IP address range that must be included in the Local intranet zone, add a Rangex key (where x is 1, 2, 3, and so on) to the following registry key under HKEY_CURRENT_USER (for a currently logged-on user only) or HKEY_LOCAL_MACHINE (for all users on the local computer):
Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Ranges

4 5

Add a DWORD value named * (the asterisk character) to the 1.

Rangex

key and set it to

Add a String value named :Range (the colon character followed by the word Range) to the Rangex key, and then set it to the IP address range (for example, 157.54.100-200.*).
Note - This work around does not work for sites named according to the Universal Naming Convention (UNC) or file:// addresses that use an IP address. For example, \\157.54.100.101\share, or file://157.54.100.101/share, might be identified as being in the Internet zone, even if you add the appropriate IP address range to the Local Intranet Sites list. In this case, you must use a file:// URL that has the NetBIOS name (for example, \\server\share) for the site to be identified in the Local intranet zone.

Configuring Multiple Web Sites in SmartDashboard

Configuring multiple Web sites for UserAuthority WebAccess is the same as configuring the first Web site. If the two Web sites are set to the same UserAuthority WebAccess module (WAPS or WAPI), then you must differentiate between the two Web sites using the domain value. This configuration is done in the SmartDashboard WebAccess rule base. Carry out the configuration on the selected Web site in the URL tree. The following explanation assumes that the Web site objects are already configured in SmartDashboard. If they are not, see Configuring a Basic Web SSO Rule on page 85 for details on how to add a Web site Object. To configure another Web site on the same UserAuthority WebAccess module: 1 Double click one of the Web sites on the UserAuthority WebAccess module. The Web Site Properties window is displayed.

122

Configuring Multiple Web Sites in SmartDashboard

FIGURE 3-9

Web Site Properties Window Domain Tab

2 3 4

Click the Click

Domains

tab. window is displayed.

Add.

The

Domain Name

Enter the name of the fully qualified domain name of the web. (if using a WAPS, enter the virtual host domain).
Note - Domain names must be in lower case.

Click

OK

to close the Window. The new domain is displayed in the

List of web site

domains.

Note - Domain names must be in lower case.

6 7

Click

OK.

Repeat the above steps for each Web site on the UserAuthority WebAccess module.

Chapter 3

Web SSO

123

Advanced Configuration

8 9

Install the policy on WebAccess. Right-click a Web site in the URL tree and choose Install. A progress window is displayed. At the end of the installation process, click
Close.

Advanced Configuration
In This Section
Configuring UserAuthority WebAccess to Recognize Cache Proxy Users Configuring Manual Identity Sharing Options page 124 page 125

This section describes the configurations necessary to set up your system as described in the section, Special Scenarios on page 108.

Configuring UserAuthority WebAccess to Recognize Cache Proxy Users

In order for the WAPS to recognize a users computer when it makes a request via a cache proxy, a special header must be sent (see Web SSO with an Internal Proxy on page 108). Because UserAuthority WAPS only accepts requests from a trusted proxy, you must configure the trusted proxy IP addresses in the cp_ua_plugin.ini file. To configure trusted proxies: 1 Open the WebAccess configuration file cp_ua_plugin.ini and do one of the following: From the WAPS machine, type sysconfig. Then select 8 for Proxy Configuration > 2 for Advanced Configuration > 3 to open the
cp_ua_plugin.ini file

OR From the WAPI machine, browse to the installation folder and then to NG\Conf. The default folder is c:\ProgramFiles\CheckPoint\NG\Conf . Open the file. 2 3 Scroll to the PROXIES section. In the PROXIES section, find the subsection labeled [PROXIES]. In this section there are two lines:
;Trusted_Integrated_Proxies = ;Trusted_Generic_Proxies =

124

Configuring Manual Identity Sharing Options

Type the source IP of trusted third-party proxies that use the prev-connection header after the ;Trusted_Integrated_Proxies = line. Type the source IP of trusted third-party proxies that use the X-Forwarded-For header after the ;Trusted_Generic_Proxies = line. If there is more than one IP address for either line, separate the addresses with a comma (,). Use an asterisk (*) in the IP address to indicate wild cards (for example, if you want all IP addresses that begin with 191, then type 191.* in the IPs line). Save the file and close it. From SmartDashboard install the policy on WebAccess. Right click a Web site in the URL tree and choose Install. A window is displayed to show the installation process. At the end of the installation process, click Close.

5 6

Configuring Manual Identity Sharing Options

One of the greatest advantages of UserAuthority is its ability to extract the user identity from a Trusted Identification Point (TIP). UserAuthority establishes a trust relationship with TIPs on the network to ensure that it is receiving trusted information. UserAuthority searches the local hosts and servers to find the information necessary to carry out a request. If the information is not available locally, identity sharing is invoked to search other components in the deployment, for the information. Most deployments of UserAuthority use automatic identity sharing (default configuration). Automatic identity sharing searches each UserAuthority module on the same internally managed domain, for example Domain Controllers, Citrix machines and VPN peers, chaining them together to retrieve the user identity. This section describes how to configure manual identity sharing in UserAuthority. To set manual identity sharing options: 1 2 3 Using SmartDashboard, select the desired VPN-1 Pro (with UAS) Network Object on the Network Object tree, in the left-hand pane of the window. Double click the displayed.
VPN-1 Pro

Network Object. The

VPN-1 Pro Host

window is

Click UserAuthority Server on the tree, in the left pane of the window. The UserAuthority Server window is displayed.

VPN-1 Pro Host

Chapter 3

Web SSO

125

Advanced Configuration

FIGURE 3-10 UserAuthority Identity Sharing Options

In this window you can configure the settings for UserAuthority Servers (UAS) chaining, enabling you to retrieve user identity information from other UserAuthority Servers. 4 5 In the Configuration Method area, select options can now be configured.
Manual Configuration.

The identity sharing

Select one, or more options. UserAuthority determines the identity sharing priority according to the users point of entry. The last four options require you to select a group of UA Servers to be queried. To be able to do this, you must create a UAS group as explained in Creating UAS Groups on page 127. UserAuthority Servers on VPN tunnels endpoints: When a user enters the network via a VPN connection, the opposite end of the VPN tunnel is queried for the users identity.

126

Configuring Manual Identity Sharing Options

When a user authenticates to UserAuthority WebAccess, the UAS associated with the WAPS is queried for the users identity. When this option is selected, you must select the Server Group to be searched from the drop-down list. UserAuthority Server on Windows Domain Controllers: For users in a Windows domain, the Windows DC(s) are queried for the users identity. When this option is selected, you must select the Server Group to be searched from the drop-down list. UserAuthority Server on Citrix/MicroSoft Terminal Services: If a user uses resources via a Citrix/Windows terminal, UAS on a Terminal Server is queried for the users identity. When this option is selected, you must select the Server Group to be searched from the drop-down list. UserAuthority Server on Remote Access VPN Gateways: Searches for the users identity by querying all valid remote VPN gateways, not only VPN endpoints, for information. When this option is selected, you must select the Server Group to be searched from the drop-down list. 6 In the Export Policy area, specify the information that will be exported to externally managed UserAuthority Servers (that is, VPN peers that are not managed by this SmartCenter server). There is no restriction on information made available to internally managed UserAuthority Servers.
Note - Exporting of UserAuthority information can be done only between two VPN-1 gateways. The UserAuthority Server performing the query should be configured by enabling UserAuthority Servers over VPN tunnels. The UserAuthority Server supplying the information should be configured with an appropriate Export Policy. Both sides should have Security Policy rules that will allow the UserAuthority protocol ( FW1_uaa) using IKE, and encrypt it.

UserAuthority Servers that share WebAccess Authentication:

In the Logging Level area, select the logging level from the drop-down list. The following levels are available: Low: Logs all non-query related events, for example, loading policy, UAS up, UAS down. Medium: Logs all non-query related events and all query replies dealing with authentication failures. High: Also logs all queries and replies. Click
OK.

Creating UAS Groups 1 Create a UAS Group:

Chapter 3

Web SSO

127

Advanced Configuration

A In SmartDashboard, right click Groups in the Network Objects tree. From the shortcut menu, select New Groups > UserAuthority Server Group. The UserAuthority Groups Properties window is displayed. B Enter a name for the group in the C You can enter a comment in the
Name

field. field (optional).

Comment

D From the Not in group field, select the name you gave to the object containing the UAS. E Click
Add.

The selected Network Object is moved to the

In group

field.

F Click OK to close the window. The window should resemble FIGURE 3-11.
FIGURE 3-11 UserAuthority Group Properties Window

128

CHAPTER

Authorization for Web Applications

In This Chapter
The Challenge The UserAuthority Access Control Solution Access Control Policy Access Control Enforcement Access Control Scenarios Configuration page 129 page 130 page 131 page 132 page 134 page 137

The Challenge
Many enterprises need to provide special access to administrators and managers, while limiting or blocking other users access to specific information. For example, an enterprise might want to grant an administrator both read and write access to a specific application at all times, but grant read and write access to managers only during regular business hours. At the same time, the enterprise might want to only grant read access to regular users. This enterprise needs to find a solution that implements different authorization schemes for different users. Many enterprises provide services to outside customers or clients and need to ensure that users can access all information that is relevant to them, and only information that is relevant to them. For example, a Health Maintenance Organization (HMO) might want to grant members access to their medical records on the HMOs Web site. For reasons of security and privacy, access to this information must be restricted. It is

129

The UserAuthority Access Control Solution

important that members can view their own records without fear of others accessing them. In this case, the enterprise needs to be able to restrict access and provide secure connections, while ensuring members easy access to the correct records. Chapter 3, Web SSO describes how UserAuthority identifies and authenticates a user. However, this is not enough to enable the user to access the requested application. UserAuthority must also enforce security and authorization rules for each Web application.

The UserAuthority Access Control Solution

UserAuthority supports many types of access control scenarios to meet the challenges of diverse enterprises. UserAuthority enables you to assign specific access rights, such as write and read-only access, to users and Groups. In addition, you can also configure the required type of security connections to be used by a user or Group, such as access only through an encrypted connection.
Note - If the system works in Web SSO Only mode and authorization is also required, you must enable SSO with authorization. For more information, see Access Control with SSO-Only Web Site on page 145.

Access control can be configured to: Provide different users different authorization privileges for the same application. This is achieved by creating User Groups with different access rights. When a user signs on to the network, the user is matched to a User Group. The Authorization Requirements rule base is used to define which Groups can access a Web application and which operations can be carried out by each group. The Authorization rules define who is granted access to which sites, what type of access (e.g., Read only or Full access) and when the user has access. Enforce secure access to sensitive information. The Security Requirements rule base includes Trusts, which determine the security requirements for the requested Web application. Security rules can be set to determine whether or not: SSL encryption is enforced Limits on the location from where a connection can be accepted are enforced Limits to when a connection can be accepted are enforced Authentication or authentication type is necessary For more information, see: Access Control Policy on page 131 Defining Security and Authorization Rules on page 146.

130

Creating Security and Authorization Rules

Access Control Policy

An administrator creates an access control policy that limits the use of an application. This policy contains allowed operations and trusts, which determine how a user is authorized to access an application, and which specific users can access the application.

Creating Security and Authorization Rules

Security and Authorization rules are configured in SmartDashboards Web Access tab. You associate rules to a Web page or Web application that has a URL. To do this, you must create Web site and URL Objects in SmartDashboards Web Access URL tree. The URLs are listed hierarchically, so that a URL for a specific application may be subordinate to another URL. For information on creating Web sites, see Defining Web Sites on page 138; for information on creating URL Objects, see Defining URLs on page 145. After you create the Web sites, you can define the security and authorization rules in the rule bases. The rule bases are included in SmartDashboards Web Access tab, as follows: Security Requirements: This is the top rule base. Each rule satisfies a security requirement. These rules determine the security requirements for accessing a Web site or URL. In other words, how a user can accesses the URL for a specific operation. For example, an administrator can set up a rule for writing that allows outside LAN sources to access the Web server only if they use VPN encrypted connections, however, all internal connections are permitted. In order to authorize access, at least one Security rule must be defined. If there is more than one rule, the requirements for all rules must be met in order for a connection to be allowed. For information on assigning security rules, see Security Rules on page 148. Authorization Requirements: This is the middle rule base. An Authorization rule base defines rules that specify which users or User Groups are allowed to access sites and for which operations. For example, a rule can allow all users to read an internal Web site directory, and all sub-directory URLs below it. Administrators, however, can be given full administration rights when accessing the internal Web site. At least one rule must be satisfied for the connection to be authorized. In order to provide authorization, at least one authorization rule must be defined. For information on assigning authorization rules, see Defining a Basic Access Control Policy on page 147. All security and authorization rules have the following characteristics:

Chapter 4

Authorization for Web Applications

131

Access Control Enforcement

Scope determines whether a rule effects a URL that is subordinate to the Web page URL that is associated with the rule. A rule can apply to only the selected Web page or URL or it can be applied to all URLs subordinate to it in the URL tree. Exceptions allow you to exclude subordinate URLs from the defined scope. For example, a rule may be set allowing all employees to enter the main Intranet site and all of the subordinate department sites. However, the finance department site can be set as an exception. Operations: Operations explain the intention of a request (e.g., Read, Write). They are assigned to both security and authorization rules. You define operations in SmartDashboard by assigning a name, an HTTP method and parameters. For example, an operation that is defined with an HTTP operation of GET and no parameters allows read-only access. If you assign the GET method with parameters, such as mode=write, then the user who meets the authorization requirements is granted write access to the requested URL. For more information on how to assign operations to security and authorization rules, see Defining Security and Authorization Rules on page 146. For information on defining an operation, see Defining Operation Objects and Groups on page 154. Trusts: Trust Objects define the security requirements for a selected URL. Trust Objects can have one or all of the following security requirements: Encryption defines the types of encryption (SSL or VPN) methods that the user must use to enter the site. Authentication defines the Authentication Types (such as certificate authentication) that are required to access the selected URL. Networking defines from which locations a request can arrive and to which sites a request is authorized to go. Time defines when a user can access the URL.

Scope:

For information on creating a Trust Object, see Defining Trust Objects and Groups on page 159.

Access Control Enforcement

The security and authorization policies configured in SmartDashboard are downloaded to UserAuthority WebAccess to be used to direct the traffic for each incoming request to access a Web page. The first step in the authorization process is to match the requested Web page to its URL. The rules defined for this URL are used to determine whether or not the user is authorized to view or work on the page. In some cases the requested Web page is subordinate to a different URL. This is determined by the URL

132

Creating Security and Authorization Rules

scope (see Security Rules on page 148 for information on setting the rules scope). After matching the URL and Operations, UserAuthority WebAccess must verify the security and authorization rules. Security rules define the security requirements for requests to the URL. The security rule includes at least one Operation and one Trust. The Trust indicates the security requirements. These requirements indicate the conditions that apply to a request. If the Security Trust requires a connection over SSL, then any other type of connection will not be accepted. You must always create a security rule. If you do not want to have any security requirements, create a rule that allows Any Operation and Any Trust to access the URL. Any Trust indicates that UserAuthority WebAccess will accept any connection from any place at any time and Any Operation indicates that UserAuthority WebAccess will approve any kind of Operation. All security rules must be verified for the request to be accepted. After verifying the security requirements, UserAuthority WebAccess must verify the authorization requirements. Authorization requirements specify what a user can do and/or where a user or Group(s) can enter. The combination of one UserAuthority WebAccess Operation that allows for specifying the action (such as Read or Write) and the User Group gives the Web Administrator the ability to set the desired access control policy. Only one authorization rule must be verified for the user to be authorized. FIGURE 4-1 shows an example where a user meets only one rule. The user is a member of the Sales Staff Group. In this case the user is authorized based on rule 1, which grants read access to the Sales Staff Group. Rule 2 grants write access to the Sales Managers Group. The user does not meet the second criteria, however UserAuthority WebAccess will grant the user read-only access to the Web page based on rule 1.
FIGURE 4-1 Multiple UserAuthority WebAccess Authorization Rules

For more information on creating these rules, see Defining Security and Authorization Rules on page 146.

Chapter 4

Authorization for Web Applications

133

Access Control Scenarios

Access Control Scenarios

In This Section
User Groups with Different Authorization Levels Enforcing SSL Encryption on Connections page 134 page 136

The following examples show how to use the Security and Authorization rule bases for authorization in specific situations.

User Groups with Different Authorization Levels

An administrator can grant different access levels to the members of an organization. To illustrate how this works, consider the following example. FIGURE 4-2 shows the Security and Authorization rule bases and the rules for this example.
FIGURE 4-2 Sales Division URL Security and Authorization Rules

Bill is a manager in the sales department of a medium-sized company. Bill enters the enterprises network and requests the Updated_Sales_Assignments for his group. Before he can be authorized, he must be identified by UserAuthority (see Achieving User Identity on page 101 in Chapter 3, Web SSO).
134

User Groups with Different Authorization Levels

Once Bill is identified, UserAuthority WebAccess matches the Updated_Sales_Assignments to its URL. The rule base for this URL is used to determine whether Bill is authorized to view or work on the page. In this case, the Updated_Sales_Assignments list is subordinate to the Sales_Division URL. The rules for the Sales_Division URL have been applied to all subordinate Web pages. UserAuthority has now determined that the Web page that Bill requested can be accessed for both reading and writing without security requirements. UserAuthority must now verify the authorization rules to determine if Bill can work on this page. In this example there are two authorization rules. The first rule states that only Read access is granted to the Sales Staff Group and the second rule states that both Read and Write status can be granted to members of the Sales Managers Group. Since Bill is a member of both groups, he is granted both read and write access. If a member of Bills sales staff requested the same Web page, only read access would be granted because Sales Staff members do not meet the requirements of the second rule. For information on creating users and Groups in UserAuthority, see Managing Users and Groups on page 182. For more information on creating these rules, see Defining Web Sites on page 138.
Workflow

Follow steps 1-3 of the workflow for UserAuthority for Enterprise Web Applications in Workflow on page 31, OR steps 1-2 of the workflow for B2C deployment in Workflow on page 36. Create a Web site. See Defining Web Sites on page 138. If you already have an SSO-only Web site and you want to add an access control rule to it, see Access Control with SSO-Only Web Site on page 145. Create an access control policy. A Create a basic security requirements rule. See Defining a Basic Access Control Policy on page 147. Add only the security requirements rule. If you want to set up more elaborate security rules, see Security Rules on page 148. B Create authorization requirements that suit your enterprise. See Authorization Rules on page 150.

If you want to add SSO to the Web site, add a rule in the Application Settings rule base. See Defining a Basic Access Control Policy on page 147. You do not need to create the Web site, start from step 4.

Chapter 4

Authorization for Web Applications

135

Access Control Scenarios

Test Your Deployment

To test your deployment try to enter the Web applications as an allowed user and as a not allowed user.

Enforcing SSL Encryption on Connections

One type of enterprise that benefits greatly from UserAuthority authorization is a Health Maintenance Organization (HMO) that wants to provide its members with access to their medical records. This type of information is very sensitive and it is important that security measures are in place to prevent unauthorized individuals from viewing the information. In this case, you can create a trust in the security rules that requires the information to be encrypted. To do this, you must create a Trust Object that is defined to accept SSL encryption. Because most HMO members access their records from a home computer, SSL encryption is the only option. In the example in FIGURE 4-3, a Trust Object called Members was created. This trust requires SSL encryption so that the information cannot be viewed by others on the Internet. If a users browser does not support SSL encryption or it is disabled, the user will not be authorized.
FIGURE 4-3 Security Rule with a Trust that Requires SSL Encryption.

For more information on creating trusts, see Defining Trust Objects and Groups on page 159.
Workflow

Follow steps 1-3 of the workflow for UserAuthority for Enterprise Web Applications in Workflow on page 31, OR steps 1-2 of the workflow for B2C deployment in Workflow on page 36. Create a Web site. See Defining Web Sites on page 138. If you already have an SSO-only Web site and you want to add an access control rule to it, see Access Control with SSO-Only Web Site on page 145 Create an access control policy. A Create security requirements that suit your enterprise. See Security Rules on page 148.

136

Enforcing SSL Encryption on Connections

B Create a basic authorization requirements rule. See Defining a Basic Access Control Policy on page 147. Add only the authorization requirements rule. If you want to set up more elaborate authorization rules, see Authorization Rules on page 150. 4 If you want to add SSO to the Web site, add a rule in the Application Settings rule base. See Defining a Basic Access Control Policy on page 147. You do not need to create the Web site, start from step 4.

Test Your Deployment

To test your deployment, try to enter the Web applications as an allowed user and as a not allowed user.

Configuration
In This Section
Defining Web Sites Defining Advanced Web Site Options Defining URLs Defining Security and Authorization Rules Defining Operation Objects and Groups Defining Trust Objects and Groups page 138 page 141 page 145 page 146 page 154 page 159

This section describes the procedures for creating the UserAuthority WebAccess access control policy. All of the configuration takes place in the Security and Authorization rule bases. Before you can select the options to be configured, Web sites, URLs and special Objects (for example, Operations) must be defined in SmartDashboard. This section explains how to use SmartDashboard to configure UserAuthority WebAccess. It does not explain how to install and use SmartDashboard or any SmartDashboard features that are not related to UserAuthority WebAccess. For more information on SmartDashboard, see the Check Point SmartCenter Guide. UserAuthority WebAccess is configured in the WebAccess tab. This tab is not automatically available when you install UserAuthority WebAccess. Configuring UserAuthority WAPS in SmartDashboard on page 75 explains how to display this tab. The WebAccess tab has the following elements: A URL Tree B Security Requirements rule base
Chapter 4 Authorization for Web Applications 137

Configuration

C Authorization Requirements rule base D Application Settings - Effects rule base Access Control policy is configured for each URL in the Security Requirements rule base and the Authorization Requirements rule base, which are described in this section. For information on configuring the Application Settings - Effects rule base to establish SSO, see Configuring UserAuthority WebAccess Application Settings on page 87. FIGURE 4-4 shows the
FIGURE 4-4 WebAccess

tab and its elements.

WebAccess Tab in SmartDashboard

Defining Web Sites

In SmartDashboard, a Web site is the main node on a hierarchical tree. Subordinate pages and Web applications are defined as URLs. Each Web site and URL Object represents a real site or Web page in your network. When you create a new Web site Object, you must also define its properties.

138

Defining Web Sites

To create a new Web site and define its properties: 1 From the URL tree, right click Web Sites and select of the Web Site Properties window is displayed.
Web Site Properties Window New > Web Site.

The

General

tab

FIGURE 4-5

Enter the requested information in the fields: Name: Web site property name. Comment: Explanation of the property name (optional). Add an Enforcement WebAccess Module. This is the UserAuthority WebAccess that will enforce the rules that you configure on this Web site. A Click Add to select the UserAuthority WebAccess that will enforce the rules from the Select Check Point UA WebAccess Installed workstations window. B Select the WebAccess that will enforce the rules from the available list. C Click D Click
Add OK

to add it to the selected list.

to close the window. tab. This enables you to add, remove or edit Web domain

Click the names.

Domains

Chapter 4

Authorization for Web Applications

139

Configuration

FIGURE 4-6

Web Site Properties Domains Tab

5 6

Click

Add.

The

Domain Name

window is displayed.

Enter the name of the fully qualified domain name of the web (if using a proxy, enter the virtual host domain). The domain name must be in lower case letters. The domain name is the name of the domain that is used to access the Web site. Click OK to save the domain and close the window. The new domain is displayed in the List of web site domains.
Note - To edit a domain, select the domain from the List of web site domains and then click Edit to change the name of the domain. To delete a domain, select the domain from the List of web site domains and then click Remove.

8 9

Click

OK

to close the window and save the new Web site properties.

Repeat the above steps for each Web server on the UserAuthority WebAccess module.
Tip - To edit a Web sites properties, double click the Web site in the Web sites tree to open the Web Site Properties window for that Web site. Follow the directions in this procedure to make any required changes, and then click OK to save the new properties and close the window.

140

Defining Advanced Web Site Options

Defining Advanced Web Site Options

Advanced options include configuring the Web Site Advanced Properties and a Custom Rejection Policy. Advanced Properties Advanced properties include configurations for: Sub Sites IP Addresses Ports To display the 1
Web Site Advanced Properties

window:

In the General tab of the Web Site Properties window, click Advanced. The Web Site Advanced Properties window is displayed, with the Sub Sites tab open.
Web Site Advanced Properties Sub Sites Tab

FIGURE 4-7

Configure the following parameters in the Sub Sites tab of the Web Site Advanced Properties window: List of sub sites: Enter the URL prefix that you want to enforce for your domain. URLs defined for the Web site are always matched with the prefix preceding the URL. For example, if the name of the Web site is Company Divisions and a subordinate or subsite to Company Divisions is called Sales, the URL would be:

Chapter 4

Authorization for Web Applications

141

Configuration

Company Divisions/Sales Click Add to open Sub Site Token window. Enter a name and then click OK to close the window and return to the Sub Site tab. The new sub site is listed in the List of sub sites. A sub site is a site that is related to the main URL domain. This enables you to set a policy for the sub site only and not for the entire domain. For example, if your Web site is myEnterprise.com and you have a sub site called Sales, then you can set policy for the URL myEnterprise.com/sales only and not for the entire myEnterprise.com domain.
Note - You cannot have two sub site tokens where one contains the name of the other. For example, you cannot have two sub sites called Sale and Sales because the word Sale is contained in Sales.

Select a sub site from the the sub site.

FIGURE 4-8

List of sub sites

to edit the sub site name or to delete

Web Site Advanced Properties IP Addresses Tab

Configure the following parameters in the IP Addresses tab of the Web Site Advanced Properties window: List of IP addresses: The list of IP addresses which users can use to access the Web site if you have more than one interface and want to restrict entrance to only one.

142

Defining Advanced Web Site Options

Click Add to open the IP Address tab. Enter the IP address and then click OK to close the window and return to the IP Address tab. The new IP is listed in the List of IP Addresses. Select an IP Address from the List of IP Addresses to edit the IP address or to delete the IP address.
FIGURE 4-9 Web Site Advanced Properties Ports Tab

Configure the following parameters in the Ports tab of the Web Site Advanced Properties window: List of web site ports: The list of Port Numbers from which users can access the Web site. Click Add to open the Ports number window. Enter a port number and then click OK to close the window and return to the Ports tab. The new port is listed in the List of web site Ports. Select a port number from the List of web site Ports to change the port number or to delete the port, and click Edit or Remove as required. Click OR Click
OK

to confirm your selections. to return to the

Web Site Properties

Cancel

window.

Chapter 4

Authorization for Web Applications

143

Configuration

Custom Rejection Policy You configure the rejection policy in the Rejection Policy tab of the window. By default the policy is set to Reject. To define another policy: 1 Open the
Web Site Properties Web Site Properties

window and click the

Rejection Policy

tab.

FIGURE 4-10 Web Site Properties Rejection Policy Tab

Select the requested information: Reject: Select this option to reject all requests that do not meet the policy rules. Redirect to: Select this option to redirect requests that do not meet the policy rules to a different Web page. Enter the URL or IP address of the Web page in the designated field. Track: Indicate the type of tracking to use for this Web site:
None

Log: Creates log files. You must indicate Log in the rule bases. For information on reading the information contained in the logs, see Chapter 8, Auditing in UserAuthority and Chapter 12, Monitoring the UserAuthority Environment. Popup alert: Displays a pop-up with tracking information to be displayed each time the Web site is accessed.
144

Defining URLs

Click

OK

to close the

Web Site Properties

window.

Access Control with SSO-Only Web Site A Web site can be defined as an SSO-only Web site. An SSO-only Web site only has the Application Settings rule base applied to it in the Web Access tab of SmartDashboard. If you want to add access control rules to this Web site, you must change it to a regular Web site so that you can also add Security and Authorization requirements. To convert an SSO-only Web site to a regular Web site: 1 2 Right click the SSO-only Web site you want to convert. Select
Convert to WAC Web Site.

You will not see the effect immediately, however if you close the Web site and then select it again, all three rule bases are displayed. You can now set the access control policy as you would for any Web site.

Defining URLs
URL Objects can be added to each Web site that is defined. Each URL Object represents an actual Web page or Web application in your system. The URLs are added to the URL tree subordinate to the Web site. A URL can also be subordinate to another URL. The URL tree below shows an example of a URL called Updated_Sales_Assignments. This URL is subordinate to the Company Divisions Intranet Web site. It is also subordinate to two other URLs.
FIGURE 4-11 URL Tree

This URL would be entered into a Web browser as follows: http://<Website Domain>/Sales_Division/Bills Group/Updated_Sales_Assignments The Web site domain can be defined in the Domain tab of the Web Site Object (in the example above the Web site is Company_Divisions_Intranet) or it can be Any. For more information, see Defining Web Sites on page 138. To add a URL: 1 In the Web Access tab URL tree, right click a Web site or URL and select URL. The URL Properties window is displayed.
New >

Chapter 4

Authorization for Web Applications

145

Configuration

FIGURE 4-12 URL Properties Window

The new URL will be subordinate to the URL that you selected as well as to all other elements above it in the tree. 2 3 Enter a name or string for the URL in the Click
OK. URL String

field.

The new URL is added to the URL tree.

Defining Security and Authorization Rules

Once you have configured the Objects and URLs, you can begin to define rules in the rule bases. The security and authorization rules form the basis of UserAuthority WebAccess policy. This section describes how to create your own UserAuthority WebAccess policy to enforce access to the Web application. This section contains three parts: Defining a Basic Access Control Policy: Provides a step-by-step procedure for setting up a basic Access Control Policy (this is a policy that will Accept All or Deny All requests). Security Rules: Describes the Security rule base in detail. Use the table in this section to help you make the correct selections when defining security requirements for your enterprise. Authorization Rules: Describes the Authority rule base in detail. Use the table in this section to help you make the correct selections when defining authorization requirements for your enterprise.

146

Defining Security and Authorization Rules

Defining a Basic Access Control Policy Before beginning to define an access control policy, verify that: The necessary Web site and URL Objects have been created and they are displayed in the URL tree (see Defining Web Sites on page 138 and Defining URLs on page 145). UserAuthority WebAccess is installed and configured (see Installing and Configuring UserAuthority WAPS on page 70 or Installing and Configuring the UserAuthority WAPI on page 80). To define a basic authorization policy: 1 2 3 Select a Check Point Web site Object from the URL Tree. Click the
Security Requirements Must Satisfy All Rule Base

window.

Click the Add Rule Below button in the tool bar or select Rule > Add Rule > Bottom. This adds the rules fields to the base. The default settings are: Scope: Here and Below Operation: None Trust: None Track: None Scope: Leave the scope as
Operation: Here and Below.

4 5 6 7 8

Right click in the Operation field and select Add. From the Add Object window, click Any and then OK to close the window.
Trust:

Right click in the Trust field and select Add. From the Add Object window, click Any and then OK to close the window. Click in the window.
Authorization Requirements Allow if Match at Least One

Rule Base

Click the Add Rule Below button in the tool bar or select: Rule > Add Rule > Bottom. This adds the rules fields to the base. The default settings are: Scope: Here Operation: None Group: None Track: None
Scope:

Change the scope to

Here and below.

Chapter 4

Authorization for Web Applications

147

Configuration

10 11

Operation:

Right click in the Operation field and select Add. From the Add Object window, click Any and then OK to close the window.
Group:

Right click in the Group field and select Add. From the Add Object window, click Any and then OK to close the window.

12 Save the policy. 13 Install the policy on WebAccess. Right-click a Web site in the URL tree and choose Install. A progress window is displayed. At the end of the installation process, click Close. To set a
Deny All Deny Access

policy, leave all the rules set to None (the default). When you install a policy, a warning is displayed. Click to continue and ignore the warning.

Test your connection by opening a browser and try to enter the protected Web site. Depending on the policy you chose to create (Deny All or Accept All), you should now be allowed/not allowed to enter the site. Security Rules This section describes the options available for creating rules in the Security rule base. UserAuthority WebAccess attempts to match the conditions that you set. There are two stages to matching conditions: Checking to see if each operation matches the request. If the operation matches, the rule is retained, otherwise it is discarded. Matching the trusts (security requirements) for all remaining rules. All security requirements must be matched. If the trust doesnt match the remaining rules, the request is handled as defined in the rejection policy for the Web site.
Warning - All rules must match. You must have at least one security rule. FIGURE 4-13 Security Requirements rule base

148

Defining Security and Authorization Rules

The following table describes the options in the

TABLE 4-1

Security Requirements

rule base:

SmartDashboard WebAccess Security Settings

Field
Scope

Description The scope column indicates which URLs are affected by the Security Settings. To change the scope of a rule, right click the Scope column and select one of the following from the menu: Here & Below: All URLs below this node are effected by the settings. Here: Only this URL is effected by the settings. Where defined?: Where the rule is defined. Edit Exceptions: Check the URL to which the rule must apply. Operations describe the intention of the request, such as Read, Write or Delete. Operations are defined as Operations Objects. To select an operation: Right click the Operations field and select Add, then select an Operation from the Add Object window. Click OK to close the window. You can create your own operation. For information on how to define and create Operations Objects, see Defining Operation Objects and Groups on page 154. Trusts describe the security requirements. To select a Trust: Right click the Trust field and select Add. Then select a Trust from the Add Object window. Click OK to close the window. If you have not defined Trust Objects, no Trusts are displayed in the Add Object window. For information on how to define and create trusts, see Defining Trust Objects and Groups on page 159. You can select no tracking or choose to create a log. A log provides one line in the fwlog for every UserAuthority WebAccess request. To enable logs: Right click the Track field and select Log.

Operation

Trust

Track

Chapter 4

Authorization for Web Applications

149

Configuration

Authorization Rules Authorization Requirements define the privileges of users who enter your Web site or URL. In order to match conditions, UserAuthority WebAccess checks to see if there is an operation that fits the request. If it fits the request, the rule is retained, otherwise it is discarded. If the trust does not match the remaining rules, the request is handled as defined in the rejection policy for the Web site.
Warning - At least one Authorization Requirements rule is mandatory, however only one rule must be matched in order for a rule to pass.

If no operation rule matches the requested operation, the request is discarded. If there is a rule that matches the requested operation, the requesting user is matched to the group in the rule. If the user belongs to the group, the request is retained, if not it is discarded.
FIGURE 4-14 Authorization Rule Base

150

Defining Security and Authorization Rules

The following table describes the options in the

TABLE 4-2

Authorization Requirements

rule base:

SmartDashboard WebAccess Authorization Settings

Field
Scope

Description The Scope column indicates which URLs are affected by the Authorization Settings. To change the scope of a rule, right click the Scope column and select one of the following from the menu: Here & Below: All URLs below this node are effected by the settings. Here: Only this URL is effected by the settings. Where defined?: Where the rule is defined. Edit Exceptions: Check the URL to which the rule must apply. Operations describe the intention of the request, such as Read, Write or Delete. Operations are defined as Operations Objects. To select an operation: Right click the Operations field and select Add. Then select an Operation from the Add Object window. Click OK to close the window. You can create you own operation. For information on how to define and create Operations Objects, see Defining Operation Objects and Groups on page 154. Groups describe the users who can access an application and carry out the specified operation. To select a Group: Right click the Group field and select Add. Then select Group from the Add Object window. Click OK to close the window. If you have not defined Groups, no Groups are displayed in the Add Object window. For information on the how to define and create Groups, see Chapter 6, User Management in UserAuthority. You can select no tracking or choose to create a log. A log provides one line in the fwlog for every UserAuthority WebAccess request. To enable logs: From the Track field, right click and select Log.
Chapter 4 Authorization for Web Applications 151

Operation

Group

Track

Configuration

Advanced Configuration in SmartDashboard

The SmartDashboard Host window enables you to configure various options. This section describes the configuration options in detail and explains how to carry out some additional configurations that may be necessary when implementing Web SSO. To configure UserAuthority WebAccess: 1 From the SmartDashboard Network Object tree, double click the UserAuthority WebAccess Network Object (if there is more than one, select the one that you want to configure). The UserAuthority WebAccess Host window is displayed.
Note - If there is no UserAuthority WebAccess network Object in the Network Object tree, then you must add a network Object (see Configuring UserAuthority WAPS in SmartDashboard on page 75).

2 3

Click

UserAuthority WebAccess

WebAccess

on the left pane of the window. The window is displayed.

UserAuthority

Set the following parameters: UserAuthority Server: Select the location of the CheckPoint Host on which UserAuthority Server (UAS) is installed; this is usually the VPN-1 Pro Module. UserAuthority Server Service: The default setting does not need to be changed unless you have manually changed the service on the UAS. Action taken for URL outside the scope of the policy: The way in which UserAuthority WebAccess handles a URL that does not match the configured policy. Select one of the following from the drop-down list: Reject: This option is the default. No access is allowed for any request coming to any Web sites that are not defined in UserAuthority WebAccess policy, as applicable.
Warning - For security reasons, it is recommended that you leave the default option, Reject, selected.

Redirect:

the

Redirect URL.

Sends the request to a specific URL. Selecting this option activates Enter the target URL in the Redirect URL field.

Note - On redirection, do not redirect to a place where the request will be rejected or redirected again.

152

Advanced Configuration in SmartDashboard

Accept:

UserAuthority WebAccess allows access to URLs outside the defined URL tree.

Warning - This option may open a security hole.

UserAuthority WebAccess Advanced Configurations Window In the WebAccess Configuration window, click Advanced. The UserAuthority WebAccess Advanced Properties window is displayed.
FIGURE 4-15 UserAuthority WebAccess Advanced Properties

The following configuration options are available in this window: Limits and Timeouts: Maximal client request buffer size: Every HTTP request is divided into the HTTP Method and URI, the HTTP Header section, and the Content section. While the HTTP Request is processed, the first two parts are examined. In order to avoid overflow, set the limit of the Maximal URI size that should be used. The default value is 40 Kb.

Chapter 4

Authorization for Web Applications

153

Configuration

Communication to UserAuthority Server timeout: The amount of time that WebAccess waits for a response from the UAS before declaring that the connection is lost. The default is 5000 milliseconds (5 seconds). HTTP session timeout: To avoid constant communication with UserAuthority on every incoming request, all user data for a session is cached. A session is defined as a series of actions or requests carried out using the same browser against the same Web site. To ensure that data does not remain in the cache memory for an unlimited time, a Session Timeout needs to be defined. When a user is idle longer than the specified timeout, all information about the user is deleted. The default value of the timeout is 900 seconds (15 minutes). SSL: Select one of the following options from the drop-down menu: Redirect to original URL by HTTPS: This redirects to original URL by HTTPS, which means that HTTP at the beginning of the URL is replaced with HTTPS, causing the Web Server to perform SSL. Redirect to page: This redirects the request to a specified URL. Use this option when you want every encryption requirement to redirect to one specific page that has SSL. When this option is selected, the Redirect to URL field is enabled. In the Redirect to URL field, enter the URL. Windows Groups: The Get Windows group data for windows users option helps administrators monitor user and Group databases in the Windows environment, eliminating the need for costly migration from Windows to the VPN-1 Pro database or an LDAP database. Under specific conditions, UserAuthority WebAccess is able to access all Group data on users from the Windows environment and use it with UserAuthority WebAccess. When this option is selected, the Windows domain controller field is enabled. For information on how to configure Windows groups, see Users in the Windows Domain on page 184

Note - This option only works with UAS Version FP3.

Case Sensitivity: Select the Case sensitive naming URL names to be case sensitive.

conventions for URLs

checkbox if you want all

Defining Operation Objects and Groups

Operations describe the intention of a request. For more information on creating Operations, see Creating Security and Authorization Rules on page 131).

154

Defining Operation Objects and Groups

To create an Operation Object: 1 Right click the Operations field in any of the rule bases and select Add. OR From the SmartDashboard Manage menu, select UserAuthority > Operations. The Operation Objects window is displayed.

FIGURE 4-16 Operation Objects Window

Click New > Operation Object, OR Select an operation from the list and click

Edit.

Chapter 4

Authorization for Web Applications

155

Configuration

The

Operation Properties

window is displayed.

FIGURE 4-17 Operation Properties Window

Configure the following parameters in the General tab: Name: The operations name, for example, read. Comment: Descriptive text about the specific operation (optional). Color: The color of the operations icon. Select a color from the drop-down list to help in organizing the Operations Objects (optional). Click the
HTTP Request parameters

tab and enter the required information:

FIGURE 4-18 HTTP Request Parameters Tab

156

Defining Operation Objects and Groups

HTTP Method: GET POST DELETE HEAD Any

Select one of the following methods from the drop-down list:

Or you can enter any other HTTP method in the field. Query parameters: Self-defined URL application parameters. This parameter indicates a special attribute and is entered after the ? symbol in the URL (for example, www.myEnterprise.com/managers?cm=chart, where cm=chart is the query parameter). This allows a match for the rule when a user connects to the application with the specified parameters. Headers: Any HTTP headers associated with the operation. File extension: Specific extensions that are relevant, such as .asp or .dll. 5 Click
OK.

To create an Operations Object Group: 1 Right click an Operation field in any of the rule bases and select Add. OR From the SmartDashboard Manage menu, select UserAuthority > Operations. The Operation Objects window is displayed. Click New > Group, OR Select an Operation Group from the list and click The Group Properties window is displayed.

Edit.

Chapter 4

Authorization for Web Applications

157

Configuration

FIGURE 4-19 Group Properties Window

Configure the following parameters in the Group Properties window. Name: Enter the Group name. Comment: Enter descriptive text about the specific Group (optional). Color: The color of the Groups icon. Select a color from the drop-down list to help in organizing the Operations Groups (optional). View expanded group: If a selected object is a chained object, clicking View expanded Group shows the individual objects in the Group. To add an Operation Object or Group to this Group, select an Object or Group in the Not in Group list and click Add. The selected Object or Group is moved to the In Group list. To delete an Operation Object or Group from this Group, select any Object or Group in the In Group list and click Remove. The selected Object or Group is moved to the Not in Group list.

158

Defining Trust Objects and Groups

Defining Trust Objects and Groups

Trust Objects define the security requirements for the Web site or URL (for more information, see Creating Security and Authorization Rules on page 131). Trust Objects are defined in the Trust Objects window. Use this window to remove and edit Trust Objects or to define a new Trust Object. Creating a Trust Object To create a Trust Object: 1 Right click the Trust field in the Security rule base. OR From the SmartDashboard Manage menu, select UserAuthority The Trust Objects window is displayed.

> Trusts.

FIGURE 4-20 Trust Objects Window

Click New > Trust Object OR Select a Trust from the list and click

Edit.

Chapter 4

Authorization for Web Applications

159

Configuration

The

Trust Properties

window is displayed.

FIGURE 4-21 Trust Properties Window - General Page[

3 4

Enter the required information in the window. For a description of the parameters in this window, see Trust Object Parameters on page 160. Click OK to create and save the Trust Object.

Trust Object Parameters The Trust Properties window has five pages. The General page opens by default. The other pages are available only when specific security types are selected. This section explains the elements on each page.
General Page

The

General

page contains the following fields and options:

Name:

The Trust Objects name. Descriptive text about the Trust Object (optional).

Comment: Color :

The color of the Trust Objects icon. Select a color from the drop-down list to help in organizing the Trust Objects (optional).

160

Defining Trust Objects and Groups

Security Requirements: The type of security requirements that this trust will allow. If you do not make a selection, this trust will not allow any traffic to enter the Web site.

When you select a Security Requirement, it is displayed in the tree on the left side of the window. Click the name of the Security Requirement in the tree to define the Security Requirements properties.
Encryption Page

To display the Encryption page, click Encryption in the left pane of the window. If Encryption is not displayed in the tree, make sure that the Encryption checkbox is selected in the General page.

FIGURE 4-22 Trust Properties Window - Encryption Page

The Encryption page allows you to select one, both or none of the following encryption schemes: Allowed encryption schemes: VPN: Allows VPN encryption for users entering the Web site using a VPN client, such as SecuRemote or SecureClient. SSL: Allows users to enter the Web site using SSL encryption.

Chapter 4

Authorization for Web Applications

161

Configuration

Encryption type:

Desktop to Web Server Encryption:

Select this checkbox to allow encryption of information at its origin and decryption at its intended UserAuthority WebAccess destination with no intermediate decryption. Desktop to Web Server Encryption occurs in one of these cases: SSL to the Web Server/WebAccess Proxy Server (WAPS). Secure Server is installed on the Web Server and the SSL terminates in it.

Authentication Page

To display the Authentication page, click Authentication in the left pane of the window. If Authentication is not displayed in the tree, make sure that the Authentication checkbox is selected in the General page.

FIGURE 4-23 Trust Properties Window - Authentication Page

The Authentication page contains the following fields and options. Allowed user groups: This area is used to select the User Group that the trust recognizes.

162

Defining Trust Objects and Groups

Select the User Group that the Trust recognizes. For information on User Groups and how to define them, see Managing Users and Groups on page 182. Authentication methods: The authentication methods that the Trust allows. The available authentication methods are listed from the fastest to the most secure: Fixed Password: The password is set by Check Point or the Operating System. Token: Secure ID. Certificate: The password authenticates the certificate. If no authentication method is selected then all authentication methods are accepted.

Allowed:

Networking Page

To display the Networking page, click Networking in the left pane of the window. If Networking is not displayed, make sure that the Networking checkbox is selected in the General page.

FIGURE 4-24 Trust Properties Window - Networking Page

Chapter 4

Authorization for Web Applications

163

Configuration

Source: This area is used to determine how to handle networks entering the Web site. You can grant access to specific networks, or you can grant access to all networks except those indicated. Allowed: Select the networks that are allowed to enter the Web site. Note: If Negate is selected (below), then this field changes to Not Allowed to indicate those networks that cannot enter. Negate: Select this checkbox if you want to allow access to all networks, except those indicated. When this checkbox is selected, the Allowed field changes to Not Allowed. Enter the networks that are not allowed to enter the Web site in the Not Allowed field. Destination: This area is used to determine how to handle users leaving the Web site. The options are configured in the same way as for the Source.

Time Page

To display the Time page, click Time in the left pane of the window. If Time is not displayed, make sure that the Time checkbox is selected in the General page.

FIGURE 4-25 Trust Properties Window - Time Page

164

Defining Trust Objects and Groups

Time: This area allows you to determine when the Web site can be accessed. You can define specific time periods to allow access or you can allow access at all times except those indicated. Allowed: Select the time periods when access to the Web site is allowed. If Negate is selected (below), then this field indicates those times when access is not allowed. Negate: Select this checkbox if you want to allow access at all times, except those indicated. When this checkbox is selected, the Allowed field changes to Not Allowed. Enter the times when access is not allowed in the Not Allowed field. Note - At least one Time Object must be defined in SmartDashboard in order for a time to be displayed in the Allowed drop-down list. For information on creating a Time Object, see the Check Point SmartCenter Guide.

Creating a Trust Object Group To create a Trust Object Group: 1 Right click a Trust in the Security rule base. OR From the SmartDashboard Manage menu, select UserAuthority The Trusts Objects window is displayed (see FIGURE 4-20). Click New > Group, OR Select a Trust Group from the list and click The Group Properties window is displayed.

> Trusts.

Edit.

Chapter 4

Authorization for Web Applications

165

Configuration

FIGURE 4-26 Group Properties Window

Enter the requested information in the Group Properties window: Name: Enter the Group name Comment: Enter descriptive text about the specific Group (optional) Color: The color of the Groups icon. Select a color from the drop-down list to help in organizing the Trust Groups (optional). To add a Trust Object or Group to this Group, select any Object or Group in the Not in Group list and click Add. This adds the selected Object or Group to the In Group list. To delete a Trust Object or Group from this Group, select any Object or Group in the In Group list and click Remove. This returns the selected Object or Group to the Not in Group list. Click
OK

to save the Trust Object Group.

166

CHAPTER

Outbound Access Control

In This Chapter
The Challenge The UserAuthority Solution Retrieving Windows Groups with UserAuthority Outbound Access Control using Citrix Terminals as TIP Scenario - An Organization using Multiple Windows DCs Scenario - An Organization Using Multiple Domains Configurations page 167 page 168 page 171 page 172 page 172 page 174 page 176

The Challenge
Many enterprises grant their users access to external resources (such as the Internet) from the local network. The network administrator often needs to control the traffic that leaves the internal network. This can be achieved by: Restricting access to specific external resources for some or all users Auditing user requests for external resources For a variety of reasons, an enterprise may want to restrict users access to external resources. Internal policy may determine that users cannot access competitors Web sites to ensure that privacy is maintained, or that users can only access the Internet if their position in the enterprise requires it. In other cases, an enterprise may decide to limit Internet access to specific users, or allow differing levels of access based on the users position.

167

The UserAuthority Solution

In addition, an enterprise may want to keep track of users access of external resources, for example, the amount of time spent using external resources and which resources are being used. Many available security applications intercept and limit traffic entering and exiting various external networks and the Internet. A firewall, such as Check Points VPN-1 Pro, is one such solution that can also be used to monitor a local networks inbound and outbound traffic, providing the enterprise with valuable information regarding how each user is utilizing external resources. Users must authenticate to the security application each time they access an external resource. The added challenge here is to create Single Sign-On (SSO) for LAN users who are accessing external resources. UserAuthority provides Single Sign-On (SSO), eliminating the need to repeatedly submit credentials. SSO provides one-time authentication for all applications, which remains valid for subsequent access attempts. In this case however, UserAuthority requires no additional authentication if the user has already been authenticated by Windows.

The UserAuthority Solution

In This Section
Identification using SecureAgent Identity Sharing Using Outbound Access Control with Web SSO page 170 page 170 page 171

UserAuthority eliminates the need for authentication by retrieving the users identity from the Windows Domain Controller (DC) and providing it to VPN-1 Pro. In a system without UserAuthority, VPN-1 Pro requires authentication each time an external resource is requested, in order to identify the user and allow the users request to go through the VPN-1 Pro. In addition, without the ability to identify the user, there is no way to keep track of the outbound traffic. FIGURE 5-1 shows how outbound traffic is handled by the firewall in a system without UserAuthority.

168

FIGURE 5-1

Outbound Requests without UserAuthority

1 2 3 4 5

A user signs on to the domain and authenticates to the Windows DC. The user accesses an external resource. The VPN-1 Pro gateway intercepts the request and, based on the VPN-1 Pro policy (authorization or auditing), tries to authenticate the user. The user enters credentials for VPN-1 Pro and sends them back. VPN-1 Pro receives the credentials and grants the user access to the external resource.

UserAuthority provides the means to easily identify the user and keep track of user activities. If a UserAuthority Server (UAS) is installed on the VPN-1 Pro gateway and the Windows DC, identification is performed by UserAuthority, without the user having to authenticate to VPN-1 Pro. FIGURE 5-2 illustrates this process.
FIGURE 5-2 Outbound Request with Outbound Access Control

1 2

A user signs on to the Domain and authenticates to the Windows DC. UserAuthority SecureAgent is copied to the users desktop.
Chapter 5 Outbound Access Control 169

The UserAuthority Solution

3 4

The user accesses an external resource. The VPN-1 Pro gateway intercepts the request and, based on the VPN-1 Pro policy (authorization or auditing), queries the UAS installed on the gateway for the users identity. The UAS on VPN-1 Pro sends the request to the UAS on the Windows DC. The UAS on the Windows DC retrieves the user identity from SecureAgent on the users desktop. The identity is sent back through the Windows DC to the VPN-1 Pro gateway. The user is granted access to the external resource.

5 6 7 8

The examples described in this section show how UserAuthority solves the authentication problem by using the UserAuthority SecureAgent to identify the user.

Identification using SecureAgent

Outbound Access Control uses UserAuthority SecureAgent to identify the user. SecureAgent is automatically installed on all clients in the network, so there is no need for individual installation and configuration. UserAuthority SecureAgent is an executable that is installed and run on desktop computers in a Windows domain. SecureAgent identifies the user (who is signed on to the Windows domain) by responding to queries from the UAS installed on the domain. UserAuthority provides SSO, eliminating the need for the user to repeatedly submit his/her credentials. The Trusted Identification Point (TIP) for this scenario is the Windows DC and the UAS installed on the Windows DC provides the identification.

Identity Sharing
Identity sharing is used by the UAS to get the users identity from other UASes in the enterprises intranet. In the Outbound Access Control deployment, identity sharing is used by the UAS on the gateway to retrieve the users identity from the UAS on the Windows DC. By default, identity sharing is automatically configured in your deployment and sharing is implemented when the UAS associated with the WebAccess module does not have any information about the users identity. The default identity-sharing configuration is: If the request arrives over a VPN tunnel from another gateway, the UAS queries the UAS on the originating gateway.

170

Using Outbound Access Control with Web SSO

If the query contains a user key (user was authenticated by UserAuthority WebAccess authentication), then the UAS queries all UASes against which UserAuthority WebAccess authenticates. UAS queries all UASes on Windows DCs or Terminal Services.

Identity sharing can also be configured manually if it is necessary for your deployment. For information on configuring identity sharing, see Configuring Manual Identity Sharing Options on page 125. UserAuthority uses two protocols for identity sharing. The UAA protocol is used for communication between UASes, and the SSPI protocol is used for communication between the UAS on the Windows DC and UserAuthority SecureAgent.

Using Outbound Access Control with Web SSO

If you have a network with Web SSO deployed (see Chapter 3, Web SSO), it is possible to add Outbound Access Control functionality to the deployment. A Web SSO deployment includes: Internal Web servers UserAuthority WebAccess (WebAccess Proxy Server (WAPS) or WebAccess Plug-In (WAPI)) LAN users Remote users (with and without VPN client) UAS installed on a VPN-1 Pro gateway Workflow To add Outbound Access Control functionality to a Web SSO deployment. Perform steps 2-4 of the Outbound Access Control Workflow on page 36. Remote users do not benefit from the Outbound Access Control deployment, therefore this does not effect them. The internal Web servers and UserAuthority WebAccess also continue to function normally, and are not effected by adding Outbound Access Control.

Retrieving Windows Groups with UserAuthority

UserAuthority can retrieve Windows-defined groups for users identified by UserAuthority. This allows authorization to be handled on the VPN-1 Pro using pre-defined Windows groups.

Chapter 5

Outbound Access Control

171

Outbound Access Control using Citrix Terminals as TIP

Groups are defined in SmartDashboard to make it easier to administer large numbers of people. UserAuthority uses the Group data on users from the Windows environment to authorize users, eliminating the need to transfer data from Windows to the VPN-1 Pro database or to an LDAP database. This is done by creating Groups in SmartDashboard that correspond to the Groups in the Windows Domain. To do this, create a Group and give it the exact same name as its related Windows Group with the prefix WIN_<domain name>_. For additional information see Configuring UserAuthority to Recognize Windows User Groups on page 184.
Note - Using Windows groups with UserAuthority requires that UAS be installed on the Windows DC.

Outbound Access Control using Citrix Terminals as TIP

Users working on a Citrix or Terminal Services machine have no IP uniqueness because each machine connected to the terminal shares the same IP address. In this case, UserAuthority on the Terminal Services retrieves the user information and identifies the user through the connection information. Because the UAS on the Terminal Services can retrieve the connection information to identify the user, there is no need to use UserAuthority SecureAgent. When you configure VPN-1 Pro in this deployment, you must set Session Authentication in SmartDashboard. (See Citrix MetaFrame or Windows Terminal Services on page 42.)

Scenario - An Organization using Multiple Windows DCs

Some enterprises work with more than one Windows DC on a domain. In this case, the UAS on the VPN-1 Pro gateway may need to query various Windows DCs for user identification. Because the automatic identity-sharing configuration checks all UASes for user identification, no special configuration is required. This scenario is recommended for high availability. FIGURE 5-3 shows a deployment with more than one Windows DC.

172

Using Outbound Access Control with Web SSO

FIGURE 5-3

Outbound Access Control deployed with Multiple Windows DCs

1 2 3 4 5 6 7 8

A user signs on to the domain and authenticates to the Windows DC. UserAuthority SecureAgent is copied to the users desktop. The user accesses an external resource. The VPN-1 Pro gateway queries the UAS installed on the gateway for the users identity. The UAS on VPN-1 Pro queries the UAS on each Windows DC. UAS on the Windows DC retrieves the user identity from UserAuthority SecureAgent on the users desktop. The users identity is sent back to the VPN-1 Pro gateway from the first UAS to identify the user. The user is granted access to the external resource.

Workflow To deploy Outbound Access Control with multiple Windows DCs: 1 2 3 4 Install the UAS on the VPN-1 Pro gateway. See Installing and Configuring UAS on VPN-1 Pro on page 49. Install and configure UAS on the Windows DCs in your network. See Installing and Configuring the UAS on the Windows DC on page 61. Configure the system to automatically install SecureAgent on each of the Windows DCs. See Configuring SecureAgent Automatic Installation on page 68. From the SmartDashboard SSO Rule on page 39.
Security

tab, configure an SSO rule. See Adding an

Chapter 5

Outbound Access Control

173

Scenario - An Organization Using Multiple Domains

Test Your Deployment The deployment should work the same as with a single DC. Perform the steps described in Test Your Deployment on page 37 when logging in to each of the Windows DCs in the network.

Scenario - An Organization Using Multiple Domains

Some enterprises work with more than one Domain. In this case, the UAS on the VPN-1 Pro gateway may need to query the UASes on the Windows DCs in the different domains for user identification. Because the automatic identity-sharing configuration checks all UASes for user identification, no special configuration is required. This scenario requires installing a UAS on each domain. Each user identity in a Windows domain is defined with two parts, the domain and the user identity (usually the user name). By default, UserAuthority ignores the domain name when identifying a user. In this way, the user is recognized no matter which domain they are using. For example, domain1/Bill and domain2/Bill are recognized as the same user by UserAuthority. This is called domain equality. If you do not want UserAuthority to recognize the user as the same on all domains, you must manually configure the domain equality options. For information on configuring domain equality, see Configuring UserAuthority Domain Equality on page 177. FIGURE 5-4 shows a deployment with more than one domain.
FIGURE 5-4 SSO for VPN-1 Pro deployed with Multiple Domains

1 2

A user signs on to the domain and authenticates to the Windows DC. UserAuthority SecureAgent is copied to the users desktop.

174

Using Outbound Access Control with Web SSO

3 4 5 6

The user accesses an external resource. The VPN-1 Pro gateway queries the UAS installed on the gateway for the users identity. The UAS on VPN-1 Pro queries UAS on each Windows DC. The UAS on the Windows DC retrieves the user identity from SecureAgent on the users desktop. Only the UAS on the Windows DC where the user was authenticated can identify the user using SecureAgent.
Note - If a Windows Trust is established between the domains, then any domain can identify the user.

7 8

The identity is sent back to the VPN-1 Pro gateway. The user is granted access to the external resource.

Workflow To deploy Outbound Access Control with multiple Windows DCs: 1 2 3 4 Install the UAS on the VPN-1 Pro gateway. See Installing and Configuring UAS on VPN-1 Pro on page 49. Install and configure UAS on the Windows DCs in your network. See Installing and Configuring the UAS on the Windows DC on page 61. Configure the system to automatically install SecureAgent on each of the Windows DCs. See Configuring SecureAgent Automatic Installation on page 68. From the SmartDashboard SSO Rule on page 39.
Security

tab, configure an SSO rule. See Adding an

Test Your Deployment The deployment should work the same as with a single DC. Perform the steps described in Test Your Deployment on page 37 when logging in to each of the Windows DCs in the network.

Chapter 5

Outbound Access Control

175

Configurations

Configurations
In This Section
Adding Additional Windows DCs Outbound Access Control on Citrix or Windows Terminals Configuring UserAuthority Domain Equality page 176 page 176 page 177

The configurations for a basic Outbound Access Control deployment are in Chapter 2, Installation and Configuration on page 49. The sections below describe the configurations for the special scenarios described in this chapter.

Adding Additional Windows DCs

You can use a basic Outbound Access Control deployment and add additional Windows DCs. Workflow 1 2 Add as many additional Windows DCs as you need to your deployment. Install the UAS on each new Windows DC (see Installing and Configuring the UAS on the Windows DC on page 61). Dont forget to create a network Object in SmartDashboard for each of the new Windows DCs. Configure the system to automatically install SecureAgent on each of the Windows DCs. See Configuring SecureAgent Automatic Installation on page 68. Configure the system to automatically install SecureAgent from each of the Windows DCs. See Configuring SecureAgent Automatic Installation on page 68 Verify that an SSO rule is defined (see Adding an SSO Rule on page 39).

3 4

Outbound Access Control on Citrix or Windows Terminals

To deploy Outbound Access Control on Citrix MetaFrame Servers or Windows Terminal Services you must install UAS on the Citrix or Windows Terminal Services. UserAuthority gets the identification information from the connection, therefore SecureAgent is not required for Citrix. 1 Install the UAS on the VPBN-1 Pro gateway. See Installing and Configuring UAS on VPN-1 Pro on page 49

176

Configuring UserAuthority Domain Equality

Install and configure a UAS on each of the Citrix MetaFrame Servers or the Windows Terminal Services. See Installing and Configuring the UAS on the Windows DC on page 61. From the SmartDashboard Security tab, configure an SSO rule. See Adding an SSO Rule for Citrix MetaFrame or Windows Terminal Services on page 44.

Configuring UserAuthority Domain Equality

This section describes how to change the domain equality options. For more information on domain equality, see Scenario - An Organization Using Multiple Domains on page 174. To configure domain equality: 1 2 In the SmartDashboard Policy menu, select Global Properties. The Global Properties window is displayed. From the tree in the left pane of the window, click UserAuthority properties window is displayed.
UserAuthority.

The

Chapter 5

Outbound Access Control

177

Configurations

FIGURE 5-5

UserAuthority Global Properties Window

Select one of the following options: Trust all Windows Domains: This indicates that the firewall matches the user name no matter what comes before it. Therefore, a user is recognized from any domain.
Note - Trust all Windows Domains

is selected by default. This options allows you to indicate

Add

Trust only the following Windows Domains:

specific window domains to authenticate. To enter a domain name(e.g., Finance_Gurus), click Windows Domain name.

and enter the

178

Configuring UserAuthority Domain Equality

To remove a domain name, select the domain name and click 4 5 Click Click
OK. Install Policy

Remove.

from the tool bar to install the Policy.

Chapter 5

Outbound Access Control

179

Configurations

180

CHAPTER

User Management in UserAuthority

In This Chapter
Overview Managing Users and Groups Using a Local Check Point Database Using an External Database Using the Windows User Identity page 181 page 182 page 183 page 183 page 184

Overview
Managing users is a central part of UserAuthority because Single Sign-On (SSO), authorization and authentication rules are dependant on defining users and User Groups in the system. UserAuthority provides SSO, user authorization and auditing to users in an enterprise by identifying the user. If the system does not have a database of users, UserAuthority cannot carry out these functions. Users and User Groups can be managed in three ways: Using a local Check Point database in SmartDashboard (see Using a Local Check Point Database on page 183). Using an external database (for example, Radius, LDAP) (see Using an External Database on page 183). Using the users identity in the Windows domain (see Using the Windows User Identity on page 184).

181

Managing Users and Groups

Managing Users and Groups

In This Section
Users in UserAuthority User Groups in UserAuthority page 182 page 182

Users in UserAuthority
In order for UserAuthority to perform SSO, identification and authorization, it must have a database of users defined in the system. One of the advantages of UserAuthority is that it uses the same databases that are used by VPN-1 Pro, including LDAP databases or the VPN-1 Pro database. There is no need to create and define separate user databases and groups for each security-related module in the network.

User Groups in UserAuthority

User Groups are important in UserAuthority because the SSO for VPN-1 Pro policy and UserAuthority WebAccess policy can be defined in terms of User Groups. User groups are created or used for the following reasons: Defining UserAuthority WebAccess policy. UserAuthority WebAccess enforces authorization and authentication policy according to User Groups. Authorization rules are associated with specific Web applications (according to a defined URL). For more information on how to create UserAuthority WebAccess policy, see Configuring a Basic Web SSO Rule on page 85 and Access Control Policy on page 131. Defining client and session authentication actions in the VPN-1 Pro security policy. UserAuthority provides SSO for VPN-1 Pro authentication by creating an SSO rule in the VPN-1 Pro policy. User groups can be as part of a rule to indicate which users can access the requested resource. For more information, see Chapter 5, Outbound Access Control. Access control is based on User Groups and not individual users. Groups can be defined on the VPN-1 Pro local database, on an LDAP server, or based on Windows User Identity. For information on how to use these options, see: Using a Local Check Point Database on page 183 Using an External Database on page 183 Using the Windows User Identity on page 184

182

User Groups in UserAuthority

Using a Local Check Point Database

Check Points user management solution utilizing a local database is intended for small deployments, such as: Computer labs Enterprises with a small number of users and computers Users and User Groups in a local Check Point database are managed using SmartDashboard. The SmartDashboard hierarchical tree structure allows you to define users, User Groups and Administrators by right clicking the correct object tree. The Check Point local database is created on the Check Point SmartServer and is transferred to the VPN-1 Pro gateway when the policy is installed. In order to use this database with UserAuthority, you must be sure that the policy is installed on the VPN-1 Pro gateway where the UserAuthority Server (UAS) is installed. For information on creating and defining various users and groups in SmartDashboard, see the Check Point SmartCenter Guide.

Using an External Database

If you already have an external user management infrastructure in place, such as an LDAP, it is usually easier to use the existing user databases. UserAuthority and VPN-1 Pro support LDAP technology and use existing LDAP servers to obtain user information for authentication. If you have a large user account, it is recommended to use an LDAP system. Another advantage of using an LDAP database is that the information is external and can be shared by other systems. VPN-1 Pro, UserAuthority, and all other components in the Check Point security system act as LDAP clients. The SmartCenter Server (for example, SmartDashboard, SmartView Tracker, SmartView Status) can manage the information on the LDAP server. UserAuthority can use all of the information on the LDAP server to create policy for the UAS and UserAuthority WebAccess. To use the information on the LDAP database, you must define the LDAP server in SmartDashboard (see the section on defining an LDAP server in the Check Point SmartCenter Guide). Once the LDAP server is defined in SmartDashboard and connected, all users in the database can be used by UserAuthority. To use groups with UserAuthority over an LDAP server, you must create LDAP groups in SmartDashboard. This is done by creating a new LDAP group from the Users tree. LDAP groups are defined according to the LDAP tree (or subtree), a DN prefix, or by a defined filter. For a detailed description on how to manage Users with an LDAP server, see the Check Point SmartCenter Guide.
Chapter 6 User Management in UserAuthority 183

Using the Windows User Identity

Using the Windows User Identity

In This Section
Users in the Windows Domain Configuring UserAuthority to Recognize Windows User Groups page 184 page 184

Users in the Windows Domain

UserAuthority can take advantage of user databases in the Windows environment to identify users. This saves a costly migration from Windows to the VPN-1 Pro database or to LDAP. Windows groups in UserAuthority are used for Outbound Access Control and require the installation of UAS on the Windows Domain Controller (DC). To use Windows groups with UserAuthority, you must define groups in SmartDashboard according to the Windows group name. UserAuthority imports the group information from Windows and matches it to the groups you defined in SmartDashboard. For information on how to define these groups, see Configuring UserAuthority to Recognize Windows User Groups on page 184. You can maintain a database on the VPN-1 Pro Firewall and also use the Windows domain to identify users. In this case, you must ensure that user identity in the Windows Domains and in VPN-1 Pro are the same.
Note - By default, UserAuthority identifies the user from the Windows systems by the user name only, without the users domain.

Configuring UserAuthority to Recognize Windows User Groups

Windows groups are defined in a Windows Domain database, such as ActiveDirectory. In order to use Windows groups, a UAS must be installed on a Windows DC. To enable UserAuthority to use Windows Domain groups for Outbound Access Control, you must define a users group with the name WIN_<Domain Name>_<Windows Group Name> by doing the following: 1 From the The
Users and Administrators,

right click the

User Groups

object and select

New Group. Group Properties

window is displayed.

184

Configuring UserAuthority to Recognize Windows User Groups

FIGURE 6-1

Group Properties Window

2 3 4

In the

Name

Group Name>,

field, write a name in the form of WIN_<Domain Name>_<Windows for example WIN_INTUSERS_Managers.

Click OK to close the window. The new group appears under the User Groups object. Install the policy.

Chapter 6

User Management in UserAuthority

185

Using the Windows User Identity

186

CHAPTER

Web Security Features

In This Chapter
Overview Broken Access Control Broken Account and Session Management Remote Administration Flaws Web Server and Application Misconfiguration page 187 page 188 page 189 page 191 page 193

Overview
Web applications are vulnerable to attack, therefore Web application security is an important issue. Although it is impossible to completely eliminate the risk of attack at the application level, it is important to make every effort to reduce vulnerability to a minimum. Many different factors contribute to Web application vulnerabilities. HTTP requests to an enterprises Web site may include attacks on the application code. Because the requests themselves are legal, many of these requests are not caught by a firewall. The Open Web Application Security Project (OWASP) publishes a list of the top ten Web application vulnerabilities. These vulnerabilities are problems that can occur in an enterprises application security procedures. The list is intended to help organizations recognize potential risks in their Web application security. Check Points UserAuthority provides Web security at the application level. For this reason, it can address many of these vulnerabilities. This chapter discusses four Web application vulnerabilities and how UserAuthority can be used to handle them.

187

Broken Access Control

Broken Access Control

Access control, also called authentication/authorization, is how a Web application grants access to users. Authentication verifies a users identity and performs checks to ensure that the user is authenticated to continue. Based on authentication, other checks may be carried out to allow only authorized users to access the Web application. Access control is very difficult to manage. This is because the Web application must conform to the Web site content and function, and the various users accessing the application might belong to different groups, each with different privileges and roles. These problems make it difficult to implement access control. As users and applications are added over time, many of the methods used to implement access control are not well planned and, as a result, a group of disjointed and unorganized rules are used for authentication/authorization. These rules are difficult to follow or understand and therefore difficult to control. It is not hard to find a flaw in these rules. Once discovered, attackers can take advantage of such a flaw and cause major damage to the Web application and possibly the entire local network. Almost all Web sites are vulnerable to Broken Access Control. If your authentication or authorization design is not well documented, then you are particularly vulnerable. Good access control must be centralized, well-structured, and modular. Check Points UserAuthority is designed to provide authentication and authorization on the application level by creating organized, centralized and modular policies that are easy to understand. These policies are displayed in a simple GUI and can be easily documented. Many UserAuthority features can be used to prevent some of the most common problems associated with Broken Access Control, including: Separating the Access Control from the application: This relates to the security principle of leveling the defense. You can configure Access Control in SmartDashboard. For more information, see Chapter 4, Authorization for Web Applications. Insecure IDs: User IDs are vulnerable to theft. An attacker can access any part of a Web site using someone elses legitimate user ID. Web applications should not rely on secret IDs for access control. UserAuthority WebAccess allows you to require Token (SecureID) and Certificate authentication, which help protect against insecure user IDs. This is carried out in the Authentication tab of the Trust Properties window. For information on defining Trusts, see Defining Trust Objects and Groups on page 159.

188

Forced Browsing past Access Control Checkpoints: An attacker that gains access to a Web page that is deeper in the hierarchy than the sites home page might be able to bypass pages that were set up for access control. UserAuthority WebAccess policy can be configured to handle authorization to these pages. Directory Traversal: Users attempt to access a Web site using a relative path such as http://<server>/../../../winnt/system32/logs/theimportantlog.log. This might allow an attacker to access a Web page that would not normally be accessible or to which access would be denied if requested directly. UserAuthority WebAccess automatically resolves the relative path to a fixed path using canonicalization. This prevents an attacker from accessing a Web application using relative paths. File Permissions: Many files that are used for system management, such as configuration files, default files, and scripts, are sometimes located on the Web server machine. These files are vulnerable to attack if accessed. UserAuthority WebAccess policy can be configured to ensure that files on URLs that should not be accessed cannot be accessed. This is done by eliminating all of the rules for the URL. In this case, the UserAuthority WebAccess policy has no relevant access rule and no one can access the URL. For information on how to create UserAuthority WebAccess policies, see Defining Security and Authorization Rules on page 146.

Broken Account and Session Management

Account and session management refers to all aspects of handling user accounts and sessions. Strong and secure authentication procedures, as described in Broken Access Control on page 188, help in the handling of account and session management. However, poor credential management functions can weaken good authentication management. This can include problems such as users forgetting their passwords, or attackers updating a users account through phishing, the act of forging a legitimate Web site and getting a user to access the site for the purpose of phishing for the users credentials. Protecting against these vulnerabilities requires a strong method of authentication that cannot be counterfeited, hijacked, or stolen. UserAuthority WebAccess supports the use of strong identification for Web applications, without the expense of purchasing a special application and without the need to create a complex in-house session management scheme. This is carried out in the Authentication tab of the Trust Properties window. For information on defining Trusts, see Defining Trust Objects and Groups on page 159.

Chapter 7

Web Security Features

189

Broken Account and Session Management

Another vulnerability lies in how Web applications create sessions to keep track of user sessions. HTTP does not have the ability to create sessions, so each Web application must do this itself. If the session tokens are not protected, then it is possible for an attacker to hijack a session and take on the identity of another user. One way to hijack a sessions is called Session Fixation. This happens when a user sends an e-mail to another user. This e-mail contains a link with a session ID, such as http://iii.checkpoint.com/funfun.cgi?sessionid=1234. If the receiver clicks the link and authenticates, the indicated session (1234) opens. At this time the sender can enter the session using the receivers identity. UserAuthority WebAccess has capabilities that minimize these session-related vulnerabilities. These capabilities include: Randomized Session ID: UserAuthority provides session ID information by providing a session cookie to the client computer and the UserAuthority Server (UAS). The application uses this information to keep track of the user session. The session information on the UAS cookie is not accessible and the user key cannot be used to extract the information from it. In addition, because session ID numbers are assigned randomly, there is no way to guess the session ID. Session Timeouts: UserAuthority WebAccess allows you to set a time limit on the session. This prevents someone from using an old ID because the session will already have timed out. For example, an attacker is able to break the encryption and find a session ID. This takes some time because UserAuthority WebAccess session IDs are hard to get. If a reasonable timeout is set, the session will end before the attacker is able to use the session ID. The legitimate user is not effected because with Single Sign-On (SSO), a new session is created and user authentication takes place on behalf of the user. The user continues without interruption under a new session ID. Session timeouts are configured in the UserAuthority WebAccess Advanced Properties window. This window is accessed from the UserAuthority WebAccess tab of the Smart Dashboard WebAccess Network Object window. To configure session timeouts: 1 2 3 From SmartDashboard, double click the network object with UserAuthority WebAccess. The Network Object window is displayed. From the list on the left side of the window, click UserAuthority WebAccess. The UserAuthority WebAccess tab opens in the window. Click Advanced. The displayed.
UserAuthority WebAccess Advanced Properties

window is

190

FIGURE 7-1

UserAuthority WebAccess Advanced Properties Window

In the HTTP session timeout field, enter the amount of time a session is to remain active. The time entered is in seconds. The default value is 900 seconds (15 minutes).

Remote Administration Flaws

Remote Administration Flaws are vulnerabilities that take advantage of special administrator applications, which are used to allow administrators to effectively manage users in a local network. These applications are accessed through powerful remote interfaces that allow access to users applications. If an administrator Web application is attacked, damage can be caused to the entire local network. Some of the causes of this vulnerability include: the lack of a strong ID requirement; interfaces that are too powerful; the inability of the local network to provide a separate mechanism between users and administrators;
Chapter 7 Web Security Features

191

Remote Administration Flaws

the lack of documentation of administrator activities; the ability of attackers to get into the administrator application when the administrator is online and connected to the system.

UserAuthority WebAccess provides the capabilities to solve these problems in an easy and inexpensive way. Some of the specific problems and UserAuthority solutions include: Lack of strong ID requirements: Many administrator applications only require normal password and user identification for access. This is a high risk because this type of authentication is vulnerable to outsiders access, either by stealing the ID or spoofing. Using a strong ID system protects against this abuse. As described in Broken Access Control on page 188, UserAuthority WebAccess can be forced to require Token (SecureID) and Certificate authentication, which help protect against insecure user IDs. In this case, configure the administrator Web application to require Token or Certificate authentication when creating a Trust in the Authentication tab of the Trust Properties window. After a Trust with the appropriate ID requirements is created, create a rule in the Security Requirements rule base and enter the appropriate Trust in the Trust field or add the Trust to an existing UserAuthority WebAccess Security policy. For information on defining Trust and Security rules, see Defining Security and Authorization Rules on page 146. Poor session protection: Session protection is the ability to protect the administrator session from attack. Because an administrator works on other users accounts, an attack on an administrator session can be especially harmful. UserAuthority WebAccess can be configured to require any connection to the administrator URL to be made by SSL. This is configured when creating a Trust by selecting SSL encryption from the Encryption tab of the Trust Properties window. After creating the Trust, enter the Trust in the Security Requirements rule base for the UserAuthority WebAccess policy created for the administrator application. For information, see Defining Security and Authorization Rules on page 146. Poor documentation or auditing features: In many cases it is hard to know how many administrators are accessing the system and what they are doing. UserAuthority WebAccess auditing and logging features can help to track security problems in Web applications. Log creation is configured when creating a UserAuthority WebAccess policy by selecting Log in the Track field of the Security Requirements and Authorization Requirements rule bases. For information on using and configuring logs, see Chapter 8, Auditing in UserAuthority and Chapter 12, Monitoring the UserAuthority Environment.

192

Web Server and Application Misconfiguration

Web server and application server configurations are important to a Web applications security. Unpatched servers, defaults, file permissions, unnecessary service-enabled default accounts, administrative and debugging functions, errors, misconfigured and default certificates, and the use of self-signed certificates can cause security failures. Many of these problems can be easily detected and exploited by an attacker, which completely endangers the Web site. Some examples of areas where Web server misconfiguration is likely include the IIS administrative interface, old versions of PHP and Perl, and the installation of a Front Page development on a production server. Many precautions can be taken to guard against Web server misconfiguration. UserAuthority WebAccess enables implementation of many such precautions: Setting up roles, permissions, and accounts: This provides control over which administrators and users can configure parts of the system. UserAuthority works with administrator and user groups, which can be defined so that only specific people have access to important components in the network. For example, a group can be defined that allows only specific administrators to implement security policy. This can help limit the amount of problems with certificates in the system. For information on how to create groups with specific permissions, see Chapter 6, User Management in UserAuthority. Logging and alerts: Configuration problems can be easily tracked by logs and alerts in a system. Chapter 12, Monitoring the UserAuthority Environment, describes how UserAuthority uses logs and alerts to monitor system problems. Many security misconfigurations can be identified by reading the logs. Prevent access to specific files or Web applications: Network configuration often requires that some infrastructure services, such as databases or the IIS administrative interface, be installed directly on the Web server. Access to these services by regular users (especially a malicious attacker) could cause damage to the networks Web applications. UserAuthority WebAccess can be configured to lock users out of applications that should not be accessed. This is done by eliminating all of the rules for the URL. In this case, the UserAuthority WebAccess policy for the resource URL has no access rule. If there is no rule, then UserAuthority WebAccess is unable to grant access to anyone that requests the URL. For information on how to create UserAuthority WebAccess policies, see Defining Security and Authorization Rules on page 146. Limiting access to specific file types: In some cases, old file types can cause security problems in a network, such as old versions of PHP or Perl. With UserAuthority WebAccess, policies can be created to limit the file types that users can access. This is done by defining an Operation that specifies the file type for the Web applications on the URL.
Chapter 7 Web Security Features

193

Web Server and Application Misconfiguration

To specify a file type for a URL: 1 Create an Operation (see Defining Operation Objects and Groups on page 154). When creating the Operation, you must enter a file extension for the file type you want to specify in the URL. If there is already an Operation defined with the specific file extension, skip to step 5 on page 194. 2 Enter the file type in the File extension field of the window, HTTP Request Parameters tab.
Operation Properties

3 Finish creating the Operation, as described in Defining Operation Objects and Groups on page 154. 4 Add the Operation to the Web Access Policy. 5 In either the Security Requirements or Authorization Requirements rule base, right click the Operations field and then click Add from the shortcut menu. The Add Object window is displayed.
Note - To specify a specific file type for a URL, you can add an Object to either the Security Requirements or Authorization Requirements rules base, however, It is recommended that you add the Operation to both rule bases.

6 Select the Operation you created with the file extension specification. 7 Click
OK

to close the

Add Object

window.

8 Save and install the new policy or policy changes on UserAuthority WebAccess using SmartDashboard.

194

CHAPTER

Auditing in UserAuthority
In This Chapter
Overview Using Logs for Auditing Configuring UserAuthority for Auditing Customizing Logs page 195 page 196 page 206 page 210

Overview
UserAuthority uses the SmartView Tracker, Check Point's advanced tracking tool, to enable auditing of both UserAuthority Server (UAS) and UserAuthority WebAccess activities. Auditing enables you to: Troubleshoot security issues. Gather information for legal purposes. Generate reports and analyze traffic patterns. Generate logs in specific instances, for example, if the system is being attacked. Auditing in UserAuthority provides the following advantages: Auditing user requests (permitted and not permitted) for Web SSO and Outbound Access Control. Auditing successful and unsuccessful UserAuthority Identification and Authentication queries. Tracking UserAuthority WebAccess Authorization and Security Requirements as well as SSO activities.

195

Using Logs for Auditing

Auditing authenticated outbound requests, enabling you to keep track of all outbound traffic from the local network.

Using Logs for Auditing

In This Section
Auditing Outbound Traffic Using UserAuthority Outbound Access Control page 198 Auditing Web Access Using UserAuthority WebAccess page 201

Auditing in UserAuthority is performed using logs and alerts. UserAuthority and UserAuthority WebAccess can be configured to create logs for specific activities. These logs provide comprehensive information on network activity. You can analyze the information provided by the logs to get a complete picture of your UserAuthority system. The SmartView Tracker provides an interface that displays all of the logs generated in the system. Each log contains specific information about network activity. For an explanation of the information in the logs, see Auditing Web Access Using UserAuthority WebAccess on page 201 and Auditing Outbound Traffic Using UserAuthority Outbound Access Control on page 198. FIGURE 8-1 shows the SmartView Tracker interface.

196

FIGURE 8-1

SmartView Tracker

The SmartView Tracker display is divided into the following panes: 1 This pane displays pre-defined and custom queries. The queries in this pane that are important to auditing in UserAuthority are FireWall-1, UA WebAccess and UA Server. Double clicking these queries displays logs for the selected products only.
Query Properties pane: Query Tree pane:

This pane allows you to select and customize the properties displayed for each log record. To display a field, find the field name and select the adjacent checkboxes.

Records pane: This pane displays all the log records and the log information for each one. Double click on a record to open a window that displays the log information.

Chapter 8

Auditing in UserAuthority

197

Using Logs for Auditing

Another important feature of the SmartView Tracker is its filtering ability. Each query acts as a filter. Double click UA WebAccess in the Query Tree to filter the Records pane to display only logs from UserAuthority WebAccess, as shown in FIGURE 8-1. You can also filter other parameters. For example, filtering according to the UA Session ID enables you to display only the records from a single session, making it easier to track the activity for that session.
Note - For details on how to use the SmartView Tracker, see the Check Point SmartCenter Guide.

Auditing Outbound Traffic Using UserAuthority Outbound Access Control

When deploying a local network for Outbound Access Control, you can use the VPN-1 Pro logs to show which users are accessing which external resources. Although these logs contain many different fields, the fields that provide the information necessary to audit user activities are the User, Destination, and Information fields. FIGURE 8-2 shows a FireWall-1 Record Details window. If you do not see one of those fields, you should customize your view in the Query Properties pane. See SmartView Tracker on page 197.

198

Auditing Outbound Traffic Using UserAuthority Outbound Access Control

FIGURE 8-2

FireWall-1 Record Details Widow

The User, Destination, and Information fields in FIGURE 8-2 show the following: User: The user is identified as Administrator. This is the name of the user in the Windows domain. SecureAgent identifies the user at the Trusted Identification Point (TIP) according to the credentials entered when the user first authenticates to the Windows Domain Controller (DC). Destination: The Destination field indicates the IP address (66.102.11.104) for the requested external resource. This is used to identify the requested external resource. This field can also display DNS entries.

Chapter 8

Auditing in UserAuthority

199

Using Logs for Auditing

Information:

This field provides special information, including information on resources that are configured in the VPN-1 Pro SSO policy. You can configure an SSO rule to display the URL in the logs by creating a resource in SmartDashboard that obtains the Fully Qualified Domain Name for the requested resource. See Displaying the Resource Name in the Information Field on page 200.

Displaying the Resource Name in the Information Field To display the name of the URL in the SmartDashboard.
Information

field, you must create a resource in

To create a resource in SmartDashboard: 1 In the Resource tree, right click the Resource and select The URI Resource Properties window is displayed.
URI Resource Properties Window New -> URI.

FIGURE 8-3

2 3 4

In the In the

Name

field, enter a name for the URI resource. section, select

Optimize URL logging.

Use this resource to

Click OK to close the window. The URI resource appears in the Resource tree under URI.

200

Auditing Web Access Using UserAuthority WebAccess

When you create your SSO policy, you need to configure a Service with the resource you created in the Service field of the Security tab. To configure a service with the resource: 1 In the Security tab of the SmartDashboard, right click on the Service field and select Add With Resource. The Service with Resource window is displayed
Service with Resource Window

FIGURE 8-4

2 3 4

From the enabled.

Service

list, select the required service. The

Resource

drop-down list is

Select the URI Resource you created. Click

OK

to close the window.

FIGURE 8-5

SSO Policy Configure to Display the URL

In FIGURE 8-5, the Service field indicates that requests from the Sales Managers group are accepted with Client Authentication for the HTTP service with a URI resource named URL.

Auditing Web Access Using UserAuthority WebAccess

UserAuthority WebAccess logs provide information on the following: The flow of a users session based on the defined UserAuthority WebAccess policy
Chapter 8 Auditing in UserAuthority 201

Using Logs for Auditing

SSO Usage UserAuthority control information

FIGURE 8-6 shows log records that indicate the flow of a specific session. A session is opened each time a user opens the Internet browser to start surfing on the Web. A session can have one or more requests or activities. and each activity might generate a log, depending the UserAuthority WebAccess configuration. In the following example, three logs were generated.
FIGURE 8-6 Session Flow (Logging)

These log records indicate the following: Date of access: November 3, 2003. Time of Access: 10:20 in the morning. Product: UA WebAccess. This indicates that UserAuthority WebAccess created the logs according to the defined policy. For information on how to define UserAuthority WebAccess to create logs, see Configuring UserAuthority for Auditing on page 206. Service: This indicates that the request was made using the HTTP protocol or service. UA Session ID: This shows the UserAuthority Session ID. All logs for the same session have the same number. The UA Session ID number in the example shown is F88773E660A945E803. By filtering the display to show only a specific UserAuthority Session ID, you can easily track the flow of a single session. Comment: This describes what happened for each action or request in the session. Each action or request generates a log, unless you configure the system not to create a log for a specific type of request (see Disabling Specific Log Entries on page 211). In the example shown in FIGURE 8-6, the following three events occurred: New user (browser) was opened: This comment indicates that a user opened a browser to make a request. Headers added to the request as stated in policy: This indicates that a header was injected into the users HTTP request. This was done because the UserAuthority WebAccess SSO policy defined in the Application Settings Effects column, required a header to be injected. FIGURE 8-7 shows this policy.

202

Auditing Web Access Using UserAuthority WebAccess

FIGURE 8-7

UserAuthority WebAccess Policy with Insert Header

User request was authorized by WebAccess: This indicates that the user met the UserAuthority WebAccess policy guidelines and was granted access to whatever application was requested.

You can audit each specific activity more closely by double clicking the record to display the Record Details window. This window displays all of the log information for a specific activity or request. The Record Details window displays the information for the first activity shown in FIGURE 8-6. This window shows the information for each of the columns displayed in the Records pane for a single log record. This makes it easier to view all of the information, although it is not as easy to see the flow of single session. When you double click on a record in the Record Details window, you can use the Previous and Next buttons at the top of window to display the Record Details window for the adjacent log records. You can create a filter that displays only the activities of one session in the Records pane. Filtering the Records pane limits the records that can be accessed when you click the Previous and Next buttons, allowing you to more easily view the details for the logs in a single session. Auditing User Requests Each time a user requests a URL (that represents a Web application), a log is created. Based on the URL information contained in the logs, you can determine which applications are being accessed by which users. FIGURE 8-8 shows a list of logs in the Records pane of the SmartView Tracker. The URL column indicates the Web addresses accessed by Bill.

Chapter 8

Auditing in UserAuthority

203

Using Logs for Auditing

FIGURE 8-8

URLs in UserAuthority WebAccess Logs

A log is created for each UserAuthority action, such as authentication and SSO, therefore more than one log may indicate the same URL. From the sample log shown in FIGURE 8-8, a system administrator can determine that: Bill accessed the home page of the company Web site through a local server (URL: myserver.myEnterprise.com). UserAuthority carried out authentication on Bills behalf. (URL: myserver.myEnterprise.com/UserAuthority/cp_ua_action.aspP?original_url=/). Bill was returned to the company home page. Bill accessed a Web application called temp (URL: myserver.myEnterprise.com/temp). Bill accessed a default page from the temp application (URL: myserver.myEnterprise.com/temp/default). Auditing UserAuthority WebAccess Authorization Rejections When a user requests a URL without authorization (i.e., the user might not belong to a group that has access to the URL), UserAuthority WebAccess rejects or redirects the request depending on how the URL is configured to handle this situation. It is also possible to configure UserAuthority WebAccess to create a log each time this occurs. See Configuring Rejection Policy Logs on page 207 for information on configuring this option.

204

Auditing Web Access Using UserAuthority WebAccess

Other UserAuthority WebAccess Logs UserAuthority WebAccess allows you to generate additional types of UserAuthority WebAccess logs: SSO Rejection Logs: Log situations when a user attempts to access a Web application using a different name. For example, if Bill signs on to UserAuthority and then tries to access a Web application with a different set of credentials, UserAuthority WebAccess creates an alert. If you configure UserAuthority WebAccess to create SSO Abuse logs, a log is created for this alert. This is useful only if all Web applications use the same authentication credentials as UserAuthority. UserAuthority can map different user credentials to create SSO no matter what type of credentials are required by the application for authentication (see Mapping User Identity to Application Information by UserAuthority on page 106 for an explanation). In this case, however, if the authorization used for Web applications and UserAuthority are different, an alert is created each time. This option should not be used if users in your network have different authentication credentials for UserAuthority and Web applications. For information on how to configure this option, see Configuring SSO Abuse Tracking on page 209. Logs for actions taken for URLs outside the scope of the policy: URLs outside the scope of the policy are URLs that are not defined in your system. For example, you define a policy for URLs called www.myEnterprise.com/sale and www.myEnterprise.com/managers. A request arrives for www.myEnterprise.com/mgrs. This does not match any URL that you have defined, which might indicate that an unauthenticated user is trying to access the network. You can configure the system to create a log for these attempts to access URLs outside the policy scope. For information on how to configure this option, see Configuring Auditing of Requests for URLs Outside the Policy Scope on page 208.
Note - A full list of the logs provided by WebAccess is in the error.ini file on the WebAccess Proxy Server (WAPS). For information about the error.ini file and customizing the logs, see Customizing Logs on page 210.

Chapter 8

Auditing in UserAuthority

205

Configuring UserAuthority for Auditing

Configuring UserAuthority for Auditing

In This Section
Configuring Auditing of Requests for External Resources Configuring Auditing for UserAuthority WebAccess Configuring Rejection Policy Logs Configuring Auditing of Requests for URLs Outside the Policy Scope Configuring SSO Abuse Tracking page 206 page 206 page 207 page 208 page 209

This section describes how to configure UserAuthority to create logs that can be used for auditing.

Configuring Auditing of Requests for External Resources

Auditing of requests to external resources is performed using VPN-1 Pro logs. For a description on how to use these logs to audit outbound traffic, see Auditing Outbound Traffic Using UserAuthority Outbound Access Control on page 198. To configure the system to create VPN-1 Pro logs: 1 2 3 4 In SmartDashboard, click the
Security

tab.

In the Security tab, create a basic Outbound Access Control rule (see Adding an SSO Rule on page 39). To configure logging, right click
Track

and then select

Log.

Save the policy and install it on the firewall.

Configuring Auditing for UserAuthority WebAccess

Auditing of UserAuthority WebAccess requests is performed using UA WebAccess logs. For a description on how to use these logs to audit UserAuthority WebAccess requests, see Auditing Web Access Using UserAuthority WebAccess on page 201. To configure the system to create UA WebAccess logs: 1 In SmartDashboard, click the WebAccess tab. If the WebAccess tab is not available, see Configuring UserAuthority WAPS in SmartDashboard on page 75 for information on how to display it in SmartDashboard. Make sure that you have at least one basic Web SSO policy configured (see Configuring a Basic Web SSO Rule on page 85).

206

Configuring Rejection Policy Logs

To create logs for access control, do both of the following: In the UserAuthority WebAccess Security rule base, right click Track and then select Log. In the UserAuthority WebAccess Authorization rule base, right click Track and then select Log. To create logs for SSO requests, in the UserAuthority WebAccess Settings rule base, right click Track and then select Log. Save the rules and install them in UserAuthority WebAccess.
Application

4 5

Configuring Rejection Policy Logs

You can configure UserAuthority WebAccess to create logs each time a user is denied access to a Web site based on your UserAuthority WebAccess rules. For more information on Rejection Policy logs, see Auditing UserAuthority WebAccess Authorization Rejections on page 204. To configure UserAuthority WebAccess to create Rejection Policy Logs: 1 In SmartDashboard, click the WebAccess tab. If the WebAccess tab is not available, see Configuring UserAuthority WAPS in SmartDashboard on page 75 for information on how to display it in SmartDashboard. Make sure that you have at least one basic Web SSO policy configured (see Configuring a Basic Web SSO Rule on page 85). In the URL tree, double click the URL or Web site where you want to audit the rejection policy. The Web Site Properties window is displayed. Click the
Rejection Policy

2 3 4

tab.

Chapter 8

Auditing in UserAuthority

207

Configuring UserAuthority for Auditing

FIGURE 8-9

Web Site Properties Window Rejection Policy Tab

5 6 7 8

From the Click

OK.

Track

drop-down list, select

Log.

You can repeat steps 3 through step 6 for each Web site for which you want to generate Rejection Policy logs. Save the policy and install it on UserAuthority WebAccess.

Configuring Auditing of Requests for URLs Outside the Policy Scope

You can configure UserAuthority WebAccess to create logs each time a user requests a Web site that is outside the UserAuthority WebAccess policy scope. URLs outside the scope of the policy are URLs that are not defined in your system. For more information on requests outside the policy scope, see Other UserAuthority WebAccess Logs on page 205. To configure UserAuthority WebAccess to create logs for requests outside of the policy scope:

208

Configuring SSO Abuse Tracking

In the SmartDashboard Network Object tree, double click the network object for the UserAuthority WebAccess machine. If you have not created a UserAuthority WebAccess network object in SmartDashboard, see Configuring UserAuthority WAPS in SmartDashboard on page 75. The Check Point Host window is displayed. In the Tree pane, click is displayed. From the Click
OK. Track UserAuthority WebAccess.

2 3 4 5 6

The

UserAuthority WebAccess

tab

drop-down list, select

Log.

Save the policy and install it on UserAuthority WebAccess. You can repeat this procedure for each UserAuthority WebAccess where you want to log requests outside the scope of the UserAuthority WebAccess policy.

Configuring SSO Abuse Tracking

You can configure UserAuthority WebAccess to create logs each time a user authenticates with different credentials for a Web application and for sign in. This helps to track SSO abuse if all Web applications accept the same credentials as UserAuthority. For more information on SSO abuse, see Other UserAuthority WebAccess Logs on page 205. To configure UserAuthority WebAccess to create SSO Abuse Logs: 1 In SmartDashboard, click the WebAccess tab. If the WebAccess tab is not available, see Configuring UserAuthority WAPS in SmartDashboard on page 75 for information on how to display it in SmartDashboard. Make sure that you have at least one basic Web SSO policy configured (see Configuring a Basic Web SSO Rule on page 85). In the URL tree, click the URL or Web site where you want to audit the SSO abuse and then from the Effects field in the Application Settings rule base, double click Single Sign On. The Single Sign On window is displayed. If there are no URL objects defined in the URL tree, you must create one, see Defining URLs on page 145. Click the
Track

2 3

tab.

Chapter 8

Auditing in UserAuthority

209

Customizing Logs

FIGURE 8-10 Single Sign On Track Tab

5 6 7 8

From the Click

OK.

Track Method

drop-down list, select

Log.

Save the policy and install it on UserAuthority WebAccess. You can repeat step 3 through step 7 for each URL for which you want to generate SSO Abuse logs.

Customizing Logs
In This Section
Disabling Specific Log Entries Customizing Specific Log Entries page 211 page 212

The comment section of the UserAuthority WebAccess logs describes what occurs during a session. The list of specific comments is contained in a file called error.ini, which is located in the $UAGDIR/conf directory (in Windows c:\Program Files\CheckPoint\NG\Conf).

210

Disabling Specific Log Entries

The following shows some of the entries in the errors.ini file:

SendingUasQuery = CP_LOG|ADMIN_LOG|DEV_LOG, log, Querying_UA_Server. UasQueryReply = CP_LOG|ADMIN_LOG|DEV_LOG, log, UA_Server_Replied. OpenedNewSession = CP_LOG|ADMIN_LOG|DEV_LOG, log, New_user_session_(browser)_was_opened. AuthorizationSuccess = CP_LOG|ADMIN_LOG|DEV_LOG, log, User_request_was_authorized_by_UA_WebAccess. AuthorizationFailed = CP_LOG|ADMIN_LOG|DEV_LOG, Alert, User_request_was_not_authorized.

Each line of the file contains the following:

Name of comment=log_locations, log, the text displayed in the comment section of the log.

The error.ini file uses a code to indicate the log locations for each comment. If the comment can be sent to more than one log location, the location code is separated by a (|). The following are the log location codes: CP_LOG: This is the Check Point log. These logs can be viewed using the SmartView Tracker. OS_DEV: These logs can be viewed using the Windows Event Viewer. ADMIN_LOG: These logs can be viewed from the WebAccess Plug-In (WAPI) machine only. The logs are retrieved under wwroot\UA_logs. DEV_LOG: These logs can be viewed from the WAPI machine only. The logs are retrieved under $WADIR\logs. These logs are used by developers for debugging.

Disabling Specific Log Entries

You can edit the error.ini so that it does not display logs for specific actions. For example, if you disable the OpenNewSession comment, a log is not created when a user opens a new browser session even if you configured logs in SmartDashboard. You can choose to eliminate the text from all log file locations or selected locations. If you disable a specific comment from one log only, it will still appear in other log files. A log entry is created for all log locations that are not disabled. To disable specific log entries: 1 2 Open the error.ini file from the $WADIR/conf directory (in Windows c:\Program Files\CheckPoint\NG\Conf). Find the code line with the comment to be disabled.

Chapter 8

Auditing in UserAuthority

211

Customizing Logs

Delete the location code and the line (|) after it for the log location where you want to disable this comment. If you want to disable the comment from all logs, delete all the location codes including the comma (,) after the last code. Repeat this for each comment that you want to disable. Save the file. Restart WebAccess: A On the WAPS machine, type sysconfig and then 8 to enter the Proxy Configuration. B On the WAPI machine, from the command line: i Type net stop IIS admin and press Enter.

4 5

ii Type netstart W3SRV and press Enter.

Warning - When you change the text in the errors.ini file, you must be sure to use the same format used in the original message.

Customizing Specific Log Entries

The comment text that is displayed can be edited in the errors.ini file to meet your enterprises needs. To customize specific log entries: 1 2 3 4 5 Open the errors.ini file from the $UAGDIR/conf directory (in Windows c:\Program Files\CheckPoint\NG\Conf). Find the code line with the comment to be edited. Change the comment text. Repeat this for each comment that you want to edit. Save the file. Restart WebAccess: A On the WAPS machine, type sysconfig and then 8 to enter the Proxy Configuration. B On the WAPI machine, from the command line: i Type net stop IIS admin and press Enter.

212

Eliminating Logging of Graphics Files

ii Type netstart W3SRV and press Enter.

Warning - When you change the text in the errors.ini file, you must be sure to use the same format used in the original message.

Eliminating Logging of Graphics Files

If a Web page or application uses HTML Version 1.0, the browser recognizes each graphic file (i.e., GIF, JPEG, PNG) that is displayed as a request for a separate Web page or application. In this case, a log entry appears for each graphic that is included in the Web page. If a Web page contains a large amount of graphics, there will be many log entries, many of which might not be relevant to your auditing process. By default, UserAuthority WebAccess is configured to ignore all gif, jpeg, css, js, and pac files. You can configure the logging system to ignore requests for graphic files by editing the cp_ua_plugin.ini file. To disable the logging of graphics file requests: 1 Open the WebAccess configuration file cp_ua_plugin.ini and do one of the following: From the WAPS machine, type sysconfig. Then select 8 for Proxy Configuration > 2 for Advanced Configuration > 3 to open the
cp_ua_plugin.ini file

OR From the WAPI machine, browse to the installation folder and then to NG\Conf. The default folder is c:\ProgramFiles\CheckPoint\NG\Conf. Open the file. 2 3 Scroll to the OMIT_AUDIT_LOGS section. In the line Extentions=, delete the file type extensions for the file types for which you do not want to create log entries, and add file type extensions for the file types for which you want to create log entries. Save the file. From SmartDashboard, install the policy on the UserAuthority WebAccess.

4 5

Chapter 8

Auditing in UserAuthority

213

Customizing Logs

214

CHAPTER

High Availability and Load Balancing

In This Chapter
Overview Using Multiple UserAuthority WebAccess Servers Using Multiple Windows DCs Using a VPN-1 Pro Cluster page 215 page 216 page 222 page 222

Overview
In This Section
High Availability Load Balancing High Availability and Load Balancing in UserAuthority page 215 page 216 page 216

High Availability
High availability indicates that a product or system is available at almost all times. An accepted standard in high availability is called five nines, which indicates that a product system is available 99.999% of the time. Although this standard is rarely reached, a system or product should come close to this benchmark to be considered highly available. One way to ensure high availability is to use a cluster of two or more computers or servers. Each computer in the cluster performs the same job, however only one of the computers is active at a given time. All system updates are made to all of the computers

215

Using Multiple UserAuthority WebAccess Servers

in the cluster. If the main computer goes offline for any reason, another computer containing identical information is available to take its place - with no adverse effect on system performance. This also allows system administrators to perform maintenance tasks on the main computer without impacting on system availability.

Load Balancing
Distributing requests in high-traffic Web sites is called load balancing. Load balancing plays an important role in high availability because it ensures that a server will not go offline due to excessive traffic. Load balancing uses clusters to distribute traffic between servers. Requests are received by a managing computer that balances the traffic load. All of the computers in the cluster are active computers and hold identical information. The balancing computer receives the request and sends it to one of the computers in the cluster based on pre-configured criteria. In most cases, the configuration aims to evenly distribute traffic between the available servers.

High Availability and Load Balancing in UserAuthority

The UserAuthority Server (UAS) and UserAuthority WebAccess can be configured to provide both high availability and load balancing. Clusters can be set up and configured to ensure that network traffic to the security system is handled efficiently and virtually without interruption. The following areas can be configured or set up to provide high availability and load balancing: UserAuthority WebAccess Cluster UAS on a Windows Domain Controller (DC) UAS on the VPN-1 Pro gateways

Using Multiple UserAuthority WebAccess Servers

In This Section
Using UserAuthority WAPS Clusters Configuring WebAccess Cluster page 216 page 218

Using UserAuthority WAPS Clusters

The UserAuthority WebAccess Proxy Server (WAPS) provides Web security on the application level to multiple Web servers. Although the WAPS is used to support a system with multiple Web servers, all traffic routed to the Web servers must go through

216

Using UserAuthority WAPS Clusters

the WAPS. If this machine is unavailable or has too much traffic, the entire system is also unavailable. This problem can be handled by creating a cluster of UserAuthority WAPSes. Clustering is the use of multiple computers (or other types of devices) in one group with each computer doing the same job. Transparent to the user, a cluster acts as only one computer (or system) that is highly available. In the case of UserAuthority WebAccess, a cluster of WAPSes can be deployed to serve multiple Web servers. All of the WAPSes contain the same configuration (including the same virtual hosts) and can access the same Web servers. A balancing computer is employed to route the requests to each of the servers in the cluster in a balanced way. FIGURE 9-1 shows a cluster of three UserAuthority WAPSes. Each WAPS contains the same configuration and receives information from the same Web servers.
FIGURE 9-1 UserAuthority WAPS Cluster

In the configuration shown in FIGURE 9-1, the VPN-1 Pro gateway acts as the balancer for the UserAuthority WAPS cluster. When a user requests a Web application, the request is sent to the WAPS. The VPN-1 Pro intercepts the request and sends it to a UserAuthority WebAccess proxy that can handle the traffic. Each WAPS in the cluster can handle the same requests. In addition, this configuration contributes to high

Chapter 9

High Availability and Load Balancing

217

Using Multiple UserAuthority WebAccess Servers

availability. If one of the WAPSes goes offline, the other proxies can handle all requests. See Configuring WebAccess Cluster on page 218 for information on how to set up UserAuthority WebAccess for high availability and load balancing.
Note - If a UserAuthority WAPS goes offline while a user is authenticating or updating credentials, that authentication request or update will not be accepted even if there are multiple WAPSes as backup. In this case, the user must re-authenticate or update the credentials again.

In order to improve system performance, load balancing should be configured to always route the same user to the same WAPS during a single session. This is called stickiness or persistency. In this case, even if the WAPS to which the user was originally routed has more traffic than the others in the cluster, that users requests continue to go through the original WAPS. This is because the user is identified by a cookie that is placed on the users computer and the WAPS. For information on how to define persistency, see Creating a Logical Server Object on page 219.

Configuring WebAccess Cluster

In order for the VPN-1 Pro to act as the load balancer for a WAPS cluster, you must configure Connect Control. Workflow 1 2 3 Create a Server Group that contains the UserAuthority WAPS in the cluster. See Creating a New Server Group on page 218. Create a Logical Server object that contains your UserAuthority WebAccess cluster Server Group object. See Creating a Logical Server Object on page 219. Create a Security rule that contains your UserAuthority WAPS cluster Server Group object. See Defining a Security Policy for the UserAuthority WAPS Cluster Server Group on page 221. The Security rule should also contain HTTP and/or HTTPS as the Service.

Creating a New Server Group The first step in configuring Connect Control is to create a Server Group. This group should contain all of the UserAuthority WAPSes that are in the cluster. The UserAuthority WebAccess Cluster in FIGURE 9-1 contains three UserAuthority WAPSes called WAPS-1, WAPS-2, and WAPS-3. To create a Server Group, do the following in SmartDashboard: 1 From the
> Simple

tree, right click Network Objects and select Group. The Group Properties window is displayed.
Network Object

New > Groups

218

Configuring WebAccess Cluster

2 3

Enter a

Name

for the Group.

From the Not in Group list, select the UserAuthority WAPSes that are in the cluster. You can select the servers one at a time, or use the Shift or Control keys to make multiple selections. Click
Add

4 5

to add the selected object(s) to the

In Group

list.

When you have added all of the UserAuthority WAPSes to the Group, click OK to close the window. The new Server Group appears in the Network Object tree under Groups.

Creating a Logical Server Object The Logical Server is created to enable load balancing by a cluster. The Logical Server acts as the IP address that intercepts user requests and balances the load between the WAPSes in the cluster. The Logical Server Objects configuration enables you to define all of the parameters necessary for load balancing. To define a Logical Server, do the following in SmartDashboard: 1 From the Network Object tree, right click Network Objects and select Server. The Logical Server Properties window is displayed.
Logical Server Properties Window New > Logical

FIGURE 9-2

Chapter 9

High Availability and Load Balancing

219

Using Multiple UserAuthority WebAccess Servers

2 3 4 5

Enter a

Name

for the Logical Server. to which all requests to WAPSes in the cluster are to be (all UserAuthority WAPSes should be Other).

Enter the routed. Select the

IP Address

Servers type

From the Servers group drop-down list, select the name of the Server Group that corresponds to the UserAuthority WAPS (see Creating a New Server Group on page 218). Select the Persistent server mode checkbox. This is important to enable stickiness and ensure that all user requests for a session are routed to the same WAPS (see Using UserAuthority WAPS Clusters on page 216). Select the type of persistency: Persistency by service: Once a client is connected to a physical server for a specified service, subsequent connection to the same Logical Server and the same service are redirected to the same physical server for the duration of the session. Persistency by server: Once a client is connected to a physical server, subsequent connections to the same Logical Server (for any service) are redirected to the same physical server for the duration of the session.
Warning - Select Persistency by server for most deployments.

Select the Balance Method: Server Load: Assigns the WAPS to be used based on which server can best handle the traffic for the new connection.
Note - To use the Server Load option, you must install the CheckPoint Load Agent (CP LoadAgent) on each UserAuthority WAPS machine in the cluster. The agent is available on your installation CD.

Assigns the WAPS to be used based on the shortest round trip time between VPN-1 Pro and the servers. This is done by executing a simple ICMP echo request (ping). Round Robin: Assigns each WAPS in its turn. Random: Assigns the WAPS at random. Domain: Assigns the WAPS based on domain names.

Round Trip Time:

220

Configuring WebAccess Cluster

Defining a Security Policy for the UserAuthority WAPS Cluster Server Group In order to implement Connect Control, you must add the Server Group with the UserAuthority WAPS cluster to the source of your Security policy (for VPN-1 Pro). If a Logical Server with that group is defined, then Connect Control will take place for all requests from that source. You can also create a new Security policy with the Server Group in the source. For information on how to create a Security Policy, see the Check Point SmartCenter Guide. To add a Server Group to the source of a Security Policy: 1 In the SmartDashboard Security tab, right click the Destination field of an existing Security rule and then select Add from the shortcut menu. The Add Object window is displayed. From the Network Objects list in the Add Object window, select Logical Server that corresponds to your UserAuthority WAPS cluster. Click
OK

2 3 4 5 6 7 8 9

to close the window.

Service

Right click the

field and select HTTP and/or HTTPS.

Destination

Create a second rule and right click the window.

field to open the

Add Object

From the Network Objects list in the Add Object window, select the Server Group that corresponds to your UserAuthority WAPS cluster. Click
OK

to close the window.

Service

Right-click the

field and select

HTTP

and/or

HTTPS.

Save and install the policy on the VPN-1 Pro gateway.

FIGURE 9-3 shows an example of a rule base with load balancing configured. The first rule is configured to accept all connections that arrive in the UserAuthority WAPS cluster. The second rule is configured to ensure that HTTP traffic will not be dropped by VPN-1 Pro.
FIGURE 9-3 Load Balancing Rule

Chapter 9

High Availability and Load Balancing

221

Using Multiple Windows DCs

Using Multiple Windows DCs

UASes that are installed on the Windows DC do not contain any dynamic information that must be updated. Each time a query is made to the UAS, it sends the query to the users desktop to receive the user identity (through SecureAgent). In this case, high availability is easily achieved by installing the UAS in more than one location on the same Windows domain. No special configuration is required. The default Shared Identity option automatically queries each UAS until the users identity is established. If one UAS in the Windows domain is offline, the others will still be queried so that the user identity can be obtained.

Using a VPN-1 Pro Cluster

In This Section
Using VPN-1 Pro Clusters Synchronizing the Credentials Manager page 222 page 222

Using VPN-1 Pro Clusters

High Availability for the UAS on the VPN-1 Pro gateway is provided when there is more than one gateway. In this situation, the network is configured with VPN-1 Pro clusters. In each cluster, one VPN-1 Pro gateway is the primary gateway to which all requests are automatically routed. When the primary gateway is offline, requests go to the gateway that is designated as the secondary gateway. For more information on VPN-1 Pro clustering, see the Check Point Firewall Guide. To create high availability, install the UAS on each VPN-1 Pro machine in the cluster. One component of the UAS, the Credentials Manager, contains information that must be synchronized. For this purpose, UserAuthority provides a script called db_sync that ensures that the Credentials Manager on each UAS contains the same information at all times. Therefore, if one UAS goes offline and another takes over, users that are already signed on to the system can still be authenticated automatically.

Synchronizing the Credentials Manager

When UserAuthority identifies a user, it inserts the users credentials into requested applications using information stored in the Credentials Manager (see Mapping User Identity to Application Information by UserAuthority on page 106 for information about the Credentials Manager). When multiple UASes are deployed in a VPN-1 Pro

222

Synchronizing the Credentials Manager

cluster for high-availability purposes, the Credentials Managers for each UAS must be synchronized. This ensures that the user information is available if there is a failover from the primary UAS to another UAS in the cluster in the course of a users session. Automatic Synchronization The UASes on the same VPN-1 Pro cluster communicate through a special communications interface. When the main Credentials Manager is updated, updates are sent through this interface to the other Credentials Managers in the cluster. However, this interface can be offline, even if all the UASes are still operational. In this case, the updates will not be made. To ensure that all updates are made, you can configure the UASes to update the Credentials Managers simultaneously through all possible communications interfaces. To do this, you must change the default settings in the netso.ini file. To set UserAuthority to update all Credentials Managers multiple communications interfaces on each UAS: 1 2 3 4 5 6 Run uagstop. Find the netso.ini in the $uagdir\conf directory (for Windows the file is in the UAG\conf folder). Find the line cluster_update_chaining _only_to_main_ips = Type true after the (=) sign. Save the file. Run uagstart.
Note - This solution works when all UASes on the cluster are online. If a UAS is offline for any reason when an update is made, the Credentials Manager for that UAS will not be updated. In this case, you must manually update each Credentials Manager by running the db_sync script. For information on how to run the db_sync script, see Using the db_sync Script.

Using the db_sync Script You can sychronize the Credentials Managers on the same cluster by running the db_sync script. The script synchronizes Credentials Managers that are deployed with same exact information. You must run the script on the machine with the UAS that contains the Credentials Manager that needs to be updated. If there are more than two machines in the cluster, you must update each Credentials Manager individually.

Chapter 9

High Availability and Load Balancing

223

Using a VPN-1 Pro Cluster

To synchronize Credentials Managers: From the machine with the Credentials Manager that must be updated, run the script:
db_sync <Remote Gateways IP Address>

The IP address must be the IP address for the UAS with the Credentials Manager that has the updated information. The following message is returned: Synchronization successfully finished! If a problem occurs, the following error message is returned:
Synchronization error. Please try again or contact Check Point Support. Bad status received. The status is <reason for error>.

224

CHAPTER

10

UserAuthority CLIs
In This Chapter
UAS uas debug uas drv uas reconf uas d uas kill uas ver netsod debug netsod drv netsod d netsod kill netsod simple netsod simple kill netsod ver uas cpstop cpstart cprestart uagstop uagstart page 226 page 226 page 226 page 227 page 227 page 227 page 227 page 228 page 228 page 229 page 229 page 229 page 229 page 230 page 230 page 230 page 231 page 231 page 231 page 232

225

wastop wastart service wa_proxy sysconfig remote_wa_admin wac_ver ver uainfo

page 232 page 232 page 232 page 233 page 233 page 234 page 234 page 234

UAS
Description Usage The UAS command activates the UserAuthority Server (UAS) in NG with Application Intelligence or later.
UAS.

uas debug
Description Usage Usage Syntax This command is used to activate or deactivate the debug log directory.
uas debug on uas debug off

Argument

Description

on off Return Value

Writes development logs in the UA_log.elg directory. Stops writing logs in the UA_log.elg directory.

UAS debug already off UAS debug already on

uas drv
Description Usage Usage
226

This command is used to activate or deactivate a UAS on the device driver.

uas drv on uas drv off

Syntax

Argument

Description

on off Comments

Loads UAS device driver. Stops UAS device driver.

Note that all kernel information in the UAS is swapped when running uas drv off .

uas reconf
Description Usage Return Value This command reconfigures the UAS using the netso.ini file.
uas reconf UserAuthority: Reconfiguring using netso.ini file

uas d
Description Usage Return Value Comments This command initializes the UAS daemon.
uas d CheckPoint UserAuthority Server is already running.

If the UAS is not running, then a list of debugging outputs is returned.

uas kill
Description Usage Return Value This command shuts down all parts of the UAS.
uas kill UserAuthority Server is going down...

uas ver
Description Usage Return Value Comments This command displays the UAS version installed.
uas ver This is Check Point UserAuthority (TM) Server <version information>

The version information contains the name of the version and build.

Chapter 10

UserAuthority CLIs

227

Example

This is an example of a return value:

This is Check Point UserAuthority

(TM) Server NG with Application Intelligence (R 55) Build 047.

netsod
Description Usage The netsod command activates the UAS operation in modes prior to NG with Application Intelligence.
netsod

netsod debug
Description Usage Usage Syntax This command is used to activate or deactivate logging in the log directory.
netsod debug on netsod debug off

Argument

Description

on off Return Value

Writes logs in the UA_log.elg directory. Stops writing logs in the UA_log.elg directory.

Switching UAG to debug ON Switching UAG to debug OFF

netsod drv
Description Usage Usage Syntax This command is used to activate or deactivate UAS on the device driver.
netsod drv on netsod drv off

Argument

Description

on off

Loads the UAS device driver. Stops the UAS device driver.

228

netsod d
Description Usage Return Value Comments This command initializes the UAS daemon.
netsod d Check Point UserAuthority Server is already Running

If the UAS is not running, then a list of debugging outputs is returned.

netsod kill
Description Usage Return Value This command shuts down all parts of the UAS.
netsod kill UserAuthority Server is going down...

netsod simple
Description Usage Return Value Comments Turns on the netsod simple mode.
netsod simple <there is no return value>

netsod simple

is a mode of operation that allows you to manually send plain text messages (queries) to the netsod daemon using telnet port 19190. If the UAS is running in simple mode, it can translate the message and send a return. UAS is active in simple mode by default. You do not need to run this command unless simple mode was turned off.

netsod simple kill

Description Usage Return Value Comments Turns off the netsod simple mode.
netsod simple kill <there is no return value>

netsod simple

is a mode of operation that allows you to manually send plain text messages (queries) to the netsod daemon using telnet port 19190. If the UAS is running in simple mode, it can translate the message and send a return. UAS is active in simple mode by default. You do not need to run this command unless simple mode was turned off.

Chapter 10

UserAuthority CLIs

229

netsod ver
Description Usage Return Value Comments Example This command displays the UAS version installed.
netsod ver This is Check Point UserAuthority (TM) Server <version information>

The version information contains the name of the version and build. This is an example of a return value:
This is Check Point UserAuthority

(TM) Server NG Feature Pack 3 (R 55) Build 047.

uas
Description Usage Return Value Comments This command displays the command lines and the descriptions of each command available for the UAS.
uas uas d # initialize uas daemon uas renconf # Reconfigure UAS using netso.ini

This return value is a list of commands and their definitions. The above return is an example of the first part of the return.

cpstop
Description Usage Return Value Comments This command stops all Check Point product services running on the computer.
cpstop The Check Point UserAuthority Service is stopping The Checkpoint UserAuthority Service was stopped successfully

This return value is followed with a similar return for all other Check Point modules installed on the machine. The second line indicates the success or failure of the request.

230

cpstart
Description Usage Return Value Comments This command starts all Check Point product services running on the computer.
cpstart The Check Point UserAuthority Service is starting The Checkpoint UserAuthority Service was started successfully

This return value is followed with a similar return for all other Check Point modules installed on the machine. The second line indicates the success or failure of the request.

cprestart
Description Usage Return Value Return Value Comments This command stops and then automatically restarts all Check Point product services running on the computer.
cprestart The Check Point UserAuthority Service is stopping The Checkpoint UserAuthority Service was stopped successfully The Check Point UserAuthority Service is starting The Checkpoint UserAuthority Service was started successfully

These return values are followed with similar messages for all other Check Point modules installed on the machine. The second line indicates the success or failure of the request.

uagstop
Description Usage Return Value Comments This command stops the UAS installed on the computer.
uagstop The Check Point UserAuthority Service is stopping The Checkpoint UserAuthority Service was stopped successfully

The second line indicates the success or failure of the request.

Chapter 10

UserAuthority CLIs

231

uagstart
Description Usage Return Value Comments This command starts the UAS installed on the computer.
uagstart The Check Point UserAuthority Service is starting The Checkpoint UserAuthority Service was started successfully

The second line indicates the success or failure of the request.

wastop
Description Usage Return Value This command stops the UserAuthority WebAccess agent (WebAccess Proxy Server (WAPS) or WebAccess Plug-In (WAPI)) installed on the computer.
wastop Stopping WA_Proxy Stopping WebAccess Remote Agent WebAccess Remote Agent Stopped

Comments

The first return value line indicates whether UserAuthority WebAccess is a WAPS or WAPI.

wastart
Description Usage Return Value This command starts the UserAuthority WebAccess installed on the computer.
wastart WebAccess Remote Agent already running

service wa_proxy
Description Usage Usage Usage This is a Unix service command that is used to activate, deactivate, or restart the UserAuthority WAPS. It is used only on Apache servers.
service_wa_proxy on service wa_proxy off service wa_proxy restart

232

Syntax

Argument

Description

on off restart

Activates UserAuthority WAPS. Stops UserAuthority WAPS. Stops and then automatically restarts UserAuthority WAPS

sysconfig
Description This command displays a menu with commands that are used for configuring UserAuthority WebAccess. These configurations include defining the virtual hosts for the WAPS and setting the common domain name.
sysconfig

Usage Comments

The main configuration menu is returned when running this command. Each menu item is explained in the interface and in other chapters of this user guide.

remote_wa_admin
Description This command lists the UserAuthority WebAccess debugging and OPSEC debugging options. If using the SecurePlatform, you must be in expert mode to execute this command.
remote_wa_admin Commands: Stop Stops the remote_wa daemon debug_on Stars logging the debug message

Usage Return Value

Comments

The return lists the following commands: Stop debug_on debug_off debug_OPSEC_on debug_OPSEC_off

Chapter 10

UserAuthority CLIs

233

wac_ver
Description Usage Return Value Comments This command displays the UserAuthority WebAccess version and build number.
wac_ver This is Check Point UserAuthority (TM) WebAccess <version information>

The version information contains the name of the version, its number and build. This is an example of a return value:
This is Check Point UserAuthority

Example

(TM) Server NG Feature Pack 3 (R 55) Build 51000001.

ver
Description Usage Return Value Example This command is used on machines that are running Check Points SecurePlatform. It displays the SecurePlatform version and build number.
ver This is Check Point SecurePlatform <version information>

This is an example of a return value: This

is Check Point SecurePlatform

NG with Application Intelligence Build 51000001.

uainfo
Description This command is executed on the UserAuthority WAPS machine. It creates a file with all configuration information. The file is named uainfo_data.tar and is located in the opt/CPwa-50-03/uainfo directory. If you are using the SecurePlatform, you must be in expert mode to execute this command.
uainfo ****copying Apache log files**** ****Generating status info**** ****Doing tar for all files****

Usage Return Value

Comments

The return lists the following configuration files that are summarized in the uainfo_data.tar file:

234

HKLM_Registry.data WA_ADMIN.log apache_access_log apache_error_log apache_ssl_log cp_ua-plugin.ini cpshared_value dev_log.log httpd.conf machine_info.txt wa.binding.log was_objects.C was_ver_value

Chapter 10

UserAuthority CLIs

235

236

CHAPTER

11

UserAuthority OPSEC APIs

In This Chapter
Overview Programming Model Function Calls Event Handlers page 237 page 237 page 251 page 260

Overview
Check Points OPSEC (Open Platform for Security) integrates and manages all aspects of network security through an open, extensible management framework. Third-party applications can plug into the OPSEC framework through published application programming interfaces (APIs). Once integrated into the OPSEC framework, the security aspects of these applications can be configured and managed from a central point, utilizing a single Security SmartDashboard. For information about how to integrate third-party HTTP Proxies with Check Point UserAuthority, see Web SSO with an Internal Proxy on page 108.

Programming Model
In This Section
Defining a UAA Client Client Server Configuration OPSEC UserAuthority API Overview page 240 page 240 page 241

237

Programming Model

UserAuthority API (UAA) provides third-party application servers with network security information from various Check Point products, such as VPN-1 Pro, SecuRemote/SecureClient. This enables the application servers to use Check Points security mechanisms rather than implementing their own. FIGURE 11-1 illustrates the system architecture.
FIGURE 11-1 System Architectures

Note - If the original connection comes from a LAN, then it can be sent through a UAA server on the Domain Controller or a Citrix/Terminal services.

The desktop connecting to the application server can also use VPN-1 SecuRemote or VPN-1 SecureClient. VPN-1 SecuRemote enables PC users to securely communicate sensitive and private information over untrusted networks by encrypting and decrypting information leaving and entering their computers.

238

VPN-1 SecureClient enables administrators to enforce a security policy on desktops and prevents unauthorized users from taking control of authorized connections. When the SecureClient connects to the Policy Server from which it obtains its desktop policy, the Policy Server can verify the SecureClient machines configuration and deny access to misconfigured machines. The UAA server resides on a VPN-1 Pro Module and collects information about the connections made through that module. This information might include: Connection Sign-On Information: The network security information associated with a specific connection, including user information (user name, distinguished name (DN), and group membership), authentication scheme, and type of encryption. Client Sign-On Information: The network security information associated with a specific IP Address, including user information, authentication scheme, and whether the SecureClients configuration is secure. Credential Management Information: The UserAuthority server can store and provide user credentials for several authentication domains (user name and password) to enable Single Sign-On and enhanced security. The UserAuthority Server collects information about the logins made to the local network. This information might include NT domain controller logon, DHCP, and RADIUS authentications. The UserAuthority Server also keeps historical information for logging purposes, which can be accessed through the UserAuthority Administration Server. The types of connections made through VPN-1 Pro for which information is collected are shown in TABLE 11-1.
TABLE 11-1

Network Security Information Collected by UAA Collected When Information Includes*

Type of Information

Connection Signon information

A connection is made through a Security Policy rule specifying User, Client, or Session Authentication. A SecuRemote connection is made. A VPN connection is made.

UI, AS

UI, AS, ET ET

Chapter 11

UserAuthority OPSEC APIs

239

Programming Model

TABLE 11-1

Network Security Information Collected by UAA Collected When Information Includes*

Type of Information

Client Signon information

A user logs onto a Client Authentication Server. SecuRemote executes a key exchange with VPN-1 Pro. A SecureClient user logs onto a Policy Server.

UI, AS UI, AS UI, AS, SCS

* Information includes: AS: Authentication Scheme ET: Encryption Type SCS: SecureClient Secure UI: User Information When an application server needs information about a client or connection, the UAA client sends a query to the UAA server. This query includes a key to the connection or event. Based on this key, the UAA server retrieves the appropriate information and passes the requested data back to the client. The UAA server and the UAA client use a separate connection for communication. This enables the application server to identify the user before responding. Communication between the UAA client and the UAA server is implemented using the OPSEC framework. For a more detailed overview of UAA and various usage scenarios, see OPSEC UserAuthority API Overview on page 241.

Defining a UAA Client

The procedure for integrating a UAA Client with VPN-1 Pro can be divided into two parts: Configuring communication between VPN-1 Pro and the UAA Client. Creating queries, sending them to the UAA server, and processing the replies. This is described in detail in OPSEC UserAuthority API Overview on page 241.

Client Server Configuration

For information on configuring OPSEC UserAuthority clients and servers, see ClientServer Connection in the Check Point VPN-1 Pro OPSEC API Specifications.

240

OPSEC UserAuthority API Overview

For information on configuring UAA clients in the Check Point Management, see Server Objects and OPSEC Applications in the Check Point SmartCenter Guide.

OPSEC UserAuthority API Overview

The OPSEC UserAuthority API and the OPSEC API provide functions for querying, updating and carrying out authentication against the UAA server, and processing replies.

Chapter 11

UserAuthority OPSEC APIs

241

Programming Model

UAA Client Application Structure A UAA clients main function should flow as shown in FIGURE 11-2.
FIGURE 11-2 UAA Client Application Structure

When the OPSEC environment and the UAA session are initialized, a request is sent to the UAA server. The main loop then waits for a reply to arrive and processes it. Requests and replies are handled by the OPSEC UserAuthority API functions. The main loop is terminated by the underlying OPSEC level. After termination, the OPSEC entities and environment are freed.
242

OPSEC UserAuthority API Overview

For more information on uaa_new_session and uaa_end_session, see Session Management on page 251. Event Handling The UAA client responds to the UAA_QUERY_REPLY event handler, UAA_UPDATE_REPLY event handler, and UAA_AUTHENTICATE_REPLY event handler. These events are triggered when a reply from the server becomes available. The response to these events is handled by the event handlers (callback functions) set in the call to opsec_init_entity for the client entity. These callbacks are set using the attributes listed in TABLE 11-2
TABLE 11-2

opsec_init_entity - UAA Entity Type Values Type Meaning

Value UAA_QUERY_REPLY_HANDLER

handler handler handler

The event handler for the

UAA_QUERY_REPLY.

UAA_UPDATE_REPLY_HANDLERS

The event handler for the

UAA_UPDATE_REPLY.

UAA_AUTHENTICATE_REPLY_HANDLER

The event handler for the

UAA_Authenticate_REPLY.

For more information on opsec_init_entity, see the OPSEC API Specifications. Requests A UAA request has two parts: Key: This is used by the UAA server to identify the appropriate connection. Request: This is used by the requested user and/or connection information. Both the key and the request have one or more assertions. Each assertion has a type and a value, both of which are strings (char *).
Request Implementation

The uaa_assert_t data structure is used to pass key assertions and request assertions from the UAA client to the UAA server.

Chapter 11

UserAuthority OPSEC APIs

243

Programming Model

TABLE 11-3 shows the API functions that handle UAA requests.
TABLE 11-3

Request Handling Functions Description

Function Name UAA_send_query UAA_short_query UAA_send_update UAA_send_authenticate_request

Sends a query to the UAA server. Cancels a query to the UserAuthority server Sends an update to the UserAuthority server. Sends an authentication request to the UserAuthority server.

Key Assertions Key assertions are the input to the UserAuthority server for each request. They determine the behavior of the server. Each of the different commands has a different set of key assertions. TABLE 11-4 shows the key assertion types and values.
TABLE 11-4

Key Assertions Types and Values Key Type src s_port dst d_port ipp Key Value

Command Query

The IP address of the connections source. The port number of the connections source. The IP address of the connections destination. The port number of the connections destination. The IP protocol. This assertion is optional. By default, the IP protocol is assumed to be 6 (TCP). The Check Point session ID, a unique string stored in the HTTP_CP_SESSION_ID environment variable of the UserAuthority Overview. Used for credential management queries. It specifies the username whose credentials are requested. The IP address of the connections source. Used for credential management updates. It specifies the username whose credentials are updated. The username to authenticate. The password of the user to be authenticated.

snid

uid

Update

src uid

Authenticate

uid password

244

OPSEC UserAuthority API Overview

Request Assertions Request assertions specify the information to be retrieved from the UAA server and designate how this information should be returned. A request assertion includes a request type specifying the data to be retrieved from the UAA server (possible request types are shown in TABLE 11-5) and the following value: * if the reply may include multiple values corresponding to the specified type. Currently only used for: the group assertion user_info/all_auth_domains_available assertion.
TABLE 11-5

Request Assertion Type Assertion Type user dn Meaning

Command Query

The ID used for authentication. The DN (LDAP distinquished name) of the user. The client IP address, which may be different from the connections source if: The client has undergone Network Address Translation (NAT), or The connection has been redirected through a VPN-1 Pro Security Server. This attribute is returned only if: The UAA request is included in the connection information assertion (e.g., src, s_port, dst, d_port and ipp). The connection specified in the request is passed through VPN-1 Pro. The type of authentication. The VPN-1 Pro groups to which the user belongs. The type of encryption. Indicates that the machine running SecureClient has been verified by the Policy Server running on the same machine as the UAA server.

client_ip

scheme group

enc scv

Chapter 11

UserAuthority OPSEC APIs

245

Programming Model

TABLE 11-5

Request Assertion Type Assertion Type logon_time Meaning

Command Query

Used to allow a client to query for a sessions logon time or to include the logon time in the scope of a query. Used to allow a client to query for a sessions logoff time or to include the logoff time in the scope of a query. Used for credential management queries. The VPN-1 Pro Users username in the selected authentication domain. Used for credential management queries. The password of the VPN-1 Pro user in the selected authentication domain. Used for credential management queries. The reply returned for this query includes all the information stored by the credential manager for the associated user.
Note - In order to use this type of query, use the Credential Management Web page configuration. See the The Credentials Manager Web GUI - UA Settings on page 15 for more information.

logoff_time

auth_domain/<nam e corresponding to authentication domain>/user user_info/<name corresponding to authentication domain>/password auth_domain/all_ auth_domains_ava ilable

win_group=* Update auth_domain/<nam e corresponding to authentication domain>/user user_info/<name corresponding to authenticatin domain>/password user action

Used to define Windows domain groups. Used for credential management updates. The user name of the VPN-1 Pro user in the selected authentication domain. Used for credential management updates. The password of the VPN-1 Pro user in the selected authentication domain. The authenticated username. Action stage in the authentication process (i.e., failure, success, more information needed). Message suitable for the action to be taken.

Update

Authenticate

message

246

OPSEC UserAuthority API Overview

TABLE 11-5

Request Assertion Type Assertion Type group Meaning

Command

The VPN-1 Pro groups to which the user belongs. The DN (LDAP Distinguished Name) of the user. The type of authentication.

dn

scheme

Each request is uniquely identified by a request ID returned by the call to one of the uaa_send_xxx functions. The request ID is used as a parameter to be passed to other functions, for example, uaa_abort_query. The request ID is not valid in the following cases: After the last reply has arrived to the users event handler function After a query has been aborted by calling uaa_abort_query After the event handler has been called because the request has timed out (that is, the timeout specified in uaa_send_xxx expired). The result of using the request ID in any of these cases is undefined. Replies A reply consists of reply assertions corresponding to the request assertions in the request. Each reply assertion consists of a type and a value, both of which are strings (char *). The reply type is identical to the corresponding request type. If there is no value corresponding to a given request type, then the assertion is not returned. If a reply type has more than one corresponding value, and the corresponding request assertion had a value of *, then the reply contains one assertion for each value. That is, the reply contains several reply assertions of the same type.

Chapter 11

UserAuthority OPSEC APIs

247

Programming Model

TABLE 11-6 shows the assertion types and values.

TABLE 11-6

Reply Assertions Types and Values Reply Value

Type user dn

The user ID (name) used for authentication. The DN (LDAP Distinquished Name) of the user. Null if the user does not have a DN. This attribute can be used by LDAP-aware applications and is available only if the user entry was taken from an LDAP Server. The IP address of the UAA Client (which may be different than the source of the connection if the connection has been redirected through a VPN-1 Pro Security Server). Used to define Windows domain groups. The type of authentication: NULL - The connection is not authenticated Unknown - exact details unknown (e.g. RADIUS, TACACS) IP Based - such as UAM Fixed password - Pre-shared secret, OS, VPN-1 Pro, LDAP One Time Password - S/Key Token - SecurID, Axent Certificate - PKI. The VPN-1 Pro groups to which the user belongs. Note: Because groups are defined in the VPN-1 Pro database, LDAP groups may appear as external groups. The type of encryption: NULL - either the connection did not pass through VPN-1 Pro, or not enough information is available on the connection PLAIN - no encryption ENCRYPTED - encrypted, but the exact details are unknown EXPORT - such as RC4/40 DOMESTIC - such as DES STRONG - such as Triple DES 1 if the SecureClient is currently connected to a Policy Server running on the same machine as the UAA Server. 0 in all other situations.

client_ip

win_group scheme

group*

enc

scv

248

OPSEC UserAuthority API Overview

The UAA server uses the uaa_assert_t data structure to return reply assertions to the UAA client. The uaa_assert_t data structure is passed to the UAA client as one of the arguments to the event handlers. The structure is automatically freed when the event handlers return. Connection-Based Vs. IP-Based Information in Queries
TABLE 11-7

UserAuthority Queries Use these connection key assertions UAA Server Returns: User Info. user group dn client_ip Authentication Scheme scheme Encryption Type enc SecureClient Secure

UAA Queries on:

A connection

One of:
src s_port dst d_port

and
ipp snid user group dn client_ip win_group scheme scv

An IP address

src

Tip - For detailed information on advanced UAA queries, contact OPSEC SDK Technical Services.

Chapter 11

UserAuthority OPSEC APIs

249

Programming Model

UAA Assertions Structure Functions TABLE 11-8 shows API functions that enable you to step through the assertions in a UAA assertions structure.
TABLE 11-8

API Functions for Iterating through Assertions Description

Function Name uaa__assert_t_iter_create

Creates an iteration object for UserAuthority assertions. Sets the iterator to the next assertion in the assertions structure. Resets the iterator to the first assertion. Destroys the assertions iterator and frees its memory.

uaa__assert_t_iter_get_next

uaa__assert_t_iter_reset uaa__assert_t_iter_destroy

Processing Error Codes Error codes can be processed using the API functions shown in TABLE 11-9.
TABLE 11-9

API Functions to Process Error Codes Description

Function Name uaa__error_str

Converts an error value to a string.

Session Management Several queries and updates can run on a single session, but each authenticate command should run on a separate session.

250

Session Management

Function Calls
In This Section
Session Management Assertions Management Managing Queries Managing Updates Managing Authentication Requests Assertions Iteration Managing UAA Errors Debugging page 251 page 252 page 254 page 256 page 256 page 257 page 259 page 260

This section describes the functions provided by the OPSEC UserAuthority API.

Session Management
The Session Management function calls the start and end OPSEC session APIs. Function prototypes are defined in the uaa_client.h file and include: uaa_new_session on page 251 uaa_end_session on page 252 uaa_new_session Description: uaa_new_session initializes an OPSEC session between the UAA client and the UAA server. Usage: OpsecSession * uaa_new_session( OpsecEntity *client, OpsecEntity *server); Arguments
TABLE 11-10 uaa_new_session Arguments

Arguments client server

Meaning

A pointer to the Client entity as returned by opsec_init_entity. A pointer to the Server entity as returned by opsec_init_entity.

Return Values: Pointer to the new session, if successful, or Null.

Chapter 11

UserAuthority OPSEC APIs

251

Function Calls

uaa_end_session Description: uaa_end_session ends the OPSEC session. The UAA client must call this function to correctly terminate the information exchange with the UAA server. Usage: void uaa_end_session (OpsecSession *session) ; Arguments:
TABLE 11-11 uaa_end_session Arguments

Arguments session

Meaning

A pointer to the OPESEC session as returned by uaa_new_session.

Return Values: None

Assertions Management
The Assertions Management functions create, build, copy and destroy UAA assertions. Unless otherwise specified, the function prototypes are defined in the file uaa.h. They include: uaa_assert_t_create on page 252 uaa_assert_t_add on page 252 uaa_assert_t_duplicate on page 253 uaa_assert_t_destroy on page 253 uaa_assert_t_compare on page 254 uaa_asser_t_n_elements on page 254 uaa_assert_t_create Description: uaa_asseret_t_create creates a uaa_aassert_t data structure. Usage: uaa_asseret_t * uaa_asseret_t_create (); Arguments: There are no arguments to this function. Return Values: Pointer to uaa_asseret_t structure, if successful, or Null. uaa_assert_t_add Description: uaa_asser_t_add adds a request assertion to the specified UAA assertions. Usage: int uaa_assert_t_add( uaa_assert_t *asserts, char *type, char
*value);

252

Assertions Management

Arguments
TABLE 11-12 uaa_assert_t_add Arguments

Arguments asserts

Meaning

A pointer to the uaa_asser_t structure containing the UAA assertions. The type of assertion to be added. For more information, see Requests on page 243. The value of the assertion to be added. For more information, see Requests on page 243.

type

value

Return Values: Successful - (0) Not successful - (-1) uaa_assert_t_duplicate Description: uaa_asser_t_duplicate creates a copy of the specified UAA assertions. Usage: uaa_assert_t * uaa_asser_t_duplicate( uaa_assert_t *asserts); Arguments
TABLE 11-13 uaa_assert_t_duplicate Arguments

Arguments asserts

Meaning

A pointer to a uaa_asser_t structure.

Return Values: Pointer to the new copy of the session, if successful, or Null. uaa_assert_t_destroy Description: uaa_asser_t_destroy destroys the data structure containing the UAA assertions and frees its memory. Usage: void uaa_assert_t_destroy( uaa_assert_t *asserts); Arguments
TABLE 11-14 uaa_assert_t_destroy Arguments

Arguments asserts

Meaning

A pointer to a uaa_asser_t structure.

Return Values: None.

Chapter 11

UserAuthority OPSEC APIs

253

Function Calls

uaa_assert_t_compare Description: uaa_asser_t_compare compares two assertion structures. The user can specify a list of types to ignore. Usage: int uaa_assert_t_compare(uaa_assert_t *a, uaa_assert_t *b, char **ignore_list); Arguments
TABLE 11-15 uaa_assert_t_compare Arguments

Arguments a b ignore_list

Meaning

A pointer to a uaa_asser_t structure. A pointer to a uaa_asser_t structure. A pointer to the Server entity as returned by opsec_init_entity.

Return Values: 0 if equal, a non-zero value if not equal. uaa_asser_t_n_elements Description: uaa_asser_t_n_elements returns the number of assertions in the object. Usage: int uaa_assert_t_n_elements( uaa_assert_t *asserts); Arguments
TABLE 11-16 uaa_assert_t_n_elements Arguments

Arguments asserts

Meaning

A pointer to a uaa_asser_t structure.

Return Values: Number of assertions in the structure, if successful, or a negative value.

Managing Queries
The following Query Management functions are available: uaa_send_query on page 254 uaa_abort_query on page 255 uaa_send_query Description: uaa_send_query sends a query to the UAA server. The function usage is defined in the uaa_client.h file. Usage: int uaa_send_query ( OpsecSession *session, uaa_assert_t *query,
void *opaque, unsigned int timeout);

254

Managing Queries

Arguments
TABLE 11-17 uaa_send_query Arguments

Arguments session query opaque timeout

Meaning

A pointer to the OPSEC session. A pointer to the uaa_asser_t structure containing the UAA query. A general purpose pointer to be passed directly to the reply handler. The number of milliseconds before a UAA request times out. If a reply is not available by this time, the event handler for the event is called with the appropriate status.

Return Values: Successful: A unique query ID different than (-1) Not Successful (-1)
Note - The query ID is not valid in any of the following cases, and the result of using the query ID is undefined: After the last reply has arrived to the users event handler function. After the query has been aborted by calling uaa_abort_query. After the event handler has been called because the query has timed out (that is, the timeout specified in uaa_send_query expired).

uaa_abort_query Description: uaa_abort_query cancels a request to the UAA server and the event handler for the UAA_QUERY_REPLY is called. The function usage is defined in the uaa_client.h file. Usage: int uaa_abort_query ( OpsecSession *session, int query_id); Arguments
TABLE 11-18 uaa_abort_query Arguments

Arguments session query_id

Meaning

A pointer to the session. The ID of the query to be cancelled, as returned by

uaa_send_query.

Return Values: 0 if successful, or less than 0.

Chapter 11

UserAuthority OPSEC APIs

255

Function Calls

Managing Updates
uaa_send_update Description: uaa_send_update sends an update to the UAA server. The function usage is defined in the uaa_client.h file. Usage: int uaa_send_update ( OpsecSession *session, uaa_assert_t *update,
void *opaque, unsigned int timeout);

Arguments
TABLE 11-19 uaa_send_update Arguments

Arguments session update opaque timeout

Meaning

A pointer to the OPSEC session. A pointer to the uaa_asser_t structure containing the UAA update. A general purpose pointer to be passed directly to the reply handler. The number of milliseconds before a UAA request times out. If a reply is not available by this time, the event handler for the event is called with the appropriate status.

Return Values: Successful: A unique query ID different than (-1) Not Successful (-1)
Note - The update ID is not valid in any of the following cases, and the result of using the update ID is undefined: After the last reply has arrived to the users event handler function. After the event handler has been called because the update has timed out (that is, the timeout specified in uaa_send_update expired).

Managing Authentication Requests

uaa_send_authenticate_request Description: uaa_send_authenticate_request sends an authentication request to the UAA server. The function usage is defined in the uaa_client.h file. Usage: int uaa_send_authenticate_request ( OpsecSession *session,
uaa_assert_t *auth_info, void *opaque, unsigned int timeout);

256

Assertions Iteration

Arguments
TABLE 11-20 uaa_send_authenticate_request Arguments

Arguments session auth_info

Meaning

A pointer to the OPSEC session. A pointer to the uaa_asser_t structure containing the UAA authenticate information. A general purpose pointer to be passed directly to the reply handler (see $$$). The number of milliseconds before a UAA request times out. If a reply is not available by this time, the event handler for the event is called with the appropriate status (see the $$$).

opaque

timeout

Return Values: Successful: A unique query ID different than (-1) Not Successful (-1)
Note - The update ID is not valid in any of the following cases, and the result of using the update ID is undefined: After the last reply has arrived to the users event handler function. After the event handler has been called because the authentication has timed out (that is, the timeout specified in uaa_send_authenticate_reqest expired).

Assertions Iteration
Function prototypes are defined in the uaa.h file. The following functions step through the assertions in a UAA assertions structure: uaa_assert_t_iter_create on page 257 uaa_assert_t_iter_get_next on page 258 uaa_assert_t_iter_reset on page 259 uaa_assert_t_iter_destroy on page 259 uaa_assert_t_iter_create Description: uaa_assert_t_iter_create creates an iteration object for UAA assertions. Usage: uaa_assert_t_iter * uaa_assert_t_iter_create(uaa_assert_t *asserts, char *type);

Chapter 11

UserAuthority OPSEC APIs

257

Function Calls

Arguments
TABLE 11-21 uaa_assert_t_iter_create Arguments

Arguments asserts

Meaning

A pointer to the uaa_assert_t structure containing the UAA assertions. If non-NULL, the iterator is typed. That is, the iterator only iterates through assertions of the specified type. Type can be one of the following: NULL: Iterate through all assertions in the assertions structure. Any other valid string: Iterate through assertions of the specified type (for more information, see Key Assertions on page 244 and Replies on page 247).

type

Return Values: Pointer to assertions iterator, if successful, or NULL. uaa_assert_t_iter_get_next Description: uaa_assert_t_iter_get_next sets the iterator to the next assertion in the assertions structure. Usage: uaa_assert_t_iter_get_next (uaa_assert_t *iter, char **value char
**type);

Arguments
TABLE 11-22 uaa_assert_t_iter_get_next Arguments

Arguments iter value type

Meaning

A pointer to the assertion iterator. A pointer to be set to the value of the assertion. A pointer to be set to the type of the assertion.

Return Values: If successful: 0 If either of the following are true then the value is (-1): There are no more request assertions of the specified type (in the case of a typed iterator (see uaa_assert_t_iter_create on page 257). An error has occurred.

258

Managing UAA Errors

uaa_assert_t_iter_reset Description: uaa_assert_t_iter_reset resets the iterator to the first assertion in the assertions data structure. Usage: uaa_assert_t_iter_reset (uaa_assert_t *iter); Arguments
TABLE 11-23 uaa_assert_t_iter_reset Arguments

Arguments iter

Meaning

A pointer to the assertions iterator.

Return Values: 0, if successful, or a non-zero value. uaa_assert_t_iter_destroy Description: uaa_assert_t_iter_destroy destroys the assertions iterator and frees its memory. Usage: void uaa_assert_t_iter_destroy (uaa_assert_t *iter); Arguments
TABLE 11-24 uaa_assert_t_iter_destroy Arguments

Arguments iter

Meaning

A pointer to the assertions iterator.

Return Values: None.

Managing UAA Errors

This section describes the error utility functions. The function usage is defined in the uaa_error.h file. uaa_error_str Description: uaa_error_str converts the status of a reply to an error message. Usage: char *uaa_error_str(uaa_reply_status status);

Chapter 11

UserAuthority OPSEC APIs

259

Event Handlers

Arguments
TABLE 11-25 uaa_error_str Arguments

Arguments status

Meaning

The reply status, as returned by event handler.

status

argument of the reply

Return Values: A string indicating the error, if successful, or NULL.

Debugging
This section describes utility functions for debugging. To enable these functions, the OPSEC_DEBUG_LEVEL environment variable must be set to 3. For further details about the OPSEC_DEBUG_LEVEL, see OPSEC API Specification. Function prototypes are defined in the uaa.h file. uaa_print_assert_t Description: uaa_print_assert_t prints the contents of the uaa_print_assert_t structure. Usage: void uaa_print_assert_t(uaa_assert_t *asserts); Arguments
TABLE 11-26 uaa_print_str Arguments

Arguments asserts

Meaning

A pointer to the uaa_assert_t structure to be printed.

Return Values: None

Event Handlers
This section describes the functions that need to be written to implement a UAA Client. All of these functions take a pointer to OpsecSession as an argument.
Note - Memory allocated for function arguments is managed by the OPSEC environment, and the arguments hold valid data only during the execution of the handler functions. For this reason, you should not, for example, save a static pointer to this data for use after the handler function returns.

260

UAA_QUERY_REPLY Event Handler

UAA_QUERY_REPLY Event Handler

Description: UAA_QUERY_REPLY is called when a reply to a UAA query becomes available.
Note - The name QueryReplyHandler is a placeholder. You can assign any name to this function.

Usage: int QueryReplyHandler( OpsecSession *session, uaa_assert_t *reply, void *opaque, int query_id, uaa_reply_status status, UaaReplyIsLast last); Arguments
TABLE 11-27 QueryReplyHandler Arguments

Arguments session

Meaning

A pointer to an OpsecSession structure, as returned by uaa_new_session (seeuaa_new_session on page 251). A pointer to the uaa_asser_t structure containing the reply assertions. The general-purpose pointer copied from the corresponding call to uaa_send_query (see uaa_send_query on page 254). The ID returned by the corresponding call to uaa_send_query (see uaa_send_query on page 254). The reply status: UAA_REPLY_STAT_OK if no errors have occured Otherwise, a value that can be converted to an error message using uaa_error_str (see uaa_error_str on page 259). The value UAA_REPLY_LAST indicates that this is the last reply for the specific query and the value UAA_REPLY_NOT_LAST indicates that the server will send additional replies.

reply

opaque

query_id

status

last

Return Values: OPSEC_SESSION_OK if the session can continue. OPSEC_SESSION_END if the session must be closed. OPSEC_SESSION_ERR if the session must be closed due to an error.

Chapter 11

UserAuthority OPSEC APIs

261

Event Handlers

UAA_UPDATE_REPLY Event Handler

Description: UAA_UPDATE_REPLY is called when a reply to a UAA update becomes available.
Note - The name UpdateReplyHandler is a placeholder. You can assign any name to this function.

Usage: int UpdateReplyHandler( OpsecSession *session, uaa_assert_t *reply, void *opaque, int cmd_id, uaa_reply_status status; Arguments
TABLE 11-28 UpdateReplyHandler Arguments

Arguments session

Meaning

A pointer to an OpsecSession structure, as returned by uaa_new_session (seeuaa_new_session on page 251). A pointer to the uaa_asser_t structure containing the reply assertions. The general-purpose pointer copied from the corresponding call to uaa_send_update (see uaa_send_update on page 256). The ID returned by the corresponding call to uaa_send_update (see uaa_send_update on page 256). The reply status: UAA_REPLY_STAT_OK if no errors have occured Otherwise, a value that can be converted to an error message using uaa_error_str (see uaa_error_str on page 259).

reply

opaque

cmd_id

status

Return Values: OPSEC_SESSION_OK if the session can continue. OPSEC_SESSION_END if the session must be closed. OPSEC_SESSION_ERR if the session must be closed due to an error.

262

UAA_AUTHENTICATE_REPLY Event Handler

UAA_AUTHENTICATE_REPLY Event Handler

Description: UAA_AUTHENTICATE_REPLY is called when a reply to a UAA authentication request becomes available.
Note - The name AuthenticationReplyHandler is a placeholder. You can assign any name to this function.

Usage: int AuthenticationReplyHandler( OpsecSession *session,

uaa_assert_t *reply, void *opaque, int cmd_id, uaa_reply_status status;

Arguments
TABLE 11-29 UpdateReplyHandler Arguments

Arguments session

Meaning

A pointer to an OpsecSession structure, as returned by uaa_new_session (seeuaa_new_session on page 251). A pointer to the uaa_asser_t structure containing the reply assertions. The general-purpose pointer copied from the corresponding call to uaa_send_authenticate_request (see uaa_send_authenticate_request on page 256). The ID returned by the corresponding call to uaa_send_autheticate_request (see uaa_send_authenticate_request on page 256). The reply status: UAA_REPLY_STAT_OK if no errors have occured. Otherwise, a value that can be converted to an error message using uaa_error_str (see uaa_error_str on page 259).

reply

opaque

cmd_id

status

Return Values: OPSEC_SESSION_OK if the session can continue. OPSEC_SESSION_END if the session must be closed. OPSEC_SESSION_ERR if the session must be closed due to an error.

Chapter 11

UserAuthority OPSEC APIs

263

Event Handlers

264

CHAPTER

12

Monitoring the UserAuthority Environment

In This Chapter
Overview System Monitoring User Monitoring page 265 page 266 page 273

Overview
Monitoring allows the system administrator to view the system status for debugging and problem solving in the system. For example, an administrator might receive a complaint that a user is unable to access a Web application. The administrator can use the monitoring tools to determine if this is due to a problem in the system (such as a server is offline) or a problem in the system configuration, or because the user does not have the necessary authorization to access the requested application. There are two types of monitoring in UserAuthority: System monitoring is used to check the status and state of the UserAuthority System at any time. The system is monitored to determine if any component is offline or if there are problems in the systems configuration. See System Monitoring on page 266. User monitoring is used to determine if there are any problems specific to the user. Logs are used to follow the users requests and see how the system responds (e.g., what queries are made by the UserAuthority Server (UAS) or whether the correct credentials are injected into a Web applications authentication page by UserAuthority WebAccess). See User Monitoring on page 273.
265

System Monitoring

This chapter describes the two types of monitoring and how to carry out monitoring activities.

System Monitoring
In This Section
Monitoring the System Status Using Logs in System Monitoring Monitoring Example: UAS is Offline page 266 page 269 page 272

Monitoring the System Status

UAS and UserAuthority WebAccess protect the local network and specific Web applications from access by unauthorized and unauthenticated users. For this reason, it is important to know whether all components in the system are operating. Check Points SmartCenter server gathers information on all system components. This information can be monitored using the SmartView Status console. For more information on how to use SmartView Status, see the Check Point SmartCenter Guide. SmartView Status reports system status information for all Check Point and OPSEC modules in the system, including UAS and UserAuthority WebAccess. The possible module status types are: OK: The module installed on the object is responding to status update requests indicating that everything is working correctly. Untrusted: Secure Internal Communication failed. Problem: The module installed on the object is responding to status update requests, but there is a problem in the status. There can be different types of problems, such as the UAS is not responding. Attention: The module is active although there might be a problem on a product installed on the module. For more information on monitoring statuses, see the Check Point SmartCenter Guide. You can display specific information about a module by: Clicking the icon in the toolbar, which displays a window containing information for all modules for the selected product (UAS or WebAccess). Clicking on the module in the Modules pane, which displays detailed information about the UAS or UserAuthority WebAccess installed on that module. The following sections describe the detailed information displayed for the UAS and UserAuthority WebAccess.
266

Monitoring the System Status

UAS The module pane of SmartView Status lists the modules that are deployed in your network. Each product that is installed on a module is listed in the tree under the module. When you select a UAS in the module tree, details for the selected UAS are displayed in the Details pane on the right side of the window.
TABLE 12-1

UAS Details Description

Detail

Status

The status for the selected UAS. See Monitoring the System Status on page 266 for a list of possible statuses. A description of the UAS on that module. The software version for the selected UAS. The name of the policy installed on the selected UAS. The date and time that the last UserAuthority policy was installed. The license number and information for the selected UAS. The type of UAS (installed on VPN-1 Pro, on a Windows Domain Controller (DC), or on a Citrix/Terminal Services). A list of items included in the configuration that relate to the selected UAS: Log Server IP Addresses. Windows domains trusted by VPN-1 Pro. Other UASes that provide identity information. A list of run-time items: IP address(es) for the UserAuthority WebAccess hosts and their connection status. The IP addresses for UserAuthority OPSEC clients. Number of requests processed. Average response time per request (in seconds).

Description UserAuthority Server Version Policy Name Installed At License UserAuthority Server Type

Configuration

Run-Time Information

Chapter 12

Monitoring the UserAuthority Environment

267

System Monitoring

UserAuthority WebAccess When you select UserAuthority WebAccess in the module tree, a detailed list of the status for that specific UserAuthority WebAccess module is displayed in the Details Pane on the right side of the window
TABLE 12-2

UserAuthority WebAccess Details Description

Detail

Status

The status of the selected UserAuthority WebAccess module. See Monitoring the System Status on page 266 for a list of possible statuses. A description of UserAuthority WebAccess on the selected module. The software version of the selected UserAuthority WebAccess module. The name of the UserAuthority WebAccess module. The following information about UserAuthority WebAccess performance: Number of accepted requests. Number of rejected requests.

Description Version WAM Name UA WebAccess Performance

268

Monitoring the System Status

TABLE 12-2

UserAuthority WebAccess Details Description

Detail

Policy Info

The following information regarding the UserAuthority WebAccess policy currently installed: Policy Name. Policy Last Update: The last date and time when the policy was installed. The following information about the UAS associated with this UserAuthority WebAccess module: UAS Host: The name of the host machine on which the UAS is installed. UAS IP Address: The IP address of the machine on which the UAS is installed. UAS Port: The port on which the UAS listens. Number of UAS queries: The number of queries that the UAS has handled. UAS Last handling time: The last time the UAS handled a request. The following information about the selected UserAuthority WebAccess modules performance: Number of Open Sessions: The number of UserAuthority WebAccess sessions that are currently open. Last Open Session Time: The time and date of the last open UserAuthority WebAccess Session.

UAS Info

Global Performance Info

Using Logs in System Monitoring UAS and UserAuthority WebAccess logs display control messages and alerts regarding problems that are encountered in the system, and help in determining configuration problems. UserAuthority WebAccess logs are described in Chapter 8, Auditing in UserAuthority. Using UAS and UserAuthority WebAccess Logs for System Monitoring UAS and UserAuthority WebAccess have three types of logs. The log type is displayed in the Type column of the Records pane or the Record Details window. The log types are:
Chapter 12 Monitoring the UserAuthority Environment 269

System Monitoring

Log: Standard logs that describe what is happening or whether a query is carried out for each user request. For example, Authentication Success is a log entry that indicates that the user was authenticated, and appears in a regular log file. Alert: Alerts are displayed in red and call attention to potential problems in the system. An example of an alert is Web server is stopping. This indicates that the Web server is not online. Control: Control logs indicate a standard system activity. For example, when the system is turned on or configured there must be a connection between different components. A UserAuthority WebAccess control log that states Connection established with UA Server indicates that the UserAuthority WebAccess server and UAS communication is established.

The Alert and Control logs are helpful for system monitoring. They can show potential problems or indicate whether standard communication activities have occurred, and can be used to troubleshoot system problems. For example, if a user is denied access to a specific application even though UserAuthority WebAccess policy is configured to grant access, the log files can help to find the reason. Checking the control logs, it is possible to see if the UserAuthority WebAccess policy was loaded by seeking a control log entry, Loading Policy. If this log is missing, the policy must be installed. The actual messages displayed in the logs can be edited to fit the needs of your organization. For information on how to edit log messages, see Customizing Specific Log Entries on page 212. Using UAS Logs UAS logs provide information on queries to and from the UASes in the deployment, as well as information on the chaining (shared identity) between computers. To use UserAuthority logs, verify that there is a Log Server and then configure the logging level (see Configuring the Logging Level for the UAS on the FireWall Gateway on page 270). For information on log servers, see the Check Point SmartCenter Guide. UAS logs are useful for solving user access problems. An example of how monitoring with UAS logs can help pinpoint a problem is described in the section Monitoring Example: UAS is Offline on page 272.
Configuring the Logging Level for the UAS on the FireWall Gateway

UAS logs can be configured to work on three levels:

Low:

UAS generates Alert and Control logs only.

Medium:

UAS generates logs on UAS query failures, in addition to the Alert and Control logs.

270

Monitoring the System Status

High: UAS generates logs with detailed information about UAS queries, including failures in identity sharing, in addition to the logs generated on the Low and Medium levels.

To configure the level of UAS logs, do the following in SmartDashboard: 1 In the Network Object tree, double click the network object for the VPN-1 Pro gateway with UAS installed. The Check Point Gateway window is displayed. In the tree pane, select
UserAuthority Server. Note - You must separately configure the logging level for each UAS on a VPN-1 Pro gateway. UASes on Windows DCs are configured to create logs by default. To change the logging configuration for UASes on Windows DCs, you must edit the netso.ini file on the Windows DC. For information, see Configuring Logs for UASes not on a FireWall Gateway on page 271.

3 4 5

In the Logging Level area, select a logging level from the Level drop-down list. Click
OK

UserAuthority Logging

to close the window.

Save and install the policy on the VPN-1 Pro gateway.

Configuring Logs for UASes not on a FireWall Gateway

By default, UASes on Windows DCs and Citrix/Terminal services are configured to generate logs. The log generation configuration is found in the netso.ini file on the Windows DC or Citrix/Terminal Services machine. If logs are not being created or you want to turn off logging for the UAS on the Windows DC, you must edit the netso.ini file. To configure UAS Logging on a Windows DC: 1 In the Windows DC or Citrix/Terminal Services machine, browse to the UAS installation directory (by default C:\\Program Files\Check Point\UAG\R55\Conf). From the Conf folder, open the netso.ini file.
Note - You must open the netso.ini file with WordPad. You cannot open it with NotePad.

In the [NETSO_Configuration] section, find the line log server=

Chapter 12

Monitoring the UserAuthority Environment

271

System Monitoring

After the equal (=) sign, enter the IP address or net bios name for the machine with the log server (if you want the logs to be created on the management server, enter DN_Mgmt). In the event of multiple log servers, enter the IP addresses (or net bios) for each one separated by commas (,). Save and close the file. Run UAS renconf to restart the UserAuthority Service and activate the changes to the file. The following is an example of the netso.ini file configured to create logs on the management computer.
Log Server = DN_Mgmt

5 6

For more information on user monitoring, see User Monitoring on page 273.

Monitoring Example: UAS is Offline

This scenario describes what happens if the UAS is not working. In this case, a user attempts to access an intranet application through UserAuthority WebAccess. If the user is configured to receive Single Sign-On (SSO), UserAuthority WebAccess automatically queries the UAS. The user receives a message that the requested service is not available. It is possible to determine that the UAS is offline by checking the SmartView Status. Checking the SmartView Status immediately shows the location of the problem. Once offline, the UAS is no longer able to send log information. Therefore, viewing the logs enables you to determine when the UserAuthority went offline. FIGURE 12-1 shows five UserAuthority WebAccess logs.
FIGURE 12-1 UserAuthority WebAccess Logs

The logs in FIGURE 12-1 provide information on why the user was unable to access the Web application, and on when the UAS went offline. The first log is an Alert. This alert is Connection Lost with UA Server. The second log shows the user attempt to connect to a Web application. UserAuthority WebAccess reports that the user opened a new browser request. The third log shows the UserAuthority WebAccess query to the UAS. The last two logs are Alerts that state UA Server is not responding. There is no answer to the UserAuthority WebAccess query, so the service is unavailable. Checking the SmartView Status shows why the UAS is not responding.

272

Monitoring User Activities

User Monitoring
In This Section
Monitoring User Activities Monitoring Example: SecureAgent Cannot Provide User Identity page 273 page 276

Monitoring User Activities

UAS and UserAuthority WebAccess logs enable user monitoring to troubleshoot user problems in the system. These logs provide a description of the activities that occur in the system when a user makes a request. For example, UAS logs indicate when a query for the users identity is made. The UserAuthority WebAccess logs show the requests that are being made to UAS and the UAS replies to the UserAuthority WebAccess queries. If you want to compare the UAS and UserAuthority WebAccess activities for the same user request, you should create a filter to display only logs with the same UserAuthority Session ID (UA Session ID). This ID will be the same for both types of logs. By examining these logs you can monitor many user activities, such as: User requests to Web applications User authentication User credential injection Replies to user requests

To monitor the system, you must understand the order of the queries between UserAuthority WebAccess and UAS. Each time a query is made by the UserAuthority WebAccess, a return query is received from UAS. The next query depends on the answer that was returned. This query flow is shown in FIGURE 12-2.

Chapter 12

Monitoring the UserAuthority Environment

273

User Monitoring

FIGURE 12-2 Communication Flow between UserAuthority WebAccess and UAS

274

Monitoring Example: Successful Access to a Web Application

Each of the processes or queries in the flow is represented by a UserAuthority log. The logs indicates where the initial request came from, where it is going and what is happening. In some cases the result is also indicated. This information can be used to determine why a user might be unable to access applications or benefit from SSO. Configuration problems can then be corrected so that the user can continue to use the Web applications on the network as usual. See Monitoring Example: SecureAgent Cannot Provide User Identity on page 276 for an example on monitoring user activities.

Monitoring Example: Successful Access to a Web Application

In most cases a user successfully accesses the requested Web application or Web site. The UserAuthority logs show the query flow for the request, enabling a system administrator to see that the system is functioning properly. FIGURE 12-3 shows a partial list of UserAuthority logs in the SmartView Monitor records pane. These logs show the UserAuthority Session ID and a description (in the Comment column) of the queries made by the UAS for the session.
FIGURE 12-3 Successful Attempt to Access a Web Application

The logs in this example indicate the following: The user opens a session in a Web browser. The user requests a Web Application at a specific address. The request goes to UserAuthority WebAccess as indicated by the IP address in the log. UserAuthority WebAccess sends an identification query to the UAS. The UAS returns an empty reply, indicating that it was unable to identify the user.

Chapter 12

Monitoring the UserAuthority Environment

275

User Monitoring

The user (Bill) authenticates by sending his user name and password. The password is indicated in the log by a series of asterisks to ensure user privacy. The next two logs show the user identification request being updated with a key. The authentication is updated successfully. A credential query is sent to the UAS. The UAS replies to UserAuthority WebAccess with the credentials provided when Bill authenticated. UserAuthority WebAccess injects the credentials into the authentication page of the requested Web application. The credentials are accepted and UserAuthority WebAccess authorizes the user.

By reading the logs, you can follow the entire flow and see that the UAS and UserAuthority WebAccess are communicating properly.

Monitoring Example: SecureAgent Cannot Provide User Identity

You can use UAS logs to determine why user identity is not achieved. The following is true in this example: The user must be identified by the Windows DC. UserAuthority WebAccess is not configured to retrieve the user identity by Windows Integrated Authentication. SecureAgent is not active. In this case, when a user attempts to access a Web application, the user receives a message that the service is not available. This is because the UAS is unable to identify or authenticate the user. When this problem is reported in the system, it is easy to determine why this happens with the logs. The following UAS logs are generated when a user requests a Web application in this situation:
FIGURE 12-4 Unsuccessful Attempt to Access a Web Application

The logs in this example indicate the following: 1 The UAS on the VPN-1 Pro gateway queries the UAS on the Windows DC. The log information indicates the two machines and that the query was successful.

276

Monitoring Example: SecureAgent Cannot Provide User Identity

The UAS on the Windows DC queries SecureAgent for the users identity. This happens because the system is not configure for Windows Integrate Authentication. In this case, it is necessary to install the UAS on the Windows DC and retrieve the user identity with SecureAgent. An alert indicating that the system is not active is returned because SecureAgent is not responding. The following Record Details window shows the information returned for this alert.

FIGURE 12-5 SecureAgent Query Timed Out

The comment clearly states that the SecureAgent query failed and the system timed out.

Chapter 12

Monitoring the UserAuthority Environment

277

User Monitoring

The last log shows that the UAS on the Windows DC sent an empty query back to the UAS on the VPN-1 Pro gateway. An empty query indicates that there is no identification information for the user requesting the Web application. Therefore, the VPN-1 Pro cannot forward the request and the user receives a message indicating that the service is not available.

278

CHAPTER

13

Troubleshooting UserAuthority
In This Chapter
Overview General Problems User-Related Problems page 279 page 280 page 286

Overview
This chapter provides help for common problems that might arise when using UserAuthority. Problems in UserAuthority can be divided into two categories: General Problems: These are problems that effect the system as a whole, such as a system failure or bad configuration. User problems: These are problems that effect a single user, such as improper configuration of the users SecureAgent. In addition to the information provided in this chapter, you can also read the logs generated to identify a problem. For more information on using logs to monitor system errors, see Chapter 12, Monitoring the UserAuthority Environment.

279

General Problems

General Problems
This section provides information on common problems in the overall system.

In This Section
Why is the service not available? Why is there a proxy error? Why are users not authorized to view the page? Why is there no established SIC? Why are users not authorized access when the policy is installed? Why are there no logs in SmartView Tracker? page 280 page 281 page 282 page 283 page 285 page 286

Why is the service not available?

Symptom When system users request a Web page, the following message is displayed:
Service is currently not available Please try again later or contact the administrator. Administrator log ticket ID: <log ID number>

Problem UserAuthority WebAccess is not communicating properly with the UserAuthority Server (UAS). Solutions Make sure that the appropriate UAS is defined in the UserAuthority WebAccess network object in SmartDashboard. See Configuring UserAuthority WAPS in SmartDashboard on page 75. After configuring the UserAuthority WebAccess network object, make sure that the policy is installed on the gateway (so the UAS recognizes the new UserAuthority WebAccess machine that is contacting it). Use the VPN-1 Pro logs to determine if the FW_UAA (open by default in implied rules) communication is being received by the UAS from UserAuthority WebAccess. To do this, make sure that the destination configured for the VPN-1 Pro logs is the UserAuthority WebAccess machine and that subsequent logs communicate with the UAS. If you do not see an IP address for a UserAuthority WebAccess machine in a destination field, then there is a problem in your configuration. See Chapter 8, Auditing in UserAuthority for information on log configuration.
280

Why is there a proxy error?

Make sure that the UAS is online by: Checking the status in SmartView Status. Running uag_start from the UAS machine. A return message states that the UAS is already running. If it is not running, it will start the UAS. If you are using Web SSO, make sure that the UserAuthority WebAccess module is defined in all defined authentication domains. See steps 2C-2D in Configuring a Basic Web SSO Rule on page 85. Examine the UserAuthority WebAccess logs to determine which query fails to communicate with the UAS. FIGURE 13-1 shows an example of an alert that indicates that there is no communication. If there is an alert that states Communication Lost with UA server, then the UAS was not updated with the last policy or the FW_UAA traffic is blocked. The following is an excerpt from a log that contains this alert.

FIGURE 13-1 Communications Lost Alert

If the log shows that permission was denied, the problem is setting permission on an authentication domain for UserAuthority WebAccess. You must make sure that you have set access to UserAuthority WebAccess on each authentication domain. See steps 4-5 in Defining Authentication Domains on page 92.

Why is there a proxy error?

Symptom When system users request a Web page, the following message is displayed:
Proxy Error The proxy server received an invalid request from an upstream server. The proxy server could not handle the request GET/

Chapter 13

Troubleshooting UserAuthority

281

General Problems

Reason: Could not connect to remote machine: Network is unreachable

Problem UserAuthority WebAccess Proxy Server (WAPS) is not communicating properly with the target Web server. Solutions Make sure the Web server is online. Make sure that the Web server is configured correctly in the virtual host (no mistake in domain or IP address) and that there is a connection between the WAPS and Web server (by pinging the relevant domain from the WAPS). Make sure that HTTP traffic from the WAPS to the server is allowed in VPN-1 Pro policy. This is configured in the Service field in the SmartDashboard Security tab. Check the VPN-1 Pro logs to verify.

Why are users not authorized to view the page?

Symptom When system users request a Web page, the following message is displayed:
You are not authorized to view this page If you believe you should be able to view this directory or page, please contact the servers administrator.

Problem UserAuthority WebAccess is not authorizing access to the requested URL when users try to access the URL. Solutions These solutions assume that all (or most) users in the system are being denied access. For information on how to solve the problem for individual users, see Why is the service not available to the user? on page 286. Make sure that your policy in the WebAccess tab is set on the relevant UserAuthority WebAccess module and install the Web Access policy again. See steps 2C-2D in Configuring a Basic Web SSO Rule on page 85. In your policy, verify that all URLs in the Web site have at least one Security rule and one Authorization rule. Make sure these rules have: A value different than None in the Operation field. A value different than None in the Trust/Group field.

282

Why is there no established SIC?

The value Here and below is selected in the Scope field (if the Scope indicates Here, make sure that was what you intended and that this is not causing the authorization failure). If the problem persists, look at the UserAuthority WebAccess logs in SmartView Tracker to determine which URL was denied and check your policy for that URL.

Why is there no established SIC?

Symptom There is a problem in the Secure Internal Communication (SIC) configuration in the UserAuthority WebAccess or UAS. Problem When completing the SIC configuration in SmartDashboard, you receive a SIC Failure message in the Communication window.
FIGURE 13-2 SIC Failure Message

Solutions
Verify the SIC status.

To verify SIC status: 1 From SmartDashboard, double click the relevant network object. The window is displayed.
Chapter 13
Network Host

Troubleshooting UserAuthority

283

General Problems

In the The

Secure Internal Communication

area at the bottom of the window, click

Communication. Communication

window is displayed.

Click Test SIC Status. Make sure that the Trust state is Communicating. If the Trust state is not Communicating, then SIC is not established. If SIC is not established, do one or more of the following as necessary: Make sure that the Check Point SVN Foundation service is started on the relevant network object. Make sure that the relevant network object can be reached from the Check Point SmartCenter management server and that communication is not blocked by a VPN-1 Pro module. Note that VPN-1 Pro inserts an implied rule for this communication. Make sure that there is time and time zone synchronization between the VPN-1 Pro gateway and the relevant network object. Re-establish SIC (see Re-establish SIC on page 284).

Re-establish SIC

You must re-establish SIC on both the relevant machine (UserAuthority WebAccess or VPN-1 Pro gateway where the UAS is installed) and in SmartDashboard. To re-establish SIC on the relevant machine: On a Windows machine: 1 2 3 4 From the Click the Click
Start Check Point Configuration

menu, select Programs > Check Point SmartConsole NG_AI_R55 to open the Check Point Configuration window. tab.
Yes.

>

Secure Internal Communications

Reset

and then confirm by clicking

Enter a password key in the Activation Key field and then enter it again in the Confirm Activation Key field to confirm it. Be sure to remember your key, you need to enter it in the SmartDashboard configuration. Click Click
OK. Yes

5 6

to restart Check Point services.

If this is a Linux or Unix machine: 1 From a command line, type sysconfig.

284

Why are users not authorized access when the policy is installed?

2 3 4 5

From the Configuration menu, type 7; Products Configuration and then press Enter. From the Products Configuration menu, type 3; Secure Internal Communication and then press Enter. At the prompt, Would you like to re-initialize communication?, type y and then press Enter. Type your password as described in the Windows procedure and follow the on-screen instructions to close and save your configuration.

To re-establish SIC in SmartDashboard: 1 2 3 4 5 6 7 Double click the relevant network object. The In the Click Click
Secure Internal Communication Communication. Reset OK Network Host

window is displayed.

area at the bottom of the window, click

and then click

Yes.

in the

Reset is done

window.

In the Activation Key field, enter the activation key that you created when you re-initialized SIC on the relevant machine. Enter the activation key again in the
Confirmation

field. are displayed in the

Trust

Click Initialize. If the Operation is successful, the words state field.

Trust established

Why are users not authorized access when the policy is installed?
Symptom After verifying that the correct UserAuthority WebAccess policy is installed, users are still not authorized to access the Web server. Problem UserAuthority WebAccess did not update itself for the new policy. Solutions Restart UserAuthority WebAccess by running cpstop and then cpstart (or wastop and then wastart) on the UserAuthority WebAccess machine.

Chapter 13

Troubleshooting UserAuthority

285

User-Related Problems

Why are there no logs in SmartView Tracker?

Symptom No logs from UserAuthority WebAccess appear in the SmartView Tracker after initial installation. Problem UserAuthority WebAccess logs are not sent to the SmartServer Management server. Solutions If this is a new installation (or re-installation), run cpstop and then cpstart (or wastop and then wastart) on the UserAuthority WebAccess machine. If the problem continues, check whether the VPN-1 Pro module is blocking communication from WebAccess to the Management server.

User-Related Problems
This section provides information on common problems related to individual users.

In This Section
Why is the service not available to the user? Why cant the user sign in with a specific user name? Why does SecureAgent not identify the user? Why do users receive a pop-up even when signed into the domain? page 286 page 287 page 288 page 291

Why is the service not available to the user?

Symptom When a user requests a Web page, the following message is displayed:
You are not authorized to view this page If you believe you should be able to view this directory or page, please contact the servers administrator.

Problem UserAuthority WebAccess is not authorizing access to the URL requested by a specific user.

286

Why cant the user sign in with a specific user name?

Solutions In this case, UserAuthority WebAccess is blocking the users access to the requested URL. Check the UserAuthority WebAccess policy for the requested URL. Possible reasons are: Authorization Rule: User does not belong to any of the groups specified for the URL. Security Rule: User has violated one of the Trusts specified for the URL. The connection may not be encrypted in the manner specified in the Trust, or may come from a not allowed network. Operation requested by the user does not match any of the operations specified in the above rules. To diagnose this problem, open SmartView Tracker and click the UA Server query. For reason 1, look for the UAS log that shows the groups retrieved for the user. For reason 2, look for the UAS log that shows the encryption type retrieved for the user's request. For reason 3, look for the UAS log that shows the operation type retrieved for the user's request. For more information on monitoring users with logs, see Chapter 12, Monitoring the UserAuthority Environment.

Why cant the user sign in with a specific user name?

Symptom When a user requests a Web page, a window with the following message is displayed.
<WebApplication1> would not let you sign on with User name: <username> This is usually caused by one of the following: 1. <WebApplication1> is experiencing problems. This might be temporary. Click here to try <WebApplication1> again. 2. If you know your password in <WebApplication1> changed, update your Sign On Information for <WebApplication1>. If the steps above don't help, please contact the administrator.

Problem The requested Web application did not receive the users credentials.

Chapter 13

Troubleshooting UserAuthority

287

User-Related Problems

Solutions The set of user credentials for this application is not correct or was changed. Ask the user to update the name and password for the application in the UserAuthority settings page, See Manually Updating User Credentials on page 115. The application cannot check the users credentials. See the Web applications instructions to try and solve this, and then ask the user to try to access the application again.

Why does SecureAgent not identify the user?

Symptom A user with SecureAgent is not identified by VPN-1 Pro. In this case, the user is denied access to all external resources (resources on the other side of the gateway). Problem SecureAgent is not retrieving the users identity. Solutions Make sure that SecureAgent is running by doing the following: Check that the SecureAgent icon is in the taskbar and that it is still active. The SecureAgent icon looks like . From the Windows Task Manager, click the Processes tab and make sure that the uatc.exe process is running. Make sure that SecureAgent is installed on the users PC. Make sure that the user is logged on to the Windows Domain Controller (DC) and not to a local machine account. Make sure that the user is not using cached credentials (this occurs when the machine cannot connect to the Windows DC when logging on). Make sure that Configure SecureAgent automatic installation through a Windows Logon Script was configured. See Configuring SecureAgent Automatic Installation on page 68. Make sure that the SecureAgent scripts are in the NETLOGON directory (see TABLE 2-1 on page 69). Make sure that the client machine has the MSVCP60.dll (this DLL is available from Microsoft). Make sure that the user has sufficient rights to install programs on the PC (i.e., the user is an administrator on the target machine).

288

Why does SecureAgent not identify the user?

Make sure that SecureAgent is communicating with the UAS: Make sure that there is network connectivity between the Windows DC and the desktop. Check the UAS logs to make sure that the UAS on the Windows DC is sending queries to the SecureAgent. Make sure that Client IPs are not hidden from the VPN-1 Pro gateway by an intermediate VPN-1 Pro NAT Hide rule. Make sure that SecureClient/SecuRemote or a Personal Firewall are not blocking the query (UDP port 19190). For clients running both SecureClient and SecureAgent, the Desktop Policy must contain the following rule:
Desktop Policy Desktop Service Action

TABLE 13-1

Source

Windows DC(s)

LAN computer

CP_SecureAgent-udp

Accept

checkbox is selected in the window. If SecureAgent flashes red when trying to access an external resource, then make sure the server that is attempting to query the SecureAgent is defined in the acl.txt file. To define the server:
Client for Microsoft Networks Windows Network Settings

Make sure that the

1 On the Windows DC where the UAS is installed, open the file uatcs-acl.txt in Windows WordPad.

Chapter 13

Troubleshooting UserAuthority

289

User-Related Problems

2 Edit the following file parameters: [hostname]: The host name of the UAS. [ipaddress]: The IP address of the UAS. [port]: The UAS UDP source port (this should always be 19195). The following is an example of a uatcs-acl.txt file configured to accept queries from a Windows DC with the name DC, IP address 10.0.0.2, and port number 19195.
# #hostname # DC ipaddress 10.0.0.2 port 19195

Note - Normally you would modify this file on the Windows DC and have it distributed to clients automatically. If this file is modified directly on a client machine, then SecureAgent must be restarted.

Make sure that the SecureAgent installation is completed before browsing for external resources. This is verified when the Command Prompt window that is running the script appears and then closes. Make sure that there are no HTTP (cache) proxies between Web browsers and the VPN-1 Pro gateway. If you are using an HTTP proxy, then you must do one of the following: Configure IP addresses from trusted proxies to send a special header called X-Forwarded-For. UserAuthority WebAccess will be able to get the necessary information to identify the user from this header. For information on how to make this configuration, see Configuring UserAuthority WebAccess to Recognize Cache Proxy Users on page 124. Use a special configuration file to make requests from specific DNS entries bypass the HTTP proxy. To do this: 1 From Internet Explorer, select window is displayed. 2 Click the 3 Click LAN displayed.
Connections Settings. Tools > Internet Options.

The

Internet Options

tab.
Local Area Network (LAN) Settings

The

window is

4 In the Automatic script.

290

Configuration

area, select

User automatic configuration

Why do users receive a pop-up even when signed into the domain?

5 In the Address field, enter the FQDN or IP address where your configuration file is located. 6 Click
OK,

and then

OK

again to close the windows.

7 Make sure the configuration file contains the DNS entries that you want to bypass the HTTP proxy. The following is an example of a configuration file:
function FindProxyForURL(url, host { if (isPlainHostName(host) || dnsDomainIs(host, ".checkpoint.com") || dnsDomainIs(host, ".checkpoint.co.jp") || isInNet(host, "172.31.0.0", "255.255.0.0") || isInNet(host, "192.168.0.0", "255.255.0.0") || isInNet(host, "10.0.0.0", "255.0.0.0") || isInNet(host, "127.0.0.1", "255.255.255.255") || dnsDomainIs(host, ".us.checkpoint.com") || dnsDomainIs(host, ".ts.checkpoint.com")) return "DIRECT"; else return "PROXY proxy-scan1.checkpoint.com:8080; PROXY proxy5.checkpoint.com:8080; DIRECT"; }

Why do users receive a pop-up even when signed into the domain?
Symptom Users browsing to a Web Application behind a UserAuthority WAPS receive a pop-up for authentication even though they are logged on to the Windows Domain and UserAuthority WebAccess is configured to support Integrated Windows Authentication. Problem The users identity was not retrieved using Integrated Windows Authentication. Solutions Make sure that Integrated Windows Authentication is configured in the UserAuthority WAPS (you can also check to see whether Integrated Windows Authentication works when you log in). See Configuring Integrated Windows Authentication on page 116. Make sure that the user is using Internet Explorer version 5.5 or higher.

Chapter 13

Troubleshooting UserAuthority

291

User-Related Problems

Make sure that the user is not using another proxy on route to the UserAuthority WAPS. To verify that there is no intermediate proxy, in Internet Explorer, select Tools > Internet Options > LAN Settings and make sure that your browser is not configured with a conflicting proxy. Make sure that the WAPS is in the local domain of the users browser and that all the local Web pages are recognized as Intranet sites. See Ensuring that all Local Web pages are Recognized as Intranet Sites on page 120.

292

APPENDIX

Integrating UserAuthority with Meta IP

In This Appendix
Overview Required Components Preliminary Steps Windows DC Configuration VPN-1 Pro Policy Configuration DHCP Server Configuration page 293 page 293 page 294 page 294 page 294 page 296

Overview
Meta IP has a DHCP plugin that monitors a DHCP Server IP subscription. UserAuthority can easily be integrated with the Meta IP product to provide authenticated IP addresses from an authenticated IP pool to authenticated users.

Required Components
Check Point NG with Application Intelligence, UserAuthority Server. A Microsoft Windows NT or Windows 2000 Server Domain Controller (DC). A DHCP relay installed on the router. Check Point SmartDashboard installed on a management server. Meta IP Feature Pack 2 Hotfix 1 (Professional or Enterprise edition). Meta IP UAA Programmable Extension component.

293

Preliminary Steps
Install Check Point VPN-1 Pro, UserAuthority Server, and Check Point SMART Clients (see Installing and Configuring UAS on VPN-1 Pro on page 49). Install Check Point UserAuthority Server on the Windows DC (see Installing and Configuring the UAS on the Windows DC on page 61).

Windows DC Configuration
1 After installation, verify that uatcs.bat script and its associated files have been installed in the netlogon shared folder on the Windows DC. These files should reside in the same folder that is used to store user logon scripts for the Windows domain. For example, on a Windows 2000 Server, the path to this folder is:
<windows_dir>\SYSVOL\<win_domain_name>\scripts
Note - The following files should reside in netlogon shared folder:

instuatc.exe uatc.exe uatcs.bat uatcs-acl.txt

Edit the uatcs-acl.txt file to include an entry for your Windows DC. If your Windows DC has multiple interfaces, add an entry for each IP address associated with the Windows DC. For example, to add a Windows DC called DOMAINCONTROL with IP addresses 172.16.10.21 and 10.11.1.1, add the following entries to the uatcs-acl.txt file:
DOMAINCONTROL 172.16.10.21 19195 DOMAINCONTROL 10.11.1.1 19195

Using Active Directory Users and Computers (Windows 2000 Server) or User Manager For Domains (NT 4.0 Server), configure each users profile to run the uatcs.bat logon script.

VPN-1 Pro Policy Configuration

See the Check Point Firewall and SmartDefense Guide for details on how to perform the following procedures in SmartDashboard: 1 Add the Windows DC: A From SmartDashboard, click the your Domain Controller.
Network Objects

tab and create an object for The

Check

B Right click Check Points and select Point Host window is displayed.

New > Check Point > Host.

294

C Enter the name of the Windows DC. D Enter the IP address of the Windows DC. E Under Check Point Products, select the UserAuthority Server checkbox and click Communication. If trust has not been established, provide an activation key and click Initialize to establish trust between the Windows DC and VPN-1 Pro. After initialization, click Close. F Click 2
OK

to close the window.

Create an entry for each Meta IP DHCP server under nodes in the Check Point SmartDashboard. Right-click Nodes, and select New > Host. A Enter a name for the host. B Enter an IP address. C Click
OK

to close the window.

tab, right click OPSEC Application, and select New For more information on configuring OPSEC applications, see Chapter 11, UserAuthority OPSEC APIs.
OPSEC Applications OPSEC Application.

Open the

A Enter a name for the OPSEC application (for example, dhcp_uaa). B Select a DHCP server object as the host for the OPSEC application. C In the Client Entities area, select the UAA checkbox. Click Communication and specify an activation key, then click Initialize. After initialization, click Close. Note that trust will not be established between the DHCP server and the OPSEC Application object on the firewall until the DHCP server has pulled the certificate from the Certificate Authority. 4 For networks that use UAA communications, configure a rule on the VPN-1 Pro to allow communications over the following ports: UDP Communications between the VPN-1 Pro and the Windows DC on ports 19194 and 19195 (you may choose pre-defined service: CP_SecureAgent). TCP Communications between the DHCP Server(s) and VPN-1 Pro on ports 19191 and 18210 (you may choose pre-defined services: FW_uaa and FW_ica_pull). Install the policy.

Chapter A

295

DHCP Server Configuration

1 Run the opsec_pull_cert utility, which establishes trust with the Certificate Authority (VPN-1 Pro). The required command line parameters are: -h <VPN-1 Pro IP address> -n <OPSEC application object name> -p <activation key> Example:
opsec_pull_cert.exe -h 172.16.10.20 -n UAAPE_NT -p activation_password

The n parameter must match the name of the OPSEC application object created in the Firewall Policy Configuration procedure. The p parameter must match the activation key specified in the OPSEC Communications Properties dialog.
Note - On Windows NT 4.0 Servers, it may be necessary to provide the FQDN of the VPN-Pro instead of the IP address of the -h parameter.

Install the DHCP UAA programmable extension on the DHCP Server and on the computer hosting the Meta IP NG FP2 Management Console by running the installation package. On Windows Platforms, run the mip_uape51.msi file to install the programmable extension and UI Updates. On Solaris platforms, do the following: A Copy miusrauth.tgz to a directory on the DHCP Server. B unzip miusrauth.tgz C tar -xvf miusrauth.tar
D ipkgadd -d

E Choose to install the miusrauth package. F Answer yes to the following prompt:
The following files are already installed on the system and are being used by another package: /opt/metaip51/bin/dhcsim /opt/metaip51/sbin/dhcpd Do you want to install these conflicting files [y,n,?,q] y

G Add the Check Point SVN Foundation library path to the metaip51 profiles: metaip51_profile.sh and metaip51_profile.csh.
296

H After installation completes, restart the SMC service:

/etc/init.d/mip-smc-51 start

On Linux (7.3 and later) A Copy the file miusrauth-51-00.i386.rpm to a directory on the DHCP server ii rpm -i miusrauth-51-00.i386.rpm B Add the Check Point SVN Foundation library path to the metaip51 profiles: metaip51_profile.sh and metaip51_profile.csh. C After installation completes, restart the SMC service:
/etc/init.d/mip-smc-51 start
Note - If you have a secondary DHCP server, you must configure the secondary DHCP server to authenticate with the same UserAuthority server that the primary DHCP server uses.

On Unix platforms, modify the LD_LIBRARY_PATH in the Meta IP profiles to include the CPShared library directory. This enables DHCP to dynamically link to the OPSEC libraries. A Open /opt/metaip51/etc/metaip51_profile.sh. in a text editor. On Linux platforms, change:
LD_LIBRARY_PATH="${CPIPIDIR}/lib:${LD_LIBRARY_PATH}"

to
LD_LIBRARY_PATH="${CPIPIDIR}/lib:/opt/CPshrd-55-03/ lib:${LD_LIBRARY_PATH}"

On Solaris platforms, change:

LD_LIBRARY_PATH="${CPIPIDIR}/lib:${LD_LIBRARY_PATH}"

to
LD_LIBRARY_PATH="${CPIPIDIR}/lib:/opt/CPshrd-55/ lib:${LD_LIBRARY_PATH}"

B Open /opt/metaip51/etc/metaip51_profile.csh. in a text editor. On Linux platforms, change:

setenv LD_LIBRARY_PATH "${CPIPIDIR}/lib:${LD_LIBRARY_PATH}"

to
setenv LD_LIBRARY_PATH "${CPIPIDIR}/lib:/opt/CPshrd-55-03/ lib:${LD_LIBRARY_PATH}"

Chapter A

297

 ii On Solaris platforms, change:

setenv LD_LIBRARY_PATH "${CPIPIDIR}/lib:${LD_LIBRARY_PATH}"

to
setenv LD_LIBRARY_PATH "${CPIPIDIR}/lib:/opt/CPshrd-55/ lib:${LD_LIBRARY_PATH}"

Note - Check Point SVN Foundation R 55 with Application Intelligence uses the CPshrd-55 directory. If the directory name for CPshared changes, you must update the Meta IP profile files to reflect the new path.

C Stop and restart the SMC service:

/etc/init.d/mip-smc-51 stop /etc/init.d/mip-smc-51 start

To configure DHCP, enter the following information in the UserAuthority window: A The complete Path to the UserAuthority Extension on the DHCP Server (for example, Program Files\MetaIP\5.1\lib\uaauth.dll or /opt/metap51/ lib/uaauth.so)
machine

B The IP Address of the UserAuthority Server : This server is usually located on the same computer that is running the VPN-1 Pro. Specify the IP address of this server. C The Port that UserAuthority Server Listens on: The default port is 19191. If UserAuthority is configured to listen on a different port, enter that port number instead. D Timeout (in seconds) for UA Queries (1-300): The maximum time that the DHCP server should wait for a response from the UserAuthority server. Do not change this value unless you have a specific reason. E The Secure Internal Communication (SIC) name of the OPSEC Client returned by the Certificate Authority. To find this name, open the OPSEC Application Properties dialog for your OPSEC application object in the Check Point Policy Editor. The SIC name for the OPSEC client appears near the bottom of the dialog in the DN: edit box. Example: CN=UAAPE_NT,O=SAGITTARIUS.uagdomain.metainfo.com.sct29n
Client SIC Name:

298

Server SIC Name: The SIC name of the Certificate Authority (VPN-1 Pro). To find this name, open the VPN-1 Pro servers Properties window in the Check Point Policy Editor. You can open this dialog by clicking on the Network Objects tab in the Policy Editor, selecting the Check Point object corresponding to your VPN-1 Pro, and selecting Edit from the pop-up menu for that object. The Secure Internal Communication (SIC) name for the Certificate Authority (FireWall-1) appears near the bottom of the dialog in the DN: edit box. Example: CN=cp_mgmt,O=SAGITTARIUS.uagdomain.metainfo.com.sct29n

G Complete Path to the p12 file on the DHCP Server machine: Enter the path to the certificate file that was created when you ran the opsec_pull_cert utility (for example, Program Files\MetaIP\5.1\etc\opsec.p12 or /opt/metap51/ etc/opsec.p12). H Logging: Set the desired logging level. Logging levels include (listed from most detailed to least detailed): Debug: Client authentication debug messages. Info: Client authentication information messages.arn Warning messages on client authentication. Error: Error messages on client authentication. Std. Error: Logs messages to STDERROR. 5 Create a Shared network object containing at least two lease pools: one unauthenticated and one authenticated. A In the authenticated lease pool, set the following parameters and options: DHCP Parameter Client Request Handling Authentication level = Authenticated One Lease Per Client = True DHCP Parameter Lease Time Default Lease Time = desired lease time for authenticated clients DHCP Options: (3) Routers = the IP address of the router to reach the Domain Controller and WINS server (44) NetBIOS Name Server = the IP address of the WINS server (46) NetBIOS Node Type = the desired NETBIOS node type (P, M, or H Node) B In the unauthenticated lease pool, set the following parameters and options: DHCP Parameter Client Request Handling Authentication level = Unauthenticated One Lease Per Client = True.

Chapter A

299

 DHCP Parameter Lease Time Default Lease Time = 3060 seconds (short lease time recommended). DHCP Options: (3) Routers = the IP address of the router to reach the Domain Controller and WINS server (44) NetBIOS Name Server = the IP address of the WINS server (46) NetBIOS Node Type = the desired NETBIOS node type (P, M, or H Node) 6 Right click the DHCP service and select
Export DHCP Service.

Note - Client SIC Name and Server SIC Name are case-sensitive.

300

APPENDIX

Glossary
In This Appendix
Acronyms and Abbreviations page 301

Acronyms and Abbreviations

The following acronyms and abbreviations are used in this guide.
TABLE 13-2

Glossary of Terms

OPSEC OWASP SIC SSO TIP UAA UAS WAPI WAPS WebAccess Windows DC

Open Platform for Security Open Web Application Security Project Secure Internal Connection Single Sign On Trusted Identification Point UserAuthority API UserAuthority Server WebAccess Plug-In WebAccess Proxy Server A general name for WAPS and WAPI Windows Domain Controller

301

302

Index

A
Abuse Tracking 209 Access control 188 enforcement 132 scenarios 134 Access control problems 188 file permissions 189 forced browsing 189 insecure IDs 188 path traversal 189 separating the application from access control 188 Achieving User Identity 101 Administrator types 22 APIs Assertions Management 252 event handlers 260 Application authentication 113 Application information 106 Application Manager 22 Application misconfiguration 193 Auditing configuring, for external resources 206 Outbound Traffic using UserAuthority Outbound Access Control 198 overview 195 requests for URLs outside the policy scope 208 SSO abuse tracking 209 user requests 203 using logs 196 Web Access using UserAuthority WebAccess 201 WebAccess authorization rejections 204 WebAccess requests 206 Authentication domains defining 92 Authentication methods basic HTTP 100 HTML form-based 100 HTTP headers 100

NTLM 101 SecureAgent 102 using a header 108 Authorization creating rules 131 policy 130 rejections 204 rule base 131 Authorization policy defining 147 Authorization rules 131, 150 defining 146 Authorization scenarios different authorization levels 134 enforcing SSL encryption 136 Automatic synchronization 223 using db_sync Script 223

B
B2C deployment 18 benefits with UserAuthority 19 components 33 overview 32 sample deployment 34 workflow 36 Broken access control 188

Clustering 215 defining security policy 221 logical server 219 VPN-1 Pro 222 Clusters VPN-1 Pro 222 WebAccess proxies 217 Common Suffix Domains 30 domains 83 Configuring Common Suffix Domains 83 UserAuthority Server 55 UserAuthority Server properties 65 Web SSO policy 85 WebAccess in SmartDashboard 75 WebAccess Plug-In in SmartDashboard 83 WebAccess proxy 72 Connect Control 218 Credentials Manager 101 automatic synchronization 223 mapping user identity 106 synchronizing 222 tables 107 Custom Rejection Policy 144

D
Databases using local Check Point 183 db_sync script 223 DC 294 Debugging 260 Deployment Business to Customer (B2C) 18, 32 Citrix MetaFrame Server or Windows Terminal Services 42 Enterprise with Enterprise Web Applications 25 Outbound Access Control 38

C
Cache proxy users 124 Citrix MetaFrame deployment 17, 42 Citrix MetaFrame Server or Windows Terminal Services deployment sample deployment 43 workflow 43 Citrix MetaFrame Servers Outbound Access Control 176 Citrix MetaFrame Terminals Outbound Access Control 172

303

E overview 23 SSO for VPN-1 Pro 20 UserAuthority for Enterprise Web Applications 14 WebAccess 27 Deployments combining 45 typical 14 DHCP server configuration 296 Domain Controllers adding 176 Domain equality configuring 177

G
Graphics files eliminating logging 213 Groups defining 172

K
Key assertions 244

L
LDAP database 183 License installing 49 Load balancing 216 configuring WebAccess clusters 218 Local Web pages ensuring recognition as Intranet sites 120 Log records viewing in SmartTracker 202 Logical server defining 219 Logs configuring for UserAuthority Server on the FireWall Gateway 270 configuring for UserAuthority Servers not on a FireWall Gateway 271 customizing 210 customizing specific entries 212 disabling specific entries 211 eliminating graphics files 213 for actions taken for URLs outside policy scope 205 rejection policy, configuring 207 SSO abuse 209 SSO rejection 205 system monitoring 269 use in auditing 196 viewing 196 WebAccess 202

H
High availability 215 using a VPN-1 Pro cluster 222 using Multiple Domain Controllers 222 WebAccess proxy clusters 216 HTML form authentication 100, 113 HTTP authentication 100 basic authentication 113 headers 100

E
Enterprise with Enterpise Web Applications deployment benefits with UserAuthority 17 components 26 drawbacks without UserAuthority 15 Event Handlers 260 UAA_AUTHENTICATE_RE PLY 263 UAA_QUERY_REPLY 261 UAA_UPDATE_REPLY E 262 Event Handling 243 External database 183 External resources auditing requests 206 monitoring access to 198

I
Identification on a Citrix or Terminal Services system 103 using NTLM Authentication Protocol 102 using SecureAgent 170 Identity sharing 170 configuring manual 125 manual 111 Insecure IDs 188 Insert Header Effect configuring 90 Installing UserAuthority license 49 UserAuthority on UNIX/ Linux-based machine 54 UserAuthority Server 49 UserAuthority Server on Domain Controller 61 WebAccess Plug-In 80 WebAccess proxy 71 Integrated Windows Authentication 27 configuring 116 Internal proxy 108 Internal users 101 authenticating 101

F
File permissions 189 File type specifying for a URL 194 Firewall gateway 27 Forced browsing 189 Function calls 251 assertions Iteration 257 assertions management 252 debugging 260 managing authentication requests 256 managing queries 254 managing UAA Errors 259 managing updates 256 session management 251

M
Manual Identity sharing 111 configuring 125 Mapping user credentials 101 Mapping user identity 106 manually 107 Maximal client request buffer size 153

304

S Meta IP 293 DHCP server configuration 296 Domain Controller configuration 294 VPN-Pro policy configuration 294 Windows Domain Controller configuration 294 Module status types 266 Monitoring 265 example 272 system 266 system status 266 user 273 Multiple Domain Controllers 222 Outbound Access Control 172 Multiple domains Outbound Access Control 174

P
Path traversal 189 Policy VPN-1 Pro 182 WebAccess 182 Programming model 237

R
Randomized session ID 190 Rejection Policy logs configuring 207 Remote administration flaws 191 lack of strong ID requirements 192 poor auditing 192 poor documentation 192 poor session protection 192 Remote users with a VPN Client 104 without VPN Client 105 Request Assertions 245 Requests for external resources configuring auditing 206 Requests for URLs outside the policy scope configuring auditing 208 Reverse proxy rules 84 Rules authorization 131 scope 132 security 131

N
NTLM 101

O
Open Web Application Security Project 187 Operation objects defining 154 Operations 132 OPSEC APIs 21, 237 overview 241 OPSEC protocols 21 Outbound Access Control 38, 167 identity sharing 170 multiple domains 174 on Citrix MetaFrame Servers 176 UserAuthority solution 168 with SSO 171 Outbound Access Control deployment components 38 sample deployment 38 workflow 39

S
SecureAgent 102 automatic installation 68 Outbound Access Control 170 Security SSL encryption 136 Security Administrator 22 Security policy defining 221 Security Requirements rule base 131 Security rules 131, 148 defining 146 Server Groups creating 218 defining a security policy for 221

Session management 189 Session timeouts 190 SIC reestablishing 284 verifying status 283 Single Sign On configuring 89 Effect 89 SmartDashboard configuring additional Web sites 122 configuring WebAccess 75 configuring WebAccess PlugIn 83 creating groups 172 SmartView Tracker interface 196 SSL Encryption enforcing 136 SSO Applications with no Authentication Requirements 114 establishing for VPN-1/ Firewall-1 39 HTML Form Authentication 113 HTTP Basic Authentication 113 UserAuthority solution for VPN-1 167 Web sites 145 SSO abuse tracking configuring 209 SSO for VPN-1 Pro 167 on Citrix terminals 172 UserAuthority solution 168 SSO for VPN-1 Pro deployment 20 adding SSO rule 39 on Windows Terminal Services 176 SSO rules 85 creating 39 creating for SSO for Citrix MetaFrame or Windows Terminal Services 44 System monitoring 266 UserAuthority Server 267 using logs 269 using UserAuthority Server logs 270 using WebAccess logs 269 WebAccess 268

305

T
Testing deployment Application with no Authentication Requirements 114 combined deployment 48 Outbound Access Control 39, 43 SSO with HTML Basic Authentication 113 SSO with HTML Form Authentication 114 UA with B2C 37 UA with Enterprise Web Applications 32 Web SSO with Internal Proxy 110 Web SSO with Manual Identity Sharing 112 Web SSO with more than one Web site 111 Timeouts 153 Troubleshooting general problems 280 no established SIC 283 no logs in SmartView Tracker 286 proxy error 281 SecureAgent does not identify the user 288 service not available 280 service not available to user 286 user cannot sign in 287 User-related problems 286 users not authorized to view page 282 users receive popup when signed on 291 Trust object group defining 165 Trust Objects defining 159 parameters 160 Trust objects 132 Trusted Identification Points 13, 98, 101, 170

U
UAA Assertions structure functions 250

UAA Client application structure 242 event handling 243 key assertions 244 request assertions 245 requests 243 server configuration 240 UAA errors 259 UAS Groups creating 127 URL objects defining 145 User credentials manual update 115 mapping 101 User Groups different authorization levels 134 in UserAuthority 182 User Identity 101 mapping to application information 106 providing for VPN-1 Pro 168 sharing between Web servers 111 User monitoring 273 example of successful access attempt 275 example of unsuccessful access attempt 276 User requests 203 UserAuthority advantages 11 installing license 49 integrating with Meta IP 293 introduction 11 management model 21 Queries 249 underlying concept 13 UserAuthority API 237 function calls 251 overview 241 programming model 238 UserAuthority CLIs 226 UserAuthority for Enterprise Web Applications deployment 14, 25 sample deployment 26 workflow 31 UserAuthority Server configuring 55 configuring SecureAgent automatic installation 68 installing on a Windows gateway 50

installing on Domain Controller 61 installing on VPN-1 Pro 49 monitoring 267 UserAuthority Server properties 65 UserAuthority Settings configuring manual 114 Users in UserAuthority 182 managing 181

V
Virtual hosts 29 configuring 84 defining 84 VPN-1 Pro clusters 222 defining authentication actions in authentication policy 182 deployment with multiple domain controllers 172 deployment with multiple domains 174 Outbound Access Control 167 policy configuration 294

W
Web Applications authorization 129 SSO types 100 Web security 187 application misconfiguration 193 broken access control 188 broken account and session management 189 overview 187 remote administration flaws 191 session-related vulnerabilities 190 Web server misconfiguration 193 Web Security Administrator 22 Web server misconfiguration 193 limiting access 193 limiting access to file types 193 precautions 193 Web sites advanced properties 141

306

W configuring additional in SmartDashboard 122 custom rejection policy 144 defining 138 defining advanced options 141 defining URLs 145 SSO only 145 Web SSO 97 manual identity sharing 111 policy 85 rule configuring 85 types 100 UserAuthority solution 98 with Citrix 110 with internal proxy 108 with more than one Web Server 110 WebAccess advanced configuration 124, 153 application settings, configuring 87 authorization rejections 204 configuration considerations 29 configuring SSO for application authentication 113 configuring to recogize Windows user groups 184 configuring to recognize cache proxy users 124 creating authorization policy 137 defining policy 182 disabling for specific IP addresses 115 logs 201 monitoring 268 WebAccess deployment 27 components 27 sample deployment 28 WebAccess Plug-In 28 configuring in SmartDashboard 83 installing 80 WebAccess proxy 27 configuring 72 configuring using SmartDashboard 75 defining a security policy server group 221 installing 71 WebAccess proxy clusters 216 WebAccess requests configuring auditing 206 Windows Groups 154 retrieving with UserAuthority 171 Windows Terminal Services 176 deployment 17, 42 Windows user identity using 184

307

308