The radius daemon
Radius Attributes
Reporting Bugs and getting information
Obtaining GNU Radius
What Next?
Appendices
Indices
Here are some other nodes which are really inferiors of the ones already listed, mentioned here so you can get to them in one step:
--- The Detailed Node Listing ---
Radius Configuration
Client configuration
GNU Radius is a software package that provides authentication and accounting services. The acronym radius stands for Remote Authentication Dial In User Service and (in that form) usually denotes the underlying protocol name.
Historically, radius servers were used as a means to authenticate the user coming from a dial-in connection, but GNU Radius is much more than an authentication system: it is an advanced, customizable, and extensible system for controlling access to the network.
GNU Radius has several built-in authentication and accounting methods. When these methods are not enough, it allows the administrator to implement any new method she deems convenient.
The GNU Radius package includes the server program, radiusd, which responds to authentication and accounting requests, and a set of accompanying programs designed to monitor the activity of the server and analyze the information it provides.
To illustrate what GNU Radius does, let's consider an imaginary internet service provider. Our provider has two network access servers (nases for short)—i.e., two pieces of equipment which directly accept users' connections—and a core router that connects the ISP's internal network with the Internet backbone.
When a user connects to a nas, the server must verify that the user is actually registered and that the credentials she has supplied are correct. This first step is called authentication.
Upon authenticating the user, the nas must determine which services the user is permitted to use and to what extent the user may use them. This second step is called authorization.
When the first two stages have been successfully completed, the nas takes the third step and establishes the connection between the user and the main server. This connection is called a user session. For the purposes of accounting, the nas remembers the exact time of the start of the session. When the session is terminated, the duration of the session and the number of bytes transferred are recorded as well.
All three tasks can be accomplished by the use of user and accounting databases on each terminal server. However, this is not convenient, and it is error-prone in that the maintenance of separate databases for the same users is not a trivial task. What is worse, as the number of terminal servers grows, this maintenance problem becomes more difficult.
radius allows an administrator to keep authentication and accounting data in a single place, no matter how many network access servers are actually present. Using radius, nases instead communicate with this central server to perform authentication and accounting, thus easing the burden on the system administrator.
Let's return to our imaginary ISP. Suppose it runs a radius daemon on its central server. Each nas runs client software to communicate with the radius server by sending radius packets.
An average user session life cycle looks as follows.
A user connects to the nearest nas and supplies his login and password. The nas forms an authentication request and sends it to the radius server.
The radius server verifies the user's credentials and finds them sufficient. It then retrieves the user's authorization information from its database, packages it into an acknowledgement packet, and then sends it back to the nas
The nas receives the acknowledgement packet and starts the user session. The information brought with the packet tells the nas to establish a connection between the core router and the user, and to assign the user a certain IP address. Having established the session, the nas informs the radius server by sending it an accounting start packet. The server acknowledges the receipt of the accounting packet.
Now suppose that after some time the user decides to break the connection. The nas notices this and terminates the user's session. The nas then sends an accounting stop packet to the radius server to mark this event. Again, the server acknowledges the receipt of the packet.
Attributes are means of passing the information between the nas and the server. Basically, an attribute is an integer number that identifies some piece of information. A set of properties are associated with each attribute, specifying the way to interpret the attribute. The most important property is the data type, which declares the type of data that the attribute identifies (character string, integer number, IP address, or raw binary data).
The information to be transmitted with the request is packaged in a set of attribute-value pairs (or a/v pairs for short). Such pairs consist of attribute numbers and the associated data.
There exist two basic kinds of radius packets: authentication and accounting packets. Each of them is subdivided into requests and replies.
Authentication requests are sent from the nas to the radius server and contain the information necessary to check the identity of the user. The minimum set of data in such packets consists of the user login name, user password, and nas IP or identifier.
Authentication replies are sent by the radius server and contain the reply code and a set of additional attributes. According to their reply code the authentication replies are subdivided into authentication acknowledgements, authentication rejections, and authentication challenges.
An authentication acknowledgement packet is sent to the nas if the credentials supplied with the authentication request were correct. This kind of packet tells the nas to establish a normal user session. The additional attributes in such packets carry the authorization data, i.e., they determine which kind of service the user is to be provided.
An authentication rejection is sent to the nas if the authentication has failed. This packet forbids the nas to provide any service to the user. The additional attributes may carry descriptive text to be displayed as an explanation to the user for the failure of his request.
Finally, an authentication challenge packet is sent to the nas if the supplied credentials did not suffice to establish the authenticity of the user. This means that the dialog between the nas and the radius server continues. As the radius server asks for additional authentication credentials, the nas acts as a liaison, passing server requests to the user and sending user replies back to the server. Such a dialog ends when the radius server sends either an acknowledgement packet or a rejection packet.
An accounting request is sent to the server when the nas wishes to report some event in the user session: the start of the session, session termination, etc. The attributes carry the actual information about the event.
For each accounting request that has been received and successfully processed, the radius server sends back an accounting acknowledgement. This packet carries no attributes, but simply informs the nas that the information it had sent was received.
Occasionally, a radius server may fail to receive incoming requests or may fail to process them due to high server load. In order to prevent such requests from being lost, the nas retransmits the request if no response from the server is received within a predefined interval of time (a timeout interval). Usually the nas is configured in such a way that it continues retransmitting failed requests until either it receives a reply from the server or a predefined number of retries are exhausted, whichever occurs first. Furthermore, a nas may be configured to communicate with a set of backup radius servers. In this case it applies the described process to each server from the set, until one of them responds or the set is exhausted.
This chapter describes file naming conventions used throughout this document.
Programs from the GNU Radius package use the following directories to store various configuration and log files:
Rewrite
or Scheme source files.
The default locations of these directories are determined at compile time. Usually these are:
These locations may differ depending on your local site configuration.
Throughout this document we will refer to these directories by their short names. For example, when we say:
... this information is contained in file raddb/sqlserver
we actually mean /usr/local/etc/raddb/sqlserver.
To get the default directory names that your version of Radius was compiled with, run radiusd --version.
Locations of these directories may be overridden by specifying the appropriate command line options. For example, any program from the GNU Radius package accepts the command line option -d or --directory, which introduces the configuration directory path.
The main purpose of GNU Radius is to centralize authentication of users coming from various network stations, pursuant to the radius specification. Its primary usage is for dial-in users, though it can be used for any kind of network connection.
Information carried by radius requests is stored as a list of attribute-value pairs. Each pair consists of an attribute number and an attribute value. The attribute number identifies the type of information the pair carries, and the attribute value keeps the actual data.
The value part of an attribute can contain data of one of the following types:
For convenience, the attributes and the values of some frequently used integer attributes are given symbolic names. These names are assigned to attributes and values in the dictionary file (see dictionary file).
Attribute numbers range from 1 to 255. Attributes with numbers greater than 255 are used internally by the server and cannot be sent to the nas.
The vendor-specific attribute number 26 is special, allowing vendors of the nas hardware or software to support their own extended attributes. vendor-specific attribute.
Each attribute has a set of properties associated with it. The properties are:
Attributes are declared in the raddb/dictionary file. For a detailed description, see ATTRIBUTE. For information about particular attributes, see Attribute List.
The term request refers to both the authentication/accounting request packet from a nas to a radius server and the response packet that the server sends back to the nas.
Each request contains the following fields:
A nas sends authentication requests (packets with code field set to Access-Request) to a radius server when a user is trying to connect to that nas. Such requests convey information used to determine whether a user is allowed access to the nas, and whether any special services are requested for that user.
An Access-Request must contain a User-Name attribute
User-Name. This packet should contain a NAS-IP-Address
attribute, a NAS-Identifier attribute, or both. It
also must contain either a User-Password attribute or a
CHAP-Password attribute. These attributes are passed after
being encoded
using a method based on the RSA Message Digest Algorithm MD5.
The Access-Request should contain a NAS-Port or NAS-Port-Type
attribute or both, unless the type of access being requested does
not involve a port or the nas does not distinguish among its
ports.
Upon receiving an Access-Request packet for a particular user and authenticating that user, the radius server replies to the nas that has sent the packet with any one of the following packets:
GNU Radius replies with an Access-Accept packet when it has successfully authenticated the user. Such a reply packet provides the configuration information necessary to begin delivery of service to the user.
GNU Radius replies with an Access-Reject packet when it is unable to
authenticate the user. Such a packet may contain a descriptive text
encapsulated in one or more Reply-Message attributes. The
nas may display this text along with its response to the user.
GNU Radius replies with an Access-Challenge packet when it needs to obtain more information from the user in order to determine the user's authenticity or to determine the kind of service to be provided to the user.
An Access-Challenge packet may include one or more
Reply-Message attributes, and it may or may not include a
single State attribute. No other attributes are permitted in an
Access-Challenge packet.
Upon receipt of an Access-Challenge, the Identifier field is matched with a pending Access-Request. Additionally, the Response Authenticator field must contain the correct response for the pending Access-Request. In the event of an invalid packet, GNU Radius discards the offending packet and issues the appropriate log message.
If the nas does not support challenge/response, it treats an
Access-Challenge as though it had received an Access-Reject instead.
Otherwise, upon receipt of a valid Access-Challenge the nas prompts
the user for a response, possibly displaying the text message provided
in the Reply-Message attributes of the request. It then sends its
original Access-Request with a new request id and request
authenticator, along with the User-Password attribute replaced
by the encrypted user's response, and including the State
attribute from the Access-Challenge, if any.
Accounting-Request packets are sent from a nas to a radius server to allow for accounting of a service provided to a user.
Upon receipt of an Accounting-Request packet, the server attempts to record it (see Accounting), and if it succeeds in doing so, it replies with an Accounting-Response packet. Otherwise, it sends no reply, which then causes the nas to retransmit its request within a preconfigured interval of time. Such retransmits will continue until either the server responds with an Accounting-Response packet or a preconfigured number of retransmits is reached, whichever occurs first.
Any attribute valid in an Access-Request or Access-Accept packet is also valid in an Accounting-Request packet, except the following attributes, which are never present in any Accounting-Request packet:
User-Password
CHAP-Password
Reply-Message
State
Either a NAS-IP-Address or a NAS-Identifier must be
present in an Accounting-Request packet. It should contain either a
NAS-Port or a NAS-Port-Type attribute (or both),
unless the service does not involve a port or the nas
does not distinguish among its ports.
If the Accounting-Request packet includes a Framed-IP-Address,
that attribute must contain the actual IP of the user.
There are five types of accounting packets, differentiated by the
value of the Acct-Status-Type attribute. These are:
Acct-Status-Type = Start
User-Name
Acct-Session-Id
NAS-IP-Address
NAS-Port-Id
Acct-Status-Type = Stop
User-Name
NAS-IP-Address
Acct-Session-Id
The last three of them are used to find the corresponding session
start packet.
Acct-Status-Type = Alive
User-Name
NAS-IP-Address
Acct-Session-Id
Acct-Status-Type = Accounting-Off
NAS-IP-Address
Acct-Status-Type = Accounting-On
NAS-IP-Address
A record in the GNU Radius database describing a particular rule for matching an incoming request is called a matching rule. Each such rule defines an action to be taken when the match occurs.
The matching rule consists of three distinct parts:
DEFAULT and BEGIN are reserved. These will be described
in detail below.
The following GNU Radius configuration files keep data in a matching rule format: hints, huntgroups, and users. Although they keep data in a similar format, the rules that are used to match incoming requests against the contents of these files differ from file to file. The following section describes these rules in detail.
Upon receiving a request, radiusd applies to it a number of checks to determine whether the request comes from an authorized source. If these checks succeed, the request is processed and answered. Otherwise, the request is dropped and corresponding error message is issued (see Logging).
The following checks are performed:
User-Name attribute, it is not processed.
User-Password attribute.
As described above (see Operation), a nas may decide to retransmit the request under certain circumstances. This behavior ensures that no requests are lost. For example, consider the following scenario:
Thus the radius server will receive and process the same request
twice. This probably won't do any harm if the request in question is an
authentication one, but for accounting requests it will lead to
duplicate accounting. To avoid such an undesirable effect, radiusd
keeps a queue of received requests. When an incoming request arrives,
radiusd first scans the request queue to see if the request is a
duplicate. If so, it drops the request; otherwise, it inserts the
request into the queue for processing. After the request is completed,
it will still reside in the queue for a preconfigured interval of time
(see auth, parameter request-cleanup-delay).
By default, radiusd considers two requests to be equal if the following conditions are met:
Additionally, radiusd may be configured to take into account the contents of both requests. This may be necessary, since some nases modify the request authenticator or request identifier before retransmitting the request, so the method described above fails to recognize the request as a duplicate. This extended comparison is described in detail in Extended Comparison.
Proxying is a mode of operation where a radius server forwards incoming requests from a nas to another radius server, waits for the latter to reply, and then forwards the reply back to the requesting nas. A common use for such operation mode is to provide roaming between several internet service providers (ISPs). Roaming permits ISPs to share their resources, allowing each party's users to connect to other party's equipment. Thus, users traveling outside the area of one ISP's coverage are still able to access their services through another ISP.
Suppose the ISP ‘Local’ has a roaming arrangement with the ISP ‘Remote’. When the user of ‘Remote’ dials in to the nas of ‘Local’, the nas sends the authentication request to the ‘Local’ radius server. The server then determines that this is a roaming user, stores a copy of the request in its internal queue, and forwards the request to the ‘Remote’ radius server for processing. Thus, the ‘Local’ radius server acts as a client for the ‘Remote’ radius server.
When the ‘Remote’ radius server responds, the ‘Local’
radius server receives the response, and passes it back to the
nas. The copy of the request from the server's queue determines
which nas originated the request. Before passing the request back
to the nas, the server removes information specific to the
‘Remote’ site, such as Framed-IP-Address,
Framed-Netmask, etc. Only the attributes marked with a
‘propagation’ flag (see Attributes) are passed back to the
nas. After removing site-specific attributes, the ‘Local’
radius server passes the request through its user profiles
(see User Profiles) to insert any local, site-specific information
that might be needed. Finally, it passes the reply back to the nas.
Proxied accounting requests are processed in a similar manner, except that no attribute filtering takes place, as accounting responses do not carry any a/v pairs.
This example illustrates only the simplest proxy chain, consisting of two servers; real-life proxy chains may consist of several servers. For example, our ‘Remote’ radius server might also act as a proxy, forwarding the request to yet another radius server, and so on.
Note that when the accounting request passes through a chain of forwarding servers, the accounting records are stored on all servers in the chain.
GNU Radius determines which server a request must be forwarded to by the request's authentication realm. There are three kinds of realms:
GNU Radius keeps the information about the realms it serves in the raddb/realms configuration file (see realms file).
User-name hints are special rules that modify the incoming
request depending on the user name and its credentials. Hints are
stored as a list of matching rules (see Matching Rule). Upon
receiving a request, radiusd scans the hint entries sequentially,
comparing each rule's label with the value of the
User-Name attribute from the request. If they coincide, then
radiusd appends the contents of the rule's rhs to the request's
pair list.
The two user names must match exactly in order for a hint to take effect,
unless the hint's checklist contains either the Prefix or the
Suffix attribute. The special name ‘DEFAULT’ or
‘DEFAULT%d’ (where %d denotes any decimal number),
used as a hint's
label, matches any user name.
Two special attributes, Prefix and Suffix, may be used
in lhs to restrict the match to a specified part of a
user name. Both are string attributes. The Prefix instructs
radiusd to accept the hint only if the user name begins with the
given prefix. Similarly, Suffix instructs radiusd to accept
the hint only if the user name ends with the given suffix. A hint may
contain both Prefix and Suffix attributes.
In addition to these two attributes, a hint's lhs may contain
User-ID and Group attributes.
The following attributes, when used in a hint's rhs have special meaning. They are not appended to the request pair list. Instead, they are removed after completing their function:
Fall-ThroughYes, radiusd
continues scanning the hints after processing the current entry. This
allows radiusd to apply several hints to a single packet.
Rewrite-FunctionReplace-User-NameUser-Name attribute from the
request.
Hint rules are defined in the raddb/hints file (see hints file).
Huntgroups are special rules that allow an administrator to provide alternate processing of certain incoming requests depending on the nas IP and port number they come from. These rules are stored as a list of matching rules (see Matching Rule).
Upon receiving a request, radiusd scans this list sequentially until it finds an entry such that the conditions set forth in its lhs are matched by the request. If such an entry is found, radiusd verifies that the request meets the conditions described by rhs. If it does not, the request is rejected. In short, a huntgroup requires that any request matching its lhs must match also its rhs.
The label part of the rule is not used in comparisons; instead
it is used to label huntgroups. All entries with the same label form a
single huntgroup. The special attribute Huntgroup-Name can be
used to request a match against a particular huntgroup
(see Huntgroup-Name).
Huntgroup rules are defined in the raddb/huntgroups file (see huntgroups file).
User profiles are per-user matching rules
(see Matching Rule). All incoming authentication requests are
compared with the user profiles after they have passed both
hints and huntgroups. radiusd selects the user
profiles whose label matches the value of the User-Name
attribute from the incoming request.
The selected profiles form the list of authentication rules for the
request. In order for a profile to be selected, its label must either
coincide literally with the User-Name value, or be one
of the special labels, DEFAULT or BEGIN.
Rules in an authentication list are ordered as follows: first go all
the profiles with the BEGIN label, followed by the profiles whose
labels match the User-Name literally, followed finally by the rules
labeled with the DEFAULT. 1
Within each of the three sublists, the rules preserve the order in
which they appear in the raddb/users file. Once the list is
constructed, it is scanned sequentially until the rule is found whose
lhs matches the incoming request. If no such rule is found, the
authentication fails. Otherwise, the contents of its rhs are
appended to the reply list being constructed. If the rhs of
the matched rule contains the attribute Fall-Through with the
value Yes, the matching continues. When the list is exhausted,
the authentication result is sent back to the nas along with the
a/v pairs collected in the reply list.
User profiles are defined in the raddb/users file (see users file).
When started radiusd uses the configuration values from the following sources (in order of increasing precedence):
Whenever a command line options has its equivalent in config file the use of this equivalent should be preferred (see config file).
The following command line options are accepted:
Config file equivalent: auth { detail yes; };.
Config file equivalent: option { acct-dir DIR; };.
Config file equivalent: usedbm yes;.
Config file equivalent: option { source-ip IP; };.
Note that listen statement in raddb/config
provides a better control over ip addresses to listen on (see auth, and
see acct).
Config file equivalent: option { log-dir DIR; };.
Config file equivalent: option { resolve no };.
Config file equivalent: auth { strip-names yes };.
MODULE
MODULE = LEVEL
where MODULE is the module name or any non-ambiguous assignment thereof, LEVEL is the debugging level in the range 0-100. Debugging
Config file equivalent:
logging {
category debug {
level DEBUG_LEVEL;
};
};
Config file equivalent: logging { category auth { detail yes;
}; }; .
Config file equivalent:
logging {
category auth {
print-pass yes;
};
};
See config file.
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 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.
The rest of this chapter describes each of these files in detail.
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:
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.
resolveresolve no speeds up the server and reduces
the network traffic.
source-ipmax-requestsmax-processesprocess-idle-timeoutmaster-read-timeoutmaster-write-timeoutmaster-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-userSystem (see System Auth) requires
root privileges, so it cannot be used with radiusd-user. Any
raddb/users profiles using this authentication type will be
discarded.
PAM (see PAM Auth) 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-userExec-Program and Exec-Program-Wait. The real user
and group ids will be retrieved from the /etc/passwd entry
for the given user.
username-charsusername-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-diracct-dirlogging 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.
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 Logging Hook Functions.
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-authprint-passprint-failed-passchannel 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 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-pidprint-consprint-categoryprint-priorityprint-levelprint-millisecondsprefix-hooksuffix-hooklogging 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;
};
};
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 ;
} ;
The auth statement configures the parameters of the authentication
service.
listen statementThis 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 statementThis 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.
portmax-requeststime-to-liverequest-cleanup-delaypassword-expire-warningdetailstrip-namescheckrad-assume-loggedauth for compatibility with previous versions of GNU Radius.
trace-rulesreject-malformed-namesUser-Name attribute. By default
such requests are discarded without answering. See the description of
username-chars (see username-chars).
compare-attribute-flagacct 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 statementThis 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 statementThis 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.
portmax-requeststime-to-liverequest-cleanup-delaydetailno, disables detailed accounting
(see Detailed Request Accounting).
systemno, disables system accounting (see System Accounting). Notice, that this will disable simultaneous use checking
as well, unless you supply an alternative mlc method (currently
sql, See Multiple Login Checking, for the detailed discussion
of this).
trace-rulescompare-attribute-flagusedbm statementusedbm ( yes | no ) ;
The usedbm statement determines whether the DBM support should
be enabled.
noyessnmp 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 ;
} ;
};
The snmp statement configures the SNMP service.
listen statementThe 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;
portmax-requeststime-to-liverequest-cleanup-delayidentcommunity name ( rw | ro )rw) or read-only
(ro).
network name network [ network ... ]allow network_name community_namedeny NETWORK_NAMEGNU 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.
filepermsmax-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
|
rewrite statement.(This message will disappear, once this node revised.)
rewrite {
stack-size number ;
load-path string ;
load string ;
};
stack-sizeload-pathloadload-path statement.
The default load path is RADDB:DATADIR/rewrite.
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 ;
};
debuggc-intervalgc-interval statement sets
such interval in seconds.
For more information about Guile memory management system in general and garbage collections in particular, see Memory Management and Garbage Collection.
evalScheme expression.
load-path%load-path variable.
loadload-moduleGuile
rules, except that the ones starting with a dash (‘-’) are
converted to keyword arguments.
outfileGuile
functions to the given file. Unless the filename starts with ‘/’,
it is taken relative to the current logging directory.
See Guile, for a detailed description of Guile extensions interface.
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 Macro Substitution).
account-closedpassword-expiredpassword-expire-warningpassword-expire-warning variable in auth block.
See auth. 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-deniedrealm-quotamultiple-loginsecond-loginmultiple-login, which is used when
the user's login limit is 1.
timespan-violationfilters statement
The filters statement configures user-defined external filters.
See 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 Exec-Program-Wait).
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.
mlc statement mlc {
method (system|sql);
checkrad-assume-logged bool;
};
Mlc statement configures multiple login checking subsystem
(see Multiple Login Checking).
method
to system will use system accounting database (see System Accounting). This is the default method. Setting it to sql
will use sql database.
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.
The dictionary file raddb/dictionary defines the symbolic names for radius attributes and their values (see 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:
stringintegeripaddrdateComments are introduced by a pound sign (‘#’). Everything starting from the first occurrence of ‘#’ up to the end of line is ignored.
$INCLUDE filename
The $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.