rlm_eap

Synopsis

Configuration for EAP types (PEAP, TTLS, etc.). EAP types not listed here may be supported via the eap2 module.

Note	Do not set `Auth-Type := EAP`. The server is smart enough to figure this out on its own. The most common side effect of setting `Auth-Type := EAP` is that the users then cannot use any other authentication method.

Default configuration

Processing Sections

authorize

When listed in the authorize section, the eap module looks for the EAP-Message attribute in the Access-Request packet. If found, the module sets Auth-Type := EAP.

Return codes: noop No EAP-Message attribute was found in the packet.
: fail The EAP-Message contained an invalid EAP packet.
: handled The EAP-Message contained an EAP-Start packet, and the server will respond with an EAP-Identity request.
: ok The module is processing EAP-TTLS or PEAP, and has not yet set up the inner tunnel.
: updated The module set Auth-Type := EAP, and processing is continuing.

authenticate

When listed in the authenticate section, the eap module performs EAP authentication. It calls an EAP sub-module to perform the authentication.

Return codes: fail The EAP-Message contained an invalid EAP packet.
: invalid The EAP packet cannot be resolved to a known EAP type.
: handled The inner EAP data will be proxied to another server.
: ok The request was successfully authenticated by the EAP type.
: rejected The request was rejected by the EAP type.

post-auth

When listed in the post-auth section, the eap module updates the reply for EAP failures. This is done only for the Post-Auth-Type Reject section.

The use-case here is that another module may reject the user. However, the EAP standards still require that an EAP-Fail is sent inside of the Access-Reject. The eap module will look for this situation, and ensure that the reject packet contains the correct information.

Return codes: noop The Access-Request does not contain EAP-Message, or the reply is an Access-Accept.
: fail The module was unable to create an EAP packet.
: updated The module added an EAP-Message contain an EAP failure, and also added a Message-Authenticator attribute to the Access-Reject packet.

post-proxy

When listed in the post-proxy section, the eap module updates the Cisco-specific attributes for the leap method.

When the inner EAP data was proxied, the module also calls the EAP type to finish processing the encapsulating EAP type.

Return codes: noop There was no inner EAP session, and no leap information.
: fail There is an inner EAP session, but there was a problem retrieving it.
: reject The inner EAP session rejected the session.
: ok The inner EAP session continued processing the request.
: updated The leap information was successfully updated.

Expansions

None.

Directives

cisco_accounting_username_bug

Syntax: cisco_accounting_username_bug = boolean
Default: no
Description: Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given a User-Name attribute in an Access-Accept, it copies one more byte than it should. Cisco_accounting_username_bug provides a reconfigured workaround (an extra zero byte is added).

default_eap_type

Syntax: default_eap_type = string
Default: md5
Description: Invokes the default supported EAP type when the EAP-Identity response is received. The incoming EAP messages do not specify which EAP type they will be using, so it must be set here. For now, only one default EAP type may be used at a time. If the EAP-Type attribute is set by another module, then that value takes precedence over the default type configured here.

ignore_unknown_eap_types

Syntax: ignore_unknown_eap_types = boolean
Default: no
Description: There are many EAP types, but the server has support for only a limited subset. If the server receives a request for an EAP type it does not support, then it normally rejects the request. By setting this configuration to yes, you can tell the server to instead keep processing the request. Another module must then be configured to proxy the request to another RADIUS server which supports that EAP type. If another module is not configured to handle the request, then the request will still end up being rejected.

The only reason to set this value to yes is if you are writing your own experimental EAP type.

max_sessions

Syntax: max_sessions = integer
Default: 4096
Description: Helps prevent DoS attacks by limiting the number of sessions that the server is tracking. Most systems can handle a hundred or so simultaneous EAP sessions per second, so the default limit of 4096 should be sufficient.

timer_expire

Syntax: timer_expire = integer
Default: 60
Description: A list is maintained to correlate EAP-Response packets with EAP-Request packets. After the above configurable length of time, entries in the list expire, and are deleted. Requests are also deleted when the EAP session either succeeds or fails. i.e. This timer is used only for unfinished sessions.

Setting this value too low means that slow EAP sessions will get deleted before they finish. That configuration is not recommended.

Setting this value too high means that a little more memory is used than necessary.

In general, EAP sessions should finish within a few seconds.

Supported EAP-types

The EAP module has a number of sub-sections which contain configurations for each EAP type. Please see the following links for information on each EAP type.

Generic Token Card (gtc)

Secure Password-based Authentication (pwd)

tls

ttls

The tls parameters are configured separately from the EAP-TLS configuration. See the tls-common section.