default

This configuration is designed to work in the widest possible set of circumstances with the widest possible number of authentication methods. This means that in general, very few changes to this file are required.

The best way to configure the server for a local system is to carefully edit this file. Most attempts to make large edits to this file will break the server. Any edits should be small and tested by running the server with radiusd -X. Once the edits have been verified to work, save a copy of these configuration files somewhere (e.g., as a "tar" file). Then make more edits and test, as above.

There are many "commented out" references to modules such as ldap, sql, etc. These references serve as place-holders. If the functionality of that module is needed, then it can be configured in radiusd.conf, and the references to it can be uncommented in this file. In most cases, those small changes will result in the server being able to connect to the DB and to authenticate users.

server default

listen {
    type = auth
    ipaddr = *
    port = 0

    limit {
        max_connections = 16
        lifetime = 0
        idle_timeout = 30
    }
}

listen {
    ipaddr = *
    port = 0
    type = acct

    limit {
    }
}

IPv6 version

listen {
    type = auth
    ipv6addr = :: any.  ::1 == localhost
    port = 0

    limit {
        max_connections = 16
        lifetime = 0
        idle_timeout = 30
    }
}

listen {
    ipv6addr = ::
    port = 0
    type = acct

    limit {
    }
}

Authorization

This contains the authorize section, which is processed when the server receives an Access-Request packet.

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

Any changes made here should also be made to the "inner-tunnel" virtual server.

The order of the realm modules will determine the order in which a matching realm is found.

Make sure that 'preprocess' comes before any realm when setting up hints for the remote radius server.

authorize {

This policy takes a User-Name and performs checks on it for spaces and other invalid characters. If the User-Name appears invalid, then the request is rejected.

See policy.d/filter for the definition of the filter_username policy.

The User-Name policy is filtered first to ensure that all of the subsequent modules have a "clean" and "correct" User-Name.

	filter-username

Once the User-Name is sanitized, the preprocess module sanitizes some non-standard format attributes in the request and turns them into attributes that have a standard format.

This module takes care of processing the raddb/hints and the raddb/huntgroups files.

	preprocess

If CUI will be used and the Operator-Name will be required to be set for CUI generation and CUI will also be generated for local clients, then uncomment the operator-name and set the operator-name for your clients in clients.conf

#	operator-name

To generate CUI for some clients that do not send proper CUI requests, uncomment the cui line and set add_cui = yes for these clients in clients.conf

#	cui

To generate a log of authentication requests, un-comment the following line

#	auth_log

The chap module will set Auth-Type := CHAP for requests which contain a CHAP-Password attribute.

	chap

When users log in with an MS-CHAP-Challenge attribute for authentication, the mschap module finds the MS-CHAP-Challenge attribute and adds 'Auth-Type := MS-CHAP' to the request, which causes the server to then use the mschap module for authentication.

	mschap

If a Cisco SIP server is used to authenticate against FreeRADIUS, then the digest lines, both here and in the 'authenticate' section, should be uncommented.

	digest

The WiMAX specification states that the Calling-Station-Id is 6 octets of the MAC. This definition conflicts with RFC 3580 and with all common RADIUS practices. Uncommenting the wimax module here means that it will fix the Calling-Station-Id attribute to the normal format as specified in RFC 3580 Section 3.21.

#	wimax

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, set "ignore_null = yes" for all of them. Otherwise, if the first style of realm doesn’t match, then the other styles won’t be checked.

	suffix
#	ntdomain

The eap module takes care of EAP-MD5, EAP-TLS, and EAP-LEAP authentication.

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

As of 2.0, the EAP module returns "ok" in the authorize stage for TTLS and PEAP. In 1.x, it never returned "ok" here, so this change is compatible with older configurations.

The example below uses module failover to avoid querying all of the following modules in the event that the EAP module returns "ok". Therefore, any 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
	}

Unix 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 in radiusd.conf.

#	unix

Files reads the 'users' file.

	files

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

See "Authorization Queries" in sql.conf.

	-sql

When using /etc/smbpasswd while doing mschap authentication, uncomment this line and configure the smbpasswd module.

#	smbpasswd

The ldap module reads passwords from the LDAP database.

	-ldap

Enforces daily limits on time spent logged in.

#	daily

	expiration
	logintime

If no other module has claimed responsibility for authentication, then try pap. This process allows the other modules listed above to only add a "known good" password to the request and 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

If "status_server = yes", then Status-Server messages are passed through the following section and only the following section. This permits DB queries, for example. If the modules listed here return "fail", then no response is sent.

	Autz-Type Status-Server {

	}
}

Authentication.

This is the authentication section.

This section lists those modules that are available for authentication. Note that the order of modules listed below does not mean 'try each module in order'. Instead, 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, the Auth-Type attribute should not be set. 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.

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

