A utility configures LDAP authentication so that the FortiGate not only verifies a back-office employee's password against the corporate directory, but also checks which LDAP group the employee belongs to, in order to decide which firewall policy applies. What is this second check, beyond password verification, generally called?

Verifying a password against the directory is the authentication step — confirming the claimed identity is genuine — while separately querying which LDAP group that now-verified identity belongs to is an authorization step, determining what the authenticated user is permitted to access; FortiGate policies commonly key off this LDAP group membership to select the correct policy, distinct from the initial credential check. This has nothing to do with RADIUS shared secrets, which is an entirely different protocol's mechanism for securing its own messages and plays no role in an LDAP-only deployment. The bind DN is used once to establish the connection needed to search the directory; group membership is typically read as an attribute of the user's directory entry or via a group-membership query, not by repeating the bind step for redundancy. FSSO is a separate, passive identity-derivation mechanism unrelated to an active LDAP authentication flow that already directly verified a password — the presence of a group check does not imply FSSO is running underneath it. The caveat worth remembering is that authorization based on stale group data (an employee moved teams but the directory wasn't updated) can grant or deny access incorrectly even though authentication itself succeeded correctly. Confirm this distinction by testing a user with a correct password but no matching group membership and observing that the group-restricted policy still does not apply.