Getting Started With Identity Awareness

Introduction

Traditionally, firewalls use IP addresses to monitor traffic and are unaware of the user and computer identities behind those IP addresses. Identity Awareness removes this notion of anonymity since it maps users and computer 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 computer

When Identity Awareness identifies a source or destination, it shows the IP address of the user or computer 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 computers or a firewall rule for a specific user regardless of which computer they send traffic from.

In SmartDashboard, you use Access Role objects to define users, computers and network locations as one object.

Identity Awareness also lets you see user activity in SmartView Tracker and SmartEvent based on user and computer 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

Identity Awareness Security Gateways can share the identity information that they acquire with Identity Awareness Security Gateways. In this way, users that need to pass through many Security Gateways are only identified once. See Advanced Deployment for more information.

Comparison of Acquisition Sources

These tables show 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.

Browser-Based Authentication - Captive Portal

Unidentified users log in with a user name and password in a Captive Portal. After authentication, the user clicks a link to go to the destination address.

AD Query

Gets identity data seamlessly from Active Directory (AD).

Endpoint Identity Agent

A lightweight Endpoint Identity Agent authenticates users securely with Single Sign-On (SSO).

Terminal Servers Endpoint Identity Agent

Identifies multiple users who connect from one IP address. A terminal Server Endpoint Identity Agent is installed on the application server, which hosts the terminal/Citrix services.

Browser-Based Authentication - Transparent Kerberos Authentication

The Transparent Kerberos Authentication Single-Sign On (SSO) solution transparently authenticates users already logged into AD. 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. If Transparent Kerberos Authentication fails, the user is redirected to the Captive Portal for manual authentication.

Remote Access

Users who get access using IPsec VPN Office Mode can authenticate seamlessly.

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 computer) 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 computer 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.

How AD Query Works- Firewall Rule Base

Browser-Based Authentication

Browser-Based Authentication gets identities and authenticates users with one of these acquisition methods:

• Captive Portal
• Transparent Kerberos Authentication

Captive Portal is a simple method that authenticates users with a web interface. When users try to access a protected resource, they enter authentication information in a form that shows in their browser.

Transparent Kerberos Authentication authenticates users by getting authentication data from the browser without any user input. If authentication is successful, the user goes directly to the specified destination. If authentication fails, the user must enter credentials in the Captive Portal.

The Captive Portal shows when a user tries to access a web resource and all of these conditions apply:

• Captive Portal is enabled.
• The redirect option enabled for the applicable rule.
• Firewall or Application and URL Filtering rules block access by unidentified users to resources that would be allowed if they were identified.

The Captive Portal also shows when Transparent Kerberos Authentication is enabled, but authentication fails.

From the Captive Portal, users can:

• Enter their user name and password.
• Enter guest user credentials (Configured in the Portal Settings).
• Click a link to download an Identity Awareness agent (Configured in the Portal Settings).

How Captive Portal Works- Firewall Rule

How Transparent Kerberos Authentication Works

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 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 Endpoint Identity Agent - an Endpoint Identity Agent installed on an application server that hosts Citrix/Terminal services. It identifies individual users whose source is the same IP address.

Using Endpoint Identity Agents gives you:

• User and computer identity
• Minimal user intervention - All necessary configuration steps are 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 computer authentication.

These are the types of Endpoint Identity Agents you can install:

• Full – Predefined Endpoint Identity Agent includes packet tagging and computer authentication. It applies to all users of the computer that it is installed on. Administrator permissions are required to use the Full Endpoint Identity Agent type.
• Light – Predefined Endpoint Identity Agent that does not include packet tagging and computer authentication. You can install this Endpoint Identity Agent individually for each user on the target computer. Administrator permissions are not required.
• Terminal Servers - Predefined Endpoint Identity Agent that installs MAD services and the Multi-user host driver on Citrix and Terminal Servers. This Endpoint Identity Agent type cannot be used for endpoint computers.
• Custom - Configure custom features for all computers that use this agent, such as MAD services and packet tagging.

For more information, see Creating Custom Endpoint Identity Agents.

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).

Downloading Endpoint Identity Agent

This shows how a user downloads the Endpoint Identity Agent from the Captive Portal:

Deployment

Identity Awareness is commonly enabled on a perimeter Security Gateway. It is frequently used in conjunction with Application Control.

