FortiGate IKEv2 VPN with Microsoft NPS, Active Directory and FortiToken MFA

Verified outcome and scope

Production-tested configuration: FortiGate dial-up IKEv2 using a Microsoft NPS RADIUS server to verify Active Directory credentials, FortiToken Mobile MFA enforced for VPN establishment, and a separate remote RADIUS group to restrict network access through firewall policies.

Three outcomes were independently validated:

1. The client completed an IKEv2 connection only after the FortiToken challenge.
2. A user could reach only an explicitly permitted application destination and TCP port.
3. Removing the user from the application's AD security group revoked application access, even though VPN authentication with MFA still succeeded. Restoring group membership restored access on a fresh connection.

This guide contains fictional names and documentation-only sample addressing. It does not disclose the originating environment's hostnames, user identities, public IPs, address plan, token identifiers, or secrets. It describes an implementation tested with FortiOS 7.2.x and FortiClient VPN-only 7.4.3; verify differences before using other firmware/client versions.

Architecture

FortiClient VPN-only (IKEv2 / EAP-MSCHAPv2 / PSK)
    |
    v
FortiGate dial-up IPsec tunnel
    |-- Phase 1 authusrgrp --> Individual RADIUS user + FortiToken Mobile
    |                              |
    |                              +--> Microsoft NPS --> Active Directory password
    |
    +-- Firewall identity policy --> Remote RADIUS group
                                        ^
                                        |
                          NPS Fortinet-Group-Name VSA
                                        ^
                                        |
                             AD security group membership

The key design principle is authentication is not authorization. The Phase 1 user group requires FortiToken; a distinct group returned by NPS determines application permissions. Do not grant network access to the technical MFA group.

Prerequisites

• A FortiGate with working dial-up IPsec/IKEv2 and reachable UDP/500 and UDP/4500.
• A Windows Server running NPS and registered in Active Directory.
• RADIUS connectivity from the FortiGate to NPS (typically UDP/1812), restricted by the Windows firewall.
• AD user accounts and dedicated AD Security Groups per application or role.
• FortiToken Mobile entitlements and activated tokens for the individual VPN users.
• A configuration backup and an independent management route. Do not modify an existing production tunnel when testing a separate profile.

Example-only names: RADIUS_NPS (FortiGate RADIUS server), VPN_RADIUS_MFA_AUTH (technical MFA group), VPN_APP_USERS (AD / RADIUS authorization group), VPN_APP_USERS_RADIUS (FortiGate remote group), and VPN_IKE2_MFA (dial-up tunnel). Documentation IPv4 such as 203.0.113.10 and sample LAN 10.60.10.0/24 must be replaced with actual deployment values.

1. Configure NPS and AD authorization

1. Install the Network Policy and Access Services role, register the NPS server in AD, and confirm domain connectivity.
2. Under RADIUS Clients, add the FortiGate's actual RADIUS source IP and a unique, strong shared secret. Restrict inbound RADIUS requests to this source.
3. Create a Connection Request Policy matching that RADIUS client and processing authentication on the local NPS server.
4. Create a Network Policy matching the appropriate Windows Groups condition, for example VPN_APP_USERS. Grant access and select authentication methods compatible with the implemented EAP/RADIUS flow (the tested deployment used MS-CHAPv2).
5. Under Settings → RADIUS Attributes → Vendor Specific, create the Fortinet group assignment:
   • RADIUS attribute type: Vendor-Specific (26).
   • Vendor ID: 12356 (Fortinet).
   • Vendor attribute number: 1 (Fortinet-Group-Name).
   • Data type: String.
   • Value: VPN_APP_USERS (must match the FortiGate group match string exactly).
6. Review the order of all Network Policies. NPS uses matching-policy priority: a broad policy above the intended group-specific policy can prevent the expected VSA from being returned.

Multiple authorization groups: Do not assume NPS will return every group in which a user is a member. Define a tested precedence or group-mapping scheme, especially for users who need access to multiple applications. Confirm actual returned RADIUS attributes in logs before expanding access.

2. FortiGate RADIUS server and individual FortiToken users

In User & Authentication, create a RADIUS server pointing at NPS, with the matching shared secret and controlled source IP. Then create individual Remote RADIUS Users pointing to that server and assign/activate a FortiToken for each.

Example of the intended end state (omit real token identifiers and secrets from change records):

config user local
    edit "vpn.testuser"
        set type radius
        set radius-server "RADIUS_NPS"
        set two-factor fortitoken
        # Assign a valid FortiToken through the approved administration workflow.
    next
end

Create a technical local user group, containing only the individual users who have MFA enabled:

config user group
    edit "VPN_RADIUS_MFA_AUTH"
        set member "vpn.testuser"
    next
end

Do not add RADIUS_NPS directly to this technical group. Doing so can allow a parallel authentication path that does not use the FortiToken attached to the named user.

3. Configure a separate IKEv2 tunnel

Create a new dial-up IPsec tunnel in VPN → IPsec Tunnels. Select a unique PSK, a dedicated Mode Config client address pool, DNS server, and explicit split routes. Configure Phase 1 proposals compatible with the FortiClient. For an existing remote-access gateway with multiple dial-up IKEv2 profiles, a distinct Network ID can select this tunnel.

