You can create an advanced Firewall access rule with the Response set as Require Authentication. When you implement such a rule, the Sensor ensures that the corresponding users have valid AD logon credentials.
Note
A Require Authentication access rule is effective only when the monitoring ports are inline. These rules are relevant only for HTTP traffic and becomes effective only when configured on top of all the rules in the Access Rules tab while creating an internal firewall policy
If you have created a require-authentication access rule, the Sensor ensures AD authentication in the following ways:
As discussed in the earlier sections, when users log on to your network, the Sensor receives the user details through the Manager. So, if the Sensor has an IP-to-user mapping, it indicates that the user has been already authenticated by the AD server. So, the Sensor proceeds to evaluate the rest of the rules.
If the Sensor does not have a user bound to the IP address in the detected HTTP traffic, it redirects the user to the Guest Portal. This is the Web portal hosted on the Sensor for explicitly determining the identity of users based on their AD credentials.
The Sensor sends the logon credentials that the user entered in the Guest Portal to the Manager. The Manager checks if it already has the AD details of the user. If yes, it forwards the details to the Sensor. If not, it verifies the user credentials with the configured list of AD servers. The Manager notifies whether the credentials are valid or not to the Sensor. The Manager provides the IP-to-user and user-to-user group mappings to the Sensor.
Note
In case of Sensor failover, the Sensor that detected the HTTP traffic redirects the user to its Guest Portal. It sends the AD details to the Manager. The Manager verifies with the AD servers and responds to the Sensor. If the authentication is successful, the Sensor sends the details to its peer Sensor. In case of an MDR pair, the process is same but only the active Manager is involved.
The following are the parameters allowed in a require-authentication access rule:
You must select the default HTTP Service rule object as the Application. You cannot select any other rule object for Application. Even the default HTTP Application rule object or a custom HTTP Service rule object are not valid.
The Source User must be set to Any.
Select the Response as Require Authentication.
For all other parameters, you can specify the values you require. For example, you can specify all your critical Web servers in the Destination Address field. So, the Sensor ensures that all users accessing these Web servers have valid AD credentials.
Purpose of require-authentication access rules
Assume that the communication between the Manager and Trellix Logon Collector is down. Now, consider a user who is physically connecting a Windows host that is already unlocked. In this case, the Sensor might not have a IP-to-user mapping because the communication with Trellix Logon Collector is down. Also, the host did not generate any Kerberos traffic since the host is already unlocked. Because the Sensor does not have the IP-to-user mapping, it might not be able to evaluate and apply the correct user-based access rule for this user. If you have a require-authentication rule, then the Sensor will be able to derive the user details even in this case as illustrated by the following example.
Consider the following example rules:
Source Address: Other | Source User: Any | Destination Address: Critical Web servers | Application: HTTP | Response: Require Authentication.
Source Address: Other | Source User: Jane | Destination Address: Critical Web servers | Application: HTTP | Response: Scan.
Source Address: Other | Source User: John | Destination Address: Critical Web servers | Application: HTTP | Response: Deny.
Consider that Jane accesses a critical Web server:
If the Sensor has the IP-to-user mapping for this traffic, the Sensor proceeds to the second rule. In this case, only the second rule is considered as a match.
If the Sensor does not have the IP-to-user mapping for this traffic, it redirects Jane to its Guest Portal, where the Jane enters her AD credentials. In this case, the first rule is considered as a match. The Manager checks if it has the AD details for Jane. If not, it verifies these credentials with the AD servers and also forwards the details related to Jane to the Sensor. So, the Sensor now has at least the IP-to-user mapping for Jane.
Jane retries to access a critical Web server. This time, since the Sensor has the IP-to-user mapping, it proceeds to the second rule. The second rule matches and the Sensor forwards the traffic for IPS inspection.
Requirements for require-authentication access rules
In addition to the requirements in High-level steps for implementing user-based Firewall and QoS rules, the following are required for a required-authentication access rule to work:
You have deployed the required Sensor monitoring ports in inline mode. Required-authentication access rule is not effective in SPAN or tap mode.
You must specify an IP address to the monitoring port pair to redirect users to the Guest Portal.
You must specify the AD servers and trusted Domain Controllers that the Manager should check with to verify the AD credentials entered in the Guest Portal.
Enable the Guest Portal settings through the Manager.