To protect internal data centers, Identity Awareness can be enabled on an internal Security Gateway in front of internal servers, such as data centers. This can be in addition to on the perimeter Security Gateway but does not require a perimeter Security 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 Security Gateway acts as a router with different subnets connected to its network interfaces.

For redundancy, you can deploy a Security 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 Security Gateway, you can configure the Security Gateways to share identity information. Common scenarios include:

• Deploy on your perimeter Security Gateway and data center Security Gateway.
• Deploy on several data center Security Gateways.
• Deploy on branch office Security Gateways and central Security Gateways.

You can have one or more Security Gateways acquire identities and share them with the other Security Gateways.

You can also share identities between Security 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, computers and network locations as one object.

Active Directory users that log in and are authenticated will have seamless access to resources based on Firewall 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 Security 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).

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 Security 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 computer 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 shows that 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.

Using Access Roles

To let John Adams access the HR Web Server from any computer, change the rule in the Rule Base. Create an access role for John Adams, from any network and any computer. In the rule, change the source object to be the access role object (for example, HR_Partner).

Install the policy. You can remove the static IP from John Adam's laptop and give it a dynamic IP. The Security Gateway John Adams, defined in the HR_Partner access role, access the HR Web server from his laptop with a dynamic IP.

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.

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 Security 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.
   1. Enter a Name for the Access Role.
   2. In the Users tab, select Specific users and choose Jennifer McHanry.
   3. In the Machines tab make sure that Any machine is selected.
   4. Click OK.

      The Access Role is added to the rule.

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.

User Identification in the Logs

The SmartView Tracker log 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.

Required SmartDashboard Configuration

To make this scenario work, the IT administrator must:

1. Enable Identity Awareness on a Security 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:
   1. If it is not already there, create a rule that identified users can access the internet from the organization.
      1. From the Source of the rule, right-click to create an Access Role.
      2. Enter a Name for the Access Role.
      3. In the Users tab, select All identified users.
      4. Click OK.

      The Access Role is added to the rule.

   2. Create a rule to let Unauthorized Guests access only the internet.
      1. From the Source of the rule, right-click to create an Access Role.
      2. Enter a Name for the Access Role.
      3. In the Users tab, select Specific users and choose Unauthenticated Guests.
      4. Click OK. The Access Role is added to the rule.
      5. Select accept as the Action.
      6. Right-click the Action column and select Edit Properties. The Action Properties window opens.
      7. Select Redirect http connections to an authentication (captive) portal. Note: redirection will not occur if the source IP is already mapped to a user.
      8. Click OK.

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:

• Endpoint Identity Agents as an identity source for Identity Awareness.
• Endpoint Identity Agent deployment for the Finance department group from the Captive Portal. She needs to deploy the Full Endpoint 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 computers 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.

Required SmartDashboard Configuration

To make this scenario work, the IT administrator must:

1. Enable Identity Awareness on a Security Gateway and select Endpoint 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 Endpoint Identity Agent Deployment from the Portal, select Require users to download and select Endpoint Identity Agent - Full option.

   Note - This configures Endpoint Identity Agent for all users. Alternatively, you can set Endpoint Identity Agent download for a specific group.

5. Configure Kerberos SSO.
6. Create a rule in the Firewall Rule Base that lets only Finance department users access the Finance Web server and install policy:
   1. From the Source of the rule, right-click to create an Access Role.
   2. Enter a Name for the Access Role.
   3. In the Networks tab, select Specific users and add the Active Directory Finance user group.
   4. In the Users tab, select All identified users.
   5. In the Machines tab, select All identified machines and select Enforce IP spoofing protection (requires Full Endpoint Identity Agent).
   6. Click OK.

      The Access Role is added to the rule.

7. Install policy.

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 Security 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 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 for more details. In this scenario, the File Name server discovery method is used.
• Access roles to leverage computer 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.

User Identification in the Logs

The SmartView Tracker log shows how the system recognizes a guest.

This log entry shows that the system maps the source IP address with the user 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 Terminal Server 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 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, computer awareness, and application awareness to the Check Point Security 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 R76 Application Control and URL Filtering Administration Guide.

Required SmartDashboard Configuration

To make this scenario work, the IT administrator:

1. Enable the Application Control blade on a Security Gateway.

   This adds a default rule to the Application Control Rule Base that allows traffic from known applications, with the tracking set to Log.

2. Enables Identity Awareness on a Security 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 identity. It also shows Application Control data.

SmartDashboard Toolbar

You can use the SmartDashboard toolbar to do these actions: