RADIUS and EAP between FortiAuthenticator, FortiGate, and FortiAnalyzer

[tanr]

I’m using a FortiAuthenticator 200D v5.4.1 as a CA and to provide RADIUS service to some FortiGates (300D and 100D) v5.4.1, a FortiAnalyzer 200D v5.4.1, and to some FortiAPs v5.4.1.

No LDAP or AD in the setup, just the FAC providing authentication and group information for its locally defined users and locally defined admins, within some defined realms.  Some of the admin users have two-factor authentication with FortiTokens.

I can make this work, authenticating RADIUS users through the FortiGate’s local captive portal, doing two-factor authentication for a RADIUS admin from the FAZ, etc.  I've specified a server-side certificate on the FAC to authenticate the RADIUS server to clients.

What I am having trouble with, and not finding full documentation for, is how to enforce the use of specific forms of EAP, and how to enforce what form of encapsulation/encryption is uses to transport and protect EAP over the wire.

The documentation for RADIUS use and authentication types are different for all three devices.

FortiAuthenticator Docs for Radius Service client profile EAP Types:

  EAP               ServerAuth  ClientAuth  Encryption  NativeOS-Support

  PEAP (MSCHAPv2)   Yes         Yes         Yes         Windows XP, Vista, 7

  EAP-TTLS          Yes         No          Yes         Windows Vista, 7

  EAP-TLS           Yes         Yes         Yes         Windows (XP, 7), Mac OS X, iOS, Linux, Android

  EAP-GTC           Yes         Yes         Yes         None (external supplicant required)

Fortigate Docs for Radius Server Authentication Method:

- MS-CHAP-v2

- MS-CHAP

- CHAP

- PAP (all in the clear)

FortiAnalyzer Docs for Radius Server Authentication Types:

- PAP

- CHAP

- MSv2

 The FAC EAP types are a little ambiguous:

-   PEAP could mean PEAPv0, with PEAP as an SSL wrapper around EAP, or mean PEAPv1 (which uses EAP-GTC), or both

-   EAP-TLS may or may not require the client to authenticate with its own certificate

-   EAP-GTC could actually mean PEAPv1 (which uses EAP-GTC)?

Now to the odd results.

For local non-admin users on the RADIUS server, I can authenticate them from the FGT through the CLI with

  diag test auth radius RadServerName EapProto UserName PassWd

But regardless of which EAP protocol I use in the CLI command (pap, chap, mschap, mschap2), AND regardless of which EAP types I have checked on the matching FAC Radius Client profile’s EAP types (EAP-GTC, EAP-TLS, PEAP, EAP-TTLS), AND regardless of what Authentication Method I’ve specified for the Radius Server defined on the FGT, the login always succeeds (as long as the username and password are correct) and I get back the user’s group.

So, it appears the EAP types set on the FAC aren’t enforced?

Or the test from the FGT doesn’t enforce the EAP type specified?

Or both, it seems.

If I instead try to authenticate a FAC local admin (with RADIUS authentication allowed), then the CLI auth test ONLY succeeds if the the protocol specified is PAP (meaning clear text).  Again, it doesn’t seem to matter which EAP types are specified on the FAC.  This is also seen from the FortiAnalyzer, where I can only authenticate an admin user on the FAC if I specify PAP on the FAZ.

When any of these authentications fails, all I see in the FAC logs is “Local administrator authentication(chap/mschap) with FortiToken failed: invalid user parameter”

Is anybody successfully authenticating users (normal or admin) against the (non-remote) RADIUS service on the FAC and actually managing to enforce the EAP types?   Am I just missing some basic setup somewhere?

Thanks in advance for any suggestions.