| [ < ] | [ > ] | [ << ] | [ 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 descrip