Description
Scope
Solution
When configuring WPA2-Enterprise for WiFi on the FortiGate/FortiAP, the general recommendation is to set Authentication to 'RADIUS Server'. This allows the FortiGate to operate as an EAP pass-through authenticator and simply forward the authentication traffic between the wireless client (aka the Supplicant) and the RADIUS Authentication Server:
Supplicant (WiFi Client) -> EAP over LAN (EAPOL) -> Authenticator (FortiGate) -> EAP messages over RADIUS -> Authentication Server (RADIUS).
In some scenarios, it may be not possible to set up a RADIUS server to handle this EAP authentication. In those cases, the SSID can instead be configured to use Local Authentication for WPA2-Enterprise instead, where EAP authentication is performed between the Supplicant and the FortiGate on the front end and another authentication scheme (e.g. Local, LDAP, RADIUS, TACACS+) is used on the back end to authenticate and authorize the user for access.
While this can work well, there are some limitations when using Local Authentication for a WPA2-Enterprise SSID that should be kept in mind:
- The FortiGate supports a number of EAP authentication methods, including EAP-TLS, EAP-TTLS, and PEAP. However, it does not provide a way to specify/limit which method a client should use when connecting.
- This can be problematic if certain security requirements regarding WiFi network access need to be met (i.e. organizations disallow older EAP methods from being used).
- It can also be an issue if users rely on their devices to auto-select the appropriate EAP method to use when connecting to WiFi, as the device could choose the non-preferred settings (Windows, for example, will run through a list of EAP options one by one until the first available one is matched).
- This can be worked around by having users manually create wireless network profiles on the devices with the desired settings, but this can be burdensome for end-users, especially in BYOD environments.
- For guidance on creating manual wireless profiles for Windows 10, refer to the following FortiAuthenticator documentation: FortiAuthenticator Cookbook - Configuring Windows 10 wireless profile to use certificate
- When using LDAP-based authentication with Local Authentication, administrators are restricted to using EAP methods that support plaintext authentication schemes only (like the older EAP-TTLS/PAP). The reason that this is necessary is because authentication is happening in two stages:
- On the front end, the FortiGate and wireless client are authenticating via EAP, which negotiates and supports password hashing schemes like CHAP, MSCHAP, or MSCHAPv2 (for example, PEAP/MSCHAPv2 is the most common username/password scheme used for WPA2-Enterprise wireless networks).
- However on the back end the FortiGate must forward the client's credentials to an LDAP server, and the LDAP protocol notably does not support these password hashing schemes (i.e. it is expecting the credentials to be provided in plaintext).
- Since the back-end LDAP authentication requires plaintext credentials to be provided, the front-end EAP authentication must also use a protocol that supports plaintext credential submission. This limits administrators to EAP-TTLS only, as it is an older authentication method that still supports using cleartext PAP authentication as the inner method.
Additional Notes:
- RADIUS and TACACS+ natively support PAP, CHAP, MSCHAP, and MSCHAPv2, and so using Local Authentication with these protocols allows for more flexibility on the front-end EAP authentication (e.g. PEAP/MSCHAPv2 would become a supported EAP method since the back-end authentication server is capable of understanding/accepting hashed credentials sent by the wireless client).
- Local Users/Groups on the FortiGate will also support the above authentication methods since the FortiGate has the plaintext username/password accessible locally (i.e. it can accept hashed credentials from the client and then compare them against the hashes of the locally-known credentials).
- Technically, it is possible to use hashed authentication schemes like CHAP, MSCHAP, and MSCHAPv2 with LDAP-based Local WiFi Authentication. However, it requires the LDAP/domain administrator to manually set the 'userPassword' attribute for each user in Active Directory to that user's plaintext password.
- This does allow the FortiGate to retrieve the plaintext password from the LDAP server and compare it against the password supplied by the client, but it is both burdensome for administrators to implement and also carries significant security risks (since the password is now available in plaintext format within LDAP).
Related articles:
Technical Tip: FortiOS LDAP and WiFi WPA/WPA2 - enterprise security mode (older)