Relevant partial Phase 1 configuration:

config vpn ipsec phase1-interface
    edit "VPN_IKE2_MFA"
        set type dynamic
        set ike-version 2
        set mode-cfg enable
        set proposal aes256-sha256
        set dhgrp 14
        set eap enable
        set eap-identity send-request
        set authusrgrp "VPN_RADIUS_MFA_AUTH"
        set network-overlay enable
        set network-id 1
    next
end

This is not a complete deployable Phase 1: also configure the real interface and gateway, PSK, DPD/NAT traversal, DNS, pool, split-routing object, and matching Phase 2. For the tested dial-up design, Phase 2 used AES256/SHA256, PFS DH14, and broad traffic selectors; firewall policies provided the actual access restriction.

Security finding: In the validated configuration, removing authusrgrp from Phase 1 enabled a connection without FortiToken through a remote RADIUS authorization-group path. Reinstating the technical MFA group in Phase 1 made the token challenge mandatory. Therefore, an established tunnel alone does not prove MFA enforcement. Always perform a negative MFA test.

4. Configure AD-group-based authorization on the FortiGate

Create a separate remote RADIUS authorization group that matches the NPS group attribute:

config user group
    edit "VPN_APP_USERS_RADIUS"
        set member "RADIUS_NPS"
        config match
            edit 1
                set server-name "RADIUS_NPS"
                set group-name "VPN_APP_USERS"
            next
        end
    next
end

In Policy & Objects → Firewall Policy, create an identity-aware rule with:

• Incoming interface: VPN_IKE2_MFA.
• Source address: dedicated VPN client pool.
• Source user/group: VPN_APP_USERS_RADIUS — not the MFA technical group.
• Outgoing interface / destination: the specific application subnet and server.
• Service: only the intended protocol/port (example: TCP/8443, not ALL).
• NAT: disabled when routing supports it.
• Logging: enabled for allowed traffic and troubleshooting.

A split tunnel only advertises routes. It does not authorize traffic. Limit advertised destinations to the required networks, too.

5. FortiClient VPN-only 7.4.3 and Network ID

Create a new, separate IPsec VPN profile; leave existing VPN profiles unchanged. Use IKEv2 with the corresponding PSK, AES256/SHA256, DH14, and Phase 2 PFS settings. The tested EAP method was EAP-MSCHAPv2 (XML eap_method=1, the default when omitted in this tested version); EAP-TTLS/PAP (2) is a different method.

When the client GUI does not expose Network ID, export/backup its VPN configuration and add these fields within the new profile's <ike_settings> section:

<networkid>1</networkid>
<version>2</version>

Re-import the appropriate XML profile using the supported FortiClient import workflow. Preserve a backup and check that the original production connection is intact. Confirm the new tunnel's allocated VPN pool after connecting.

6. Verification checklist

AD group changes and existing sessions: terminate the session and reconnect when testing revocation; do not assume that an existing authenticated session will immediately lose access on an AD membership change.

Useful read-only checks:

show vpn ipsec phase1-interface VPN_IKE2_MFA
show user group VPN_RADIUS_MFA_AUTH
show user group VPN_APP_USERS_RADIUS
diagnose vpn ike gateway list

Do not expose FortiToken serials, secrets, user email addresses, private configuration backups or identifying logs in public documentation.

7. Day-2 operations: users, groups, and revocation

Add a VPN user

1. Create/validate their AD account.
2. Add them only to the AD application groups their job requires.
3. Create an individual FortiGate Remote RADIUS User referencing NPS.
4. Assign and activate their own FortiToken Mobile.
5. Add the FortiGate user object to VPN_RADIUS_MFA_AUTH.
6. Deliver the existing dedicated MFA FortiClient profile through an approved channel.
7. Test MFA success and denial without MFA, permitted services, and blocked services.

Add an application/role group

1. Create a new AD Security Group, for example VPN_FINANCE_USERS.
2. In NPS, add a matching Network Policy whose Fortinet VSA returns exactly VPN_FINANCE_USERS; verify policy order and overlapping memberships.
3. Create VPN_FINANCE_USERS_RADIUS on the FortiGate, with RADIUS_NPS as remote member and the exact group-name match.
4. Create a new least-privilege firewall policy for the relevant VPN interface, remote RADIUS group, server and service.
5. Expand split routes only where necessary; confirm server return routing.
6. Test with a member and non-member, and confirm removal from the AD group revokes application access after a new connection.

Do not edit VPN_RADIUS_MFA_AUTH when merely granting a new application permission to someone already enrolled in VPN MFA.

Revoke an application permission

Remove the user from the relevant AD group; terminate active sessions as required; reconnect and confirm the access is blocked. For full VPN offboarding, remove the individual FortiGate user from the technical MFA group and revoke/unassign the token, in addition to the normal AD account lifecycle actions.

Troubleshooting and rollback

Rollback only the newly introduced objects and policies after checking dependencies; keep the existing VPN service unchanged. Review logs with sensitive identifiers redacted.

Further reading

• Fortinet — EAP user authentication
• Fortinet — RADIUS AVPs and VSAs
• Fortinet — FortiClient 7.4.3 XML IPsec VPN