Nested AD Groups and MFA Break SSL VPN Policy Matching
A FortiGate 200F provides SSL VPN for 150 remote users. Authentication uses LDAP to Active Directory, and MFA uses FortiAuthenticator as a RADIUS server with FortiToken push. AD groups are VPN-Users, VPN-Admins, and VPN-Contractors. Contractors are members of VPN-Contractors, which is nested inside VPN-Users. The FortiGate LDAP group object for VPN-Users uses member attribute member and a group base DN, but recursive group search is not enabled. The SSL VPN portal full-access is mapped to VPN-Users. Contractors authenticate successfully but land on the no-access portal. Staff report that FortiToken is requested only every 30 days, while security policy requires MFA at every new login. Admin accounts use RADIUS with the super_admin profile; during a FortiAuthenticator outage, the only super_admin admin was locked out. Tasks: fix contractor access, enforce MFA every login, and design break-glass admin access.
1. Why do contractors authenticate but fail to match the full-access portal? What are two fixes that do not require changing the FortiGate LDAP schema?
Read the worked answer
The FortiGate LDAP group object checks the direct member attribute of VPN-Users. Contractors are direct members of VPN-Contractors, not VPN-Users, so the nested membership is not resolved and the SSL VPN portal mapping does not match. Authentication succeeds because LDAP bind succeeds; authorization fails because group evaluation fails.
Two fixes without schema changes: flatten the AD membership by adding contractors directly to VPN-Users, or create a direct VPN-Contractors group and map that group to a separate portal or policy. Alternatively, put FortiAuthenticator in front as an LDAP proxy or RADIUS server that resolves nested groups and returns a group attribute, then map that attribute to a FortiGate group. A third option, if supported in the deployed FortiOS, is an AD recursive group filter using the matching-rule-in-chain construct, but test it carefully because support varies by version and attribute.
2. How do you enforce MFA on every new SSL VPN login without breaking staff workflows?
Read the worked answer
Make FortiAuthenticator the RADIUS authentication path for SSL VPN and configure its authentication policy to require a token on every authentication. Disable remembered-device or trusted-device behavior and shorten the SSL VPN session or idle timeout so a new login means a new token challenge. Remove any LDAP-only fallback that lets users bypass RADIUS, and confirm the FortiGate SSL VPN settings use the RADIUS server as the primary method.
For staff workflow, use FortiToken push rather than typed OTP where possible, and document the offline or bypass-code process. Test with a pilot group before enforcing globally. Verify that RADIUS attributes map users to the correct portal and that group membership is evaluated after MFA, not before. Monitor FortiAuthenticator logs for users who are still being cached or trusted.
3. Design break-glass admin access for FortiAuthenticator outages.
Read the worked answer
Do not rely on a single RADIUS-backed super_admin account. Keep a local emergency admin on the FortiGate with a strong unique password, restricted trusted hosts on the management VLAN, and a documented sealed-envelope or vault process. Give it the minimum profile needed for recovery, and log and alert on its use. Use a different account name from day-to-day admins so misuse is visible.
For normal admin access, use RADIUS with MFA but run at least two FortiAuthenticator nodes or a RADIUS failover path. Test failover before an outage. Keep local admin accounts on standby with least privilege, and avoid shared accounts. After an outage, rotate any emergency credentials used and review logs for unauthorized access.