Identity Awareness Deployment

In This Section: Identity Sharing Configuring Identity Awareness for a Domain Forest (Subdomains) Non-English Language Support Nested Groups Configuring Identity Awareness Gateway as Active Directory Proxy

Identity Sharing

Best Practice - In a distributed environment with multiple Identity Awareness Security Gateways and AD Query, we recommend to consider Identity Sharing configuration.

In this configuration, Identity Awareness Security Gateways can share the identity information that they acquire with other Identity Awareness Security Gateways. You can configure Identity Sharing across multiple Security Gateways if the gateways have Identity Awareness enabled.

Use-case scenario without the Identity Sharing (sk149255):

• Connectivity:

  Identity Agents can be connected to only one Identity Awareness Security Gateway. If no sharing is enabled it will not work with other Identity Awareness Security Gateways.

• User Experience:

  For example, when the traffic goes through several Security Gateways, double authentication might be required (e.g. in captive portal).

• Performance:

  Each Security Gateway is connected to an identity source, for example with ADQuery. Each Security Gateway will query the Active Directory. Each Gateway will perform the group membership query once a login event is observed and calculate the Access Role object.

Solution

Identity Awareness Security Gateways (configured as Policy Decision Points) acquire identity information and share it with other Identity Awareness Security Gateways (configured as Policy Enforcement Points). Traffic passes through many Security Gateways, but the User is only identified once. Only one Identity Awareness Security Gateway performs the group membership query and calculates the Access Role object. This reduces the load on the identity sources and/or on User Directory.

PDP - Policy Decision Point (Identity Server):

1. Acquires user/machine identities from the designated identity sources
2. Shares user/machine identities with other Security Gateways

PEP - Policy Enforcement Point (Identity Gateway):

1. Provides the relevant Access Roles to the Rule Base matching process. It enforces the action as defined in the policy.
2. Can receive identities through Identity Sharing
3. Can redirect users to the Identity Awareness Captive Portal

Identity Sharing Configurations

There are multiple ways to deploy Identity Sharing:

• One PDP shares identities to multiple PEPs.
• One PEP receives identities from multiple PDPs.
• PDP and PEP processes run on different gateways and communicate using a Smart-Pull Sharing method.
• PDP and PEP processes run on the same gateway and communicate using a Push Sharing method.

To configure Identity Sharing Configuration, define:

1. Which Identity Awareness Security Gateways will share their identities (Policy Decision Point).
2. Which Identity Awareness Security Gateways will receive identities (Policy Enforcement Point).

Smart-Pull Sharing Method

In this method, identities are sent to the PEP only when the PEP needs them, i.e. requests or pulls them from the PDP. In larger deployments not all identities acquired by PDPs are needed by all of the PEPs. For instance, small branch offices with a small number of users do not require storing of all of the identities acquired by the PDP located in the headquarters site. Storing unnecessary identities will consume more space on the PEP and create more unnecessary transactions between the PDP and the PEP over the network.

Smart-Pull sharing method divides into the 3 following Operation mode stages:

1. Identity Acquisition

1. The PDP acquires identities and stores them in the PDP repository.
2. The PDP notifies the relevant PEPs about the network (Class C), from which the user was identified.
3. The pep show network pdp command on the PEP shows the PDPs and the networks they identify.
4. The # pdp network info command shows all the networks published by the PDP.

The PDP does not publish the identities to the PEPs yet.

2. Sub-Network Registration

When a user initiates a connection through the PEP, where the policy requires an identity element, the PEP searches for the identity in its local database.

If the identity is not found, the PEP checks to see if there is a PDP that knows that the Class C network needed to resolve the identity.

If the identity is found, then:

1. The PEP registers to the PDP for notification about a smaller network (subnet mask 255.255.255.240).
2. The pep show network registration command on the PEP shows the 255.255.255.240 networks, to which the PEP is registered.
3. The pdp network registered command on the PDP shows the distribution of the PEPs to 255.255.255.240 networks.
4. The PDP publishes all the currently known identities from the 255.255.255.240 networks to the registering PEPs.

3. Identity Propagation

1. The PDP acquires identity of a user whose IP address is from an already registered 255.255.255.240 network.
2. The PDP immediately publishes the identity to the registered PEPs.

Push Sharing Method

This method is straight-forward: a PDP publishes each identity when it is acquired to the PEP.

Note - It is the only sharing method for the Identity Awareness Security Gateway that runs both as PDP and PEP.

Monitoring Identity Sharing

With Identity Sharing, there is always a connection from PDP to PEP, presented below as 'Outgoing'.

The 'Outgoing' (2) is the local connection PDP -> PEP running on the same Security Gateway.

With the Smart-Pull sharing method, when the Identity Sharing is used between PDP and remote PEP, with the Smart Pull sharing method there is an additional connection PEP->PDP presented below as 'Incoming' (1).

Monitoring Identity Sharing

With Identity Sharing, there is always a connection from PDP to PEP, presented below as 'Outgoing'.

The 'Outgoing' (2) is the local connection PDP -> PEP running on the same Security Gateway.

With the Smart-Pull sharing method, when the Identity Sharing is used between PDP and remote PEP, there is an additional connection PEP->PDP presented below as 'Incoming' (1).

The Deployment Scenarios section has more details.

Configuring Identity Awareness for a Domain Forest (Subdomains)

Create a separate LDAP Account Unit for each domain in the forest (subdomain). You cannot add domain controllers from two different subdomains into the same LDAP Account Unit.

You can use the Identity Awareness Configuration Wizard to define one subdomain. This automatically creates an LDAP Account Unit that you can easily configure for more settings. You must manually create all other domains that you want Identity Awareness to relate to, from Servers and OPSEC in the Objects tree > Servers > New > LDAP Account Unit.

When you create an LDAP Account Unit for each domain in the forest:

1. Make sure the username is one of these:
   • A Domain administrator account that is a member of the Domain Admins group in the subdomain. Enter the username as subdomain\user.
   • An Enterprise administrator account that is a member of the Enterprise Admins group in the domain. If you use an Enterprise administrator, enter the username as domain\user.

     For example, if the domain is ACME.COM, the subdomain is SUB.ACME.COM, and the administrator is John_Doe:

     If the admin is a Domain administrator, Username is: SUB.ACME.COM\John_Doe

     If the admin is an Enterprise administrator, Username is: ACME.COM\John_Doe

     Note - In the wizard, this is the Username field. In the LDAP Account Unit, go to LDAP Server Properties tab > Add > Username.

2. In LDAP Server Properties tab > Add > Login DN, add the login DN.
3. In Objects Management tab > Branches in use, edit the base DN
   from: DC=DOMAIN_NAME,DC=DOMAIN_SUFFIX
   to: DC=SUB_DOMAIN_NAME,DC=DOMAIN_NAME,DC=DOMAIN_SUFFIX
   For example, change DC=ACME,DC=local to DC=SUB,DC=ACME,DC=local

Non-English Language Support

To support non-English user names on an Identity Awareness Gateway, you must set a parameter in the LDAP Account Unit object in SmartConsole.

It is not necessary to set this parameter when you enable Identity Awareness on the Security Management Server or Log Server.

To set non-English language support:

1. In SmartConsole, click Open Object Explorer (Ctrl+E).
2. From the Categories tree, select Servers > LDAP Account Unit and select the LDAP Account Unit.
3. In the General tab of the LDAP Account Unit, make sure Enable Unicode support. is selected. It is selected by default.
4. Click OK.

Nested Groups

Identity Awareness supports the use of LDAP nested groups. When a group is nested in another group, users in the nested group are identified as part of the parent group. For example, if you make Group_B a member of Group_A, Group_B members will be identified by Identity Awareness as being part of Group A.

There are three ways to configure nested group queries:

