Configuring Identity Awareness

In This Section: Enabling Identity Awareness on the Security Gateway Working with Access Roles Using Identity Awareness in the Firewall Rule Base Using Identity Awareness in the Application Control and URL Filtering Rule Base Configuring Browser-Based Authentication in SmartDashboard Configuring Endpoint Identity Agents Configuring Terminal Servers Working with RADIUS Accounting Configuring Remote Access Configuring Identity Logging for a Log Server

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 Security Gateway environment or to configure Endpoint 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 computer identity.

To enable Identity Awareness:

1. Log in to SmartDashboard.
2. From the Network Objects tree, expand the Check Point branch.
3. Double-click the Security Gateway on which to enable Identity Awareness.
4. 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.

   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 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 Security Gateway show in the list. The IP address selected by default is the Security Gateway main IP address>. The same IP address can be used for other portals with different paths. For example:

    • Identity Awareness Browser-Based Authentication - 143.100.75.1/connect
    • DLP Portal - 2.2.2.2/DLP
    • Mobile Access Portal - 2.2.2.2/sslvpn
12. 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 Security Gateway.
13. 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.

14. Click Finish.
15. 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.
• Configure Terminal Servers, if you have installed them.

Working with Access Roles

After you enable Identity Awareness, you create Access Role objects.

You can use Access Role objects as source and/or destination parameter in a rule. Access role objects can include one or more of these objects:

• Users and user groups
• Computers and computer groups
• Networks

To create an Access Role object:

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. In the Networks tab, select one of these:
   • Any network
   • Specific networks - Click the plus sign and select a network.

     Your selection is shown in the Networks node in the Role Preview pane.

