| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
At startup, GNU Radius obtains the information vital for its functioning from a number of configuration files. These are normally found in /usr/local/etc/raddb directory, which is defined at configuration time, although their location can be specified at runtime. In the discussion below we will refer to this directory by `raddb'. See section 2. Naming Conventions.
Each configuration file is responsible for a certain part of the GNU Radius functionality. The following table lists all configuration files along with a brief description of their purposes.
radiusd, such
as the IP address and ports to listen on, the sizes of the request
queues, configuration of the SNMP subsystem, fine-tuning of the
extension languages, etc.
radiusd.
The rest of this chapter describes each of these files in detail.
5.1 Run-Time Configuration Options -- `raddb/config' Run-time configuration options. 5.2 Dictionary of Attributes -- `raddb/dictionary' Radius dictionary. 5.3 Clients List -- `raddb/clients' Clients lists the NASes that are allowed to communicate with radius. 5.4 NAS List -- `raddb/naslist' The naslist file keeps general information about the NASes. 5.5 NAS Types -- `raddb/nastypes' Information about how to query the NASes about active user sessions. 5.6 Request Processing Hints -- `raddb/hints' Important user information that is common for the users whose names match some pattern. 5.7 Huntgroups -- `raddb/huntgroups' Group users by the NAS (and, possibly, a port number) they come from. 5.8 List of Proxy Realms -- `raddb/realms' Communication with remote radius servers 5.9 User Profiles -- `raddb/users' User profile. 5.10 List of Blocked Users -- `raddb/access.deny' List of users which are denied access. 5.11 SQL Configuration -- `raddb/sqlserver' SQL server configuration. 5.12 Rewrite functions -- `raddb/rewrite' Rewrite functions allow to change the input packets. 5.13 Login Menus -- `raddb/menus' Menus allow user to select the type of service. 5.14 Macro Substitution Macros which are expanded by the actual attribute values.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
At startup radiusd obtains its configuration values from three
places. The basic configuration is kept in the executable module
itself. These values are overridden by those obtained from
`raddb/config' file. Finally, the options obtained from the
command line override the first two sets of options.
When re-reading of the configuration is initiated either by
SIGHUP signal or by SNMP channel any changes in the config file
take precedence over command line arguments, since `raddb/config' is
the only way to change configuration of the running program.
This chapter discusses the `raddb/config' file in detail.
The `raddb/config' consists of statements and comments. Statements end with a semicolon. Many statements contain a block of sub-statements which also terminate with a semicolon.
Comments can be written in shell, C, or C++ constructs, i.e. any of the following represent a valid comment:
# A shell comment /* A C-style * multi-line comment */ // A C++-style comment |
These are the basic statements:
5.1.1 optionblockOptionblock: set the global program options.5.1.2 loggingblockFine-tune the logging. 5.1.3 authstatementConfigure authentication service. 5.1.4 acctstatementConfigure accounting service. 5.1.5 usedbmstatementEnable the DBM feature. 5.1.6 snmpstatementConfigure SNMP service. 5.1.7 rewritestatement.Configure Rewrite interface. 5.1.8 guilestatementConfigure Guile interface. 5.1.9 messagestatementConfigure server reply messages. 5.1.10 filtersstatementConfigure authentication and accounting filters. 5.1.11 mlcstatementConfigure multiple login checking.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
option block
option {
source-ip number ;
max-requests number ;
radiusd-user string ;
exec-program-user string ;
username-chars string ;
log-dir string ;
acct-dir string ;
resolve bool ;
max-processes number ;
process-idle-timeout number ;
master-read-timeout number ;
master-write-timeout number ;
} ;
|
The option block defines the global options to be used by radiusd.
resolve
resolve no speeds up the server and reduces
the network traffic.
source-ip
max-requests
max-processes
process-idle-timeout
master-read-timeout
master-write-timeout
master-read-timeout sets the maximum number of seconds the main
process will wait for the answer from the subprocess, and
master-write-timeout sets the maximum number of seconds the main
process will wait for the subprocess's comunication channel to become
ready for input. By default, no timeouts are imposed.
radiusd-user
radiusd to drop root privileges and to switch to
the real user and group IDs of the given user after becoming
daemon. Notice the following implications of this statement:
System (see section 7.5 System Authentication Type) requires
root privileges, so it cannot be used with radiusd-user. Any
`raddb/users' profiles using this authentication type will be
discarded.
PAM (see section 7.7 PAM Authentication Type) may require root
provileges. It is reported to always require root privileges on some
systems (notably on Solaris).
exec-program-user statement (see below) is ignored when
used with radiusd-user.
exec-program-user
Exec-Program and Exec-Program-Wait. The real user
and group ids will be retrieved from the `/etc/passwd' entry
for the given user.
username-chars
username-chars statement overrides this default, thus setting:
username-chars ":" |
will restrict the set of allowed characters to the alphanumeric
characters and colon. If you wish to expand the default character
set, you will have to explicitly specify it in the
username-chars argument, as shown in the example below:
username-chars ".-_!@#$%^&\\/\":" |
(Notice the use of escape character `\').
log-dir
acct-dir
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
logging block
logging {
prefix-hook string ;
suffix-hook string ;
category category_spec {
channel channel_name ;
print-auth bool ;
print-pass bool ;
print-failed-pass bool ;
level debug_level ;
} ;
channel channel_name {
file string ;
syslog facility . priority ;
print-pid bool ;
print-category bool ;
print-cons bool ;
print-level bool ;
print-priority bool ;
print-tid bool;
print-milliseconds bool;
prefix-hook string ;
suffix-hook string ;
};
} ;
|
The logging statement describes the course followed by
radiusd's logging information.
The parts of this statement are discussed below.
5.1.2.1 Logging hooks 5.1.2.2 categorystatement5.1.2.3 channelstatement5.1.2.4 Example of the loggingstatement
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Most diagnostic messages displayed by radiusd describe
some events that occured while processig a certain incoming request.
By default they contain only a short summary of the event.
Logging hooks are means of controlling actual amount of
information displayed in such messages. They allow you to add to the
message being displayed any relevant information from the incoming
request that caused the message to appear.
A hook is a special Rewrite function that takes three arguments and returns a string. There are two kinds of logging hooks: prefix and suffix. Return value from the prefix hook function will be displayed before the actual log message, that of the suffix hook function will be displayed after the message.
Furthermore, there may be global and channel-specific
hooks. Global hooks apply to all categories, unless overridden by
category-specific hooks. Global prefix hook is enabled by
prefix-hook statement appearing in the logging block.
Global suffix hook is enabled by suffix-hook statement.
Both statements take as their argument the name of corresponding
Rewrite function.
For detailed information about writing logging hooks, See section 11.2.7 Logging Hook Functions.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
category statement
Each line of logging information generated by radiusd has an
associated category. The logging statement allows each
category of output to be controlled independently of the others.
The logging category is defined by category name and a
severity. category name determines what part of radiusd
daemon is allowed to send its logging information to this channel.
It can be any of main, auth, acct, proxy,
snmp. priority determines the minimum priority of
the messages displayed by this channel. The priorities in ascending
order are: debug, info, notice, warn,
err, crit, alert, emerg.
The full category specification, denoted by the category_spec
in the above section, can take any of the following three forms:
Additional category options valid for auth category are:
print-auth
print-pass
print-failed-pass
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
channel statement
Channels represent methods for recording logging information. Each
channel has a unique name, and any categories which specify that name in
a channel statement will use that channel.
radiusd can write logging information to files or send it to
syslog. The file statement sends the channel's output to the
named file (see section 2. Naming Conventions). The syslog statement
sends the channel's output to syslog with the specified facility and
severity.
Channel options modify the data flowing through the channel:
print-pid
print-cons
print-category
print-priority
print-level
print-milliseconds
prefix-hook
suffix-hook
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
logging statement
logging {
channel default {
file "radius.log";
print-category yes;
print-priority yes;
};
channel info {
file "radius.info";
print-pid yes;
print-cons yes;
print-priority yes;
};
channel notice {
syslog auth.notice;
};
category auth {
print-auth yes;
print-failed-pass yes;
};
category notice {
channel notice;
};
category info {
channel info;
};
category debug {
channel info;
level radiusd=1,files;
};
category *.!debug {
channel default;
};
};
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
auth statement
auth {
listen ( addr-list | no );
forward addr-list;
port number ;
max-requests number ;
time-to-live number ;
request-cleanup-delay number ;
detail bool ;
strip-names bool ;
checkrad-assume-logged bool ;
password-expire-warning number ;
compare-atribute-flag character ;
trace-rules bool ;
reject-malformed-names bool ;
} ;
|
auth statement configures the parameters of the authentication
service.
listen statement This statement determines on which addresses radiusd will listen for incoming authentication requests. Its argument is a comma-separated list of items in the form ip:port-number. ip can be either an IP address in familiar "dotted-quad" notation or a hostname. :port-number part may be omitted, in which case the default authentication port is assumed.
If the listen statement is omitted, radiusd will accept incoming
requests from any interface on the machine.
The special value no disables listening for authentication
requests.
The following example configures radius to listen for the incoming requests on the default authentication port on the address 10.10.10.1 and on port 1645 on address 10.10.11.2.
listen 10.10.10.1, 10.10.11.2:1645; |
forward statement This statement enables forwarding of the requests to the given set of servers. Forwarding is an experimental feature of GNU Radius, it differs from proxying in that the requests are sent to the remote server (or servers) and processed locally. The remote server is not expected to reply.
This mode is intended primarily for debugging purposes. It could also be useful in some very complex and unusual configurations.
port
max-requests
time-to-live
request-cleanup-delay
password-expire-warning
detail
radiusd will produce the detailed log of each
received packet in the file `radacct/nasname/detail.auth'. The
format of such log files is identical to the format of detailed
accounting files (see section 8.2 Detailed Request Accounting).
strip-names
radiusd should strip any prefixes/suffixes
off the username before logging.
checkrad-assume-logged
mlc statement, for the description of this setting. It is accepted in
auth for compatibility with previous versions of GNU Radius.
trace-rules
reject-malformed-names
User-Name attribute. By default
such requests are discarded without answering. See the description of
username-chars (see section Option statement).
compare-attribute-flag
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
acct statement acct {
listen ( addr-list | no );
forward addr-list ;
port number ;
detail bool;
system bool;
max-requests number ;
time-to-live number ;
request-cleanup-delay number ;
compare-atribute-flag character ;
trace-rules bool ;
} ;
|
The acct statement configures the parameters of the accounting
service.
listen statement This statement determines on which addresses radiusd will listen for incoming accounting requests. Its argument is a comma-separated list of items in the form ip:port-number. ip can be either an IP address in familiar "dotted-quad" notation or a hostname. :port-number part may be omitted, in which case the default accounting port is assumed.
If the listen statement is omitted, radiusd will accept incoming
requests from any interface on the machine.
The special value no disables listening for accounting
requests.
The following example configures radius to listen for the incoming requests on the default accounting port on the address 10.10.10.1 and on port 1646 on address 10.10.11.2.
listen 10.10.10.1, 10.10.11.2:1646; |
forward statement This statement enables forwarding of the requests to the given set of servers. Forwarding is an experimental feature of GNU Radius, it differs from proxying in that the requests are sent to the remote server (or servers) and processed locally. The remote server is not expected to reply.
This mode is intended primarily for debugging purposes. It could also be useful in some very complex and unusual configurations.
port
max-requests
time-to-live
request-cleanup-delay
detail
no, disables detailed accounting
(see section 8.2 Detailed Request Accounting).
system
no, disables system accounting (see section 8.1 System Accounting). Notice, that this will disable simultaneous use checking
as well, unless you supply an alternative MLC method (currently
SQL, See section 7.9 Multiple Login Checking, for the detailed discussion
of this).
trace-rules
compare-attribute-flag
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
usedbm statement usedbm ( yes | no ) ; |
usedbm statement determines whether the DBM support should
be enabled.
no
yes
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
snmp statement snmp {
port portno ;
listen ( addr-list | no );
max-requests number ;
time-to-live number ;
request-cleanup-delay number ;
ident string ;
community name ( rw | ro ) ;
network name network [ network ... ] ;
acl {
allow network_name community_name ;
deny network_name ;
} ;
storage {
file filename ;
perms number ;
max-nas-count number ;
max-port-count number ;
} ;
};
|
snmp statement configures the SNMP service.
listen statement
The listen statement determines on which addresses radiusd will
listen for incoming SNMP requests. The argument is a comma-separated
list of items in the form ip:port-number. The ip can
be either an IP address in familiar "dotted-quad" notation or a
hostname. The :port-number part may be omitted, in which case the
default SNMP port (161) is used.
If the listen statement is omitted, radiusd will accept incoming
requests from any interface on the machine.
The special value no disables listening for SNMP requests.
The following example configures radius to listen for the incoming SNMP requests on the default SNMP port on the address 10.10.10.1 and on port 4500 on address 10.10.11.2.
listen 10.10.10.1, 10.10.11.2:4500; |
port
max-requests
time-to-live
request-cleanup-delay
ident
community name ( rw | ro )
rw) or read-only
(ro).
network name network [ network ... ]
allow network_name community_name
deny NETWORK_NAME
GNU Radius stores the SNMP monitoring data in an area of shared memory mapped to an external file. This allows all subprocesses to share this information and to accumulate the statistics across invocations of the daemon.
The storage statement controls the usage of the storage for
the SNMP data.
file
perms
max-nas-count
reached SNMP storage limit for the number of monitored NASes: increase max-nas-count |
max-port-count
reached SNMP storage limit for the number of monitored ports: increase max-port-count |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
rewrite statement. (This message will disappear, once this node revised.)
rewrite {
stack-size number ;
load-path string ;
load string ;
};
|
stack-size
load-path
load
load-path statement.
The default load path is `RADDB':`DATADIR'/rewrite.
<FIXME> Describe the loading process in detail. Also, some kind of
autoloading is necessary for Rewrite. </>
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
guile statement (This message will disappear, once this node revised.)
The guile statement allows to configure server interface with
Guile.
guile {
debug bool ;
load-path string ;
load string ;
load-module string [ string ... ] ;
eval expression [ expression ... ] ;
gc-interval number ;
outfile string ;
};
|
debug
gc-interval
gc-interval statement sets
such interval in seconds.
For more information about Guile memory management system in general and garbage collections in particular, see section `Memory Management and Garbage Collection' in The Guile Reference Manual.
eval
Scheme expression.
load-path
%load-path variable.
load
load-module
Guile
rules, except that the ones starting with a dash (`-') are
converted to keyword arguments.
<FIXME> Describe the
loading sequence in more detail. Why are modules preferred over plain
SCM programs, etc. </>
outfile
Guile
functions to the given file. Unless the filename starts with `/',
it is taken relative to the current logging directory.
See section 11.3 Guile, for a detailed description of Guile extensions interface.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
message statement
The message statement allows to set up the messages that are
returned to the user with authentication-response packets.
message {
account-closed string ;
password-expired string ;
password-expire-warning string ;
access-denied string ;
realm-quota string ;
multiple-login string ;
second-login string ;
timespan-violation string ;
};
|
All variables in message block take a string argument. In
string you can use the usual C backslash notation to represent
non-printable characters. The use of %C{} and %R{} sequences
is also allowed (see section 5.14 Macro Substitution).
account-closed
password-expired
password-expire-warning
password-expire-warning variable in auth block.
See section 5.1.3 auth statement. In this string, you can use the %R{Password-Expire-Days}
substitution, to represent the actual number of days left
to the expiration date. The default is
Password Will Expire in %R{Password-Expire-Days} Days\r\n
|
access-denied
realm-quota
multiple-login
Simultaneous-Use.
second-login
multiple-login, which is used when
the user's login limit is 1.
timespan-violation
Login-Time.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
filters statement
The filters statement configures user-defined external filters.
See section 11.1 Filters, for the detailed discussion of external filters.
filters {
filter ident {
exec-path path ;
error-log filename ;
common bool [max-wait];
auth {
input-format fmt ;
wait-reply bool ;
};
acct {
input-format fmt ;
wait-reply bool ;
};
};
...
};
|
Each filter directive defines a new filter. The ident
argument declares the name of the filter. This string must be
used in Exec-Program-Wait or Acct-Ext-Program attributes
to trigger invocation of this filter (see section 14.3.7 Exec-Program-Wait).
These compound statements define authentication and accounting
parts of this filter. Any one of them may be missing. The two
statements allowed within auth and acct blocks are:
You can also use the return value from a rewrite function as
input line to the filter. To do so, declare:
input-format "=my_func()"; |
where my_func is the name of the rewrite function to invoke. The function must return string value.
yes. Otherwise, if the filter produces no output, use
wait-reply no.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
mlc statement
mlc {
method (system|sql);
checkrad-assume-logged bool;
};
|
Mlc statement configures multiple login checking subsystem
(see section 7.9 Multiple Login Checking).
method
to system will use system accounting database (see section 8.1 System Accounting). This is the default method. Setting it to sql
will use SQL database.
radiusd consults the value of this variable when the NAS
does not responds to checkrad queries (see section 7.9 Multiple Login Checking).
If this variable is set to yes, the daemon will proceed as if
the NAS returned "yes", i.e. it will assume the user is logged in.
Otherwise radiusd assumes the user is not logged in.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The dictionary file `raddb/dictionary' defines the symbolic names for radius attributes and their values (see section 3.1 Attributes). The file consists of a series of statements, each statement occupies one line.
In the detailed discussion below we use the following meta-syntactic characters:
string
integer
ipaddr
date
5.2.1 Comments Introducing a comment line. 5.2.2 $INCLUDE Statement Include a file. 5.2.3 VENDOR Statement Define a vendor-id. 5.2.4 ATTRIBUTE statement Define an attribute translation. 5.2.5 Blocks of Vendor-Specific Attributes Blocks of vendor-specific attributes 5.2.6 ALIAS statement Define alternative name for an attribute. 5.2.7 PROPERTY statement Define attribute properties. 5.2.8 VALUE Statement Define a value translation.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
$INCLUDE `filename' |
$INCLUDE statement causes the contents of the file `filename'
to be read in and processed. The file is looked up in the Radius database
directory, unless its name starts with a slash.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
VENDOR vendor-name vendor-id |
VENDOR statement defines the symbolic name vendor-name
for vendor identifier vendor-id.
This name can subsequently be used in ATTRIBUTE statements
to define Vendor-Specific attribute translations. See section 14.1.26 Vendor-Specific.
VENDOR Livingston 307 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ATTRIBUTE name number type [vendor] [flags] |
ATTRIBUTE statement defines the internal representation of
an attribute: its symbolic name, data type and syntactical usage.
Its parts have the following meaning:
The attribute property flags consist of a sequence of letters, whose meaning is determined by the following rules: (2)
[L--RLR] |
means that the attribute may be used in LHS of a rule in `raddb/users', in RHS of a rule in `raddb/hints', and in both sides of a rule in `raddb/huntgroups'.
ATTRIBUTE Service-Type 6 integer - [LR-RLR]=P |
This statement declares that the attribute number 6 will be referred
to by the symbolic name `Service-Type'. The attribute is of
integer data type and it may be used in any part of matching rules,
except in LHS of a `raddb/hints' rule. The
additivity of Service-Type is set to `Replace'. The
attribute will be propagated through the proxy chain.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BEGIN VENDOR vendor-name [vendor-id] ... END |
BEGIN keyword marks start of the block of definitions of
vendor-specific attributes. The block is terminated by END
keyword, optionally followed by an arbitrary number of words,
which are regarded as a comment. The block may contain any valid
dictionary declarations, except other blocks: nesting of declaration
blocks is not allowed.
If vendor-id is absent, the value of vendor ID is looked
up in the internal table of vendors; therefore, it must be
defined before BEGIN statement (see section 5.2.3 VENDOR Statement).
BEGIN--END block alters the handling of ATTRIBUTE
statements within it. If ATTRIBUTE statement does not
contain an explicit vendor-id specification, the value of
vendor-id is used instead.
For compatibility with FreeRadius an alternative syntax is also supported:
BEGIN-VENDOR vendor-name ... END-VENDOR vendor-name |
Such compatibility blocks must appear only ater the declaration of vendor-name (see section 5.2.3 VENDOR Statement).
The following is the usual way of definig vendor-specific attributes:
VENDOR Livingston 307 ATTRIBUTE LE-Terminate-Detail 2 string Livingston ATTRIBUTE LE-Advice-of-Charge 3 string Livingston |
The following two examples show the alternative ways:
VENDOR Livingston 307 BEGIN VENDOR Livingston ATTRIBUTE LE-Terminate-Detail 2 string ATTRIBUTE LE-Advice-of-Charge 3 string END |
BEGIN VENDOR Livingston 307 ATTRIBUTE LE-Terminate-Detail 2 string ATTRIBUTE LE-Advice-of-Charge 3 string END |
These three examples are completely equivalent to each other.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ALIAS name alt-name |
ALIAS statement defines an altenative name alt-name
for attribute name. The latter should already be defined,
otherwise an error occurs.
ALIAS User-Password Password |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
PROPERTY name flags PROPERTY name +flags [-flags ...] |
PROPERTY statement redefines property flags for attribute
name. The attribute must be defined, otherwise an error occurs.
The PROPERTY statement has two forms. In first form, it takes
a single argument, representing new property flags for the attribute.
In its second form it takes any number of arguments, each of them
preceeded by `+' sign, inidicating addition of properties, or
by `-' sign, indicating removal of these.
See section 5.2.4 ATTRIBUTE statement, for the discussion of attribute property flags.
The following example defines that the attribute User-Password
may be used only on left-hand side of a `raddb/users' entry, and
that it is transmitted in encrypted form.
PROPERTY User-Password [L-----]E |
Next example illustrates adding and removing attribute properties:
PROPERTY My-Attrib +P -= |
it adds propagation bit (`P') and removes `replace'
additivity from My-Attrib attribute.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
VALUE Attribute-Translation Value-Translation number |
VALUE statement assigns a translation string to a given
value of an integer attribute. Attribute-Translation specifies
the attribute and the Value-Translation specifies the name
assigned to the value number of this attribute.
The following assigns the translation string `Login-User' to the value 1 of the attribute `Service-Type'.
VALUE Service-Type Login-User 1 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The `raddb/clients' lists NASes which are allowed to make authentication requests. As usual, the `#' character introduces a comment. Each record in the file consists of two fields, separated by whitespace. The fields are:
If the set of NASes share the same encryption key, there are two
ways to list it in `raddb/clients'. First, if these NASes
lie in a single network, you can specify this network address in
NAS name field, e.g.:
10.10.10.0/27 seCRet |
Notice also that specifying full netmask after the `/' character is also allowed, so that the above example could also be written as follows:
10.10.10.0/255.255.255.224 seCRet |
Otherwise, the keyword DEFAULT may be used as NAS name. This
notation will match any IP address, so it should be used with caution.
5.3.1 Example of `clients' file An example of clients file.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
# This is a list of clients which are allowed to make authentication # requests. # Each record consists of two fields: # i. Valid hostname. # ii. The shared encryption key for this hostname. # #Client Name Key #---------------- ------------------- myhost.dom.ain guessme merlin emrys 11.10.10.10 secRet |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The `raddb/naslist' file contains a list of NASes known to the Radius server. Each record in the file consist of the following four fields, the first two being mandatory, the last two being optional:
radiusd
determines the way to query NAS about the presence of a given user on it
(see section 7.9 Multiple Login Checking).
The two special types: `true' and `false', can be used to
disable NAS querying. When the type field contains `true',
radiusd assumes the user is logged in to the NAS, when it
contains `false', radiusd assumes the user is not
logged in. Otherwise, the type
is used as a link to `nastypes' entry (see section 5.5 NAS Types -- `raddb/nastypes').
If this field is not present `true' is assumed.
There are two groups of nas arguments: nas-specific arguments and
nas-querying arguments. Nas-specific arguments are used to
modify a behavior of radiusd when sending or receiving the
information to or from a particular NAS.
Nas-querying arguments control the way radiusd queries
a NAS for confirmation of a user's session (see section 7.9 Multiple Login Checking). These arguments override the ones specified in
`nastypes' and can thus be used to override the default
values.
The nas-specific arguments currently implemented are:
radiusd uses
method specified by RFC 2865. However some NASes, most notably
MAX Ascend series, implement a broken method of encoding long
passwords. This flag instructs radiusd to use broken method
of password encryption for the given NAS.
compare-attribute-flag (see section 5.1.3 auth statement) for this particular NAS.
See section 6.1 Extended Comparison, for a detailed description of its usage.
compare-attribute-flag (see section 5.1.4 acct statement) for this particular NAS.
See section 6.1 Extended Comparison, for a detailed description of its usage.
See section 3.4.1 Checking for Duplicate Requests, for general description of request comparison methods.
For the list of nas-querying arguments, See section Full list of allowed arguments.
5.4.1 Example of `naslist' file
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
# raddb/naslist: contains a list of Network Access Servers # # Each record consists of following fields: # # i. A valid hostname or IP address for the client. # ii. The short name to use in the logfiles for this NAS. # iii. Type of device. Valid values are `true', `false' and # those defined in raddb/nastypes file. # NAS Name Short Name Type #---------------- ---------- ---- myhost.dom.ain myhost unix merlin merlin max 11.10.10.10 arthur livingston |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The `raddb/nastypes' file describes the ways to query NASes about active user sessions.
5.5.1 Syntax of `raddb/nastypes' Syntax described. 5.5.2 Example of nastypes file. 5.5.3 Standard NAS types NAS types defined in standard nastypes file.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
Version 1.3 of GNU Radius supports following querying methods: finger, snmp, external and guile. <FIXME> Describe these fully </> .
In the discussion below n means numeric and s string value.
The following arguments are predefined:
The following macro-variables are recognized and substituted when encountered in the value pair of an argument: <FIXME> Describe new syntax for extendable strings. Notice, that the use of old meta-characters is deprecated. </>
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Note, that in the following example the long lines are broken into several lines for readability.
# Type Method Args
# ---- ------ ----
unix finger function=check_unix
max-f finger function=check_max_finger
max snmp oid=.1.3.6.1.4.1.529.12.3.1.4.%d,
function=check_snmp_u
as5300-f finger function=check_as5300_finger
as5300 snmp oid=.1.3.6.1.4.1.9.9.150.1.1.3.1.2.%d,
function=check_snmp_u
livingston snmp oid=.1.3.6.1.4.1.307.3.2.1.1.1.5.%P,
function=check_snmp_s
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The `nastypes' shipped with version 1.3 of GNU Radius defines following NAS types:
#Hostname Shortname Type #-------- --------- ---- nas.name T unix |
#Hostname Shortname Type Flags #-------- --------- ---- ----- nas.name T max-f broken_pass |
Note the use of broken_pass flag. It is needed
for most MAX Ascend servers (see section 5.4 NAS List -- `raddb/naslist').
#Hostname Shortname Type Flags #-------- --------- ---- ----- nas.name T max-f broken_pass,community=comm |
Replace comm with your actual SNMP community name.
livingston queries portmaster using SNMP.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The `raddb/hints' file is used to modify the contents of the incoming request depending on the username. For a detailed description of this, See section 3.4.3 Hints.
The file contains data in Matching Rule format (see section 3.3 Matching Rule).
Notice, that versions of GNU Radius up to 1.0 allowed to use only a subset of attributes in the check list of a `hints' entry, namely:
Suffix
Prefix
Group
User-ID
This requirement has been removed in version 1.0.
5.6.1 Example of `hints' file An example of `hints' file.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
## If the username starts with `U', append the UUCP hint
DEFAULT Prefix = "U", Strip-User-Name = No
Hint = "UUCP"
## If the username ends with `.slip', append the SLIP service data
## and remove the suffix from the user name.
DEFAULT Suffix = ".slip",
Strip-User-Name = Yes
Hint = "SLIP",
Service-Type = Framed-User,
Framed-Protocol = SLIP
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The `raddb/huntgroups' contains the definitions of the huntgroups. For a detailed description of huntgroup concept, See section 3.4.4 Huntgroups.
The file contains data in Matching Rule format (see section 3.3 Matching Rule).
5.7.1 Example of `huntgroups' file. An example of the `huntgroups' file.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
## This defines the packet rewriting function for the server 11.10.10.11
DEFAULT NAS-IP-Address = 11.10.10.11, Rewrite-Function = "max_fixup"
NULL
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The `raddb/realms' file lists remote Radius servers that are allowed to communicate with the local Radius server (see section 3.4.2 Proxying).
Each record consists of up to three fields, separated by whitespace. Two of them are mandatory. The fields are:
The name `NOREALM' defines the empty realm, i.e. lines marked with this name will match user names without any realm suffix.
The name `DEFAULT' defines the default realm (see section 3.4.2.2 Realms). The lines with this realm name will match any user name, not matched by any other line in `raddb/realms'.
A comma-separated list of remote servers to which the requests for this realm should be forwarded. Each item in the list is:
servername[:auth-port[:acct-port]] |
Optional auth-port and acct-port are the authentication and accounting port numbers. If acct-port is omitted, it is computed as auth-port + 1. If auth-port is omitted, the default authentication port number is used.
The servers from this list are tried in turn until any of them replies
or the list is exhausted, whichever occurs first. The timeout value and
number of retries for each server are set via timeout and
retry flags (see below).
There may be cases where you would wish a particular realm to be served by the server itself. It is tempting to write
# Wrong! realm.name localhost |
however, this will not work. The special form of the server list is provided for this case. It is the word `LOCAL'. The correct configuration line for the above case will thus be:
# Use this to declare a locally handled realm realm.nam LOCAL |
The flags meaningful in `raddb/realms' are
myrealm.net remote.server.net:1812 ignorecase |
then user name `user@MyREAlm.NeT' will match this definition.
strip enables stripping, setting nostrip disables
it. Default is to always strip user names.
5.8.1 Example of `realms' file An example of `realms' file.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
# Realm Remote server[:port] flags #---------------- --------------------- -------- that.net radius.that.net nostrip dom.ain server.dom.ain:3000 strip,quota=20 remote.net srv1.remote.net,srv2.remote.net |
# Realm Remote server[:port] flags #---------------- --------------------- -------- NOREALM radius.server.net that.net radius.that.net nostrip dom.ain server.dom.ain:3000 strip,quota=20 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
File `raddb/users' contains the list of User Profiles. See section 3.4.5 User Profiles, for a description of its purpose.
5.9.1 Example of `users' file An example of `users' file.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
## The following entry is matched when the user appends ``.ppp'' to his
## username when logging in.
## The suffix is removed from the user name, then the password is
## looked up in the SQL database.
## Users may log in at any time. They get PPP service.
DEFAULT Suffix = ".ppp",
Auth-Type = SQL,
Login-Time = "Al",
Simultaneous-Use = 1,
Strip-User-Name = Yes
Service-Type = Framed-User,
Framed-Protocol = PPP
## This is for SLIP users.
## This entry is matched when the auth request matches ``SLIP'' hint
DEFAULT Hint = "SLIP",
Auth-Type = Mysql
Service-Type = Framed-User
Framed-Protocol = SLIP
## The following authenticates users using system passwd files.
## The users are allowed to log in from 7:55 to 23:05 on any weekday,
## except the weekend, and from 07:55 to 12:00 on Sunday.
## Only one login is allowed per user.
## The program telauth is used to further check the authentication
## information and provide the reply pairs
## Note the use of backslashes to split a long line.
DEFAULT Auth-Type = System,
Login-Time = "Wk0755-2305,Su0755-1200",
Simultaneous-Use = 1
Exec-Program-Wait = "/usr/local/sbin/telauth \
%C{User-Name} \
%C{Calling-Station-Id} \
%C{NAS-IP-Address} \
%C{NAS-Port-Id}"
## This particular user is authenticated via PAM. He is presented a
## choice from `raddb/menus/menu1' file.
gray Auth-Type = Pam
Menu = menu1
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The `raddb/access.deny' file contains a list of user names which are not allowed to log in via Radius. Each user name is listed on a separate line. As usual, the `#' character introduces an end-of-line comment.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The `raddb/sqlserver' file configures the connection to SQL server.
The file uses simple line-oriented `keyword -- value' format. Comments are introduced by `#' character.
The `sqlserver' statements can logically be subdivided into following groups: SQL Client Parameters, configuring the connection between SQL client and the server, Authentication Server Parameters, Authorization Parameters, and Accounting server parameters.
5.11.1 SQL Client Parameters 5.11.2 Authentication Server Parameters 5.11.3 Authorization Parameters 5.11.4 Accounting Parameters
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These parameters configure various aspects of connection between SQL client and the server.
interface iface-type
mysql and postgres. Depending
on this, the default communication port number is set: it is 3306 for
interface mysql and 5432 for interface postgres. Use of
this statement is only meaningful when the package was configured with
both `--with-mysql' and `--with-postgres' option.
server string
port number
login string
password password
keepopen bool
radiusd should try to keep the connection open.
When set to no (the default), radiusd will open new connection
before the transaction and close it right after finishing it.
We recommend setting keepopen to yes for heavily loaded
servers, since opening the new connection can take a substantial amount
of time and slow down the operation considerably.
idle_timeout number
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
These parameters configure the SQL authentication. The general syntax is:
doauth bool
yes, enables authentication via SQL. All auth_
keywords are ignored if doauth is set to no.
auth_db string
auth_query string
group_query string
Group or Group-Name
attribute appears in the LHS of a user's or hint's profile.
auth_success_query string
auth_failure_query string
Let's suppose the authentication information is kept in the tables
passwd and groups.
The passwd table contains user passwords. A user is allowed
to have different passwords for different services. The table structure
is:
CREATE TABLE passwd ( user_name varchar(32) binary default '' not null, service char(16) default 'Framed-PPP' not null, password char(64) ); |
Additionally, the table groups contains information about
user groups a particular user belongs to. Its structure is:
CREATE TABLE groups ( user_name char(32) binary default '' not null, user_group char(32) ); |
The queries used to retrieve the information from these tables will then look like:
auth_query SELECT password
FROM passwd
WHERE user_name = '%C{User-Name}'
AND service = '%C{Auth-Data}'
group_query SELECT user_group
FROM groups
WHERE user_name = '%C{User-Name}'
|
It is supposed, that the information about the particular service a
user is wishing to obtain, will be kept in Auth-Data attribute
in LHS of a user's profile.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These parameters define queries used to retrieve the authorization information from the SQL database. All the queries refer to the authentication database.
check_attr_query string
attr-name, attr-value, opcode |
The query is executed before comparing the request with the profile entry. The values returned by the query are added to LHS of the entry. opcode here means one of valid operation codes: `=', `!=', `<', `>', `<=', `>='.
reply_attr_query string
attr-name, attr-value |
The query is executed after a successful match, the values it returns are added to the RHS list of the matched entry, and are therefore returned to the NAS in the reply packet.
Suppose your attribute information is stored in a SQL table of the following structure:
CREATE TABLE attrib (
user_name varchar(32) default '' not null,
attr char(32) default '' not null,
value char(128),
op enum("=", "!=", "<", ">", "<=", ">=") default null
);
|
Each row of the table contains the attribute-value pair for a given
user. If op field is NULL, the row describes RHS
(reply) pair. Otherwise, it describes a LHS (check) pair. The
authorization queries for this table will look as follows:
check_attr_query SELECT attr,value,op \
FROM attrib \
WHERE user_name='%u' \
AND op IS NOT NULL
reply_attr_query SELECT attr,value \
FROM attrib \
WHERE user_name='%u' \
AND op IS NULL
|
Now, let's suppose the `raddb/users' contains only one entry:
DEFAULT Auth-Type = SQL
Service-Type = Framed-User
|
And the attrib table contains following rows:
| user_name | attr | value | op |
jsmith | NAS-IP-Address | 10.10.10.1 | |
jsmith | NAS-Port-Id | 20 | <= |
jsmith | Framed-Protocol | PPP | NULL |
jsmith | Framed-IP-Address | 10.10.10.11 | NULL |
Then, when the user jsmith is trying to authenticate, the
following happens:
DEFAULT) in the
`raddb/users'.
check_attr_query. The
triplets it returns are then added to the LHS of the profile
entry. Thus, the LHS will contain:
Auth-Type = SQL, NAS-IP-Address = 10.10.10.1, NAS-Port-Id <= 20 |
Auth-Type attributes itself
triggers execution of auth_query, described in the previous
section.
reply_attr_query, and adds its return to the list
of RHS pairs. The RHS pairs will then be:
Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 10.10.10.11 |
This list is returned to the NAS along with the authentication accept packet.
Thus, this configuration allows the user jsmith to use only
NAS 10.10.10.1, ports from 1 to 20 inclusive. If the user meets
these conditions, he is allowed to use PPP service, and is
assigned IP address 10.10.10.11.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To perform the SQL accounting radiusd needs to know the
database where it is to store the accounting information. This
information is supplied by the following statements:
doacct bool
yes enables SQL accounting. All acct_
keywords are ignored if doacct is set to no.
acct_db string
Further, radiusd needs to know which information it is
to store into the database and when. Each of five accounting request
types (see section 3.2.2 Accounting Requests) has a SQL query associated with
it. Thus, when radius receives an accounting request, it determines
the query to use by the value of Acct-Status-Type attribute.
Following statements define the accounting queries:
acct_start_query string
INSERT statement
(see section 5.11.4.1 Writing SQL Accounting Query Templates).
acct_stop_query string
UPDATE statement.
acct_stop_query string
UPDATE statement.
acct_nasup_query string
acct_nasdown_query string
None of these queries should return any values.
Three queries are designed for use by multiple login checking mechanism (see section 7.9 Multiple Login Checking):
mlc_user_query string
mlc_realm_query string
mlc_stop_query string
5.11.4.1 Writing SQL Accounting Query Templates Writing SQL accounting query templates.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Let's suppose you have an accounting table of the following structure:
CREATE TABLE calls ( status int(3), user_name char(32), event_date_time datetime DEFAULT '0000-00-00 00:00:00' NOT NULL, nas_ip_address char(17), nas_port_id int(6), acct_session_id char(16) DEFAULT '' NOT NULL, acct_session_time int(11), acct_input_octets int(11), acct_output_octets int(11), connect_term_reason int(4), framed_ip_address char(17), called_station_id char(32), calling_station_id char(32) ); |
On receiving the Session Start Packet we would insert a record into this
table with status set to 1. At this point the columns
acct_session_time, acct_input_octets,
acct_output_octets as well as connect_term_reason are
unknown, so we will set them to 0:
# Query to be used on session start
acct_start_query INSERT INTO calls \
VALUES(%C{Acct-Status-Type},\
'%u',\
'%G',\
'%C{NAS-IP-Address}',\
%C{NAS-Port-Id},\
'%C{Acct-Session-Id}',\
0,\
0,\
0,\
0,\
'%C{Framed-IP-Address}',\
'%C{Called-Station-Id}',\
'%C{Calling-Station-Id}')
|
Then, when the Session Stop Packet request arrives we will look up
the record having status = 1, user_name matching the
value of User-Name attribute, and acct_session_id matching
that of Acct-Session-Id attribute. Once the record is found,
we will update it, setting
status = 2 acct_session_time = value of Acct-Session-Time attribute acct_input_octets = value of Acct-Input-Octets attribute acct_output_octets = value of Acct-Output-Octets attribute connect_term_reason = value of Acct-Terminate-Cause attribute |
Thus, every record with status = 1 will represent the active
session and every record with status = 2 will represent
the finished and correctly closed record. The constructed
acct_stop_query is then:
# Query to be used on session end
acct_stop_query UPDATE calls \
SET status=%C{Acct-Status-Type},\
acct_session_time=%C{Acct-Session-Time},\
acct_input_octets=%C{Acct-Input-Octets},\
acct_output_octets=%C{Acct-Output-Octets},\
connect_term_reason=%C{Acct-Terminate-Cause} \
WHERE user_name='%C{User-Name}' \
AND status = 1 \
AND acct_session_id='%C{Acct-Session-Id}'
|
Upon receiving a Keepalive Packet we will update the information
stored with acct_start_query:
acct_alive_query UPDATE calls \
SET acct_session_time=%C{Acct-Session-Time},\
acct_input_octets=%C{Acct-Input-Octets},\
acct_output_octets=%C{Acct-Output-Octets},\
framed_ip_address=%C{Framed-IP-Address} \
WHERE user_name='%C{User-Name}' \
AND status = 1 \
AND acct_session_id='%C{Acct-Session-Id}'
|
Further, there may be times when it is necessary to bring some NAS
down. To correctly close the currently active sessions on this NAS
we will define a acct_nasdown_query so that it would
set status column to 2 and update acct_session_time
in all records having status = 1 and
nas_ip_address equal to IP address of the NAS. Thus, all
sessions on a given NAS will be closed correctly when it brought
down. The acct_session_time can be computed as difference
between the current time and the time stored in event_date_time
column:
# Query to be used when a NAS goes down, i.e. when it sends
# Accounting-Off packet
acct_nasdown_query UPDATE calls \
SET status=2,\
acct_session_time=unix_timestamp(now())-\
unix_timestamp(event_date_time) \
WHERE status=1 \
AND nas_ip_address='%C{NAS-IP-Address}'
|
We have not covered only one case: when a NAS crashes, e.g. due to
a power failure. In this case it does not have a time to send
Accounting-Off request and all its records remain open. But when
the power supply is restored, the NAS will send an
Accounting On packet, so we define a acct_nasup_query to
set status column to 3 and update acct_session_time
in all open records belonging to this NAS. Thus we will know that
each record having status = 3 represents a crashed session.
The query constructed will be:
# Query to be used when a NAS goes up, i.e. when it sends
# Accounting-On packet
acct_nasup_query UPDATE calls \
SET status=3,\
acct_session_time=unix_timestamp(now())-\
unix_timestamp(event_date_time) \
WHERE status=1 \
AND nas_ip_address='%C{NAS-IP-Address}'
|
If you plan to use SQL database for multiple login checking (see section 7.9 Multiple Login Checking), you will have to supply at least two additional queries for retrieving the information about currently active sessions for a given user and realm (see section 7.9.1 Retrieving Session Data). Each of these queries must return a list consisting of 5-element tuples:
user-name, nas-ip-address, nas-port-id, acct-session-id |
For example, in our setup these queries will be:
mlc_user_query SELECT user_name,nas_ip_address,\
nas_port_id,acct_session_id \
FROM calls \
WHERE user_name='%C{User-Name}' \
AND status = 1
mlc_realm_query SELECT user_name,nas_ip_address,\
nas_port_id,acct_session_id \
FROM calls \
WHERE realm_name='%C{Realm-Name}'
|
While performing multiple login checking radiusd will
eventually need to close hung records, i.e. such records that are
marked as open in the database (status=1, in our setup), but
are actually not active (See section 7.9.2 Verifying Active Sessions, for the
description of why it may be necessary). It will by default use
acct_stop_query for that, but it has a drawback that hung
records will be marked as if they were closed correctly. This may not
be suitable for accounting purposes. The special query
mlc_stop_query is provided to override
acct_stop_query. If we mark hung records with status=4,
then the mlc_stop_query will look as follows:
mlc_stop_query UPDATE calls \
SET status=4,\
acct_session_time=unix_timestamp(now())-\
unix_timestamp(event_date_time) \
WHERE user_name='%C{User-Name}' \
AND status = 1 \
AND acct_session_id='%C{Acct-Session-Id}'
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The file `raddb/rewrite' contains definitions of Rewrite extension functions. For information regarding Rewrite extension language See section 11.2 Rewrite.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The menus is a way to allow user the choice between various services he could be provided. The menu functionality is enabled when Radius is compiled with `--enable-livingston-menus' option.
A user is presented a menu after it is authenticated if the RHS of his profile record consists of a single A/V pair in the form:
Menu = <menu-name> |
The menu files are stored in directory `raddb/menus'.
5.13.1 A menu file syntax. 5.13.2 An example of menu files
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A menu file is a text file containing a menu declaration and any number of choice descriptions. The menus can be nested to an arbitrary depth.
A comment is introduced by a `#' character. All characters from this one up to the end of line are discarded.
The menu declaration is contained between the words `menu' and `end'. Each of these must be the only word on a line and must start in column 1.
Choice descriptions follow the menu declaration. Each description starts with a line containing choice identifier. A choice identifier is an arbitrary word identifying this choice, or a word `DEFAULT'. It is followed by comma-separated list of A/V pairs which will be returned to the server when a user selects this choice.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Suppose the following file is stored under `raddb/menus/menu1':
menu
*** Welcome EEE user! ***
Please select an option:
1. Start CSLIP session
2. Start PPP session
3. Quit
Option:
end
# CSLIP choice
# Framed-IP-Address of 255.255.255.254 indicates that the NAS should
# select an address for the user from its own IP pool.
1
Service-Type = Framed-User,
Framed-Protocol = SLIP,
Framed-IP-Address = 255.255.255.254,
Termination-Menu = "menu1"
# PPP choice
2
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 255.255.255.254,
Termination-Menu = "menu1"
# A special menu EXIT means abort the session
3
Menu = "EXIT"
# Return to this menu if no valid choice have been entered
DEFAULT
Menu = "menu1"
|
Now, suppose the `raddb/users' contains the following profile entry:
DEFAULT Auth-Type = System
Menu = "menu1"
|
and user `jsmith' has a valid system account and tries to log in
from some NAS. Upon authenticating the user, the Radius server sees that
his reply pairs contain the Menu attribute. Radius then sends
Access-Challenge packet to the NAS with the text of the menu in it.
The `jsmith' then sees on his terminal:
*** Welcome EEE user! ***
Please select an option:
1. Start CSLIP session
2. Start PPP session
3. Quit
Option:
|
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 255.255.255.254,
Termination-Menu = "menu1"
|
The Termination-Menu in this list makes sure the same process
will continue when `jsmith' logs out, i.e. he will be presented
the same menu again until he enters choice `3' which will
disconnect him.
In this example, the `other' choice refers to the menu above.
menu
*** Welcome here! ***
Please enter an option:
ppp --- Start PPP session
telnet --- Begin guest login session
other --- Select other option
Enter your choice:
end
ppp
Service-Type = Framed-User,
Framed-Protocol = PPP
telnet
Service-Type = Login-User,
Login-IP-Host = 10.11.11.7,
Login-Service = Telnet,
Login-TCP-Port = 23
other
Menu = "menu1"
DEFAULT
menu = "menu2"
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some statements in the configuration files need to use the actual values of the attributes supplied with the request. These are:
Exec-Program and Exec-Program-Wait assignments in `users' database
In these statements the following macros are replaced by the value of corresponding attributes:
%Cnum
%C{attr-name}
%Rnum
%R{attr-name}
%D
%G
The exact substitution procedure varies depending on the type
of the attribute referenced by macro. If the attribute is of
string or date type, radiusd first checks if the resulting
substitution should be quoted. It does so by looking at the character
immediately preceeding `%'. If it is a single or double quote,
then radiusd assumes the macro must be quoted and replaces it
by an appropriately modified attribute value. The purpose of the
modification is to ensure that no characters within the expanded
string would conflict with the quoting characters. In particular,
radiusd searches the attribute value for any of the
characters `\', `'', `"' and prepends
a `\' to any occurrence of these. For example, suppose that
attribute NAS-Identifier has the value `A "new" host'.
Then:
nasid=%C{NAS-Identifier} ==> nasid=A "new" host
nasid="%C{NAS-Identifier}" ==> nasid="A \"new\" host"
nasid=%\C{NAS-Identifier} ==> nasid=A \"new\" host
|
The last example illustrates the use of backslash character to force string quoting in the absense of explicit quotation marks.
If an integer attribute reference is quoted, radiusd looks
up the string translation of its value in the dictionary
(see section 5.2.8 VALUE Statement) and uses this string as a replacement. If no
translation is found, the numeric value is used. The following
example assumes that the value of Acct-Terminate-Cause
attribute is 10:
reason=%C{Acct-Terminate-Cause} ==> reason=10
reason='%C{Acct-Terminate-Cause}' ==> reason='NAS-Request'
reason=%\C{Acct-Terminate-Cause} ==> reason=NAS-Request
|
Again, a backslash after percent sign can be used to force dictionary lookup.
<FIXME> The quoting rules are not flexible enough. For example, a string 'isn't it a string' may be produced, but backslash escape within a singly quoted string is useless in most implementations (e.g. in shell or SQL). Besides, quoting unconditionally replaces unprintable characters with their octal values, where the notion of "unprintable" is determined by the current locale. Is it always the right thing to do? </>
The "`{}' form" allows to specify default value for the substitution. The default value will be used when no such attribute is encountered in the pairlist. The syntax for specifying the default value resembles that of shell environment variables.
The substitution %C{attr-name:-defval} is expanded
to the value of attr-name attribute, if it is present in the
request pairlist, and to defval otherwise. For example:
%C{Acct-Session-Time:-0}
|
will return the value of Acct-Session-Time attribute or 0 if it doesn't exist in the request pairlist.
<FIXME> Should the quoting rules apply for defval as well? I'd say they should... </>
The substitution %C{attr-name:=defval} is expanded
to the value of attr-name attribute. If this attribute is not
present in the request pairlist, it will be created and assigned the
value defval. E.g.:
%C{Acct-Session-Time:=0}
|
The substitution %C{attr-name:?message} is expanded
to the value of attr-name attribute, if it is present. Otherwise
the diagnostic message "attr-name: message" is issued to
the log error channel, and string "message" is returned.
The substitution %C{attr-name:+retval} is expanded
to empty string if the attribute attr-name is present in the
referenced pairlist. Otherwise it is expanded to retval.
You can also use the following shortcuts:
%p
%n
%f
%u
%c
%i
%t
%a
%s
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |