Print Download PDF Send Feedback

Previous

Next

Server Discovery and Server Trust

Introduction

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

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 Endpoint 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 Endpoint Identity Agent will use it. You can make sure that this is the case by looking at the Endpoint Identity Agent settings and seeing that the Identity Awareness Gateway that is shown in the file name is present in the Endpoint 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 Endpoint Identity Agent.

This tool is installed a part of the Endpoint 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:

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 Endpoint Identity Agent fetches the configured rule lists from the Active Directory database. Each time the Endpoint Identity Agent needs to connect to an Identity Awareness Gateway, it tries to match itself against the rules, from top to bottom.

When the Endpoint 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:

Trusted Gateways

The Trusted Gateways pane shows the list of Identity Awareness Gateways considered trusted - no pop-ups will open when the Endpoint 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 Endpoint 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.