Note that Auth-Type := Accept will NOT work with EAP.

Please do not put "unlang" configurations into the "authenticate" section. Put them in the "post-auth" section instead. That’s what the post-auth section is for.

authenticate {

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. A back-end database listed in the `authorize section must supply a clear text password. Encrypted passwords won’t work.

 	Auth-Type CHAP {
		chap
	}

MSCHAP authentication.

	Auth-Type MS-CHAP {
		mschap
	}

When a Cisco SIP server is authenticating against FreeRADIUS, this line and the digest line in the authorize section should both be uncommented.

	digest

Pluggable Authentication Modules (pam).

#	pam

Uncomment this line to use ldap for authentication.

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

This method is not recommended. 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.

#	Auth-Type LDAP {
#		ldap
#	}

Allows for EAP authentication.

eap

The older configurations sent a number of attributes in Access-Challenge packets, which wasn’t strictly correct. To filter out these attributes, uncomment the following lines:

#	Auth-Type eap {
#		eap {
#			handled = 1
#		}
#		if (handled && (Response-Packet-Type == Access-Challenge)) {
#			attr_filter.access_challenge.post-auth
#			handled  # override the "updated" code from attr_filter
#		}
#	}
}

Pre-accounting.

This is the pre-accounting section. This section decides which accounting type to use.

preacct {
	preprocess

Merges Acct-[Input|Output]-Gigawords and Acct-[Input-Output]-Octets into a single 64bit counter Acct-[Input|Output]-Octets64.

#	acct_counters64

Session start times are implied in RADIUS. The NAS never sends a "start time". Instead, it sends a start packet, possibly with an Acct-Delay-Time. The server is supposed to conclude that the start time was "Acct-Delay-Time" seconds in the past.

The code below creates an explicit start time that can then be used in other modules. It will be mostly correct. Any errors are due to the 1-second resolution of RADIUS and the possibility that the time on the NAS may be off.

The start time is: NOW - delay - session_length

#	update request {
#		FreeRADIUS-Acct-Session-Start-Time = "%{expr: %l - %{%{Acct-Session-Time}:-0} - %{%{Acct-Delay-Time}:-0}}"
#	}

Ensures that a semi-unique identifier is available for every request because many NAS boxes are broken.

	acct_unique

Looks for IPASS-style 'realm/' and, if not found, looks for '@realm' and decides whether or not to proxy based on that result.

Accounting requests are generally proxied to the same home server as authentication requests.

#	IPASS
	suffix
#	ntdomain

The files module reads the 'acct_users' file.

	files
}

Accounting

This is the accounting section. It logs the accounting data.

accounting {

Updates accounting packets by adding the CUI attribute recorded from the corresponding Access-Accept. Use this process only if the NAS boxes do not support CUI themselves.

#	cui

Creates a 'detail'ed log of the packets. Note that accounting requests that are proxied are also logged in the detail file.

	detail
#	daily

The unix module updates the wtmp file.

If not using "radlast", this line can be deleted.

	unix

The radutmp and sradutmp modules are for Simultaneous-Use tracking.

Because of packet losses in the network, the data here may be incorrect. There is little that can be done about it.

#	radutmp
#	sradutmp

Returns an address to the IP Pool when a stop record is viewed.

#	main_pool

Logs traffic to an SQL database.

See "Accounting queries" in sql.conf

	-sql

Stop packets with zero session length are not logged in the database. The SQL module will print a message (only in debugging mode) and will return "noop".

These packets can be ignored by uncommenting the following three lines. Otherwise, the server will not respond to the accounting request, and the NAS will retransmit.

#	if (noop) {
#		ok
#	}

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

#	sql_log

Cisco VoIP specific bulk accounting.

#	pgsql-voip

For Exec-Program and Exec-Program-Wait.

	exec

Filter attributes from the accounting response.

	attr_filter.accounting_response

See "Autz-Type Status-Server" for how this section works.

#	Acct-Type Status-Server {
#
#	}
}

Session database, used for checking Simultaneous-Use. Either the radutmp or sql module can handle this section.

The sql module is much faster than the radutmp module.

session {
#	radutmp

See "Simultaneous Use Checking Queries" in sql.conf

#	sql
}

Post-Authentication

This is the post-authentication section.

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

post-auth {

If a State attribute is required, it can be added below (e.g., for later CoA-Request with State and Service-Type = Authorize-Only).

#	if (!&reply:State) {
#		update reply {
#			State := "0x%{randstr:16h}"
#		}
#	}

For EAP-TTLS and PEAP, this module adds the cached attributes to the reply. The "session-state" attributes are automatically cached when an Access-Challenge is sent and are automatically retrieved when an Access-Request is received.

The session-state attributes are automatically deleted after an Access-Reject or an Access-Accept is sent.

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

Retrieves an address from the IP Pool.

#	main-pool

This module creates the CUI value and adds the attribute to Access-Accept. Uncomment this line if returning the CUI.

#	cui

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

#	reply-log

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

See "Authentication Logging Queries" in sql.conf

	-sql

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

#	sql_log

To modify the user’s object in LDAP after a successful login, uncomment the ldap line.

#	ldap

For Exec-Program and Exec-Program-Wait.

	exec

Calculates the various wimax keys. For this to work, the WiMAX NAI must be defined, usually via:

#	update request {
#		WiMAX-MN-NAI = "%{User-Name}"
#	}

For various keys to be calculated, the reply should be updated with template values. The module will see this update and will replace the template values with the correct ones taken from the cryptographic calculations, e.g.:

#	update reply {
#		WiMAX-FA-RK-Key = 0x00
#		WiMAX-MSK = "%{EAP-MSK}"
#	}

Some WiMAX clients behave badly when the the MS-MPPE--Keys attributes are included; in this case, the MS-MPPE--Keys may be deleted. See raddb/modules/wimax, configuration entry "delete_mppe_keys" for more information.

#	wimax

If there is a client certificate (EAP-TLS, sometimes PEAP and TTLS), then some attributes are filled out after the certificate verification has been performed. These fields may be available during the authentication or they may be available only in the post-auth section.

The first set of attributes contains information about the issuing certificate that is being used. The second contains information about the client certificate (if available).

#	update reply {
#		Reply-Message += "%{TLS-Cert-Serial}"
#		Reply-Message += "%{TLS-Cert-Expiration}"
#		Reply-Message += "%{TLS-Cert-Subject}"
#		Reply-Message += "%{TLS-Cert-Issuer}"
#		Reply-Message += "%{TLS-Cert-Common-Name}"
#		Reply-Message += "%{TLS-Cert-Subject-Alt-Name-Email}"
#
#		Reply-Message += "%{TLS-Client-Cert-Serial}"
#		Reply-Message += "%{TLS-Client-Cert-Expiration}"
#		Reply-Message += "%{TLS-Client-Cert-Subject}"
#		Reply-Message += "%{TLS-Client-Cert-Issuer}"
#		Reply-Message += "%{TLS-Client-Cert-Common-Name}"
#		Reply-Message += "%{TLS-Client-Cert-Subject-Alt-Name-Email}"
#	}

This line inserts the class attribute (with unique value) into the response, aids matching auth and acct records, and protects against duplicate Acct-Session-Id.

Note: This module only works if the NAS has implemented RFC 2865 behaviour for the class attribute and if the NAS supports long Class attributes. Many older or cheap NASes only support 16-octet Class attributes.

#	insert_acct_class

MacSEC requires the use of EAP-Key-Name, which should not be sent for all EAP sessions. Therefore, the EAP modules put required data into the EAP-Session-Id attribute. This attribute is never put into a request or reply packet.

Uncomment the next few lines to copy the required data into the EAP-Key-Name attribute:

#	if (&reply:EAP-Session-Id) {
#		update reply {
#			EAP-Key-Name := &reply:EAP-Session-Id
#		}
#	}

Removes reply message if the response contains an EAP-Message.

	remove_reply_message_if_eap

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

This section adds the ldap module name (or instance) if 'edir_account_policy_check = yes' in the ldap module configuration.

The "session-state" attributes are not available here.

	Post-Auth-Type REJECT {

Logs failed authentications in SQL, too.

		-sql
		attr_filter.access_reject

Inserts EAP-Failure message if the request was rejected by policy rather than being rejected owing to an authentication failure.

eap

Removes the reply message if the response contains an EAP-Message.

		remove_reply_message_if_eap
	}
}

Pre-proxy

This is the pre-proxy section.

When the server decides to proxy a request to a home server, the proxied request is first passed through the pre-proxy stage. This stage either rewrites the request or decides to cancel the proxy.

Only a few modules currently have this method.

pre-proxy {

Before proxing the request, this section adds an Operator-Name attribute identifying whether or not the operator-name is found for this client.

There is no need to uncomment this line if it has already been enabled in the authorize section.

#	operator-name

The client requests the CUI by sending a CUI attribute containing one zero byte.

Uncomment this line if requesting the CUI.

#	cui

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

#	files

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

#	attr_filter.pre-proxy

To log packets proxied to a home server, uncomment this line as well as the 'detail pre_proxy_log' section, above.

#	pre_proxy_log
}

Post-proxy

This is the post-proxy section.

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

post-proxy {

To log replies from a home server, uncomment this line and the 'detail post_proxy_log' section, above.

#	post_proxy_log

Uncomment this 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 must be listed here, in the post-proxy stage.

The 'nostrip' option must also be see 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. Then, 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 will 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
#	}
}
}