NSE6 Part 3: FortiAuthenticator RADIUS Service, LDAP Integration, and Remote Auth

The most common reason to deploy FortiAuthenticator in a Fortinet stack is to act as a centralised RADIUS server. Rather than configuring each FortiGate, FortiSwitch, and SSL-VPN gateway to talk directly to Active Directory (which requires exposing LDAP credentials on every device), FortiAuthenticator sits in the middle: it receives RADIUS requests from NAS devices, queries AD via LDAP, and returns a response that can carry group membership, VLAN assignments, and Fortinet-specific VSAs.

---

RADIUS Concepts Recap

RADIUS (RFC 2865) is a UDP-based AAA protocol. The NAS (Network Access Server — FortiGate, FortiSwitch, etc.) acts as a RADIUS client and sends an Access-Request to the RADIUS server (FortiAuthenticator) containing the username, password (hashed with the shared secret), and NAS attributes.

FortiAuthenticator responds with one of:

• Access-Accept — authentication succeeded; may carry RADIUS attributes in the response
• Access-Reject — authentication failed
• Access-Challenge — additional information required (used for 2FA prompts)

Key attributes to know for the exam:

RADIUS Attribute	Type	Use
User-Name (1)	Standard	Username
User-Password (2)	Standard	PAP-encrypted password
NAS-Identifier (32)	Standard	String name of the NAS — used for realm routing
NAS-IP-Address (4)	Standard	IP of the NAS
Tunnel-Type (64)	Standard	Value 13 = VLAN
Tunnel-Medium-Type (65)	Standard	Value 6 = 802
Tunnel-Private-Group-ID (81)	Standard	VLAN ID string
Fortinet-Group-Name (VSA 1)	Vendor 12356	Group name for FortiGate RBAC
Fortinet-Vdom-Name (VSA 3)	Vendor 12356	VDOM selection

---

Configuring FortiAuthenticator as a RADIUS Server

Step 1 — Enable RADIUS service

Authentication > RADIUS Service > General

• Listen on: Select the interface(s) FAC should listen for RADIUS requests on. Port1 is typical.
• Port: Default 1812 (auth), 1813 (accounting). Can be changed to non-standard ports.
• Shared secret (per client): Set on the RADIUS client definition, not globally.

Step 2 — Define RADIUS clients

Authentication > RADIUS Service > Clients > Create New

Each FortiGate, FortiSwitch, or other NAS needs its own client entry:

Field	Value
Name	Descriptive (e.g. FGT-EDGE-01)
Client name/IP	IP address of the NAS sending requests
Secret	Shared secret — must match what’s configured on the NAS
RADIUS attribute value	Override attributes for this specific client

NAS-Identifier: The client can optionally send a NAS-Identifier string in requests. FAC uses this for realm routing (see below).

Step 3 — Authentication policy (realms)

Authentication > RADIUS Service > Policies

A RADIUS policy (sometimes called a realm) tells FAC which authentication source to use for requests matching certain criteria (client IP, NAS-Identifier, or username suffix).

Example policy:

Name: Corp-Users
Clients: FGT-EDGE-01 (or wildcard)
NAS-Identifier: (empty = match all)
Auth source: Local users + LDAP-AD
Require 2FA: Yes (FortiToken)

Multiple policies allow one FAC to serve different authentication sources to different NAS devices — e.g., admin RADIUS to one FortiGate goes to a local admin group, while user RADIUS for SSL-VPN goes to AD.

---

Configuring RADIUS on the NAS (FortiGate Side)

On FortiGate, the RADIUS server object points to FortiAuthenticator:

config user radius
  edit "FAC-RADIUS"
    set server "10.0.0.10"
    set secret "YourSharedSecret123"
    set auth-type auto        # PAP, CHAP, or auto
  next
end

For SSL-VPN or admin authentication:

config user group
  edit "VPN-Users"
    set member "FAC-RADIUS"
  next
end

On FortiSwitch (via FortiGate managed mode):

config switch-controller security-policy 802-1X
  edit "dot1x-policy"
    set radius-server "FAC-RADIUS"  # references FortiGate RADIUS object
  next
end

---

LDAP Integration

Rather than storing all users locally, FAC can validate authentication requests against Active Directory via LDAP.

Step 1 — Create an LDAP server object

Authentication > Remote Auth. Servers > LDAP > Create New

Field	Notes
Name	e.g. AD-CORP
Server name/IP	Domain controller IP or FQDN
Port	389 (LDAP), 636 (LDAPS), 3268 (Global Catalog)
Base DN	DC=corp,DC=example,DC=com
Bind type	Regular bind (requires admin DN + password), or anonymous (read-only AD users)
Admin DN	CN=svc-fac-ldap,OU=Service Accounts,DC=corp,DC=example,DC=com
Admin password	Service account password
Username attribute	sAMAccountName for AD, uid for OpenLDAP
Filter	(optional) Restrict which accounts can auth: (&(objectClass=user)(memberOf=CN=VPN-Users,...))

