CP R75.40VS IdentityAwareness AdminGuide

Identity Awareness
R75.40VS
Administration Guide
15 July 2012
Classification: [Protected]
2012 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: Refer to the Copyright page (http://www.checkpoint.com/copyright.html) for a list of our trademarks. Refer to the Third Party copyright notices (http://www.checkpoint.com/3rd_party_copyright.html) for a list of relevant copyrights and third-party licenses.
Important Information
Latest Software
We recommend that you install the most recent software release to stay up-to-date with the latest functional improvements, stability fixes, security enhancements and protection against new and evolving attacks.
Latest Documentation
The latest version of this document is at: http://supportcontent.checkpoint.com/documentation_download?ID=16185 For additional technical information, visit the Check Point Support Center (http://supportcenter.checkpoint.com).
Revision History
Date 7/15/2012 Description First release of this document
Feedback
Check Point is engaged in a continuous effort to improve its documentation. Please help us by sending your comments (mailto:[email protected]?subject=Feedback on Identity Awareness R75.40VS Administration Guide).
Contents
Important Information .............................................................................................3 Getting Started With Identity Awareness ..............................................................7 Introduction ......................................................................................................... 7 AD Query .......................................................................................................10 Browser-Based Authentication .......................................................................11 Identity Agents ...............................................................................................13 Deployment ........................................................................................................14 Identity Awareness Scenarios ............................................................................15 Acquiring Identities for Active Directory Users ...............................................15 Acquiring Identities with Browser-Based Authentication .................................17 Acquiring Identities with Endpoint Identity Agents ..........................................20 Acquiring Identities in a Terminal Server Environment ...................................22 Acquiring Identities in Application Control ......................................................22 Configuring Identity Awareness ..........................................................................24 Enabling Identity Awareness on the Security Gateway .......................................24 Results of the Wizard .....................................................................................26 Creating Access Roles .......................................................................................26 Using Identity Awareness in the Firewall Rule Base ...........................................28 Access Role Objects ......................................................................................29 Negate and Drop ...........................................................................................29 Using Identity Awareness in the Application and URL Filtering Rule Base..........29 Source and Destination Fields .......................................................................31 Negate and Block ..........................................................................................31 Configuring Browser-Based Authentication in SmartDashboard .........................31 Portal Network Location .................................................................................32 Access Settings .............................................................................................32 Authentication Settings ..................................................................................32 Customize Appearance..................................................................................33 User Access ..................................................................................................33 Agent Deployment from the Portal .................................................................34 Configuring Endpoint Identity Agents ..................................................................34 Endpoint Identity Agent Types .......................................................................35 Endpoint Identity Agent Deployment Methods................................................37 Server Discovery and Trust............................................................................38 Configuring Endpoint Identity Agents in SmartDashboard ..............................39 Configuring Terminal Servers .............................................................................40 Deploying the Terminal Servers Identity Awareness Solution ........................41 Terminal Servers - Users Tab ........................................................................42 Terminal Servers Advanced Settings .............................................................42 Configuring Remote Access ...............................................................................43 Configuring Identity Logging for a Log Server .....................................................43 Enabling Identity Awareness on the Log Server for Identity Logging ..............44 Identity Sources ....................................................................................................45 Choosing Identity Sources ..................................................................................45 Advanced AD Query Configuration .....................................................................46 Configuring Identity Awareness for a Domain Forest (Subdomains) ..............46 Specifying Domain Controllers per Security Gateway ....................................47 Permissions and Timeout ..............................................................................48 Multiple Gateway Environments .....................................................................50 Non-English Language Support .....................................................................50 Performance ..................................................................................................50 Nested Groups...............................................................................................50
Troubleshooting .............................................................................................51 Advanced Browser-Based Authentication Configuration .....................................53 Customizing Text Strings ...............................................................................53 Adding a New Language................................................................................55 Server Certificates .........................................................................................57 Transparent Kerberos Authentication Configuration .......................................60 Advanced Endpoint Identity Agents Configuration ..............................................65 Customizing Parameters ................................................................................65 Prepackaging Endpoint Identity Agent Installation .........................................66 Advanced Deployment .........................................................................................67 Introduction ........................................................................................................67 Deployment Options ...........................................................................................68 Deploying a Test Environment ............................................................................68 Testing Identity Sources ................................................................................68 Testing Endpoint Identity Agents ...................................................................69 Deployment Scenarios .......................................................................................69 Perimeter Security Gateway with Identity Awareness ....................................69 Data Center Protection ..................................................................................70 Large Scale Enterprise Deployment ...............................................................71 Network Segregation .....................................................................................72 Distributed Enterprise with Branch Offices .....................................................73 Wireless Campus...........................................................................................75 Dedicated Identity Acquisition Gateway .........................................................75 Advanced Identity Agent Options ........................................................................77 Kerberos SSO Configuration ..............................................................................77 Overview........................................................................................................77 How SSO Operates .......................................................................................78 References ....................................................................................................78 SSO Configuration .........................................................................................79 Server Discovery and Trust ................................................................................83 Introduction ....................................................................................................83 Discovery and Trust Options ..........................................................................84 Option Comparison ........................................................................................85 Prepackaging Identity Agents .............................................................................91 Introduction ....................................................................................................91 Custom Endpoint Identity Agent msi ..............................................................91 Using the cpmsi_tool.exe ...............................................................................91 Sample INI File ..............................................................................................96 Deploying a Prepackaged Agent via the Captive Portal .................................97 Identity Awareness Commands ...........................................................................98 Introduction ........................................................................................................98 pdp .....................................................................................................................99 pdp monitor..................................................................................................100 pdp connections...........................................................................................101 pdp control ...................................................................................................102 pdp network .................................................................................................102 pdp debug....................................................................................................103 pdp tracker...................................................................................................104 pdp status ....................................................................................................105 pdp update...................................................................................................105 pep ...................................................................................................................106 pep show .....................................................................................................106 pep debug....................................................................................................108 adlog ................................................................................................................109 adlog query ..................................................................................................109 adlog dc .......................................................................................................110 adlog statistics .............................................................................................110 adlog debug .................................................................................................110 adlog control ................................................................................................111
adlog service_accounts ...............................................................................111 test_ad_connectivity .........................................................................................112 Regular Expressions .......................................................................................... 113 Metacharacters.................................................................................................113 Square Brackets ...............................................................................................114 Parentheses .....................................................................................................114 Hyphen .............................................................................................................114 Dot ...................................................................................................................114 Vertical Bar .......................................................................................................114 Backslash .........................................................................................................114 Escaping Symbols .......................................................................................114 Encoding Non-Printable Characters .............................................................115 Specifying Character Types .........................................................................115 Quantifiers ........................................................................................................115 Curly Brackets .............................................................................................116 Question Marks............................................................................................116 Asterisk ........................................................................................................116 Plus .............................................................................................................116 Index .................................................................................................................... 117
Getting Started With Identity Awareness
Chapter 1
In This Chapter Introduction Deployment Identity Awareness Scenarios 7 14 15
Introduction
Traditionally, firewalls use IP addresses to monitor traffic and are unaware of the user and machine identities behind those IP addresses. Identity Awareness removes this notion of anonymity since it maps users and machine identities. This lets you enforce access and audit data based on identity. Identity Awareness is an easy to deploy and scalable solution. It is applicable for both Active Directory and non-Active Directory based networks as well as for employees and guest users. It is currently available on the Firewall blade and Application Control blade and will operate with other blades in the future. Identity Awareness lets you easily configure network access and auditing based on network location and: The identity of a user The identity of a machine
When Identity Awareness identifies a source or destination, it shows the IP address of the user or machine with a name. For example, this lets you create firewall rules with any of these properties. You can define a firewall rule for specific users when they send traffic from specific machines or a firewall rule for a specific user regardless of which machine they send traffic from.
Identity Awareness Administration Guide R75.40VS | 7
In SmartDashboard, you use Access Role objects to define users, machines and network locations as one object.
Identity Awareness also lets you see user activity in SmartView Tracker and SmartEvent based on user and machine name and not just IP addresses.
Identity Awareness gets identities from these acquisition sources: AD Query Browser-Based Authentication Endpoint Identity Agent Terminal Servers Identity Agent Remote Access
The table below shows how identity sources are different in terms of usage and deployment considerations. Depending on those considerations, you can configure Identity Awareness to use one identity source or a combination of identity sources ("Choosing Identity Sources" on page 45). Source AD Query Description Gets identity data seamlessly from Microsoft Active Directory (AD) Recommended Usage
Identity based auditing and logging Leveraging identity in Internet application control Basic identity enforcement in the internal network
Deployment Considerations
Easy configuration (requires AD administrator credentials). For organizations that prefer not to allow administrator users to be used as service accounts on third party devices there is an option to configure AD Query without AD administrator privileges, see sk43874 (http://supportcontent. checkpoint.com/soluti ons?id=sk43874). Preferred for desktop users Only detects AD users and machines Used for identity enforcement (not intended for logging purposes)
Browser-Based Authentication
Captive Portal sends Captive Portal unidentified users to Identity based a Web portal for enforcement for authentication non-AD users If Transparent Kerberos Authentication is configured, the browser attempts to authenticate users transparently by getting identity information before the Captive Portal Username/password page is shown to the user.
(non-Windows and guest users) For deployment of Endpoint Identity Agents
Transparent Kerberos Authentication

In AD environments, when users are already logged in to the domain the browser obtains identity information from the credentials used in the original log in (SSO). Leveraging identity for Data Center protection Protecting highly sensitive servers When accuracy in detecting identity is crucial See Choosing Identity Sources (on page 45).
Endpoint Identity A lightweight Agent endpoint agent that authenticates securely with Single Sign-On (SSO)
Source
Description
Recommended Usage
Identify users that use a Terminal Servers or Citrix environment.
Deployment Considerations
See Choosing Identity Sources (on page 45).
Terminal Servers To identify multiple Identity Agent users that connect from one IP address, a Terminal Server Identity agent is installed on the application server that hosts Terminal/Citrix services.
Remote Access
Users that gain access through IPSec VPN Office Mode are seamlessly authenticated.
Identify and apply identitybased security policy on users that access the organization through VPN.
See Choosing Identity Sources (on page 45).
Identity aware gateways can share the identity information that they acquire with other identity aware gateways. In this way, users that need to pass through several enforcement points are only identified once. See Advanced Deployment (on page 67) for more information.
AD Query
AD Query is an easy to deploy, clientless identity acquisition method. It is based on Active Directory integration and it is completely transparent to the user. The AD Query option operates when: An identified asset (user or machine) tries to access an Intranet resource that creates an authentication request. For example, when a user logs in, unlocks a screen, shares a network drive, reads emails through Exchange, or accesses an Intranet portal. AD Query is selected as a way to acquire identities.
The technology is based on querying the Active Directory Security Event Logs and extracting the user and machine mapping to the network address from them. It is based on Windows Management Instrumentation (WMI), a standard Microsoft protocol. The Security Gateway communicates directly with the Active Directory domain controllers and does not require a separate server. No installation is necessary on the clients or on the Active Directory server. Identity Awareness supports connections to Microsoft Active Directory on Windows Server 2003 and 2008.
How AD Query Operates - Firewall Rule Base Example

The steps listed in the example align with the numbers in the image below. 1. The Security Gateway registers to receive security event logs from the Active Directory domain controllers. 2. A user logs in to a desktop computer using his Active Directory credentials. 3. The Active Directory DC sends the security event log to the Security Gateway. The Security Gateway extracts the user and IP information (user name@domain, machine name and source IP address). 4. The user initiates a connection to the Internet. 5. The Security Gateway confirms that the user has been identified and lets him access the Internet based on the policy.
Browser-Based Authentication
Browser-Based Authentication acquires identities from unidentified users. You can configure these acquisition methods: Captive Portal Transparent Kerberos Authentication
Captive Portal is a simple method that authenticates users through a web interface before granting them access to Intranet resources. When users try to access a protected resource, they get a web page that must fill out to continue.
With Transparent Kerberos Authentication, the browser attempts to authenticate users transparently by getting identity information before the Captive Portal username/password page opens. When you configure this option, the Captive Portal requests authentication data from the browser. Upon successful authentication, the user is redirected to its original destination. If authentication fails, the user must enter credentials in the Captive Portal. The Captive Portal option operates when a user tries to access a web resource and all of these apply: The Captive Portal is selected as a way to acquire identities and the redirect option has been set for the applicable rule. Unidentified users cannot access that resource because of rules with access roles in the Firewall / Application Rule Base. But if users are identified, they might be able to access the resource. Transparent Kerberos Authentication was configured, but authentication failed.
When these criteria are true, Captive Portal acquires the identities of users. From the Captive Portal users can: Enter an existing user name and password if they have them. For guest users, enter required credentials. Configure what is required in the Portal Settings. Click a link to download an Identity Awareness agent. Configure this in the Portal Settings.
How Captive Portal Operates - Firewall Rule Base

The steps listed in the example align with the numbers in the image below. 1. A user wants to access the Internal Data Center. 2. Identity Awareness does not recognize him and redirects the browser to the Captive Portal. 3. The user enters his regular office credentials. The credentials can be AD or other Check Point supported authentication methods, such as LDAP, Check Point internal credentials, or RADIUS. 4. The credentials are sent to the Security Gateway and verified in this example against the AD server. 5. The user can now go to the originally requested URL.
How Transparent Kerberos Authentication Operates

1. A user wants to access the Internal Data Center. 2. Identity Awareness does not recognize the user and redirects the browser to the Transparent Authentication page. 3. The Transparent Authentication page asks the browser to authenticate itself. 4. The browser gets a Kerberos ticket from the Active Directory and presents it to the Transparent Authentication page. 5. The Transparent Authentication page sends the ticket to the Security Gateway which authenticates the user and redirects it to the originally requested URL. 6. If Kerberos authentication fails for some reason, Identity Awareness redirects the browser to the Captive Portal.
Identity Agents
There are two types of Identity Agents: Endpoint Identity Agents - dedicated client agents installed on users' computers that acquire and report identities to the Security Gateway. Terminal Servers Identity Agent - an agent installed on an application server that hosts Citrix/Terminal services. It identifies individual users whose source is the same IP address. ("Configuring Terminal Servers" on page 40)
Check Point Endpoint Identity Agent
Using Endpoint Identity Agents gives you: User and machine identity Minimal user intervention - all necessary configuration is done by administrators and does not require user input. Seamless connectivity - transparent authentication using Kerberos Single Sign-On (SSO) when users are logged in to the domain. If you do not want to use SSO, users enter their credentials manually. You can let them save these credentials. Connectivity through roaming - users stay automatically identified when they move between networks, as the client detects the movement and reconnects. Added security - you can use the patented packet tagging technology to prevent IP Spoofing. Endpoint Identity Agents also gives you strong (Kerberos based) user and machine authentication.
These are the types of Endpoint Identity Agents you can install: Full - requires administrator permissions for installation. If installed by a user without administrator permissions, it will automatically revert to installing the Light agent. The Full agent performs packet tagging and machine authentication. Light - does not require administrator permissions for installation. Cannot be configured with packet tagging or machine authentication. The light agent supports Microsoft Windows and Mac OS X. For supported version information, see the R75.40VS Release Notes (http://supportcontent.checkpoint.com/solutions?id=sk76540). Custom - a customized installation package. For more information, see Prepackaging Identity Agents (on page 91).
Users can download and install Endpoint Identity Agents from the Captive Portal or you can distribute MSI/DMG files to computers with distribution software or any other method (such as telling them where to download the client from).
How You Download an Endpoint Identity Agent - Example

This is how a user downloads the Endpoint Identity Agent from the Captive Portal: 1. A user logs in to his PC with his credentials and wants to access the Internal Data Center. 2. The Security Gateway enabled with Identity Awareness does not recognize him and sends him to the Captive Portal. 3. The Security Gateway sends a page that shows the Captive Portal to the user. It contains a link that he can use to download the Endpoint Identity Agent. 4. The user downloads the Endpoint Identity Agent from the Captive Portal and installs it on his PC. 5. The Endpoint Identity Agent client connects to the Security Gateway. If SSO with Kerberos is configured, the user is automatically connected. 6. The user is authenticated and the Security Gateway sends the connection to its destination according to the Firewall Rule Base.
Deployment
Identity Awareness is commonly enabled on the perimeter gateway of the organization. It is frequently used in conjunction with Application Control. To protect internal data centers, Identity Awareness can be enabled on an internal gateway in front of internal servers, such as data centers. This can be in addition to on the perimeter gateway but does not require a perimeter gateway. Identity Awareness can be deployed in Bridge mode or Route mode. In Bridge mode it can use an existing subnet with no change to the hosts' IP addresses. In Route mode the gateway acts as a router with different subnets connected to its network interfaces.
For redundancy, you can deploy a gateway cluster in Active-Standby (HA) or Active-Active (LS) modes. Identity awareness supports ClusterXL HA and LS modes. If you deploy Identity Awareness on more than one gateway, you can configure the gateways to share identity information. Common scenarios include: Deploy on your perimeter gateway and data center gateway. Deploy on several data center gateways. Deploy on branch office gateways and central gateways.
You can have one or more gateways acquire identities and share them with the other gateways. You can also share identities between gateways managed in different Multi-Domain Servers.
Identity Awareness Scenarios

This section describes scenarios in which you can use Identity Awareness to let users access network resources. The first 3 scenarios describe different situations of acquiring identities in a Firewall Rule Base environment. The last scenario describes the use of Identity Awareness in an Application Control environment.
Acquiring Identities for Active Directory Users

Organizations that use Microsoft Active Directory as a central user repository for employee data can use AD Query to acquire identities. When you set the AD Query option to get identities, you are configuring clientless employee access for all Active Directory users. To enforce access options, make rules in the Firewall Rule Base that contain access role objects. An access role object defines users, machines and network locations as one object. Active Directory users that log in and are authenticated will have seamless access to resources based on Firewall Rule Base rules. Let's examine a scenario to understand what AD Query does.
Scenario: Laptop Access

John Adams is an HR partner in the ACME organization. ACME IT wants to limit access to HR servers to designated IP addresses to minimize malware infection and unauthorized access risks. Thus, the gateway policy permits access only from John's desktop which is assigned a static IP address 10.0.0.19. He received a laptop and wants to access the HR Web Server from anywhere in the organization. The IT department gave the laptop a static IP address, but that limits him to operating it only from his desk. The current Rule Base contains a rule that lets John Adams access the HR Web Server from his laptop with a static IP (10.0.0.19). Name Jadams to HR Server Source Jadams_PC Destination HR_Web_Server VPN Any Traffic Service Any Action accept Track Log
He wants to move around the organization and continue to have access to the HR Web Server. To make this scenario work, the IT administrator does these steps: 1. Enables Identity Awareness on a gateway, selects AD Query as one of the Identity Sources and installs the policy. 2. Checks SmartView Tracker to make sure the system identifies John Adams in the logs. 3. Adds an access role object to the Firewall Rule Base that lets John Adams access the HR Web Server from any machine and from any location. 4. Sees how the system tracks the actions of the access role in SmartView Tracker.
User Identification in the Logs

The SmartView Tracker log below shows how the system recognizes John Adams as the user behind IP 10.0.0.19.
This log entry shows that the system maps the source IP to the user John Adams from CORP.ACME.COM. This uses the identity acquired from AD Query. Note - AD Query maps the users based on AD activity. This can take some time and depends on user activity. If John Adams is not identified (the IT administrator does not see the log), he should lock and unlock the computer.
Using Access Roles

To let John Adams access the HR Web Server from any machine, it is necessary for the administrator to change the current rule in the Rule Base. To do this, it is necessary to create an access role ("Creating Access Roles" on page 26) for John Adams that includes the specific user John Adams from any network and any machine. Then the IT administrator replaces the source object of the current rule with the HR_Partner access role object and installs the policy for the changes to be updated. Name HR Partner Access Source HR_Partner Destination HR_Web_Server VPN Any Traffic Service Any Action accept Track None
The IT administrator can then remove the static IP from John Adam's laptop and give it a dynamic IP. The Security Gateway lets the user John Adams access the HR Web server from his laptop with a dynamic IP as the HR_Partner access role tells it that the user John Adams from any machine and any network is permitted access.
Acquiring Identities with Browser-Based Authentication

Browser-Based Authentication lets you acquire identities from unidentified users such as: Managed users connecting to the network from unknown devices such as Linux computers or iPhones. Unmanaged, guest users such as partners or contractors.
If unidentified users try to connect to resources in the network that are restricted to identified users, they are automatically sent to the Captive Portal. If Transparent Kerberos Authentication is configured, the browser will attempt to identify users that are logged into the domain using SSO before it shows the Captive Portal. Let's examine some scenarios to understand what Browser-Based Authentication does and the configuration required for each scenario.
Scenario: Recognized User from Unmanaged Device

The CEO of ACME recently bought her own personal iPad. She wants to access the internal Finance Web server from her iPad. Because the iPad is not a member of the Active Directory domain, she cannot identify seamlessly with AD Query. However, she can enter her AD credentials in the Captive Portal and then get the same access as on her office computer. Her access to resources is based on rules in the Firewall Rule Base.
Required SmartDashboard Configuration

To make this scenario work, the IT administrator must: 1. Enable Identity Awareness on a gateway and select Browser-Based Authentication as one of the Identity Sources. 2. In the Portal Settings window in the User Access section, make sure that Name and password login is selected. 3. Create a new rule in the Firewall Rule Base to let Jennifer McHanry access network destinations. Select accept as the Action. 4. Right-click the Action column and select Edit Properties. The Action Properties window opens. 5. Select the Redirect http connections to an authentication (captive) portal. Note: redirection will not occur if the source IP is already mapped to a user checkbox. 6. Click OK. 7. From the Source of the rule, right-click to create an Access Role. a) Enter a Name for the Access Role. b) In the Users tab, select Specific users and choose Jennifer McHanry. c) In the Machines tab make sure that Any machine is selected. d) Click OK. The Access Role is added to the rule. Name CEO Access Source Jennifer_McHanry Destination Finance_Server VPN Service Action accept (display captive portal) Track Log
Any http Traffic
User Experience
Jennifer McHanry does these steps: 1. Browses to the Finance server from her iPad. The Captive Portal opens because she is not identified and therefore cannot access the Finance Server. 2. She enters her usual system credentials in the Captive Portal. A Welcome to the network window opens. 3. She can successfully browse to the Finance server.

