Server Discovery and Server Trust

Introduction

The Identity Agent client needs to be connected to an Identity Awareness Gateway. For this to happen, it must discover the server and trust it.

Server discovery refers to the process of deciding, to which server the client should connect. We offer several methods for configuring server discovery – from a very basic method of simply configuring one server to a method of deploying a domain wide policy of connecting to a server based on your current location. This section describes these options.

Server trust refers to the process of validating that the server, to which the end user connects, is indeed a genuine one. It also makes sure that communication between the client and the server was not tampered with by a Man In The Middle (MITM) attack.

The trust process compares the server fingerprint calculated during the SSL handshake with the expected fingerprint. If the client does not have the expected fingerprint configured, it will ask the user to verify that it is correct manually. This section describes the methods that allow the expected fingerprint to be known, without user intervention.

Discovery and Trust Options

These are the options that the client has for discovering a server and creating trust with it:

• File name based server configuration – If no other method is configured (default, out-of-the-box situation), any Identity Agent downloaded from the portal will be renamed to have the portal computer IP in it. During installation, the client uses this IP to represent the Identity Awareness Gateway. Note that the user has to trust the server by himself (the trust dialog box opens).
• AD based configuration – If client computers are members of an Active Directory domain, you can deploy the server addresses and trust data using a dedicated tool.
• DNS SRV record based server discovery – It is possible to configure the server addresses in the DNS server. Because the DNS is not secure, we recommend that you do not configure trust this way. Users can authorize the server manually in a trust dialog box that opens. This is the only server discovery method that is applicable for the MAC OS Identity Agent.
• Remote registry – All client configuration, including the server addresses and trust data are in the registry. You can deploy the values before installing the client (by GPO, or any other system that lets you control the registry remotely). This lets you use the configuration from first run.
• Custom Identity Agents – You can create a custom version of the Identity Agent installation package that includes the server IP and trust data.

Comparing Options

	Requires AD	Manual User Trust Required?	Multi- Site	Client Remains Signed?	Allows Ongoing Changes	Level	Recommended for...
File name based	No	Yes	No	Yes	No	Very Simple	Single Security Gateway deployments
AD based	Yes	No	Yes	Yes	Yes	Simple	Deployments with AD that you can modify
DNS based	No	Yes	Partially (per DNS server)	Yes	Yes	Simple	Deployments without AD or with an AD you cannot modify, but the DNS can be changed
Remote registry	No	No	Yes	Yes	Yes	Moderate	Where remote registry is used for other purposes
Pre- packaging	No	No	Yes	No	No	Advanced	When both DNS and AD cannot be changed, and there is more than one Security Gateway

File Name Based Server Discovery

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

How does it work?

When a user downloads the Identity Agent client from the Captive Portal, the address of the Identity Awareness Gateway is added to the file name. During the installation sequence, the client checks if there is any other discovery method configured (Pre-packaged, AD based, DNS based or local registry). If no method is configured, and the Identity Awareness Gateway can be reached, the Identity Agent will use it. You can make sure that this is the case by looking at the Identity Agent settings and seeing that the Identity Awareness Gateway that is shown in the file name is present in the Identity Agent dialog box.

Why can't we use this for trust data?

As the file name can be changed, we cannot be sure that the file name was not modified by an attacker along the way. Therefore, we cannot trust data passed in the file name as authentic, and we need to verify the trust data by another means.

AD Based Configuration

If your endpoint computers are members of an Active Directory domain, and you have administrative access to this domain, you can use the Distributed Configuration tool to configure connectivity and trust rules for the Identity Agent.

This tool is installed a part of the Identity Agent: go to the Start menu > All Programs > Check Point > Identity Agent.

Note - You must have administrative access to this Active Directory domain to allow automatic creation of new LDAP keys and writing.
The credentials are not saved anywhere, and the access is only required when you modify the distributed configuration. It only writes there when it saves configuration through the distributed configuration tool.

Viewing the configuration is allowed for all users (otherwise the agents themselves would not be able to fetch it).

LDAP keys:

LDAP://CN=PDP,CN=Check Point,CN=Program Data,DC=...<Domain Name>…

LDAP://CN=PDPconnRB,CN=Check Point,CN=Program Data,DC=...<Domain Name>…

The Distributed Configuration tool has three panes:

• Welcome - This pane describes the tool and lets you enter alternate credentials that are used to access the AD.
• Server Configuration - This pane lets you configure, to which Identity Awareness Gateway the Identity Agent should connect, depending on the IPv4 / IPv6 address that is configured on the endpoint computer, or its AD Site.
• Trusted Gateways - This pane lets you view and change the list of fingerprints of Identity Awareness Gateways, which the Identity Agent considers secure.

