Identity Awareness Deployment

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

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