The SmartView Tracker log below shows how the system recognizes Jennifer McHanry from her iPad.
This log entry shows that the system maps the source "Jennifer_McHanry" to the user name. This uses the identity acquired from Captive Portal.
Scenario: Guest Users from Unmanaged Device

Guests frequently come to the ACME company. While they visit, the CEO wants to let them access the Internet on their own laptops. Amy, the IT administrator configures the Captive Portal to let unregistered guests log in to the portal to get network access. She makes a rule in the Firewall Rule Base to let unauthenticated guests access the Internet only. When guests browse to the Internet, the Captive Portal opens. Guests enter their name, company, email address, and phone number in the portal. They then agree to the terms and conditions written in a network access agreement. Afterwards they are given access to the Internet for a specified period of time.

To make this scenario work, the IT administrator must: 1. Enable Identity Awareness on a gateway and select Browser-Based Authentication as one of the Identity Sources. 2. In the Portal Settings window in the User Access section, make sure that Unregistered guest login is selected. 3. Click Unregistered guest login - Settings. 4. In the Unregistered Guest Login Settings window, configure: The data guests must enter. For how long users can access the network resources.
If a user agreement is required and its text. 5. Create two new rules in the Firewall Rule Base: a) If it is not already there, create a rule that identified users can access the internet from the organization. (i) From the Source of the rule, right-click to create an Access Role. (ii) Enter a Name for the Access Role. (iii) In the Users tab, select All identified users. (iv) Click OK. (v) The Access Role is added to the rule. Name Internet Source Identified_users Destination ExternalZone VPN Service Action accept
Any http Traffic
b) Create a rule to let Unauthorized Guests access only the internet. (i) From the Source of the rule, right-click to create an Access Role. (ii) Enter a Name for the Access Role. (iii) In the Users tab, select Specific users and choose Unauthenticated Guests. (iv) Click OK. The Access Role is added to the rule. (v) Select accept as the Action. (vi) Right-click the Action column and select Edit Properties. The Action Properties window opens. (vii) Select Redirect http connections to an authentication (captive) portal. Note: redirection will not occur if the source IP is already mapped to a user. (viii) Click OK. Name Guests Source Guests Destination VPN Service Action http accept (display captive portal)
ExternalZone Any Traffic
User Experience
From the perspective of a guest at ACME, she does these steps: 1. Browses to an internet site from her laptop. The Captive Portal opens because she is not identified and therefore cannot access the Internet. 2. She enters her identifying data in the Captive Portal and reads through and accepts a network access agreement. A Welcome to the network window opens. 3. She can successfully browse to the Internet for a specified period of time.
Acquiring Identities with Endpoint Identity Agents

Scenario: Endpoint Identity Agent Deployment and User Group Access
The ACME organization wants to make sure that only the Finance department can access the Finance Web server. The current Rule Base uses static IP addresses to define access for the Finance department. Amy, the IT administrator wants to leverage the use of Endpoint Identity Agents so: Finance users will automatically be authenticated one time with SSO when logging in (using Kerberos which is built-in into Microsoft Active Directory). Users that roam the organization will have continuous access to the Finance Web server. Access to the Finance Web server will be more secure by preventing IP spoofing attempts.
Amy wants Finance users to download the Endpoint Identity Agent from the Captive Portal. She needs to configure: Identity Agents as an identity source for Identity Awareness. Agent deployment for the Finance department group from the Captive Portal. She needs to deploy the Full Identity Agent so she can set the IP spoofing protection. No configuration is necessary on the client for IP spoofing protection. A rule in the Rule Base with an access role for Finance users, from all managed machines and from all locations with IP spoofing protection enabled.
After configuration and policy install, users that browse to the Finance Web server will get the Captive Portal and can download the Endpoint Identity Agent.

To make this scenario work, the IT administrator must: 1. Enable Identity Awareness on a gateway and select Identity Agents and Browser-Based Authentication as Identity Sources. 2. Click the Browser-Based Authentication Settings button. 3. In the Portal Settings window in the Users Access section, select Name and password login. 4. In the Identity Agent Deployment from the Portal, select Require users to download and select Identity Agent - Full option. Note - This configures Endpoint Identity Agent for all users. Alternatively, you can set Identity Agent download for a specific group ("Configuring Agent Deployment for User Groups" on page 37). 5. Configure Kerberos SSO ("Kerberos SSO Configuration" on page 77). 6. Create a rule in the Firewall Rule Base that lets only Finance department users access the Finance Web server and install policy: a) From the Source of the rule, right-click to create an Access Role. b) Enter a Name for the Access Role. c) In the Networks tab, select Specific users and add the Active Directory Finance user group. d) In the Users tab, select All identified users. e) In the Machines tab, select All identified machines and select Enforce IP spoofing protection (requires Full Identity Agent). f) Click OK.
g) The Access Role is added to the rule. Name Finance Web Server 7. Install policy.
Source Finance_dept
Destination Finance_web_server
VPN Any Traffic
Service http https
Action accept
User Experience
A Finance department user does this: 1. Browses to the Finance Web server. The Captive Portal opens because the user is not identified and cannot access the server. A link to download the Endpoint Identity Agent is shown.
2. The user clicks the link to download the Endpoint Identity Agent. The user automatically connects to the gateway. A window opens asking the user to trust the server. Note - The trust window opens because the user connects to the Security Gateway with Identity Awareness using the File name based server discovery option. See Server Discovery and Trust (on page 38) for more details on other server discovery methods that do not require user trust confirmation. 3. Click OK. The user automatically connects to the Finance Web server. The user can successfully browse to the internet for a specified period of time.
What's Next
Other options that can be configured for Endpoint Identity Agents: A method that determines how Endpoint Identity Agents connect to a Security Gateway enabled with Identity Awareness and trusts it. See Server Discovery and Trust (on page 38)for more details. In this scenario, the File Name server discovery method is used. Access roles ("Creating Access Roles" on page 26) to leverage machine awareness. End user interface protection so users cannot access the client settings. Let users defer client installation for a set time and ask for user agreement confirmation. See User Access (on page 33).

The SmartView Tracker log below shows how the system recognizes a guest.
This log entry shows that the system maps the source IP address with the user's identity. In this case, the identity is "guest" because that is how the user is identified in the Captive Portal.
Acquiring Identities in a Terminal Server Environment

Scenario: Identifying Users Accessing the Internet through Terminal Servers
The ACME organization defined a new policy that only allows users to access the internet through Terminal Servers. The ACME organization wants to make sure that only the Sales department will be able to access Facebook. The current Rule Base uses static IP addresses to define access for Facebook, but now all connections are initiated from the Terminal Servers' IP addresses. Amy, the IT administrator wants to leverage the use of the Terminal Servers solution so that: Sales users will automatically be authenticated with Identity Awareness when logging in to the Terminal Servers. All connections to the internet will be identified and logged. Access to Facebook will be restricted to the Sales department's users.
To enable the Terminal Servers solution, Amy must: Configure Terminal Server/Citrix Identity Agents as an identity source for Identity Awareness. Install a Terminal Servers Identity Agent on each of the Terminal Servers. Configure a shared secret between the Terminal Servers Identity Agents and the Identity Server. After configuration and installation of the policy, users that log in to Terminal Servers and browse to the internet will be identified and only Sales department users will be able to access Facebook.
Acquiring Identities in Application Control

Identity Awareness and Application and URL Filtering can be used together to add user awareness, machine awareness, and application awareness to the Check Point gateway. They work together in these procedures: Use Identity Awareness Access Roles in Application and URL Filtering rules as the source of the rule. You can use all the types of identity sources to acquire identities of users who try to access applications. In SmartView Tracker logs and SmartEvent events, you can see which user and IP address accesses which applications.
Scenario: Identifying Users in Application Control Logs