Note - The complete configuration is written to Active Directory database - under the Program Data branch in a hive named Check Point. This hive is added in the first run of the tool. Adding this hive will not have any effect on other AD based applications or features.

Server Configuration Rules

The Identity Agent fetches the configured rule lists from the Active Directory database. Each time the Identity Agent needs to connect to an Identity Awareness Gateway, it tries to match itself against the rules, from top to bottom.

When the Identity Agent matches a rule, it uses the Identity Awareness Gateways configured in this rule, according to the priority specified.

For example:

This configuration means:

• If the user's computer is configured with the IPv4 address 192.168.0.1 / 24, then the Identity Agent needs to connect to the Identity Awareness Gateway "US-GW1".

  If the gateway "US-GW1" is not available, then the Identity Agent needs to connect to the Identity Awareness Gateway "BAK-GS2" (it will be used only if gateway "US-GW1" is not available, as its priority is higher).

• If the user connects from the Active Directory site "UK-SITE", then the Identity Agent needs to connect to either Identity Awareness Gateway "US-GW1", or Identity Awareness Gateway "UK-GW2" (Identity Agent will choose between these gateways randomly, as they both have the same priority).

  If both of these gateways are not available, then the Identity Agent needs to connect to the Identity Awareness Gateway "BAK-GS2".

• The default rule is that the Identity Agent needs to connect to Identity Awareness Gateway "BAK-GS2" (the default rule is always matched when it is encountered).

Trusted Gateways

The Trusted Gateways pane shows the list of Identity Awareness Gateways considered trusted - no pop-ups will open when the Identity Agent tries to connect to these Identity Awareness Gateways.

You can add, edit or delete a server. If you have connectivity to the Identity Awareness Gateway, you can get the name and fingerprint by entering its address and clicking Fetch Fingerprint. Otherwise, you should enter the same name and fingerprint that is shown when connecting to that Identity Awareness Gateway.

For example:

DNS Based Configuration

If you configure the client to "Automatic Discovery" (the default), it looks for a server by issuing a DNS SRV query for the address "CHECKPOINT_NAC_SERVER._tcp" (the DNS suffix is added automatically). You can configure the address in your DNS server.

On the DNS server (Example is Windows 2003. For more information, see official Microsoft documentation):

1. Go to Start > All Programs > Administrative Tools > DNS.
2. Go to Forward lookup zones and select the applicable domain.
3. Go to the _tcp subdomain.
4. Right-click and select Other new record.
5. Select Service Location, Create Record.
6. In the Service field, enter CHECKPOINT_NAC_SERVER.
7. Set the Port number to 443.
8. In Host offering this service, enter the address of the Identity Awareness Gateway.
9. Click OK.

Note - To define an Identity Awareness Load Sharing, make several SRV records with the same priority. To define an Identity Awareness High Availability, make several SRV records with different priorities.

Note - If you configure AD based and DNS based configuration, the results are combined according to the specified priority (from the lowest to highest).

Troubleshooting - See SRV Record Stored in the DNS Server

1. In Windows Command Prompt, run:

   C:\> nslookup

2. Set query type to SERVER:

   > set type=SRV

3. Query for the checkpoint_nac_server:

   > checkpoint_nac_server._tcp

   Example output:

   Server: dns.company.com
Address: 192.168.0.17

   checkpoint_nac_server._tcp.ad.company.com SRV service location:
priority = 0
weight = 0
port = 443
svr hostname = idserver.company.com

   idserver.company.com internet address = 192.168.1.212

4. To exit, run:

   > exit

Remote Registry

If you have another way to deploy registry entries to your client computers (such as Active Directory GPO updates), you can deploy the Identity Awareness Gateway addresses and trust parameters before you install the clients. Clients will use the already-deployed settings immediately after installation.

To use the remote registry option:

1. Install the client on a computer. Make sure it is installed in the same mode that will be installed on the other computers.

   The full agent installs itself to your Program Files directory and saves its configuration to HKEY_LOCAL_MACHINE.

   The light Identity Agent installs itself to the Users directory and saves its configuration to HKEY_CURRENT_USER.

2. Connect manually to all of the servers that are configured, verify their fingerprints, and click Trust in the fingerprint verification window.
3. In the client Settings window, configure it to connect to the requested servers.

   If let the client choose a server based on location, click Advanced.

4. Export these registry keys (from HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER, according to the client type installed):
   1. SOFTWARE\CheckPoint\IA\TrustedGateways (the whole tree)
   2. SOFTWARE\CheckPoint\IA\ (on 32-bit), or

      SOFTWARE\Wow6432Node\Checkpoint\IA (on 64-bit)

      • DefaultGateway
      • DefaultGatewayEnabled
      • PredefinedPDPConnRBUsed
      • PredefinedPDPConnectRuleBase
5. Deploy the exported keys to the workstations before you install the client on them.