Configuring Identity Awareness

In This Section: Enabling Identity Awareness on the Security Gateway Working with Access Roles Using Identity Awareness in the Rule Base Configuring Browser-Based Authentication in R80 SmartConsole Configuring Terminal Servers

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 see the logs for user and computer identity in the Manage & Settings > Logs tab. You can see events in the Logs & Monitor Access Control views.

To enable Identity Awareness:

1. Log in to R80 SmartConsole.
2. From the Gateways & Servers view, double-click the Security Gateway on which to enable Identity Awareness.
3. On the Network Security tab, select Identity Awareness.

   The Identity Awareness Configuration wizard opens.

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

   These are the methods of acquiring identities you can choose in the wizard. However, other identity sources are supported.

   Note - When you enable Browser-Based Authentication on an IPSO 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.

5. Click Next.

   The Integration with Active Directory window opens.

   When the R80 SmartConsole client computer is part of the AD domain, R80 SmartConsole 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 the R80 SmartConsole computer is part of the domain, the Wizard fetches all the domain controllers of the domain and all of the domain controllers are configured

   If you create a new domain, and the R80 SmartConsole computer is not part of the 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, open Object Explorer (Ctrl + E), and select Servers > LDAP Account units in the Categories tree.

   The LDAP Account Unit name syntax is: <domain name>_ _ AD

   For example, CORP.ACME.COM_ _ AD.

6. 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.
7. 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.
8. 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.
9. Click Next.

   If you selected Browser-Based Authentication on the first page, the Browser-Based Authentication Settings page opens.

10. 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 - 192.0.2.2/connect
    • DLP Portal - 192.0.2.2/DLP
    • Mobile Access Portal - 192.0.2.2/sslvpn
11. 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.
12. 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.

13. Click Finish.
14. Select Install Policy (Ctrl+Shift+Enter).

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:

• Networks
• Users and user groups
• Computers and computer groups
• Remote Access Clients

To create an Access Role object:

1. In R80 SmartConsole, open the Object Explorer (Ctrl+E).
2. Click New > Users > Access Role.

   The New Access Role window opens.

3. Enter a Name and Comment (optional).
4. On the Networks page, select one of these:
   • Any network
   • Specific networks - Click the plus sign and select a network - click the plus sign next to the network name or search for a known network
5. On the Users page, select one of these:
   • Any user
   • All identified users - Includes users identified by a supported authentication method.
   • Specific users - Click the plus sign and select a user - click the plus sign next to the username or search for a known user or user group.
6. On the Machines page, select one of these:
   • Any machine
   • All identified machines - Includes computers identified by a supported authentication method
   • Specific machines - Click the plus sign and select a device - click the plus sign next to the device name or search for a known device or group of devices

   For computers that use Full Endpoint Identity Agents, you can select (optional) Enforce IP Spoofing protection.

7. On the Remote Access Clients page, select the Allowed Clients or add new ones. For R77.xx Gateways or lower, you must choose Any.
8. Click OK.

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 LDAP group update:

1. From the Security Gateway command line, run:

   adlogconfig a

   The adlog status screen and menu opens.

2. Select Turn LDAP groups update on/off.

   LDAP groups update notifications status changes to [ ] (not active). If you enter Turn LDAP groups update on/off when automatic LDAP group update is not active, LDAP groups update notifications status changes to [X] (active).

3. Enter 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 the Notifications accumulation time to set the time between LDAP change notifications.
3. Enter the time between notifications in seconds (default = 10).
4. Enter Update only user-related LDAP changes to/not to send notifications only for user related changes.

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

5. Enter Exit and save to save these settings and close the adlogconfig tool.
6. Install policy.

Automatic LDAP Group Update 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 LDAP Groups. 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 LDAP Group Update assignments immediately. This action can cause Identity Awareness to work slower.

To deactivate the LDAP cache:

1. In R80 SmartConsole, go to Menu > 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 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 enable 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. The packet is matched according to the other fields in the rule. After the system gets the credentials from the Captive Portal, it can examine the rule for the next connection.

In rules with access role objects, criteria matching 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 action.
  • If it does not match an access role, the next rule is examined.
• When identity data for an IP is unknown and:
  • All rule fields match, other than 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 - 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.

To redirect http traffic to the Captive Portal:

1. In a policy rule that uses an access role in the Source column, right-click the Action column and select More.

   The Action Settings window opens.

2. Select the Enable Identity Captive Portal.
3. Click OK.

   The Action column shows that a redirect to the Captive Portal occurs.

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

No.	Source	Destination	Services & Applications	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	Services & Applications	Action
IT and Sales File Sharing	IT_dept	Sales_dept	Any	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 word [Negated] is added to the cell.

Source	Destination	VPN	Services & Applications	Action
Temp_employees [Negated]	Intranet_web_server	Any	http	accept

To prevent access to unidentified users, add another rule that ensures that only identified employees are allowed access.

Source	Destination	VPN	Services & Applications	Action
Temp_employees	Intranet_web_server	Any	http	drop
Any_identified_employee	Intranet_web_server	Any	http	accept

Configuring Browser-Based Authentication in R80 SmartConsole

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.

If you already configured the portal in the Identity Awareness Wizard or R80 SmartConsole, 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

     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 Wizard.
     • Aliases - Click the Aliases button to Add URL aliases that are redirected to the main portal URL. For example, ID.yourcompany.com can send users to the Captive Portal. To make the alias work, it must be resolved to the main URL on your DNS server.
     • Certificate - Click Import to import a certificate for the portal website to use. If you do not import a certificate, the portal uses a Check Point auto-generated certificate. This might cause browser warnings if the browser does not recognize Check Point as a trusted Certificate Authority. See Server Certificates 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.
       • IP Address: The IP address to which the Portal URL is resolved if DNS resolution fails.

       Notes:

       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.

       The IP Address option only shows when you select Browser-based Authentication as an identity source.

     • Authentication Method - Select one method that known users must use to authenticate.
       • Defined on user record (Legacy Authentication) - Takes the authentication method from Gateway Object Properties > Other > Legacy Authentication.
       • User name and password - This can be configured internally or on an LDAP server.
       • RADIUS - A configured RADIUS server. Select the server from the list.
     • User Directories - Select one or more places where the 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.
   • 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 instead of 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 will only be able to access the network if they install the Endpoint Identity Agent.
     • Users may defer installation until - Select this if you want to give users flexibility to choose when they install the Endpoint Identity Agent. Select the date by which they must install it. Until that date a Skip Endpoint Identity Agent installation option shows in the Captive Portal.

Note - When you enable Browser-Based Authentication on an IPSO 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.

Configuring Terminal Servers

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 R80 SmartConsole, you can automatically generate a shared secret that matches these conditions.

To configure the shared secret on the Identity Server:

1. Log in to R80 SmartConsole.
2. From the Gateways & Servers view, double-click the Check Point Security Gateway that has Identity Awareness enabled.
3. Go to the Identity Awareness page.
4. In the Identity Sources section, select Terminal Servers and click Settings.
5. 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.
6. 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.