[Top] | [Contents] | [Index] | [ ? ] |
GNU Radius is a suite of programs for performing user authentication and accounting using RADIUS protocol.
This Info file documents the version 1.3 of the package.
Introduction to Radius An introduction to RADIUS concepts
The RADIUS daemon
2. Naming Conventions Conventions about naming files and directories 3. How Radius Operates How radiusd
operates4. How to Start the Daemon. How to start the daemon 5. Radius Configuration Files radiusd
configuration files6. Request Comparison Methods How duplicate requests are dealt with 7. Authentication How users are authenticated 8. Accounting Accounting methods 9. Logging What gets logged and where 10. Problem Tracking Fixing configuration errors 11. Extensions Extending GNU Radius
12. Utility Programs 13. Client Package
Radius Attributes
14. Attribute List Some frequently used attributes
Reporting Bugs and getting information
15. Reporting Bugs How to report a bug 16. Where to Get Information about GNU Radius Where to get info about GNU Radius
Obtaining GNU Radius
How to Obtain Radius How to Obtain the GNU Radius Radius Glossary The glossary Acknowledgements
What Next?
17. New Configuration Approach (draft) New configuration
Appendices
A. GNU Free Documentation License The GNU Free Documentation License.
Indices
Index
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
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.
Client configuration
13.1 Client Configuration Main client configuration file.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
1.0 Overview
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
radiusd
stores its log files.
radiusd
stores accounting detail files
(see section 8.2 Detailed Request Accounting).
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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
3.1 Attributes 3.2 RADIUS Requests RADIUS requests. 3.3 Matching Rule Rules for request processing. 3.4 Processing Requests How GNU Radius processes incoming requests.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 section 5.2 Dictionary of Attributes -- `raddb/dictionary').
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:
radiusd
scans the request to see if it already contains a pair with the same
attribute. If it does, the value of the additivity determines the
following additional actions:
Attributes are declared in the `raddb/dictionary' file. For a detailed description, see 5.2.4 ATTRIBUTE statement. For information about particular attributes, see 14. Attribute List.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
The list of attribute-value pairs carrying actual information about the request.
3.2.1 Authentication Requests 3.2.2 Accounting Requests
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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
14.1.24 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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 section 8. 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
radiusd
mark all
sessions registered from this particular NAS as finished. Receiving
this packet usually means that the NAS is to be shut down, or is
about to change its configuration in a way that requires all currently
opened sessions to be closed. The packet must contain at least the
following attributes:
Acct-Status-Type = Accounting-Off
NAS-IP-Address
radiusd
that it is ready
to accept the incoming connections. Usually this packet is sent after
startup, or after a major reconfiguration of the NAS. It must
contain at least the following attributes:
Acct-Status-Type = Accounting-On
NAS-IP-Address
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 section 9. Logging).
The following checks are performed:
User-Name
attribute, it is not processed.
User-Password
attribute.
3.4.1 Checking for Duplicate Requests 3.4.2 Proxying 3.4.3 Hints 3.4.4 Huntgroups 3.4.5 User Profiles
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
As described above (see section 3. How Radius Operates), 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 section 5.1.3 auth
statement, 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 6.1 Extended Comparison.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
3.4.2.1 Proxy Service 3.4.2.2 Realms
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 section 3.1 Attributes) are passed back to the
NAS. After removing site-specific attributes, the `Local'
RADIUS server passes the request through its user profiles
(see section 3.4.5 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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 section 5.8 List of Proxy Realms -- `raddb/realms').
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 section 3.3 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-Through
Yes
, radiusd
continues scanning the hints after processing the current entry. This
allows radiusd
to apply several hints to a single packet.
Rewrite-Function
Replace-User-Name
User-Name
attribute from the
request.
Hint rules are defined in the `raddb/hints' file (see section 5.6 Request Processing Hints -- `raddb/hints').
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 section 3.3 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 section 14.3.12 Huntgroup-Name
).
Huntgroup rules are defined in the `raddb/huntgroups' file (see section 5.7 Huntgroups -- `raddb/huntgroups').
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
User profiles are per-user matching rules
(see section 3.3 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 section 5.9 User Profiles -- `raddb/users').
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 section 5.1 Run-Time Configuration Options -- `raddb/config').
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;
.
radiusd
will listen on.
If this option is not specified, the program will listen on all
IP addresses, assigned to the machine it runs on.
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 section 5.1.3 auth
statement, and
see section 5.1.4 acct
statement).
Config file equivalent: option { log-dir DIR; };
.
builddbm
.
radiusd
starts an interactive interpreter
which allows to test various aspects of its configuration.
Do not resolve IP addresses for diagnostic output. This can reduce the amount of network traffic and speed up the server.
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. 10.2 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 section 5.1 Run-Time Configuration Options -- `raddb/config'.
[ < ] | [ > ] | [ << ] | [ 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 option
blockOption
block: set the global program options.5.1.2 logging
blockFine-tune the logging. 5.1.3 auth
statementConfigure authentication service. 5.1.4 acct
statementConfigure accounting service. 5.1.5 usedbm
statementEnable the DBM feature. 5.1.6 snmp
statementConfigure SNMP service. 5.1.7 rewrite
statement.Configure Rewrite interface. 5.1.8 guile
statementConfigure Guile interface. 5.1.9 message
statementConfigure server reply messages. 5.1.10 filters
statementConfigure authentication and accounting filters. 5.1.11 mlc
statementConfigure 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 category
statement5.1.2.3 channel
statement5.1.2.4 Example of the logging
statement
[ < ] | [ > ] | [ << ] | [ 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
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The basic notions about comparison of the incoming requests and why it is necessary were given in 3.4.1 Checking for Duplicate Requests. This chapter concentrates on extended methods of request comparison and on the configuration issues.
6.1 Extended Comparison 6.2 Fine-Tuning the Request Queue
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The default comparison method may fail to recognize duplicate requests. if the originating NAS has modified the request authenticator or request identifier before retransmitting the request. If you happen to use such NASes, you will have to enable extended request comparison to compensate for their deficiencies.
The extended request comparison consists in comparing the
contents of both requests. However, blindly comparing
each A/V pair from both requests won't work, since many attributes do
change their values between successive retransmits. Therefore,
radiusd
uses only comparable attribute, i.e. a
user-defined subset of such attributes that can safely be used in
comparison. Thus, extended request comparison works as follows:
Password
and
CHAP-Password
are decoded prior to comparison.
To use the extended comparison, follow the procedure below:
The syntax of dictionary file allows for nine user-defined properties,
denoted by characters `1' through `9'. You should select one of
them to mark comparable attributes for authentication and another one to
mark those for accounting. It is strongly suggested that you use
PROPERTY
statement in your main dictionary file
(see section 5.2.7 PROPERTY statement), instead of modifying ATTRIBUTE
statements
in the underlying dictionary files.
See section 5.2.4 ATTRIBUTE statement, for detailed description of attribute property flags.
To enable the extended comparison for authentication requests,
add to your auth
block the statement
compare-attribute-flag flag; |
The flag is the same symbol you used in the dictionary to mark comparable attributes for authentication.
To enable the extended comparison for accounting requests, insert
compare-attribute-flag
statement into the acct
block.
Add the following statement to the declaration of those NASes, that require using the extended comparison (in flags column):
compare-auth-flag=flag,compare-acct-flag=flag |
See section 5.4 NAS List -- `raddb/naslist', for a description of naslist file syntax.
6.1.1 An example of extended comparison configuration 6.1.2 List of attributes that can be declared comparable.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In this example configuration, the user-defined flag `1' marks authentication comparable attributes, and the flag `2' marks the accounting comparable attributes.
PROPERTY User-Name +12 PROPERTY Password +1 PROPERTY NAS-Port-Id +12 PROPERTY State +1 PROPERTY Called-Station-Id +12 PROPERTY Calling-Station-Id +12 PROPERTY Acct-Status-Type +2 PROPERTY Acct-Session-Id +2 PROPERTY Acct-Session-Time +2 |
auth { max-requests 127; request-cleanup-delay 2; compare-attribute-flag 1; }; acct { max-requests 127; request-cleanup-delay 2; compare-attribute-flag 2; }; |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following attributes can be declared as comparable:
User-Name
Password
CHAP-Password
NAS-Port-Id
State
Called-Station-Id
Calling-Station-Id
NAS-Identifier
Acct-Status-Type
Acct-Session-Id
Acct-Session-Time
User-UID
User-GID
Notice that this list is by no means an exhaustive one. Depending on a particular NAS other attributes may be safe to be used in comparisons, or, vice-versa, some attributes from this list may not be used. You should carefully analyze packets coming from your NAS before deciding which attributes to mark as comparable.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
As described in 3.4.1 Checking for Duplicate Requests, each request is added
to the request queue when radiusd
starts processing it
and is removed from there a certain amount of time after its
processing was finished. The configuration parameter
request-cleanup-delay
defines how long each already processed
request is kept in the queue. Its value must be synchronized with
the NAS settings.
Each NAS allows to configure two parameters:
Ntimeout
Nretries
Of course, these parameters are named differently for different makes of NASes. Refer to your NAS documentation to find out where these values are configured.
In general, these parameters must satisfy the following relation:
request-cleanup-delay = Nretries * Ntimeout + const |
where const is an empirical constant that depends on the average time of processing a single request. Usually its value lies between 0 and 10 seconds.
For example, if the configuration of your NAS sets
Nretries = 3 Ntimeout = 10 |
then your raddb/config should contain:
auth { request-cleanup-delay 40; }; acct { request-cleanup-delay 40; }; |
Notice the duplication of request-cleanup-delay
:
radiusd
uses distinct values for authentication
and accounting requests, however most existing NASes do
not make such distinction.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An Authentication Type specifies which credentials the user
is required to supply in order to be authenticated and where the
user's authentication data are stored. It is defined by the value
of Auth-Type
attribute in LHS of a `users' entry.
7.1 Accept Authentication Type Accept unconditionally. 7.2 Reject Authentication Type Reject unconditionally. 7.3 Local Password Authentication Type Authenticate using plaintext password. 7.4 Encrypted Password Authentication Type Authenticate using MD5 encrypted password. 7.5 System Authentication Type Authenticate using system account. 7.6 SQL Authentication Type Authenticate using SQL. 7.7 PAM Authentication Type Authenticate using PAM. 7.8 Defining Custom Authentication Types 7.9 Multiple Login Checking Checking for Simultaneous Logins. 7.10 Controlling Authentication Probes
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Accept is the simplest authentication type. Users with this authentication type will be authenticated successfully without checking any credentials. Actually this means that only username is required for authentication.
This authentication type is used for each `users' entry, whose LHS contains
Auth-Type = Accept |
This authentication type can be used for guest accounts, e.g. the following profile in `users':
guest Auth-Type = Accept, Simultaneous-Use = 10 Service-Type = Framed-User, Framed-Protocol = PPP |
allows up to 10 simultaneous guest PPP accounts. To log in using such guest account it is sufficient to use username `guest' and any password.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The Reject authentication type causes the request to be rejected unconditionally. It can be used to disable a user account (For another method of disabling user accounts, see section 5.10 List of Blocked Users -- `raddb/access.deny').
This authentication type is used for each `users' entry, whose LHS contains
Auth-Type = Reject |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The Local Password authentication type allows to keep plaintext user passwords. Although the use of this authentication type is strongly discouraged for security reasons, this is the only authentication type that can be used with CHAP authentication.
There are two ways of using this authentication type
user-name Auth-Type = Local, User-Password = plaintext |
The plaintext is the user's plaintext password. Obviously,
user-name may not be DEFAULT
nor BEGIN
.
user-name Auth-Type = Local, Password-Location = SQL |
When the user is authenticated using such profile, its password
is retrieved from the authentication database using auth_query
.
The configuration of SQL authentication is described in
detail in 5.11.2 Authentication Server Parameters.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The Encrypted Password type allows to keep user's passwords encrypted via DES or MD5 algorithm. There are two ways of using this authentication type.
user-name Auth-Type = Crypt-Local, User-Password = crypt-pass |
The Crypt-Password
is a shortcut for the above notation:
user-name Crypt-Password = crypt-pass |
user-name Auth-Type = Crypt-Local, Password-Location = SQL |
Using this profile, the user's password is retrieved from the
authentication database using auth_query
.
The configuration of SQL authentication is described in
detail on 5.11.2 Authentication Server Parameters.
The shortcut for this notation is Auth-Type = SQL
.
In any case, the passwords used with this authentication type must be either DES or MD5 hashed.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The System authentication type requires that the user have a valid system account on the machine where the radius server is running. The use of this type is triggered by setting
Auth-Type = System |
in the LHS of a `users' entry.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Setting Auth-Type = SQL
or Auth-Type = Mysql
in the LHS of a `users' entry is a synonym for
Auth-Type = Crypt-Local, Password-Location = SQL |
and is provided as a shortcut and for backward compatibility with previous versions of GNU Radius.
For description of SQL authentication, see 7.4 Encrypted Password Authentication Type. The configuration of SQL subsystem is described in 5.11 SQL Configuration -- `raddb/sqlserver'.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
PAM authentication type indicates that a user should be authenticated using PAM (Pluggable Authentication Module) framework. The simplest way of usage is:
Auth-Type = PAM |
Any user whose `users' profile contains the above, will be
authenticated via PAM, using service name `radius'.
If you wish to use another service name, set it using Auth-Data
attribute, e.g.:
Auth-Type = PAM, Auth-Data = pam-service |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The are three ways to define custom authentication types:
You can write a PAM module implementing the new authentication
type. Then, specifying Auth-Type = PAM
allows to apply
it (see section 7.7 PAM Authentication Type).
Alternatively, you may write a Scheme procedure implementing the new
authentication type. To apply it, use Scheme-Procedure
attribute
in RHS. The Auth-Type = Accept
can be used in LHS if
the whole authentication burden is to be passed to the Scheme procedure.
For example, if one wrote a procedure my-auth
, to apply it to
all users, one will place the following profile in his `users'
file:
DEFAULT Auth-Type = Accept Scheme-Procedure = "my-auth" |
For a discussion of how to write Scheme authentication procedures, See section 11.3.2 Authentication with Scheme.
The third way to implement your own authentication method is using an external program. This is less effective than the methods described above, but may be necessary sometimes. To invoke the program, use the following statement in the RHS of `users' entry:
Exec-Program-Wait = "progname args" |
The progname must be the full path to the program, args --- any arguments it needs. The usual substitutions may be used in args to pass any request attributes to the program (see section 5.14 Macro Substitution).
For a detailed description of Exec-Program-Wait
attribute and
an example of its use, see 14.3.7 Exec-Program-Wait
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The number of sessions a user can have open simultaneously can be
restricted by setting Simultaneous-Use
attribute in the user's
profile LHS (see section 14.3.25 Simultaneous-Use
). By default the number
of simultaneous sessions is unlimited.
When a user with limited number of simultaneous logins authenticates
himself, Radius counts the number of the sessions that are already
opened by this user. If this number is equal to the value of
Simultaneous-Use
attribute the authentication request is
rejected.
This process is run in several stages. First, Radius retrieves the
information about currently opened sessions from one of its accounting
databases. Then, it verifies whether all these sessions are still
active. This pass is necessary since an open entry might be a result
of missing Stop
request. Finally, the server counts the
sessions and compares their count with the value of
Simultaneous-Use
attribute.
The following subsections address each stage in detail.
7.9.1 Retrieving Session Data 7.9.2 Verifying Active Sessions
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Radius retrieves the list of sessions currently opened by the user either from the system database (see section 8.1 System Accounting), or from the SQL database (see section 8.3 SQL Accounting). The system administrator determines which method to use.
By default, system accounting database is used. Its advantages are simplicity and ease of handling. It has, however, a serious deficiency: the information is kept in the local files. If you run several radius servers, each of them has no easy way of knowing about the sessions initiated by other servers.
This problem is easy to solve if you run SQL accounting (see section 8.3 SQL Accounting). In this case, each radius server stores the data in your SQL database and can easily retrieve them from there.
To enable use of SQL database for multiple login checking, do the following:
In your `raddb/config' file set:
mlc { method sql; }; |
In your `raddb/sqlserver' file, specify the queries for retrieving the information about open sessions and, optionally, a query to close an existing open record.
There are two queries for retrieving the information:
mlc_user_query
returns the list of sessions opened by the user,
mlc_realm_query
returns the list of sessions opened for the
given realm. Each of them should return a list of 5-element
tuples(4):
user-name, nas-ip-address, nas-port-id, acct-session-id |
Here is an example of mlc_user_query
and mlc_realm_query
:
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}' |
Apart from these two queries you may also wish to provide a query for
closing a hung record. By default, radiusd
will use
acct_stop_query
. If you wish to override it, supply a query
named mlc_stop_query
, for example:
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}' |
See section 5.11.4.1 Writing SQL Accounting Query Templates, for detailed information on how to write these queries.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Whatever database radiusd
uses, an open entry in it does not
necessary mean that the corresponding session is still being
active. So, after retrieving the information about user sessions,
Radius verifies on corresponding NASes whether these are actually
active.
For each entry in the session list, if its NAS acknowledges the session, the session count is incremented. Otherwise, such entry is marked as closed in the database and is not counted.
There may also be cases when the NAS is unreachable due to some
reasons. In such cases the Radius behavior is determined by the value
of checkrad-assume-logged
in `config' file
auth statement (raddb/config). If the value is yes
,
Radius assumes the session is still active and increases the session
count, otherwise it proceeds as if the NAS returned negative reply.
To query a NAS, Radius first looks up its type and additional parameters
in `naslist' file (see section 5.4 NAS List -- `raddb/naslist'). There are two
predefined NAS types that cause Radius to act immediately without
querying tne NAS: the special type `true' forces Radius to act
as if the NAS returned 1, the type `false' forces it to act
as if the NAS returned 0. If the type is neither of this predefined types,
Radius uses it as a look up key into the `nastypes' file
(see section 5.5 NAS Types -- `raddb/nastypes') and tries to retrieve an entry which has
matching type. If such entry does not exist, Radius issues the error
message and acts accordingly to the value of configuration variable
checkrad-assume-logged
. Otherwise, Radius determines the query
method to use from the second field of this entry, and constructs method
arguments by appending arguments from the `naslist' entry to
those of nastypes
entry. Note, that the former take precedence over the
latter, and can thus be used to override default values specified
in `nastypes'.
Having determined the query method and its argument, Radius queries
NAS and analyzes its output by invoking a user-supplied
Rewrite function. The function to use
is specified by the function=
argument to the method. It is
called each time a line of output is received from the NAS (for
finger queries) or a variable is received (for SNMP queries). The
process continues until the function returns 1 or the last line
of output is read or a timeout occurs whichever comes first.
If the user-function returns 1 it is taken to mean the user's session is now active at the NAS, otherwise, if it replies 0 or if the end of output is reached, it is taken to mean the user's session is not active.
The syntax conventions for user-supplied functions are described in detail in 11.2.5 Login Verification Functions.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Authentication probe is an attempt of a user to use other user's account, by guessing his password. The obvious indication of an authentication probe is appearence of several consecutive authentication failures for the same user. Of course, if the intruder is given sufficient number of such probes he will sooner or later succeed in finding the actual password. The conventional method to prevent this from occurring is to keep failure counters for each user and to lock the account when its failure countrer reaches a predefined limit. Notice that a legitimate user may fail (sometimes even several times in sequence) in entering his password so, two important points should always be observed. First, failure counters record the number of consecutive authentication failures and they are reset after each successive authentication. Secondly, the maximum number of allowed consecutive failures should be set sufficiantly high.
The version 1.3 offers two ways for controlling authentication probes: using external programs and using special SQL queries.
To control authentication probes using external programs, use the
combination of Exec-Program-Wait
and
Auth-Failure-Trigger
. The program specified by
Auth-Failure-Trigger
is executed each time an authentication
attempt failed. When both attributes are used together, the program
invoked by Auth-Failure-Trigger
can update the failure
counter, and the one invoked by Exec-Program-Wait
can compare
the counter value with the predefined limit and reject authentication
when both values become equal. Such approach is most useful in
conjunction with BEGIN
profile.
Let's suppose the program `/sbin/check_failure' accepts a user name and returns 1 if the failure counter for this user has reached maximum allowed value. Otherwise it returns 0 and clears the counter. Another program, `/sbin/count_failure' increases failure counter value for the given user name. Assuming our basic authentication type is `PAM', the `raddb/users' file will look as follows:
BEGIN NULL Exec-Program-Wait = "/sbin/check_failure %C{User-Name}", Auth-Failure-Trigger = "/sbin/count_failure %C{User-Name}", Fall-Through = Yes DEFAULT Auth-Type = PAM Service-Type = Framed-User, Framed-Protocol = PPP [... Other profiles ...] |
The BEGIN
profile will be executed before any other profile.
It will add to the RHS Exec-Program-Wait
and
Auth-Failure-Trigger
attributes and then radiusd
will
proceed to finding a matching profile (due to Fall-Through
attribute). When such profile is found, the user will be authenticated
according to the method set up by the profile's Auth-Type
attribute. If authentication fails, `/sbin/count_failure'
will be called and the user name passed to it as the argument. Otherwise,
`/sbin/check_failure' will be invoked.
To complete the example, here are working versions of both programs.
Failure counters for each user name are kept in separate file in
`/var/log/radius/fails' directory. Both programs are written
in bash
.
#! /bin/bash test $# -eq 1 || exit 1 MAXFAIL=8 REGDIR=/var/log/radius/fails if [ -r "$REGDIR/$1" ]; then read COUNT < "$REGDIR/$1" COUNT=$((COUNT+1)) else COUNT=1 fi echo $COUNT > "$REGDIR/$1" # End of /sbin/count_failure |
#! /bin/bash test $# -eq 1 || exit 1 MAXFAIL=8 REGDIR=/var/log/radius/fails if [ -r "$REGDIR/$1" ]; then read COUNT < "$REGDIR/$1" if [ $COUNT -ge $MAXFAIL ]; then echo "Reply-Message=\"Too many login failures. Your account is locked\"" exit 1 else rm "$REGDIR/$1" fi fi exit 0 # End of check_failure |
Another way of controlling authentication probes is by using
SQL database to store failure counters. Two queries are
provided for this purpose in `raddb/sqlserver' file:
auth_success_query
is executed upon each successful
authentication, and auth_failure_query
is executed upon
each authentication failure. Both queries are not expected to return
any values. One obvious purpose of auth_failure_query
would be to
update failure counters and that of auth_success_query
would be
to clear them. The auth_query
or group_query
should then
be modified to take into account the number of authentication
failures.
The default SQL configuration GNU Radius is shipped with provides a working example of using these queries. Let's consider this example.
First, we create a special table for keeping authentication failure counters for each user:
CREATE TABLE authfail ( # User name this entry refers to user_name varchar(32) binary default '' not null, # Number of successive authentication failures for this user count int, # Timestamp when this entry was last updated time datetime DEFAULT '1970-01-01 00:00:00' NOT NULL, # Create a unique index on user_name UNIQUE uname (user_name) ); |
The query auth_fail_query
will increment the value of
count
column for the user in question:
auth_failure_query UPDATE authfail \ SET count=count+1,time=now() \ WHERE user_name='%C{User-Name}' |
The query auth_success_query
will clear count
:
auth_success_query UPDATE authfail \ SET count=0,time=now() \ WHERE user_name='%C{User-Name}' |
Now, the question is: how to use this counter in authentication? The answer is quite simple. First, let's create a special group for all the users whose authentication failure counter has reached its maximum value. Let this group be called `*LOCKED_ACCOUNT*'. We'll add the following entry to `raddb/users':
DEFAULT Group = "*LOCKED_ACCOUNT*", Auth-Type = Reject Reply-Message = "Your account is currently locked.\n\ Please, contact your system administrator\n" |
which will reject all such users with an appropriate reply message.
The only thing left now is to rewrite group_query
so that it
returns `*LOCKED_ACCOUNT*' when authfail.count
reaches its
maximum value. Let's say this maximum value is 8. Then the following
query will do the job:
group_query SELECT user_group FROM groups \ WHERE user_name='%u' \ UNION \ SELECT CASE WHEN (SELECT count > 8 FROM authfail \ WHERE user_name='%u') THEN '*LOCKED_ACCOUNT*' END |
The default configuration comes with these queries commented out. It is up to you to uncomment them if you wish to use SQL-based control over authentication failures.
Notice the following important points when using this approach:
UNION
. Earlier
versions of MySQL
lacked this support, so if you run
MySQL
make sure you run a reasonably new version (at least
4.0.18).
auth_failure_query
and auth_success_query
assume the database already contains an entry for each user. So,
when adding a new user to the database, make sure to insert
an appropriate record into authfails
table, e.g.
INSERT INTO authfail VALUES('new-user',0,now()); |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
By default GNU Radius supports three types of accounting. Any additional accounting methods can be defined using extension mechanisms.
The accounting methods are applied to a request in a following sequence:
Any method can be enabled or disabled. Thus, you can even disable them all, thereby disabling accounting altogether.
Notice, that the multiple login checking scheme relies on
accounting being enabled. By default it uses system accounting, but
can also be configured to use SQL accounting. So, if you
disable system accounting and still wish to use reliable multiple login
checking, make sure you configure radiusd
to use SQL
for this purpose. See section 7.9 Multiple Login Checking, for the detailed information
about the subject.
If any accounting type in this sequence fails, the accounting is deemed to fail and all subsequent methods are not invoked.
8.1 System Accounting UNIX style utmp/wtmp accounting. 8.2 Detailed Request Accounting Detailed requests. 8.3 SQL Accounting Accounting to SQL server. 8.4 Defining Custom Accounting Types
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Radius keeps files `radutmp' and `radwtmp' in its logging
directory and stores the accounting data there. The utilities
radwho
and radlast
can be used to list information
about users' sessions.
<FIXME> Should they work if other mlc method is used? </>
This accounting method is enabled by default. To disable it, use
system no
statement in `raddb/config'. See section 5.1.4 acct
statement, for more
information. Please notice that disabling this authentication method will
disable multiple login checking as well. Refer to 7.9 Multiple Login Checking, for the detailed discussion of this.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Radius stores the detailed information about accounting packets it receives in files `radacct/nasname/detail' (see section 2. Naming Conventions), where nasname is replaced with the short name of the NAS from the `raddb/naslist' file (see section 5.4 NAS List -- `raddb/naslist').
By default, this accounting type is always enabled, provided that
`radacct' directory exists and is writable
(see section 2. Naming Conventions). To turn the detailed accounting off,
use the detail
statement in the `config' file. For more information
about it, see 5.1.4 acct
statement.
The accounting detail files consist of a record for each accounting request. A record includes the timestamp and detailed dump of attributes from the packet, e.g.:
Fri Dec 15 18:00:24 2000 Acct-Session-Id = "2193976896017" User-Name = "e2" Acct-Status-Type = Start Acct-Authentic = RADIUS Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = 11.10.10.125 Calling-Station-Id = "+15678023561" NAS-IP-Address = 11.10.10.11 NAS-Port-Id = 8 Acct-Delay-Time = 0 Timestamp = 976896024 Request-Authenticator = Unverified Fri Dec 15 18:32:09 2000 Acct-Session-Id = "2193976896017" User-Name = "e2" Acct-Status-Type = Stop Acct-Authentic = RADIUS Acct-Output-Octets = 5382 Acct-Input-Octets = 7761 Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = 11.10.10.125 Acct-Session-Time = 1905 NAS-IP-Address = 11.10.10.11 NAS-Port-Id = 8 Acct-Delay-Time = 0 Timestamp = 976897929 Request-Authenticator = Unverified |
Notice that radiusd
always adds two pseudo-attributes to
detailed listings. Attribute Timestamp
shows the UNIX timestamp
when radiusd
has received the request. Attribute
Request-Authenticator
shows the result of checking the request
authenticator. Its possible values are:
radiusd
do not agree on the value of the shared secret.
Notice also that the so-called internal attributes by default are not
logged in the detail file. Internal attributes are those whose decimal
value is greater than 255. Such attributes are used internally by
radius and cannot be transferred via RADIUS protocol. Examples of
such attributes are Fall-Through
, Hint
and
Huntgroup-Name
. See section 14.3 Radius Internal Attributes, for detailed
listing of all internal attributes. The special attribute flag
l
(lower-case ell) may be used to force logging of such
attributes (see section 5.2.4 ATTRIBUTE statement).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The SQL accounting method is enabled when Radius is configured with `--enable-sql' option and the `sqlserver' file in its configuration directory is properly set up (see section 5.11 SQL Configuration -- `raddb/sqlserver').
This version of GNU Radius (1.3) supports MySQL and PostgreSQL servers. It also supports ODBC, which can be used to build interfaces to another database management systems.
With this accounting method enabled, radiusd
will store the
information about accounting requests in the configured SQL database.
The accounting method is fully configurable: the Radius administrator
defines both the types of requests to be accounted and the information
to be stored into the database (see section 5.11 SQL Configuration -- `raddb/sqlserver').
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If the built-in accounting methods do not meet your requirements, you can implement your own. There are two ways of doing so:
To use a Guile procedure for accounting, the name of the procedure
must be specified as a value to the Scheme-Acct-Procedure
attribute
in the RHS list of a `hints' entry, e.g.:
DEFAULT NULL Scheme-Acct-Procedure = "my-acct" |
For a detailed description of Scheme accounting procedures, see section 11.3.3 Accounting with Scheme.
Another way of implementing your own accounting method is using an external program. This is less effective than the methods described above, but may be necessary sometimes. To invoke the program, use the following statement in the LHS of the `hints' entry:
Acct-Ext-Program = "progname args" |
The progname must be the full path to the program, and args any arguments it needs. The usual substitutions may be used in args to pass any request attributes to the program (see section 5.14 Macro Substitution).
For a detailed description of Acct-Ext-Program
,
see section 14.3.1 Acct-Ext-Program
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GNU Radius reports every event worth mentioning. The events are segregated by their severity level. Radius discerns the following levels (in order of increasing severity):
Debug
Auth
level auth; |
category auth
statement of the `config' file.
Proxy
Info
Notice
Warning
Error
CRIT
By default, all messages in all levels are output to the file
`radlog/radius.log'. In addition, messages in level
CRIT
are also duplicated to the system console. These defaults
can be overridden using logging
statement in the
`raddb/config' file.
(See section logging statement, for the description of logging
statement syntax; see section 2. Naming Conventions for information about the
locations of different Radius configuration files.)
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
10.1 Rule Tracing Tracing rules. 10.2 Debugging Enabling full debugging information. 10.3 Test Mode Running radius in test mode.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you have more than one entry in your `users' file it is not always obvious which of the entries were used for authentication. The authentication data flow becomes even harder to understand if there are some complex rules in the `hints' and `huntgroups' files.
The rule tracing mode is intended to help you find out the exact
order of the rules that each request matched during processing.
The mode is toggled by trace-rules
statement in auth
or acct
block of your `config' file. When rule tracing
mode is on for a given type of requests, radiusd
will
display the data flow diagram for each processed request of this
type. The diagram is output on info
logging category,
it represents the list of rules in reverse chronological order.
Each rule is represented by its location in the form
filename:line. To make the output more compact, if
several rules appear in the same configuration file, their locations
are listed as a comma-separated list of numbers after the file name.
Furthermore, if the configuration files have the same path prefix,
then only the first file name appears with the full prefix.
Here is an example of trace rule diagram:
Oct 31 11:37:17 [28322]: Auth.info: (Access-Request foo 170 bar): rule trace: /etc/raddb/users:157,22,3; huntgroups:72; hints:34 |
This diagram means, that the authentication request from server `foo' for user `bar' with ID 170 matched the following rules
File name | Line number |
`/etc/raddb/hints' | 34 |
`/etc/raddb/huntgroups' | 72 |
`/etc/raddb/users' | 3 |
`/etc/raddb/users' | 22 |
`/etc/raddb/users' | 157 |
As a practical example, let's suppose you have the following setup. There are three classes of users:
In addition, users from the first two classes are accounted using
custom Scheme procedure staff-acct
.
The configuration files for this setup are showed below:
Contents of `hints':
DEFAULT Group = "root" Scheme-Acct-Procedure = "staff-acct", Hint = "admin" DEFAULT Group = "staff" Scheme-Acct-Procedure = "staff-acct", Hint = "staff" |
Contents of file `users':
DEFAULT Auth-Type = SQL, Simultaneous-Use = 1 Service-Type = Framed-User, Framed-Protocol = PPP DEFAULT Hint = "admin", Auth-Type = System Service-Type = Login-User, Login-IP-Host = 192.168.0.1, Login-Service = Rlogin DEFAULT Hint = "staff", Auth-Type = System, Simultaneous-Use = 1 Service-Type = Login-User, Login-IP-Host = 192.168.0.2, Login-Service = Telnet |
Now, let's suppose that user `svp' is in the group
`staff' and is trying to log in. However, he fails to do so and
in radiusd
logs you see:
Nov 06 21:25:24: Auth.notice: (Access-Request local 61 svp): Login incorrect [svp] |
Why? To answer this question, you add to auth
block of your
`config' the statement
trace-rules yes; |
and ask user `svp' to retry his attempt. Now you see in your logs:
Nov 06 21:31:24: Auth.notice: (Access-Request local 13 svp): Login incorrect [svp] Nov 06 21:31:24: Auth.info: (Access-Request local 13 svp): rule trace: /etc/raddb/users:1, hints: 5 |
This means that the request for `svp' has first matched rule on the line 1 of file `hints', then the rule on line 1 of file `users'. Now you see the error: the entries in `users' appear in wrong order! After fixing it your `users' looks like:
DEFAULT Hint = "admin", Auth-Type = System Service-Type = Login-User, Login-IP-Host = 192.168.0.1, Login-Service = Rlogin DEFAULT Hint = "staff", Auth-Type = System, Simultaneous-Use = 1 Service-Type = Login-User, Login-IP-Host = 192.168.0.2, Login-Service = Telnet DEFAULT Auth-Type = SQL, Simultaneous-Use = 1 Service-Type = Framed-User, Framed-Protocol = PPP |
Now, you ask `svp' to log in again, and see:
Nov 06 21:35:14: Auth.notice: (Access-Request local 42 svp): Login OK [svp] Nov 06 21:35:14: Auth.info: (Access-Request local 42 svp): rule trace: /etc/raddb/users:7, hints: 5 |
Let's also suppose that user `plog' is not listed in groups "root" and "staff", so he is supposed to authenticate using SQL. When he logs in, you see in your logs:
Nov 06 21:39:05: Auth.notice: (Access-Request local 122 plog): Login OK [svp] Nov 06 21:39:05: Auth.info: (Access-Request local 122 plog): rule trace: /etc/raddb/users:14 |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GNU Radius provides extensive debugging features. These are enabled
either by the `--debug' (`-x') command line option to
radiusd
(see section 4. How to Start the Daemon.), or by the level
statement in the debug category (see section logging statement).
Both cases require as an argument a valid debug specification.
A debug specification sets the module for which the debugging should be enabled and the debugging level. The higher the level is, the more detailed information is provided. The module name and level are separated by an equal sign. If the level is omitted, the highest possible level (100) is assumed. The module name may be abbreviated to the first N characters, in which case the first matching module is selected. Several such specifications can be specified, in which case they should be separated by commas. For example, the following is a valid debug specification:
proxy.c=10,files.c,config.y=1 |
It sets debug level 10 for module proxy.c
, 100 for
files.c
, and 1 for config.y
.
The modules and debugging levels are subject to change from release to release.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Test mode is used to test various aspects of radius configuration, without starting the daemon. To enter test mode, run
radiusd -mt |
You will see usual radiusd
diagnostics and the following two lines:
** TEST SHELL ** (radiusd) _ |
The string `** TEST SHELL **' indicates that radiusd
has entered test mode, the string `(radiusd)' is the shell
prompt, indicating that radiusd
is waiting for your
commands.
The syntax of test shell command resembles that of Bourne shell: each command consists of a list of words separated by any amount of whitespace. Each word is either a sequence of allowed word characters (i.e. alphabetical characters, decimal digits, dashes and underscores), or any sequence of characters enclosed in a pair of double quotes. The very first word is a command verb, the rest of words are arguments to this command verb. A command verb may be used in its full form, in its abbreviated form (i.e. you may type only several first characters of the verb, the only condition being that they do not coincide with another command verb), or in it's short form.
The first command you should know is help
(or, in its short
form, h
). This command takes no arguments and displays
the short summary of all the available commands. Here is an example
of its output:
(radiusd) help h help Print this help screen q query-nas NAS LOGIN SID PORT [IP] Query the given NAS g guile Enter Guile rs rewrite-stack [NUMBER] Print or set the Rewrite stack size r run-rewrite FUNCTION(args..) Run given Rewrite function s source FILE Source the given Rewrite file t timespan TIMESPAN [DOW [HH [MM]]] Check the timespan interval d debug LEVEL Set debugging level rd request-define [PAIR [,PAIR]] Define a request rp request-print Print the request quit quit Quit the shell |
Each line of the output consists of three fields. The first field shows the short command form. The second one lists its full form and its arguments, optional arguments being enclosed in square brackets. The third field contains short textual description of the command.
The command displays the following result codes:
If the function being tested operates on request contents
(see section 11.2.4 Rewriting Incoming Requests), you may supply the request
using request-define
command (see below).
radiusd
timespan specification (see section 14.3.14 Login-Time
). Rest of
arguments define the time. If any of these is omitted, the
corresponding value from current local time is used.
The following set of samples illustrates this command:
(radiusd) timespan Wk0900-1800 ctime: Tue Dec 2 16:08:47 2003 inside Wk0900-1800: 6720 seconds left (radiusd) timespan Wk0900-1800 0 ctime: Sun Nov 30 16:09:03 2003 OUTSIDE Wk0900-1800: 60660 seconds to wait (radiusd) timespan Wk0900-1800 0 12 30 ctime: Sun Nov 30 12:30:13 2003 OUTSIDE Wk0900-1800: 73800 seconds to wait (radiusd) timespan Wk0900-1800 1 05 00 ctime: Mon Dec 1 05:00:33 2003 OUTSIDE Wk0900-1800: 14400 seconds to wait (radiusd) timespan Wk0900-1800 1 09 10 ctime: Wed Jan 7 22:09:41 2004 OUTSIDE Wk0900-1800: 39060 seconds to wait (radiusd) timespan Wk0900-1800 1 09 10 ctime: Mon Dec 1 09:10:44 2003 inside Wk0900-1800: 31800 seconds left (radiusd) |
(radiusd) request-define Enter the pair list. End with end of file [radiusd] User-Name = smith, User-Password = guessme [radiusd] NAS-IP-Address = 10.10.10.1 [radiusd] NAS-Port-Id = 34 [radiusd] (radiusd) |
Notice that any number of A/V pairs may be specified in a line. To finish entering the request, either type an EOF character or enter an empty line.
request-define
.
(radiusd) request-print User-Name = (STRING) smith User-Password = (STRING) guessme NAS-IP-Address = (IPADDR) 10.10.10.1 NAS-Port-Id = (INTEGER) 34 (radiusd) |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The use of extension language allows extending the functionality of GNU Radius without having to modify its source code. The two extension languages supported are Rewrite and Scheme. Use of Rewrite is always enabled. Use of Scheme requires Guile version 1.4 or higher.
11.1 Filters Using external filter programs. 11.2 Rewrite The built-in extension language. 11.3 Guile Using Scheme.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The simplest way to extend the functionality of Radius is to use filters. A filter is an external program that communicates with Radius via its standard input and output channels.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Suppose we wish to implement an authentication method based on the user name and the user's calling station ID. We have a database of user names with valid IDs, and the new method should authenticate a user only if the combination {user_name, id} is found in this database.
We write a filter program that reads its standard input line by line.
Each input line must consist of exactly two words: the user name
and the calling station ID. For each input line, the
program prints 0
if the {user_name, id} is found in the
database and 1
otherwise. Let's suppose for the sake of example
that the database is a plaintext file and the filter is written in
a shell programming language. Then it will look like
#! /bin/sh DB=/var/db/userlist while read NAME CLID do if grep "$1:$2" $DB; then echo "0" else echo "1" fi done |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Here is how this filter is declared in the `raddb/config' file:
filters { filter check_clid { exec-path "/usr/libexec/myfilter"; error-log "myfilter.log"; auth { input-format "%C{User-Name} %C{Calling-Station-Id}"; wait-reply yes; }; }; }; |
Let's analyze this declaration line by line:
filters {
This keyword opens the filters declaration block. The block may contain several declarations.
filter check_clid {
This line starts the declaration of this particular filter and names it `check_clid'.
exec-path "/usr/libexec/myfilter";
This line tells radiusd
where to find the executable image of
this filter.
error-log "myfilter.log";
The diagnostic output from this filter must be redirected to the file `myfilter.log' in the current logging directory
auth {
This filter will process authentication requests.
input-format "%C{User-Name} %C{Calling-Station-Id}";
Define the input line format for this filter. The %C{} expressions will be replaced by the values of the corresponding attributes from the incoming request (see section 5.14 Macro Substitution).
wait-reply yes;
radiusd
will wait for the reply from this filter to decide whether to
authenticate the user.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To invoke this filter from the user profile, specify its name prefixed
with `|' in the value of Exec-Program-Wait
attribute,
like this:
DEFAULT Auth-Type = System, Simultaneous-Use = 1 Exec-Program-Wait = "|check_clid" |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Apart from simply deciding whether to authenticate a user, the filter can also modify the reply pairs.
#! /bin/sh DB=/var/db/userlist while read NAME CLID do if grep "$1:$2" $DB; then echo "0 Service-Type = Login, Session-Timeout = 1200" else echo "1 Reply-Message = \"You are not authorized to log in\"" fi done |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Let's suppose we further modify our filter to also handle accounting requests. To discern between the authentication and accounting requests we'll prefix each authentication request with the word `auth' and each accounting request with the word `acct'. Furthermore, the input line for accounting requests will contain a timestamp.
Now, our filter program will look as follows:
#! /bin/sh AUTH_DB=/var/db/userlist ACCT_DB=/var/db/acct.db while read CODE NAME CLID DATE do case CODE auth) if grep "$1:$2" $DB; then echo "0 Service-Type = Login, \ Session-Timeout = 1200" else echo "1 Reply-Message = \ \"You are not authorized to log in\"" fi acct) echo "$CODE $NAME $CLID $DATE" >> $ACCT_DB done |
Its declaration in the `raddb/config' will also change:
filter check_clid { exec-path "/usr/libexec/myfilter"; error-log "myfilter.log"; auth { input-format "auth %C{User-Name} %C{Calling-Station-Id}"; wait-reply yes; }; acct { input-format "acct %C{User-Name} %C{Calling-Station-Id} %D"; wait-reply no; }; }; |
(The input-format
lines are split for readability. Each of them
is actually one line).
Notice wait-reply no
in the acct
statement. It
tells radiusd
that it shouldn't wait for the response on
accounting requests from the filter.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To invoke the accounting filter, specify its name prefixed with a
vertical bar character as a value of Acct-Ext-Program
in our
`raddb/hints' file. For example:
DEFAULT NULL Acct-Ext-Program = "|check_clid: |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Rewrite is the GNU Radius extension language. Its name reflects the fact that it was originally designed to rewrite the broken request packets so they could be processed as usual (see section 11.2.4 Rewriting Incoming Requests). Beside this basic use, however, Rewrite functions are used to control various aspects of GNU Radius functionality, such as verifying the activity of user sessions, controlling the amount of information displayed in log messages, etc (see section 11.2.3 Interaction with Radius).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The syntax of Rewrite resembles that of C. Rewrite has two basic data types:
integer and string. It does not have global variables; all variables are
automatic. The only exceptions are the A/V pairs from the incoming request,
which are accessible to Rewrite functions via the special notation
%[attr]
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
As an example, let's consider the following Rewrite function:
string foo(integer i) { string rc; if (i % 2) rc = "odd"; else rc = "even"; return "the number is " + rc; } |
The function takes an integer argument and returns the string
`the number is odd' or `the number is even', depending on the
value of i
. This illustrates the fact that in Rewrite the
addition operator is defined on the string type. The result of
such operation is the concatenation of operands.
Another example is a function that adds a prefix to the User-Name
attribute:
integer px_add() { %[User-Name] = "pfx-" + %[User-Name]; return 0; } |
This function manipulates the contents of the incoming request; its return value has no special meaning.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A Rewrite function can be invoked in several ways, depending on its purpose. There are three major kinds of Rewrite functions:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The need for rewriting the incoming requests arises from the fact that
some NASes are very particular about the information they send with
the requests. There are cases when the information they send
is hardly usable or even completely unusable. For example, a
Cisco AS5300 terminal server used as a voice-over IP router packs
a lot of information into its Acct-Session-Id
attribute. Though
the information stored there is otherwise relevant, it makes proper
accounting impossible, since the Acct-Session-Id
attributes
in the start and stop packets of the same session become different, and
thus Radius cannot determine the session start to which the given
session stop request corresponds (see section 14.2.7 Acct-Session-Id
).
In order to cope with such NASes, GNU Radius is able to invoke a Rewrite function upon arrival of the packet and before processing it further. This function can transform the packet so that it obtains the form prescribed by RFCs and its further processing becomes possible.
For example, in the case of the AS5300 router, a corresponding Rewrite
function parses the Acct-Session-Id
attribute; breaks it
down into fields; stores them into proper attributes, creating
them if necessary; and finally replaces Acct-Session-Id
with
its real value, which is the same for the start and stop records
corresponding to a single session. Thus all the information that
came with the packet is preserved, but the packet itself is made
usable for proper accounting.
A special attribute, Rewrite-Function
, is used to trigger
invocation of a Rewrite function. Its value is a name of the
function to be invoked.
When used in a `naslist' profile, the attribute causes the function
to be invoked when the incoming request matches the huntgroup
(see section 3.4.4 Huntgroups). For example, to have a function fixup
invoked for each packet from the NAS 10.10.10.11
, the
following huntgroup rule may be used:
DEFAULT NAS-IP-Address = 11.10.10.11 Rewrite-Function = "fixup" |
The Rewrite-Function
attribute may also be used in a `hints'
rule. In this case, it will invoke the function if the request matches
the rule (see section 3.4.3 Hints). For example, this `hints' rule will
cause the function to be invoked for each request containing the user name
starting with `P':
DEFAULT Prefix = "P" Rewrite-Function = "fixup" |
Note that in both cases the attribute can be used either in LHS or in RHS pairs of a rule.
The packet rewrite function must be declared as having no arguments and returning an integer value:
integer fixup() { } |
The actual return value from such a function is ignored, the integer return type is just a matter of convention.
The following subsection present some examples of packet rewrite functions.
11.2.4.1 Examples of Various Rewrite Functions
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The examples found in this chapter are working functions that can be used with various existing NAS types. They are taken from the `rewrite' file contained in distribution of GNU Radius.
Some MAX Ascend terminal servers pack additional information
into the NAS-Port-Id
attribute. The port number is constructed as
XYYZZ, where X = 1 for digital, X = 2 for analog,
YY is the line number
(1 for first PRI/T1/E1, 2 for second, and so on), and ZZ is the
channel number
(on the PRI or channelized T1/E1).
The following rewrite functions are intended to compute the integer
port number in the range (1 .. portcnt), where portcnt
represents the real number of physical ports available on the NAS.
Such a port number can be used, for example, to create a dynamic pool
of IP addresses (see section 14.1.8 Framed-IP-Address
).
/* * decode MAX port number * input: P -- The value of NAS-Port-Id attribute * portcnt -- number of physical ports on the NAS */ integer max_decode_port(integer P, integer portcnt) { if (P > 9999) { integer s, l, c; s = P / 10000; l = (P - (10000 * s))/100; c = P - ((10000 * s) + (100 * l)); return (c-1) + (l-1) * portcnt; } return P; } /* * Interface function for MAX terminal server with 23 ports. * Note that it saves the received NAS-Port-Id attribute in * the Orig-NAS-Port-Id attribute. The latter must be * defined somewhere in the dictionary */ integer max_fixup() { %[Orig-NAS-Port-Id] = %[NAS-Port-Id]; # Preserve original data %[NAS-Port-Id] = max_decode_port(%[NAS-Port-Id], 23); return 0; } |
Cisco VOIP IOS encodes a lot of other information into its
Acct-Session-Id
. The pieces of information are separated by
`/' characters. The part of Acct-Session-Id
up to the first
`/' character is the actual session ID.
On the other hand, its accounting packets lack NAS-Port-Id
,
though they may contain the vendor-specific pair with code 2
(vendor PEC 9), which is a string in the form `ISDN 9:D:999'
(`9' represents any decimal digit). The number after the last
`:' character can be used as a port number.
The following code parses Acct-Session-Id
attribute and stores
the information it contains in various other attributes, generates a
normal Acct-Session-Id
, and attempts to generate a
NAS-Port-Id
attribute.
/* * The port rewriting function for Cisco AS5300 used for * VoIP. This function is used to generate NAS-Port-Id pair * on the basis of vendor-specific pair 2. If the latter is * in the form "ISDN 9:D:999" (where each 9 represents a * decimal digit), then the function returns the number * after the last colon. This is used as a port number. */ integer cisco_pid(string A) { if (A =~ ".*\([0-9][0-9]*\): [A-Z0-9][A-Z0-9]*:\([0-9][0-9]*\)") { return (integer)\2; } return -1; } /* * This function parses the packed session id. * The actual sid is the number before the first slash * character. Other possibly relevant fields are also * parsed out and saved in the Voip-* A/V pairs. The latter * should be defined somewhere in the dictionary. * Note that the regular expression in this example * spans several lines for readability. It should be on one * line in real file. */ string cisco_sid(string S) { if (S =~ "\(.[^/]*\)/[^/]*/[^/]*/\([^/]*\)/\([^/]*\)/ \([^/]*\)/\([^/]*\)/\([^/]*\)/\([^/]*\) /\([^/]*\).*") { %[Voip-Connection-ID] = \2; %[Voip-Call-Leg-Type] = \3; %[Voip-Connection-Type] = \4; %[Voip-Connect-Time] = \5; %[Voip-Disconnect-Time] = \6; %[Voip-Disconnect-Cause] = \7; %[Voip-Remote-IP] = \8; return \1; } return S; } /* * Normalize cisco AS5300 packets */ integer cisco_fixup() { integer pid; if ((pid = cisco_pid(%[Cisco-PRI-Circuit])) != -1) { if (*%[NAS-Port-Id]) %[Orig-NAS-Port-Id] = %[NAS-Port-Id]; %[NAS-Port-Id] = pid; } if (*%[Acct-Session-Id]) { %[Orig-Acct-Session-Id] = %[Acct-Session-Id]; %[Acct-Session-Id] = cisco_sid(%[Acct-Session-Id]); } return 0; } |
Users coming from Windows NT machines often authenticate themselves as
`NT_DOMAIN\username'. The following function selects the
user-name part and stores it in the User-Name
attribute:
integer login_nt(string uname) { integer i; if ((i = index(uname, '\\')) != -1) return substr(uname, i+1, -1); return uname; } integer nt_rewrite() { %[Orig-User-Name] = %[User-Name]; %[User-Name] = login_nt(%[User-Name]); return 0; } |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A login verification function is invoked to process the output from the
NAS. This process is described in 7.9 Multiple Login Checking.
The function to be invoked for given NAS is defined by
a function
flag in the `raddb/nastypes' or `raddb/naslist'
file (see section 5.5 NAS Types -- `raddb/nastypes'). It must be defined as follows:
Its arguments are:
finger
, this is the string
of output received from the NAS with trailing newline stripped off. If
the query method is snmp
, it is the received variable value
converted to its string representation.
The function should return non-0 if its arguments match the user's session, and 0 otherwise.
11.2.5.1 Examples of Login Verification Functions
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
As an example, let's consider the function for analyzing a
line of output from a standard UNIX finger
service. In each line
of finger
output the first field contains the user name; the
third field, the
The function must return 1 if the three fields match the input
user name and port and session IDs:
integer check_unix(string str, string name, integer pid, string sid) { return field(str, 1) == name && field(str, 3) == pid && field(str, 7) == sid; } |
The next example is a function to analyze a line of output from an SNMP query returning a user name. This function must return 1 if the entire input line matches the user name:
integer check_username(string str, string name, integer pid, string sid) { return str == name; } |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These are the functions used to create Radius reply attributes. An attribute creation function can take any number of arguments. The type of its return is determined by the type of Radius attribute the value will be assigned to. To invoke the function, write its name in the A/V pair of the RHS in the `raddb/users' file, e.g.:
DEFAULT Auth-Type = SQL Service-Type = Framed-User, Framed-IP-Address = "=get_ip_addr(10.10.10.1)" |
The function get_ip_addr
will be invoked after successful
authentication and it will be passed the IP 10.10.10.1
as its
argument. An example of a useful function that can be invoked this
way is
integer get_ip_address(integer base) { return base + %[NAS-Port-Id] - %[NAS-Port-Id]/16; } |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A logging hook functions should be declared as follows:
request_code_string
function (see section 11.2.8.7 Rewrite Built-in Functions).
Notice that the hook function shall not produce any side effects, in particular it shall not modify the incoming request in any way.
Following is an example prefix hook function that formats the incoming request data:
string compat_log_prefix(integer reqtype, string nas, integer id) { string result; return "(" + request_code_string(reqtype) + " " + nas + " " + (string)id + " " + %[User-Name] + ")"; } |
Here is a sample log produced by radiusd
before and after
enabling this function:
Auth.notice: Login OK [jsmith] ... Auth.notice: (AUTHREQ nas-2 251 jsmith): Login OK [jsmith] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There are only two data types: integer
and string
,
the two being coercible to each other in the sense that a string
can be coerced to an integer if it contains a valid ASCII representation
of a decimal, octal, or hex number, and an integer can always be coerced
to a string, the result of such coercion being the ASCII string
that is the
decimal representation of the number.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A symbol is a lexical token. The following symbols are recognized:
If the character following the backslash is not one of those specified, the backslash is ignored.
Rewrite-Function
attribute. It is kept as an associative array,
whose entries can be accessed using the following syntax:
`%[' attribute-name `]' `%[' attribute-name `]' `(' n `)' |
The first form returns the value of the attribute attribute-name. Here attribute-name should be a valid Radius dictionary name (see section 5.2 Dictionary of Attributes -- `raddb/dictionary').
The second form returns the value of the nth attribute of type attribute-name. The index n is counted from zero, so
%[attribute-name](0) |
is equivalent to
%[attribute-name] |
`\number' |
refers to the contents of parenthesized group number number obtained as a result of the last executed `=~' command. The regexp group reference has always string data type. For example:
string basename(string arg) { if (arg =~ ".*/\(.*\)\..*") return \1; else return arg; } |
This function strips from arg all leading components up to the
last slash character, and all trailing components after the last dot
character. It returns arg unaltered if it does not contain
slashes and dots. It is roughly analogous to the system basename
utility.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A valid identifier is a string of characters meeting the following requirements:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A Rewrite function is declared as follows:
type function-name (parameter-list) |
where type specifies the return type of the function, function-name declares the symbolic name of the function, and parameter-list declares the formal parameters to the function. It is a comma-separated list of declarations in the form
type parm-name |
type being the parameter type, and parm-name being its symbolic name. Both function-name and parm-name should be valid identifiers.
There are no global variables in Rewrite. All variables are local. The local variables are declared right after the opening curly brace (`{') and before any executable statements. The declaration syntax is
type ident_list ; |
Here ident_list is either a valid Rewrite identifier or a comma-separated list of such identifiers.
Note that, unlike in C, no assignments are allowed in variable declarations.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The Rewrite statements are: expressions, assignments, conditional statements, and return statements. A statement is terminated by a semicolon.
An expression is one of the following:
`(' type `)' ident |
The result of type coercion is as follows:
type | Variable type | Resulting conversion |
integer | integer | No conversion. This results in the same integer value. |
integer | string | If the string value of the variable is a valid ASCII representation of the integer number (either decimal, octal, or hex), it is converted to the integer; otherwise the result of the conversion is undefined. |
string | integer | The ASCII representation (in decimal) of the integer number. |
string | string | No conversion. This results in the same string value. |
ident = expression ; |
The variable ident is assigned the value of expression.
ident ( arg-list ) |
where ident is the identifier representing the function, and arg-list is a comma-separated list of expressions supplying actual arguments to the function. The number of the expressions must correspond exactly to the number of formal parameters in the function definition. The function that ident references can be either a compiled function or a built-in function.
The `delete' statement is used to delete an attribute or attributes from the incoming request. Its syntax is:
delete attribute-name; delete attribute-name(n); |
The first variant deletes all the attributes of the given type. The second variant deletes only the nth occurrence of the matching attribute.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Rewrite uses POSIX regular expressions (See section `Regular Expression Library' in Regular Expression Library, for the detailed description of these).
You control the exact type of regular expressions by the use of the
pragmatic comment regex
. Its syntax is as follows:
#pragma regex option-list |
Option-list is a whitespace-separated list of options. Each option is one of the following words prefixed with `+' or `-':
extended
icase
newline
A non-matching list (`[^...]') not containing a newline does not match a newline.
Match-beginning-of-line operator (`^') matches the empty string immediately after a newline.
Match-end-of-line operator (`$') matches the empty string immediately before a newline.
Prefixing an option with `+' means to enable the corresponding behavior. Prefixing it with `-' means to disable it. Thus, the following statement:
#pragma regex +extended +icase |
will enable extended POSIX regular expressions using case-insensitive comparison.
Using the following comment:
#pragma regex -extended |
will switch to the basic POSIX regular expressions.
The settings of a regex
pragmatic comment remain in force up to
the end of current source file, or to the next regex
comment,
whichever occurs first.
For compatibility with previous versions, GNU Radius uses the following defaults:
#pragma regex -extended -icase -newline |
i.e. all regular expressions are treated as basic POSIX, comparison is case-sensitive.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following built-in functions are provided:
length("string") => 6 |
index("/raddb/users", 47) => 0 index("/raddb/users", 45) => -1 |
rindex("/raddb/users", 47) => 6 |
substr("foo-bar-baz", 3, 5) => "-bar-" |
All character positions in strings are counted from 0.
field("GNU's not UNIX", 1) => "GNU's" field("GNU's not UNIX", 2) => "not" field("GNU's not UNIX", 3) => "UNIX" field("GNU's not UNIX", 4) => "" |
info
. Returns 0.
For debugging purposes.
inet_aton("127.0.0.1") => 2130706433 |
inet_ntoa(2130706433) => "127.0.0.1" |
gsub("s","S","strings") => "StringS" gsub("[0-9][0-9]*","N","28 or 29 days") => "N or N days" gsub("[()'\"]","/","\"a\" (quoted) 'string'") => "/a/ /quoted/ /string/" |
qprn("a string/value") => "a%20string%2Fvalue" |
quote_string("François contains non-!-printable chars") => "Fran\347ois contains non\tprintable chars" |
unquote_string("Fran\347ois") => "François" |
toupper("a-string") => "A-STRING" |
tolower("A-STRING") => "a-string" |
request_code_string(4) => "Accounting-Request" |
The native language support is provided via the functions described
below. These functions are interfaces to GNU gettext
library.
For the information about general concepts and principles of
Native Language Support, please refer to
section `gettext' in GNU gettext
utilities.
The default current textual domain is `radius'.
gettext
and ngettext
.
Returns the name of the previously used domain.
The second form of this function provides a traditional shortcut notation.
For a detailed description of the GNU gettext
interface,
refer to section `Interface to gettext' in GNU gettext
utilities.
ngettext
function is used to translate the messages that
have singular and plural forms. The msgid_singular parameter
must contain the singular form of the string to be converted. It is
also used as the key for the search in the catalog. The
msgid_plural
parameter is the plural form. The parameter
number is used to determine the plural form. If no message
catalog is found msgid_singular is returned if
number == 1
, otherwise msgid_plural.
For a detailed description of the GNU gettext
interface for the
plural translation,
refer to section `Additional functions for plural forms' in GNU gettext
utilities.
ngettext
, but searches translation in the given domain.
The following functions are used to read some internal fields of a RADIUS request.
NAS-IP-Address
attribute to the requests
lacking one, e.g.:
integer restore_nas_ip() { if (!*%[NAS-IP-Address]) %[NAS-IP-Address] = request_source_ip(); return 0; } |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The name Guile stands for GNU's Ubiquitous Intelligent Language for Extensions. It provides a Scheme interpreter conforming to the R4RS language specification. This section describes use of Guile as an extension language for GNU Radius. It assumes that the reader is sufficiently familiar with the Scheme language. For information about the language, refer to section `Top' in Revised(4) Report on the Algorithmic Language Scheme. For more information about Guile, see section `Overview' in The Guile Reference Manual.
Scheme procedures can be called for processing both authentication
and accounting requests. The invocation of a Scheme procedure for an
authentication request is triggered by the Scheme-Procedure
attribute; the invocation for an accounting request is triggered
by the Scheme-Acct-Procedure
attribute. The following sections
address these issues in more detail.
11.3.1 Data Representation 11.3.2 Authentication with Scheme 11.3.3 Accounting with Scheme 11.3.4 Radius-Specific Functions
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A/V pair lists are the main object Scheme functions operate upon. Scheme is extremely convenient for representation of such objects. A Radius A/V pair is represented by a Scheme pair; e.g.,
Session-Timeout = 10 |
is represented in Guile as
(cons "Session-Timeout" 10) |
The car
of the pair can contain either the attribute dictionary
name or the attribute number. Thus, the above pair may also be
written in Scheme as
(cons 27 10) |
(because Session-Timeout
corresponds to attribute number 27).
Lists of A/V pairs are represented by Scheme lists. For example, the Radius pair list
User-Name = "jsmith", User-Password = "guessme", NAS-IP-Address = 10.10.10.1, NAS-Port-Id = 10 |
is written in Scheme as
(list (cons "User-Name" "jsmith") (cons "User-Password" "guessme") (cons "NAS-IP-Address" "10.10.10.1") (cons "NAS-Port-Id" 10)) |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The Scheme procedure used for authentication must be declared as follows:
The function return value determines whether the authentication will
succeed. The function must return either a boolean value or a pair.
The return of #t
causes authentication to succeed. The return
of #f
causes it to fail.
For a function to add something to the reply A/V pairs, it should return a pair in the form
(cons return-code list) |
where return-code is a boolean value of the same meaning as described above. list is a list of A/V pairs to be added to the reply list. For example, the following function will always deny the authentication, returning an appropriate message to the user:
(define (decline-auth request-list check-list reply-list) (cons #f (list (cons "Reply-Message" "\r\nSorry, you are not allowed to log in\r\n")))) |
As a more constructive example, let's consider a function that allows the authentication only if a user name is found in its internal database:
(define staff-data (list (list "scheme" (cons (list (cons "NAS-IP-Address" "127.0.0.1")) (list (cons "Framed-MTU" "8096"))) (cons '() (list (cons "Framed-MTU" "256")))))) (define (auth req check reply) (let* ((username (assoc "User-Name" req)) (reqlist (assoc username req)) (reply-list '())) (if username (let ((user-data (assoc (cdr username) staff-data))) (rad-log L_INFO (format #f "~A" user-data)) (if user-data (call-with-current-continuation (lambda (xx) (for-each (lambda (pair) (cond ((avl-match? req (car pair)) (set! reply-list (avl-merge reply-list (cdr pair))) (xx #t)))) (cdr user-data)) #f))))) (cons #t reply-list))) |
To trigger the invocation of the Scheme authentication function, assign
its name to the Scheme-Procedure
attribute in the RHS of a
corresponding `raddb/users' profile. For example:
DEFAULT Auth-Type = SQL Scheme-Procedure = "auth" |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The Scheme accounting procedure must be declared as follows:
The function must return a boolean value. The accounting succeeds only
if it has returned #t
.
Here is an example of a Scheme accounting function. The function dumps the contents of the incoming request to a file:
(define radius-acct-file "/var/log/acct/radius") (define (acct req) (call-with-output-file radius-acct-file (lambda (port) (for-each (lambda (pair) (display (car pair) port) (display "=" port) (display (cdr pair) port) (newline port)) req) (newline port))) #t) |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
#t
if all pairs from list are present in target.
#f
if
no such name was found in the dictionary.
A dictionary entry is a list in the form
where the arguments are as follows:
#f
otherwise.
rad-log-open
.
Return value: return of the corresponding Rewrite call, translated to the Scheme data type.
(car arglist)
is interpreted as a name of the Rewrite
function to execute, and (cdr arglist)
as a list of
arguments to be passed to it.
Return value: return of the corresponding Rewrite call, translated to the Scheme data type.
openlog()
call.
syslog()
call.
closelog()
call.
list is:
NAS-Port-Id
attribute
Calling-Station-Id
attribute from the request
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Controlling who and when was logged in
12.1 radwho
Show who is logged in by radius now. 12.2 radlast
Show the history of logins by radius.
Maintenance commands
12.3 radzap
Modify the login records. 12.4 radgrep
Quickly find the login record. 12.5 radping
Ping the remote machine by the username. 12.6 radauth
Check if a user can be authenticated. 12.7 radctl
Radctl monitor. 12.8 builddbm
Create DBM version of the `raddb/users' file.
Guile interface
12.9 radscm
: A Guile Interface to Radius FunctionsA Guile interface to radius functions.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
radwho
Radwho
displays the list of users currently logged in by the
Radius server.
Default output information is made compatible with that of the standard
UNIX finger(1)
utility. For each user the following information is
displayed: login name, name, connection protocol, NAS port, login date,
NAS name, assigned IP or corresponding network name.
When used with `-l' option, the long output format is used. In this format the following information is output:
12.1.1 radwho
Command Line OptionsCommand line options. 12.1.2 radwho
Format Strings12.1.3 radwho
Predefined Formats
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
radwho
Command Line Options The following command line options can be used to modify the behavior of the program:
strftime(3)
format string. It defaults to %a %H:%M
, i.e. the abbreviated weekday
name according to the current locale, and the hour and the minutes as two-digit
decimal numbers.
radwho
is fed to some analyzing program, as it helps to keep
the same number of columns on each line of output.
fingerd
mode. In this mode radwho
emulates the
behavior of the fingerd(8)
utility. Use this option if starting
radwho
from the `/etc/inetd.conf' line like this (5):
finger stream tcp nowait nobody /usr/sbin/radwho radwho -fL |
This mode is also enabled by default if radwho
notices that its
name (argv[0]
) is `fingerd' or `in.fingerd'.
radwho
as a finger daemon.
RADWHO_FORMAT
. The format
is either a symbolic name of one of the predefined formats or a format
specification (see next subsection).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
radwho
Format Strings A format string controls the output of every record from `radutmp'. It contains two types of objects: ordinary characters, which are simply copied to the output, and format specifications, each of which causes output of a particular piece of information from the `radutmp' record.
Each format specification starts with an opening brace and ends with a closing brace. The first word after the brace is the name of the format specification. The rest of words are positional arguments followed by keyword arguments. Both are optional. The keyword arguments begin with a colon and must follow the positional arguments.
The full list of format specifications follows.
The following specifications output particular fields of a `radutmp' record. They all take two positional arguments: width and title.
The first argument, width sets the maximum output
length for this specification. If the number of characters actually output
is less than the width, they will be padded with whitespace either to
the left or to the right, depending on the presence of the :right
keyword argument. If the number of characters is greater than width, they
will be truncated to fit. If width is
not given, the exact data are output as is.
The second argument, title, gives the title of this column for the heading line. By default no title is output.
Every field specification accepts at least two keyword arguments.
The keyword :right
may be used to request alignment to the right
for the data. This keyword is ignored if width is not given.
The keyword :empty
followed by a string causes radwho
to output that string if the resulting value for this specification
would otherwise be empty.
The :nodomain
keyword suppresses the output of the domain part of
the name, i.e., the hostname is displayed only up to the first dot.
The :nodomain
keyword suppresses the output of the domain part of
the name, i.e. the hostname is displayed only up to the first dot.
Framed-Protocol
attribute.
If the symbolic value is found in the dictionary file, it will be
displayed. Otherwise, the numeric value will be displayed as is.
The :format
keyword introduces the strftime
format string
to be used when converting the date for printing. The default value is
%a %H:%M
.
Acct-Delay-Time
).
NAS-Port-Type
attribute.
If the symbolic value is found in the dictionary file, it will be
displayed. Otherwise, the numeric value will be displayed as is.
:nodomain
keyword may be used to suppress the output of the
domain part of the name, i.e. to display the hostname only up to the
first dot.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
radwho
Predefined Formats The predefined formats are:
(login 10 Login) (gecos 17 Name) \ (protocol 5 Proto) (nas-port 5 TTY) \ (time 9 When) (nas-address 9 From) \ (framed-address 16 Location) |
(login 32 Login) (session-id 32 SID) \ (protocol 5 Proto) (nas-port 5 Port) \ (time 27 Date) (nas-address 32 NAS) \ (clid 17 CLID) (duration 7 Duration) \ (framed-address 16 Location) (realm 16 Realm) |
User: (login)(newline)\ In real life: (gecos)(newline)\ Logged in: (time)(newline)\ NAS: (nas-address)(newline)\ Port: (nas-port)(newline)\ CLID: (clid)(newline)\ Protocol: (protocol)(newline)\ Session ID: (session-id)(newline)\ Uptime: (duration)(newline)\ Assigned IP: (framed-address)(newline)\ Realm: (realm)(newline)" |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
radlast
The radlast
utility lists sessions of specified users, NASes,
NAS ports, and hosts, in reverse time order. By default, each line of output
contains the login name, the NAS short name and port number from where the
session was conducted, the host IP or name, the start and stop
times for the session, and the duration of the session. If the session
is still continuing, radlast
will so indicate.
When the `-l' option is specified, radlast
produces long
output. It includes following fields:
12.2.1 radlast
Command Line OptionsCommand line options.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
radlast
Command Line Options
Use following command line options to control the behavior of the
radlast
utility:
radlast
will output at most this many
lines of information.
radlast -p S03
or radlast -p 3
.
last(1)
.
If multiple arguments are given, the logical OR operation between them is assumed, i.e., the information selected by each argument is printed. This, however, does not apply to the `-c' option. That option is always combined with the rest of command line by logical AND.
The pseudo-user `~reboot' logs in on every reboot of the network access server.
If radlast
is interrupted, it indicates to what date the search
had progressed.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
radzap
radzap
searches the Radius accounting database for matching login
records and closes them.
At least one of the options `-n', `-p', or the user name must be specified. If they are used in conjunction, they are taken as if joined by the logical AND operation.
radzap
operates in two modes: silent and confirm. The silent
mode is enabled by default. When run in this mode, radzap
deletes
every record that matches the search conditions given.
In confirm mode radzap
will ask for a confirmation
before zapping each matching record. Any line beginning with a `y'
is taken as a positive response; any other line is taken as a negative
response.
The confirm mode is toggled by the command line option `-c'.
radzap [options] [username] |
Options are:
This option is deprecated. It is currently retained for backward compatibility with previous versions.
radzap -p S02
, or in
its short form, e.g. radzap -p 2
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
radgrep
This utility allows one to quickly look up the user in the Radius
accounting database, using a regular expression match.
radgrep
scans the output of radwho
utility and
outputs only the lines that match given regular expressions.
radgrep
accepts two sets of options separated by `--'
(double hyphen). The first subset is passed as the command line to the
radwho
utility. The second one is passed to grep
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
radping
This utility is a shell program that determines the user's
framed IP and runs ping
on that address.
radping username radping -c calling-station-id |
The second way of invoking the program allows one to use the calling station ID to indicate the user.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
radauth
The radauth
utility sends the Radius server an Access-Request
packet and displays the result it gets. If the server responds with
Access-Accept
radauth
can also send an
Accounting-Request
thereby initiating user's session.
The utility is a radtest
program. See section 13.2.12 Sample Radtest Program, for the detailed discussion of its internals.
radauth [options] [command] user-name [password] |
Options are:
<FIXME> GNU long options are not yet supported </>
Valid commands are:
Access-Request
. This is the default.
Access-Request
. If successfull, send
Accounting-Request
with Acct-Status-Type = Start
.
Accounting-Request
with Acct-Status-Type = Start
.
Accounting-Request
with Acct-Status-Type = Stop
.
The program determines which Radius server to use, the authentication port number, and the shared secret, following the procedure common to all client scripts (see section 13.1 Client Configuration).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
radctl
Radctl
is a control interface to the radiusd
daemon. It allows the
user running it to query radiusd
about various aspects of its
work and to issue administrative commands to it. The syntax is
radctl command [args] |
where command is a command telling radctl
which actions to
take, and args are optional arguments to the command. Only one
command can be specified per invocation.
The valid commands are as follows:
start [args]
radiusd
is not running already, it is started. When
present, args are passed as the command line to the
server.
stop
radiusd
.
restart [args]
reload
radiusd
server to reread its configuration files.
dumpdb
radiusd
to dump its user hash table into the file
`radlog/radius.parse'. This can be used for debugging
configuration files.
which
radiusd
. This command shows
the line of ps(1)
describing the running copy of
radiusd
program. The exact look depends on the version of
operating system you are running. Please refer to "man ps" for more
detail on ps
output.
Here is an example of what radctl which
prints on
GNU/Linux
:
19692 ? 01:53:11 radiusd |
Here, first field is the PID of the process, second field (`?') indicates that the running program has detached from the controlling terminal, the third field gives total amount of CPU time used by the program, and, finally, the last field shows the full name under which the command was invoked.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
builddbm
builddbm
converts the plaintext Radius users database into
DBM files. Some versions of the Radius daemon have used this to
speed up the access to the users database.
However, with GNU Radius things go the other way around.
The server reads the entire plaintext database, converts it into internal
form, and stores into a hash table, which provides for fast
access. Actually, using a DBM version of the users database slows
down the access unless the machine that runs the Radius daemon is
short of address space for the daemon to store the users database.
builddbm
utility attempts to
convert the file `raddb/users' to `raddb/users.db' or to
the pair
`raddb/users.pag', `raddb/users.dir', depending on the
version of the DBM library used.
If used with one argument, that argument is taken as the name of the plaintext database file to operate upon.
Use the following command line options to modify the operation of
buildbm
:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
radscm
: A Guile Interface to Radius Functions
radscm
is a Scheme interpreter based on Guile with the addition
of special functions and variables for communicating with
radiusd
. This chapter concentrates on the special features
provided by radscm
. Refer to Guile documentation for
information about Scheme and Guile (see section `Overview' in The Guile Reference Manual).
(list id-str host-str secret-str auth-num acct-num cntl-num) |
where the arguments are as follows:
id-str | Server ID |
host-str | Server hostname or IP |
secret-str | Shared secret key to use |
auth-num | Authentication port number |
acct-num | Accounting port number |
cntl-num | Control channel port number |
rad-client-set-server
or
rad-client-add-server
.
0 | Authentication port |
1 | Accounting port |
2 | Control port |
(cons attr-name-str value) |
(cons attr-number value) |
Return: On success,
(list return-code-number pair-list) |
'() |
rad-send-internal
,
but if verbose is specified, the verbose report about interaction with
the radius server is printed.
(list id-str host-str secret-str auth-num acct-num cntl-num) |
id-str | Server ID |
host-str | Server hostname or IP |
secret-str | Shared secret key to use |
auth-num | Authentication port number |
acct-num | Accounting port number |
cntl-num | Control channel port number |
(list id-str host-str secret-str auth-num acct-num cntl-num) |
where the elements are as follows:
id-str | Server ID |
host-str | Server hostname or IP |
secret-str | Shared secret key to use |
auth-num | Authentication port number |
acct-num | Accounting port number |
cntl-num | Control channel port number |
getpass(3)
function.
format
(see section `Formatted Output' in The Guile Reference Manual.)
format
.
pair is either
(cons name-str value) |
(cons attr-number value) |
(cons name-str value) |
(cons attr-number value) |
All Reply-Message
pairs from the list are concatenated and displayed
as one.
Reply-Message
pairs from
pair-list. If text is specified, it is printed before the
concatenated
text.
rad-server-list
, print its ID and hostname
or IP.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Beside the Radius server and accompanying utilities, GNU Radius provides a set of utilities to be used as Radius clients.
The following sections describe in detail the parts of the Radius client package.
13.1 Client Configuration Configuration file is common for all client utilities. 13.2 radtest Radius client shell. 13.3 radsession Send arbitrary requests to Radius server. 13.4 nas.scm
A NAS implementation for GNU/Linux machines. 13.5 pam_radius.so
A PAM module for authentication via Radius.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
All programs from the client package share the same configuration file: `raddb/client.conf'. The file uses simple line-oriented syntax. Empty lines are ignored; the command `#' introduces an end-of-line comment.
The source IP is introduced with the source_ip
statement. Its
syntax is:
source_ip ip-addr |
where ip-addr must be the IP in dotted-quad notation.
The Radius server to send the requests to is introduced with
server
statement:
server name ip-addr secret auth-port acct-port |
Its parts are:
If several server
statement are present, they are tried in
turn until one of them replies to the request.
The amount of time a client program waits for the reply from a
server is configured using the timeout
statement:
timeout number |
If the program does not receive any response within number seconds,
it assumes the server does not respond and either retries the
transmission or tries the next available server. The number of retries is
set with the retry
statement:
retry number |
The example `raddb/client.conf' follows:
server first 10.11.10.1 secret 1645 1646 server second 10.11.10.1 secret 1645 1646 source_ip 127.0.0.1 timeout 3 retry 5 |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Radtest
is a radius client shell, providing a simple and
convenient language for sending requests to RADIUS servers and
analyzing their reply packets.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There are four basic data types in radtest
language: integer
,
ipaddr
, string
and avlist
.
13.2.2.1 Numeric Values Integers and IP addresses. 13.2.2.2 Character Strings 13.2.2.3 Lists of A/V pairs
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Integer means a signed integer value in the range -2147483648..2147483647.
Ipaddr is an unsigned integer value suitable for representing IPv4 addresses. These can be input either as decimal numbers or as IP addresss in usual "dotted-quad" notation.
As a convenience measure, RADIUS request code names can be used in integer context. The following table lists currently defined request names with their integer codes:
Access-Request | 1 |
Access-Accept | 2 |
Access-Reject | 3 |
Accounting-Request | 4 |
Accounting-Response | 5 |
Accounting-Status | 6 |
Password-Request | 7 |
Password-Ack | 8 |
Password-Reject | 9 |
Accounting-Message | 10 |
Access-Challenge | 11 |
Status-Server | 12 |
Status-Client | 13 |
Ascend-Terminate-Session | 31 |
Ascend-Event-Request | 33 |
Ascend-Event-Response | 34 |
Ascend-Allocate-IP | 51 |
Ascend-Release-IP | 52 |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
String is an arbitrary string of characters. Any input token consisting of letters of Latin alphabet, decimal digits, underscores dashes and dots and starting with a Latin alphabet letter or underscores is considered a string. To input strings containing other letters, surround them by double quotes. The following are valid strings:
A-string "String, containing white space" |
The double quote character `"' must be preceeded by a backslash `\' if it is part of a string:
"Always quote \" character" |
Generally speaking, `\' is an escape character, that alters the meaning of the immediately following character. If it is located at the end of the line, it allows to input newline character to strings:
"This string contains a \ newline character." |
Other special escape sequences are:
If the character following the backslash is not one of those specified, the backslash is ignored.
An important variant of string
is a numeric string,
or STRNUM for short. A numeric string is a string that
can be converted to a number, for example "+2"
. This concept
is used for type conversion between integer
and string
values.
Another way to represent strings is using here document syntax. Its format is as follows:
<<[-]delimiter text delimiter |
Delimiter is any word you choose to delimit the text, text represent the text of the string. If delimiter is prepended by a dash, any leading tabulation characters will be removed from text. This allows for natural indentation of `here document' constructs.
The `here document' construct is especially useful to represent strings containing embedded newlines, as shown in the example below:
print <<EOT usage: foo [OPTIONS] [NAME...] OPTIONS are: -h Print this help list. EOT |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Avlist are whitespace or comma-separated lists of RADIUS attribute-value pairs. A syntax for A/V pair is
name op value |
where name is attribute name, op is a comparison
operator (`=', `!=', `<', `<=', `>',
`>='), and value is any valid radtest
data
or expression.
An A/V pair list must be enclosed in parentheses. This is an
example of an A/V pair list consisting of two pairs:
( User-Name = "test" NAS-IP-Address = 10.10.10.1 ) |
An empty pair list is represented by a pair of parentheses: ()
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following keywords are reserved in radtest
:
acct, and, auth, begin, break, case, continue, do, else, end, exit, expect, getopt, if, in, input, not, or, print, return, send, set, shift, while |
The reserved keywords may be used as variable names, provided that the following requrements are met:
'case' = 1 |
${case} + 2 |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Variables are means of storing data values at one point of your
program for using them in another parts of it. Variables can be
assigned either in the program itself, or from the radtest
command line.
13.2.4.1 Using Variables 13.2.4.2 Variable Assignments 13.2.4.3 Dereferencing Variables 13.2.4.4 Accessing Elements of A/V Pair Lists 13.2.4.5 Assignment Options 13.2.4.6 Built-in Variables
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The name of a variable must be a sequence of letters, digits,
underscores and dashes, but it may not begin with a digit or dash. Notice,
that in contrast to the majority of programming languages, use of
dashes (minus signs) is allowed in user names. This is because
traditionally RADIUS attribute names contain dashes, so
extending this practice to variable names makes radtest
programs more consistent. On the other hand, this means that you
should be careful when using minus sign as a subtraction
operator (see minus-ambiguity). Case is significant in variable names:
a
and A
are different variables.
A name of a variable may coincide with one of radtest
reserved
keywords. See section 13.2.3 Reserved Keywords, for description on how to use such
variables.
A few variables have special built-in meanings (see section 13.2.4.6 Built-in Variables). Such variables can be assigned and accessed just as any other ones. All built-in variables names are entirely upper-case.
Variables are never declared, they spring into existence when an assignment is made to them. The type of a variable is determined by the type of the value assigned to it.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An assignment stores a new value into a variable. It's syntax is quite straightforward:
variable = expression |
As a result of the assignment, the expression is evaluated and its value is assigned to variable. If variable did not exist before the assignment, it is created. Otherwise, whatever old value it had before the assignment is forgotten.
It is important to notice that variables do not have permanent types. The type of a variable is the type of whatever value it currently holds. For example:
foo = 1 print $foo => 1 foo = "bar" print $foo => bar foo = ( User-Name = "antonius" NAS-IP-Address = 127.0.0.1 ) print $foo => ( User-Name = "antonius" NAS-IP-Address = 127.0.0.1 ) |
Another important point is that in radtest
, assignment is
not an expression, as it is in many other programming languages. So
C
programmers should resist temptation to use assignments in
expressions. The following is not correct:
x = y = 1 |
Finally, if the variable name coincides with one of radtest
keywords, it must be enclosed in single quotes:
'case' = 1 |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Dereferencing a variable means accessing its value. The simplest form of dereferencing is by prepending a dollar sign to the variable name:
foo = 1 print foo => foo print $foo => 1 |
Notice, that in the example above, the first print
statement
understands foo
as a literal string, whereas the second one
prints the value of the variable.
Dereferencing an undefined variable produces error message:
print $x error--> variable `x' used before definition |
Optionally, the variable name may be surrounded by curly braces.
Both $foo
and ${foo}
are equivalent. The use of
the latter form is obligatory only when the variable name coincides
with one of the reserved keywords (see section 13.2.3 Reserved Keywords).
It also can be used to resolve ambiguity between using dash as
a part of user name and as a subtraction operator:
long-name = 2 $long-name => 2 $long-name-1 error--> variable `long-name-1' used before definition ${long-name}-1 => 1 $long-name - 1 => 1 |
We recommend to always surround `-' with whitespace when it is used as arithmetic operator.
The ${}
notation also permits some operations similar to
shell variable substitution.
$x error--> variable `x' used before definition ${x:-1} => 1 x = 2 ${x:-1} => 2 |
$x error--> variable `x' used before definition ${x:=1} => 1 $x => 1 |
$x error--> variable `x' used before definition ${x:?} error--> x: variable unset ${x:?foobar} error--> foobar |
radtest
prints text (or a default message, if it
is empty), reads the standard input up to the newline character
and returns the value read. Otherwise, the value of the variable
is returned. This notation provides a convenient way for asking
user to supply default values.
${x::} -| (<teletype>:1)x? ${x::Enter value of x: } -| Enter value of x: |
${variable::text}
, with the exception that the input
value will not be echoed on the screen. This notation provides a
convenient way for asking user to supply default values for variables
(such as passwords, shared secrets, etc.) while preventing them from
being compromised.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Elements of an avlist
are accessed as if it were an array,
i.e.:
$variable [ attribute-name ] |
If the attribute attribute-name is of string
data type
and variable may contain more than one pair with this attribute,
adding an asterisk after attribute-name returns concatenated
values of all such pairs:
$variable [ attribute-name * ] |
Examples:
x = (NAS-Port-Id = 127.0.0.1 \ Reply-Message = "a long" Reply-Message = " string" $x[NAS-Port-Id] => 127.0.0.1 $x[Reply-Message] => "a long" $x[Reply-Message*] => "a long string" |
<FIXME> How to get nth instance of an attribute? What gets returned if there is no such attribute in the list? </>
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You can set any radtest
variable from the command line.
There are two ways of doing so.
First, you can use variable assignment option `--assign' (or `-a'). Its syntax is:
--assign variable=text -a variable=text |
For example:
radtest -a foobar=5 |
Another way is useful when you load a radtest
program by
`--file' or `-f'. This second way consists in including
a variable assignment in the form
variable=text |
in the command line after the script name. For example:
radtest -f myprog.rad foo=5 addr=127.0.0.1 |
This method is especially useful for executable scripts that are
run using #!
shell magic. Consider a simple script:
#! /usr/local/bin/radtest -f print $addr |
The value of addr can be given to the script from the command line as in the example below:
myprog.rad addr=127.0.0.1 |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following variables are predefined:
Contains the result of last evaluated expression.
integer
).
avlist
).
ipaddr
).
By default, it equals the IP address set via source_ip
statement
in your `client.conf' file (see section 13.1 Client Configuration).
input
statement
(see section input).
getopt
(see section getopt).
getopt
.
getopt
. If the last call to getopt
returned false,
OPTIND
contains index of the first non-optional argument
in the command line.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Normally radtest
stops parsing its command line
when it encounters either first non-optional argument
(i.e. the one not starting with dash), or an argument consisting
of two dashes. The rest of the command line starting from the
first non-optional argument forms positional parameters.
These parameters are said to form the top-level environment.
Similarly, when invoking a user-defined function (see section 13.2.7 Function Definitions), arguments passed to it are said to form the current environment of the function. These arguments are positional parameters for this function.
Positional parameters are assigned numbers starting from 1. To access
(dereference) a positional parameter, the syntax $n
is used, where n is the number of the parameter. Alternative
forms, such as ${n}
or ${n:-text}
,
can also be used. These work exactly as described in
13.2.4.3 Dereferencing Variables).
The number of positional parameters can be accessed using a special
notation $#
.
Several things need to be mentioned:
string
data
type, whereas the types of positional parameters in a function
current environment are determined before inoking the function.
$0
returns the name of the function
being evaluated. When used in the top-level environment, it returns
the name of radtest
program as given by `--file'
(`-f') option.
AWK
programmers should note that assignments
(see section 13.2.4.5 Assignment Options) are not included in the top level
environment (see example below).
For example, suppose you run:
radtest -f script.rad name foo=bar 5 |
Then, the top-level environment of program `script.rad' consists of the following variables:
$0 => script.rad $1 => name $2 => 5 |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An expression evaluates to a value, which can be printed,
assigned to a variable, used in a conditional statement or passed
to a function. As in other languages, expressions in radtest
include literals, variable and positional parameter dereferences,
function calls and combinations of these with various operators.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Radtest
provides the common arithmetic operators, which
follow normal precedence rules (see section 13.2.6.8 Operator Precedence (How Operators Nest)), and work as
you would expect them to. The only notable exception is subtraction
operator (minus) which can be used as part of a variable or attribute
name, and therefore expressions like $x-3
are ambiguous. This
expression can be thought of either as a dereference of the variable
x-3
(see section 13.2.4.3 Dereferencing Variables), or as subtraction of the value
3
from the value of the variable x
. Radtest
always resolves this ambiguityin the favor of variable dereference.
Therefore we advise you to always surround minus sign by whitespace,
if it is used as a subtraction operator. So, instead of $x-3
,
write $x - 3
. For other methods of solving this ambiguity,
See minus-ambiguity.
This table lists the arithmetic operators in order from highest precedence to lowest:
- x
+ x
x
.
<FIXME> Should this
imply converting x to integer? </>
x * y
x / y
x % y
x + y
x - y
Unary plus and minus have the same precedence, the multiplication, division and remainder all have the same precedence, and addition and subtraction have the same precedence.
If x and y are of different data types, their values are first coerced to a common data type, selected using a set of rules (see section 13.2.6.6 Conversion Between Data Types).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There is only one string operation: concatenation. It is represented by plus sign, e.g.:
"string" + "ent" => "stringent" |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
The following operations are defined on A/V lists:
x + y
( User-Name = "foo" ) + ( Password = "bar" ) => ( User-Name = "foo" Password = "bar" ) ( User-Name = "foo" Service-Type = Login-User ) + \ ( Service-Type = Framed-User Password = "bar" ) => ( User-Name = "foo" \ Service-Type = Framed-User \ Password = "bar" ) |
x - y
( User-Name = "foo" Service-Type = Login-User ) - \ ( Service-Type = Framed-User ) => ( User-Name = "foo" ) |
Notice, that only attribute name matters, its value is ignored. <FIXME> Is this correct? Is there a better way to put it? should we provide an operation that whould compare both attribute number and its value? </>
x % y
( User-Name = "foo" Service-Type = Login-User ) - \ ( Service-Type = Framed-User ) => ( Service-Type = Login-User ) |
<FIXME> Same as above. </>
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Comparison expressions compare operands for relationships
such as equality. They return boolean values, i.e. true
or false
. The comparison operations are nonassociative,
i.e. they cannot be used together as in:
# Wrong! 1 < $x < 2 |
Use boolean operations (see section 13.2.6.5 Boolean Operations) to group comparisons together.
Comparison operations can only be used in conditional expressions.
This table lists all comparison operators in order from highest precedence to lowest (notice, however, the comment after it):
x = y
C
and AWK
programmers, please note single equal sign!
x != y
x < y
x <= y
x > y
x >= y
Operators =
and !=
have equal precedence. Operators
<
, <=
, >
, >=
have equal precedence.
Most operators are defined for all radtest
data types.
However, only =
and !=
are defined for avlist
s.
Using any other comparison operator with avlist
s produces
error.
If x and y are of different data types, their values are first coerced to a common data type, selected using a set of rules (see section 13.2.6.6 Conversion Between Data Types).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A boolean operation is a combination of comparison expressions. Boolean operations can only be used in conditional expressions.
This table lists all comparison operators in order from highest precedence to lowest.
not x
! x
x and y
x or y
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
The unary negation operand is always converted to integer
type:
-(1 + 1) => -2 -(127.0.0.1 + 2) => -2130706435 - ("1" + "1") => -11 - "text" error--> cannot convert string to integer |
The unary not
operand is converted using the following rules:
integer
, no conversion is performed.
STRNUM
(see STRNUM) or
ipaddr
, it is converted to integer.
string
(but is not STRNUM
), the
result of not
is true
only if the operand is an empty
string.
avl
, the result of not
is
true
if the list is empty.
Examples:
not 0 => 1 not 10 => 0 not "23" => 0 not "0" => 1 not "text" => 0 not "" => 1 not 127.0.0.1 => 0 not 0.0.0.0 => 1 |
When operands of two different data types are used in a binary operation, one of the operands is converted (cast) to another operand's type according to the following rules:
radtest
attemtps
to convert another operand to the literal data type. If this attempt
fails, it goes on to rule 2.
STRNUM
(see STRNUM) and another is of numeric
data type (i.e. either integer
or ipaddr
), the latter is converted
to string representation.
ipaddr
and another is
integer
, the latter is converted to ipaddr
.
Radtest
prints appropriate diagnostics and aborts execution of the current
statement.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A function is a name for a particular sequence of statements. It is defined using special definition syntax (see section 13.2.7 Function Definitions). Normally a function return some value. The way to use this value in an expression is with a function call expression, which consists of the function name followed by a comma-separated list of arguments in parentheses. The arguments are expressions which provide values for the function call environment (see section 13.2.5 Positional Parameters. When there is more than one argument, they are separated by commas. <FIXME> Actually, commas in the argument list are optional. At least, now... </> If there are no arguments, write just `()' after the function name. Here are some examples:
foo() no arguments bar(1) one argument bar(1, "string") two arguments |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Operator precedence determines the order of executing operators,
when different operators appear close by in one expression.
For example, *
has higher precedence than +
; thus,
a + b * c
means to multiply b
and c
, and then add
a
to the product.
You can overrule the precedence of the operators by using
parentheses. You can think of the precedence rules as saying where
the parentheses are assumed to be if you do not write parentheses
yourself. Thus the above example is equivalent to a + (b * c)
.
When operators of equal precedence are used together, the leftmost
operator groups first. Thus, a - b + c
groups as
(a - b) + c
.
This table lists radtest
operators in order from highest
precedence to the lowest:
$
(...)
+ - not !
* / %
+ -
< <= = != > >=
and
or
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A function is a name for a particular sequence of statements. The syntax for the function definition is:
name begin ... end |
where name is function name and `...' represent a
non-empty list of valid radtest
statements.
Notice that newline characters are obligatory after name,
begin
and before the final end
keyword.
If the function accepts arguments, these can be referenced in the
function body using $n
notation (see section 13.2.5 Positional Parameters). To return the value from the function return
statement is used.
For example, here is a function that computes sum of the squares of its two arguments:
hypo begin return $1*$1 + $2*$2 end |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Radtest
provides two commands for interaction with remote
RADIUS servers.
Command send
sends request to the server specified in
`raddb/client.conf'. Its syntax is:
send [flags] port-type code [expr-or-pair-list] |
Optional flags can be used for fine-tuning the internals of
send
. You will seldom need to use these, unless you are
developing GNU Radius. See section send, for the detailed description of these.
The first obligatory argument, port-type, specifies which RADIUS port to send the request to. Specifying `auth' will send the request to the authentication port (see section auth-port); specifying `acct' will send it to the accounting port (see section acct-port).
Argument code gives the request code. It is either a number or a symbolic request code name (see section 13.2.2.1 Numeric Values).
The last argument, expr-or-pair-list is either a
radtest
expression evaluating to avlist
or a list
of A/V pairs. These pairs will be included in the request.
Here are several examples:
# Send a |
Command send
stores the reply code into the variable
REPLY_CODE
and reply pairs into the variable REPLY
(see section 13.2.4.6 Built-in Variables).
<FIXME> How do I know if send
has failed? </>
Another primitive is expect
. Expect
takes at most two
arguments: a request code (either numeric or symbolic, (see section 13.2.2.1 Numeric Values)) and optional
list of A/V pairs (similar to send
expr-or-pair-list
argument). Expect
check if these match current
REPLY_CODE
and REPLY
values and if so, prints
the string `PASS'. Otherwise, it prints `FAIL'. This
command is designed primarily for use in GNU Radius testsuite.
Expect
is usually used right after send
, as shown
in the example below:
send auth Access-Request User-Name = "foo" User-Password = "bar" expect Access-Accept Reply-Message = "Access allowed" |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
Radtest
provides two kinds of conditional statements:
if
and case
.
An if
statement in its simplest form is:
if cond stmt |
where cond is a conditional expression and stmt is a
valid radtest
statement. Optional newline may be inserted
between cond stmt.
In this form, if
evaluates the condition and if it yields true,
executes the statement. For example:
if $REPLY[NAS-IP-Address] = 127.0.0.1 print "Request from localhost" |
More complex form of this statement allows to select between the two statements:
if cond stmt-1 else stmt-2 |
Here, stmt-1 will be executed if cond evaluates to true, and stmt-2 will be executed if cond evaluates to false.
Notice, that an optional newline is allowed between cond and
stmt-1 and right after else
keyword. However, a newline
before else
constitutes an error.
If several statements should be executed in a branch of the if
statement, use compound statement as in the example below:
if $REPLY_CODE != Accounting-Response begin print "Accounting failed.\n" exit 1 end else print "Accounting succeeded.\n" |
If
statements can be nested to any depth.
Case
statement allows select a statement based on whether
a string
expression matches given regular expression. The
syntax of case
statement is:
case expr in expr-1 ) stmt-1 expr-2 ) stmt-2 ... expr-n ) stmt-n end |
where expr is a control expression, expr-1, expr-2 etc. are expressions evaluating to extended POSIX regular expressions (for the detailed description of these see section `Regular Expression Library' in Regular Expression Library).
Case
statement first evaluates expr and converts it to
string
data type. Then it evaluates each expr-n in turn
and tests if the resulting regular expression matches expr. If
so, the statement stmt-n is executed and the execution of
case
statement finishes.
The following example illustrates the concept:
case $COMMAND in "auth.*") authenticate($LIST, no) "acct") authenticate($LIST, yes) ".*") begin print "Unknown command." exit 1 end end |
Bourne shell
programmers should notice that:
Case
statement ends with end
, not esac
.
;;
at the end of each branch,
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
Two looping constructs are provided: while
and
do...while
.
The syntax of a while loop is:
while cond stmt |
Newline after cond is obligatory.
do stmt while cond |
As usual do...while
loop differs from its while
counterpart in that its stmt is executed at least once.
The looping constructs can be nested to any depth.
Two special statements are provided for branching within loop
constructs. These are break
and continue
.
Break
statement stops the execution of the current
loop statement and passes control to the statement immediately
following it
while $x < 10 begin if $x < $y break ... x = $x + 1 end print "OK\n" |
In the example above, execution of break
statement passes
control to print
statement.
Break
may also take an argument: a literal number representing
the number of nested loop statements to break from. For example, the
break
statement in the sample code below will exit from the
outermost while
:
while $y < 10 begin while $x < 10 begin if $x < $y break 2 ... x = $x + 1 end ... y = $y + 1 end print "OK\n" |
Continue
statement passes control to the condition of the
current looping construct. When used with a numeric argument, the
latter specifies the number of the nesting looping construct to
pass control to (as with break
, the innermost loop is
considered to have number 1, so continue
is equivalent
to continue 1
).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Getopt
is used to break up command line options for
subsequent parsing.
The only mandatory argument, optstring is a list of short (one-character) options to be recognized. Each short option character in optstring may be followed by one colon to indicate it has a required argument, and by two colons to indicate it has an optional argument. <FIXME> Document starting `+' and `-' chars. </>
Each subsequent invocation of getopt
processes next command
line argument. Getopt
returns true if the argument is an
option and returns false otherwise. It stores the retrieved option
(always with a leading dash) in the variable opt (OPTVAR
by default). If the option has an argument, the latter is stored
in the variable arg (OPTARG
by default). Index of the
next command line argument to be processed is preserved in the
variable ind (OPTIND
by default).
The usual way of processing command line options is by invoking
getopt
in a condition expression of while
loop and
analyzing its return values within the loop. For example:
while getopt "hf:" case $OPTVAR in "-h") print "Got -h option\n" "-f") print "Got -f option. Argument is " $OPTARG "\n" ".*") begin print "Unknown option: " $OPTVAR "\n" exit 1 end end end |
If expr is given, name must also be present.
If name is not given, variable INPUT is used by default.
radtest
command line options. Options should
be a valid radtest
command line (see section 13.2.1 Invoking radtest).
$2
becomes
$1
, $3
becomes $2
etc. $#
is decremented.
$0
is not affected.
If expr is given, it is evaluated, converted to integer and
used as shift value. Thus shift 2
shifts all positional
parameters left by 2.
It is an error to use return
outside of a function definition.
See section 13.2.10 Loops, for the detailed discussion of the subject.
See section 13.2.10 Loops, for the detailed discussion of the subject.
REPLY_CODE
and reply A/V pairs in
the variable REPLY
(see section 13.2.8 Interacting with Radius Servers).
flags are a whitespace-separated list of variable assignments. Following variables are understood:
repeat=n
id=n
keepauth=1
avlist
, or an immediate
avlist
(see section 13.2.2.3 Lists of A/V pairs). In the latter case, the parentheses
around the list are optional.
REPLY_CODE
matches code and, optionally, if
REPLY
matches expr-or-pair-list. If so, print the
string `PASS', otherwise print `FAIL'.
See section 13.2.8 Interacting with Radius Servers, for the detailed discussion of this statement.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
As an example, let's consider radauth
program
(see section 12.6 radauth
). Its main purpose is to send authentication
request to the remote server, analyze its reply and if it is
positive, send an appropriate accounting record, thereby initiating
user's session. Optionally, the script should also be able to
send a lone accounting record.
In the discussion below, we will show and explain subsequent parts of the script text. For the ease of explanation, each line of program text will be prepended by its ordinal line number.
The script begins as follows:
1 #! /usr/bin/radtest -f 2 3 while getopt "n:s:P:hv" 4 begin 5 case $OPTVAR in 6 "-n") NASIP = $OPTARG 7 "-s") SID = $OPTARG 8 "-P") PID = $OPTARG 9 "-v") set -v |
radtest
in order to interpret the program.
Getopt
(see section getopt) in line 3 analyzes each
subsequent command line argument and if it is an option checks
whether it matches one of the option letters defined in its
first argument. The option letter will be returned in OPTVAR
variable, its argument (if any) -- in OPTARG
variable.
OPTARG
value is analyzed using case
statement. Lines
6 -- 8 preserve OPTARG
values in appropriate variables for
later use. NASIP
will be used as the value of
NAS-IP-Address
attribute, SID
is the session id
(Acct-Session-Id
attribute), and PID
is the port
number (for NAS-Port-Id
attribute.
radtest
interpreter (see section 13.2.1 Invoking radtest).
The next piece of code handles `-h' and erroneous options:
10 "-h") begin 11 print <<-EOT 12 usage: radauth [OPTIONS] [COMMAND] login [password] 13 Options are: 14 -v Print verbose descriptions of what is being done 15 -n IP Set NAS IP address 16 -s SID Set session ID 17 -P PORT Set NAS port number 18 COMMAND is one of: 19 auth Send only Access-Request (default) 20 acct Send Access-Request. If successfull, send 21 accounting start request 22 start Send accounting start request 23 stop Send accounting stop request 24 EOT 25 exit 0 26 end 27 ".*") begin 28 print "Unknown option: " $OPTVAR "\n" 29 exit 1 30 end 31 end 32 end |
33 34 shift ${OPTIND}-1 35 36 if $# > 3 37 begin 38 print "Wrong number of arguments." 39 print "Try radauth -h for more info" 40 exit 1 41 end |
OPTIND
keeps the ordinal number of the first non-optional
argument. This line shifts off all the options processed by
getopt
, so that the first non-optional argument may be
addressed by $1
notation. Notice use of curly braces to
solve minus ambiguity (see minus-ambiguity).
Next piece of code:
42 43 case $1 in 44 "auth|acct|start|stop") begin 45 COMMAND=$1 46 shift 1 47 end 48 ".*") COMMAND="auth" 49 end 50 51 LOGIN=${1:?User name is not specified. Try radauth -h for more info.} 52 53 if ${NASIP:-} = "" 54 NASIP=$SOURCEIP 55 56 LIST = ( User-Name = $LOGIN NAS-IP-Address = $NASIP ) |
COMMAND
and shift arguments by one, so login becomes argument
$1
. Otherwise, assume `auth' command.
LOGIN
variable. Otherwise, print diagnostic message and exit.
NASIP
variable from the built-in
variable SOURCEIP
(see section 13.2.4.6 Built-in Variables)
LIST
will hold the list of A/V pairs to be sent
to the server. This line initializes it with a list of two A/V pairs:
User-Name
and NAS-IP-Address
.
Accounting function will be used to send accounting requests to
the server. It is supposed to take a single argument: an avlist
of A/V pairs to be sent to the server.
57 58 'acct' 59 begin 60 if ${SID:-} = "" 61 input "Enter session ID: " SID 62 if ${PID:-} = "" 63 input "Enter NAS port ID: " PID 64 send auth Accounting-Request $1 + \ (Acct-Session-Id = $SID NAS-Port-Id = $PID) |
SID
(session ID) is not supplied, prompt the
user to input it.
PID
(port ID) is not supplied, prompt the
user to input it.
Acct-Session-Id
and NAS-Port-Id
attributes
to the function's first argument.
The final part of acct
function analyzes the reply from the
server:
65 if $REPLY_CODE != Accounting-Response 66 begin 67 print "Accounting failed.\n" 68 exit 1 69 end 70 print "Accounting OK.\n" 71 exit 0 72 end 73 |
Notice, that acct
never returns. Instead it exits with an
error code indicating success or failure.
The purpose of the authentication function auth
is
to send an Access-Request
to the server and perform
some actions based on its reply.
The function will take three arguments:
$1
$2
$3
The function is not expected to return. Instead it should exit to the shell with an appropriate error code.
74 'auth' 75 begin 76 send auth Access-Request $1 + (User-Password = $2) |
User-Password
pair to the list given
by the first argument to the function.
The rest of the function analyzes the reply from the server and takes
appropriate actions. Notice that if the server replies with an
Access-Challenge
packet, we will have to send subsequent
authentication requests, so this piece of code is enclosed within
a while
loop.
First, the function handles Access-Accept
and
Access-Reject
replies:
77 while 1 78 begin 79 if $REPLY_CODE = Access-Accept 80 begin 81 print "Authentication passed. " + $REPLY[Reply-Message*] + "\n" 82 if ${3:-no} = no 83 exit 0 84 'acct'($1 + ( Acct-Status-Type = Start )) 85 end else if $REPLY_CODE = Access-Reject 86 begin 87 print "Authentication failed. " + $REPLY[Reply-Message*] + "\n" 88 break |
while
loop. It will eventually be exited
either using break
, or using exit
(see below).
Access-Accept
replies:
Reply-Message
attribute from the reply
packet (see section 13.2.4.4 Accessing Elements of A/V Pair Lists).
acct
function to perform accounting. The
A/V pairs included in the accounting request are formed by adding
Acct-Status-Type
attribute to the list given by the first
argument to the function.
Access-Reject
replies. Print the reply message and
break from the loop.
Next piece of code deals with Access-Challenge
replies. For
simplicity we assume that such replies always carry user menus
(See section 5.13 Login Menus -- `raddb/menus', for the description of these). So, upon
receiving an Access-Challenge
we should print out the menu,
read the users selection and send back an Access-Request
to the server. This part is the only one that actually continues
the loop at line 77.
89 end else if $REPLY_CODE = Access-Challenge 90 begin 91 print $REPLY[Reply-Message*] 92 input 93 send auth Access-Request \ 94 (User-Name = $LOGIN User-Password = $INPUT \ State = $REPLY[State]) |
Reply-Message
attributes. There may be several instances of the attribute, hence the
use of `*' to concatenate their values together.
INPUT
variable. See section 13.2.11 Built-in Primitives, for the description of
input
statement.
Access-Request
packet with three attributes.
User-Password
contains the user reply, State
contains
the menu state from the server reply packet.
Final part of the function:
95 end else begin 96 print "Authentication failed. Reply code " + $REPLY_CODE + "\n" 97 break 98 end 99 end 100 exit 1 101 end 102 |
break
is executed either on line 88 or on line 97.
The final part selects an action based on the user command and
executes it. It is equivalent to the main
function in a
C
program:
103 case ${COMMAND} in 104 "auth") 'auth'($LIST, ${2:&Password: }, no) 105 "acct") 'auth'($LIST, ${2:&Password: }, yes) 106 "start") 'acct'($LIST+(Acct-Status-Type = Start)) 107 "stop") 'acct'($LIST+(Acct-Status-Type = Stop)) 108 ".*") begin 109 print "Unknown command. Try radauth -h for more info" 110 exit 1 111 end 112 end 113 114 # End of radauth |
COMMAND
variable.
auth
function. If the second argument is given in the
command line, its value is taken as user's password. Otherwise, the
user is prompted for the password with the string `Password: '.
The input is read with echo turned off to prevent the password from
being compromised (the `:&' construct, see section 13.2.4.3 Dereferencing Variables).
acct
function for `start' and stop
commands.
case
statement from line 103.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
radsession
is a Guile script that sends authentication and
accounting requests to the Radius server. To invoke the script, run
radsession options action |
Possible actions are:
Options determine the contents of the request's pairlist. They are:
NAS-IP-Address
attribute.
Acct-Session-Id
attribute).
NAS-Port-Id
attribute).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
nas.scm
nas.scm
is a Guile program that allows one to convert a GNU/Linux
box into a NAS. It requires Guile version 1.4 or better and PPP
version 2.3.7 or better.
To use it, you will basically need to do the following:
ln -s libexec/nas.scm /etc/ppp/ip-up ln -s libexec/nas.scm /etc/ppp/ip-down |
Here, libexec denotes the location of your libexec directory,
where nas.scm
is installed. If not overridden at configure
time, it defaults to `prefix/libexec'. These links assure
that ppp
will invoke nas.scm
when the user's session
starts and ends, thus giving it a possibility to send accounting
requests.
nas-log-facility
, specifying the syslog
facility to be used for logging, and pppd-args
, keeping the
arguments to be given to ppp
.
getty
.
For example, if you use mgetty
, then the `inittab'
entries for dial-up lines will look like:
d0:345:respawn:/sbin/mgetty ttyS0 vt100 d1:345:respawn:/sbin/mgetty ttyS1 vt100 ... |
mgetty
's `login.config' will then contain the following line:
* - - /usr/local/libexec/nas.scm @ |
If you use agetty
, then the `inittab' will contain
(with the long lines split for readability)
d0:345:respawn:/sbin/agetty -mt60 \ -l /usr/local/libexec/nas.scm 38400,19200,9600 \ ttyS0 vt100 d1:345:respawn:/sbin/agetty -mt60 \ -l /usr/local/libexec/nas.scm 38400,19200,9600 \ ttyS1 vt100 ... |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
pam_radius.so
pam_radius.so
is a PAM module for Radius
authentication. The module understands the following command line options:
Debugging levels equal to or greater than 10 compromise users' passwords, so use them sparingly.
attr: Service-Type=type |
The pam_radius.so
module logs its messages under LOG_AUTH
syslog facility.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following sections describe the most frequently used Radius attributes. Each attribute is described as follows:
ATTRIBUTE name value type |
Users: | user-flags |
|
Hints: | hints-flags |
|
Huntgroups: | huntgroup-flags |
|
Additivity: | additivity | |
Proxy propagated: | prop |
These values have the following meaning:
The entry N/A for any of this fields signifies "not applicable".
14.1 Authentication Attributes 14.2 Accounting Attributes 14.3 Radius Internal Attributes
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These are the attributes the NAS uses in authentication packets and expects to get back in authentication replies. These can be used in matching rules.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
CHAP-Password
ATTRIBUTE CHAP-Password 3 string |
Users: | L- |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | N/A | |
Proxy propagated: | No |
This attribute indicates the response value provided by a PPP Challenge-Handshake Authentication Protocol (CHAP) user in response to the challenge. It is only used in Access-Request packets.
The CHAP challenge value is found in the CHAP-Challenge attribute (60) if present in the packet, otherwise in the request authenticator field.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Callback-Id
ATTRIBUTE Callback-Id 20 string |
Users: | -R |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | Replace | |
Proxy propagated: | No |
This attribute indicates the name of a place to be called, to be interpreted by the NAS. It may be used in Access-Accept packets.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Callback-Number
ATTRIBUTE Callback-Number 19 string |
Users: | -R |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | Replace | |
Proxy propagated: | No |
This attribute indicates a dialing string to be used for callback. It may be used in Access-Accept packets. It may be used in an Access-Request packet as a hint to the server that a Callback service is desired, but the server is not required to honor the hint.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Called-Station-Id
ATTRIBUTE Called-Station-Id 30 string |
Users: | L- |
|
Hints: | -R |
|
Huntgroups: | LR |
|
Additivity: | Append | |
Proxy propagated: | No |
This attribute allows the NAS to send in the Access-Request packet the phone number that the user called, using Dialed Number Identification (DNIS) or similar technology. Note that this may be different from the phone number the call comes in on. It is only used in Access-Request packets.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Calling-Station-Id
ATTRIBUTE Calling-Station-Id 31 string |
Users: | L- |
|
Hints: | -R |
|
Huntgroups: | LR |
|
Additivity: | Append | |
Proxy propagated: | No |
This attribute allows the NAS to send in the Access-Request packet the phone number that the call came from, using automatic number identification (ANI) or similar technology. It is only used in Access-Request packets.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Class
ATTRIBUTE Class 25 string |
Users: | LR |
|
Hints: | LR |
|
Huntgroups: | LR |
|
Additivity: | Append | |
Proxy propagated: | No |
This attribute is available to be sent by the server to the client in an Access-Accept and should be sent unmodified by the client to the accounting server as part of the Accounting-Request packet if accounting is supported.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Framed-Compression
ATTRIBUTE Framed-Compression 13 integer |
Users: | LR |
|
Hints: | -R |
|
Huntgroups: | LR |
|
Additivity: | Replace | |
Proxy propagated: | Yes |
VALUE Framed-Compression None 0 VALUE Framed-Compression Van-Jacobson-TCP-IP 1 |
This attribute indicates a compression protocol to be used for the link. It may be used in Access-Accept packets. It may be used in an Access-Request packet as a hint to the server that the NAS would prefer to use that compression, but the server is not required to honor the hint.
More than one compression protocol attribute may be sent. It is the responsibility of the NAS to apply the proper compression protocol to appropriate link traffic.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Framed-IP-Address
ATTRIBUTE Framed-IP-Address 8 ipaddr |
Users: | LR |
|
Hints: | -R |
|
Huntgroups: | LR |
|
Additivity: | Replace | |
Proxy propagated: | No |
This attribute indicates the address to be configured for the user. It may be used in Access-Accept packets. It may be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that address, but the server is not required to honor the hint.
The value 0xFFFFFFFF
(255.255.255.255
) indicates that
the NAS should
allow the user to select an address. The value 0xFFFFFFFE
(255.255.255.254
)
indicates that the NAS should select an address for the user (e.g. assigned
from a pool of addresses kept by the NAS). Other valid values indicate
that the NAS should use that value as the user's IP.
When used in a RHS, the value of this attribute can
optionally be followed by a plus sign. This usage means that
the value of NAS-Port-Id
must be added to this IP before
replying. For example,
Framed-IP-Address = 10.10.0.1+ |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Framed-IP-Netmask
ATTRIBUTE Framed-IP-Netmask 9 ipaddr |
Users: | LR |
|
Hints: | -R |
|
Huntgroups: | LR |
|
Additivity: | Replace | |
Proxy propagated: | No |
This attribute indicates the IP netmask to be configured for the user when the user is a router to a network. It may be used in Access-Accept packets. It may be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that netmask, but the server is not required to honor the hint.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Framed-MTU
ATTRIBUTE Framed-MTU 12 integer |
Users: | LR |
|
Hints: | -R |
|
Huntgroups: | -R |
|
Additivity: | Replace | |
Proxy propagated: | Yes |
This attribute indicates the maximum transmission unit to be configured for the user, when it is not negotiated by some other means (such as PPP). It is only used in Access-Accept packets.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Framed-Protocol
ATTRIBUTE Framed-Protocol 7 integer |
Users: | LR |
|
Hints: | -R |
|
Huntgroups: | LR |
|
Additivity: | Replace | |
Proxy propagated: | Yes |
VALUE Framed-Protocol PPP 1 VALUE Framed-Protocol SLIP 2 |
This attribute indicates the framing to be used for framed access. It may be used in both Access-Request and Access-Accept packets.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Framed-Route
ATTRIBUTE Framed-Route 22 string |
Users: | -R |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | Replace | |
Proxy propagated: | No |
This attribute provides routing information to be configured for the user on the NAS. It is used in the Access-Accept packet and can appear multiple times.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Framed-Routing
ATTRIBUTE Framed-Routing 10 integer |
Users: | -R |
|
Hints: | -R |
|
Huntgroups: | -R |
|
Additivity: | Replace | |
Proxy propagated: | No |
VALUE Framed-Routing None 0 VALUE Framed-Routing Broadcast 1 VALUE Framed-Routing Listen 2 VALUE Framed-Routing Broadcast-Listen 3 |
This attribute indicates the routing method for the user when the user is a router to a network. It is only used in Access-Accept packets.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Idle-Timeout
ATTRIBUTE Idle-Timeout 28 integer |
Users: | -R |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | Replace | |
Proxy propagated: | Yes |
This attribute sets the maximum number of consecutive seconds of idle connection allowed to the user before termination of the session or prompt. The server may send this attribute to the client in an Access-Accept or Access-Challenge.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
NAS-IP-Address
ATTRIBUTE NAS-IP-Address 4 ipaddr |
Users: | L- |
|
Hints: | -R |
|
Huntgroups: | LR |
|
Additivity: | Append | |
Proxy propagated: | No |
This attribute indicates the identifying IP of the NAS
which is requesting authentication of the user. It is only used
in Access-Request packets. Each Access-Request packet should contain
either a NAS-IP-Address
or a NAS-Identifier
attribute
(14.1.16 NAS-Identifier
).
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
NAS-Identifier
ATTRIBUTE NAS-Identifier 32 string |
Users: | L- |
|
Hints: | -R |
|
Huntgroups: | LR |
|
Additivity: | Append | |
Proxy propagated: | No |
This attribute contains a string identifying the NAS originating
the access request. It is only used in Access-Request packets.
Either NAS-IP-Address
or NAS-Identifier
should be present in an
Access-Request packet.
See section 14.1.15 NAS-IP-Address
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
NAS-Port-Id
ATTRIBUTE NAS-Port-Id 5 integer |
Users: | LR |
|
Hints: | -R |
|
Huntgroups: | LR |
|
Additivity: | Append | |
Proxy propagated: | No |
This attribute indicates the physical port number of the NAS that is authenticating the user. It is only used in Access-Request packets. Note that here we are using "port" in its sense of a physical connection on the NAS, not in the sense of a TCP or UDP port number.
Some NASes try to encode various information in the NAS-Port-Id
attribute value. For example, the MAX Ascend terminal server constructs
NAS-Port-Id
by concatenating the line type (one digit), the line number
(two digits), and the channel number (two digits), thus producing
a five-digit port number. In order to normalize such encoded
port numbers we recommend using a rewrite function (see section 5.12 Rewrite functions -- `raddb/rewrite').
A rewrite function for MAX Ascend servers is provided in the
distribution.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
NAS-Port-Type
ATTRIBUTE NAS-Port-Type 61 integer |
Users: | -- |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | Append | |
Proxy propagated: | No |
VALUE NAS-Port-Type Async 0 VALUE NAS-Port-Type Sync 1 VALUE NAS-Port-Type ISDN 2 VALUE NAS-Port-Type ISDN-V120 3 VALUE NAS-Port-Type ISDN-V110 4 |
This attribute indicates the type of the physical port of the NAS
that is authenticating the user. It can be used instead of or in
addition to the NAS-Port-Id
(14.1.17 NAS-Port-Id
) attribute. It
is only used in
Access-Request packets. Either NAS-Port
or NAS-Port-Type
or
both should be present in an Access-Request packet, if the NAS
differentiates among its ports.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Reply-Message
ATTRIBUTE Reply-Message 18 string |
Users: | -R |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | Append | |
Proxy propagated: | Yes |
This attribute indicates text that may be displayed to the user.
When used in an Access-Accept, it is the success message.
When used in an Access-Reject, it is the failure message. It may indicate a dialog message to prompt the user before another Access-Request attempt.
When used in an Access-Challenge, it may indicate a dialog message to prompt the user for a response.
Multiple Reply-Message
attributes may be included, and if any
are displayed,
they must be displayed in the same order as they appear in in the
packet.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Service-Type
ATTRIBUTE Service-Type 6 integer |
Users: | LR |
|
Hints: | -R |
|
Huntgroups: | LR |
|
Additivity: | Replace | |
Proxy propagated: | Yes |
VALUE Service-Type Login-User 1 VALUE Service-Type Framed-User 2 VALUE Service-Type Callback-Login-User 3 VALUE Service-Type Callback-Framed-User 4 VALUE Service-Type Outbound-User 5 VALUE Service-Type Administrative-User 6 VALUE Service-Type NAS-Prompt-User 7 VALUE Service-Type Authenticate-Only 8 VALUE Service-Type Call-Check 10 |
This attribute indicates the type of service the user has requested, or the type of service to be provided. It may be used in both Access-Request and Access-Accept packets.
When used in an Access-Request the service type represents a hint to the Radius server that the NAS has reason to believe the user would prefer the kind of service indicated.
When used in an Access-Accept, the service type is an indication to the NAS that the user must be provided this type of service.
The meaning of various service types is as follows:
Login-User
Framed-User
Framed-IP-Address
attribute (see section 14.1.8 Framed-IP-Address
) will
supply the IP to be used.
Callback-Login-User
Callback-Framed-User
Outbound-User
Administrative-User
NAS-Prompt
Authenticate-Only
Call-Check
Callback-NAS-Prompt
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Session-Timeout
ATTRIBUTE Session-Timeout 27 integer |
Users: | -R |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | Replace | |
Proxy propagated: | Yes |
This attribute sets the maximum number of seconds of service to be provided to the user before termination of the session or prompt. The server may send this attribute to the client in an Access-Accept or Access-Challenge.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
State
ATTRIBUTE State 24 string |
Users: | LR |
|
Hints: | LR |
|
Huntgroups: | LR |
|
Additivity: | Append | |
Proxy propagated: | No |
This attribute is available to be sent by the server to the client in an Access-Challenge and must be sent unmodified from the client to the server in the new Access-Request reply to that challenge, if any.
This attribute is available to be sent by the server to the client
in an Access-Accept that also includes a Termination-Action
attribute with the value RADIUS-Request
. If the NAS performs
the termination action by sending a new Access-Request upon
termination of the current session, it must include the State
attribute unchanged in that Access-Request.
In either usage, no interpretation by the client should be made.
A packet may have only one State
attribute.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Termination-Action
ATTRIBUTE Termination-Action 29 integer |
Users: | LR |
|
Hints: | -R |
|
Huntgroups: | -R |
|
Additivity: | Replace | |
Proxy propagated: | No |
VALUE Termination-Action Default 0 VALUE Termination-Action RADIUS-Request 1 |
This attribute indicates what action the NAS should take when the specified service is completed. It is only used in Access-Accept packets.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
User-Name
ATTRIBUTE User-Name 1 string |
Users: | LR |
|
Hints: | -R |
|
Huntgroups: | LR |
|
Additivity: | Replace | |
Proxy propagated: | Yes |
This attribute indicates the name of the user to be authenticated or
accounted. It is used in Access-Request and Accounting attributes.
The length of the user name is usually limited by some arbitrary value.
By default, Radius supports user names up to 32 characters long. This
value can be modified by redefining the RUT_USERNAME
macro in the
`include/radutmp.h' file in the distribution directory and recompiling the
program.
Some NASes have peculiarities about sending long user names. For example, the Specialix Jetstream 8500 24-port access server inserts a `/' character after the 10th character if the user name is longer than 10 characters. In such cases, we recommend applying rewrite functions in order to bring the user name to its normal form (see section 5.12 Rewrite functions -- `raddb/rewrite').
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
User-Password
ATTRIBUTE User-Password 2 string |
Users: | L- |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | N/A | |
Proxy propagated: | No |
This attribute indicates the password of the user to be authenticated, or the user's input following an Access-Challenge. It is only used in Access-Request packets.
On transmission, the password is hidden. The password is first padded at the end with nulls to a multiple of 16 octets. A one-way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the request authenticator. This value is XORed with the first 16 octet segment of the password and placed in the first 16 octets of the String field of the User-Password attribute.
If the password is longer than 16 characters, a second one-way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the result of the first xor. That hash is XORed with the second 16 octet segment of the password and placed in the second 16 octets of the string field of the User-Password attribute.
If necessary, this operation is repeated, with each XOR result being used along with the shared secret to generate the next hash to XOR the next segment of the password, up to no more than 128 characters.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Vendor-Specific
(This message will disappear, once this node revised.)
ATTRIBUTE Vendor-Specific 26 string |
Users: | LR |
|
Hints: | -R |
|
Huntgroups: | -R |
|
Additivity: | Append | |
Proxy propagated: | No |
This attribute is available to allow vendors to support their own extended attributes not suitable for general usage. <FIXME> some more detail over the VSAs? How does GNU Radius handle unknown VSAs? </>
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These are attributes the NAS sends along with accounting requests. These attributes can not be used in matching rules.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Acct-Authentic
ATTRIBUTE Acct-Authentic 45 integer |
Users: | -- |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | N/A | |
Proxy propagated: | N/A |
VALUE Acct-Authentic RADIUS 1 VALUE Acct-Authentic Local 2 VALUE Acct-Authentic Remote 3 |
This attribute may be included in an Accounting-Request to indicate how the user was authenticated, whether by Radius, the NAS itself, or another remote authentication protocol. Users who are delivered service without being authenticated should not generate accounting records.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Acct-Delay-Time
ATTRIBUTE Acct-Delay-Time 41 integer |
Users: | -- |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | N/A | |
Proxy propagated: | N/A |
This attribute indicates how many seconds the client has been trying to send this record for, and can be subtracted from the time of arrival on the server to find the approximate time of the event generating this Accounting-Request. (Network transit time is ignored.)
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Acct-Input-Octets
ATTRIBUTE Acct-Input-Octets 42 integer |
Users: | -- |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | N/A | |
Proxy propagated: | N/A |
This attribute indicates how many octets have been received from
the port over the course of this service being provided, and can
only be present in Accounting-Request records where
Acct-Status-Type
is set to Stop
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Acct-Input-Packets
ATTRIBUTE Acct-Input-Packets 47 integer |
Users: | -- |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | N/A | |
Proxy propagated: | N/A |
This attribute indicates how many packets have been received from
the port over the course of this service being provided to a
framed user, and can only be present in Accounting-Request records
where Acct-Status-Type
is set to Stop
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Acct-Output-Octets
ATTRIBUTE Acct-Output-Octets 43 integer |
Users: | -- |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | N/A | |
Proxy propagated: | N/A |
This attribute indicates how many octets have been sent to the
port in the course of delivering this service, and can only be
present in Accounting-Request records where Acct-Status-Type
is set to Stop
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Acct-Output-Packets
ATTRIBUTE Acct-Output-Packets 48 integer |
Users: | -- |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | N/A | |
Proxy propagated: | N/A |
This attribute indicates how many packets have been sent to the
port in the course of delivering this service to a framed user,
and can only be present in Accounting-Request records where
Acct-Status-Type
is set to Stop
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Acct-Session-Id
ATTRIBUTE Acct-Session-Id 44 string |
Users: | -- |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | N/A | |
Proxy propagated: | N/A |
This attribute is a unique accounting ID to make it easy to match
start and stop records in a log file. The start and stop records
for a given session must have the same Acct-Session-Id
. An
Accounting-Request packet must have an Acct-Session-Id
. An
Access-Request packet may have an Acct-Session-Id
; if it does,
then the NAS must use the same Acct-Session-Id
in the
Accounting-Request
packets for that session.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Acct-Session-Time
ATTRIBUTE Acct-Session-Time 46 integer |
Users: | -- |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | N/A | |
Proxy propagated: | N/A |
This attribute indicates how many seconds the user has received
service for, and can only be present in Accounting-Request records
where Acct-Status-Type
is set to Stop
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Acct-Status-Type
ATTRIBUTE Acct-Status-Type 40 integer |
Users: | -- |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | N/A | |
Proxy propagated: | N/A |
VALUE Acct-Status-Type Start 1 VALUE Acct-Status-Type Stop 2 VALUE Acct-Status-Type Alive 3 VALUE Acct-Status-Type Accounting-On 7 VALUE Acct-Status-Type Accounting-Off 8 |
This attribute indicates whether this Accounting-Request marks the
beginning of the user service (Start
) or the end (Stop
).
It may also be used to mark the start of accounting (for example,
upon booting) by specifying Accounting-On
and to mark the end of
accounting (for example, just before a scheduled reboot) by specifying
Accounting-Off
.
A special value Alive
or Interim-Update
indicates the packet that
contains some additional data to the initial Start
record or to the
last Alive
record.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Acct-Terminate-Cause
ATTRIBUTE Acct-Terminate-Cause 49 integer |
Users: | -- |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | N/A | |
Proxy propagated: | N/A |
VALUE Acct-Terminate-Cause User-Request 1 VALUE Acct-Terminate-Cause Lost-Carrier 2 VALUE Acct-Terminate-Cause Lost-Service 3 VALUE Acct-Terminate-Cause Idle-Timeout 4 VALUE Acct-Terminate-Cause Session-Timeout 5 VALUE Acct-Terminate-Cause Admin-Reset 6 VALUE Acct-Terminate-Cause Admin-Reboot 7 VALUE Acct-Terminate-Cause Port-Error 8 VALUE Acct-Terminate-Cause NAS-Error 9 VALUE Acct-Terminate-Cause NAS-Request 10 VALUE Acct-Terminate-Cause NAS-Reboot 11 VALUE Acct-Terminate-Cause Port-Unneeded 12 VALUE Acct-Terminate-Cause Port-Preempted 13 VALUE Acct-Terminate-Cause Port-Suspended 14 VALUE Acct-Terminate-Cause Service-Unavailable 15 VALUE Acct-Terminate-Cause Callback 16 VALUE Acct-Terminate-Cause User-Error 17 VALUE Acct-Terminate-Cause Host-Request 18 |
This attribute indicates how the session was terminated, and can
only be present in Accounting-Request records where
Acct-Status-Type
is set to Stop
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These are attributes used by GNU Radius during the processing of a request. They are never returned to the NAS. Mostly, they are used in matching rules.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Acct-Ext-Program
ATTRIBUTE Acct-Ext-Program 2008 string |
Users: | -- |
|
Hints: | -R |
|
Huntgroups: | -- |
|
Additivity: | Replace | |
Proxy propagated: | N/A |
The Acct-Ext-Program
attribute can be used in RHS of an
`raddb/hints' to require the execution of an external accounting
program or filter. If the attribute value starts with a vertical bar
(`|'), then the attribute specifies the filter program to be used.
If it starts with a slash (`/'), then it is understood as
the full pathname and arguments for the external program to be executed.
Using any other character as the start of this string results in error.
The command line can reference any attributes from both check and reply pairlists using attribute macros (see section 5.14 Macro Substitution).
Before the execution of the program, radiusd
switches to the
uid and gid of the user daemon
and the group daemon
. You can
override these defaults by setting variables exec-program-user
and exec-program-group
in configuration file to proper values
(see section The option statement).
The accounting program must exit with status 0 to indicate a successful accounting.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Acct-Type
ATTRIBUTE Acct-Type 2003 integer |
Users: | L- |
|
Hints: | -R |
|
Huntgroups: | -R |
|
Additivity: | Append | |
Proxy propagated: | N/A |
VALUE Acct-Type None 0 VALUE Acct-Type System 1 VALUE Acct-Type Detail 2 VALUE Acct-Type SQL 3 |
The Acct-Type
allows one to control which accounting methods
must be used for a given user or group of users. In the absence
of this attribute, all currently enabled accounting types are used.
See section 8. Accounting, for more information about accounting types.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Auth-Failure-Trigger
This attribute specifies an external program or a Scheme expression to be run upon an authentication failure. The handling of this attribute depends upon its value:
If the value of Auth-Failure-Trigger
begins with `/', it
is taken to contain a command line for invoking an external
program. In this case radiusd
invokes the program much the
same way it does when handling Exec-Program
attribute, i.e. the
program is invoked with standard input closed, its standard output and
standard error are captured and redirected to
`radlog/radius.stderr' file, the return value of the
program is ignored.
If the value of Auth-Failure-Trigger
begins with `(', it
is executed it as a Scheme
expression. The return value of the
expression is ignored.
This attribute is designed as a means to provide special handling for authentication failures. It can be used, for example, to increase failure counters and to block accounts after a specified number of authentication failures occurs. See section 7.10 Controlling Authentication Probes, for the detailed discussion of its usage.
<FIXME> There is no corresponding Auth-Success-Trigger
...
Exec-Program
or Scheme-Procedure
may be used for the
purpose, the latter, however, is not able to execute s-exps. At
the time of this writing the release 1.3 is being prepared, so I do
not want to introduce any possibly destabilizing changes. This will be
fixed in future releases. </>
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Auth-Data
ATTRIBUTE Auth-Data 2006 string |
Users: | L- |
|
Hints: | -R |
|
Huntgroups: | -R |
|
Additivity: | Replace | |
Proxy propagated: | N/A |
The Auth-Data
can be used to pass additional data to the
authentication methods that need them. In version 1.3
of GNU Radius, this attribute may be used in conjunction with the
SQL
and Pam
authentication types. When used with the
Pam
authentication type, this attribute holds the name
of the PAM service to use. This attribute is temporarily
appended to the authentication request, so its value can be
referenced to as %C{Auth-Data}
.
See section 5.11.2 Authentication Server Parameters, for an example of
of using the Auth-Data
attribute in `raddb/sqlserver':
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Auth-Type
ATTRIBUTE Auth-Type 1000 integer |
Users: | L- |
|
Hints: | -R |
|
Huntgroups: | -R |
|
Additivity: | Append | |
Proxy propagated: | No |
VALUE Auth-Type Local 0 VALUE Auth-Type System 1 VALUE Auth-Type Crypt-Local 3 VALUE Auth-Type Reject 4 VALUE Auth-Type SQL 252 VALUE Auth-Type Pam 253 VALUE Auth-Type Accept 254 |
This attribute tells the server which type of authentication to apply to a particular user. It can be used in the LHS of the user's profile (see section 7. Authentication.)
Radius interprets values of Auth-Type
attribute as follows:
Local
User-Password
attribute from the record is taken
as a cleantext password and is compared against the User-Password
value
from the input packet.
System
Crypt-Local
User-Password
attribute from the record is taken
as an MD5 hash on the user's password. Radius generates MD5 hash
on the supplied User-Password
value and compares the two strings.
Reject
Accept
SQL
Mysql
Mysql
is an alias maintained for compatibility
with other versions of Radius.
Pam
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Crypt-Password
ATTRIBUTE Crypt-Password 1006 string |
Users: | L- |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | Append | |
Proxy propagated: | No |
This attribute is intended to be used in user's profile LHS.
It specifies the MD5 hash of the user's password. When this attribute
is present, Auth-Type = Crypt-Local
is assumed. If both Auth-Type
and Crypt-Password
are present, the value of Auth-Type
is
ignored.
See section 14.3.5 Auth-Type
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Exec-Program-Wait
ATTRIBUTE Exec-Program-Wait 1039 string |
Users: | -R |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | Replace | |
Proxy propagated: | No |
When present in the RHS, the Exec-Program-Wait
attribute specifies
the program to be executed when the entry matches. If the attribute
value string starts with vertical bar (`|'), then the attribute
specifies the filter program to be used. If it starts with
slash (`/'), then it is understood as the full
pathname and arguments for the external program to be executed. Using
any other character as the start of this string results in error.
14.3.7.1 Running an External Program 14.3.7.2 Using an External Filter
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The command line can reference any attributes from both check and reply pairlists using attribute macros see section 5.14 Macro Substitution.
Before the execution of the program, radiusd
switches to
uid and gid of the user daemon
and the group daemon
. You can
override these defaults by setting the variable exec-program-user
in the configuration file to a proper value.
See section The option statement.
The daemon will wait until the program terminates. The return value of its execution determines whether the entry matches. If the program exits with a nonzero code, then the match fails. If it exits with a zero code, the match succeeds. In this case the standard output of the program is read and parsed as if it were a pairlist. The attributes thus obtained are added to the entry's reply attributes.
Suppose the `users' file contains the following entry:
DEFAULT Auth-Type = System, Simultaneous-Use = 1 Exec-Program-Wait = "/usr/local/sbin/telauth \ %C{User-Name} \ %C{Calling-Station-Id}" |
Then, upon successful matching, the program
`/usr/local/sbin/telauth' will be executed. It will get as its
arguments the values of the User-Name
and Calling-Station-Id
attributes from the request pairs.
The `/usr/local/sbin/telauth' can, for example, contain the following:
#! /bin/sh DB=/var/db/userlist if grep "$1:$2" $DB; then echo "Service-Type = Login," echo "Session-Timeout = 1200" exit 0 else echo "Reply-Message = \ \"You are not authorized to log in\"" exit 1 fi |
It is assumed that `/var/db/userlist' contains a list of
username
:caller-id
pairs for those users that are
authorized to use login service.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If the value of Exec-Program-Wait
attribute begins with `|',
radiusd
strips this character from the value and uses the
resulting string
as a name of the predefined external filter. Such filter must be
declared in `raddb/config' (see section 5.1.10 filters
statement).
DEFAULT Auth-Type = System, Simultaneous-Use = 1 Exec-Program-Wait = "|myfilter" |
and let the `raddb/config' contain the following (6):
filters { filter myfilter { exec-path "/usr/libexec/myfilter"; error-log "myfilter.log"; auth { input-format "%C{User-Name} %C{Calling-Station-Id}"; wait-reply yes; }; }; }; |
/usr/libexec/myfilter
will be invoked, if it hasn't already been
started for this thread. Any output it sends to its standard error
will be redirected to the file `myfilter.log' in the current
logging directory. A string consisting of the user's login name and
his calling station ID followed by a newline will be sent to the
program.
The following is a sample /usr/libexec/myfilter
written
in the shell:
#! /bin/sh DB=/var/db/userlist while read NAME CLID do if grep "$1:$2" $DB; then echo "0 Service-Type = Login, Session-Timeout = 1200" else echo "1 Reply-Message = \ \"You are not authorized to log in\"" fi done |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Exec-Program
ATTRIBUTE Exec-Program 1038 string |
Users: | -R |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | Replace | |
Proxy propagated: | No |
When present in the RHS, the Exec-Program
attribute specifies
the full pathname and arguments for the program to be executed when the
entry matches.
The command line can reference any attributes from both check and reply pairlists, using attribute macros (see section 5.14 Macro Substitution).
Before the execution of the program, radiusd
switches to the
uid and gid of the user daemon
and the group daemon
. You can
override these defaults by setting variables exec-program-user
and exec-program-group
in configuration file to proper values
The option statement.
The daemon does not wait for the process to terminate.
Suppose the `users' file contains the following entry:
DEFAULT Auth-Type = System, Simultaneous-Use = 1 Exec-Program = "/usr/local/sbin/logauth \ %C{User-Name} \ %C{Calling-Station-Id}" |
Then, upon successful matching, the program
`/usr/local/sbin/logauth' will be executed. It will get as its
arguments the values of the User-Name
and Calling-Station-Id
attributes from the request pairs.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Fall-Through
ATTRIBUTE Fall-Through 1036 integer |
Users: | LR |
|
Hints: | LR |
|
Huntgroups: | -- |
|
Additivity: | Append | |
Proxy propagated: | No |
VALUE Fall-Through No 0 VALUE Fall-Through Yes 1 |
The Fall-Through
attribute should be used in the reply list.
If its value is set to Yes
in a particular record, that
tells Radius to continue looking up other records
even when the record at hand matches the request. It can be used to provide
default values for several profiles.
Consider the following example. Let's suppose the `users' file contains the following:
johns Auth-Type = SQL Framed-IP-Address = 11.10.10.251, Fall-Through = Yes smith Auth-Type = SQL Framed-IP-Address = 11.10.10.252, Fall-Through = Yes DEFAULT NAS-IP-Address = 11.10.10.1 Service-Type = Framed-User, Framed-Protocol = PPP |
Then after successful matching of a particular user's record,
the matching will continue until it finds the DEFAULT
entry,
which will add its RHS to the reply pairs for
this request. The effect is that, if user `johns' authenticates
successfully she gets the following reply pairs:
Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 11.10.10.251 |
whereas user smith
gets
Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 11.10.10.252 |
Note that the attribute Fall-Through
itself
is never returned to the NAS.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Group
ATTRIBUTE Group 1005 string |
Users: | L- |
|
Hints: | L- |
|
Huntgroups: | LR |
|
Additivity: | Append | |
Proxy propagated: | No |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Hint
ATTRIBUTE Hint 1040 string |
Users: | L- |
|
Hints: | -R |
|
Huntgroups: | -R |
|
Additivity: | Append | |
Proxy propagated: | No |
Use the Hint
attribute to specify additional matching criteria
depending on the hint (see section 5.6 Request Processing Hints -- `raddb/hints').
Let the `hints' file contain
DEFAULT Prefix = "S", Strip-User-Name = No Hint = "SLIP" |
and the `users' file contain
DEFAULT Hint = "SLIP", NAS-IP-Address = 11.10.10.12, Auth-Type = System Service-Type = Framed-User, Framed-Protocol = SLIP |
Then any user having a valid system account and coming from NAS `11.10.10.12' will be provided SLIP service if his user name starts with `S'.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Huntgroup-Name
ATTRIBUTE Huntgroup-Name 221 string |
Users: | L- |
|
Hints: | -R |
|
Huntgroups: | LR |
|
Additivity: | Append | |
Proxy propagated: | No |
The Huntgroup-Name
can be used either in the LHS of the
`users' file record or in the RHS of the `huntgroups'
file record.
When encountered in a LHS of a particular `users' profile, this attribute indicates the huntgroup name to be matched. Radius looks up the corresponding record in the `huntgroups' file. If such a record is found, each A/V pair from its reply list is compared against the corresponding pair from the request being processed. The request matches only if it contains all the attributes from the specified huntgroup, and their values satisfy the conditions listed in the huntgroup pairs.
For example, suppose that the authentication request contains the following attributes:
User-Name = "john", User-Password = "guess", NAS-IP-Address = 10.11.11.1, NAS-Port-Id = 24 |
Let us further suppose that the `users' file contains the following entry:
john Huntgroup-Name = "users_group", Auth-Type = System Service-Type = Login |
and, finally, `huntgroups' contains the following entry:
users_group NAS-IP-Address = 10.11.11.1 NAS-Port-Id < 32 |
Then the authentication request will succeed, since it contains
NAS-Port-Id
attribute and its value is less than 32.
See section 5.7 Huntgroups -- `raddb/huntgroups'.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Log-Mode-Mask
ATTRIBUTE Log-Mode-Mask 2007 integer |
Users: | L- |
|
Hints: | -R |
|
Huntgroups: | -R |
|
Additivity: | Append | |
Proxy propagated: | N/A |
VALUE Log-Mode-Mask Log-Auth 1 VALUE Log-Mode-Mask Log-Auth-Pass 2 VALUE Log-Mode-Mask Log-Failed-Pass 4 VALUE Log-Mode-Mask Log-Pass 6 VALUE Log-Mode-Mask Log-All 7 |
Log-Mode-Mask
is used to control the verbosity of authentication
log messages for given user or class of users. The meaning of its
values is:
Log-Auth
Log-Auth-Pass
Log-Failed-Pass
Log-Pass
Log-All
Technical details: After authentication, the server collects all
Log-Mode-Mask
attributes from the incoming request and LHS
of the user's entry. The values of these attributes ORed together
form a mask, which is applied via an XOR operation to the current log
mode. The value thus obtained is used as effective log mode.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Login-Time
ATTRIBUTE Login-Time 1042 string |
Users: | L- |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | Append | |
Proxy propagated: | No |
The Login-Time
attribute specifies the time range over which the user
is allowed to log in. The attribute should be specified in the LHS.
The format of the Login-Time
string is the same as that of UUCP
time ranges. The following description of the time range format is
adopted from the documentation for the Taylor UUCP package:
A time string may be a list of simple time strings separated with vertical bars `|' or commas `,'.
Each simple time string must begin either with a day-of-week abbreviation (one of `Su', `Mo', `Tu', `We', `Th', `Fr', `Sa'), or `Wk' for any day from Monday to Friday inclusive, or `Any' or `Al' for any day.
Following the day may be a range of hours separated with a hyphen, using 24-hour time. The range of hours may cross 0; for example `2300-0700' means any time except 7 AM to 11 PM. If no time is given, calls may be made at any time on the specified day(s).
The time string may also be the single word `Never', which does not match any time.
Here are a few sample time strings with an explanation of what they mean.
This means weekdays before 8:55 AM or after 11:05 PM, any time Saturday, or Sunday before 4:55 PM or after 11:05 PM. These are approximately the times during which night rates apply to phone calls in the U.S.A. Note that this time string uses, for example, `2305' rather than `2300'; this will ensure a cheap rate even if the computer clock is running up to five minutes ahead of the real time.
This means weekdays from 9:05 AM to 10:55 PM, or Sunday from 5:05 PM to 10:55 PM. This is approximately the opposite of the previous example.
This means any day. Since no time is specified, it means any time on any day.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Match-Profile
ATTRIBUTE Match-Profile 2004 string |
Users: | LR |
|
Hints: | -R |
|
Huntgroups: | -R |
|
Additivity: | Append | |
Proxy propagated: | No |
The Match-Profile
attribute can be used in LHS and RHS lists of a
user profile. Its value is the name of another user's profile (target
profile). When Match-Profile
is used in the LHS, the incoming
packet will match this profile only if it matches the target profile.
In this case the reply pairs will be formed by concatenating the RHS
lists from both profiles.
When used in the RHS, this attribute causes the reply pairs
from the target profile to be appended to the reply from the current
profile if the target profile matches the incoming request.
For example:
IPPOOL NAS-IP-Address = 10.10.10.1 Framed-Protocol = PPP, Framed-IP-Address = "10.10.10.2" IPPOOL NAS-IP-Address = 10.10.11.1 Framed-Protocol = PPP, Framed-IP-Address = "10.10.11.2" guest Auth-Type = SQL Service-Type = Framed-User, Match-Profile = IPPOOL |
In this example, when user guest
comes from NAS
10.10.10.1
, he is
assigned IP 10.10.10.2
, otherwise if he is coming from NAS
10.10.11.1
he is assigned IP 10.10.11.2
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Menu
ATTRIBUTE Menu 1001 string |
Users: | -R |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | Replace | |
Proxy propagated: | No |
This attribute should be used in the RHS. If it is used, it should be the only reply item.
The Menu
attribute specifies the name of the menu to be presented
to the user. The corresponding menu code is looked up in the
`RADIUS_DIR/menus/' directory (see section 5.13 Login Menus -- `raddb/menus').
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Pam-Auth
ATTRIBUTE Pam-Auth 1041 string |
Users: | L- |
|
Hints: | -R |
|
Huntgroups: | -R |
|
Additivity: | Append | |
Proxy propagated: | No |
The Pam-Auth
attribute can be used in conjunction with
Auth-Type = Pam |
to supply the PAM service name instead of the default `radius'.
It is ignored if Auth-Type
attribute is not set to Pam
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Prefix
ATTRIBUTE Prefix 1003 string |
Users: | L- |
|
Hints: | L- |
|
Huntgroups: | LR |
|
Additivity: | Append | |
Proxy propagated: | No |
The Prefix
attribute indicates the prefix that the user name
should contain in order for a particular record in the profile
to be matched. This attribute should be specified in the LHS
of the `users' or `hints' file.
For example, if the `users' file contained
DEFAULT Prefix = "U", Auth-Type = System Service-Type = Login-User |
then the user names `Ugray' and `Uyoda' would match this record, whereas `gray' and `yoda' would not.
Both Prefix
and Suffix
attributes may be specified in
a profile. In this case the record is matched only if the user name
contains both the prefix and the suffix specified.
See section 14.3.27 Suffix
, and
14.3.26 Strip-User-Name
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Proxy-Replied
ATTRIBUTE Proxy-Replied 2012 integer |
Users: | L- |
|
Hints: | L- |
|
Huntgroups: | L- |
|
Additivity: | Replace | |
Proxy propagated: | N/A |
VALUE Proxy-Replied No 0 VALUE Proxy-Replied Yes 1 |
radiusd
adds this attribute to the incoming request if it
was already processed by a remote radius server.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Realm-Name
(This message will disappear, once this node revised.)
ATTRIBUTE Realm-Name 2013 string |
Users: | L- |
|
Hints: | L- |
|
Huntgroups: | L- |
|
Additivity: | Append | |
Proxy propagated: | No |
<FIXME> This is an `internal attribute'. It keeps the realm name
of the user. The Realm-Name
attribute is added to the proxied
request after receiving a reply from the realm server. See section 14.3.19 Proxy-Replied
. </>
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Replace-User-Name
ATTRIBUTE Replace-User-Name 2001 string |
Users: | LR |
|
Hints: | LR |
|
Huntgroups: | -- |
|
Additivity: | Append | |
Proxy propagated: | No |
VALUE Replace-User-Name No 0 VALUE Replace-User-Name Yes 1 |
Use this attribute to modify the user name from the incoming packet. The
Replace-User-Name
can reference any attributes from both LHS
and RHS pairlists using attribute macros (5.14 Macro Substitution).
For example, the `users' entry
guest NAS-IP-Address = 11.10.10.11, Calling-Station-Id != "" Auth-Type = Accept Replace-User-Name = "guest#%C{Calling-Station-Id}", Service-Type = Framed-User, Framed-Protocol = PPP |
allows the use of PPP service for user name guest
, coming from NAS
`11.10.10.11' with a nonempty Calling-Station-Id
attribute.
A string consisting of a `#' character followed by the
Calling-Station-Id
value is appended to the user name.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Rewrite-Function
ATTRIBUTE Rewrite-Function 2004 string |
Users: | LR |
|
Hints: | LR |
|
Huntgroups: | LR |
|
Additivity: | Append | |
Proxy propagated: | No |
The Rewrite-Function
attribute specifies the name of the
rewriting function to be applied to the request. The attribute
may be specified in either pairlist in the entries of
the `hints' or `huntgroups' configuration file.
The corresponding function should be defined in `rewrite' as
integer name() |
i.e., it should return an integer value and should not take any arguments.
See section Packet rewriting rules, 5.6 Request Processing Hints -- `raddb/hints'; 5.7 Huntgroups -- `raddb/huntgroups'.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Scheme-Acct-Procedure
ATTRIBUTE Scheme-Acct-Procedure 2010 string |
Users: | -- |
|
Hints: | -R |
|
Huntgroups: | -- |
|
Additivity: | Replace | |
Proxy propagated: | N/A |
The Scheme-Acct-Procedure
attribute is used to set the name
of the Scheme accounting procedure. See section 11.3.3 Accounting with Scheme, for
information about how to write Scheme accounting procedures.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Scheme-Procedure
ATTRIBUTE Scheme-Procedure 2009 string |
Users: | -R |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | Append | |
Proxy propagated: | N/A |
The Scheme-Procedure
attribute is used to set the name
of the Scheme authentication procedure. See section 11.3.2 Authentication with Scheme, for
information about how to write Scheme authentication procedures.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Simultaneous-Use
ATTRIBUTE Simultaneous-Use 1034 integer |
Users: | L- |
|
Hints: | -R |
|
Huntgroups: | -R |
|
Additivity: | Append | |
Proxy propagated: | No |
This attribute specifies the maximum number of simultaneous logins a given user is permitted to have. When the user is logged in this number of times, any further attempts to log in are rejected.
See section 7.9 Multiple Login Checking.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Strip-User-Name
ATTRIBUTE Strip-User-Name 1035 integer |
Users: | LR |
|
Hints: | LR |
|
Huntgroups: | -R |
|
Additivity: | Append | |
Proxy propagated: | No |
VALUE Strip-User-Name No 0 VALUE Strip-User-Name Yes 1 |
The value of Strip-User-Name
indicates whether Radius should
strip any prefixes/suffixes specified in the user's profile from the
user name. When it is set to Yes
, the user names will be logged and
accounted without any prefixes or suffixes.
A user may have several user names for different kind of services. In this case differentiating the user names by their prefixes and stripping them off before accounting would help keep accounting records consistent.
For example, let's suppose the `users' file contains
DEFAULT Suffix = ".ppp", Strip-User-Name = Yes, Auth-Type = SQL Service-Type = Framed-User, Framed-Protocol = PPP DEFAULT Suffix = ".slip", Strip-User-Name = Yes, Auth-Type = SQL Service-Type = Framed-User, Framed-Protocol = SLIP |
Now, user `johns', having a valid account in the SQL database, logs in as `johns.ppp'. She then is provided the PPP service, and her PPP session is accounted under user name `johns'. Later on, she logs in as `johns.slip'. In this case she is provided the SLIP service and again her session is accounted under her real user name `johns'.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Suffix
ATTRIBUTE Suffix 1004 string |
Users: | L- |
|
Hints: | L- |
|
Huntgroups: | LR |
|
Additivity: | Append | |
Proxy propagated: | No |
The Suffix
attribute indicates the suffix that the user name
should contain in order for a particular record in the profile
to be matched. This attribute should be specified in LHS
of the `users' or `hints' file.
For example, if the `users' file contained
DEFAULT Suffix = ".ppp", Auth-Type = System, Strip-User-Name = Yes Service-Type = Framed-User, Framed-Protocol = PPP |
then the user names `gray.ppp' and `yoda.ppp' would match this record, whereas `gray' and `yoda' would not.
Both Prefix
and Suffix
attributes may be specified in
a profile. In this case the record is matched only if the user name
contains both the prefix and the suffix specified.
See section 14.3.18 Prefix
, and
14.3.26 Strip-User-Name
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Termination-Menu
ATTRIBUTE Termination-Menu 1002 string |
Users: | -R |
|
Hints: | -- |
|
Huntgroups: | -- |
|
Additivity: | Replace | |
Proxy propagated: | No |
This attribute should be used in the RHS. If it is used, it should be the only reply item.
The Termination-Menu
specifies the name of the menu file to be
presented to the user after finishing his session. The corresponding
menu code is looked up in the `RADIUS_DIR/menus/' directory
(see section 5.13 Login Menus -- `raddb/menus').
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
It is possible you will encounter a bug in one of the Radius programs. If this happens, we would like to hear about it. As the purpose of bug reporting is to improve software, please be sure to include maximum information when reporting a bug. The information needed is:
radiusd
daemon, run
`radiusd -v' and include the output it produces.
Send your report to bug-gnu-radius@gnu.org. Allow us a couple of days to answer.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The two places to look for news regarding GNU Radius are the Radius homepage at http://www.gnu.org/software/radius and the Radius project page at http://savannah.gnu.org/projects/radius.
The following mailing lists are related to GNU Radius:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GNU Radius is free software; this means that everyone is free to use it and free to redistribute it on certain conditions. GNU Radius is not in the public domain; it is copyrighted and there are restrictions on its distribution, but these restrictions are designed to permit everything that a good cooperating citizen would want to do. What is not allowed is to try to prevent others from further sharing any version of GNU Radius that they might get from you. The precise conditions are found in the GNU General Public License that comes with Radius and also appears following this section.
One way to get a copy of GNU Radius is from someone else who has it. You need not ask for our permission to do so, or tell any one else; just copy it. If you have access to the Internet, you can get the latest distribution version of GNU Radius by anonymous FTP. It is available at ftp://ftp.gnu.org/pub/gnu/radius
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Throughout this document the following terms are used:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
I would like to acknowledge Oswaldo Aguirre and Francisco
Obispo, who invested a lot of time and effort to debug and test
the program. They also wrote web-radact
-- a web interface
to the radius database.
Alexandre Oliva provided a lot of good advice and offered valuable help in testing Radius on various platforms.
The following people provided many helpful comments, bug reports and patches: Dustin Mitchell, Jody Owens, Andrey Y. Mosienko, Oleg Gawriloff, Adrian P. van Bloois, Michael Samuel, Michael Smirnov, Andrey Pavlenko, Michael Weiser, Eric Salomé, Clement Gerouville, Dave Restall, Vlad Lungu, Robert Abbate, Jaime Tellez Sanchez, Cornel Cristea, Krzysztof Kopera, and David Friedman.
Additional people need to be thanked for their assistance in producing this manual. Lisa M. Goldstein coordinated its preparation and Joseph C. Fineman and Daniel Barowy did a remarkable job of editing.
And of course, thanks to Richard M. Stallman for founding the FSF and starting the GNU project.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
This document presents a draft describing new approach for processing RADIUS requests. It is intended as a request for comments, and, in the long run, as a guide for GNU Radius developers. In its current state it is far from being complete. Please check http://www.gnu.org/software/radius/manual for updated versions. Feel free to send your comments and suggestions to bug-gnu-radius@gnu.org.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When I started to write GNU Radius, back in 1998, I had two major aims. The first and primary aim was to create a flexible and robust system that would follow the principle of Jon Postel:
Be liberal in what you accept and conservative in what you send.
This, I believe, is the main principle of any good software for Internet.
The second aim was to be backward compatible with the implementations that already existed back then. This seemed to be important (and the time has proved it was), because it would allow users to easily switch from older radius daemon to GNU Radius.
An important part of every complex program is its configuration file. Traditional implementations of RADIUS servers (beginning from Livingston Radius) used a configuration suite consisting of several files, usually located in `/etc/raddb' subdirectory. Its main components were:
Among these files, the first two were used for requests of any kind,
whereas `users' was used only for Access-Request
packets.
Though this configuration system suffered from many inconsistencies, the second aim required GNU Radius to use this approach.
To compensate for its deficiencies and to fulfill the first aim,
this configuration system was extended, while preserving its main
functionality. A number of additional internal attributes were
added, that control radiusd
behavior. A new language was
created whose main purpose was to modify incoming requests
(see section 11.2 Rewrite). The support for GNU's Ubiquitous Intelligent
Language for Extensions (see section 11.3 Guile) was added, that allowed to
further extend GNU Radius functionality.
The present operation model(7) of GNU Radius and its configuration file system(8) emerged as a result of the two development aims described above. Since 1998 up to present, GNU Radius users contributed a lot of ideas and code to the further development of the system.
However, it became obvious that this system presents strong obstacles to the further development. The next section addresses its deficiencies.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The main deficiencies are inherited with the traditional configuration
file suite. The rules for processing each request are split among
three files, each of which is processed differently, despite of their
external similarity. The administrator has to keep in mind a set of
exotic rules when configuring the system(9). When matching incoming
requests with configuration file entries (LHS, see section 3.3 Matching Rule), some attributes are taken verbatim, whereas others are used
to control radiusd
behavior and to pass additional data to
other rules (see section 14.3 Radius Internal Attributes). The things become even
more complicated when RADIUS realms come into play (see section 3.4.2.1 Proxy Service). Some attributes are meaningful only if used in a certain
part of a certain configuration file rule.
So, while being a lot more flexible than the approach used by other RADIUS implementations, the current system is quite difficult to maintain.
Another deficiency is little control over actions executed on
different events. For example, it is often asked how can one
block a user account after a predefined number of authentication
failures? Currently this can only be done by writing an external
authentication procedure (either in Scheme, using Guile, or as
a standalone executable, using Exec-Program-Wait
). The
proper solution would be to have a set of user-defined triggers
for every RADIUS event (in this case, for authentication failure).
Another commonly asked question is how to make radiusd
execute several SQL queries when processing a request.
While GNU Radius is not supposed to compensate for deficiencies
of some SQL implementations that do not allow for
nested queries, such a feature could come quite handy.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
Processing of incoming requests is controlled by request-processing program. Request-processing program is a list-like structure, consisting of instructions.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Request-processing program consists of instructions. There are seven basic instruction types:
grad_instr_conditional_t
grad_instr_call_t
grad_instr_action_t
grad_instr_proxy_t
grad_instr_forward_t
grad_instr_reply_t
Consequently, an instruction is defined as a union of the above node types:
enum grad_instr_type { grad_instr_conditional, grad_instr_call, grad_instr_return, grad_instr_action, grad_instr_reply, grad_instr_proxy, grad_instr_forward }; typedef struct grad_instr grad_instr_t; struct grad_instr { enum grad_instr_type type; grad_instr_t *next; union { grad_instr_conditional_t cond; grad_instr_call_t call; grad_instr_action_t action; grad_instr_reply_t reply; grad_instr_proxy_t proxy; grad_instr_forward_t forward; } v; }; |
Type
member contains type of the instruction. The evaluator
uses type
to determine which part of union v
, holds
instruction-specific data.
Next
points to the next instruction. The evaluator will
go to this instruction unless the present one changes the control
flow.
Finally, v
contains instruction-specific data. These will
be discussed in the following subsections.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
struct grad_instr_conditional { grad_entry_point_t cond; /* Entry point to the compiled Rewrite condition */ grad_instr_t *iftrue; /* Points to the ``true'' branch */ grad_instr_t *iffalse; /* Points to the ``false'' branch */ }; typedef struct grad_instr_conditional grad_instr_conditional_t; |
Instructions of type grad_instr_conditional_t
indicate branching.
Upon encountering an grad_instr_conditional_t
, the
engine executes a Rewrite expression pointed to by cond
.
If the expression evaluates to true
, execution branches to
instruction iftrue
. Otherwise, if iffalse
is not NULL
,
execution branches to that instruction. Otherwise, the control flow
passes to grad_instr_t.next
, as described in the previous section.
t
.
nil
.
COND
with two arguments:
(COND "%[User-Name] ~= \"test-.*\"" (REPLY Access-Reject ("Reply-Message" . "Test accounts disabled"))) |
COND
with three arguments:
(COND "%[Hint] == "PPP" && authorize(PAM)" (REPLY Access-Accept ("Service-Type" . "Framed-User") ("Framed-Protocol" . "PPP")) (REPLY Access-Reject ("Reply-Message" . "Access Denied"))) |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
struct grad_instr_call { grad_instr_t *entry; }; typedef struct grad_instr_call grad_instr_call_t; |
Instructions of type grad_instr_call
instruct the engine to
call the given subprogram. The engine pushes the current
instruction
<FIXME> definition of current instruction or pc? </>
to the return
point stack
<FIXME> definition of this? </>
and branches to instruction
entry
. Execution of the subprogram ends when the engine
encounters an instruction of one of the following types:
grad_instr_return
, grad_instr_reply
or grad_instr_proxy
.
If grad_instr_return
is encountered, the engine pops the
instruction from the top of the return point stack and makes it
current instruction, then it branches to the next
node.
If grad_instr_reply
or grad_instr_proxy
is encountered,
the engine, after executing corresponding actions, finishes executing
the program.
In the second form defun-name is a name of the RPL subprogram
defined by defun
.
First form:
(CALL (ACTION "myfun(%[User-Name])") (REPLY Access-Reject ("Reply-Message" . "Access Denied"))) |
Second form:
(CALL process_users) |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
An instruction of type grad_instr_return
indicates a return point from
the subprogram. If encountered in a subprogram (i.e. a program entered by
grad_instr_call
node), it indicates return to the calling
subprogram (see the previous subsection). Otherwise, if
grad_instr_return
is encountered within the main trunk, it
ends evaluating of the program.
Instructions of this type have no data associated with them in union v
.
(RETURN) |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
struct grad_instr_action { grad_entry_point_t expr; /* Entry point to the compiled Rewrite expression */ }; typedef struct grad_instr_action grad_instr_reply_t; |
The machine executes a Rewrite expression with entry point
expr
. Any return value from the expression is ignored.
<FIXME> Should the expression receive any arguments? If so,
what arguments? I'd say it should take at least the
request being processed and the reply pairs collected so far. </>
(ACTION "%[NAS-IP-Address] = request_source_ip()") |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
struct grad_instr_reply { u_char reply_code; /* Radius request code */ }; typedef struct grad_instr_reply grad_instr_reply_t; |
grad_instr_reply
instructs radiusd
to send to the
requesting NAS a reply with code reply_code
. Any reply
pairs collected while executing the program are attached to
the reply.
After executing grad_instr_reply
instruction, the engine
stops executing of the program.
Any execution path will usually end with this instruction.
Arguments:
cons
: (name-or-number . value)
.
(REPLY Access-Accept ("Service-Type" . "Framed-User") ("Framed-Protocol" . "PPP")) |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
struct grad_instr_proxy { grad_realm_t realm; }; typedef struct grad_instr_proxy grad_instr_proxy_t; |
This instruction tells radius to proxy the request to the server defined
in realm
. In other words, the engine executes
proxy_send
. Further processing of the program is stopped.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
struct grad_instr_forward { grad_list_t server_list; }; typedef struct grad_instr_forward grad_instr_forward_t; |
This node forwards the request to each servers from
server_list
. Forwarding differs from proxying
in that the requests are sent to the remote servers and processed
locally. The remote server is not expected to
reply. See section forwarding, for more information on this subject.
In contrast to grad_instr_proxy
, this instruction type does not
cause the execution to stop.
Elements of server_list
are of type grad_server_t
.
Currently forwarding is performed by forward_request
function
(`forward.c'), which could be used with little modifications.
Namely, it will be rewritten to get server list as argument, instead
of using static variable forward_list
. Consequently, the
functions responsible for creating and initializing this static
variable will disappear along with the variable itself.
<FIXME> Ok, but
what shall we do with forward
statement in `raddb/config'?
I should address this issue in the section dedicated to backward
compatibility </>
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
Within the new configuration system, the traditional "trio" `hints-huntgroups-users' will be translated to the following program:
(defprog main (CALL hints) (CALL huntgroups) (COND "request_code() == Access-Request" (CALL users)) (REPLY Access-Reject (Reply-Message . "\nAccess denied\n"))) |
For example, consider the following configuration:
# raddb/hints: DEFAULT Prefix = "PPP" Hint = PPP |
This will produce the following program:
(defprog hints (COND "%[Prefix] == \"PPP\"") (ACTION "%[Hint] = \"PPP\"")) |
#raddb/huntgroups DEFAULT NAS-IP-Address = 10.10.4.1 Suffix = "staff" DEFAULT NAS-IP-Address = 10.10.4.2 Huntgroup-Name = "second" |
Will produce
(defprog huntgroups (COND "%[NAS-IP-Address] == 10.10.4.1 && !(%[Suffix] == \"staff\")" (REPLY Access-Reject ("Reply-Message" . "Access Denied by Huntgroup"))) (COND "%[NAS-IP-Address] == 10.10.4.2" (ACTION "%[Huntgroup-Name] = \"second\""))) |
Finally, `users':
#raddb/users DEFAULT Hint = "PPP", Auth-Type = PAM Service-Type = Framed-User, Framed-Protocol = PPP DEFAULT Huntgroup-Name = "second", Auth-Type = PAM Service-Type = "Authenticate-Only", Reply-Message = "Authentity Confirmed" |
will produce
(defprog users (COND "%[Hint] == "PPP" && authorize(PAM)" (REPLY Access-Accept (Service-Type . Framed-User) (Framed-Protocol . PPP)) (REPLY Access-Reject (Reply-Message . "Access Denied"))) (COND "%[Huntgroup-Name] == \"second\" && authorize(PAM)" (REPLY Access-Accept (Service-Type . "Authenticate-Only") (Reply-Message . "Authentity Confirmed")))) |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This message will disappear, once this node revised.)
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. |
The purpose of this License is to make a manual, textbook, or other functional and useful document free in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.
A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.
The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.
A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.
A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.
You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements."
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.
If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:
Copyright (C) year your name. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License''. |
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts." line with this:
with the Invariant Sections being list their titles, with the Front-Cover Texts being list, and with the Back-Cover Texts being list. |
If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Jump to: | $
%
_
A B C D E F G H I L M N O P Q R S T U V W |
---|
Jump to: | $
%
_
A B C D E F G H I L M N O P Q R S T U V W |
---|
[Top] | [Contents] | [Index] | [ ? ] |
For compatibility with other
radius implementations, GNU Radius treats profile labels in the
form DEFAULT%d
, where %d represents a decimal number, in
the same way it treats DEFAULT
labels. The same applies to
BEGIN
labels.
The flags are optional for compatibility with previous versions of GNU Radius. If they are omitted, the default is `[LRLRLR]+'
Logins from DEFAULT NASes are not reflected in SNMP variables.
This interface is likely to change in future versions
In this example the statement has been split on two lines to fit the page width. It must occupy a single line in the real configuration file.
In this example the input-format
statement has been
split on two lines to fit the page width. It must occupy a single line
in the real configuration file.
See section 3. How Radius Operates.
See section 5. Radius Configuration Files.
`Hints' is processed for each request... Authentication requests first pass `hints', then `huntgroups', then `users'... Accounting requests use only `hints' and `huntgroups'... `Huntgroups' entries may also be used (sometimes inadvertently) to create ACL rules, etc, etc...
[Top] | [Contents] | [Index] | [ ? ] |
option
block
logging
block
category
statement
channel
statement
logging
statement
auth
statement
acct
statement
usedbm
statement
snmp
statement
rewrite
statement.
guile
statement
message
statement
filters
statement
mlc
statement
radwho
radwho
Command Line Options
radwho
Format Strings
radwho
Predefined Formats
radlast
radlast
Command Line Options
radzap
radgrep
radping
radauth
radctl
builddbm
radscm
: A Guile Interface to Radius Functions
nas.scm
pam_radius.so
CHAP-Password
Callback-Id
Callback-Number
Called-Station-Id
Calling-Station-Id
Class
Framed-Compression
Framed-IP-Address
Framed-IP-Netmask
Framed-MTU
Framed-Protocol
Framed-Route
Framed-Routing
Idle-Timeout
NAS-IP-Address
NAS-Identifier
NAS-Port-Id
NAS-Port-Type
Reply-Message
Service-Type
Session-Timeout
State
Termination-Action
User-Name
User-Password
Vendor-Specific
Acct-Authentic
Acct-Delay-Time
Acct-Input-Octets
Acct-Input-Packets
Acct-Output-Octets
Acct-Output-Packets
Acct-Session-Id
Acct-Session-Time
Acct-Status-Type
Acct-Terminate-Cause
Acct-Ext-Program
Acct-Type
Auth-Failure-Trigger
Auth-Data
Auth-Type
Crypt-Password
Exec-Program-Wait
Exec-Program
Fall-Through
Group
Hint
Huntgroup-Name
Log-Mode-Mask
Login-Time
Match-Profile
Menu
Pam-Auth
Prefix
Proxy-Replied
Realm-Name
Replace-User-Name
Rewrite-Function
Scheme-Acct-Procedure
Scheme-Procedure
Simultaneous-Use
Strip-User-Name
Suffix
Termination-Menu
[Top] | [Contents] | [Index] | [ ? ] |
Introduction to Radius
2. Naming Conventions
3. How Radius Operates
4. How to Start the Daemon.
5. Radius Configuration Files
6. Request Comparison Methods
7. Authentication
8. Accounting
9. Logging
10. Problem Tracking
11. Extensions
12. Utility Programs
13. Client Package
14. Attribute List
15. Reporting Bugs
16. Where to Get Information about GNU Radius
How to Obtain Radius
Radius Glossary
Acknowledgements
17. New Configuration Approach (draft)
A. GNU Free Documentation License
Index
[Top] | [Contents] | [Index] | [ ? ] |
Button | Name | Go to | From 1.2.3 go to |
---|---|---|---|
[ < ] | Back | previous section in reading order | 1.2.2 |
[ > ] | Forward | next section in reading order | 1.2.4 |
[ << ] | FastBack | previous or up-and-previous section | 1.1 |
[ Up ] | Up | up section | 1.2 |
[ >> ] | FastForward | next or up-and-next section | 1.3 |
[Top] | Top | cover (top) of document | |
[Contents] | Contents | table of contents | |
[Index] | Index | concept index | |
[ ? ] | About | this page |