Local 802.1x RADIUS Authentication Service

A primary component of the 802.1x authentication process is the RADIUS server. WLAN users are unable to authenticate and are denied access to the WLAN network if the RADIUS server becomes unavailable. Therefore, it is necessary to provide redundancy for RADIUS services. Depending on the network topology, RADIUS redundancy deployment might differ. In the case of a remote branch office (or a remote store), it is preferred to deploy local redundancy for RADIUS services because the primary RADIUS server is usually located at a central site. Thus, if the primary RADIUS server becomes unreachable (for example, due to WAN link failure), you can use the local fallback RADIUS server. You can use the local 802.1x authentication service available on IOS APs (release 12.2[11]JA and above) or a 2600/3700 series router acting as the WDS server to provide fallback 802.1x RADIUS authentication service for LEAP and EAP-FAST users. You can configure standalone APs or the WDS server running the local 802.1x RADIUS authentication service to periodically monitor the availability of the primary RADIUS server. When the primary RADIUS server becomes available, the WDS server and the standalone APs will revert to using it.

The following is a summary of the local 802.1x RADIUS authentication service capabilities:

  • The local 802.1x RADIUS server can reside within an active AP (on a standalone AP, WDS client AP, or an AP acting as the WDS server). Alternatively, the local 802.1x RADIUS server can reside on a branch office router (2600/3700 series).

  • The local 802.1x RADIUS server will attach to the standard RADIUS UDP port number (such as UDP port number 1812 for authentication) and listen for RADIUS request packets.

  • The local 802.1x RADIUS server handle client authentication and AP infrastructure authentication.

  • An operator will manually configure the database of valid users. The database will not be automatically synchronized with the primary RADIUS server. Up to 50 users can be supported on the local 802.1x RADIUS server.

  • If a username is removed from the corporate server for security reasons (such as an employee quitting), the operators must remember to remove the name from each of the remote servers.

  • Configurable parameters on the local 802.1x RADIUS server are as follows:

    - NAS settings? Specifies the IP address and shared secret for an AP

    - User account configuration? Username, password (both cleartext and NT-hash formats), and group ID association

    - Group settings? IETF attribute 27 (session timeout value), list of allowed SSIDs, client lock-out parameters (number of failed attempts to lock out a client and the lock-out timer before a locked out client is allowed to reauthenticate)

The local RADIUS server is preconfigured on a standalone AP or on the WDS server (if the functionality is available) as the secondary RADIUS server. When the primary RADIUS server becomes unreachable (the default is three consecutive nonresponses from the RADIUS server), the standalone AP or the WDS server falls back to the specified local RADIUS server. Figure 9-10 shows the deployment of a local 802.1x RADIUS authentication service in a remote branch office scenario. When an authenticator (standalone AP or the WDS server) fails to reach the primary RADIUS server after a certain number of tries (the default is three but is configurable), the authenticator falls back to the local RADIUS server (defined as the secondary RADIUS server).

Figure 9-10. Local 802.1x RADIUS Authentication Service Deployment


A "dead RADIUS server" timer interval is configurable on each AP to recheck for the availability of the primary RADIUS server(s). At every dead timer interval, the primary servers are re-enabled and tried again on the next authentication. The dead timer setting is a trade-off between timing out on the unreachable servers too often and not seeing the WAN link and servers come up as soon as possible. Thus, it is recommended that you configure an appropriate value for the dead timer depending on the deployment scenario. When the standalone AP or the WDS server tries the main servers while they are down, the radio client trying to authenticate usually reports an authentication timeout.