Getting Started With Identity Awareness

In This Section: Introduction Deployment Identity Awareness Default Ports Identity Awareness Scenarios SmartDashboard Toolbar

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

In Advanced Deployment, you can configure Identity Awareness Security Gateways to share the data that they acquire. Users that need to pass through many Security Gateways are only identified once.

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.

Recommended Usage	Deployment Considerations
Identity based enforcement for non-AD users (non-Windows and guest users) You can require deployment of Endpoint Identity Agents	Used for identity enforcement (not intended for logging purposes).

AD Query Gets identity data seamlessly from Active Directory (AD).

Recommended Usage	Deployment Considerations
Identity based auditing and logging Leveraging identity in Internet application control Basic identity enforcement in the internal network	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. Preferred for desktop users Only detects AD users and computers

Endpoint Identity Agent

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

Recommended Usage	Deployment Considerations
Identity enforcement for Data Centers Protecting highly sensitive servers When accuracy in detecting identity is crucial	See Choosing Identity Sources.

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.

Recommended Usage	Deployment Considerations
Identify users who use Terminal Servers or a Citrix environment.	See Choosing Identity Sources.

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.

Note -The Endpoint Identity Agent download link and the Automatic Logout option are ignored when Transparent Kerberos Authentication SSO is successful. The user does not see the Captive Portal.

Recommended Usage	Deployment Considerations
In AD environments, when known users are already logged in to the domain.	Used for identity enforcement only (not intended for logging purposes) Transparent Kerberos Authentication does not use Endpoint Identity Agents or the Automatic Logout feature.

RADIUS Accounting

You can configure a Security Gateway with Identity Awareness to use RADIUS Accounting to get user and computer identities directly from a RADIUS accounting client. Identity Awareness uses this information to apply access permissions to the connection.

RADIUS Accounting gets identity data from RADIUS Accounting Requests generated by the RADIUS accounting client. Identity Awareness uses the data from these requests to get user and device group information from the LDAP server. Firewall rules apply these permissions to users, computers and networks.

Recommended Usage	Deployment Considerations
In environments where authentication is handled by a RADIUS server.	You must define the Security Gateway as a RADIUS accounting client. You must give the RADIUS client access permissions and create a shared secret.

Remote Access

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

Recommended Usage	Deployment Considerations
Identify and apply identity-based security Policy on users that access the organization through VPN.	See Choosing Identity Sources.

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

Item	Description
	Security Gateway
	Active Directory domain controller
1	The Security Gateway gets security event logs from the Active Directory domain controllers.
2	A user logs in to a computer with Active Directory credentials.
3	The Active Directory domain controller sends the security event log to the Security Gateway. The Security Gateway gets the user and IP information (user name@domain, computer name and source IP address).
4	The user connects to the Internet.
5	The Security Gateway confirms the user identification and lets him access the Internet based on the policy.

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 Control 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

Item	Description
	Security Gateway with Identity Awareness
	Active Directory domain controller
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 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 go to the Security Gateway, which finds them in the AD server.
5	The user can access the requested URL.

How Transparent Kerberos Authentication Works

Flow of events for Browser-Based Authentication with Transparent Kerberos Authentication:

1. A user wants to access the Internal Data Center.
2. Identity Awareness Gateway does not recognize the user and redirects the user's web browser to the Transparent Authentication page.
3. The Transparent Authentication page asks the web browser to authenticate itself.
4. The web 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 Identity Awareness Gateway, which authenticates the user and redirects the user's web browser to the originally requested URL.
6. If Kerberos authentication fails for some reason, Identity Awareness Gateway redirects the user's web browser to the Captive Portal.

Identity Agents

There are different 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 do 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.

You can install these Endpoint Identity Agent types:

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

Users can download and install Endpoint Identity Agents from the Captive Portal, or you can distribute MSI or DMG files to computers with distribution software or a download link.

Downloading Endpoint Identity Agent

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

Item	Description
	Security Gateway with Identity Awareness
	Active Directory domain controller
1	A user logs in to a computer with credentials, to access the Internal Data Center.
2	The Security Gateway with Identity Awareness does not recognize the user and redirects to the Captive Portal.
3	The user sees the Portal page, with a link to download the Endpoint Identity Agent.
4	The user downloads the Endpoint Identity Agent from the Captive Portal and installs it.
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 Software Blade is commonly enabled on a perimeter Security Gateway. It is frequently used in conjunction with Application Control Software Blade.

To protect internal data centers, Identity Awareness Software Blade can be enabled on an internal Security Gateway located in front of internal servers, such as data centers. This can be done in addition to the perimeter Security Gateway, but does not require a perimeter Security Gateway.

Identity Awareness can be deployed in Bridge mode or Route mode.

• In the Bridge mode, it can use an existing subnet with no change to the hosts' IP addresses.
• In the Route mode, the Security Gateway acts as a router with different subnets connected to its network interfaces.

For redundancy, you can deploy a cluster of Identity Awareness Security Gateways in High Availability or Load Sharing modes.

If you deploy several Identity Awareness Security Gateways in your environment and configure them to share identity information. Common scenarios include:

• Enable Identity Awareness Software Blade on your perimeter Security Gateway and on data center Security Gateway.
• Enable Identity Awareness Software Blade on several data center Security Gateways.
• Enable Identity Awareness Software Blade on branch office Security Gateways and central Security Gateways.

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

You can also share identities between Identity Awareness Gateways that are managed in different Multi-Domain Servers.

Identity Awareness Default Ports

This section shows the default ports used by Identity Awareness features:

Feature	Port
LDAP	389
LDAP over SSL	636
AD Query	135
Global Catalog	3268
Global Catalog over SSL	3269
Gateway to AD	135, 389
AD to gateway	135
Enforcement gateway	389
Identity Sharing gateway to Enforcement gateway	15105, 28581
Browser-based Authentication	443
Identity Agents/Terminal Server Agents	443
Radius Accounting	1813

It is possible to configure these features to different ports. For more information about Identity Awareness ports, see sk98561 and sk52421.

Identity Awareness Scenarios

This section describes scenarios in which you can use Identity Awareness to let users access network resources.

The first few 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 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, create rules in the Firewall Rule 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.

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

Name	Source	Destination	VPN	Service	Action	Track
Jadams to HR Server	Jadams_PC	HR_Web_Server	Any Traffic	Any	accept	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 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 James Wilson as the user behind IP 10.0.0.19. This log entry shows that the system maps the source IP to the user James Wilson 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 James Wilson is not identified (the IT administrator does not see the log), he should lock and unlock the computer.

Using Access Roles

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

Name	Source	Destination	VPN	Services & Applications	Action	Track
HR Partner Access	HR_Partner	HR_Web_Server	Any	Any	accept	None

Install the policy. You can remove the static IP from the laptop of James Wilson and give it a dynamic IP. The Security Gateway James Wilson, 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, select Browser-Based Authentication as one of the Identity Sources, and click Settings.
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.

Name	Source	Destination	VPN	Service	Action	Track
CEO Access	Jennifer_McHanry	Finance_Server	Any Traffic	http	accept (display captive portal)	Log

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 an Access Role rule in the Firewall Rule Base, to let identified users access the Internet from the organization:
   1. Right-click Source and select Access Role.
   2. In the Users tab, select All identified users.
6. Create an Access Role rule in the Firewall Rule Base, to let Unauthorized Guests access only the Internet:
   1. Right-click Source and select Access Role.
   2. In the Users tab, select Specific users > Unauthenticated Guests.
   3. Select accept as the Action.
   4. Right-click the Action column and select Edit Properties. The Action Properties window opens.
   5. Select Redirect http connections to an authentication (captive) portal. Note: redirection will not occur if the source IP is already mapped to a user.
   6. 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 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.

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 Identity Awareness Gateway, with the File name based server discovery option. There are other server discovery methods, which 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 time.

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.

What's Next

Other options that can be configured for Endpoint Identity Agents:

• A method that determines how Endpoint Identity Agents connect to an Identity Awareness Gateway and trusts it. 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.

  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 Security Gateway access the network after they enter required data.

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 gateway.
• 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

You can use the Identity Awareness and Application Control and URL Filtering together to add user awareness, computer awareness, and application awareness to the Check Point Security Gateway. They work together in these procedures:

• In the Access Control Policy Layer with the Application Control and URL Filtering Software Blade enabled, use Identity Awareness Access Roles 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 logs and 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 R77 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:

Icon	Description
	Open the SmartDashboard menu. When instructed to select menu options, click this button to show the menu. For example, if you are instructed to select Manage > Users and Administrators, click this button to open the Manage menu and then select the Users and Administrators option.
	Save current policy and all system objects.
	Open a policy package, which is a collection of Policies saved together with the same name.
	Refresh policy from the Security Management Server.
	Open the Database Revision Control window.
	Change global properties.
	Verify Rule Base consistency.
	Install the policy on Security Gateways or VSX Gateways.
	Open SmartConsole.