AD Query
AD Query is an easy to deploy, clientless identity acquisition tool. It is based on Active Directory integration, and it is completely transparent to the user.
AD Query works when:
- An identified user or computer tries to access a resource that creates an authentication request. For example, when a user logs in, unlocks a screen, shares a network drive, reads emails through Exchange, or uses an Intranet portal.
- AD Query is selected as a way to acquire identities.
The technology is based on querying the Active Directory Security Event Logs and extracting the user and computer mapping to the network address from them. It is based on Windows Management Instrumentation (WMI), a standard Microsoft protocol. The Identity Awareness Gateway communicates directly with the Active Directory domain controllers and does not require a separate server.
No installation is necessary on the clients, or on the Active Directory server.
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 a 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:
- After a predefined period of network inactivity, a user session closes automatically. The user must log in again with the Captive Portal.
- - 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 occurs. In this scenario, there is a risk that currently connected users can access network resources, for which they do not have permissions.
How AD Query Works - Firewall Rule Base
Item
|
Description
|
1
|
Identity Awareness Gateway
|
2
|
Active Directory Domain Controller
|
3
|
User with Active Directory credentials
|
4
|
Network resources
|
Flow of events:
- The Identity Awareness Gateway (1) gets security event logs from the Active Directory Domain Controllers (2).
- A user logs in to a computer with Active Directory credentials (3).
- The Active Directory Domain Controller (2) sends the security event log to the Identity Awareness Gateway (1).
- The Identity Awareness Gateway gets the user name (
@domain), computer name and source IP address). - The user opens a connection to the network resource (4).
- The Identity Awareness Gateway confirms the user identity and allows or blocks access to the resource based on the policy.
Browser-Based Authentication
Browser-Based Authentication gets identities and authenticates users with one of these acquisition methods:
How Captive Portal Works
Captive Portal is a simple method that authenticates users with a web interface. When users try to access a protected web resource, they enter authentication information in a form that shows in their web browser.
The Captive Portal shows when a user tries to access a web resource and all of these conditions apply:
- Captive Portal is enabled.
- The option enabled for the applicable policy rule.
- Firewall or Application & URL Filtering rules block access by unidentified users to resources that would be allowed, if they were identified.
The Captive Portal also shows when Transparent Kerberos Authentication is enabled, but authentication fails.
From the Captive Portal, users can:
- Enter their user name and password (which are configured in the Identity Awareness Gateway object > page > near the , click > refer to the section).
- Enter guest user credentials (which are configured in the Identity Awareness Gateway object > page > near the , click > refer to the section).
- Click a link to download an Identity Agent (which is configured in the Identity Awareness Gateway object > page > near the , click > refer to the section).
Browser-Based Authentication with Captive Portal:
Item
|
Description
|
1
|
User
|
2
|
Identity Awareness Gateway
|
3
|
Captive Portal
|
4
|
Active Directory Domain Controller
|
5
|
Internal Data Center
|
Flow of events for Browser-Based Authentication with Captive Portal:
- A user (1) wants to access the Internal Data Center (5).
- Identity Awareness Gateway (2) does not recognize the user and redirects the user's web browser to the Captive Portal (3).
- The user enters regular office credentials. The credentials can be AD or other Check Point supported authentication methods, such as LDAP, Check Point internal credentials, or RADIUS.
- The credentials go to the Identity Awareness Gateway, which finds them in the AD server (4).
- The user can access the requested URL in the Data Center (5).
How Transparent Kerberos Authentication Works
Browser-Based Authentication with Transparent Kerberos Authentication:
Transparent Kerberos Authentication authenticates users by getting authentication data from the web browser without any user input. If authentication is successful, the user goes directly to the specified destination. If authentication fails, the user must enter credentials in the Captive Portal.
Flow of events for Browser-Based Authentication with Transparent Kerberos Authentication:
- A user wants to access the Internal Data Center.
- Identity Awareness Gateway does not recognize the user and redirects the user's web browser to the Transparent Authentication page.
- The Transparent Authentication page asks the web browser to authenticate itself.
- The web browser gets a Kerberos ticket from Active Directory and presents it to the Transparent Authentication page.
- The Transparent Authentication page sends the ticket to the Identity Awareness Gateway, which authenticates the user and redirects the user's web browser to the originally requested URL.
- If Kerberos authentication fails for some reason, Identity Awareness Gateway redirects the user's web browser to the Captive Portal.