• Recursive nested groups - The gateway sends a query with the user name to the LDAP server. The server finds the groups that the user is a member of and sends it to the gateway. To know if a group is nested in another group, and for each nesting level, you must send a new query. This feature is enabled by default. The default nesting depth is configured to 20. For details, see sk66561.
• Per-user nested groups - With one LDAP query, the response includes all groups for the given user, with all nesting levels. The server sends the groups of a given user as a flat list.
• Multi per-group nested groups - The gateway sends one LDAP query, which includes the user name and the group. The server responds if the user is in this group or not. Best Practice - Use this configuration for Microsoft Active Directory environment with many defined users and groups, and less groups defined in SmartConsole.

Configuring Nested Groups Query Options

You configure the nested group query options through the Security Gateway CLI:

Command	Description
pdp nested_groups status	Shows status
pdp nested_groups __set_state 1	Sets recursive nested groups (like R.77x)
pdp nested_groups __set_state 2	Sets per-user nested groups
pdp nested_groups __set_state 3	Sets multi per-group nested groups

Configuring Identity Awareness Gateway as Active Directory Proxy

If Security Management Server is not currently connected to your Active Directory environment, Identity Awareness Gateway can act as Active Directory Proxy and let you use the Identity Awareness User Picker in the Access Role object.

Note - The Identity Awareness Gateway needs to be connected to your Active Directory server.

Workflow to configure this feature:

1. In SmartConsole, create a new Host object for each Active Directory Domain Controller in your Active Directory environment.
2. In SmartConsole, install the Access policy on the Identity Awareness Gateway.
3. In SmartConsole, configure an LDAP Account Unit object.
4. Enable the Identity Awareness Software Blade on the Security Gateway.