The ACME organization wants to use Identity Awareness to monitor outbound application traffic and learn what their employees are doing. To do this, the IT administrator must enable Application Control and Identity Awareness. The SmartView Tracker and SmartEvent logs will then show identity information for the traffic. Next, the IT department can add rules to block specific applications or track them differently in the Application Control policy to make it even more effective. See the R75.40VS Application Control and URL Filtering Administration Guide (http://supportcontent.checkpoint.com/solutions?id=sk76540).

To make this scenario work, the IT administrator does these steps: 1. Enables the Application Control blade on a gateway. This adds a default rule to the Application Control Rule Base that allows traffic from known applications, with the tracking set to Log. Source Any Destination Internet Application/Sites Any Recognized Action Allow Track Log
2. Enables Identity Awareness on a gateway, selects AD Query as one of the Identity Sources. 3. Installs the policy.
User identification in the Logs

Logs related to application traffic in SmartView Tracker and SmartEvent show data for identified users. The SmartView Tracker log entry shows that the system maps the source IP address with the user's identity. It also shows Application Control data. The SmartEvent Intro log entry shows details of an Application Control event with Identity Awareness user and machine identity.
Chapter 2
Configuring Identity Awareness
In This Chapter Enabling Identity Awareness on the Security Gateway Creating Access Roles Using Identity Awareness in the Firewall Rule Base Using Identity Awareness in the Application and URL Filtering Rule Base Configuring Browser-Based Authentication in SmartDashboard Configuring Endpoint Identity Agents Configuring Terminal Servers Configuring Remote Access Configuring Identity Logging for a Log Server 24 26 28 29 31 34 40 43 43
Enabling Identity Awareness on the Security Gateway

When you enable Identity Awareness on a Security Gateway, a wizard opens. You can use the wizard to configure one Security Gateway that uses the AD Query, Browser-Based Authentication, and Terminal Servers for acquiring identities. You cannot use the wizard to configure a multiple gateway environment or to configure Identity Agent and Remote Access acquisition (other methods for acquiring identities). When you complete the wizard and install a policy, the system is ready to monitor Identity Awareness. You can use SmartView Tracker and SmartEvent to see the logs for user and machine identity.
To enable Identity Awareness:

1. 2. 3. 4. Log in to SmartDashboard. From the Network Objects tree, expand the Check Point branch. Double-click the gateway on which to enable Identity Awareness. In the Software Blades section, select Identity Awareness on the Network Security tab.
The Identity Awareness Configuration wizard opens.
5. Select one or more options. These options set the methods for acquiring identities of managed and unmanaged assets. AD Query - Lets the Security Gateway seamlessly identify Active Directory users and computers. Browser-Based Authentication - Sends users to a Web page to acquire identities from unidentified users. If Transparent Kerberos Authentication is configured, AD users may be identified transparently.
Terminal Servers - Identify users in a Terminal Server environment (originating from one IP address). See Choosing Identity Sources (on page 45). Note - When you enable Browser-Based Authentication on a Security Gateway that is on an IP Series appliance, make sure to set the Voyager management application port to a port other than 443 or 80. 6. Click Next. The Integration With Active Directory window opens. When SmartDashboard is part of the domain, SmartDashboard suggests this domain automatically. If you select this domain, the system creates an LDAP Account Unit with all of the domain controllers in the organization's Active Directory. Note - We highly recommend that you go to the LDAP Account Unit and make sure that only necessary domain controllers are in the list. If AD Query is not required to operate with some of the domain controllers, delete them from the LDAP Servers list. With the Identity Awareness configuration wizard you can use existing LDAP Account units or create a new one for one AD domain. If you create a new domain, the LDAP account unit that the system creates contains only the domain controller you set manually. If it is necessary for AD Query to fetch data from other domain controllers, you must add them at a later time manually to the LDAP Servers list after you complete the wizard. To view/edit the LDAP Account Unit object, select Servers and OPSEC in the objects tree > LDAP Account Unit. The LDAP Account Unit name syntax is: <domain name>_ _ AD For example, CORP.ACME.COM_ _ AD. 7. From the Select an Active Directory list, select the Active Directory to configure from the list that shows configured LDAP account units or create a new domain. If you have not set up Active Directory, you need to enter a domain name, username, password and domain controller credentials.
8. Enter the Active Directory credentials and click Connect to verify the credentials. Important - For AD Query you must enter domain administrator credentials. For Browser-Based Authentication standard credentials are sufficient. 9. If you selected to use Browser-Based Authentication or Terminal Servers and do not wish to configure Active Directory, select I do not wish to configure Active Directory at this time and click Next. 10. Click Next. If you selected Browser-Based Authentication on the first page, the Browser-Based Authentication Settings page opens. 11. In the Browser-Based Authentication Settings page, select a URL for the portal, where unidentified users will be directed. All IP addresses configured for the gateway show in the list. The IP address selected by default is the <gateway's main IP address>/connect. The same IP address can be used for other portals with different paths. For example: 12. 13. Identity Awareness Browser-Based Authentication - 143.100.75.1/connect DLP Portal - 2.2.2.2/DLP
14. 15.
Mobile Access Portal - 2.2.2.2/sslvpn By default, access to the portal is only through internal interfaces. To change this, click Edit. We do not recommend that you let the portal be accessed through external interfaces on a perimeter gateway. Click Next. The Identity Awareness is Now Active page opens with a summary of the acquisition methods. If you selected Terminal Servers, the page includes a link to download the agent. See Terminal Servers Configuration. ("Configuring Terminal Servers" on page 40) Click Finish. Select Policy > Install from the SmartDashboard menu.
Results of the Wizard

These are the results of the wizard: Depending on the acquisition methods you set, Active Directory and / or Browser-Based Authentication become active. When you set an Active Directory domain, the system creates an LDAP Account Unit object for the Active Directory domain.
To view/edit the LDAP Account Unit object, select Servers and OPSEC in the objects tree > LDAP Account Unit. The LDAP Account Unit name syntax is: <domain name>_ _ AD For example, CORP.ACME.COM_ _ AD. If you configured Terminal Servers, you need additional configuration. See Terminal Servers Configuration. ("Configuring Terminal Servers" on page 40)
Creating Access Roles

After you activate Identity Awareness, you can create access role objects. Access role objects define users, machines and network locations as one object. The access role can be specified for a certain user, network and machine or be general for a certain user from any network or any machine. You can select specific users, user groups or user branches. To enforce Identity Awareness, use these access role objects in the Rule Base.
To create an access role:

1. Select Users and Administrators in the Objects Tree. 2. Right-click Access Roles > New Access Role.
The Access Role window opens.
3. Enter a Name and Comment (optional) for the access role. 4. Select a Color for the object (optional). 5. In the Networks tab, select one of these: Any network Specific networks - click the plus sign and select a network. Your selection is shown under the Networks node in the Role Preview pane. 6. In the Users tab, select one of these: Any user All identified users - includes any user identified by a supported authentication method (internal users, Active Directory users or LDAP users). Specific users - click the plus sign. A window opens. You can search for Active Directory entries or select them from the list. Your selections are shown in the Users node in the Role Preview pane. 7. In the Machines tab, select one of these: Any machine All identified machines - includes machines identified by a supported authentication method (Active Directory). Specific machines - click the plus sign. A window opens. You can search for Active Directory entries or select them from the list. Your selections are shown in the Machines node in the Role Preview pane. 8. In the Machines tab, select Enforce IP spoofing protection (requires full identity agent) if you want to enable the packet tagging feature. 9. Click OK. The access role is added to the Users and Administrators tree.
Using Identity Awareness in the Firewall Rule Base

The Security Gateway examines packets and applies rules in a sequential manner. When a Security Gateway receives a packet from a connection, it examines the packet against the first rule in the Rule Base. If there is no match, it then goes on to the second rule and continues until it matches a rule. In rules with access roles, you can add a property in the Action field to redirect traffic to the Captive Portal. If this property is added, when the source identity is unknown and traffic is HTTP, the user is redirected to the Captive Portal. If the source identity is known, the Action in the rule (Allow or Block) is enforced immediately and the user is not sent to the Captive Portal. After the system gets the credentials from the Captive Portal, it can examine the rule for the next connection. Important - When you set the option to redirect http traffic from unidentified IP addresses to the Captive Portal, make sure to place the rule in the correct position in the Rule Base to avoid unwanted behavior. In rules with access role objects, criteria matching operates like this: When identity data for an IP is known: If it matches an access role, the rule is applied and the traffic is accepted/dropped based on the action. If it does not match an access role, it goes on to examine the next rule. All the rules fields match besides the source field with an access role. The connection is http. The action is set to redirect to the Captive Portal. If all the conditions apply, the traffic is redirected to the Captive Portal to get credentials and see if there is a match. If not all conditions apply, there is no match and the next rule is examined. Note - You can only redirect http traffic to the Captive Portal.
When identity data for an IP is unknown and:
To redirect http traffic to the Captive Portal:

1. In a rule that uses an access role in the Source column, right-click the Action column and select Edit Properties. The Action Properties window opens. 2. Select the Redirect http connections to an authentication (captive) portal. Note: redirection will not occur if the source IP is already mapped to a user checkbox. 3. Click OK. The Action column shows that a redirect to the Captive Portal occurs. Below is an example of a Firewall Rule Base that describes how matching operates: No. 1 Source Finance_Dept (Access Role) Admin_IP Any Destination Service Action Accept (display Captive Portal) Accept Drop
Finance_Web_ Any Server Any Any Any Any
2 3
Example 1 - If an unidentified Finance Dept user tries to access the Finance Web Server with http, a redirect to the Captive Portal occurs. After the user enters credentials, the gateway allows access to the Finance Web Server. Access is allowed based on rule number 1, which identifies the user through the Captive Portal as belonging to the Finance Dept access role.
Example 2 - If an unidentified administrator tries to access the Finance Web Server with http, a redirect to the Captive Portal occurs despite rule number 2. After the administrator is identified, rule number 2 matches. To let the administrator access the Finance Web Server without redirection to the Captive Portal, switch the order of rules 1 and 2 or add a network restriction to the access role.
Access Role Objects

Access Role objects can be used as a source and/or destination parameter in a rule. For example, a rule that allows file sharing between the IT department and the Sales department access roles. Name IT and Sales File Sharing Source IT_dept Destination Sales_dept VPN Any Traffic Service Action ftp accept
Negate and Drop

When you negate a source or destination parameter, it means that a given rule applies to all sources/destinations of the request except for the specified source/destination object. When the object is an access role, this includes all unidentified entities as well. When you negate an access role, it means that the rule is applied to "all except for" the access role and unidentified entities. For example, let's say that the below rule is positioned above the Any, Any, Drop rule. The rule means that everyone (including unidentified users) can access the Intranet Web Server except for temporary employees. If a temporary employee is not identified when she accesses the system, she will have access to the Intranet Web Server. Right-click the cell with the access role and select Negate Cell. The icon that represents the access role object is shown crossed out. Source X Temp_employees Destination VPN Service Action accept
Intranet_web_server Any http Traffic
To prevent access to unidentified users, add another rule that ensures that only identified employees will be allowed access and that attempts by a temporary employee will be dropped. Source Temp_employees Destination VPN Service http Action drop
Intranet_web_server Any Traffic Intranet_web_server Any Traffic
Any_identified_employee
http
accept
Using Identity Awareness in the Application and URL Filtering Rule Base
The Security Gateway inspects Application and URL Filtering requests and applies rules in a sequential manner. When a Security Gateway receives a packet from a connection, it examines the packet against the first rule in the Rule Base. If there is no match, it goes on to the second rule and continues until it completes the Rule Base. If no rule matches, the packet is allowed. In rules with access roles, you can add a property in the Action field to redirect traffic to the Captive Portal. If this property is added, when the source identity is unknown and traffic is HTTP, the user is redirected to the Captive Portal. If the source identity is known, the Action in the rule (Allow or Block) is enforced immediately and the user is not sent to the Captive Portal. After the system gets the credentials from the Captive Portal, it can examine the rule for the next connection.
In rules with access role objects, criteria matching operates like this: When identity data for an IP is known: If it matches an access role, the rule is applied and the traffic is allowed/blocked based on the action. If it does not match an access role, it goes on to examine the next rule. All the rules fields match besides the source field with an access role. The connection protocol is HTTP. The action is set to redirect to the Captive Portal. If all the conditions apply, the traffic is redirected to the Captive Portal to get credentials and see if there is a match. If not all conditions apply, there is no match and the next rule is examined. When the criteria does not match any of the rules in the Rule Base: The traffic is allowed.
When identity data for an IP is unknown and:
To redirect HTTP traffic to the Captive Portal:

1. In a rule that uses an access role in the Source column, right-click the Action column and select Edit Properties. The Action Properties window opens. 2. Select Redirect HTTP connections. 3. Click OK. The Action column shows that a redirect to the Captive Portal occurs. Below is an example of an Application and URL Filtering Rule Base that shows how criteria matching operates: No. 1 Source Finance_Dept (Access Role) Destination Service Applications/Sites Internet Any Salesforce Action Allow (display Captive Portal) Allow
Any_identified_user Internet (Access Role)
Any
Remote Administration Tool (non-HTTP category) Any recognized
Any_identified_user Internet (Access Role)
Any
Block
When browsing the Internet, different users experience different outcomes: Example 1 - An unidentified Finance user that attempts to access Salesforce is sent to the Captive Portal. This happens because the action is set to redirect to the Captive Portal. After entering credentials and being identified, the user is granted access according to rule number 1. Example 2 - An unidentified user that attempts to access the Remote Administration Tool matches rule 2, but not the Source column. Because the application is not HTTP, traffic cannot be redirected to the Captive Portal. Since none of the rules match, the user is granted access to the Remote Administration Tool. Example 3 - An unidentified user that browses to Gmail does not match rules 1 and 2 because of the application. In rule 3 there is also no match because the action is not set to redirect to the Captive Portal. Since none of the rules match, the user is granted access to Gmail.
Source and Destination Fields

These issues are related to Source and Destination fields: You can use access role objects in the Source column or the Destination column of a rule. This means you cannot have a rule that uses an access role in both the Source column and the Destination column. Furthermore, you cannot use access roles in both the Source and Destination columns in the same Rule Base. In the Source and Destination columns, you can use a network object together with an access role object. But the condition between them is "or" and not "and".
Negate and Block

Negate and block in the Application Control Rule Base operates similarly to Negate and drop (on page 29) in the Firewall Rule Base. Unlike the Firewall Rule Base, if a connection does not match any of the rules, it is not automatically blocked. It is allowed. Thus, when you use negate on an access role you allow all unidentified users and anyone who is not the access role access. To prevent this you must include an access role that prevents access to unidentified users. This rule makes sure that only identified users will be allowed access and attempts by unidentified users will be blocked. This example shows rules that block temporary employees from accessing the Internet and allows access for identified employees. Source Temp_employees Any_identified_employee Destination Internet Internet Application Any Recognized Any Recognized Action Block Allow
Configuring Browser-Based Authentication in SmartDashboard

In the Identity Sources section of the Identity Awareness page, select Browser-Based Authentication to send unidentified users to the Captive Portal. If you configure Transparent Kerberos Authentication, the browser tries to identify AD users before sending them to the Captive Portal. See Transparent Kerberos Authentication Configuration (on page 60). If you already configured the portal in the Identity Awareness Wizard or SmartDashboard, its URL shows below Browser-Based Authentication.
To configure the Browser-Based Authentication settings:

1. Select Browser-Based Authentication and click Settings. 2. From the Portal Settings window, configure: Portal Network Location Access Settings Authentication Settings Customize Appearance Users Access Identity Agent Deployment from the Portal Note - When you enable Browser-Based Authentication on a Security Gateway that is on an IP Series appliance, make sure to set the Voyager management application port to a port other than 443 or 80.
Portal Network Location

Select if the portal runs on this gateway or a different Identity Awareness enabled gateway. The default is that the Captive Portal is on the gateway. The gateway thus redirects unidentified users to the portal on the same gateway. This is the basic configuration. A more advanced deployment is possible where the portal runs on a different gateway. See the Deployment section for more details.
Access Settings
Click Edit to open the Portal Access Settings window. In this window you can configure: Main URL - The primary URL that users are redirected to for the Captive Portal. You might have already configured this in the Identity Awareness Wizard. Aliases - Click the Aliases button to Add URL aliases that are redirected to the main portal URL. For example, ID.yourcompany.com can send users to the Captive Portal. To make the alias work, it must be resolved to the main URL on your DNS server. Certificate - Click Import to import a certificate for the portal website to use. If you do not import a certificate, the portal uses a Check Point auto-generated certificate. This might cause browser warnings if the browser does not recognize Check Point as a trusted Certificate Authority. See Server Certificates (on page 57) for more details. Accessibility - Click Edit to select from where the portal can be accessed. You might have already configured this in the Identity Awareness Wizard. The options are based on the topology configured for the gateway. Users are sent to the Captive Portal if they use networks connected to these interfaces. Through all interfaces Through internal interfaces Including undefined internal interfaces Including DMZ internal interfaces Including VPN encrypted interfaces According to the Firewall policy - Select this if there is a rule that states who can access the portal.
Authentication Settings
Click Settings to open the Authentication Settings window. In this window you can configure: Browser transparent Single Sign-On - Select Automatically authenticate users from machines in the domain if Transparent Kerberos Authentication is used to identify users before sending them to the Captive Portal. Main URL: The URL used to begin the SSO process. If transparent authentication fails, users are redirected to the configured Captive Portal.
IP Address: The IP address to which the Portal URL is resolved if DNS resolution fails. Note - this option is shown only when you select Browser-based Authentication as an identity source. Authentication Method - Select one method that known users must use to authenticate. Defined on user record (Legacy Authentication) - Takes the authentication method from Gateway Object Properties > Other > Legacy Authentication. User name and password - This can be configured internally or on an LDAP server. RADIUS - A configured RADIUS server. Select the server from the list.
User Directories - Select one or more places where the gateway searches to find users when they try to authenticate. Internal users - The directory of internal users.
LDAP users - The directory of LDAP users. Either: Any - Users from all LDAP servers. Specific - Users from an LDAP server that you select. External user profiles - The directory of users who have external user profiles.
The default is that all user directory options are selected. You might choose only one or two options if users are only from a specified directory or directories and you want to maximize gateway performance when users authenticate. Users with identical user names must log in with domain\user.
Customize Appearance
Click Edit to open the Portal Customization window and edit the images that users see in the Captive Portal. Configure the labeled elements of the image below.
Label Number 1
Name Portal Title
To do in GUI Enter the title of the portal. The default title is Network Access Login. Select Use my company logo and Browse to select a logo image for the portal. Select Use my company logo for mobiles and Browse to select a smaller logo image for users who access the portal from mobile devices.
Company Logo
Company Logo for mobiles
User Access
Configure what users can do in the Captive Portal to become identified and access the network. Name and password login- Users are prompted to enter an existing username and password. This will only let known users authenticate. Unregistered guests login - Let guests who are not known by the gateway access the network after they enter required data.
Name and Password Login Settings

Click Settings to configure settings for known users after they enter their usernames and passwords successfully. Access will be granted for xxx minutes - For how long can they access network resources before they have to authenticate again.
Ask for user agreement - You can require that users sign a user agreement. Click Edit to upload an agreement. This option is not selected by default because a user agreement is not usually necessary for known users. Adjust portal settings for specific user groups - You can add user groups and give them settings that are different from other users. Settings specified for a user group here override settings configured elsewhere in the Portal Settings. The options that you configure per user group are: If they must accept a user agreement. If they must download an Identity Agent and which one.
If they can defer the Identity Agent installation and until when. You can only configure settings for Endpoint Identity Agent deployment if Identity Agents is selected on the Identity Awareness page.
Unregistered Guest Login Settings

Click Settings to configure settings for guests. Access will be granted for xxx minutes - For how long can they access network resources before they have to authenticate again. Ask for user agreement - Makes users sign a user agreement. Click Edit to choose an agreement and the End-user Agreement Settings page opens. Select an agreement to use: Default agreement with this company name - Select this to use the standard agreement. See the text in the Agreement preview. Replace Company Name with the name of your company. This name is used in the agreement. Customized agreement - Paste the text of a customized agreement into the text box. You can use HTML code.
Login Fields - Edit the table shown until it contains the fields that users complete in that sequence. Select Is Mandatory for each field that guests must complete before they can get access to the network. To add a new field, enter it in the empty field and then click Add. Use the green arrows to change the sequence of the fields. The first field will show the user name in the SmartView Tracker logs.
Agent Deployment from the Portal

If Identity Agents is selected as a method to acquire identities, you can configure that users must download the Identity Agent from the Captive Portal. You can also let users choose not to install the Identity Agent immediately and instead wait until a specified later date. Require users to download - Select this to make users install the Endpoint Identity Agent. Select which Endpoint Identity Agent they must install. If this option is selected and the defer option is not selected, users will only be able to access the network if they install the identity agent. Users may defer installation until - Select this if you want to give users flexibility to choose when they install the Endpoint Identity Agent. Select the date by which they must install it. Until that date a Skip Identity Agent installation option shows in the Captive Portal.
Configuring Endpoint Identity Agents

Endpoint Identity Agents are dedicated client agents installed on users' computers that acquire and report identities to the Security Gateway. All necessary configuration is done by administrators and does not require user input. Before you configure Endpoint Identity Agents, you must think about these elements: Identity Agent type - Full Identity Agent, Light Identity Agent or Custom Identity Agent. For the Full Identity Agent you can enforce IP spoofing protection. For the Full Identity Agent you can also leverage machine authentication if you define machines in access roles. The Custom Identity Agent is a customized installation package. Installation deployment methods- You can deploy the Identity Agent for installation through the Captive Portal or use other means you use to deploy software in your organization.
Server discovery and trust - Before the Identity Agent can connect to a Security Gateway with Identity Awareness, the Identity Agent must discover and trust the server that it connects to. You can configure one of five methods. Automatic authentication using Single Sign-On (SSO) - Identity Agents installed on endpoint computers authenticate users automatically when they log in to the domain using SSO. The Identity Agent identity source uses SSO to authenticate users when they enter their login credentials (Active Directory or other authentication server). The system securely gets authentication data one time without making users authenticate manually (as is necessary with Captive Portal). You get SSO with Kerberos, an inherent authentication and authorization protocol in Windows networks that is available by default on all Windows servers and workstations. If you do not use SSO, users enter credentials in another window. To set up Kerberos, see Kerberos SSO Configuration (on page 77).
Endpoint Identity Agent Types

These are the Endpoint Identity Agent types that you can install: Identity Agent - Full Identity Agent - Light - For Windows and Mac clients. For supported version information, see the R75.40VS Release Notes (http://supportcontent.checkpoint.com/solutions?id=sk76540). Identity Agent - Custom - a customized installation package. For more information, see Prepackaging Identity Agents (on page 91).
Installation permissions - To install the Full Identity Agent the computer must have administrator permissions. It is not necessary to have administrator permissions to install the Light Identity Agent. User identification - Users that log in to the Active Directory domain are transparently authenticated (with SSO) and identified when using an Endpoint Identity Agent. If you do not configure SSO or you disable it, the Endpoint Identity Agent uses username and password authentication with a standard LDAP server. The system opens a window for entering credentials. Machine identification - You get machine identification when you use the Full Agent as it requires installing a service. IP change detection - When an endpoint IP address changes (interface roaming or DHCP assigns a new address), the Endpoint Identity Agent automatically detects the change. The Endpoint Identity Agent tells the Security Gateway and you stay connected. Packet tagging - A technology that prevents IP spoofing is available only for the Full Agent as it requires installing a driver.
This table shows the similarities and differences of the Light and Full Identity Agent types. Identity Agent Light Identity Agent Full Installation Elements Agent format Resident application Resident application + service + driver Administrator
Installation permissions Upgrade permissions Security Features User identification Machine identification IP change detection Packet tagging
None
None
None
SSO No
SSO Yes
Yes
Yes
No
Yes
The installation file size is 7MB for both types and the installation takes less than a minute.
Packet Tagging for Anti-Spoofing

IP Spoofing happens when an unauthorized user assigns an IP address of an authenticated user to an endpoint computer. By doing so, the user bypasses identity access enforcement rules. It is also possible to poison ARP tables that let users do ARP "man-in-the-middle attacks" that keep a continuous spoofed connectivity status. To protect packets from IP spoofing attempts, you can enable Packet Tagging. Packet Tagging is a patent pending technology that prevents spoofed connections from passing through the gateway. This is done by a joint effort between the Endpoint Identity Agent and the Security Gateway that uses a unique technology that sign packets with a shared key. The Identity Awareness view in SmartView Tracker shows Packet Tagging logs. The Success status indicates that a successful key exchange happened.
Note - Packet Tagging can only be set on computers installed with the Full Identity Agent. For details, see Packet Tagging.
To enable IP Spoofing protection:

1. 2. 3. 4. Make sure users have the Full Identity Agent installed. Create an Access Role ("Creating Access Roles" on page 26). In the Machines tab, select Enforce IP spoofing protection (requires full identity agent) . Click OK.
Endpoint Identity Agent Deployment Methods

There are 2 Endpoint Identity Agent deployment methods: Using Captive Portal - you can configure that users must download the Identity Agent from the Captive Portal. You can also let users choose not to install the Identity Agent immediately and instead wait until a specified later date. During installation, the Endpoint Identity Agent automatically knows if there are administrator permissions on the computer or not and installs itself accordingly. Note - When you deploy the Full Endpoint Identity Agent it is necessary for the user that installs the client to have administrator rights on the computer. If the user does not have administrator permissions, the Light Endpoint Identity Agent is installed instead. Using distribution software - you can deploy the Endpoint Identity Agent with distribution software. The msi installation files (Light and Full) can be found in the \linux\windows directory on the supplied DVD.
You can find a customizable msi version of the Endpoint Identity Agent (for distribution via a software distribution tool or Captive Portal) in these places: Installed Security Gateway - in /opt/CPNacPortal/htdocs/nac/nacclients/customAgent.msi SecurePlatform installation CD - in /linux/windows/Check_Point_Custom_Nac_Client.msi
For more information, see Prepackaging Identity Agents (on page 91).
Configuring Agent Deployment from Captive Portal

To configure Endpoint Identity Agent deployment from Captive Portal:
1. From the Identity Awareness page, select the Identity Agents checkbox. 2. Select Browser-Based Authentication and click Settings. 3. From the Portal Settings window, select the Require users to download checkbox to make users install the Endpoint Identity Agent. Select which Endpoint Identity Agent they must install. If you select this option and you do not select the defer option, users will can only access the network if they install the Endpoint Identity Agent. 4. To give users flexibility to choose when they install the Endpoint Identity Agent, select Users may defer installation until. Select the date by which they must install it. Until that date a Skip Endpoint Identity Agent installation option shows in the Captive Portal. 5. Click OK.
Configuring Agent Deployment for User Groups

When necessary, you can configure specific groups to download the Endpoint Identity Agent. For example, if you have a group of mobile users that roam and it is necessary for them to stay connected as they move between networks.
To configure Endpoint Identity Agent deployment for user groups:

1. From the Identity Awareness page, select the Identity Agent checkbox. 2. Select Browser-Based Authentication and click Settings. 3. Select Name and password login and click Settings.
4. Select Adjust portal settings for specific user groups - You can add user groups and give them settings that are different from other users. Settings specified for a user group here override settings configured elsewhere in the Portal Settings. The options that you configure for each user group are: If they must accept a user agreement. If they must download the Endpoint Identity Agent and which one.
If they can defer the Endpoint Identity Agent installation and until when. 5. Click OK.
Server Discovery and Trust

Server Discovery refers to the procedure the Endpoint Identity Agent uses to find which Security Gateway with Identity Awareness to connect to. There are several methods you can use to configure this. The most basic method is to configure one server. Another method is to deploy a domain wide policy of connecting to a Security Gateway with Identity Awareness based on the Endpoint Identity Agent client's current location. Server Trust refers to the procedure that: Makes sure that the Endpoint Identity Agent connects to a genuine Security Gateway with Identity Awareness. Makes sure that the communication between the Endpoint Identity Agent and the Security Gateway with Identity Awareness is not being tampered with. For example, an attempt to launch a Man-in-the-middle attack.
Trust is verified by comparing the server fingerprint calculated during the SSL handshake with the expected fingerprint. There are 5 server discovery and trust methods: File name based server configuration - If no other method is configured (out of the box situation), any Endpoint Identity Agent downloaded from the Captive Portal is renamed to include the Captive Portal machine IP address in it. During installation, the Endpoint Identity Agent uses this IP for the Security Gateway with Identity Awareness. When you use this method, users will have to manually trust the server (a trust window opens). AD based configuration If the Endpoint Identity Agent computers are members of an Active Directory domain, you can deploy the server addresses and trust data using a dedicated "Distributed Configuration" tool.
DNS SRV record based server discovery You can configure the Security Gateway with Identity Awareness addresses in the DNS server. Because DNS is not secure, users will have to manually trust the server (a trust window opens). Note - This is the only server discovery method that is applicable for the MAC OS Endpoint Identity Agent.
Remote registry All client configuration resides in the registry. This includes the Identity Server addresses and trust data. You can deploy these values before installing the client (by GPO, or any other method that lets you control the registry remotely). The Endpoint Identity Agent can then use them immediately. PrePackaging You can create a prepackaged version of the client installation that comes with the Security Gateway with Identity Awareness IP and trust data.
For more details, see Server Discovery and Server Trust ("Server Discovery and Trust" on page 83).
Configuring Endpoint Identity Agents in SmartDashboard

In the Identity Sources section of the Identity Awareness page, select Identity Agents to configure Endpoint Identity Agent settings.
To configure the Identity Agent settings:

1. Select Identity Agents and click Settings. 2. From the Identity Agents Settings window, configure: Agent Access Authentication Settings Session details Agent Upgrades
Agent Access
Click Edit to select from where the Endpoint Identity Agent can be accessed. The options are based on the topology configured for the gateway. Users can communicate with the servers if they use networks connected to these interfaces. Through all interfaces Through internal interfaces Including undefined internal interfaces Including DMZ internal interfaces Including VPN encrypted interfaces
According to the Firewall policy - the Endpoint Identity Agent is accessible through interfaces associated with source networks that appear in access rules used in the Firewall policy.
Authentication Settings
Click Settings to open the Authentication Settings window. In this window you can configure: Browser transparent Single Sign-On - Select Automatically authenticate users from machines in the domain if Transparent Kerberos Authentication is used to identify users before sending them to the Captive Portal. Main URL: The URL used to begin the SSO process. If transparent authentication fails, users are redirected to the configured Captive Portal.
IP Address: The IP address to which the Portal URL is resolved if DNS resolution fails. Note - this option is shown only when you select Browser-based Authentication as an identity source.
Authentication Method - Select one method that known users must use to authenticate. Defined on user record (Legacy Authentication) - Takes the authentication method from Gateway Object Properties > Other > Legacy Authentication. User name and password - This can be configured internally or on an LDAP server. RADIUS - A configured RADIUS server. Select the server from the list.
User Directories - Select one or more places where the gateway searches to find users when they try to authenticate. Internal users - The directory of internal users. LDAP users - The directory of LDAP users. Either: Any - Users from all LDAP servers. Specific - Users from an LDAP server that you select. External user profiles - The directory of users who have external user profiles.
The default is that all user directory options are selected. You might choose only one or two options if users are only from a specified directory or directories and you want to maximize gateway performance when users authenticate. Users with identical user names must log in with domain\user.
Session
Configure data for the logged in session using the Endpoint Identity Agent. Agents send keepalive every X minutes - The interval at which the Endpoint Identity Agent sends a keepalive signal to the Security Gateway. The keepalive is used as the server assumes the user logged out if it is not sent. Lower values affect bandwidth and network performance. Users should reauthenticate every XXX minutes - For how long can users access network resources before they have to authenticate again. When using SSO, this is irrelevant. Allow user to save password - When SSO is not enabled, you can let users save the passwords they enter in the Identity Agent login window.
Agent Upgrades
Configure data for Endpoint Identity Agent upgrades. Check agent upgrades for - You can select all users or select specific user groups that should be checked for agent upgrades. Upgrade only non-compatible versions - the system will only upgrade versions that are no longer compatible. Keep agent settings after upgrade - settings made by users before the upgrade are saved. Upgrade agents silently (without user intervention) - the Endpoint Identity Agent is automatically updated in the background without asking the user for upgrade confirmation. Note - When installing or upgrading the Full Endpoint Identity Agent version, the user will momentarily experience a connectivity loss.
Configuring Terminal Servers

The Identity Awareness Terminal Servers solution lets the system enforce identity aware policies on multiple users that connect from one IP address. This functionality is necessary when an administrator must control traffic created by users of application servers that host Microsoft Terminal Servers, Citrix XenApp, and Citrix XenDesktop. The Terminal Servers solution is based on reserving a set of TCP/UDP ports for each user. Each user that is actively connected to the application server that hosts the Terminal/Citrix services is dynamically assigned a set of port ranges. The Identity Server receives that information. Then, when a user attempts to access a resource, the packet is examined and the port information is mapped to the user. For more information, see sk66761 (http://supportcontent.checkpoint.com/solutions?id=sk66761).
Deploying the Terminal Servers Identity Awareness Solution

To deploy Terminal Servers you must do two steps: Install a Terminal Servers Identity Agent - You install this agent on the application server that hosts the Terminal/Citrix services after you enable the Terminal Servers identity source and install policy. Go to the link https://<gateway_IP>/_IA_MU_Agent/download/muhAgent.exe. Make sure you open the link from a location defined in the Terminal Servers Accessibility setting ( Gateway Properties > Identity Awareness > Terminal Servers > Settings > Edit). Configure a shared secret - You must configure the same password on the Terminal Servers Identity Agent and the Identity Server (the Security Gateway enabled with Identity Awareness). This password is used to secure the establish trust between them.
Installing the Terminal Servers Identity Agent

The Terminal Servers Identity Agent installation installs the Terminal Servers driver and features. A user with administrator rights must run the Terminal Servers installation. You can download the Terminal Servers Identity Agent from a link in SmartDashboard.
To download the Terminal Servers Identity Agent:

1. On the Identity Awareness page, enable the Terminal Servers identity source. 2. Install policy. 3. Go back to the same page and click the download agent link. Make sure you open the link from a location defined in the Accessibility setting (Terminal Servers > Settings > Edit). 4. Install the agent on the Terminal Server.
Configuring the Shared Secret

You must configure the same password as a shared secret in the Terminal Servers Identity Agent on the application server that hosts the Terminal/Citrix services and on the Security Gateway enabled with Identity Awareness. The shared secret enables secure communication and lets the Security Gateway trust the application server with the Terminal Servers functionality. The shared secret must contain at least 1 digit, 1 lowercase character, 1 uppercase character, no more than three consecutive digits, and must be eight characters long in length. In SmartDashboard, you can automatically generate a shared secret that matches these conditions.
To configure the shared secret on the Identity Server:

1. Log in to SmartDashboard. 2. From the Network Objects tree, right-click Check Point and select the Security Gateway enabled with Identity Awareness. The Identity Awareness page opens. 3. In the Identity Sources section, select Terminal Servers and click Settings. 4. To automatically configure the shared secret: a) Click Generate to automatically get a shared secret that matches the string conditions. The generated password is shown in the Pre-shared secret field. b) Click OK. 5. To manually configure the shared secret: a) Enter a password that matches the conditions in the Pre-shared secret field. Note the strength of the password in the Indicator. b) Click OK.
To configure the shared secret on the application server:

1. Open the Terminal Servers Identity Agent. The Check Point Endpoint Identity Agent - Terminal Servers main window opens. 2. In the Advanced section, click Terminal Servers Settings. 3. In Identity Server Shared Secret, enter the shared secret string. 4. Click Save.
Configuring Terminal Servers Accessibility

1. On the Identity Awareness page, click Terminal Servers - Settings. 2. In the Accessibility section, click Edit to select from where the Terminal Server Identity Agent can connect. The options are based on the topology configured for the gateway. Through all interfaces Through internal interfaces Including undefined internal interfaces Including DMZ internal interfaces Including VPN encrypted interfaces According to the Firewall policy - Select this if there is a rule that states who can access the portal.
Terminal Servers - Users Tab

The Users tab in the Terminal Servers Identity Agent shows a table with information about all users that are actively connected to the application server that hosts the Terminal/Citrix services. Table Field ID User Description The SID of the user. The user and domain name. The format used: <domain>\<user> The ports allocated to the user for TCP traffic. The ports allocated to the user for TCP traffic.
TCP Ports
UDP Ports
Authentication Status Indicates whether this user is authenticated on the Identity Server. The ID and User field information is automatically updated from processes running on the application server. The Terminal Servers Identity Agent assigns TCP and UDP port ranges for each connected user.
Terminal Servers Advanced Settings

From the Advanced section of the Multi User Host main window, you can access Terminal Servers Settings. Advanced uses can change these settings when necessary. We highly recommend that you keep the default values if you are not an advanced user. Changed settings only have an effect on new users that log in to the application server after the new settings have been saved. Users that are currently logged in will stay with the older settings.
Advanced Setting Excluded TCP Ports
Description Ports included in this range will not be assigned to any user for TCP traffic. This field accepts a port range or list of ranges (separated with a semicolon). Ports included in this range will not be assigned to any user for UDP traffic. This field accepts a port range or list of ranges (separated with a semicolon). The maximum number of ports that can be assigned to a user in each of the TCP and UDP port ranges. The number of seconds the system waits until it assigns a port to a new user after it has been released by another user. N/A The same password that is set on Identity Server that enables trusted communication between the Security Gateway and the application server.
Excluded UDP Ports
Maximum Ports Per User
Ports Reuse Timeout (seconds)
Errors History Size Identity Server Shared Secret
Configuring Remote Access

Identities are acquired for Mobile Access clients and IPSec VPN clients configured to work in Office Mode when they connect to the Security Gateway. This option is enabled by default.
To configure Remote Access:

Select or clear the Remote Access checkbox to enable it or disable it, respectively. Important - If there is more than one Security Gateway enabled with Identity Awareness that share identities with each other and have Office Mode configured, each gateway must be configured with different office mode ranges.
Configuring Identity Logging for a Log Server

When you configure identity logging for a Log Server, you are incorporating user and machine identification into Check Point logs. This is done by enabling Identity Awareness on the Log Server. Administrators can then analyze network traffic and security-related events better. The Log Server communicates with Active Directory servers and gets user and machine names along with the source IP address information from AD event logs. The data extracted from AD is stored in an association map on the Log Server. When Security Gateways generate a Check Point log entry and send it to the Log Server, the server gets the user and machine name from the association map entry that corresponds to the source IP address. It then adds this identity aware information to the log.
Enabling Identity Awareness on the Log Server for Identity Logging

Before you enable Identity Awareness on the Log Server for identity logging: Make sure there is network connectivity between the Log Server and the domain controller of your Active Directory environment. Get the Active Directory administrator's credentials.
To enable Identity Awareness on the Log Server for logging:

1. Log in to SmartDashboard. 2. From the Network Objects tree, right-click Check Point and select the gateway with the Log Server. 3. In the Software Blades section, select Logging & Status and Identity Awareness on the Management tab. The Identity Awareness Configuration wizard opens. 4. Click Next. The Integration With Active Directory window opens. When SmartDashboard is part of the domain, SmartDashboard suggests this domain automatically. If you select this domain, the system creates an LDAP Account Unit with all of the domain controllers in the organization's Active Directory. Note - We highly recommend that you go to the LDAP Account Unit and make sure that only necessary domain controllers are in the list. If AD Query is not required to operate with some of the domain controllers, delete them from the LDAP Servers list. With the Identity Awareness configuration wizard you can use existing LDAP Account units or create a new one for one AD domain. If you create a new domain, the LDAP account unit that the system creates contains only the domain controller you set manually. If it is necessary for AD Query to fetch data from other domain controllers, you must add them at a later time manually to the LDAP Servers list after you complete the wizard. To view/edit the LDAP Account Unit object, select Servers and OPSEC in the objects tree > LDAP Account Unit. The LDAP Account Unit name syntax is: <domain name>_ _ AD For example, CORP.ACME.COM_ _ AD. 5. From the Select an Active Directory list, select the Active Directory to configure from the list that shows configured LDAP account units or create a new domain. If you have not set up Active Directory, you need to enter a domain name, username, password and domain controller credentials. 6. Enter the Active Directory credentials and click Connect to verify the credentials. Important - For AD Query you must enter domain administrator credentials or do the steps in sk43874 (http://supportcontent.checkpoint.com/solutions?id=sk43874). 7. Click Finish.
Chapter 3
Identity Sources
In This Chapter Choosing Identity Sources Advanced AD Query Configuration Advanced Browser-Based Authentication Configuration Advanced Endpoint Identity Agents Configuration 45 46 53 65
Choosing Identity Sources

Identity sources are different in terms of security and deployment considerations. Depending on your organization's requirements, you can choose to set them separately or as combinations that supplement each other. This section presents some examples of how to choose identity sources for different organizational requirements. For logging and auditing with basic enforcement - enable Identity Awareness on the gateway and select AD Query as the identity source. For logging and auditing only - select the Add identity to logs received from non-identity aware gateways (requires Active Directory Query) option on the Identity Awareness page. For Application Control - set the AD Query and Browser-Based Authentication identity sources. The AD Query finds all AD users and machines. The Browser-Based Authentication identity source is necessary to include all non-Windows users. It also serves as a fallback option if AD Query cannot identify a user. If you configure Transparent Kerberos Authentication then the browser attempts to authenticate users transparently by getting identity information before the Captive Portal username/password page is shown to the user. For Data Center/internal server protection - these are some identity source options: AD Query and Browser-Based Authentication - When most users are desktop users (not remote users) and easy deployment is important. Note - You can add Identity Agents if you have mobile users and also have users that are not identified by AD Query. Users that are not identified encounter redirects to the Captive Portal. Identity Agents and Browser-Based Authentication - When a high level of security is necessary. The Captive Portal is used for distributing the Endpoint Identity Agent. IP spoofing protection can be set to prevent packets from being IP spoofed.
For Terminal Servers and Citrix environments - Set the Terminal Servers identity source and install the Terminal Servers Identity Agent on each Terminal Server. For users that access the organization through VPN - Set the Remote Access identity source to identify Mobile Access and IPsec VPN clients that work in Office Mode.
Identity Sources
Advanced AD Query Configuration

Configuring Identity Awareness for a Domain Forest (Subdomains)
You need to create a separate LDAP Account Unit for each domain in the forest (i.e. subdomain). You cannot add domain controllers from two different subdomains into the same account unit. You can use the Identity Awareness Configuration Wizard to define one of the subdomains. This automatically creates an LDAP Account Unit, but you then must make additional changes as listed below in the LDAP Account Unit. You must manually create all other domains you want Identity Awareness to relate to from Servers and OPSEC in the Objects Tree > Servers > New > LDAP Account Unit. When you create an LDAP Account Unit for each domain in the forest, note the instructions for these fields: 1. Make sure the username is one of these: A Domain administrator account that is a member of the Domain Admins group in the subdomain. Enter the administrator's name as domain\user. For example, if the domain is ACME.COM and the subdomain is SUB.ACME.COM, then for the Enterprise administrator John_Doe enter in the Username field: SUB.ACME.COM\John_Doe An Enterprise administrator account that is a member of the Enterprise Admins group in the domain. If you use an Enterprise administrator, enter the administrator's name as domain\user. For example, if the domain is ACME.COM and the subdomain is SUB.ACME.COM, then for the Enterprise administrator John_Doe enter in the Username field: ACME.COM\John_Doe Note - In the wizard this is the Username field, in the LDAP Account Unit go to LDAP Server Properties tab > Add > Username. 2. In LDAP Server Properties tab > Add > Login DN - add the login DN. 3. In Objects Management tab > Branches in use - Edit the base DN from DC=DOMAIN_NAME,DC=DOMAIN_SUFFIX to DC=SUB_DOMAIN_NAME,DC=DOMAIN_NAME,DC=DOMAIN_SUFFIX. For example, change DC=ACME,DC=local to DC=SUB,DC=ACME,DC=local
Identity Sources
Specifying Domain Controllers per Security Gateway

An organization's Active Directory can have several sites, where each site has its own domain controllers that are protected by a Security Gateway. When all of the domain controllers belong to the same Active Directory, one LDAP Account Unit is created in SmartDashboard. When AD Query is enabled on Security Gateways, you may want to configure each Security Gateway to communicate with only some of the domain controllers. This is configured in the User Directory page of the Gateway Properties. For each domain controller that is to be ignored, the default priority of the Account Unit must be set to a value higher than 1000. For example, let's say that the LDAP Account Unit ad.mycompany.com has 5 domain controllers.
On the Security Gateway we want to enable AD Query only for domain controllers dc2 and dc3. This means that all other domain controllers must be set to a priority higher than 1000 in the gateway properties.
To specify domain controllers for each Security Gateway:

1. 2. 3. 4. 5. Log in to SmartDashboard. From the Network Objects tree, right-click Check Point and select the Security Gateway. From the Gateway Properties tree, select Other > User Directory. Click Selected Account Units list and click Add. Select your Account Unit.
Identity Sources
6. Clear the Use default priorities checkbox and set the priority 1001 to dc1, dc4 and dc5.
7. Click OK. 8. Install policy.
Checking the Status of Domain Controllers

You can make sure that the domain controllers are set properly by using the adlog CLI. You can see the domain controllers that the Security Gateway is set to communicate with as well as the domain controllers it ignores. The CLI command is adlog a dc.
Permissions and Timeout

AD Query is based on querying the Active Directory Security Event Logs and extracting the user and machine mapping to the network address from them. The system receives a security event log when a user or machine accesses a network resource. For example, a user logs in, unlocks a screen, or accesses a network drive. Notifications are not sent when a user logs out as the Active Directory is not aware of this. When using AD Query you must be aware of its limitations: When the defined timeout passes (12 hours by default), permissions are no longer applicable. For example, a user sitting at the same computer with the same IP address originally authenticated. If the user does not access an Intranet resource (lock/unlock the computer, share/access a network drive) that requires authentication after logging in, the user will no longer have permissions after the timeout period. When this happens, the user gets the Captive Portal for authentication purposes (if Captive Portal is set). On average, users access resources every 30 minutes that create authentication requests, usually this is not a problem. If necessary, you can increase the default time (Check Point Gateway Properties > Identity Awareness > Active Directory Query Settings). AD Query does not distinguish between application service accounts on a user's machine and the actual user's account. For example, you can exclude "dummy" user names used for automatic actions or services running on endpoint computers (anti-virus, backup, etc.). Resulting logs show that multiple accounts are logged in on the same IP. To prevent this you can exclude irrelevant accounts ("Excluding Users" on page 49) from being logged.
Identity Sources
Multiple accounts can be connected to the same IP address. This happens because Identity Awareness does not detect user log outs and this results in IP permissions being kept until the timeout value passes. When multiple users are associated with the same IP address, SmartView Tracker logs show "user1(+) user2.... (+)userN" in the user name column. For example, when a Helpdesk administrator logs on to install a program for a user. When the administrator logs out, the user will get the Helpdesk administrator's permissions plus his own permissions until the timeout. To prevent this you must first exclude irrelevant accounts and then enable single user assumption.
Single User Assumption

A solution for multiple accounts logging in with the same IP address is to assume that only one user is connected to each computer. For example, if user A logs out before the timeout and user B logs in, user B will be considered the user connected to the computer. User B will then only have his permissions and not user A's permissions. Before you can make this assumption, it is necessary to exclude any service accounts used by user computers. Note - Another way to keep these issues to a minimum is to increase DHCP lease time.
To set single user assumption:

1. 2. 3. 4. Exclude any service accounts. See Excluding Users (on page 49). From the Identity Awareness page, select Settings for Active Directory Query. Select Assume that only one user is connected per computer. Click OK.
Excluding Users
You can distinguish between application service accounts on a user's machine and the actual user's account by excluding the service accounts. These service accounts are used for automatic actions or services running on endpoint computers (anti-virus, backup, etc.). If you do not exclude them, they show up multiple times in logs. You can exclude user or machine accounts by entering: User names Machine names * and ? wildcard characters - For example, enter Steve* to exclude all users that start with Steve. Regular expressions - You can use regular expressions to define a complex or detailed set of accounts to exclude (see "Regular Expressions" on page 113). The regular expression syntax is regexp:<regular expression> and is case-sensitive.
These examples show how regular expressions can be used. Example 1 - To exclude all users from the query except for the user Brad1 in an Active Directory that contains users named Brad1, Brad2, Brad3, Brad4, and Brad5, enter: regexp:^Brad[2-5] Example 2 - To exclude users or machines from the query that start with Brad and have 3 digits, enter: regexp:^Brad\d\d\d Example 3 - To exclude all machines from the query that start with win, any character and 2 alphanumeric characters in an Active Directory that contains machines named win7, win-xp, win2k3, win2k8, enter: regexp:^win.\w\w This excludes all machines except for win7. Example 4 - To exclude all machines or users with 3 digits in their names from the query in an Active Directory that contains users or machines named Brad1, Brad333, win2k3, win2008, enter: regexp:\d{3} This excludes Brad333 and win2008.
Identity Sources
To distinguish between application server accounts and a user's account:

1. From the Identity Awareness page, select Settings for Active Directory Query. 2. Click Advanced. 3. In the Excluded Users / Machines section, type the name or name pattern of the Active Directory accounts to ignore. You can use the * and ? wildcard characters to specify multiple users in a list entry. You can also enter any regular expression with the syntax regexp:<regular expression>. 4. Click Add. 5. Click OK.
Multiple Gateway Environments

In environments that use multiple gateways and AD Query, we recommend that you set only one gateway to acquire identities from a given Active Directory domain controller per physical site. If more than one gateway gets identities from the same AD server, the AD server can become overloaded with WMI queries. Set these options on the Identity Awareness page: One gateway to share identities with other gateways. This is the gateway that gets identities from a given domain controller. All other gateways to get identities from the gateway that acquires identities from the given domain controller.
See the Deployment Scenarios (on page 69) section for more details.
Non-English Language Support

To support non-English user names on a Security Gateway enabled with Identity Awareness, you must set a parameter in the LDAP Account Unit object in SmartDashboard. It is not necessary to set this parameter when you enable Identity Awareness on the Security Management Server or Log Server.
To set non-English language support:

1. 2. 3. 4. Select Servers and OPSEC in the Objects Tree. Right-click Servers > LDAP Account Unit and select the LDAP Account Unit. In the General tab of the LDAP Account Unit, select Enable Unicode support. Click OK.
Performance
Bandwidth between the Log server and Active Directory Domain Controllers
The amount of data transferred between the Log server and domain controllers depends on the amount of events generated. The generated events include event logs and authentication events. The amounts vary according to the applications running in the network. Programs that have many authentication requests result in a larger amount of logs. The observed bandwidth range varies between 0.1 to 0.25 Mbps per each 1000 users.
CPU Impact
When using AD Query, the impact on the domain controller's CPU is less than 3%.
Nested Groups
Identity Awareness supports the use of LDAP nested groups. When a group is nested in another group, users in the nested group are identified as part of the parent group. For example, if you make Group_B a member of Group_A, Group_B members will be identified by Identity Awareness as being part of Group A. The default nesting depth is configured to 20. This feature is enabled by default. For details on working with nested groups, see sk66561 (http://supportcontent.checkpoint.com/solutions?id=sk66561).
Identity Sources
Troubleshooting
If you experience connectivity problems between your domain controllers and Security Gateway with Identity Awareness/log servers, perform the following troubleshooting steps: In this section: Check Connectivity Use wbemtest to Verify WMI Confirm that Security Event Logs are Recorded Install Database for a Log Server 51 51 53 53
Check Connectivity
1. 2. 3. 4. Ping the domain controller from the Security Gateway with Identity Awareness/log server. Ping the Security Gateway with Identity Awareness/log server from your domain controller. Perform standard network diagnostics as required. Check SmartView Tracker and see if there are drops between a Security Gateway defined with AD Query (Source) and the domain controller (Destination). If there are drops, see Configuring the firewall (on page 52) and sk58881 (http://supportcontent.checkpoint.com/solutions?id=sk58881).
Use wbemtest to Verify WMI

To use the Microsoft wbemtest utility to verify that WMI is functional and accessible.
1. Click Start > Run. 2. Enter wbemtest.exe in the Run window. 3. In the Windows Management Instrumentation Tester window, click Connect. 4. In the Connect window, enter the following information:
a) Domain controller in the following format: \\<IP address>\root\cimv2 For example: \\11.22.33.44\root\cimv2 b) Fully qualified AD user name. For example: ad.company.com\admin c) Password 5. Click Connect.
Identity Sources
6. If the Windows Management Instrumentation Tester window re-appears with its buttons enabled, WMI is fully functional. 7. If the connection fails, or you receive an error message, check for the following conditions: a) Connectivity ("Check Connectivity" on page 51) problems b) Incorrect domain administrator credentials ("Check Domain Administrator Credentials" on page 52). c) WMI service ("Verify the WMI Service" on page 52) is not running d) A firewall is blocking traffic ("Configuring the Firewall" on page 52) between the Security Gateway with Identity Awareness/log server and domain controller.
Check Domain Administrator Credentials To verify your domain administrator credentials:

1. Click Start > Run. 2. Enter \\<domain controller IP>\c$ in the Run window. For example: \\11.22.33.44\c$. 3. In the Logon window, enter your domain administrator user name and password. 4. If the domain controller root directory appears, this indicates that your domain administrator account has sufficient privileges. An error message may indicate that: a) If the user does not have sufficient privileges, this indicates that he is not defined as a domain administrator. Obtain a domain administrator's credentials. b) You entered the incorrect user name or password. Check and retry. c) The domain controller IP is incorrect or you are experiencing connectivity issues.
Verify the WMI Service To verify if the WMI service is running on the domain controller:
1. Click Start > Run. 2. Enter services.msc in the Run window. 3. Locate the Windows Management Instrumentation service and verify that the service has started.
If it has not started, right-click this service and select Start from the option menu.
Configuring the Firewall

If a Security Gateway is located between the Security Gateway with Identity Awareness/log server and the Active Directory controller, configure the Firewall to allow WMI traffic.
To create firewall rules for WMI traffic:

1. In SmartDashboard > Firewall, create a rule that allows ALL_DCE_RPC traffic: Source = Security Gateways that run AD Query Destination = Domain Controllers Service = ALL_DCE_RPC Action = Accept
Identity Sources
2. Save the policy and install it on Security Gateways. Note - If there are connectivity issues on DCE RPC traffic after this policy is installed, see sk37453 (http://supportcontent.checkpoint.com/solutions?id=sk37453) for a solution.
Confirm that Security Event Logs are Recorded

If you have checked connectivity ("Check Connectivity" on page 51) but still do not see identity information in logs, make sure that the necessary event logs are being recorded to the Security Event Log. AD Query reads these events from the Security Event log: On Windows Server 2003 domain controllers - 672, 673, 674 On Windows Server 2008 domain controllers - 4624, 4769, 4768, 4770
Make sure you see the applicable events in the Event Viewer on the domain controller (My computer > Manage > Event Viewer > Security). If the domain controller does not generate these events (by default they are generated), refer to Microsoft Active Directory documentation for instructions on how to configure these events.
Install Database for a Log Server

If you have configured Identity Awareness for a log server, but do not see identities in logs, make sure you installed the database. To install the database: 1. Select Policy > Install Database.... The Install Database window appears. 2. Select the machine(s) on which you would like to install the database and click OK. The Install Database script appears. 3. Click Close when the script is complete.
Advanced Browser-Based Authentication Configuration

Customizing Text Strings
You can customize some aspects of the web interface. This includes changes to the text strings shown on the Captive Portal Network Login page. You can make changes to the default English language or edit files to show text strings in other languages. You can change English text that is shown on the Captive Portal to different English text through the SmartDashboard. The changes are saved in the database and can be upgraded. To configure other languages to show text strings in a specified language on the Captive Portal, you must configure language files. These language files are saved on the Security Gateway and cannot be upgraded. If you upgrade the Security Gateway, these files must be configured again. To help you understand what each string ID means, you can set the Captive Portal to String ID Help Mode. This mode lets you view the string IDs used for the text captions.
Setting Captive Portal to String ID Help Mode

To set the Captive Portal to String ID Help mode:
1. On the Security Gateway, open the file: /opt/CPNacPortal/phpincs/utils/L10N.php
Identity Sources
2. Replace the line // return $stringID; with return $stringID; (delete the two backslashes that you see before the text return $stringID).
3. Reload the Captive Portal in your web browser. The Captive Portal opens showing the string IDs.
4. To revert to regular viewing mode, open the file L10N.php and put backslashes before the text return #stringID. See the highlighted text in step number 2 above.
Changing Portal Text in SmartDashboard

To change the text that shows in SmartDashboard:
1. 2. 3. 4. 5. 6. Go to Policy > Global Properties > SmartDashboard Customization. Click Configure. Go to Identity Awareness > Portal Texts. Delete the word DEFAULT and type the new English text in the required field. Click OK. Install the policy.
Identity Sources
Adding a New Language

You can configure the Captive Portal to show the Network Login pages in different languages. After you set the language selection list, users can choose the language they prefer to log in with from a list at the bottom of the page.
To configure a language for Captive Portal you must:

1. Edit the language array for the new language locale. 2. Use the English language file as a template to create new language files. Then translate the strings in the new language file. 3. Save the files with UTF-8 encoding and move them to the correct location. 4. Set the language selection list to show on the Network Login page. 5. Make sure the text strings are shown correctly.
Editing the Language Array

The supported language file contains entries for languages that you can see in the list on the Captive Portal page. By default, English is the only language entry in the list. It has a corresponding language file. For each new language, you must create an entry in the supported languages file and create a new language file.
To create a new language, add an entry to the supported languages file:

1. Open the file: /opt/CPNacPortal/phpincs/conf/L10N/supported_languages.php
Identity Sources
2. In the $arLanguages array, create a new locale entry with the syntax: "xx_XX" => "XName". For example: "de_DE" => "German".
To disable a language:
Comment out the line of the specific language or delete the line.
Creating New Language Files

To create new language files, use the English language file ( portal_en_US.php) as a template and refer to it for the source language. The file contains the message strings. It is not necessary to translate all strings, but you must include all strings in the new language file. When you translate a string, make sure that the string's length is almost the same in size as the initial English string. This is important to prevent breaks in the page layout. If this is not possible, consult with technical support. You cannot use HTML special character sequences such as / < / &gt in the translated strings.
To create a new language file:

1. Copy the English language file: /opt/CPNacPortal/phpincs/conf/L10N/portal_en_US.php 2. Rename it to the new language using the syntax portal_xx_XX.php. For example, portal_de_DE.php 3. Translate the strings in the copied file.
Saving New Language Files

You must save the language file with UTF-8 encoding.
To save a file with UTF-8 encoding:

1. Use Notepad, Microsoft Word or a different editor to save the file with UTF-8 encoding. When using Microsoft Word, save the file as a '.txt' file with UTF-8 as the encoding method and rename it to portal_xx_XX.php. For example: portal_de_DE.php. 2. Move the file to /opt/CPNacPortal/phpincs/conf/L10N if it is not already there.
Showing the Language Selection List

When you only use the English language, the language selection list does not show at the bottom of the Captive Portal Network Login page. When you configure additional languages, you must show the language selection list on the Network Login page. Captive Portal users can then select the language with which to log in.
To see the language list on the Network Login page:

1. On the Security Gateway, open the file: /opt/CPNacPortal/phpincs/view/html/Authentication.php 2. Back up the file (for possible future revert). 3. Find the language_selection string which is part of <label for="language_selection">. 4. Remove these lines: <?PHP /* */?> You can find the first line a few lines above the language_selection string. You can find the second line about 20 lines below the language_selection string.
Identity Sources
The lines to remove appear within the marked square below:
5. Save the file. The language selection list will show on the Network Login page. 6. To revert back to not showing the language selection list, replace the current file with the backup of the original file.
Making Sure the Strings Shows Correctly

To make sure the strings show correctly:
1. 2. 3. 4. Browse to the Captive Portal and select the new language. Browse from different operating systems with different locale setups. Make sure that the text is shown correctly on the Captive Portal pages. Browse to the Captive Portal from a different browser and use a different font size.
Server Certificates
For secure SSL communication, gateways must establish trust with endpoint computers by showing a Server Certificate. This section discusses the procedures necessary to generate and install server certificates. Check Point gateways, by default, use a certificate created by the Internal Certificate Authority on the Security Management Server as their server certificate. Browsers do not trust this certificate. When an endpoint computer tries to connect to the gateway with the default certificate, certificate warning messages open in the browser. To prevent these warnings, the administrator must install a server certificate signed by a trusted certificate authority. All portals on the same Security Gateway IP address use the same certificate.
Identity Sources
Obtaining and Installing a Trusted Server Certificate

To be accepted by an endpoint computer without a warning, gateways must have a server certificate signed by a known certificate authority (such as Entrust, VeriSign or Thawte). This certificate can be issued directly to the gateway, or it can be a chained certificate that with a certification path to a trusted root certificate authority (CA).
Generating the Certificate Signing Request

First, generate a Certificate Signing Request (CSR). The CSR is for a server certificate, because the gateway acts as a server to the clients. Note - This procedure creates private key files. If private key files with the same names already exist on the machine, they are overwritten without warning. 1. From the gateway command line, log in to expert mode. 2. Run: cpopenssl req -new -out <CSR file> -keyout <private key file> -config $CPDIR/conf/openssl.cnf This command generates a private key. You see this output: Generating a 2048 bit RSA private key .+++ ...+++ writing new private key to 'server1.key' Enter PEM pass phrase: 3. Enter a password and confirm. You see this message: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank. For some fields there will be a default value. If you enter '.', the field will be left blank. Fill in the data. The Common Name field is mandatory. This field must have the Fully Qualified Domain Name (FQDN). This is the site that users access. For example: portal.example.com.
All other fields are optional. 4. Send the CSR file to a trusted certificate authority. Make sure to request a Signed Certificate in PEM format. Keep the .key private key file.
Generating the P12 File

After you get the Signed Certificate for the gateway from the CA, generate a P12 file that has the Signed Certificate and the private key. 1. Get the Signed Certificate for the gateway from the CA. If the signed certificate is in P12 or P7B format, convert these files to a PEM (Base64 encoded) formatted file with a CRT extension. 2. Make sure that the CRT file has the full certificate chain up to a trusted root CA. Usually you get the certificate chain from the signing CA. Sometimes it split into separate files. If the signed certificate and the trust chain are in separate files, use a text editor to combine them into one file. Make sure the server certificate is at the top of the CRT file. 3. From the gateway command line, log in to expert mode. 4. Use the *.crt file to install the certificate with the *.key file that you generated. a) Run: cpopenssl pkcs12 -export -out <output file> -in <signed cert chain file> -inkey <private key file>
Identity Sources
For example: cpopenssl pkcs12 -export -out server1.p12 -in server1.crt -inkey server1.key b) Enter the certificate password when prompted.
Installing the Signed Certificate

Install the Third Party signed certificate to create Trust between the Mobile Access Software Blade and the clients. All portals on the same IP address use the same certificate. Define the IP address of the portal in the Portal Settings page for the blade/feature. 1. Import the new certificate to the gateway in SmartDashboard from a page that contains the Portal Settings for that blade/feature. For example: Gateway Properties > Mobile Access > Portal Settings Gateway Properties > Platform Portal Gateway Properties > Data Loss Prevention
Gateway Properties > Identity Awareness > Browser-Based Authentication > Settings > Access Settings In the Certificate section, click Import or Replace. 2. Install the policy on the gateway. Note - The Repository of Certificates on the IPsec VPN page of the SmartDashboard gateway object is only for self-signed certificates. It does not affect the certificate installed manually using this procedure.
Viewing the Certificate

To see the new certificate from a Web browser:
The gateway uses the certificate when you connect with a browser to the portal. To see the certificate when you connect to the portal, click the lock icon that is next to the address bar in most browsers. The certificate that users see depends on the actual IP address that they use to access the portal- not only the IP address configured for the portal in SmartDashboard.
To see the new certificate from SmartDashboard:

From a page that contains the portal settings for that blade/feature, click the View button in the Certificate section.
Identity Sources
Transparent Kerberos Authentication Configuration

The Identity Awareness Single-Sign On (SSO) solution for Browser-Based Authentication tries to transparently authenticate unidentified users logged in to AD before sending them to the Captive Portal for authentication. This means that a user authenticates to the domain one time and has access to all authorized network resources without having to enter credentials again. SSO in Windows domains works with the Kerberos authentication protocol. The Kerberos protocol is based on the concept of tickets, encrypted data packets issued by a trusted authority, Active Directory (AD). When a user logs in, the user authenticates to a domain controller that gives an initial ticket granting ticket (TGT). This ticket vouches for the user's identity. In this solution, when an unidentified user is about to be redirected to the Captive Portal for identification: 1. Captive Portal asks the browser for authentication. 2. The browser shows a Kerberos ticket to the Captive Portal. 3. Captive Portal sends the ticket to the Identity Server (the Security Gateway enabled with Identity Awareness). 4. The Identity Server decrypts the ticket, extracts the user's identity, and publishes it to all relevant Identity Awareness gateways. 5. The authorized and identified user is redirected to the originally requested URL. 6. If transparent automatic authentication fails (steps 2-5), the user is redirected to the Captive Portal for identification. Transparent Kerberos Authentication uses the GSS-API Negotiation Mechanism (SPNEGO) internet standard to negotiate Kerberos. This mechanism works like the mechanism that Endpoint Identity Agents use to present the Kerberos ticket ("How SSO Operates" on page 78). You can configure SSO Transparent Kerberos Authentication to work with HTTP and/or HTTPS connections. HTTP connections work transparently with SSO Transparent Kerberos Authentication at all times. HTTPS connections work transparently only if the Security Gateway has a signed .p12 certificate. If the Security Gateway does not have a certificate, the user sees, and must respond to, the certificate warning message before a connection is made. For detailed information on Kerberos SSO, see these links: http://web.mit.edu/Kerberos/ (http://web.mit.edu/Kerberos/) http://technet.microsoft.com/en-us/library/bb742433.aspx (http://technet.microsoft.com/enus/library/bb742433.aspx)
Configuration Overview
Transparent Kerberos Authentication SSO configuration includes these steps. They are described in details in this section. AD configuration - Creating a user account and mapping it to a Kerberos principal name For HTTP connections: (HTTP/<captive portal dns name>@DOMAIN) For HTTPS connections: (HTTPS/<captive portal dns name>@DOMAIN) Creating an LDAP Account Unit and configuring it with SSO. Enabling Transparent Kerberos Authentication on the Security Gateway configured with Identity Awareness.
SmartDashboard configuration
Endpoint client configuration - Configuring trusted sites in the browsers.
Where applicable, the procedures give instructions for both HTTP and HTTPS configuration.
Identity Sources
AD Configuration Creating a New User Account

1. In Active Directory, open Active Directory Users and Computers (Start->Run->dsa.msc) 2. Add a new user account. You can choose any username and password. For example: a user account named ckpsso with the password 'qwe123!@#' to the domain corp.acme.com.
3. Clear User must change password at next logon and select Password Never Expires.
Mapping the User Account to a Kerberos Principal Name

This step uses the ktpass utility to create a Kerberos principal name that is used by the Security Gateway and the AD. A Kerberos principal name contains a service name (for the Security Gateway that Endpoint browsers connect to) and the domain name to which the service belongs. Ktpass is a command-line tool available in Windows 2000 and higher.
Identity Sources
Retrieve the correct executable

You must install the correct ktpass.exe version on the AD. Ktpass.exe is not installed by default in Windows 2003. 1. If you are using Windows 2003: a) Retrieve the correct executable for your service pack from the Microsoft Support site (http://support.microsoft.com/) prior to installation. It is part of the Windows 2003 support tools. For example, AD 2003 SP2 requires support tools for 2003 sp2 (http://www.microsoft.com/downloads/details.aspx?familyid=96A35011-FD83-419D-939B9A772EA2DF90&displaylang=en). b) Download the support.cab and suptools.msi files to a new folder on your AD server. c) Run the suptools.msi. 2. If youre using ActiveDirectory 2008, the ktpass utility is already installed on your server in the Windows\System32 folder and you can run the command line. You need to open the command prompt as an administrator by right clicking it and selecting "run as an Administrator".
Use Ktpass
1. Open a command line to run the ktpass tool (Start > Run > cmd). 2. At the command prompt, run ktpass with this syntax: For HTTP connections: C:> ktpass -princ HTTP/captive_portal_dns_name@DOMAIN_NAME -mapuser username@domain_name -pass password -out trans.keytab -ptype KRB5_NT_PRINCIPAL -crypto RC4-HMAC-NT For HTTPS connections: C:> ktpass -princ HTTPS/captive_portal_dns_name@DOMAIN_NAME -mapuser username@domain_name -pass password -out trans.keytab -ptype KRB5_NT_PRINCIPAL -crypto RC4-HMAC-NT Important - Make sure to enter the command exactly as shown as it is case-sensitive. The captive_portal_dns_name is lower case and the DOMAIN_NAME and KRB5_NT_PRINCIPAL are upper case. Below is an example of running ktpass with these parameters: Parameter captive_portal_dns_name@DOMAIN_NAME username@domain_name password Value [email protected] [email protected] qweQWE!@#
ktpass princ HTTP/[email protected] mapuser [email protected] pass qweQWE!@# -out trans.keytab ptype KRB5_NT_PRINCIPAL -crypto RC4-HMACNT The AD is ready to support Kerberos authentication for the Security Gateway. Important - If you have used the ktpass utility before for the same principal name (HTTP/captive_portal_dns_name@DOMAIN_NAME) but with a different account, you must either delete the different account beforehand or remove its association to the principal name (by using setspn D HTTP/domain_name old_account name i.e. setspn D HTTP/corp.acme.com ckpsso). Failure to do this will cause the authentication to fail. The above example shows the ktpass syntax on Windows 2003. When using Windows 2008/2008 R2 Server, the ktpass syntax is slightly different. Parameters are introduced using a forward slash "/" instead of a hyphen "-".
Identity Sources
HTTP example: ktpass /princ HTTP/[email protected] /mapuser [email protected] /pass qweQWE!@# /out trans.keytab /ptype KRB5_NT_PRINCIPAL /crypto RC4-HMACNT HTTPS example: ktpass /princ HTTPS/[email protected] /mapuser [email protected] /pass qweQWE!@# /out trans.keytab /ptype KRB5_NT_PRINCIPAL /crypto RC4-HMACNT
SmartDashboard Configuration
This section describes how to configure an LDAP Account Unit to support SSO.
Configuring an Account Unit

1. Add a new host to represent the AD domain controller. Go to Network Objects tab > Nodes > Node > Host. 2. Enter a name and IP address for the AD object and click OK. For example, ADServer. 3. Add a new LDAP Account Unit. Select Servers and OPSEC Applications in the Objects Tree. Rightclick Servers > New > LDAP Account Unit. 4. In the General tab of the LDAP Account Unit: a) Enter a name. b) In the Profile field, select Microsoft_AD. c) In the Domain field, enter the domain name. It is highly recommended to fill this field for existing account units that you want to use for Identity Awareness. Entering a value into this field will not affect existing LDAP Account Units. d) Select CRL retrieval and User management. 5. Click Active Directory SSO configuration and configure the values (see example): a) Select Use kerberos Single Sign On. b) Enter the domain name. For example, CORP.ACME.COM c) Enter the account username you created in Creating a New User Account (on page 61). For example, ckpsso. d) Enter the account password for that user (the same password you configured for the account username in AD) and confirm it. e) Leave the default settings for Ticket encryption method.
f)
Click OK.
Identity Sources
6. In the Servers tab: a) Click Add and enter the LDAP Server properties. b) In the Host field, select the AD object you configured in step 4 above. c) In the Login DN field, enter the login DN of a predefined user (added in the AD) used for LDAP operations. d) Enter the LDAP user password and confirm it. e) In the Check Point Gateways are allowed to section, select Read data from this server. f) In the Encryption tab, select Use Encryption (SSL), fetch the fingerprint and click OK. Note - LDAP over SSL is not supported by default. If you have not configured your domain controller to support LDAP over SSL, either skip step f or configure your domain controller to support LDAP over SSL. 7. In the Objects Management tab: a) In the Manage objects on field, select the AD object you configured in step 4 above. b) Click Fetch Branches to configure the branches in use. c) Set the number of entries supported. 8. In the Authentication tab, select Check Point Password in the Default authentication scheme and click OK.
Enabling Transparent Kerberos Authentication

1. 2. 3. 4. Log in to SmartDashboard. From the Network Objects tree, expand the Check Point object. Double-click the gateway enabled with Identity Awareness. Select Browser-Based Authentication - Settings. The Portal Settings window opens. 5. Select Authentication Settings - Edit. The Authentication Settings window opens. 6. Select Automatically authenticate users from machines in the domain. Main URL: The URL used to begin the SSO process. If transparent authentication fails, users are redirected to the configured Captive Portal. IP Address: The IP address to which the Portal URL is resolved if DNS resolution fails.
Browser Configuration
To work with Transparent Kerberos Authentication, it is necessary to configure your browser to trust Captive Portal URL. If the portal is working with HTTPS, you must also enter the URL in the Local Internet field using HTTPS.
Internet Explorer
It is not necessary to add the Captive Portal URL to Trusted Sites.
To configure Internet Explorer for Transparent Kerberos Authentication:

1. Open Internet Explorer. 2. Go to Internet Tools > Options > Security > Local intranet > Sites > Advanced. 3. Enter the Captive Portal URL in the applicable and then click Add.
Google Chrome
If you have already configured Internet Explorer for Transparent Kerberos Authentication, that configuration also works with Chrome. Use this procedure only if you did not configure Internet Explorer for Transparent Kerberos Authentication.
Identity Sources
To configure Google Chrome for Transparent Kerberos Authentication:

1. 2. 3. 4. 5. 6. Open Chrome. Click the menu (wrench) icon and select Settings. Click Show advanced settings. In the Network section, click Change Proxy Settings. In the Internet Properties window, go to Security > Local intranet > Sites > Advanced. Enter the Captive Portal URL in the applicable field.
Firefox
or Firefox, the Negotiate authentication option is disabled by default. To use Transparent Kerberos Authentication, you must enable this option.
To configure Firefox for Transparent Kerberos Authentication:

1. Open Firefox. 2. In the URL bar, enter about:config 3. Search for the network.negotiate-auth.trusted-uris parameter. 4. Set the value to the DNS name of the Captive Portal gateway. You can enter multiple URLs by separating them with a comma.
Advanced Endpoint Identity Agents Configuration

Customizing Parameters
You can change settings for Endpoint Identity Agent parameters to control agent behavior. You can change some of the settings from SmartDashboard and some can be prepackaged with the agent.
To change Endpoint Identity Agents parameters in SmartDashboard:

1. Go to Policy > Global Properties > SmartDashboard Customization . 2. Click Configure. 3. Go to Identity Awareness > Agent. The Agent parameters are shown. This is a sample list of parameters that you can change: Parameter Nac_agent_disable_settings Description Whether users can right click the Endpoint Identity Agent client (umbrella icon on their desktops) and change settings. You can add a default email address for to which to send client troubleshooting information. Whether users can right click the Endpoint Identity Agent client (umbrella icon on their desktops) and close the agent. Whether to disable the packet tagging feature that prevents IP spoofing. Whether to hide the client (the umbrella icon does not show on users' desktops).
Nac_agent_email_for_sending_logs
Nac_agent_disable_quit
Nac_agent_disable_tagging
Nac_agent_hide_client 4. Click OK.
Identity Sources
Prepackaging Endpoint Identity Agent Installation

Prepackaging refers to a procedure that lets you add configuration to the Endpoint Identity Agents installation. This lets you, for example, prepackage the agent with the server address. You can then have users download the Endpoint Identity Agents from the Captive Portal or send them the installation through email. For more information, see Prepackaging Identity Agents (on page 91). Note - When you use prepackaging, the digital signature in the installer is invalidated. Unless you resign the installation with your own software signing certificate, users that download the agent through the Captive Portal will receive a notification saying that the installer is not signed.
Chapter 4
Advanced Deployment
In This Chapter Introduction Deployment Options Deploying a Test Environment Deployment Scenarios 67 68 68 69
Introduction
You can deploy Check Point Security Gateways enabled with Identity Awareness in various scenarios that provide a maximum level of security for your network environment and corporate data. This section describes recommended deployment scenarios and options available with Identity Awareness. Perimeter security gateway with Identity Awareness This deployment scenario is the most common scenario, where you deploy the Check Point security gateway at the perimeter where it protects access to the DMZ and the internal network. The perimeter security gateway can also control and inspect outbound traffic, targeted to the Internet. In this case, you can create an identity-based firewall security Rule Base together with Application Control. Data Center protection If you have a Data Center or server farm, segregated from the users' network, you can protect access to the servers with the security gateway. To do this, deploy the security gateway inline in front of the Data Center. All traffic that flows is then inspected by the gateway. You can control access to resources and applications with an identity-based access policy. You can deploy the security gateway in transparent mode (bridge mode) to avoid significant changes in the existing network infrastructure. Large scale enterprise deployment In large scale enterprise networks, there is a need to deploy multiple security gateways at different network locations, such as the perimeter firewall and multiple Data Centers. Identity Awareness capability is centrally managed through the Security Management Server and SmartDashboard. You can distribute the identity-based policy to all identity aware security gateways in the network. Identity information about all users and machines obtained by each gateway is shared between all gateways in the network to provide a complete Identity Awareness infrastructure. Network segregation The security gateway helps you migrate or design internal network segregation. Identity Awareness lets you control access between different segments in the network by creating an identity-based policy. You can deploy the security gateway close to the access network to avoid malware threats and unauthorized access to general resources in the global network. Distributed enterprise with branch offices The distributed enterprise consists of remote branch offices connected to the headquarters through VPN lines. You can deploy the security gateway at the remote branch offices to avoid malware threats and unauthorized access to the headquarters' internal network and Data Centers. When you enable Identity Awareness at the branch office gateway you make sure that users are authenticated before they reach internal resources. The identity information learned from the branch office gateways is shared between internal gateways to avoid unnecessary authentications. Wireless campus Wireless networks are not considered secure for network access, however they are intensively used to provide access to wireless-enabled corporate devices and guests. You can deploy a security gateway enabled with Identity Awareness inline in front of the wireless switch, provide an identity aware access policy and inspect the traffic that comes from WLAN users. Identity Awareness gives guests access by authenticating guests with the web Captive Portal. Important - NAT between two identity aware gateways that share information with each other is not a supported configuration.
Advanced Deployment
Deployment Options
You can deploy a security gateway enabled with Identity Awareness in two different network options: IP routing mode Transparent mode (bridge mode)
IP routing mode This is a regular and standard method used to deploy Check Point security gateways. You usually use this mode when you deploy the gateway at the perimeter. In this case, the gateway behaves as an IP router that inspects and forwards traffic from the internal interface to the external interface and vice versa. Both interfaces should be located and configured using different network subnets and ranges. Transparent mode Known also as a "bridge mode". This deployment method lets you install the security gateway as a Layer 2 device, rather than an IP router. The benefit of this method is that it does not require any changes in the network infrastructure. It lets you deploy the gateway inline in the same subnet. This deployment option is mostly suitable when you must deploy a gateway for network segregation and Data Center protection purposes.
Deploying a Test Environment

If you want to evaluate how Identity Awareness operates in a security gateway, we recommend that you deploy it in a simple environment. The recommended test setup below gives you the ability to test all identity sources and create an identity-based policy. The recommendation is to install 3 main components in the setup: 1. User host (Windows) 2. Check Point security gateway R75.20 3. Microsoft Windows server with Active Directory, DNS and IIS (Web resource) Deploy the gateway inline in front of the protected resource, the Windows server that runs IIS (web server). The user host machine will access the protected resource via the security gateway.
Testing Identity Sources

To configure the test environment:
1. 2. 3. 4. 5. 6. 7. 8. 9. Install the user host machine with Windows XP or 7 OS. Install Windows Server and configure Active Directory and DNS. Install IIS with a sample Web Server. Deploy a security gateway either in routing or bridge mode. Test connectivity between the host and the Windows server. Add the user host machine to the Active Directory domain. Enable Identity Awareness in the gateway. Follow the wizard and enable the AD Query and Browser-Based Authentication identity sources. Create an Access Role and define access for all authenticated users or select users with the Users picker. 10. Create 3 rules in the Firewall Rule Base: a) Any to Any Negate HTTP accept log b) Access Role to Any HTTP accept log c) Any to Any Drop 11. Install policy. 12. Logout and login again from the user host machine. 13. Open SmartView Tracker > Identity Awareness section and check whether the user is authenticated using the AD Query method.
Advanced Deployment
14. 15. 16. 17.
Use the user host machine to test connectivity to the Web Server. Check logs. The user and machine names show in the connections logs. From the gateway's CLI revoke the authenticated user by: pdp control revoke_ip IP_ADDRESS On the user host machine open an Internet browser and try to connect to the web resource. You should be redirected to the Captive Portal, use the user's credentials to authenticate and access the web resource.
Testing Endpoint Identity Agents

Enable and configure Identity Agents and configure Identity Agents self provisioning via Captive Portal ("Configuring Agent Deployment from Captive Portal" on page 37). 1. Open a browser and connect to the web resource. You are redirected to the Captive Portal. 2. Enter user credentials. 3. Install the client as requested by the Captive Portal. When the client is installed wait for an authentication pop-up to enter the user's credentials via the client. 4. Test connectivity. The SSO method using Kerberos authentication can be tested as well, see Kerberos SSO Configuration (on page 77).
Deployment Scenarios
Perimeter Security Gateway with Identity Awareness
Security Challenge
The security gateway at the perimeter behaves as a main gate for all incoming and outgoing traffic to and from your corporate network. Users located in the internal networks access the Internet resource and applications daily. Not all Internet applications and web sites are secure and some are restricted according to corporate policy. Blocking all internal access may impact productivity of certain employees that must have access in the context of their daily work definition. Controlling access to the allowed applications is possible through the Application Control blade. However, you may require a more granular access policy that is based also on user and machine identity i.e. access roles. Access roles let you configure an identity aware policy together with Application Control to allow access only to specified user groups to the applications on the Internet. In this case Identity Awareness should be enabled on the perimeter security gateway.
Deployment scenario
1. Deploy the gateway at the perimeter in routing mode and define an external interface towards the ISP (the Internet) and an internal interface points to the internal corporate network LAN. Optional: you can define another internal interface which protects DMZ servers. 2. Make sure that NAT or Proxy devices do not exist between the gateway and LAN (the recommendation is to have proxy in the DMZ network). 3. Check that the gateway has connectivity to the internal AD domain controllers. 4. Make sure that users can reach the gateways internal interface. 5. Configure the Application Control blade. See the R75.40VS Application Control and URL Filtering Administration Guide (http://supportcontent.checkpoint.com/solutions?id=sk76540). 6. If you have several perimeter gateways leading to the Internet, we recommend that you manage these gateways with one Security Management Server and SmartDashboard to deploy the relevant security policy.
Advanced Deployment
Configuration
1. Enable Identity Awareness and select the appropriate identity sources. 2. Create access roles based on users and machines. You can create multiple access roles that represent different departments, user and machine groups and their location in the network. 3. Add the access roles to the source column of the relevant firewall and application control policies.
Data Center Protection

Security Challenge
The Data Center contains sensitive corporate resources and information that must be securely protected from unauthorized access. You must also protect it from malwares and viruses that can harm databases and steal corporate information. Access to the Data Center and particularly to certain applications must be granted only to compliant users and machines.
Deployment Scenario
1. Deploy the security gateway inline in front of the Date Center core switch, protecting access to the Data Center from the LAN. 2. We recommend that you deploy the gateway in the bridge mode, to avoid any changes in the network. However, IP routing mode is also supported. 3. Define at least two interfaces on the gateway and configure them to be internal or bridged. 4. Make sure that the gateway has connectivity to the Active Directory and all relevant internal domain controllers in the network (LAN). 5. Make sure that users from the LAN can connect to the Data Center through the security gateway with an ANY ANY accept policy. 6. Make sure that you do not have a proxy or NAT device between the gateway and users or the LAN.
Configuration
1. Enable Identity Awareness on the gateway and select identity sources. 2. Create access roles for users and apply the access roles to relevant Firewall security rules.
Advanced Deployment
Large Scale Enterprise Deployment

Security Challenge
In complex large scale enterprise networks you must control access from the local network to the Internet and to multiple Data Center resources. Access should be granted only to compliant users and machines. The Data Center contains sensitive corporate resources and information that must be securely protected from unauthorized access. You must also protect it from malwares and viruses that can harm databases and steal corporate information. Users located in the internal networks access the Internet resource and applications daily. Not all Internet applications and web sites are secure and some are restricted according to corporate policy. Blocking all internal access may impact productivity of certain employees that must have access in the context of their daily work definition. Controlling access to the allowed applications is possible through the Application Control blade. However, you may require a more granular access policy that is based also on user and machine identity i.e. access roles.
Deployment Scenario
1. Deploy or use existing security gateways at the perimeter and in front of the Data Center. 2. Install the gateway at the perimeter in routing mode, and use at least one external interface to the Internet and one to the internal network (define it as an internal interface). 3. Deploy the gateway as an inline device in front of the Data Center in bridge mode to avoid network changes. This is not required, but is recommended. Nonetheless, IP routing mode is also supported. 4. Make sure that all gateways in the Data Centers and perimeter can communicate directly with each other. 5. We recommend that you manage the gateway from one Security Management Server and SmartDashboard. 6. Make sure that there is connectivity from each gateway to the Active Directory internal domain controllers. 7. Make sure that in an "Any Any Accept" policy, users from the LAN can connect to the desired resources. 8. Make sure that there is no NAT or proxy devices installed between the gateways and LAN segment. If there are such devices, consider moving them to DMZ if possible.
Configuration
1. Enable Identity Awareness on the gateway and choose the appropriate identity source method for each gateway, at the perimeter and at the Data Center. 2. Create access roles for users and apply access roles to the relevant firewall security rules. 3. Use the Application Control policy in the perimeter gateway and add access roles to the policy. 4. In the Gateway properties > Identity Awareness tab, make sure to select Share local identities with other gateways.
Advanced Deployment
AD Query Recommended Configuration

When you enable AD Query to obtain user and machine identity, we recommend that you enable the feature on all gateways that participate in the network environment. All gateways should have the Active Directory domain defined with the list of all relevant domain controllers in the internal network.
Endpoint Identity Agents Recommended Configuration

If you choose to use Endpoint Identity Agents to authenticate users and machines, you have to select the gateway that will be used to maintain identity agents. For a single Data Center and perimeter gateway it is recommended to define identity agents that connect to a single gateway. Then the identity obtained by the gateway is shared with the other gateways in the network. Select a high capacity / performance gateway, which can also behave as an authentication server, and configure this gateways IP / DNS on the Endpoint Identity Agents (see Endpoint Identity Agents section). For complex multi Data Center environments where there are several gateways that protect different Data Centers and the perimeter, we recommend that you balance Endpoint Identity Agents authentication using different gateways. You can configure a list of gateways in the Endpoint Identity Agent settings, where the agent will connect to different gateways. This provides load balancing across the gateways. Identities learned from the agents are shared between all gateways in the network.
Identity Sharing Advanced Settings

To define a list of gateways between which identity information is shared: 1. Go to Gateway properties > Identity Awareness tab and select Get identities from other gateways. 2. Select the gateways you want to obtain identities from.
Network Segregation
Security Challenge
Networks consist of different network segments and subnets where your internal users reside. Users that connect to the network can potentially spread viruses and malwares across the network that can infect other computers and servers on the network. You want to make sure that only compliant users and machines can pass and connect across multiple network segments, as well as authenticate users connecting to the servers and the Internet.
Advanced Deployment
Deployment scenario
We recommend that you deploy security gateways close to access networks before the core switch. Access between the segments is controlled by the gateway. Access between the LAN and Data Center is controlled by the gateway. Access between the LAN and the Internet is controlled by the gateways either at each segment or at the perimeter gateway. We recommend that you deploy the gateway in bridge mode to avoid network and routing changes. Each gateway of a particular segment authenticates users with the selected method. Share identities learned from the segment gateways with the perimeter firewall to create an outgoing traffic firewall policy or use an Application Control policy as well.
Configuration
1. Deploy gateways in each segment in bridge mode. 2. Make sure that there is no proxy or NAT device between the gateways and the LAN. 3. Make sure that the gateways can communicate with the Active Directory domain controller deployed in each segment (replicated domain controllers). If there is a general domain controller that serves all users across the segments, make sure that all gateways can connect to this domain controller. 4. Enable Identity Awareness on each gateway and select an appropriate identity source method. 5. In the Identity Awareness tab, clear the Share local identities with other gateways option. If you want to share identities with one gateway, for example, the perimeter gateway, keep this option selected and disable Get identities from other gateways in the segment gateway. Then go to the perimeter gateway and select Get identities from other gateways. 6. If you want to use Endpoint Identity Agents, then define the particular gateways DNS/IP in the agent gateway configuration per access segment.
Distributed Enterprise with Branch Offices

Security Challenge
In distributed enterprises there is a potential risk of malware and viruses spreading from remote branch offices over VPN links to the corporate's internal networks. There is also a challenge of how to provide authorized access to users that come from remote branch offices that request and want to access the Data Center and the Internet.
Deployment Scenario
1. We recommend that you deploy security gateways at the remote branch offices and at headquarters in front of the Data Center and at the perimeter. 2. At remote branch offices, you can deploy low capacity gateways due to a relatively low number of users. Deploy the remote branch gateways in IP routing mode and have them function as a perimeter firewall and VPN gateway, establishing a VPN link to the corporate gateways.
Advanced Deployment
3. At the corporate headquarters, we recommend that you deploy Data Center gateways to protect access to Data Center resources and applications, as well as a perimeter gateway. You can install the Data Center gateway in bridge mode to avoid changes to the existing network. 4. In this scenario, users from the branch office are identified by the local branch office gateway before connecting to the corporate network over VPN. 5. The identities learned by the branch office gateways are then shared with the headquarters' internal and perimeter gateways. When a user from a branch office attempts to connect to the Data Center, the user is identified by the gateway at the headquarters Data Center without the need for additional authentication.
Configuration
1. 2. 3. 4. 5. Select a security gateway according to a performance guideline for your remote branch offices. Deploy the gateways at the branch offices in routing mode. Define VPN site-to-site if necessary. Deploy gateways inline at the Data Center. We recommend using bridge mode. Deploy a gateway at the perimeter that protects the internal network in routing mode. The perimeter gateway can serve as a VPN gateway for branch offices as well. If you have Active Directory domain controllers replicated across your branch offices make sure that local gateways can communicate with the domain controller. In case you do not have a local domain controller, make sure that the gateways can access the headquarters' internal domain controller over VPN. Enable Identity Awareness and select the appropriate methods to get identity. Create an access role and apply the roles in the security policy on the branch office gateways, perimeter and Data Center gateway. Make sure that you share identities between the branch offices with the headquarter and Data Center gateways, by selecting these settings on the Identity Awareness tab:
6. 7. 8.
Advanced Deployment
AD Query Recommended Configuration

When you use AD Query to authenticate users from the local and branch offices, we recommend that you only configure a local domain controller list per site in the relevant gateways. For example, if you have a branch office gateway and a Data Center gateway, enable AD Query on all gateways. On the branch office gateway, select the Active Directory domain controllers replications installed in the branch office only. On the Data Center gateway, configure a list of domain controllers installed in the internal headquarters network. It is not necessary to configure all domain controllers available in the network, since the identity information is shared between branch and internal gateways accordingly.
Endpoint Identity Agents Recommended Configuration

When using Endpoint Identity Agents, we recommend that you configure the local branch office gateways DNS/IP on the agent. The agents connect to the local gateway and the user is authenticated, identities are shared with the internal headquarter gateways.
Wireless Campus
Security Challenge
You use wireless networks to grant access to employees that use Wi-Fi enabled devices, guests and contractors. Guests and contractors in some cases cannot use the corporate wired network connection and must connect through WLAN. Furthermore, it is not intended for guests and contractors to install any endpoint agents on their devices. Wireless access is also intensively used to connect mobile devices such as smart phones where agents can be installed. These devices are not part of the Active Directory domain. Wireless networks do not give a desired level of security in terms of network access.
Deployment Scenario
1. Deploy the security gateway in bridge mode in front of the Wireless Switch. 2. Make sure that the gateway can access the Internet or any other required resource in the network. 3. Make sure that the gateway can communicate with the authentication server, such as Active Directory or RADIUS. 4. Check that there is no NAT or proxy device between the gateway and the WLAN network.
Configuration
1. Enable Identity Awareness on the gateway. 2. Select Browser-Based Authentication as an identity source. 3. In the Gateway properties > Identity Awareness tab > Browser-Based Authentication Settings, select Unregistered guests login and in Settings, select the fields you want guests to fill when they register. 4. Select Log out users when they close the portal browser.
Dedicated Identity Acquisition Gateway

Security Challenge
You have several Security Gateways that protect the Data Center or Internet access where access is based on identity acquisition. The gateways run different blades and deal with heavy traffic inspection. To avoid an impact on performance of the gateways in terms of user identity acquisition and authentication, it is possible to offload this functionality to a separate Security Gateway. The dedicated Security Gateway is responsible for acquiring user identity, performing authentication and sharing learned identities with all enforcing gateways in the network.
Advanced Deployment
Deployment Scenario
In this deployment scenario, you have to choose an appropriate appliance to deploy as the dedicated Identity Awareness enabled gateway. All users authenticate with this gateway. If you enable AD Query, the dedicated gateway should communicate with all Active Directory domain controllers over WMI. 1. On the dedicated identity acquisition gateway, enable the Identity Awareness feature and select the identity method. 2. Make sure to configure the gateway to share identities with other gateways in the network.
3. On the enforcement gateways, enable Identity Awareness and select Get identities from other gateways.
Chapter 5
Advanced Identity Agent Options
In This Chapter Kerberos SSO Configuration Server Discovery and Trust Prepackaging Identity Agents 77 83 91
Kerberos SSO Configuration

Overview
The Identity Awareness Single Sign-On (SSO) solution for Endpoint Identity Agents gives the ability to transparently authenticate users that are logged in to the domain. This means that a user authenticates to the domain one time and has access to all authorized network resources without additional authentication. Using Endpoint Identity Agents gives you: User and machine identity Minimal user intervention - all necessary configuration is done by administrators and does not require user input. Seamless connectivity - transparent authentication using Kerberos Single Sign-On (SSO) when users are logged in to the domain. If you do not want to use SSO, users enter their credentials manually. You can let them save these credentials. Connectivity through roaming - users stay automatically identified when they move between networks, as the client detects the movement and reconnects. Added security - you can use the patented packet tagging technology to prevent IP Spoofing. Endpoint Identity Agents also gives you strong (Kerberos based) user and machine authentication.
You get SSO in Windows domains with the Kerberos authentication protocol. Kerberos is the default authentication protocol used in Windows 2000 and above. The Kerberos protocol is based on the idea of tickets, encrypted data packets issued by a trusted authority which in this case is the Active Directory (AD). When a user logs in, the user authenticates to a domain controller that provides an initial ticket granting ticket (TGT). This ticket vouches for the users identity. When the user needs to authenticate against the Security Gateway with Identity Awareness, the Endpoint Identity Agent presents this ticket to the domain controller and requests a service ticket (SR) for a specific resource (Security Gateway that Endpoint Identity Agents connect to). The Endpoint Identity Agent then presents this service ticket to the gateway that grants access.
How SSO Operates
Item A B C D 1
Description User Active Directory Domain Controller Security Gateway that Endpoint Identity Agents connect to Data Center servers a) A logs in to B b) B sends an initial ticket (TGT) to A a) The Identity Agent connects to C b) C asks A for user authentication a) The Identity Agents requests a service ticket (SR) for C and presents the TGT to B b) B sends the SR (encrypting the user name with the shared secret between B and C) The Endpoint Identity Agent sends the service ticket to C C decrypts the ticket with the shared secret and identifies A A gets access to D based on identity
4 5 6
References
For detailed information on Kerberos SSO, see these links: http://web.mit.edu/Kerberos/ (http://web.mit.edu/Kerberos/) http://technet.microsoft.com/en-us/library/bb742433.aspx (http://technet.microsoft.com/enus/library/bb742433.aspx)
SSO Configuration
SSO configuration includes two steps: AD Configuration - Creating a user account and mapping it to a Kerberos principal name. SmartDashboard Configuration - Creating an LDAP Account Unit and configuring it with SSO.
AD Configuration
Creating a New User Account
1. In Active Directory, open Active Directory Users and Computers (Start->Run->dsa.msc) 2. Add a new user account. You can choose any username and password. For example: a user account named ckpsso with the password 'qwe123!@#' to the domain corp.acme.com.
3. Clear User must change password at next logon and select Password Never Expires.
Mapping the User Account to a Kerberos Principal Name

This step uses the ktpass utility to create a Kerberos principal name that is used by both the gateway and the AD. A Kerberos principal name consists of a service name (for the Security Gateway that Endpoint Identity Agents connect to) and the domain name to which the service belongs. Ktpass is a command-line tool available in Windows 2000 and higher.
Retrieve the correct executable

