Exhibit A shows that Captive Portal is enabled on the lan interface, with the HR and Sales user groups selected. This configuration forces any user initiating traffic through this interface to be challenged for authentication. After a user authenticates, their identity is known. Exhibit B shows the firewall policies that apply to this traffic. Policy 1 explicitly allows traffic from the source user group HR. Policy 2 is an explicit deny for all other traffic. Therefore, all users will be prompted to authenticate, but only users who successfully authenticate as members of the HR group will have their traffic matched by Policy 1 and allowed to pass.

A. The captive portal is enabled on the interface, which forces an authentication prompt before policy evaluation. The presence of a deny policy (not a fall-through) is what blocks non-HR users.

B. Authentication is enforced at the interface level via captive portal, not the policy level. The policy uses the authenticated identity but does not trigger the authentication itself.

C. While users from the Sales group can authenticate successfully (as they are in the captive portal's group list), their traffic will be blocked by the explicit deny in Policy 2.

FortiOS 7.2 Administration Guide, Page 338, Section: "Firewall authentication". This section explains that when authentication is enabled on an interface, the FortiGate challenges the user for credentials.

FortiOS 7.2 Administration Guide, Page 340, Section: "Identity-based policies". It states, "After a user is authenticated, their traffic is handled by the identity-based security policy that applies to them." This confirms the two-step process of authentication followed by policy matching.