5. In the Users tab, select one of these:
   • Any user
   • All identified users - Includes users identified by a supported authentication method (internal users, AD 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.

6. In the Machines tab, select one of these:
   • Any machine
   • All identified machines - Includes computers identified by a supported authentication method (AD).
   • Specific machines - Click the plus sign.

     You can search for AD entries or select them from the list.

7. Optional: For computers that use Full Endpoint Identity Agents, from the Machines tab select Enforce IP Spoofing protection.
8. Click OK.

   The access role is added to the Users and Administrators tree.

Automatic LDAP Group Update

Identity Awareness automatically recognizes changes to LDAP group membership and updates identity information, including access roles.

When you:

• Add an LDAP group to another LDAP group
• Remove an LDAP group from another LDAP group
• Move an LDAP from one LDAP group to another

The system recalculates LDAP group membership for ALL users in ALL Groups. Be very careful when you deactivate user-related notifications.

LDAP Group Update is activated by default. You can manually deactivate LDAP Group Update with the CLI.

Important - Automatic LDAP group update works only with Microsoft Active Directory when AD Query is activated.

To deactivate automatic access role assignment:

1. From the Security Gateway command line, run:

   adlogconfig a

   The adlog status screen and menu opens.

2. Select 26 - Turn LDAP groups update on/off.

   LDAP groups update notifications status changes to [ ] (not active). If you enter 26 when automatic access role assignment is not active, LDAP groups update notifications status changes to [X ] (active).

3. Enter 31 - Exit and save to save this setting and close the adlogconfig tool.
4. Install policy.

You can use adlogconfig to set the time between LDAP change notifications and to send notifications only for user related changes.

To configure LDAP group notification options:

1. From the Security Gateway command line, run:

   adlogconfig a

   The adlog status screen and menu opens.

2. Enter 27 - Turn LDAP groups update on/off to set the time between LDAP change notifications.
3. Enter the time between notifications in seconds (default = 10).
4. Enter 28 - Update only user-related LDAP changes to/not to send notifications only for user related changes.

   Be very careful when you deactivate user-related notifications. This can cause excessive gateway CPU load.

5. Enter 31 - Exit and save to save these settings and close the adlogconfig tool.
6. Install Policy

Automatic access role assignment does not occur immediately because Identity Awareness looks for users and groups in the LDAP cache first. The information in the cache does not contain the updated access role. By default, the cache contains 1,000 users and cached user information is updated every 15 minutes.

You must deactivate the LDAP cache to get automatic access role assignments immediately. This action can cause Identity Awareness to work slower.

To deactivate the LDAP cache:

1. In SmartDashboard, go to Policy> Global Properties > User Directory.
2. Change Timeout on cached users to 0.
3. Change Cache size to zero.
4. Install policy.

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 works like this:

• When identity data for an IP is known:
  • If it matches an access role, the rule is enforced and traffic is allowed or blacked based on the action.
  • If it does not match an access role, it goes on to examine the next rule.
• When identity data for an IP is unknown and:
  • All rule 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.

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.

This is an example of a Firewall Rule Base that describes how matching operates:

No.	Source	Destination	Service	Action
1	Finance_Dept (Access Role)	Finance_Web_ Server	Any	Accept (display Captive Portal)
2	Admin_IP	Any	Any	Accept
3	Any	Any	Any	Drop

Example 1 - If an unidentified Finance user tries to access the Finance Web Server with http, a redirect to the Captive Portal occurs. After the user enters credentials, the Security 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 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

You can use Access Role objects as 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	Source	Destination	VPN	Service	Action
IT and Sales File Sharing	IT_dept	Sales_dept	Any Traffic	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	Destination	VPN	Service	Action
Temp_employees	Intranet_web_server	Any Traffic	http	accept

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	Destination	VPN	Service	Action
Temp_employees	Intranet_web_server	Any Traffic	http	drop
Any_identified_employee	Intranet_web_server	Any Traffic	http	accept

Using Identity Awareness in the Application Control and URL Filtering Rule Base

The Security Gateway inspects Application Control 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. When 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 works like this:

• When identity data for an IP is known:
  • If it matches an access role, the rule is enforced and traffic is allowed or blocked based on the specified action.
  • If it does not match an access role, it goes on to examine the next rule.
• When identity data for an IP is unknown and:
  • All rule 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 do not match any of the rules in the Rule Base, the traffic is allowed.

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.

This is an example of an Application Control and URL Filtering Rule Base that shows how criteria matching operates:

No.	Source	Destination	Service	Applications/Sites	Action
1	Finance_Dept (Access Role)	Internet	Any	Salesforce	Allow (display Captive Portal)
2	Any_identified_user (Access Role)	Internet	Any	Remote Administration Tool (non-HTTP category)	Allow
3	Any_identified_user (Access Role)	Internet	Any	Any recognized	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 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	Destination	Application	Action
Temp_employees	Internet	Any Recognized	Block
Any_identified_employee	Internet	Any Recognized	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.

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
   • Endpoint 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 Security Gateway or a different Identity Awareness enabled Security Gateway. The default is that the Captive Portal is on the Security Gateway. The Security Gateway redirects unidentified users to the Captive Portal on the same Security Gateway. This is the basic configuration.

A more advanced deployment is possible where the portal runs on a different Security 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 Configuration 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 can cause browser warnings if the browser does not recognize Check Point as a trusted Certificate Authority. See Server Certificates 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 Security 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 computers in the domain if Transparent Kerberos Authentication is used to identify users.
  • Main URL: The URL used to begin the SSO process. If transparent authentication fails, users are redirected to the configured Captive Portal. This URL contains the DNS name or IP address of Identity Awareness Gateway.

  Note - The Endpoint Identity Agent download link and the Automatic Logout option are ignored when Transparent Kerberos Authentication SSO is successful. This is so because users do not see the Captive Portal.

• 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 Security 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 Security 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	Name	To do in GUI
1	Portal Title	Enter the title of the portal. The default title is Network Access Login.
2	Company Logo	Select Use my company logo and Browse to select a logo image for the portal.
2	Company Logo for mobiles	Select Use my company logo for mobiles and Browse to select a smaller logo image for users who access the portal from mobile devices.

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.

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 for each user group are:
  • If they must accept a user agreement.
  • If they must download an Endpoint Identity Agent and which one.
  • If they can defer the Endpoint Identity Agent installation and until when.

  You can only configure settings for Endpoint Identity Agent deployment if Endpoint 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.

Endpoint Identity Agent Deployment from the Portal

If Endpoint Identity Agents is selected as a method to acquire identities, you can require users to download the Endpoint Identity Agent from the Captive Portal. You can also let users install the Endpoint Identity Agent on a specified later date and not right away.

• 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 are not able to access the network if they install the Endpoint Identity Agent.
• Users may defer installation until - Select to give users flexibility to choose when to install the Endpoint Identity Agent. Select the date by which they must install it. Until that date a Skip Endpoint Identity Agent installation option shows in the Captive Portal.

Configuring Endpoint Identity Agents

Endpoint Identity Agents are dedicated client agents installed on user computers that acquire and report identities to the Security Gateway. As the administrator, you, not the users, configure the Agents.

Before you configure Endpoint Identity Agents, consider these elements:

• Endpoint Identity Agent type - Full Endpoint Identity Agent, Light Endpoint Identity Agent or Custom Endpoint Identity Agent. For the Full Endpoint Identity Agent you can enforce IP spoofing protection. For the Full Endpoint Identity Agent you can also leverage computer authentication if you define computers in access roles. The Custom Endpoint Identity Agent is a customized installation package.
• Installation deployment methods- You can deploy the Endpoint 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 Endpoint Identity Agent can connect to a Security Gateway with Identity Awareness, the Endpoint 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) - Endpoint Identity Agents installed on endpoint computers authenticate users automatically when they log in to the domain using SSO.

  The Endpoint 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.

Endpoint Identity Agent Types

These are the Endpoint Identity Agent types that 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 Prepackaging Endpoint Identity Agents.

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.

Computer identification - You get computer identification when you use the Full Endpoint Identity 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 Endpoint Identity Agent as it requires installing a driver.

This table shows the similarities and differences of the Light and Full Endpoint Identity Agent types.

		Endpoint Identity Agent Light	Endpoint Identity Agent Full
Installation Elements	Endpoint Identity Agent format	Resident application	Resident application + service + driver
	Installation permissions	None	administrator
	Upgrade permissions	None	None
Security Features	User identification	SSO	SSO
	Computer identification	No	Yes
	IP change detection	Yes	Yes
	Packet tagging	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 Security 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 Endpoint Identity Agent.

For details, see Packet Tagging.

To enable IP Spoofing protection:

1. Make sure users have the Full Endpoint Identity Agent installed.
2. Create an Access Role.
3. In the Machines tab, select Enforce IP spoofing protection (requires full Endpoint Identity Agent).
4. Click OK.

Endpoint Identity Agent Deployment Methods

There are different Endpoint Identity Agent deployment methods:

• Using Captive Portal - You can require users to download the Endpoint Identity Agent from the Captive Portal. You can also let users install the Endpoint Identity Agent on a specified later date instead of right away. During installation, the Endpoint Identity Agent automatically detects if there are administrator permissions on the computer or not and installs itself accordingly.

  Note - When you deploy the Full Endpoint Identity Agent, the user that installs the client must have administrator rights on the computer. If the user does not have administrator permissions, the Light Endpoint Identity Agent is installed instead.

  Note - When users authenticate with the transparent portal, the download link does not show. They must install the agent from the distribution media.

• Using distribution software - You can deploy the Endpoint Identity Agent with distribution software. The msi installation files (Light and Full) can be found in $NACPORTAL_HOME/htdocs/nac/nacclients/customAgent.msi on the gateway.

Configuring Endpoint Identity Agent Deployment from Captive Portal

To configure Endpoint Identity Agent deployment from Captive Portal:

1. From the Identity Awareness page, select the Endpoint 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 Endpoint Identity 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 Endpoint 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

With Server Discovery, the Endpoint Identity Agent finds the Security Gateway with Identity Awareness to connect to. There are several methods to configure this. The basic method is to configure one server. Or, you can deploy a domain-wide Policy, to connect to a Security Gateway with Identity Awareness, based on the Endpoint Identity Agent client current location.

Server Trust makes sure that the Endpoint Identity Agent connects to a genuine Security Gateway with Identity Awareness. It makes sure that the communication between the Endpoint Identity Agent and the Security Gateway is secure. For example, Server Trust blocks man-in-the-middle attacks.

Trust is made with when the server fingerprint matches the expected fingerprint, as calculated during the SSL handshake.

There are different server discovery and trust methods:

• File name based server configuration - If no other method is configured (out of the box situation), the Endpoint Identity Agent downloaded from the Captive Portal is renamed to include the Captive Portal computer IP address in it. During installation, the Endpoint Identity Agent uses this IP for the Security Gateway with Identity Awareness. Users manually accept the server in a Trust window.
• AD based configuration – If the Endpoint Identity Agent computers are members of an Active Directory domain, deploy the server addresses and trust data with a dedicated "Distributed Configuration" tool.
• DNS SRV record based server discovery – Configure the Security Gateway with Identity Awareness addresses in the DNS server. Users manually accept the server in a Trust window.

  Note - The only server discovery method for the MAC OS Endpoint Identity Agent.

• Remote registry – All client configurations, including Identity Server addresses and trust data, is in the registry. Deploy these values before installing the client (by GPO, or other method that lets you remotely control the registry). The Endpoint Identity Agent uses the data immediately.
• Prepackaging Custom Endpoint Identity Agents– Create a custom version of the Endpoint Identity Agent installation that comes with the Security Gateway with Identity Awareness.

Configuring Endpoint Identity Agents in SmartDashboard

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

To configure the Endpoint Identity Agent settings:

1. Select Endpoint Identity Agents and click Settings.
2. From the Endpoint Identity Agents Settings window, configure:
   • Endpoint Identity Agent Access
   • 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 computers in the domain if Transparent Kerberos Authentication is used to identify users.
       • Main URL: The URL used to begin the SSO process. If transparent authentication fails, users are redirected to the configured Captive Portal. This URL contains the DNS name or IP address of Identity Awareness Gateway.

       Note - The Endpoint Identity Agent download link and the Automatic Logout option are ignored when Transparent Kerberos Authentication SSO is successful. This is so because users do not see the Captive Portal.

     • 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 Security 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 Security Gateway performance when users authenticate. Users with identical user names must log in with domain\user.

   • Session details
   • Endpoint Identity Agent Upgrades

Endpoint Identity 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 Security 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.

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 re-authenticate 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 Endpoint Identity Agent login window.

Endpoint Identity 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 Endpoint Identity 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 you install or upgrade the Full Endpoint Identity Agent version, the user will experience a momentary loss of connectivity.

Troubleshooting Authentication Issues

Some users cannot authenticate with the Endpoint Identity Agent

This issue can occur in Kerberos environments with a very large Domain Controller database. The authentication failure occurs when the CCC message size is larger than the default maximum size. You can increase the maximum CCC message size to prevent this error.

To increase the maximum CCC message size, use the procedure in sk66087.

Transparent Portal Authentication fails for some users

This issue can occur for users that try to authenticate with Kerberos authentication with the transparent portal. The user sees a 400 Bad Request page with this message:

Your browser sent a request that this server could not understand.

Size of a request header field exceeds server limit.

The authentication failure occurs because the HTTP request header is larger than the default maximum size. You increase the maximum HTTP request header to prevent this error.

To increase the maximum HTTP request header size, use the procedure in sk92802.

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.

Deploying the Terminal Servers Identity Awareness Solution

To deploy Terminal Servers Endpoint Identity Agent:

• Install a Terminal Servers Endpoint Identity Agent - You install this agent on the application server that hosts the Terminal/Citrix services after you enable the Terminal Servers identity source in the Identity Awareness Gateway object and install the Access Policy.

  Go to the link https://<Gateway_IP_Address>/_IA_MU_Agent/download/muhAgent.exe

  Make sure you open the link from a location defined in the Terminal Servers Accessibility setting (Identity Awareness Gateway properties > Identity Awareness > Terminal Servers > Settings > Edit).

• Configure a Shared Secret - You must configure the same password on the Terminal Servers Endpoint Identity Agent and the Identity Awareness Gateway. This password is used to secure the established trust between them.

Installing the Terminal Servers Endpoint Identity Agent

The Terminal Servers Endpoint 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 Endpoint Identity Agent from a link in SmartDashboard.

To download the Terminal Servers Endpoint 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 Endpoint Identity Agent link. Make sure you open the link from a location defined in the Accessibility setting (Terminal Servers > Settings > Edit).
4. Install the Endpoint Identity Agent on the Terminal Server.

Upgrading a Terminal Servers Endpoint Identity Agent

There is no option to upgrade the Terminal Servers Endpoint Identity Agent when you upgrade a Security Gateway to a newer version. You must manually install the new version of the Terminal Servers Endpoint Identity Agent on the Citrix or Terminal Server.

Configuring the Shared Secret

You must configure the same password as a shared secret in the Terminal Servers Endpoint 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:
   1. Click Generate to automatically get a shared secret that matches the string conditions.

      The generated password is shown in the Pre-shared secret field.

   2. Click OK.
5. To manually configure the shared secret:
   1. Enter a password that matches the conditions in the Pre-shared secret field. Note the strength of the password in the Indicator.
   2. Click OK.

To configure the shared secret on the application server:

1. Open the Terminal Servers Endpoint 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. Log in to SmartConsole.
2. From the left Navigation Toolbar, click GATEWAYS & SERVERS.
3. Double-click the Check Point Security Gateway that has Identity Awareness enabled.
4. In the left tree, go to the Identity Awareness page.
5. Click Terminal Servers - Settings.
6. In the Accessibility section, click Edit to select from where the Terminal Servers Endpoint 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 Endpoint 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	Description
ID	The SID of the user.
User	The user and domain name. The format used: <domain>\<user>
TCP Ports	The ports allocated to the user for TCP traffic.
UDP Ports	The ports allocated to the user for TCP traffic.
Authentication Status	Indicates whether this user is authenticated on the gateway.

The ID and User field information is automatically updated from processes running on the application server. The Terminal Servers Endpoint Identity Agent assigns TCP and UDP port ranges for each connected user.

Multi User Host 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. Best Practice - We highly recommend that you keep the default values if you are not an advanced user.

Changes are applied to new users that log in to the application server after the settings are saved. Users that are currently logged in, will stay with the older settings.

Advanced Setting	Description
Excluded TCP Ports	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).
Excluded UDP Ports	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).
Maximum Ports Per User	The maximum number of ports that can be assigned to a user in each of the TCP and UDP port ranges.
Ports Reuse Timeout (seconds)	The number of seconds the system waits until it assigns a port to a new user after it has been released by another user.
Errors History Size	N/A
Gateway Shared Secret	The same password that is set on the gateway that enables trusted communication between the Security Gateway and the application server.

Working with 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.

How RADIUS Accounting Works with Identity Awareness

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.

Item	Description
1	User devices
2	Security Gateway with Identity Awareness configured as a RADIUS Accounting server
3	RADIUS authentication server with RADIUS Accounting client enabled
4	RADIUS Accounting request
5	User identity information
6	LDAP server
7	Protected resources

Enabling RADIUS Accounting on a Security Gateway

You must enable RADIUS Accounting on Security Gateways before they can work as a RADIUS Accounting server.

To enable RADIUS Accounting for a Security Gateway:

1. In the SmartDashboard Network Objects tree, open the Security Gateway.
2. On the General Properties page, make sure that the Identity Awareness Blade is enabled.
3. On the Identity Awareness page, select RADIUS Accounting.