






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 https://tools.ietf.org/html/rfc4372[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
```
