Nested AD Groups and Token Bypass on VPN RADIUS
A 3,200-employee manufacturer runs FortiAuthenticator 6.5 as the RADIUS server for FortiGate SSL VPN and wireless. VPN access requires Active Directory group VPN-Users plus FortiToken Mobile. The AD team recently moved users into a new nested group, VPN-All, whose only member is VPN-Users. Since the change, the help desk reports two symptoms: some VPN users are admitted with only their AD password and no token prompt, while others are prompted twice. RADIUS authentication logs show Access-Accept for affected users but no FortiToken challenge. At the same time, the AD service account used by FortiAuthenticator is locking out every 15 minutes. The FAC is a single node on 6.5.2, connecting to LDAP over LDAPS on TCP 636 with a bind DN and a group filter. The FortiGate RADIUS policy references a FortiAuthenticator user group named VPN-MFA. No FortiGate policy or firmware changes were made.
1. Why would users in the nested group VPN-All bypass FortiToken, and what would you change in FortiAuthenticator to enforce MFA without listing every user?
Read the worked answer
Remote LDAP group evaluation in FortiAuthenticator follows the configured group filter and member attribute. If the FAC group filter only matches memberOf=CN=VPN-Users,... against the user entry, a user who is a member of VPN-All but not directly of VPN-Users will not match; the user can then fall through to a broader password-only policy and receive Access-Accept before any FortiToken challenge. Confirm the real group DNs and membership with an LDAP browser, then either flatten VPN-Users membership or make the FAC group filter resolve nested membership. On AD, the matching-rule-in-chain OID 1.2.840.113556.1.4.1941 can be used in the member filter; if the FAC release does not support that evaluation, keep membership flat. Map the FortiGate RADIUS policy only to the FAC group that has the FortiToken policy attached, and test with one affected user.
2. Service-account lockouts every 15 minutes point to what design or credential problem, and how should the bind account be operated?
Read the worked answer
A 15-minute lockout cadence is a retry loop, not a one-off typo. Check the LDAP server object bind DN and password, then search FAC authentication logs for repeated Invalid credentials from the FAC source address. Common causes are a service-account password changed in AD but not in FAC, an expired service account, or the same account reused by a second integration with a stale password. Use a dedicated read-only service account, document every consumer, set a password that does not expire unexpectedly, and alert on lockouts. Do not use a human admin account for LDAP binds. After fixing the credential, clear the AD lockout and observe for at least 30 minutes. If the account must be rotated, update all FAC LDAP server entries and any FSSO or SSO integration in the same change window.
3. Design a low-risk verification and rollback plan before enabling the change for all 3,200 users.
Read the worked answer
Create a pilot AD group containing 10 users from both direct and nested membership, plus one service-desk tester. Apply the fix during a change window with the old FAC configuration exported. On the pilot FortiGate or a test RADIUS client, run a RADIUS debug and confirm the Access-Challenge for FortiToken appears before Access-Accept. Check FAC authentication logs for the user DN, matched group, and token result. Test a wrong token and a timeout to confirm failure behavior. Roll out to 10 percent of VPN users, monitor lockouts and help-desk tickets for one business day, then complete the rollout. Rollback is restoring the exported LDAP/group configuration and removing the pilot group mapping; no FortiGate policy change should be needed if the FAC group name is unchanged.