Step	Instructions
1	In SmartConsole, create a new Host object for each Active Directory Domain Controller in your Active Directory environment: In the top left corner, click Objects > New Host. Configure the object name and IP address. Click OK.
2	In SmartConsole, install the Access Policy on the Identity Awareness Gateway.
3A	In SmartConsole, configure an LDAP Account Unit object: In the top left corner, click Objects > Object Explorer. The Object Explorer window opens. In the left navigation tree, click Servers. From the toolbar, click New > Server > LDAP Account Unit. The LDAP Account Unit Properties window opens.
3B	Configure the LDAP Account Unit object. Go to the General tab. In the Name field, enter the desired object name (for example, mycompany.com_LDAP_ACC_UNIT). In the Profile field, select Microsoft_AD. In the Prefix field, enter your domain name (for example, mycompany.com). In the Account Unit usage section, select all the options. In the Additional configuration section, select Enable Unicode support.
3C	Continue configuring the LDAP Account Unit object. Go to the Servers tab. Click Add. The LDAP Server Properties window opens. Go to the General tab. In the Host field, select the host object you created for this Domain Controller in Step 1. In the Username field, enter the username for this Domain Controller (for example, John.Smith). In the Login DN field, enter the user's distinguished name (DN) for this Domain Controller (see RFC1779). Note - Refer to the official Microsoft documentation. For example, use the PowerShell Get-ADUser command. In the Password field, enter the password for this Domain Controller. In the Confirm password field, enter the password again. Click OK to close the LDAP Server Properties window. Note - The order, in which these LDAP Servers are displayed is also the default order, in which they will be queried. You can configure the desired priority for these LDAP Servers.
3D	Continue configuring the LDAP Account Unit object. Go to the Objects Management tab. In the Server to connect field, select the host object you created for this Domain Controller in Step 1. Manually add the branch(es). Note - This feature does not support fetching on branches. The branch name is the suffix of the Login DN that begins with DC=. For example, if the Login DN is CN=John.Smith,CN=Users,DC=mycompany,DC=com then the branch name is DC=mycompany,DC=com Select Management Server needs proxy to reach AD server. In the Proxy through field, select the Security Gateway / Security Cluster that has a route to your AD server. Configure other desired settings.
3E	Continue configuring the LDAP Account Unit object. (Optional) Go to the Authentication tab. Clear Use common group path for queries. In the Allowed authentication schemes section, select all the options. In the Users' default values section: Clear Use user template. Select Default authentication scheme > Check Point Password.
3F	Complete the configuration of the new LDAP Account Unit object: Click OK to close the LDAP Account Unit Properties window.
4	(Optional) You can configure the Security Gateway to encrypt the LDAP communication with your Domain Controller: Open the LDAP Account Unit object you configured in Step 3. Go to the Servers tab. Select the LDAP Server object and click Edit. Go to the Encryption tab. Select Use Encryption (SSL). In the Verify that server has the following Fingerprints field, enter the Active Directory server fingerprint you get from the Identity Awareness Gateway. To get the Active Directory server fingerprint from the Security Gateway: Open a plain-text editor on your computer. Copy and paste this single long command to the plain-text editor: cpopenssl s_client -connect 192.168.1.2:636 2>&1 </dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | cpopenssl x509 -noout -md5 -fingerprint In the text editor, replace the 192.168.1.2 with the IP address of your Active Directory Domain Controller. Connect to the command line on Security Gateway. Log in to Expert mode. If this is a VSX Gateway, switch to the context the relevant Virtual System that has connectivity to the Active Directory Domain Controller. Make sure there is connectivity between the Security Gateway, or Virtual System and the Active Directory Domain Controller. Copy and paste the modified command from the text editor on your computer to the Security Gateway console and press Enter. MD5 Fingerprint is displayed. For example: MD5 Fingerprint=0B:84:D1:28:A5:19:6A:4D:24:57:72:5A:32:9B:2D:4D Copy the displayed Active Directory fingerprint number (after the = sign) from the Security Gateway console. Paste the copied fingerprint number in the Verify that server has the following Fingerprints field. Click OK to close the LDAP Server Properties window. Click OK to close the LDAP Account Unit Properties window.
5	Enable the Identity Awareness Software Blade on the Security Gateway. In SmartConsole, from the left Navigation Toolbar, click Gateways & Servers. Edit the Security Gateway object. Select Identity Awareness Software Blade. When Identity Awareness Configuration wizard opens, click Cancel. Make sure the Identity Awareness is selected. In the left navigation tree, go to Identity Awareness. In the Identity Sources section, select and configure the relevant options. Click OK. Install the Access policy.

Notes about the Identity Awareness Gateway as Active Directory Proxy feature:

• This feature works only with Microsoft Active Directory.
• This feature supports only the user picker in the Access Role object. Other settings, such as Identity Awareness Configuration wizard, Client certificate, Legacy user picker, Fetch branches, Fetch fingerprint, and LDAP tree are not supported.
• This feature works only with Security Gateways R80.20 and above running on Gaia OS.
• This feature supports only Virtual Systems that belong to the same domain as the VSX Gateway or VSX Cluster (context VS0).

  This feature does not support Virtual Systems that belong to a different domain than the VSX Gateway or VSX Cluster (context VS0).

• This feature does not support Appliances running on Gaia Embedded OS (1100 / 1200R / 1400).
• This feature does not support Scalable Platforms (41000 / 44000 / 61000 / 64000).
• This feature does not support DAIP gateways or Externally managed gateways.
• Available communication types:
  • Clear - Communication between the Security Management Server and the Security Gateway is encrypted by SIC. However, the communication from the Security Gateway to the Active Directory server is not encrypted.
  • SSL - Active Directory domain controller needs to allow SSL.
• In a Multi-Domain Security Management environment, this feature is not available for Account Units that are configured in the Global SmartConsole.
• Required Active Directory permissions for the account used to configure the Account Unit:
  • For user picker functionality, the account should have permission to perform LDAP queries.
  • For gateway functionality - depends on the identity sources that are used on the Security Gateway.
  • To acquire identities using the AD Query, without using domain admin credentials, refer to sk93938.