Inner-tunnel

This virtual server handles only inner tunnel requests for EAP-TTLS and PEAP types.

This next section allows testing of the "inner-tunnel" authentication methods. The testing is independent from the "default" server. The example listener here is configured to accept packets only sent from localhost, to localhost.

Note: There are no accounting requests inside of EAP-TTLS or PEAP tunnels.

$ radtest USER PASSWORD 127.0.0.1:18120 0 testing123

If the above test works, then the inner tunnel has been configured correctly. To check if PEAP will work, use the following:

$ radtest -t mschap USER PASSWORD 127.0.0.1:18120 0 testing123

If the above command works, then PEAP should work. If not, then fix the inner tunnel configuration so that it works.

Note: Do not run any PEAP tests. It won’t help. Instead, concentrate on fixing the inner tunnel configuration. Do nothing else.

listen {
    ipaddr = 127.0.0.1
    port = 18120
    type = auth
}

Authorization.

First preprocess (hints and huntgroups files), then realms, and finally look in the "users" file.

The order of the realm modules determines the order in which a matching realm is searched.

Make sure that 'preprocess' comes before any realm if hint setup is required for the remote radius server.

authorize {

When handling a chap request, if the Auth-Type has not already been set to chap, then the chap module will set Auth-Type := CHAP.

When an MS-CHAP-Challenge attribute is used for authentication at user login, the mschap module finds the MS-CHAP-Challenge attribute and adds Auth-Type := MS-CHAP to the request. This addition causes the server to use the mschap module for authentication.

mschap

The module below pulls crypt’d passwords from `/etc/passwd or /etc/shadow using the system APIs to get the password. To read /etc/passwd or /etc/shadow directly, see the passwd module.

unix

The following looks for IPASS style 'realm/' and, if not found, looks for '@realm' and decides whether or not to proxy based on those results.

IPASS

When using multiple kinds of realms, it is prudent to set ignore_null = yes for all of them. Otherwise, if the first style of realm doesn’t match, the other styles won’t be checked.

Note: proxying the inner tunnel authentication means that the user may use one identity in the outer session (e.g., "anonymous") and a different one here (e.g., "user@example.com"). The inner session will then be proxied elsewhere for authentication. If this section is not set up correctly, then the user’s actions may cause the authentication to be forwarded to another RADIUS server but the accounting logs would not be sent to the other server. This makes it difficult to bill people for their network activity.

suffix
ntdomain

The "suffix" module takes strips the domain (e.g., "@example.com") from the User-Name attribute, and the next few lines ensure that the request is not proxied.

To proxy the inner tunnel request, delete the next few lines.

update control {
    &Proxy-To-Realm := LOCAL
}

This module takes care of EAP-MSCHAPv2 authentication.

It also sets the EAP-Type attribute in the request attribute list to the EAP type from the packet.

The example below uses module failover to avoid querying all of the following modules if the eap module returns ok. In this case, the LDAP and/or SQL servers will not be queried for the many packets that go back and forth to set up TTLS or PEAP. The load on those servers will therefore be reduced.

eap {
    ok = return
}

This section reads the 'users' file.

files

This section looks in an SQL database. The schema of the database is meant to mirror the 'users' file.

See also "Authorization Queries" in sql.conf

The dash before the module name below is so that the server will start if the module is not configured.

-sql

When using /etc/smbpasswd in combination with mschap authentication, uncomment this line and enable the smbpasswd module.

# smbpasswd

The ldap module reads passwords from the LDAP database.

The dash before the module name below is so that the server will start if the module is not configured.

-ldap

The following enforces daily limits on time spent logged in.

daily
expiration
logintime

If no other module has set Auth-Type, then try pap. When PAP is used, the other modules listed should add a known good password to the request and let another module do the authentication. The ink:/raddb/mods-available/pap[pap] module will then see that password and use it to do PAP authentication.

This module should be listed last so that the other modules get a chance to set Auth-Type for themselves.

pap

Authentication

This section lists those modules that are available for authentication. Note that the order of this list does not mean 'try each module in order'. Instead, look for the configuration attribute Auth-Type := FOO, which is added by the authorize section. That authentication type is then used to pick the appropriate module from the list below.

In general, manually setting the Auth-Type attribute is not recommended. The server will usually figure it out on its own and will use the correct authentication method. The most common side effect of erroneously setting the Auth-Type attribute is that one authentication method will work but the others will not.

The common reasons to set the Auth-Type attribute by hand are to either forcibly reject the user (Auth-Type := Reject) or forcibly accept the user (Auth-Type := Accept).

authenticate {

The following provides PAP authentication when a back-end database listed in the authorize section supplies a password. The password can be clear-text or encrypted.

Auth-Type PAP {
    pap
}

Most people want CHAP authentication.

For CHAP authentication, back-end databases listed in the authorize section must supply a Cleartext-Password attribute; encrypted passwords won’t work.

Auth-Type CHAP {
    chap
}

mschap authentication.

Auth-Type MS-CHAP {
    mschap
}

Pluggable Authentication Modules (pam).

pam

To use ldap for authentication, uncomment the following line.

Note: uncommenting this line means "check plain-text password against the ldap database". When uncommenting this line, be aware that EAP won’t work, as it does not supply a plain-text password.

Warning

Uncommenting this line is not recommended. LDAP servers are databases. They are not authentication servers. FreeRADIUS is an authentication server and thus knows what to do with authentication. LDAP servers do not.

Auth-Type LDAP {
	ldap
}

Allows eap authentication.

eap

The following is a session database that is used for checking Simultaneous-Use. Either the radutmp or sql module can handle this section.

Note: The sql module is much faster than radutmp.

session {
    radutmp

See "Simultaneous Use Checking Queries" in sql.conf

sql

Post-Authentication

Once it is known that the user has been authenticated, there are additional steps that can be taken.

Note that the last packet of the inner-tunnel authentication may not be the last packet of the outer session. So updating the outer reply might or might not work. The exact functionality depends on both the inner and outer authentication methods.

If a reply attribute needs to be sent in the outer session, then the only safe way to send it is to set use_tunneled_reply = yes and then to update the inner-tunnel reply.

post-auth {

For privacy to remain, see the Chargeable-User-Identity attribute from RFC 4372.

To use it, just uncomment the line below.

cui-inner

To have a log of authentication replies, uncomment the following line and enable the detail reply_log module.

reply_log

After authenticating the user, this section does another SQL query.

See "Authentication Logging Queries" in sql.conf

The dash before the module name below is so that the server will start if the module is not configured.

-sql

Instead of sending the query to the SQL server, the following writes it into a log file.

sql_log

If edir_account_policy_check = yes has been set in the ldap module sub-section of the modules section, then uncomment the following.

ldap

Instead of use_tunneled_reply, uncomment the next two update blocks.

update {
    &outer.session-state: += &reply:
}

These attributes are for the inner session only. They must not be sent in the outer reply.

If the previous block is uncommented and this one is left commented out, then WiFi will not work because the client will get two MS-MPPE-keys.

update outer.session-state {
    MS-MPPE-Encryption-Policy !* ANY
    MS-MPPE-Encryption-Types !* ANY
    MS-MPPE-Send-Key !* ANY
    MS-MPPE-Recv-Key !* ANY
    Message-Authenticator !* ANY
    EAP-Message !* ANY
    Proxy-State !* ANY
}

Access-Reject packets are sent through the REJECT sub-section of the post-auth section.

The following adds the ldap module name (or instance) if edir_account_policy_check = yes has been set in the ldap module configuration.

Post-Auth-Type REJECT {

log failed authentications in SQL, too.

-sql
attr_filter.access_reject

The following lets the outer session know which module failed and why.

update outer.session-state {
    Module-Failure-Message := &request:Module-Failure-Message
}

When the server proxies a request to a home server, that request is first passed through the pre-proxy stage. This stage can re-write the request or cancel the proxy.

Only a few modules currently have this method.

pre-proxy {

Uncomment the following line to change attributes as defined in the preproxy_users file.

files

Uncomment the following line to filter requests sent to remote servers based on the rules defined in the 'attrs.pre-proxy' file.

attr_filter.pre-proxy

To have a log of packets proxied to a home server, uncomment the following line and the 'detail pre_proxy_log' section.

pre_proxy_log

When the server receives a reply to a request it proxied to a home server, the request may be massaged here in the post-proxy stage.

post-proxy {

To have a log of replies from a home server, uncomment the following line and the 'detail post_proxy_log' section.

post_proxy_log

Uncomment the following line to filter replies from remote proxies based on the rules defined in the 'attrs' file.

attr_filter.post-proxy

When proxying LEAP, the eap module must be configured and it must be listed here in the post-proxy stage.

The nostrip option must also be used in the realm configuration. Otherwise, the User-Name attribute in the proxied request will not match the user name hidden inside of the EAP packet, and the end server will reject the EAP request.

eap

If the server tries to proxy a request and fails, then the request is processed through the modules in this section.

The main use of this section is to permit robust proxying of accounting packets. The server can be configured to proxy accounting packets as part of normal processing. Thus, if the home server goes down, accounting packets can be logged to a local "detail" file for processing with radrelay. When the home server comes back up, radrelay will read the detail file and send the packets to the home server.

With this configuration, the server always responds to Accounting-Requests from the NAS, but only writes accounting packets to disk if the home server is down.

Post-Proxy-Type Fail {
    detail
}