between Acct-Type and Auth/Autz-Type lies in where the Acct-Type
method is assigned. With Auth/Autz-Type, the method is typically
assigned in the 'users' file. The 'users' file, naturally, is not
-processed during the handling of the accounting {} section. However,
+processed during the handling of the process Accounting-Request {} section. However,
part of the default files {} module is the 'acct_users' file, which
serves the same purpose as the 'users' file, but applies to accounting
packets.
filename = ${radacctdir}/10.0.0.1/detail-%Y%m%d
}
- preacct {
+ recv Accounting-Request {
suffix # Add the Realm A/V pair.
files # Add the Acct-Type A/V pair based on the Realm A/V pair.
}
- accounting {
+ process Accounting-Request {
# If Acct-Type is SQLFOO use the 'sql1' instance of the SQL module.
::
#---
- authorize {
+ recv Access-Request {
preprocess
files
}
}
# Handle accounting packets
- accounting {
+ process Accounting-Request {
detail # always log to detail, stopping if it fails
redundant {
sql1 # try module sql1
#--
# Handle accounting packets
- accounting {
+ process Accounting-Request {
detail {
fail = 1
}
#--
# Handle accounting packets
- accounting {
+ process Accounting-Request {
group {
detail1 {
fail = 1 # remember ``fail`` with priority 1
::
- authorize {
+ recv Access-Request {
preprocess {
notfound = 1
noop = 2
::
- authorize {
+ recv Access-Request {
preprocess
redundant {
sql1
An example is below::
- accounting {
+ process Accounting-Request {
load-balance {
sql1
sql2
The "load-balance" section can be nested in a "redundant" section,
or vice-versa::
- accounting {
+ process Accounting-Request {
load-balance { # between two redundant sections below
redundant {
sql1
both that load balancing occurs, and that the requests are *always*
logged to one of the databases::
- accounting {
+ process Accounting-Request {
redundant {
load-balance {
sql1
And finally::
- accounting {
+ process Accounting-Request {
redundant { # between load-balance & detail
load-balance { # between two redundant sections
redundant {
}
# eap sets the authenticate type as EAP
- authorize {
+ recv Access-Request {
...
eap
}
# eap authentication takes place.
- authenticate {
+ process Access-Request {
eap
}
# ldap gets the Configured password.
# eap sets the authenticate type as EAP
- authorize {
+ recv Access-Request {
...
ldap
eap
}
# eap authentication takes place.
- authenticate {
+ process Access-Request {
...
eap
...
# eap module should be configured as the First module in
# the authorize stanza
- authorize {
+ recv Access-Request {
eap
... other modules.
}
Only if it is required then, in radiusd.conf
- authorize {
+ recv Access-Request {
eap
... other modules.
}
In the 'authenticate' section, do the same:
- authenticate {
+ process Access-Request {
# Uncomment this if you want to use PAM (Auth-Type = PAM)
pam
...
The "soh" module decodes the radius & DHCP payloads. It also makes some dynamic
variables available, for example:
-authorize {
+recv Access-Request {
soh
update request {
Tmp-String-0 = "%{soh:OS}"
And then you can use a specific instance in radiusd.conf, like
so:
- authorize {
+ recv Access-Request {
...
sql_instance1
...
}
- accounting {
+ process Accounting-Request {
...
sql_instance1
sql_instance2
[3] Make sure to have the sqlcounter names under authorize section
like the followings:
-authorize {
+recv Access-Request {
...some entries here...
...some entries here...
...some entries here...
.br
...
.br
- accounting {
+ process Accounting-Request {
.br
...
.br
.br
.br
-authorize {
+recv Access-Request {
...
.br
redundant {
}
...
.br
-accounting {
+process Accounting-Request {
...
.br
detail
.br
...
.br
-authorize {
+recv Access-Request {
...
.br
mschap
}
...
.br
-authenticate {
+process Access-Request {
...
.br
mschap
"if" and "else" statements.
.DS
- authorize {
+ recv Access-Request {
.br
if (...) {
.br
a virtual server. For example, you can do::
server {
- authorize {
+ recv Access-Request {
...
ldap
-sql
# Note: set_auth_type was removed in v3.x.x
# Equivalent functionality can be achieved by adding the following
- # stanza to the authorize {} section of your virtual server.
+ # stanza to the recv Access-Request {} section of your virtual server.
#
# ldap
# if ((ok || updated) && User-Password) {
######################################################################
#
-# All of the other configuration sections like "authorize {}",
-# "authenticate {}", "accounting {}", have been moved to the
+# All of the other configuration sections like "recv Access-Request {}",
+# "process Access-Request {}", "process Accounting-Request {}", have been moved to the
# the file:
#
# raddb/sites-available/default
# See also raddb/sites-available/copy-acct-to-home-server
# for additional description.
#
- preacct {
+ recv Accounting-Request {
#
# Proxy the packet using the given realm.
# Note that we do not use the realm for anything else such
# ...
#}
#
-#authorize {
+#recv Access-Request {
# ...
# exec
# ...
#
# Make *sure* that 'preprocess' comes before any realm if you
# need to setup hints for the remote radius server
-authorize {
+recv Access-Request {
#
# The preprocess module takes care of sanitizing some bizarre
# attributes in the request, and turning them into attributes
# For example, the chap module will set Auth-Type to CHAP, ldap to LDAP, etc.
# - After that create corresponding authtype sections in the
# authenticate section below and call the appropriate modules.
-authenticate {
+process Access-Request {
#
# PAP authentication, when a back-end database listed
# in the 'authorize' section supplies a password. The
#
# Pre-accounting. Decide which accounting type to use.
#
-preacct {
+recv Accounting-Request {
preprocess
#
#
# Accounting. Log the accounting data.
#
-accounting {
+process Accounting-Request {
#
# Ensure that we have a semi-unique identifier for every
# request, and many NAS boxes are broken.