Untitled :: The FreeRADIUS project

#	This is a virtual server that handles *only* inner tunnel
#	requests for EAP-TTLS and PEAP types.

server inner-tunnel {

	namespace = radius

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.

listen {
	type = Access-Request
	transport = udp

	udp {
		ipaddr = 127.0.0.1
		port = 18120
	}
}

Authorization

recv Access-Request {

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.

#	copy_request_to_tunnel

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.

	filter_username

Do checks on outer / inner User-Name, so that users can’t spoof us by using incompatible identities

	filter_inner_identity

The chap module will set 'Auth-Type := ::CHAP' if we are handling a CHAP request and Auth-Type has not already been set

	chap

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.

	mschap

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.

#	unix

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.

	eap {
		ok = return
	}

Read the 'users' file

	files

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

	-sql

If you are using /etc/smbpasswd, and are also doing mschap authentication, then uncomment this line, and enable the "smbpasswd" module.

#	smbpasswd

The ldap module reads passwords from the LDAP database.

	-ldap

Enforce daily limits on time spent logged in.

#	daily

	expiration

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.

	pap
}

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 'recv Access-Request' 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 'recv Access-Request' section supplies a password. The password can be clear-text, or encrypted.

authenticate pap {
	pap
}

Most people want CHAP authentication A back-end database listed in the 'recv Access-Request' section MUST supply a CLEAR TEXT password. Encrypted passwords won’t work.

authenticate chap {
	chap
}

MSCHAP authentication.

authenticate mschap {
	mschap
}

Pluggable Authentication Modules.

#authenticate pam {
#	pam
#}

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.

#authenticate ldap {
#	ldap
#}

Allow EAP authentication.

authenticate eap {
	     eap
}

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.

send Access-Accept {

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.

#	reply_log

After authenticating the user, do another SQL query.

See "Authentication Logging Queries" in mods-config/sql/main/$driver/queries.conf

	-sql

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

#	sql_log

Uncomment the following if you have set 'edir = yes' in the ldap module sub-section of the 'modules' section.

#	ldap

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.

#	use_tunneled_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.

#	log_auth_result
}

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

send Access-Reject {

log failed authentications in SQL, too.

	-sql

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.

#	log_auth_result

	attr_filter.access_reject

Let the outer session know which module failed, and why.

	outer.session-state.Module-Failure-Message := request.Module-Failure-Message
}
} # inner-tunnel server block

Default Configuration