This next section is here to allow testing of the "inner-tunnel" authentication methods, independently from the "default" server. It is listening on "localhost", so that it can only be used from the same machine.
$ radtest USER PASSWORD 127.0.0.1:18120 0 testing123
If it works, you have configured the inner tunnel correctly. To check if PEAP will work, use:
$ radtest -t mschap USER PASSWORD 127.0.0.1:18120 0 testing123
If that works, PEAP should work. If that command doesn’t work, then
FIX THE INNER TUNNEL CONFIGURATION SO THAT IT WORKS.
Do NOT do any PEAP tests. It won’t help. Instead, concentrate on fixing the inner tunnel configuration. DO NOTHING ELSE.
Authorization
The 'copy_request_to_tunnel' option has been removed from from v4.0.
Individual attributes from the outer request may be accessed with:
&outer.request.<attribute>
The following policy in raddb/policy.d/eap can be used to copy attributes over.
Take a User-Name, and perform some checks on it, for spaces and other invalid characters. If the User-Name appears invalid, reject the request.
See policy.d/filter for the definition of the filter_username policy.
Do checks on outer / inner User-Name, so that users can’t spoof us by using incompatible identities
The chap module will set 'Auth-Type := ::CHAP' if we are handling a CHAP request and Auth-Type has not already been set
If the users are logging in with an MS-CHAP-Challenge attribute for authentication, the mschap module will find the MS-CHAP-Challenge attribute, and add 'Auth-Type := ::MS-CHAP' to the request, which will cause the server to then use the mschap module for authentication.
Pull crypt’d passwords from /etc/passwd or /etc/shadow, using the system API’s to get the password. If you want to read /etc/passwd or /etc/shadow directly, see the passwd module, above.
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". Therefore, your 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.
Read the 'users' file
Look in an SQL database. The schema of the database is meant to mirror the "users" file.
See "Authorization Queries" in mods-config/sql/main/$driver/queries.conf
If you are using /etc/smbpasswd, and are also doing mschap authentication, then uncomment this line, and enable the "smbpasswd" module.
The ldap module reads passwords from the LDAP database.
Enforce daily limits on time spent logged in.
If no other module has claimed responsibility for authentication, then try to use PAP. This allows the other modules listed above to add a "known good" password to the request, and to do nothing else. The 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.
Authentication.
This section lists which modules are available for authentication. Note that it does NOT mean 'try each module in order'. It means that a module from the 'authorize' section adds a configuration attribute 'Auth-Type := ::FOO'. That authentication type is then used to pick the appropriate module from the list below.
In general, you SHOULD NOT set the Auth-Type attribute. The server will figure it out on its own, and will do the right thing. 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 is to either forcibly reject the user, or forcibly accept him.
NB You cannot forcibly accept an EAP authentication!
PAP authentication, when a back-end database listed in the 'authorize' section supplies a password. The password can be clear-text, or encrypted.
Most people want CHAP authentication A back-end database listed in the 'authorize' section MUST supply a CLEAR TEXT password. Encrypted passwords won’t work.
MSCHAP authentication.
Pluggable Authentication Modules.
Uncomment it if you want to use ldap for authentication
Note that this means "check plain-text password against the ldap database", which means that EAP won’t work, as it does not supply a plain-text password.
We do NOT recommend using this. LDAP servers are databases. They are NOT authentication servers. FreeRADIUS is an authentication server, and knows what to do with authentication. LDAP servers do not.
Allow EAP authentication.
Post-Authentication Once we KNOW that the user has been authenticated, there are additional steps we can take.
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 work, and sometimes MIGHT NOT. The exact functionality depends on both the inner and outer authentication methods.
If you need to send a reply attribute in the outer session, the ONLY safe way is to set the outer session-state list. Attributes that should be provided in the reply should be copied to the outer.session-state list:
&outer.session-state.Attribute := <Value>
The default configuration in the outer post-auth "send" section will copy this to the reply. To copy the entire reply see "use_tunneled_reply" below.
If you want privacy to remain, see the Chargeable-User-Identity attribute from RFC 4372. If you want to use it just uncomment the line below. cui-inner
If you want to have a log of authentication replies, uncomment the following line, and enable the 'detail reply_log' module.
After authenticating the user, do another SQL query.
See "Authentication Logging Queries" in mods-config/sql/main/$driver/queries.conf
Instead of sending the query to the SQL server, write it into a log file.
Uncomment the following if you have set 'edir = yes' in the ldap module sub-section of the 'modules' section.
Instead of the "use_tunneled_reply" option in previous versions of the server, uncomment the following line to copy reply attributes from the inner-tunnel back to the outer session-state. The outer "send Access-Accept" section will then copy them from the session-state into the reply.
Call an instance of linelog to log the authentication success
- equivalent to the previous log auth = yes option in v3.
See mods-enabled/linelog for message formats and destinations.
Access-Reject packets are sent through the REJECT sub-section of the post-auth section.
Add the ldap module name (or instance) if you have set 'edir = yes' in the ldap module configuration
log failed authentications in SQL, too.
Call an instance of linelog to log the authentication failure
- equivalent to the previous log auth = yes option in v3.
See mods-enabled/linelog for message formats and destinations.
Let the outer session know which module failed, and why.
Default Configuration
# This is a virtual server that handles *only* inner tunnel
# requests for EAP-TTLS and PEAP types.
server inner-tunnel {
namespace = radius
listen {
type = Access-Request
transport = udp
udp {
ipaddr = 127.0.0.1
port = 18120
}
}
recv Access-Request {
# copy_request_to_tunnel
filter_username
filter_inner_identity
chap
mschap
# unix
eap {
ok = return
}
files
-sql
# smbpasswd
-ldap
# daily
expiration
pap
}
authenticate pap {
pap
}
authenticate chap {
chap
}
authenticate mschap {
mschap
}
#authenticate pam {
# pam
#}
#authenticate ldap {
# ldap
#}
authenticate eap {
eap
}
send Access-Accept {
# reply_log
-sql
# sql_log
# ldap
# use_tunneled_reply
# log_auth_result
}
send Access-Reject {
-sql
# log_auth_result
attr_filter.access_reject
&outer.session-state.Module-Failure-Message := &request.Module-Failure-Message
}
} # inner-tunnel server block