Description
This article describes the authentication-related limitations that an administrator will encounter when configuring the Wireless SSID for WPA2-Enterprise and Local Authentication on the FortiGate, rather than using the RADIUS Server authentication option.
Scope
FortiGate, FortiAP.
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.
In this situation, 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.
- Using LDAP-based authentication restricts administrators to using EAP methods that support plaintext authentication schemes only (like the older EAP-TTLS/PAP).
- The reason for this is that the FortiGate must be able to obtain the credentials of the user through EAP, then forward those credentials to the LDAP server. However, the client will provide the credentials to the FortiGate in the format negotiated as part of EAP, which can include hashing the password.
- LDAP does not support password hashing schemes like CHAP, MSCHAP, or MSCHAPv2, so those options cannot be used during EAP authentication.
- This may limit EAP authentication options to just EAP-TTLS, as it is an older authentication method that still supports using cleartext PAP authentication as the inner method.
As a final note:
- RADIUS and TACACS+ can natively support PAP, CHAP, MSCHAP, and MSCHAPv2, and this allows for more flexibility toward EAP authentication (the hashed password sent by the client can be directly forwarded from the FortiGate to the authentication server).
- Local Users/Groups on the FortiGate will also support the above authentication methods since the FortiGate has the plaintext username/password accessible locally.
- Technically, it is possible to use hashed authentication schemes like CHAP, MSCHAP, and MSCHAPv2 with LDAP-based Local WiFi Authentication. However, it would require the LDAP/Domain administrator to manually set the 'userPassword' attribute for each user in Active Directory to that user's plaintext password. This allows the FortiGate to retrieve the plaintext password from the LDAP server and compare it against the password supplied by the client.
Related Articles
Technical Tip : FortiOS LDAP and WiFi WPA/WPA2 - enterprise security mode (older)