You must install the correct ktpass.exe version on the AD. Ktpass.exe is not installed by default in Windows 2003. 1. If you are using Windows 2003: a) Retrieve the correct executable for your service pack from the Microsoft Support site (http://support.microsoft.com/) prior to installation. It is part of the Windows 2003 support tools. For example, AD 2003 SP2 requires support tools for 2003 sp2 (http://www.microsoft.com/downloads/details.aspx?familyid=96A35011-FD83-419D-939B9A772EA2DF90&displaylang=en). b) Download the support.cab and suptools.msi files to a new folder on your AD server. c) Run the suptools.msi. 2. If youre using ActiveDirectory 2008, the ktpass utility is already installed on your server in the Windows\System32 folder and you can run the command line. You need to open the command prompt as an administrator by right clicking it and selecting "run as an Administrator".
Use Ktpass
1. Open a command line to run the ktpass tool (Start > Run > cmd). 2. At the command prompt, run ktpass with this syntax: C:> ktpass -princ ckp_pdp/domain_name@DOMAIN_NAME -mapuser username@domain_name -pass password -out unix.keytab crypto RC4-HMAC-NT Important - Make sure to enter the command exactly as shown. Mapping the username to the Kerberos principal name with ktpass is case-sensitive. Below is an example of running ktpass with these parameters: Parameter domain_name@DOMAIN_NAME username@domain_name password Value [email protected] [email protected] qwe123@#
The AD is ready to support Kerberos authentication for the Security Gateway.
Important - If you have used the ktpass utility before for the same principal name (ckp_pdp/domain_name@DOMAIN_NAME) but with a different account, you must either delete the different account beforehand or remove its association to the principal name (by using setspn D ckp_pkp/domain_name old_account name i.e. setspn D ckp_pdp/corp.acme.com ckpsso). Failure to do this will cause the authentication to fail. The example above shows the ktpass syntax on Windows 2003. When using Windows 2008/2008 R2 Server, the ktpass syntax is slightly different. Parameters are introduced using a forward slash " /" instead of a hyphen "-".
SmartDashboard Configuration
This section describes how to configure an LDAP Account Unit to support SSO.
Configuring an Account Unit

1. Add a new host to represent the AD domain controller. Go to Network Objects tab > Nodes > Node > Host. 2. Enter a name and IP address for the AD object and click OK. For example, ADServer. 3. Add a new LDAP Account Unit. Select Servers and OPSEC Applications in the Objects Tree. Rightclick Servers > New > LDAP Account Unit. 4. In the General tab of the LDAP Account Unit: a) Enter a name. b) In the Profile field, select Microsoft_AD. c) In the Domain field, enter the domain name. It is highly recommended to fill this field for existing account units that you want to use for Identity Awareness. Entering a value into this field will not affect existing LDAP Account Units. d) Select CRL retrieval and User management. 5. Click Active Directory SSO configuration and configure the values (see example): a) Select Use kerberos Single Sign On. b) Enter the domain name. For example, CORP.ACME.COM c) Enter the account username you created in Creating a New User Account (on page 61). For example, ckpsso. d) Enter the account password for that user (the same password you configured for the account username in AD) and confirm it. e) Leave the default settings for Ticket encryption method.
f)
Click OK.
6. In the Servers tab: a) Click Add and enter the LDAP Server properties. b) In the Host field, select the AD object you configured in step 4 above. c) In the Login DN field, enter the login DN of a predefined user (added in the AD) used for LDAP operations. d) Enter the LDAP user password and confirm it. e) In the Check Point Gateways are allowed to section, select Read data from this server. f) In the Encryption tab, select Use Encryption (SSL), fetch the fingerprint and click OK. Note - LDAP over SSL is not supported by default. If you have not configured your domain controller to support LDAP over SSL, either skip step f or configure your domain controller to support LDAP over SSL. 7. In the Objects Management tab: a) In the Manage objects on field, select the AD object you configured in step 4 above. b) Click Fetch Branches to configure the branches in use. c) Set the number of entries supported. 8. In the Authentication tab, select Check Point Password in the Default authentication scheme and click OK.
Server Discovery and Trust

Introduction
The Endpoint Identity Agent client needs to be connected to a Security Gateway with Identity Awareness. For this to happen, it must discover the server and trust it.
Server discovery refers to the process of deciding which server the client should connect to. We offer several methods for configuring server discovery from a very basic method of simply configuring one server to a method of deploying a domain wide policy of connecting to a server based on your current location. This section describes these options. Server trust refers to the process of validating that the server the end user connects to is indeed a genuine one. It also makes sure that communication between the client and the server was not tampered with by a Man In The Middle (MITM) attack. The trust process compares the server fingerprint calculated during the SSL handshake with the expected fingerprint. If the client does not have the expected fingerprint configured, it will ask the user to verify that it is correct manually. This section describes the methods that allow the expected fingerprint to be known, without user intervention.
Discovery and Trust Options

These are the options that the client has for discovering a server and trusting it: File name based server configuration If no other method is configured (default, out-of-the-box situation), any Endpoint Identity Agent downloaded from the portal will be renamed to have the portal machine IP in it. During installation, the client uses this IP to represent the Security Gateway with Identity Awareness. Note that the user has to trust the server by himself (the trust dialog box opens). AD based configuration If client computers are members of an Active directory domain, you can deploy the server addresses and trust data using a dedicated tool. DNS SRV record based server discovery It is possible to configure the server addresses in the DNS server. Note that as DNS isnt secure, the trust data cannot be configured in that way and the user will have to authorize it manually in a trust dialog box that opens. This is the only server discovery method that is applicable for the MAC OS Endpoint Identity Agent. Remote registry All of the client configuration, including the server addresses and trust data reside in the registry. You can deploy the values before installing the client (by GPO, or any other system that lets you control the registry remotely). This lets you use the configuration from first run. Prepackaging You can create a prepackaged version of the client installation that includes the server IP and trust data.
Option Comparison
Requires Manual MultiAD User Trust Site Required? File name based AD based No Yes No Client Allows Remains Ongoing Signed? Changes Yes No Level Recommended for... Single gateway deployments Deployments with AD that you can modify Deployments without AD or with an AD you cannot modify, but the DNS can be changed Where remote registry is used for other purposes
Very Simple Simple
Yes
No
Yes
Yes
Yes
DNS based
No
Yes
Partially Yes (per DNS server)
Yes
Simple
Remote registry
No
No
Yes
Yes
Yes
Moderate
Prepackaging
No
No
Yes
No
No
Advanced When both DNS and AD cannot be changed, and there is more than one gateway
File Name Based Server Discovery

This option is the easiest to deploy, and works out-of-the-box if the Captive Portal is also the Security Gateway with Identity Awareness. If your deployment consists of one Security Gateway with Identity Awareness and a Captive Portal running on the same gateway and it is OK with you that the user needs to verify the server fingerprint and trust it once, you can use this option, which works with no configuration.
How does it work?

When a user downloads the Endpoint Identity Agent client from the Captive Portal, the address of the Security Gateway with Identity Awareness is embedded into the file name. During the installation sequence, the client checks if there is any other discovery method configured (prepackaged, AD based, DNS based or local registry). If no method is configured and the server can be reached, it will be used as the Security Gateway with Identity Awareness. You can make sure that this is the case by looking at the client settings and seeing that the server that is shown in the file name is present in the Endpoint Identity Agent dialog box.
Why can't we use this for trust data?

As the file name can be changed, we cannot be sure that the file name wasnt modified by an attacker along the way. Therefore, we cannot trust data passed in the file name as authentic, and we need to verify the trust data by another means.
AD Based Configuration
If your client computers are members of an Active Directory domain and you have administrative access to this domain, you can use the Distributed Configuration tool to configure connectivity and trust rules. The Distributed Configuration tool consists of three windows: Welcome - This window describes the tool and lets you to enter alternate credentials that are used to access the AD.
Server configuration This window lets you configure which Security Gateway with Identity Awareness the client should use, depending on its source location. Trusted gateways This window lets you view and change the list of fingerprints that the Security Gateways with Identity Awareness consider secure.
Server Configuration Rules

If you use the Distributed Configuration tool and you configure Automatically discover the server, the client fetches the rule lists and each time it needs to connect to a server, it tries to match itself against a rule, from top to bottom. When it matches a rule, it uses the servers shown in this rule, according to the priority specified. For example:
This configuration means: 1. If the user is coming from 192.168.0.1 192.168.0.255, then try to connect to US-GW1. If it isnt available, try BAK-GS2 (it will be used only if US-GW1 is not available, as its priority is higher). 2. Otherwise, if the user is connected from the Active Directory site UK-SITE, connect either to UK-GW1 or UK-GW2 (choose between them randomly, as they both have the same priority). If both of them are not available, connect to BAK-GS2. 3. Otherwise, connect to BAK-GS2 (the default rule is always matched when it is encountered).
Trusted Gateways
The trusted gateways window shows the list of servers considered trusted no popups will open when trying to connect to them. You can add, edit or delete a server. If you have connectivity to the server, you can get the name and fingerprint by entering its address and clicking Fetch Fingerprint. Otherwise, you should enter the same name and fingerprint that is shown when connecting to that server.
Note - The entire configuration is written under a hive named Check Point under the Program Data Branch in the AD database that is added in the first run of the tool. Adding this hive wont have any effect on other AD based applications or features.
DNS Based Configuration

If you configure the client to Automatic Discovery (the default), it looks for a server by issuing a DNS SRV query for the address CHECKPOINT_NAC_SERVER._tcp (the DNS suffix is added automatically). You can configure the address in your DNS server. On the DNS server: 1. 2. 3. 4. 5. 6. 7. 8. 9. Go to Start > All Programs > Administrative Tools > DNS. Go to Forward lookup zones and select the applicable domain. Go to the _tcp subdomain. Right click and select Other new record. Select Service Location, Create Record. In the Service field, enter CHECKPOINT_NAC_SERVER. Set the Port number to 443. In Host offering this server, enter the address of the Security Gateway with Identity Awareness. Click OK. Note - Security Gateway with Identity Awareness load sharing can be achieved by creating several SRV records with the same priority and High Availability can be achieved by creating several SRV records with different priorities.
Note - If you configure AD based and DNS based configuration, the results are combined according to the specified priority (from the lowest to highest).
Troubleshooting - Displaying SRV Record Stored in the DNS Server

Run the following commands: C:\> nslookup > set type=srv > checkpoint_nac_server._tcp Server: dns.company.com Address: 192.168.0.17 checkpoint_nac_server._tcp.ad.company.com SRV service location: priority = 0 weight = 0 port = 443 svr hostname = idserver.company.com idserver.company.com internet address = 192.168.1.212 >
Remote Registry
If you have another way to deploy registry entries to your client computers (i.e. Active Directory GPO updates), you can deploy the Security Gateway with Identity Awareness addresses and trust parameters before installing the clients. That way, they will use the already deployed settings immediately after installation.
To use the remote registry option:

1. Install the client on one of your computers. Make sure it is installed in the same mode that will be installed on the other computers the full agent installs itself to your program files directory, and saves its configuration to HKEY_LOCAL_MACHINE, while the light agent installs itself to the users directory, and saves its configuration to HKEY_CURRENT_USER. 2. Connect manually to all of the servers that are configured, verify their fingerprints, and click trust on the fingerprint verification dialog box.
3. Configure it manually to connect to the requested servers (Use the settings dialog box). If you need the client to choose a server based on the client location, you can click Advanced and configure it that way. See AD Based Configuration (on page 86) to understand how these rules are interpreted. 4. Export the following registry keys (from HKEY_LOCAL_MACHINE / HKEY_CURRENT_USER, according to the client type installed): a) SOFTWARE\CheckPoint\NAC\TrustedGateways (the entire tree) b) SOFTWARE\CheckPoint\NAC\ (i) DefaultGateway (ii) DefaultGatewayEnabled (iii) PredefinedPDPConnRBUsed (iv) PredefinedPDPConnectRuleBase 5. Deploy the exported keys to the workstations before installing the client on your workstations.
Prepackaging Endpoint Identity Agents

Prepackaging can be used to control server discovery and trust as well as other client aspects. For more information, see Prepackaging Endpoint Identity Agents ("Prepackaging Identity Agents" on page 91).
Prepackaging Identity Agents

Introduction
The Check Point Endpoint Identity Agent has many advanced configuration parameters. Some of these parameters relate to the installation process and some relate to the actual operation of the agent. All of the configuration parameters have default values that are deployed with the product and can remain unchanged. There are the types of Endpoint Identity Agents: Full agent The Endpoint Identity Agent is available for all users who use the computer, with packet tagging and machine authentication. Light agent The Endpoint Identity Agent is available for the single user that is running this installation and does not include packet tagging and machine authentication. Custom - The installation process and the product configuration can be customized via prepackaging. The customization tool is called cpmsi_tool.exe and it is deployed with the agent (Program Files > Check Point > Identity Agent).
Important - The Endpoint Identity Agents come digitally signed by Check Point Software Technologies Ltd. Any modification to the Endpoint Identity Agents, including prepackaging, will invalidate the signature, and will result in security warnings displayed to the user downloading them from the Captive Portal.
Custom Endpoint Identity Agent msi

You can find a customizable msi version of the Endpoint Identity Agent (for distribution via a software distribution tool or Captive Portal) in these places: Installed Security Gateway - in /opt/CPNacPortal/htdocs/nac/nacclients/customAgent.msi SecurePlatform installation CD - in /linux/windows/Check_Point_Custom_Nac_Client.msi
Using the cpmsi_tool.exe

The cpmsi_tool.exe is a shell tool. To use it, store it in the same location as the installation package and type: cpmsi_tool <installation package name> readini <INI file name> From the INI file you can control the configuration. You can use the template INI file for quick configuration. The INI file is divided into these sections: The Properties section controls the installation process. The Features section controls the installed features. The AddFiles section controls the deployed Endpoint Identity Agent configuration.
The tool has some other options that are not used for Identity Awareness.
Configuring Installation - [Properties] Section

You can configure these Endpoint Identity Agent installation properties in the INI file:
INSTALLUITYPE
This property has these values: SILENT - No user interface is shown to the user. BASIC - An installation progress bar is shown while installation takes place. This is the default value. FULL - The user sees a full installation user interface.
HIDEFEATURES
This property determines the visibility of the Custom Setup (feature selection) dialog box in the installation process. If this dialog box is hidden then the installation process behaves as if the user clicked Next without changing anything. Values for this property: Yes No - By default, the Custom Setup dialog box is shown (it is not hidden).
INSTALLTYPE
This property lets you can choose one of these installation type values: ALLUSERS - Anyone who uses the computer SINGLEUSER - Only for the user who is installing the Endpoint Identity Agent ASKUSER - Leaves the dialog box in the installation for the end user to decide. By default, the Choose Installation orientation dialog box is shown.
Configuring Installed Features - [Features] Section

You can configure the following properties and decide whether or not to install these features, or let users decide on their own.
MADService
This property relates to the Managed Asset Detection service. This is a service that gives you machine authentication and enables managed asset detection prior to logon authentication. This property is required if you Access Roles in the Rule Base that relate to machines. For example, if you set MADService=Yes then the feature dialog box will force install the Managed Asset Detection service. Values: Yes No Ask - the dialog box is shown to the end user who can decide whether to install or not. This is the default value.
PacketTagging
This property relates to the Packet Tagging driver. This driver signs every packet that is sent from the machine. This setting is required if you have rules in the Rule Base that use Access Roles and are set to enforce IP spoofing protection on the Machines tab.
Values: Yes No Ask - the dialog box is shown to the end user who can decide whether to install or not. This is the default value.
Configuring Deployed Endpoint Identity Agents - [AddFiles] Section

You can add a defs.reg file to the installation that lets you change the deployed Endpoint Identity Agent configuration. The defs.reg file is a simple registry file. The registry values are stored in the branch HKEY_LOCAL_MACHINE > SOFTWARE > Checkpoint >IA or in HKEY_CURRENT_USER > SOFTWARE > Checkpoint > IA if the installation is for a single user. After you create the defs.reg file, you must: 1. Copy it to the same directory as the installation package and the cpmsi_tool. 2. Uncomment the DEF_FILE_NAME line in the INI file. Note - If the defs.reg file does not exist the installation will fail. Registry file values: Registry Key 1 Accepted Values Description If the value is set to 1 then the settings button will not appear in the Identity Agent's tray menu. 0 is the default value. 2 DisableQuit DWORD:1,0 If the value is set to 1 then the quit button will not appear in the Identity Agent's tray menu. 0 is the default value. 3 HideGui DWORD:1,0 If the value is set to 1 then the Identity Agent's tray icon will not appear and there will be no client GUI. 0 is the default value. 4 SendLogsTO String: <email Allows defining the default email addresses addresses to send logs to if an error occurs or if a delimited by ;> user chooses to send logs in from the agents status dialog box. For example, to send error logs to MYEmail and disable the agent's settings dialog box: [HKEY_LOCAL_MACHINE\SOFTWARE\C heckPoint\IA] "SendLogsTO"[email protected] "DisableSettings"=dword:00000001
DisableSettings DWORD:1,0
Automatic Server Discovery

You can define a default gateway and trusted gateways by defining a defs.reg file with the relevant parameters.
For example:
Note - If a default gateway is not defined and the automatic server discovery fails during installation, the user will be asked to define the Security Gateway with Identity Awareness manually.
Sample INI File

Below is a sample INI file with the default configuration.
Deploying a Prepackaged Agent via the Captive Portal

To deploy a prepackaged agent via the Captive Portal:
1. Upload the modified customAgent.msi to your identification portal at /opt/CPNacPortal/htdocs/nacclients. 2. Configure the Captive Portal to distribute the custom agent. a) In SmartDashboard, go to the Security Gateway with Identity Awareness. b) Go to the Identity Awareness page. c) Click on the Browser-Based Authentication Settings button. d) Change the Require users to download value to Identity Agent - Custom.
Chapter 6
Identity Awareness Commands
In This Chapter Introduction pdp pep adlog test_ad_connectivity 98 99 106 Error! Bookmark not defined. 112
Introduction
These terms are used in the CLI commands: PDP - The process on the Security Gateway responsible for collecting and sharing identities. PEP - The process on the Security Gateway responsible for enforcing network access restrictions. Decisions are made according to identity data collected from the PDP. AD Query - AD Query is the module responsible for acquiring identities of entities (users or machines) from the Active Directory (AD). AD Query was called Identity Logging in previous versions and in some cases is also referenced as AD Log. The adlog is the command line process used to control and monitor the AD Query feature. test_ad_connectivity - A utility that runs connectivity tests from the gateway to an AD domain controller.
The PEP and PDP processes are key components of the system. Through them, administrators control user access and network protection. AD Query can run either on a Security Gateway that has been enabled with Identity Awareness or on a Log Server. When it runs on a Security Gateway, AD Query serves the Identity Awareness feature, and gives logging and policy enforcement. When it runs on a Log Server, AD Query gives identity logging. The command line tool helps control users statuses as well as troubleshoot and monitor the system. The test_ad_connectivity utility runs over both the LDAP and WMI protocols. It is usually used by the SmartDashboard Identity Awareness first time wizard, but you can run it manually on the gateway when needed.
pdp
Description Provides commands to control and monitor the PDP process. Usage pdp [command]... <argument> Syntax Argument <none> debug tracker connections network status control monitor update Description Display available options for this command and exit. Control debug messages. Tracker options. pdp connections information. pdp network information. pdp status information. pdp control commands. Display monitoring data. Recalculate users and machines group membership (deleted accounts will not be updated). Operations related to AD Query. Show pdp timers information.
ad timers
pdp monitor
Description Lets you monitor the status of connected sessions. You may perform varied queries according to the usage below to get the output you are interested in. Usage pdp monitor <argument> <option> Syntax Argument <none> all user <user name> ip <IP address> machine <machine name> mad Description Display available options for this command and exit. Display information for all connected sessions. Display session information for the given user name. Display session information for the given IP. Display session information for the given machine name. Display all sessions that relate to a managed asset (i.e. all sessions that successfully performed machine authentication). Display all sessions connecting via the given client type. Possible client types are:
Unknown - User was identified by an unknown source. Portal - User was identified by the Captive Portal. Identity Agent - User/machine was identified by an Identity Awareness Agent. AD Query - User was identified by AD Query.
client_type [unknown|portal|"Ident ity Agent"|"AD Query"]
groups <group name>
Display all sessions of users / machines that are members of the given group name. Display all sessions that are connected via a client version that is higher than (or equal to) the given version. Display all sessions that are connected via a client version that is lower than (or equal to) the given version.
cv_ge <version>
cv_le <version>
Example pdp monitor ip 10.10.10.1 Shows the connected user behind the given IP (10.10.10.1).
Note - The last field "Published Gateways" indicates whether the session information was already published to the PEPs whose IPs are listed.
pdp connections
Description These commands assist in monitoring and synchronizing the communication between the PDP and the PEP. Usage pdp connections <argument> Syntax Argument <none> pep Description Display available options for this command and exit. Display the connection status of all the PEPs that should be updated by the current PDP.
Example Each outgoing connection is used for identity sharing. Each incoming connection is mainly used as a control channel for exchanging network topologies for the smart pull. Local PEP (in PDP perspective) will always use "push" method and therefore no incoming control channel is needed. The same is true for remote PEP gateways using a "push" method.
pdp control
Description Provides commands to control the PDP process. Usage pdp control <argument> <option> Syntax Argument <none> revoke_ip <IP address> revoke_pt_key <session id.> sync Description Display available options for this command and exit. Log out the session that is related to the given IP.
Revoke the packet tagging key if one exists.
Force an initiated synchronization operation between the PDPs and the PEPs. When running this command, the PDP will inform its related PEPs the up-to-date information of all connected sessions. At the end of this operation, the PDP and the PEPs will contain the same and latest session information.
pdp network
Description Provides information about network related features. Usage pdp network <argument> Syntax Argument <none> info registered Description Display available options for this command and exit. Display a list of networks known by the PDP. Display the mapping of a network address to registered gateways (PEP module).
pdp debug
Description Activates and deactivates the debug logs of the PDP daemon. Usage pdp debug <argument> <option> Syntax Argument <none> on Description Display available options for this command and exit. Turn on the debug logs (should be followed by the command "set" to determine the required filter). Turn off the debug logs.
off
set <topic name> Filter the debug logs that would be written to the debug file according to the [critical|surprise| given topic and severity important|events| For debug it is recommended to run: all] pdp debug set all all. Note that you can place a number of topics and severity pairs. For example: topicA severityA topicB severityB ... unset <topic name> Unset a specific topic or topics. stat reset Show the status of the debug option. Reset the debug options of severity and topic. The debug is still activated after running this command. Rotate the log files (increase the index of each log file) so that the current log file that will be written is the PDP log. For example, pdpd.elg becomes pdpd.elg.0 and so on. Allows enabling or disabling writing of the CCC debug logs into the PDP log file.
rotate
ccc [on|off]
Example
Important - Activating the debug logs affects the performance of the daemon. Make sure to turn off the debug after you complete troubleshooting.
pdp tracker
Description Adds the TRACKER topic to the PDP logs (on by default). This is very useful when monitoring the PDP-PEP identity sharing and other communication on distributed environments. This can be set manually by adding the TRACKER topic to the debug logs. Usage pdp tracker <argument> Syntax Argument <none> Description Display available options for this command and exit. Turns on logging of TRACKER events in the PDP log. Turns off the logging of TRACKER events in the PDP log.
on
off
pdp status
Description Displays PDP status information such as start time or configuration time. Usage pdp status <argument> Syntax Argument <none> show Description Display available options for this command and exit. Display PDP information.
pdp update
Description Initiates a recalculation of group membership for all users and machines. Note that deleted accounts will not be updated. Usage pdp update <argument> Syntax Argument <none> all Description Display available options for this command and exit. Recalculate group membership for all users and machines.
pep
Description Provides commands to control and monitor the PEP process. Usage pep [command]... <argument> Syntax Argument <none> debug tracker show Description Display available options for this command and exit. Control debug messages. Tracker options. Display PEP information.
Example
pep show
Description Displays information regarding pep status. Usage pep show <argument> <option> Syntax Argument <none> stat pdp <id|all> user <all|query> network <pdp|registration> Description Display available options for this command and exit. See sections below.
pep show user