Test the connection: Test Connectivity button on the LDAP config page. If it times out, check firewall rules for TCP 389 from FAC to the domain controller.

Step 2 — Import users or use live directory

User import: FAC queries AD, creates local shadow users in the FAC database. The local user record has a pointer to the LDAP server for password validation — the actual password hash never leaves AD. Groups are imported as FAC local groups.

Schedule sync: Authentication > Remote Auth. Servers > LDAP > [server] > Import Users — set a sync schedule so new AD accounts become available automatically.

Live directory (no local copy): FAC queries AD at authentication time. No local user records. Advantage: always in sync with AD deprovisioning. Disadvantage: if AD is unreachable, authentication fails. Set live-directory = enable on the LDAP config.

The exam often tests: which mode is used when users should be automatically removed from FAC when deleted from AD? Answer: live directory.

Nested group membership

By default, FAC only checks direct group membership. Enable nested-group-search if your AD structure uses nested groups:

config user ldap
  edit "AD-CORP"
    set nested-group-search enable
  next
end

---

Authentication Rules and Realm Routing

When FAC receives a RADIUS Access-Request, it matches the request against authentication rules in order. The first matching rule determines the auth source.

Authentication > RADIUS Service > Authentication Rules

Rule conditions:

• RADIUS client (source IP)
• NAS-Identifier (string match)
• Username realm suffix (e.g. @corp.example.com)
• EAP type (for 802.1X — PEAP, TLS, TTLS)

This lets you route different auth types differently:

• Requests with NAS-Identifier = FortiSwitch-802.1X → check LDAP + dynamic VLAN response
• Requests with NAS-Identifier = FortiGate-SSL-VPN → check LDAP + require FortiToken

---

RADIUS Response Attributes and Group Mapping

RADIUS attributes in the Access-Accept tell the NAS what to do with the authenticated user.

VLAN assignment (FortiSwitch 802.1X)

Map a FAC user group to return the VLAN attributes:

Authentication > RADIUS Service > Attribute Assignments

Group: Switch-VLAN100-Users
Attributes to return:
  Tunnel-Type = VLAN (13)
  Tunnel-Medium-Type = 802 (6)
  Tunnel-Private-Group-ID = 100

When a FortiSwitch port is running 802.1X and a user in Switch-VLAN100-Users authenticates, the Access-Accept carries these three attributes and the port is dynamically assigned to VLAN 100.

FortiGate admin RBAC

Group: FGT-Admins
Attributes:
  Fortinet-Group-Name = super_admin

The FortiGate RADIUS server object must have group-override = enable to consume the Fortinet-Group-Name attribute.

---

Diagnostics

Test authentication directly

# Test a specific user against a specific remote auth server
diagnose test authserver ldap AD-CORP micheal.garner Password123

# Test via the full RADIUS path (includes policy and group matching)
diagnose test authserver radius FAC-RADIUS auto micheal.garner Password123

Live debug

diagnose debug application authd 255
diagnose debug enable
# Trigger an auth attempt on the NAS, then watch output
diagnose debug disable
diagnose debug reset

The authd debug will show:

1. RADIUS packet received from which client
2. Which authentication rule matched
3. Whether LDAP bind succeeded
4. Which groups the user is a member of
5. Which RADIUS attributes are being returned in the Access-Accept

If the LDAP bind fails, you will see:

ldap_bind failed: Can't contact LDAP server

or

ldap_bind failed: Invalid credentials

The first is a connectivity or firewall issue. The second is a wrong admin DN or password.

RADIUS accounting debug

If accounting (port 1813) is configured and logs aren’t appearing:

diagnose debug application acctd 255
diagnose debug enable

---

Common Exam Scenarios

Q: A user authenticates successfully but FortiGate doesn’t apply the correct firewall policy group. A: Check that the RADIUS server object on FortiGate has group-override = enable, and that the FAC group attribute assignment is returning Fortinet-Group-Name with the correct value.

Q: FortiSwitch 802.1X auth fails with “no matching realm” in FAC logs. A: The RADIUS request is not matching any authentication rule. Check the NAS-Identifier or client IP matches a rule in Authentication > RADIUS Service > Authentication Rules.

Q: Authentication works for AD users but newly created AD accounts fail for 24 hours. A: FAC is using user import with a daily sync schedule. Either trigger a manual sync, or switch to live directory mode.

Q: FortiAuthenticator accepts the password but returns Access-Reject after 2FA is prompted. A: Check the token is assigned to the user and is in Active state. A token in Locked state will cause FAC to reject even a correct OTP. This feeds directly into Part 4.