Selecting Identity Sources

Identity sources have different security and deployment considerations. Depending on your organization requirements, you can choose to set them separately, or as combinations that supplement each other.

This section presents some examples of how to choose identity sources for different organizational requirements.

Requirement	Recommended Identity Source
Logging and auditing with basic enforcement	AD Query.
Logging and auditing only	AD Query.
Application Control	AD Query and Browser-Based Authentication. The AD Query finds all AD users and computers. The Browser-Based Authentication identity source is necessary to include all non-Windows users. It also serves as a fallback option, if AD Query cannot identify a user. If you configure Transparent Kerberos Authentication, then the browser attempts to authenticate users transparently by getting identity information before the Captive Portal username/password page is shown to the user.
Data Center, or internal server protection	The options are: AD Query and Browser-Based Authentication - When most users are desktop users (not remote users) and easy deployment is important. Note - You can add Endpoint Identity Agents if you have mobile users and have users that are not identified by AD Query. Users that are not identified encounter redirects to the Captive Portal. Endpoint Identity Agents and Browser-Based Authentication - When a high level of security is necessary. The Captive Portal is used for distributing the Endpoint Identity Agent. IP Spoofing protection can be set to prevent packets from being IP spoofed.
Terminal Servers and Citrix environments	Terminal Servers. Requires you to install the Terminal Servers Endpoint Identity Agent on each Terminal Server.
Users that access the organization through VPN	Remote Access. Lets you identify Mobile Access and IPsec VPN clients that work in Office Mode.
Environment that use a RADIUS server for authentication	RADIUS Accounting. Make sure that you configure the Security Gateway as a RADIUS Accounting client and give it access permissions and a shared secret.

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

Specifying Domain Controllers per Security Gateway

An organization Active Directory can have several sites, where each site has its own domain controllers that are protected by a Security Gateway. When all of the domain controllers belong to the same Active Directory, one LDAP Account Unit is created in SmartDashboard.

When AD Query is enabled on Security Gateways, you may want to configure each Security Gateway to communicate with only some of the domain controllers.

This is configured in the User Directory page of the Gateway Properties. For each domain controller that is to be ignored, the default priority of the Account Unit must be set to a value higher than 1000.

For example, let say that the LDAP Account Unit ad.mycompany.com has 5 domain controllers.

On the Security Gateway we want to enable AD Query only for domain controllers dc2 and dc3. This means that all other domain controllers must be set to a priority higher than 1000 in the Security Gateway properties.

To specify domain controllers for each Security Gateway:

1. Log in to SmartDashboard.
2. From the Network Objects tree, right-click Check Point and select the Security Gateway.
3. From the Gateway Properties tree, select Other > User Directory.
4. Click Selected Account Units list and click Add.
5. Select your Account Unit.
6. Clear the Use default priorities option and set the priority 1001 to dc1, dc4 and dc5.
7. Click OK.
8. Install policy.

Checking the Status of Domain Controllers

You can make sure that the domain controllers are set properly by using the adlog CLI. You can see the domain controllers that the Security Gateway is set to communicate with as well as the domain controllers it ignores.

The CLI command is: adlog a dc

Working with AD Query

AD Query extracts user and computer identity information from the Active Directory Security Event Logs. The system generates a Security Event log entry when a user or computer accesses a network resource. For example, this occurs when a user logs in, unlocks a screen, or accesses a network drive. Security Event Logs are not generated when a user logs out because Active Directory cannot detect this action.

When you work with AD Query, it is important that you understand and comply with these limitations:

• User/IP association timeout - After a predefined period of network inactivity, a user session closes automatically. The user must log in again with the Captive Portal.
• Many user accounts connected from the same IP address - AD Query cannot detect when a user logs out. Therefore, more than one user can have open sessions from the same IP address. When this occurs, the permissions for each account remain active until their User/IP association timeout occurs. In this scenario, there is a risk that currently connected users can access network resources for which they do not have permissions.

Single User Assumption

You can configure AD Query to allow only one active account per IP address. When user A logs out before the timeout and user B logs in, the user A session closes automatically and his permissions are canceled. User B is the only active user account and only his permissions are valid. This feature is called Single User Assumption.

Before you activate Single User Assumption, you must exclude all service accounts used by user computers.

Note - Another way to keep these issues to a minimum is to increase the DHCP lease time.

To activate single user assumption:

1. Exclude service accounts.
2. On the Identity Awareness page, select Settings for AD Query.
3. Select Assume that only one user is connected per computer.
4. Click OK.

To deactivate Single User Assumption, clear Assume that only one user is connected per computer.

Excluding Users, Computers and Networks

You can manually exclude service accounts, users, computers and networks from the AD Query scan. You can also configure AD Query to automatically detect and exclude suspected service accounts. Identity Awareness identifies service accounts as user accounts that are logged in to more than a specified number of computers at the same time.

To exclude objects from Active Directory queries:

1. From the Identity Awareness pane, select Settings for Active Directory Query.
2. Click Advanced.
3. In the Excluded Users / Computers section, enter the user or computer account name. You can use the * and ? wildcard characters or regular expressions to select more than one account. Use this syntax for regular expressions: regexp:<regular expression>.
4. Optional: Select Automatically exclude users which are logged into more than n machines simultaneously. Enter the threshold number of computers in the related field.
5. In the Excluded Networks section:
   • Click the plus sign (+) and select a network to add the Excluded Network list.
   • Select an excluded network and click the minus sign (-) to remove a network from the list.
6. Click Add.
7. Click OK.

Managing the Suspected Service Account List

When automatic exclusion is enabled, Identity Awareness looks for suspected service accounts every 10 minutes. Suspected service accounts are saved to a persistent database that survives reboot. When a new service account is detected, a message shows in SmartView Tracker.

Use these commands to see and manage the suspected service account database:

To show all suspected service accounts, run: adlog a control srv_accounts show

To run the service accounts scan immediately, run: adlog a control srv_accounts find
This command is useful before you enable the Assume that only one user is connected option.

To remove an account from the service account database, run: adlog a control srv_accounts unmark <account name>

To remove all accounts from the suspected service account database, run: adlog a control srv_accounts clear

Important - When you use the adlog a control command, you must run adlog a control reconf to save the configuration.

Using AD Query with NTLMv2

this release supports NTLMv2 for AD Query. Earlier releases only supported NTLM. By default, NTLMv2 support is disabled.

To enable NTLMv2 support for AD Query:

1. Enable Identity Awareness without using the wizard.
2. Install a policy.
3. From the Security Management Server command line, go to the expert mode.
4. Run: adlogconfig a
5. Select: Use NTLMv2
6. Select: Exit and save
7. Restart the Identity Awareness wizard and continue configuring Identity Awareness.

Multiple Security Gateway Environments

In environments that use many Security Gateways and AD Query, we recommend that you set only one Security Gateway to acquire identities from a given Active Directory domain controller for each physical site. If more than one Security Gateway gets identities from the same AD server, the AD server can become overloaded with WMI queries.

Set these options on the Identity Awareness > Identity Sharing page of the Security Gateway object:

• One Security Gateway to share identities with other Security Gateways. This is the Security Gateway that gets identities from a given domain controller.
• All other Security Gateways to get identities from the Security Gateway that acquires identities from the given domain controller.

The Deployment Scenarios section has more details.

Non-English Language Support

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

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. Select Servers and OPSEC in the Objects Tree.
2. Right-click Servers > LDAP Account Unit and select the LDAP Account Unit.
3. In the General tab of the LDAP Account Unit, select Enable Unicode support.
4. Click OK.

Performance

Bandwidth between the Log server and Active Directory Domain Controllers

The amount of data transferred between the Log server and domain controllers depends on the amount of events generated. The generated events include event logs and authentication events. The amounts vary according to the applications running in the network. Programs that have many authentication requests result in a larger amount of logs. The observed bandwidth range varies between 0.1 to 0.25 Mbps per each 1000 users.

CPU Impact

When using AD Query, the impact on the domain controller CPU is less than 3%.

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.

The default nesting depth is configured to 20. This feature is enabled by default. For details on working with nested groups, see sk66561.

Troubleshooting

If you experience connectivity problems between your domain controllers and Identity Awareness Gateway/Log Servers, perform the following troubleshooting steps:

Connectivity Issues

1. Ping the domain controller from the Security Gateway with Identity Awareness/log server.
2. Ping the Security Gateway with Identity Awareness/log server from your domain controller.
3. Perform standard network diagnostics as required.
4. Check SmartView Tracker and see if there are drops between a Security Gateway defined with AD Query (Source) and the domain controller (Destination). If there are drops, see Configuring the Firewall and sk58881.

Use wbemtest to Verify WMI

To use the Microsoft wbemtest utility to verify that WMI is functional and accessible.

1. Click Start > Run.
2. Enter wbemtest.exe in the Run window.
3. In the Windows Management Instrumentation Tester window, click Connect.
4. In the Connect window, in the first field, enter the Domain controller, in this format: \\<IP address>\root\cimv2
5. In the Credentials > User field, enter the fully qualified AD user name. For example: ad.company.com\admin
6. Enter a password for the user.
7. Click Connect.
8. If the Windows Management Instrumentation Tester window re-appears with its buttons enabled, WMI is fully functional.

If the connection fails, or you get an error message, check for these conditions:

• Connectivity problems
• Incorrect domain administrator credentials.
• WMI service is not running
• A Firewall is blocking traffic between the Identity Awareness Gateway or Log Server and domain controller.

Domain administrator Credentials

To verify your domain administrator credentials:

1. Click Start > Run.
2. Enter \\<domain controller IP>\c$ in the Run window. For example: \\11.22.33.44\c$.
3. In the Logon window, enter your domain administrator user name and password.
4. If the domain controller root directory appears, this indicates that your domain administrator account has sufficient privileges. An error message may indicate that:
   1. If the user does not have sufficient privileges, this indicates that he is not defined as a domain administrator. Obtain a domain administrator credentials.
   2. You entered the incorrect user name or password. Check and retry.
   3. The domain controller IP is incorrect or you are experiencing connectivity issues.

Verify the WMI Service

To verify if the WMI service is running on the domain controller:

1. Click Start > Run.
2. Enter services.msc in the Run window.
3. Find the Windows Management Instrumentation service and see that the service started.

   If it did not start, right-click this service and select Start.

Configuring the Firewall

If a Security Gateway is located between the Security Gateway with Identity Awareness/log server and the Active Directory controller, configure the Firewall to allow WMI traffic.

To create Firewall rules for WMI traffic:

1. In SmartDashboard > Firewall, create a rule that allows ALL_DCE_RPC traffic:
   • Source = Security Gateways that run AD Query
   • Destination = Domain Controllers
   • Service = ALL_DCE_RPC
   • Action = Accept
2. Save the policy and install it on Security Gateways.

   Note - If there are connectivity issues on DCE RPC traffic after this policy is installed, see sk37453 for a solution.

Confirm that Security Event Logs are Recorded

If you have checked connectivity but still do not see identity information in logs, make sure that the necessary event logs are being recorded to the Security Event Log.

AD Query reads these events from the Security Event log:

• For Windows Server 2003 domain controllers - 672, 673, 674
• For Windows Server 2008 and higher domain controllers - 4624, 4769, 4768, 4770

Make sure you see the applicable events in the Event Viewer on the domain controller (My computer > Manage > Event Viewer > Security).

If the domain controller does not generate these events (by default they are generated), refer to Microsoft Active Directory documentation for instructions on how to configure these events.

Install Database for a Log Server

If you have configured Identity Awareness for a log server, but do not see identities in logs, make sure you installed the database.

To install the database:

1. Click Policy > Install Database.

   The Install Database window appears.

2. Select the computers to install the database on.
3. Click OK.

   The Install Database script shows.

4. Click Close when the script is done.