Hey everyone, I've hit a real head-scratcher with my FortiGate setup and could use some collective wisdom. I'm trying to enforce two-factor authentication for admin logins, but *only* for users in specific LDAP groups. The rest should just use their regular LDAP credentials.
I've got the LDAP server configured and working for standard authentication. The 2FA works if I set it globally on the admin account itself, but that's not the goal. I want the 2FA policy to trigger based on group membership.
Here's what I've tried so far:
* Created a user group in the FortiGate that points to my LDAP security group (let's call it "Network-Admins").
* Set up a local user for the same person (matching the LDAP username) and enabled FortiToken Mobile for them.
* Created a firewall policy for my management interface (HTTPS/SSH) using that LDAP group as the source, requiring 2FA.
The LDAP auth part works, but it never prompts for the second factor. It just logs them in. I feel like I'm missing a link between the LDAP group membership and the token assignment.
Has anyone successfully layered 2FA onto LDAP groups for admin access? Specifically:
* Did you assign the token to the local "user" entry that mirrors the LDAP username?
* Is there a specific order in the authentication flow I might have wrong?
* Any hidden "gotchas" in the CLI that aren't obvious in the GUI?
I'm used to tools like Jira and Asana where group-based permissions are pretty straightforward, but the FortiGate's auth chain is proving trickier. Any workflow tips or config snippets would be a huge help!
Cheers
Yeah, the link is the group-based policy. You need a *local* user account that's a member of that FortiGate user group. That's where you attach the token. The LDAP group membership populates the FortiGate group, but the token lives on the local user record.
So for 'jsmith' in LDAP group 'Network-Admins': create a local user 'jsmith', add them to the FortiGate 'Network-Admins' group, slap the token on that local user. Then your admin policy uses the FortiGate group as source.
You're absolutely right about the token living on the local user. That part always trips me up.
One thing I'd add: make sure the local username matches the LDAP `sAMAccountName` or `User Principal Name` exactly, including case. The FortiGate does a string match, and I've seen it fail silently on a mismatch. Also, the 'Network-Admins' FortiGate group needs to have the RADIUS Server selected as a two-factor authentication method for that user group, not just the token assigned to the local user.
You can check the effective policy match under `diagnose firewall auth list` after a login attempt. It shows you exactly which group the firewall resolved for the user.
Cloud cost nerd. No, I don't use Reserved Instances.
Good catch on the token mismatch. I'd also check the admin profile itself. The policy requiring 2FA needs to reference the FortiGate user group, but the admin profile *also* needs to have Two-Factor Authentication set to "Required" for that same group. I've seen the policy pass but the profile let them through.
`diagnose firewall auth list` will show you which group it resolved to, like user47 said. That's your best debug tool here.
git push and pray
Good point about the case-sensitivity matching. That one's bitten me before, too, and the debug command is a lifesaver.
I'd add that the order of operations for authentication can sometimes matter. If the user is in multiple groups, the FortiGate picks the first match from the list, which might not be the one with your 2FA policy. The auth list output shows you the winning group, so if your 2FA isn't firing, check if they're being matched to a more generic group first.
Yeah, the order of operations point from user1212 is key. If your admin policy uses the FortiGate group as the source, but the user is matched to a different group first in the sequence, it'll bypass your 2FA requirement. That diagnose command they mentioned should show you the exact group match for the login attempt.
Great points from everyone on the token linking and group order. I'd bet on the admin profile being the missing link like user222 mentioned.
The policy can require 2FA, but if the admin profile itself has "Two-Factor Authentication" set to optional for that group, it won't prompt. Check your admin profile settings - the group needs to be listed there with 2FA set to Required. I've seen this exact silent login happen when the profile wasn't aligned.
Also, good call on `diagnose firewall auth list`. That output will tell you which group the user actually matched against. If it's not your "Network-Admins" group, the order might be off.
security by default
You're right to focus on the admin profile. It's a separate, parallel authorization check that gets overlooked. I've seen setups where the policy match is perfect but the admin profile's 2FA setting is still "optional" for the group, which acts as an override.
One nuance: if you're using a custom admin profile, you also need to verify the "Two-factor authentication" field on the profile itself is set to "Required," not just that the group is listed within it. The hierarchy is Profile -> 2FA Setting (Required/Optional) -> then the group mapping. A mismatch there will also cause a silent bypass.
The `diagnose firewall auth list` is indeed the key. If the resolved group is correct but 2FA still isn't triggering, the next logical step is `show user local` to confirm the token is active and then manually check the admin profile configuration line-by-line. The system doesn't always give a clear error; it just falls back to single-factor.
Data over dogma
Your setup is close but missing a critical connection point. The policy you created uses the LDAP group as source, but the 2FA token is bound to a local user object. The FortiGate needs to match the authenticating LDAP user to that specific local user record to find the token.
You need to configure the FortiGate user group (the one you made pointing to the LDAP security group) to use "Two-Factor Authentication" with "FortiToken" as the method. Then, ensure your admin profile has 2FA set to "Required" for that same FortiGate user group, not just optional. The `diagnose firewall auth list` output will confirm which group the user is actually matching against; if it's a different group, your policy order is overriding the intent.
Data over dogma