Description Enables monitoring the status of sessions that are known to the PEP. You can perform varied queries according to the usage below to get the output you are interested in. Command Usage Syntax Argument all Example The output for this command contains limited information for each user. To see full information for a specific record, use the command pep show user query. Description Display all sessions with information summary. pep show user <argument>
Query Usage Syntax Argument usr <username>
pep show user query <Arguments>
Description Display session information for the given user name.
mchn <machine name> cid <IP>
Display session information for the given machine name.
Display session information for the given IP. Display session information for the given session ID.
uid <uidString> pdp <IP>
Display all session information that was published from the given PDP IP. Display all sessions of users that are members of the given user group name. Display all sessions of machines that are members of the given machine group name.
ugrp <group> mgrp <group>
Note - You can use multiple query tokens (arguments) at once to create a logical "AND" correlation between them. For example, to display all users that have a sub string of "jo" AND are part of the user group "Employees" then you can use: # pep show user query usr jo ugrp Employees
pep show pdp

Description Enables monitoring the communication channel between the PEP and the PDP. The output displays the connect time and the number of users that were shared through the connection. Command Usage Syntax Argument all Description List all the PDPs that are connected to the current PEP with the relevant information. Display connection information of the given PDP IP. pep show pdp <argument>
id <IP> Example
pep show pdp all
pep show stat

Description Shows the last time the daemon was started and the last time a policy was received. Important - Each time the daemon starts, it loads the policy and the two timers (Daemon start time and Policy fetched at) will be very close. Usage pep show stat
pep show network

Description Shows network related information. pep show network <argument> Command Usage Syntax Argument pdp registration Description Shows information about mapping between the network and PDPs. Shows which networks this PEP is registered to.
pep debug
Description See pdp debug (on page 102).
adlog
Description Provides commands to control and monitor the AD Query process. When AD Query runs on a Security Gateway, AD Query serves the Identity Awareness feature that gives logging and policy-enforcement. In this case the command line is: adlog a <argument> (see below for options) When it runs on a Log Server, AD Query gives identity logging. In this case, the command line is: adlog l <argument>. Note: the l in adlog l is a lowercase L. Options for adlog a and adlog l are identical. Usage adlog [a | l] <command> <argument> Syntax Argument <none> [a | l] Description Display available options for this command and exit. Set the working mode: adlog l - if you are using a Log Server (identity logging) adlog a - if you are using AD Query for Identity Awareness. query debug dc statistics control service_accounts Example See sections below.
adlog query
Description Shows the database of identities acquired by AD Query, according to the given filter. Usage adlog [a|l] query <argument> Syntax
Argument ip <IP address> string <string> user <user name> machine <machine name> all
Description Filters identities relating to the given IP.
Filters identity mappings according to the given string. Filters identity mappings according to a specific user. Filters identity mappings according to a specific machine.
No filtering, shows the entire identity database.
Example adlog a query user jo Shows the entry that contains the string "jo" in the user name.
adlog dc
Description Shows status of connection to the AD domain controller. Usage adlog [a|l] dc Syntax None
adlog statistics
Description Displays statistics regarding NT Event Logs received by adlog, per IP and by total. It also shows the number of identified IPs. Usage adlog [a|l] statistics Syntax None
adlog debug
Description Turns on/off debug flags for controlling the debug file. The debug file is located at $FWDIR/log/pdpd.elg (for Identity Awareness on a Security Gateway) or $FWDIR/log/fwd.elg (for identity logging on a log server). Usage adlog [a|l] debug <argument> Syntax Argument on off mode extended Description Turn on debug. Turn off debug. Show debug status (on/off). Turn on debug and add extended debug topics.
adlog control
Description Sends control commands to AD Query. Usage adlog [a|l] control <argument> Syntax Argument stop reconf Description Stop AD Query. New identities are not acquired via AD Query. Send a reconfiguration command to AD Query, which means it resets to policy configuration as was set in SmartDashboard.
adlog service_accounts
Description Shows accounts that are suspected to be "service accounts". Service accounts are accounts that dont belong to actual users, rather they belong to services running on a computer. They are suspected as such if they are logged in more than a certain number of times. Usage adlog [a|l] service_accounts Syntax None
test_ad_connectivity
Description Runs connectivity tests from the Security Gateway to an AD domain controller. Usage $FWDIR/bin/test_ad_connectivity <argument_1 value_1> <argument value_2> <argument_n value_n> Arguments can be set in the command line as specified below, or set in a text file located at $FWDIR/conf/test_ad_connectivity.conf . Arguments set in the test_ad_connectivity.conf file are overridden by ones provided in the command line. Important - Arguments set in $FWDIR/conf/test_ad_connectivity cannot contain whitespaces and cannot be within quotation marks. Output of the utility is provided in a file (not to STDOUT). The path of the file is specified by the o argument (see below). Syntax Argument -d <domain name> -i <DC IP> -u <user name> -o <filename> Mandatory? Mandatory Description Domain name of the AD, for example ad.checkpoint.com
Mandatory Mandatory
IP of the domain controller that is being tested. Administrator user name on the AD.
Mandatory
Output filename relative to $FWDIR/tmp. For example, if you specify -o myfile, the output will be in $FWDIR/tmp/myfile Users password.
-c <password clear>
Either this or -a should be specified Either this or -c should be specified Mandatory Optional
-a
For entering password via stdin.
-t <timeout> -D <user DN>
Total timeout in milliseconds. Use this for LDAP user DN override (the utility wont try to figure out the DN automatically). Run LDAP connectivity test only (no WMI test). Run WMI connectivity test only (no LDAP test). SSL Parameters file path. Timeout for the LDAP test only. If this timeout expires and the LDAP test doesnt finish, both tests fail. Show help.
-l -w -s -L
Optional Optional Optional Optional
-h
Optional
Appendix A
Regular Expressions
Regular expressions are special characters that match or capture portions of a field. This sections covers special characters supported by Check Point and the rules that govern them. In This Appendix Metacharacters Square Brackets Parentheses Hyphen Dot Vertical Bar Backslash Quantifiers 113 114 114 114 114 114 114 115
Metacharacters
Some metacharacters are recognized anywhere in a pattern, except within square brackets; other metacharacters are recognized only in square brackets. The Check Point set of regular expressions has been enhanced for R70 and above. The following table indicates if earlier versions do not support use of a given metacharacter. Metacharacter \ (backslash) Meaning Earlier? See Backslash
escape character, and partial other meanings character class definition subpattern min/max quantifier match any character zero or one quantifier yes
[ ] (square brackets)
Square Brackets
( ) (parenthesis) { } (curly brackets) . (dot) ? (question mark) * (asterisk) + (plus) | (vertical bar) ^ (circumflex anchor)
yes no yes yes
Parentheses Curly Brackets Dot Question Mark Asterisk Plus Vertical Bar Circumflex Anchor
zero or more quantifier yes one or more quantifier yes
start alternative branch yes anchor pattern to beginning of buffer anchor pattern to end of buffer yes
$ (dollar anchor)
yes
Dollar Anchor
Regular Expressions
Square Brackets
Square brackets ([ ]) designate a character class: matching a single character in the string. Inside a character class, only these metacharacters have special meaning: backslash ( \ ) - general escape character. hyphen ( - ) - character range.
Parentheses
Parentheses ( ) designate a subpattern. To match with either an open-parenthesis or closing-parenthesis, use the backslash to escape the symbol.
Hyphen
A hyphen '-' indicates a character range inside a character class. When used as a simple character in a character class, it must be escaped by using a backslash '\'. For example: [a-z] matches the lower-case alphabet.
Dot
Outside a character class, a dot (.) matches any one character in the string. For example: .* matches zero or more occurrences of any character Inside a character class, it matches a dot (.).
Vertical Bar
A vertical bar (|) is used to separate alternative patterns. If the right side is empty, this symbol indicates the NULL string: a| matches a or empty string. For example: a|b matches a or b
Backslash
The meaning of the backslash (\) character depends on the context. The following explanations are not all supported in earlier versions; see Earlier Versions for details. In R70 and above, backslash escapes metacharacters inside and outside character classes.
Escaping Symbols
If the backslash is followed by a non-alphanumeric character, it takes away any special meaning that character may have. For example, \* matches an asterisk, rather than any character. Also, you can escape the closing bracket with a backslash [\]]. If the protection against the pattern is for earlier gateways as well as for newer ones, do not write one backslash inside square brackets. Instead, write two backslashes if you want to have a literal backslash inside square brackets. You cannot use \ to escape a letter that is not a metacharacter. For example, because "g" is not a metacharacter, you cannot use \g.
Regular Expressions
Encoding Non-Printable Characters

To use non-printable characters (such as tab, return, and so on) in patterns, use the backslash before a character set reserved for non-printable characters. Character \a \cx \e \f \n \r \t \ddd \xhh Meaning alarm; the BEL character (hex 07) "control-x", where x is any character escape (hex 1B) formfeed (hex 0C) newline (hex 0A) carriage return (hex 0D) tab (hex 09) character with octal code ddd character with hex code hh
Specifying Character Types

To specify certain types of characters (such as digits, whitespace, words) in patterns, use the backslash before a character set reserved for character types. Character \d \D \s \S \w \W Meaning any decimal digit any character that is not a decimal digit any whitespace character any character that is not whitespace any word character (underscore or alphanumeric character) any non-word character (not underscore or alphanumeric)
Quantifiers
Various metacharacters indicate how many instances of a character, character set or character class should be matched. A quantifier must not follow another quantifier, an opening parenthesis, or be th e expressions first character. These quantifiers can follow any of the following items: a literal data character an escape such as \d that matches a single character a character class a sub-pattern in parentheses
Regular Expressions
Curly Brackets
Curly brackets ({ }) are used as general repetition quantifiers. They specify a minimum and maximum number of permitted matches. For example: a{2,4} matches aa, aaa, or aaaa If the second number is omitted, but the comma is present, there is no upper limit; if the second number and the comma are both omitted, the quantifier specifies an exact number of required matches. For example: [aeiou]{3,} matches at least 3 successive vowels, but may match many more \d{8} matches exactly 8 digits
Note - A closing curly bracket '}' that is not preceded by an opening curly bracket '{' is treated as a simple character. However, it is good practice to use a backslash, '\}', when using a closing curly bracket as a simple character.
Question Marks
Outside a character class, a question mark (?) matches zero or one character in the string. It is the same as using {0,1}. For example: c([ab]?)r matches car, cbr, and cr Inside a character class, it matches a question mark: [?] matches ? (question mark).
Asterisk
Outside a character class, an asterisk (*) matches any number of characters in the string. It is the same as using {0,}. For example: c([ab]*)r matches car, cbr, cr, cabr, and caaabbbr Inside a character class, it matches an asterisk: [*] matches * (asterisk).
Plus
Outside a character class, a plus (+) matches one or more characters in the string. It is the same as using {1,}. For example: c([ab]+)r matches character strings such as car, cbr, cabr, caaabbbr; but not cr Inside a character class, it matches a plus: [+] matches + (plus).
Index
A
Access Role Objects 30 Access Settings 33 Acquiring Identities for Active Directory Users 16 Acquiring Identities in a Terminal Server Environment 23 Acquiring Identities in Application Control 23 Acquiring Identities with Browser-Based Authentication 17 Acquiring Identities with Endpoint Identity Agents 20 AD Based Configuration 85 AD Configuration 60, 78 AD Query 10 Adding a New Language 55 adlog 106 adlog control 108 adlog dc 107 adlog debug 107 adlog query 106 adlog service_accounts 108 adlog statistics 107 Advanced AD Query Configuration 46 Advanced Browser-Based Authentication Configuration 53 Advanced Deployment 66 Advanced Endpoint Identity Agents Configuration 65 Advanced Identity Agent Options 76 Agent Access 40 Agent Deployment from the Portal 35 Agent Upgrades 40 Asterisk 113 Authentication Settings 33, 40 Automatic Server Discovery 93
Configuring Endpoint Identity Agents in SmartDashboard 39 Configuring Identity Awareness 25 Configuring Identity Awareness for a Domain Forest (Subdomains) 46 Configuring Identity Logging for a Log Server 44 Configuring Installation - [Properties] Section 90 Configuring Installed Features - [Features] Section 91 Configuring Remote Access 43 Configuring Terminal Servers 41 Configuring Terminal Servers Accessibility 42 Configuring the Firewall 52 Configuring the Shared Secret 41 Confirm that Security Event Logs are Recorded 53 Creating a New User Account 60, 78 Creating Access Roles 27 Creating New Language Files 56 Curly Brackets 113 Custom Endpoint Identity Agent msi 90 Customize Appearance 34 Customizing Parameters 65 Customizing Text Strings 53
D
Data Center Protection 69 Dedicated Identity Acquisition Gateway 74 Deploying a Prepackaged Agent via the Captive Portal 95 Deploying a Test Environment 67 Deploying the Terminal Servers Identity Awareness Solution 41 Deployment 14 Deployment Options 67 Deployment Scenarios 68 Discovery and Trust Options 83 Distributed Enterprise with Branch Offices 72 DNS Based Configuration 87 Dot 111
B
Backslash 111 Browser Configuration 64 Browser-Based Authentication 11
E
Editing the Language Array 55 Enabling Identity Awareness on the Log Server for Identity Logging 44 Enabling Identity Awareness on the Security Gateway 25 Enabling Transparent Kerberos Authentication 64 Encoding Non-Printable Characters 112 Endpoint Identity Agent Deployment Methods 37 Endpoint Identity Agent Types 36 Escaping Symbols 111 Excluding Users 49
C
Changing Portal Text in SmartDashboard 54 Check Connectivity 51 Check Domain Administrator Credentials 52 Checking the Status of Domain Controllers 48 Choosing Identity Sources 45 Configuration Overview 60 Configuring Agent Deployment for User Groups 38 Configuring Agent Deployment from Captive Portal 38 Configuring an Account Unit 62, 80 Configuring Browser-Based Authentication in SmartDashboard 32 Configuring Deployed Endpoint Identity Agents - [AddFiles] Section 93 Configuring Endpoint Identity Agents 35
F
File Name Based Server Discovery 84 Firefox 64
G
Generating the Certificate Signing Request 58
Generating the P12 File 58 Getting Started With Identity Awareness 7 Google Chrome 64
H
How AD Query Operates - Firewall Rule Base Example 10 How Captive Portal Operates - Firewall Rule Base 12 How SSO Operates 77 How Transparent Kerberos Authentication Operates 12 How You Download an Endpoint Identity Agent - Example 14 Hyphen 111
I
Identity Agents 12 Identity Awareness Commands 96 Identity Awareness Scenarios 16 Identity Sources 45 Important Information 3 Install Database for a Log Server 53 Installing the Signed Certificate 59 Installing the Terminal Servers Identity Agent 41 Internet Explorer 64 Introduction 7, 66, 82, 90, 96
pdp monitor 97 pdp network 99 pdp status 101 pdp tracker 101 pdp update 102 pep 103 pep debug 105 pep show 103 pep show network 105 pep show pdp 104 pep show stat 105 pep show user 103 Performance 50 Perimeter Security Gateway with Identity Awareness 68 Permissions and Timeout 48 Plus 113 Portal Network Location 32 Prepackaging Endpoint Identity Agent Installation 65 Prepackaging Endpoint Identity Agents 89 Prepackaging Identity Agents 90
Q
Quantifiers 112 Question Marks 113
R
References 77 Regular Expressions 110 Remote Registry 88 Required SmartDashboard Configuration 18, 19, 21, 23 Results of the Wizard 27
K
Kerberos SSO Configuration 76
L
Large Scale Enterprise Deployment 70
M
Making Sure the Strings Shows Correctly 57 Mapping the User Account to a Kerberos Principal Name 61, 78 Metacharacters 110 Multiple Gateway Environments 50
S
Sample INI File 94 Saving New Language Files 56 Scenario Endpoint Identity Agent Deployment and User Group Access 20 Guest Users from Unmanaged Device 19 Identifying Users Accessing the Internet through Terminal Servers 23 Identifying Users in Application Control Logs 23 Laptop Access 16 Recognized User from Unmanaged Device 18 Server Certificates 57 Server Discovery and Trust 38, 82 Session 40 Setting Captive Portal to String ID Help Mode 53 Showing the Language Selection List 56 Single User Assumption 49 SmartDashboard Configuration 62, 80 Source and Destination Fields 31 Specifying Character Types 112 Specifying Domain Controllers per Security Gateway 46 Square Brackets 111 SSO Configuration 78
Page 118
N
Name and Password Login Settings 34 Negate and Block 32 Negate and Drop 30 Nested Groups 50 Network Segregation 71 Non-English Language Support 50
O
Obtaining and Installing a Trusted Server Certificate 58 Option Comparison 84 Overview 76
P
Packet Tagging for Anti-Spoofing 37 Parentheses 111 pdp 97 pdp connections 98 pdp control 99 pdp debug 100
T
Terminal Servers - Users Tab 42 Terminal Servers Advanced Settings 43 test_ad_connectivity 109 Testing Endpoint Identity Agents 68 Testing Identity Sources 67 Transparent Kerberos Authentication Configuration 60 Troubleshooting 51 Troubleshooting - Displaying SRV Record Stored in the DNS Server 88
U
Unregistered Guest Login Settings 35 Use wbemtest to Verify WMI 51 User Access 34 User Experience 18, 20, 21 User identification in the Logs 24 User Identification in the Logs 17, 19, 22 Using Access Roles 17 Using Identity Awareness in the Application and URL Filtering Rule Base 30 Using Identity Awareness in the Firewall Rule Base 29 Using the cpmsi_tool.exe 90
V
Verify the WMI Service 52 Vertical Bar 111 Viewing the Certificate 59
W
What's Next 22 Wireless Campus 74
Page 119

CP R75.40VS IdentityAwareness AdminGuide

Uploaded by

Copyright:

Available Formats

CP R75.40VS IdentityAwareness AdminGuide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CP R75.40VS IdentityAwareness AdminGuide

Uploaded by

Copyright:

Available Formats

Identity Awareness

Getting Started With Identity Awareness

Identity Awareness Administration Guide R75.40VS | 7

Getting Started With Identity Awareness

Identity Awareness Administration Guide R75.40VS | 8

Getting Started With Identity Awareness

Transparent Kerberos Authentication

Identity Awareness Administration Guide R75.40VS | 9

Getting Started With Identity Awareness

See Choosing Identity Sources (on page 45).

How AD Query Operates - Firewall Rule Base Example

Identity Awareness Administration Guide R75.40VS | 10

Getting Started With Identity Awareness

Getting Started With Identity Awareness

How Captive Portal Operates - Firewall Rule Base

How Transparent Kerberos Authentication Operates

Identity Awareness Administration Guide R75.40VS | 12

Getting Started With Identity Awareness

Check Point Endpoint Identity Agent

Getting Started With Identity Awareness

How You Download an Endpoint Identity Agent - Example

Getting Started With Identity Awareness

Identity Awareness Scenarios

Acquiring Identities for Active Directory Users

Scenario: Laptop Access

Identity Awareness Administration Guide R75.40VS | 15

Getting Started With Identity Awareness

User Identification in the Logs

Using Access Roles

Identity Awareness Administration Guide R75.40VS | 16

Getting Started With Identity Awareness

Acquiring Identities with Browser-Based Authentication

Scenario: Recognized User from Unmanaged Device

Required SmartDashboard Configuration

Any http Traffic

Identity Awareness Administration Guide R75.40VS | 17

Getting Started With Identity Awareness

User Identification in the Logs

Scenario: Guest Users from Unmanaged Device

Identity Awareness Administration Guide R75.40VS | 18

Getting Started With Identity Awareness

Required SmartDashboard Configuration

Any http Traffic

ExternalZone Any Traffic

Getting Started With Identity Awareness

Acquiring Identities with Endpoint Identity Agents

Required SmartDashboard Configuration

VPN Any Traffic

Service http https

Getting Started With Identity Awareness

Identity Awareness Administration Guide R75.40VS | 21

Getting Started With Identity Awareness

User Identification in the Logs

Acquiring Identities in a Terminal Server Environment

Acquiring Identities in Application Control

Scenario: Identifying Users in Application Control Logs

Identity Awareness Administration Guide R75.40VS | 22

Getting Started With Identity Awareness

Required SmartDashboard Configuration

User identification in the Logs