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/gnu-radius
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
675 Mass Ave, Cambridge, MA 02139, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and modification follow.
NO WARRANTY
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.
one line to give the program's name and an idea of what it does.
Copyright (C) 19yy name of author
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
type `show w'. This is free software, and you are welcome
to redistribute it under certain conditions; type `show c'
for details.
The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright
interest in the program `Gnomovision'
(which makes passes at compilers) written
by James Hacker.
signature of Ty Coon, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.
Radius is a system serving for authentication and accounting. The acronym RADIUS stands for Remote Authentication in Dial-In User Service and 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 administrator to implement any new method he deems convenient.
GNU Radius includes radius server program capable of serving authentication and accounting requests, and a set of accompanying programs designed to monitor the activity of the server and analyze the information it provides.
Throughout this document the following terms are used:
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
section Detailed Request Accounting.
The default locations of these directories are determined at compile time. By default these are:
| Directory | Short Name | Default location |
| Configuration directory | raddb | /usr/local/etc/raddb |
| Log directory | radlog | /var/log |
| Accounting directory | radacct | /var/log/radacct |
These location may differ depending on your local site configuration.
Throughout this document we will refer to these directories by their short names, e.g. saying
... this information is contained in file `raddb/sqlserver'
we actually mean `/usr/local/etc/raddb/sqlserver'.
If necessary, locations of these directories can be overridden by
specifying appropriate command line options to a program. For
example, any program from the GNU Radius package accepts command
line option -d or --directory, which introduces
the configuration directory path.
The main purpose of Radius is to centralize authentication of users coming from various network stations. Its primary usage is for dial-in users, though it can be used for any kind of network connection.
Radius uses the Client/Server model. The main server keeps the centralized user database. Each user's profile in this database determines which services are allowed for this particular user.
The Network Access Server (NAS in short) is a machine that actually provides a service for the user. It can do so, e.g. by running a pool of modems the users can connect to. Otherwise, it can be a machine connected to the network and allowing some form of remote access, like telnet or ssh. It can even be a workstation allowing console logins to it. Whichever service it provides the NAS sends the request to the central Radius server in order to determine whether the user trying to access the service is allowed to do so. Such request carries information about user's login name, password, NAS identifier (such as its IP address), etc.
On receiving such request Radius server retrieves from its database a profile corresponding to the user's login name. The profile basically consists of two parts: a checklist used for authentication and a reply list used for authorization. The server checks the authenticity of the user using first part of the retrieved profile. If this check succeeds, it uses second part of the profile to authorize the user, i.e. to determine which service he should be provided. Then, the server responds with the parameters of the service, such as connection speed, framed IP address, etc. If any of the described checks had failed, the server sends the negative response.
If the server needs some additional information in order to process the request, it asks the NAS to supply such information. Thus, for example, if the user is allowed to use several services, he can be asked which one of them he wishes to use, etc.
When NAS receives the positive authentication response, it initiates the connection.
The NAS can be configured to notify Radius server about such events as session start, session stop or changing some parameters during the session. It can also notify the server about other events, such as NAS shutdown or startup. This is called accounting and the radius server responsible for processing this information is called an accounting server.
The information the Radius requests carry is stored as a list of Attribute-Value pairs. Each pair consists of Attribute number and 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 the 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 section Dictionary of Attributes -- `raddb/dictionary'.
The attribute numbers range from 1 to 255. The attributes with the numbers greater than 255 are used internally by the sever and cannot be sent to the NAS.
The special attribute 26, Vendor-Specific, is available to allow vendors of the NAS hardware or software to support their own extended attributes. section Vendor-Specific.
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 additivity determines the
further actions:
The attributes are declared in `raddb/dictionary' file. For a detailed description of it, See section ATTRIBUTE statement. For information about particular attributes, See section Attribute List.
The term request means both the authentication/accounting request from NAS to a Radius server and the response that the server sends back to the NAS.
Each request contains the following fields
A NAS sends authentication requests (packets with code 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 any special services requested for that user.
An Access-Request must contain a User-Name attribute
section User-Name. It should contain either a NAS-IP-Address
attribute or NAS-Identifier attribute, or both of them.
It also must contain either a Password attribute or CHAP-Password
attribute. These attributes are passed 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 Access-Request packet for a particular user and authenticating that user, Radius server replies to the NAS that has sent the packet with either of the following packets:
Radius replies with Access-Accept packet when it has successfully authenticated the user. Such reply packet provides specific configuration information necessary to begin delivery of service to the user.
Radius replies with Access-Reject packet when it was unable to
authenticate the user. Such 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.
Radius replies with Access-Challenge packet when it desires to obtain more information from the user in order to determine its 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 may also include a single State attribute, or
none. No other Attributes are permitted in an Access-Challenge.
On 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. Radius discards invalid packets and issues 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
Reply-Message attributes of the request. It then sends its
original Access-Request with a new request ID and Request Authenticator,
with the Password attribute replaced by the encrypted user's
response, and including the State attribute from the
Access-Challenge, if any.
Accounting-Request packets are sent from a NAS to a Radius server to allow for accounting of a service provided to a user.
Upon receipt of an Accounting-Request, the server attempts to record the accounting packet section 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 an Accounting-Request packet:
Either NAS-IP-Address or NAS-Identifier must be present in an
Accounting-Request. It should contain a NAS-Port or
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 address of the user.
There are five types of accounting packets, which differ by the value of
Acct-Status-Type attribute. These are:
A record in the 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 radius configuration files keep data in a Matching Rule format: `hints', `huntgroups' and `users'. Although they keep data in similar format, the rules that are used to match incoming requests against contents of these files differ from file to file. The following section describes these rules in detail.
Upon receiving a request Radius 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 Logging).
The following checks are performed:
User-Name attribute it is not processed
Password attribute.
Proxying is a mode of operation when a radius server forwards an incoming requests from a NAS to another radius server, waits for the latter to reply, and 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 the ISPs to share their resources, allowing each other's users to connect to other party's equipment. Thus, users traveling outside the area of one ISP's coverage are still able to access their services through another ISP.
Suppose the ISP `Local' has a roaming arrangement with the
ISP `Remote'. When the user of `Remote' dials in
to the NAS of `Local', the NAS sends the authentication
request to `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 `Remote' radius
server for processing. Thus, `Local' radius acts as a client for
`Remote' radius. When `Remote' radius responds, the
`Local' receives the response, and passes it back to the NAS.
The copy of the request from the server's queue serves to determine
which NAS originated the request. Before passing the request
back to the NAS, radius removes from it the information,
specific for `Remote' site, such as Framed-IP-Address,
Framed-Netmask, etc. Only the attributes marked with
`propagate' flag (see section Attributes) are passed back to
the NAS. After removing site-specific attributes, `Local' radius
passes the request through its user profiles (see section User Profiles) to
insert any local site-specific information that might be
needed. Finally, it passes the reply back to the NAS.
The accounting requests are processed in the similar manner, except that no attribute filtering takes place, as the accounting responces do not carry any A/V pairs.
This example illustrates the simplest proxy chain, consisting of only two servers. The proxy chains may consist of several servers. In our example, the `Remote' radius server may also act as a proxy and forward the request to still another radius server, etc.
Note, that when the accounting request passes through a chain of forwarding servers, the accounting records are stored on all servers in the chain.
Radius server determines which server a request must be forwarded to by request's authentication realm. There are three kinds of realms:
GNU Radius keeps the information about the realms it serves in configuration file `raddb/realms' (see section List of Proxy Realms -- `raddb/realms').
User-name hints are special rules that modify the incoming request
depending on user name and his credentials. Hints are stored as a list
of Matching Rules (see section Matching Rule). Upon receiving a request,
radiusd scans the hints entries sequentially, comparing each
rule's Label with the value of User-Name attribute from
the request. If they coincide, then radiusd appends the contents
of the rule's RHS to the request pair-list.
Both user names must match exactly in order for a hint to
take effect, unless the hint's checklist contains either Prefix or
Suffix attribute. The special name `DEFAULT' or
`DEFAULT%d' (where %d denotes any decimal number), used as hint's
Label match any username.
The 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 radius to accept the
hint only if the username begins with the given prefix. Similarly,
Suffix instructs radius to accept the hint only if the username
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 current entry. This
allows for applying several hints to a single packet.
Rewrite-Function
Replace-User-Name
User-Name attribute from the request.
The hints rules are defined in `raddb/hints' file (see section Request Processing Hints -- `raddb/hints').
Huntgroups are special rules, that allow to alter processing of incoming
requests, depending on NAS IP address and port number they come
from. The rules are stored as a list of Matching Rules
(see section 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 meet 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 Huntgroup-Name).
The huntgroups rules are defined in `raddb/huntgroups' file (see section Huntgroups -- `raddb/huntgroups').
User Profiles are the per-user matching rules
(see section Matching Rule). Any incoming authentication request is compared
with the User Profiles after it has passed both Hints and
Huntgroups. Radiusd selects from the User Profiles
those rules, whose Label matches the value of 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
it must be one of special labels DEFAULT and BEGIN.
The rules in the authentication list are ordered as follows: first
go all the profiles with BEGIN label, they are followed
by the profiles, whose labels match the User-Name literally,
and, finally, these are followed by rules labeled with DEFAULT.
(1) Within each of the
three sub-lists the rules preserve the order in which they appear in
`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, then the authentication
fails. Otherwise, the contents of its RHS is appended to Reply
List being constructed. If the RHS of the matched rule contains 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.
The user profiles are defined in `raddb/users' file (see section User Profiles -- `raddb/users').
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 Run-Time Configuration Options -- `raddb/config').
The following command line options are accepted:
-A
--log-auth-detail
auth { detail yes; };.
-a DIR
--acct-directory DIR
option { acct-dir DIR; };.
-b
--dbm
usedbm yes;.
-d DIR
--config-directory DIR
--directory D
-f
--foreground
-i IP
--ip-address
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; };.
Please note, that listen statement in `raddb/config'
provides a better control over IP addresses to listen on (See section auth statement, and
see section acct statement).
-L
--license
-l DIR
--logging-directory DIR
option { log-dir DIR; };.
-mb
--mode b
-mc
--mode c
-mt
--mode t
radiusd starts an interactive interpreter
which allows to test various aspects of its configuration.
-n
--auth-only
-p PORTNO
--port PORTNO
-P DIR
--pid-file-dir DIR
-S
--log-stripped-names
auth { strip-names yes };.
-s
--single-process
-v
--version
-x DEBUG_LEVEL
--debug DEBUG_LEVEL
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. section Debugging
Config file equivalent:
logging {
category debug {
level DEBUG_LEVEL;
};
};
-y
--log-auth
logging { category auth { detail yes;
}; }; .
-z
--log-auth-pass
logging {
category auth {
print-pass yes;
};
};
See section Run-Time Configuration Options -- `raddb/config'.
This chapter describes the configuration files used by GNU Radius package.
These files 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 Naming Conventions.
radiusd uses the configuration values from the following
sources (in order of increasing precedence):
This order of precedence applies only on startup. When re-reading of
the configuration is initiated either by SIGHUP signal or by
SNMP channel any changes in the config file take
precedence over command line arguments, since `raddb/config' is
the only way to change configuration of the running program.
This chapter discusses the `raddb/config' file in detail.
The `raddb/config' consists of statements and comments. Statements end with a semicolon. Many statements contain a block of sub-statements which also terminate with a semicolon.
Comments can be written in shell, C, or C++ constructs, i.e. any of the following represent a valid comment:
# A shell comment
/* A C-style
* multi-line comment
*/
// A C++-style comment
These are the basic statements:
Option block: set the global program options.
option block
option {
[ source-ip number ; ]
[ max-requests number ; ]
[ exec-program-user string ; ]
[ username-chars string ; ]
[ log-dir string ; ]
[ acct-dir string ; ]
} ;
The option block defines the global options to be used by radiusd.
source-ip
max-requests
exec-program-user
Exec-Program and Exec-Program-Wait. The effective
group id will be retrieved from the `/etc/passwd' entry
for the given user.
username-chars
log-dir
acct-dir
logging block
logging {
[ 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 ; ]
}; ]
} ;
The logging statement describes the course followed by
radiusd's logging information.
category statement.
channel statement.
logging statement.
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, category_spec, can take any of the following three forms:
Additional category options valid for auth category are:
print-auth
print-pass
print-failed-pass
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 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
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;
};
};
auth statementSyntax:
auth {
[ listen addr-list ; ]
[ port number ; ]
[ spawn bool ; ]
[ max-requests number ; ]
[ time-to-live number ; ]
[ request-cleanup-delay number ; ]
[ detail bool ; ]
[ strip-names bool ; ]
[ checkrad-assume-logged bool ; ]
[ password-expire-warning number ; ]
} ;
The auth statement configures the parameters of the authentication
service.
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.
port
max-requests
time-to-live
request-cleanup-delay
password-expire-warning
spawn
radiusd should spawn a child to process the request.
detail
radiusd will produce the detailed log of each
received packet in the file `radacct/NASNAME/detail.auth'.
(see section Naming Conventions).
strip-names
radiusd should strip any prefixes/suffixes
off the username before logging.
checkrad-assume-logged
radiusd consults the value of this variable when the NAS
does not responds to checkrad queries (see section Checking Simultaneous Logins).
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.
acct statement
acct {
[ listen addr-list ; ]
[ port number ; ]
[ spawn bool ; ]
[ detail bool; ]
[ max-requests number ; ]
[ time-to-live number ; ]
[ request-cleanup-delay number ; ]
} ;
The acct statement configures the parameters of the accounting
service.
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.
port
max-requests
time-to-live
request-cleanup-delay
spawn
radiusd should spawn a child to process the request.
detail
false, disables detailed accounting
(see section Detailed Request Accounting).
proxy statement
proxy {
[ max-requests number ; ]
[ request-cleanup-delay number ; ]
} ;
The proxy statement configures the parameters of the proxy service.
max-requests
request-cleanup-delay
usedbm statement
usedbm ( yes | no ) ;
The usedbm statement determines whether the DBM support should
be enabled.
no
yes
snmp statement
snmp {
[ port portno ; ]
[ spawn bool ; ]
[ 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 ; ]
} ; ]
};
The snmp statement configures the SNMP service.
port
max-requests
time-to-live
request-cleanup-delay
spawn
radiusd should spawn a child to process the SNMP
request.
ident
community name ( rw | ro )
rw) or read-only
(ro).
network name network [ network ... ]
allow network_name community_name
deny NETWORK_NAME
guile statement
The guile statement allows to configure server interface with
Guile.
guile {
[ debug bool ; ]
[ load-path string ; ]
[ load string ; ]
};
debug
load-path
%load-path variable.
load
For the detailed description of Guile extensions interface, See section Guile.
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 Macro Substitution).
account-closed
password-expired
password-expire-warning
password-expire-warning variable in auth block.
See section 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
second-login
multiple-login, which is used when
the user's login limit is 1.
timespan-violation
The dictionary file `raddb/dictionary' defines the symbolic names for radius attributes and their values (see section 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
There are following kinds of statements:
Comments are introduced by a pound sign (`#'). Everything starting from the first occurrence of `#' up to the end of line is ignored.
$INCLUDE `filename'
The $INCLUDE statement causes the contents of the file `filename'
to be read in and processed. The file is looked up in the Radius database
directory. See section Radius Configuration Files.
VENDOR Vendor-Name number
A VENDOR statement defines the symbolic name for a Vendor-Id.
This name can subsequently be used in ATTRIBUTE statements
to define Vendor-Specific attribute translations. See section Vendor-Specific.
VENDOR Livingston 307
Syntax
ATTRIBUTE name number type [vendor [flags]]
The ATTRIBUTE statement defines the translation for an attribute.
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 assigns the translation string `Service-Type' to the
attribute number 6. It allows the use of this attribute 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.
VALUE Attribute-Translation Value-Translation number
The 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
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:
# 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
The `raddb/naslist' file contains a list of NASes known to the Radius server. Each record in the file consist of three fields:
radiusd determines
the way to query NAS about the presence of a given user on it
(see section Checking Simultaneous Logins).
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 NAS Types -- `raddb/nastypes').
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 Checking Simultaneous Logins). 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.
For the list of nas-querying arguments, See section NAS Types -- `raddb/nastypes'.
# 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
The `raddb/nastypes' file describes the ways to query NASes about active user sessions.
Each record consists of three fields separated by any amount of whitespace. The fields are:
Version 0.96 of GNU Radius supports two querying methods: finger and snmp.
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:
Please 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
The `nastypes' shipped with version 0.96 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
Please note the use of broken_pass flag. It is needed
for most MAX Ascend servers (see section 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.
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 Hints.
The file contains data in Matching Rule format (see section Matching Rule).
The only attributes that can be used in the check list are:
Suffix
Prefix
Group
User-ID
## 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
The `raddb/huntgroups' contains the definitions of the huntgroups. For a detailed description of huntgroup concept, See section Huntgroups.
The file contains data in Matching Rule format (see section Matching Rule).
## 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
The `raddb/realms' file lists remote Radius servers that are allowed to communicate with the local Radius server (see section Proxying).
Each record consists of up to three fields, separated by whitespace. Two of them are mandatory. The fields are:
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 flags meaningful in `raddb/realms' are
strip enables stripping, setting nostrip disables
it. Default is to always strip user names.
# Realm Remote server[:port] flags
#---------------- --------------------- --------
that.net radius.that.net nostrip
dom.ain server.dom.ain:3000 strip,quota=20
# Realm Remote server[:port] flags
#---------------- --------------------- --------
NOREALM radius.server.net
that.net radius.that.net nostrip
dom.ain server.dom.ain:3000 strip,quota=20
File `raddb/users' contains the list of User Profiles. For a description of its purpose, See section User Profiles.
## 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
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.
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.
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
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_max_connections bool
keepopen 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.
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.
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 LHS
(check) pair. Otherwise, it describes a RHS (reply) 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 |
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.
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
acct_max_connections number
keepopen is set to no.
Further, radiusd needs to know which information it is
to store into the database and when. Each of five accounting request
types (see section 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 statemens define the accounting queries:
acct_start_query string
INSERT statement
(see section 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.
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}'
The file `raddb/rewrite' contains definitions of Rewrite extension functions. For information regarding Rewrite extension language See section Rewrite.
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'.
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.
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:
He then enters `2'. The NAS sends the Access-Request packet to the server, which sees that user wishes to use option 2 and replies to the NAS with an Access-Accept packet containing the following attributes:
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"
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 "`{}' 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.
The substitition %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 substitition %C{attr-name:+retval} is expanded
to empty string if the attribute attr-name is present in the
referenced pairlist. Othervise it is expanded to retval.
You can also use the following shortcuts:
%p
%n
%f
%u
%c
%i
%t
%a
%s
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.
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,
Password != "",
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 non-empty password.
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 List of Blocked Users -- `raddb/access.deny').
This authentication type is used for each `users' entry, whose LHS contains
Auth-Type = Reject
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
To keep the plaintext passwords in `users' file, the profile entry must follow this pattern:
user-name Auth-Type = Local,
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 section Authentication Server Parameters.
The Encrypted Password type allows to keep user's passwords encrypted via DES or MD5 algorythm. There are two ways of using this authentication type.
user-name Auth-Type = Crypt-Local,
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 section 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.
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.
Setting Auth-Type = SQL or Auth-Type = Mysql
in the LHS of a `users' entry is a synonim 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 section Encrypted Password Authentication Type. The configuration of SQL subsystem is described in See section SQL Configuration -- `raddb/sqlserver'.
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
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 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 Authentication with Scheme.
The third way to implemement 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 Macro Substitution).
For a detailed description of Exec-Program-Wait attribute and
an example of its use, See section Exec-Program-Wait.
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 Simultaneous-Use). By default the number
of simultaneous sessions is unlimited.
When a user with limited number of simultaneous logins authenticates
himself, Radius first 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.
To determine the number of open sessions, Radius scans the
`radlog/radutmp' for any open entries marked with the
user's login name section UNIX Accounting. Such entries are created
when Radius receives an Accounting-Request packet with
Acct-Status-Type attribute set to Start. An entry is
marked closed when a corresponding Accounting-Request packet arrives with
Acct-Status-Type attribute set to Stop.
Since an open entry might be a result of missing Stop packet,
Radius queries the NAS whether the session listed in the entry is
currently active. If the NAS replies positive, the session count
is incremented, if it replies negative, such entry is marked as
closed 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 section auth statement.
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 NAS List -- `raddb/naslist'). If the NAS type is `true',
Radius acts as if the NAS returned 1, if the type is `false', it
acts as if the NAS returned 0, otherwise it looks up the entry
in the `nastypes' which has matching type (see section NAS Types -- `raddb/nastypes').
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 its arguments by appending
arguments from the `naslist' entry to those of nastypes
entry. Please 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 section Login Verification Functions.
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:
In this sequence, only UNIX Accounting is obligatory, all other methods are applied only when enabled.
If any accounting type in this sequence fails, the accounting is deemed to fail and all subsequent methods are not invoked.
This accounting method is always enabled.
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.
Radius stores the detailed information about accounting packets it receives
in files
`radacct/nasname/detail' (see section Naming Conventions),
where nasname is replaceed with the short name of the NAS from
the `raddb/naslist' file (see section NAS List -- `raddb/naslist').
By default, this accounting type is always enabled, provided that
`radacct' directory exists and is writable
(see section Naming Conventions). To turn the detailed accounting off,
use detail statement in `config' file. For more information
about it, See section acct statement.
The accounting detail files consist of a record per 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
The SQL accounting method is enabled when Radius is configured with
--enable-sql option and `sqlserver' file in its
configuration directory is properly set up (see section SQL Configuration -- `raddb/sqlserver').
This version of GNU Radius (0.96) supports MySQL and PostgreSQL servers. Support for Oracle servers will be added in the nearest future.
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 SQL Configuration -- `raddb/sqlserver').
If the built-in accounting methods do not meet your requirements, you can implement your own accounting methods. There are two ways for doing so:
To use a Guile procedure for accounting, the name of the procedure
must be specified as a value to Scheme-Acct-Procedure attribute
in 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 Accounting with Scheme.
Another way of implemementing 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 `hints' entry:
Acct-Ext-Program = "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 Macro Substitution).
For a detailed description of Acct-Ext-Program,
See section Acct-Ext-Program.
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;
in category auth statement of `config' file.
Proxy
Info
Notice
Warning
Error
CRIT
By default, all messages in all levels are output to 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 `raddb/config' file
(See section logging block, for the description of logging
statement syntax, see section Naming Conventions for information about the
locations of different radius configuration files).
GNU Radius provides extensive debugging features. These are enabled
either by -x command option to the radiusd
section How to Start the Daemon., or by level statement in debug category
section logging block. Both cases require as an argument
a valid debug specification.
A debug specification sets the module for which the debugging should be enabled and 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 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 a comma. 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, level 100 for
files.c, and 1 for config.y.
The modules and debugging levels are subject to change from release to release.
The use of extension language allows to extend 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.
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 Rewriting Incoming Requests). Beside this basic use, however, Rewrite functions are used in verifying the activity of user sessions (see section Checking Simultaneous Logins).
Rewrite syntax 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 exception are the A/V pairs from the incoming request,
which are accessible to Rewrite functions via special notation
%[attr].
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 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;
}
The function manipulates the contents of the incoming request, its return value has no special meaning.
A Rewrite function can be invoked in several ways, depending on its purpose. There are three major kinds of Rewrite functions:
The need of 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 just 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 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 further processing it. 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 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 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 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 Hints). For example, this `hints' rule will
cause the function to be invoked for each request containing the username
starting with `P':
DEFAULT Prefix = "P"
Rewrite-Function = "fixup"
Please 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 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 rewriting functions.
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 NAS-Port-Id attribute. The port number is constructed as
XYYZZ, where X = 1 for digital, X = 2 for analog, YY is line number
(1 for first PRI/T1/E1, 2 for second, so on), and ZZ = 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 port number can be used, for example, with
Add-Port-To-IP-Address attribute (see section Add-Port-To-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
`/' character. The part of Acct-Session-Id up to 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 the string in the form `ISDN 9:D:999'
(`9' represents a 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
normal Acct-Session-Id and attempts to generate
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.
* Please 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 username 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;
}
A login verification function is invoked to process the output from the
NAS. This process is described in section Checking Simultaneous Logins.
The function to be invoked for given NAS is defined by
function flag in `raddb/nastypes' or `raddb/naslist'
files (see section NAS Types -- `raddb/nastypes'). It must be defined as follows:
integer check(string str, string name, integer pid, string sid)
{
}
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, this is the received variable value
converted to its string representation.
The function should return non-0 if its arguments match user's session and 0 otherwise.
As an example, let's consider the function for analyzing a line line of output from a standard UNIX finger service. In each line of finger output the first field contains username, the third field --- tty number (Port ID), and the seventh field contains session ID. The function must return 1 if the three fields match the input user name, 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;
}
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 entire input line matches the user name.
integer
check_username(string str, string name, integer pid, string sid)
{
return str == name;
}
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 RHS in `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 IP address 10.10.10.1 as its
argument. An example of a useful function, that can be invoked this
way:
integer
get_ip_address(integer base)
{
return base + %[NAS-Port-Id] - %[NAS-Port-Id]/16;
}
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 the integer can always be coerced
to a string, the result of such coercion being the ASCII string with
decimal representation of the number.
A symbol is a lexical token. The following symbols are recognized:
Rewrite-Function attribute. It is kept as an associative array,
whose entries can be accessed using the following syntax:
`%[' attribute-name `]'
Thus notation returns the value of the attribute attribute-name.
attribute-name should be a valid Radius dictionary name
(see section Dictionary of Attributes -- `raddb/dictionary').
`\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. E.g.
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. Roughly, it is analogous to the system basename
utility.
A valid identifier is a string of characters meeting the following requirements:
The 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. Please note that, unlike in C, no assignments are allowed in variable declarations.
The Rewrite statements are: expressions, assignments, conditional statements and return statements. A statement is terminated by semicolon.
An expression is:
The type coercion is like a type cast in C. Its syntax is
`(' 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. |
An assignment is:
ident = expression ;
The variable ident is assigned the value of expression.
These take the form:
ident ( arg-list )
where ident is the identifier representing the function, arg-list is a comma-separated list of expressions supplying actual arguments to the function. The function ident references can be either a compiled function or a built-in function.
Please note that, unlike in C, the mismatch between the number of actual arguments and number of formal parameters in the compiled function declaration is not an error but rather a warning.
The following built-in functions are provided:
info. Returns 0.
The function is intended for debugging purposes.
All character positions in strings are counted from 0.
The name Guile stands for GNU's Ubiquitous Intelligent Language for Extensions. It provides the Scheme interpreter conforming to 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. Please, refer to section `Top' in Revised(4) Report on the Algorithmic Language Scheme, for the information about the language. If you wish to know more about the 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 Scheme-Procedure
attribute, the invocation for an accounting request is triggered
by Scheme-Acct-Procedure attribute. The following sections
address these issues in more detail.
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)
(Session-Timeout corresponds to attribute number 27).
Lists of A/V pairs are represented by Scheme lists. For example, the following Radius pair list
User-Name = "jsmith",
Password = "guessme",
NAS-IP-Address = 10.10.10.1,
NAS-Port-Id = 10
is written in Scheme as:
(list
(cons "User-Name" "jsmith")
(cons "Password" "guessme")
(cons "NAS-IP-Address" "10.10.10.1")
(cons "NAS-Port-Id" 10))
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.
If the function wishes 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. The 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 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 Scheme-Procedure attribute in RHS of a
corresponding `raddb/users' profile. E.g.:
DEFAULT Auth-Type = SQL
Scheme-Procedure = "auth"
The Scheme accounting procedure must be declared as follows:
The function must return a boolean value. The accounting succeeds only
if it returned #t.
Here is an example of 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)
#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:
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.
NAS-Port-Id attribute.
Calling-Station-Id attribute from the request.
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 address or corresponding network name.
When used with -l option, the long output format is used. In
this format the following information is output:
The following command line options can be used to modify the behavior of the program:
-A
--all
-c
--calling-id
-d NAME
--directory NAME
-D {short|abbr|full}
--date-formap {short|abbr|full}
DOW HH:MM, where DOW means the day of week abbreviation,
HH and MM mean hours and minutes respectively. This corresponds to
option -D short. Other available formats are:
Mon Dec 18 12:29:38 EET 2000
-e STRING
--empty STRING
radwho is fed to some analyzing program, as it helps to keep
the same number of columns on each line of output.
-F
--finger
radwho emulates the
behavior of fingerd(8) utility. Use this option if starting
radwho from the /etc/inetd.conf line like this:
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'.
-H
--no-header
-i
--session-id
-I {smart|ip|nodomain}
--ip-format {smart|ip|nodomain}
-u
--local-also
radwho as a finger daemon.
-n
--no-resolve
-o FORMAT
--format FORMAT
RADWHO_FORMAT.
The format string is a comma-separated list of format specifications
in one of the following forms:
login
orig
port
sid
nas
ip
proto
date
delay
type
ptype
| Type | Meaning |
| `L' | Local connection |
| `R' | Rlogin connection |
| `S' | SLIP connection |
| `C' | CSLIP connection |
| `P' | PPP connection |
| `A' | Auto PPP connection |
| `E' | Telnet session |
| `T' | "Clear TCP" connection |
| `U' | TCP login service |
| `!' | Console session |
| `X' | Shell |
time
clid
uname
-s
--secure
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, NAS short name and port number from where the
session was conducted, host IP address 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 specified the -l option, radlast produces long
output. It includes following fields:
Use following command line options to control the behavior of
radlast utility:
-number
-c number
--count number
radlast will output at most this many
lines of information.
-f
--file name
-h hostname
--host hostname
-n shortname
--nas shortname
-l
--long-format
-p number
--port number
radlast -p 3 or radlast -p S03.
-s
--show-seconds
-t
-p. This flag is provided for compatibility with last(1).
-w
--wide
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 -c option. This option is
always combined with the rest of command line by logical AND.
The pseudo-user `~reboot' logs in on every reboot of network access server.
If radlast is interrupted, it indicates to what date the search
was progressed.
The raduse utility shows the usage of dialup lines in the
realtime.
At the top of output the summary information is displayed. It consists of two lines. First line shows the statistic collection uptime and current date/time. Second line shows total number of lines, number of active lines, number of idle (inactive) lines and load percentage.
The dialup statistics is displayed in the area below. For each dialup line three lines of data are shown.
First line shows the network access server name, port number on that server, number of logins registered on this line, status of the line, amount of time the line keeps the current status, and date and time where the line has switched to the current status.
If the line is currently active, the status field displays login name of the user logged in on this line. If the line is inactive, the word `[Idle]' is displayed.
Second and third lines display active and idle usage summary. They show following data: total time the line is in the given state, maximum amount of time in this state, and starting date and time when maximum duration was perceived.
The example of default display:
uptime 90+20:35 Sun Dec 17 12:21
235 lines, 71 active, 164 idle. Pool load 0.30
max 001 2796 [idle] 00:05 Sun Dec 17 12:16
43+00:17 1+22:39 Fri Sep 22 18:04 - 16:44
47+20:22 06:25 Thu Oct 05 02:24 - 08:50
max 002 2877 [idle] 00:09 Sun Dec 17 12:11
41+06:56 10:55 Sat Oct 28 21:20 - 07:15
49+13:35 05:32 Mon Oct 02 00:33 - 06:05
max 003 3000 [idle] 00:08 Sun Dec 17 12:12
39+14:42 19:44 Thu Nov 02 14:52 - 10:36
50+11:22 07:29 Wed Oct 11 23:30 - 06:59
max 004 2829 jsmith 00:05 Sun Dec 17 12:15
41+21:11 1+00:04 Sun Sep 24 12:17 - 12:21
48+23:28 04:51 Sat Oct 07 03:42 - 08:33
max 005 2913 gray 00:41 Sun Dec 17 11:40
40+12:01 15:24 Mon Dec 11 19:18 - 10:43
50+08:03 11:58 Wed Nov 29 13:43 - 01:41
max 006 3014 roland 00:39 Sun Dec 17 11:41
42+02:10 22:28 Sun Sep 24 13:46 - 12:15
48+17:39 05:30 Fri Nov 24 01:57 - 07:28
max 007 2937 [idle] 00:06 Sun Dec 17 12:15
This default display can be altered using command line options or interactive commands
The following options modify the behavior of raduse:
-b
--brief
-d count
--display count
-D
--dump
-I
--no-idle-lines
raduse displays all dialup
lines.
-i
--interactive
-n
--no-interactive
-s num
--delay num
-w
--widen
-l
--list-nas
-h
--help
The following commands are understood when raduse is in
interactive mode. Some commands require an argument. Such commands
are followed by the word arg. When raduse gets such command
it displays a prompt and waits for user to enter the necessary data.
After processing each command the screen is updated immediately, no matter was the command understood or not.
radzap searches the Radius accounting database for matching login
records and closes them.
At least one of -n, -p options or username must be
specified. If they are used in conjunction, they are taken as if
joined by 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 matched the search conditions given.
In confirm mode `radzap' will ask for a confirmation before zapping each matching record. Every line beginning with a `y' is taken as positive response, otherwise it is taken as negative response.
The confirm mode is toggled by the command line option -c.
radzap [options] [username]
Options are:
-c
--confirm
-q
--quiet
-h
--help
-n NAME
--nas NAME
-p PORT
--port PORT
radzap -p S02 or in
its short form, like radzap -p 2.
This utility allows to quickly lookup 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-dash) sign. First subset is passed as command line to
radwho utility. The second one is passed to grep.
This utility is a shell program that determines the user's
framed IP address and runs ping on that address.
radping username
radping -c calling-station-id
The second way of invoking the program allows to use calling station ID in order to indicate the user.
The radauth utility sends the Radius server Access-Request
packet and displays the result it gets. It can be used to test the
configuration files. The usage is:
raduse [-v] username password
The -v or --verbose option forces radauth to be
verbose on output.
If you enter `.' (dot) instead of the password, the program will disable echoing on the screen, prompt you to enter the password, and turn the echoing on again, thus preventing the password from being compromised.
The program determines which Radius server to use, the authentication port number and shared secret following the procedure common for all client scripts (see section Client Configuration).
Radctl is a control interface to radiusd daemon. It allows
user running it to query radiusd about various aspects of its
work and issue administrative commands to it.
radctl -s 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 re-read 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.
status
radiusd reports its memory usage statistics. The information is
logged under Info log level.
which
radiusd.
Builddbm converts the plaintext Radius users database into
DBM files. Some versions of 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 entire plaintext database, converts it into internal form and stores into hash table which provides for fast access. Actually, using DBM version of the users database slows down the access unless the machine which runs Radius daemon is short of address space for the daemon to store the users database into.
When used without arguments, builddbm utility attempts to
convert file `raddb/users' into `raddb/users.db' or
`raddb/users.pag', `raddb/users.dir' pair, depending on the
version of DBM library used.
If used with one argument, the 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:
-d dir
-h
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. Please 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:
| ID-STR | Server ID, |
| HOST-STR | Server hostname or IP address, |
| SECRET-STR | Shared secret key to use, |
| AUTH-NUM | Authentication port number, |
| ACCT-NUM | Accounting port number, |
| CNTL-NUM | Control channel port number. |
Thus, each entry can be used as an argument to rad-client-set-server or rad-client-add-server.
| 0 | Authentication port, |
| 1 | Accounting port, |
| 2 | Control port. |
(cons ATTR-NAME-STR VALUE)
or
(cons ATTR-NUMBER VALUE)
Return:
On success
(list RETURN-CODE-NUMBER PAIR-LIST)
On failure:
'()
(list ID-STR HOST-STR SECRET-STR AUTH-NUM ACCT-NUM CNTL-NUM)
where:
| ID-STR | Server ID, |
| HOST-STR | Server hostname or IP address, |
| 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:
| ID-STR | Server ID, |
| HOST-STR | Server hostname or IP address, |
| SECRET-STR | Shared secret key to use, |
| AUTH-NUM | Authentication port number, |
| ACCT-NUM | Accounting port number, |
| CNTL-NUM | Control channel port number. |
(cons NAME-STR VALUE)
or
(cons ATTR-NUMBER VALUE)
where VALUE may be of any type appropriate for the given attribute.
(cons NAME-STR VALUE)
or
(cons ATTR-NUMBER VALUE)
where VALUE may be of any type appropriate for the given attribute.
All "Reply-Message" pairs from the list are concatenated and displayed as one.
rad-server-list print its ID and hostname
or IP address.
Beside the radius server and accompanying utilities, GNU Radius provides a set of utilities to be used as radius clients.
Following sections describe in detail the parts of the radius client package.
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 `#' introduces an end-of-line comment.
The source IP address is introduced with source_ip statement. Its
syntax is:
source_ip ip-addr
where ip-addr must be the IP address in "dotted-quad" notation.
The radius server where 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 any of them replies to the request.
The amount of time a client program waits for the reply from a
server is configured using timeout statement:
timepout 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 next available server. Number of retries is
set with retry statement:
retry number
The example of `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
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:
--auth
--start
--stop
Options determine the contents of the request's pairlist. They are:
-l STRING
--login STRING
-p STRING
--passwd STRING
-n IP
--nas IP
NAS-IP-Address attribute.
-s STRING
--sid STRING
Acct-Session-Id attribute).
-P NUMBER
--port NUMBER
NAS-Port-Id attribute).
-h
--help
-v
--verbose
nas.scm is a Guile program that allows 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
the 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
...
The 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
...
pam_radius.so is a PAM module for radius
authentication. The module understands following command line options:
audit
debug[=level]
use_authtok
confdir=path
service_type=type
Service-Type=type to the authentication request.
type must be a valid value, described in dictionary file.
pam_radius.so module logs its messages under LOG_AUTH
syslog facility.
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 value of N/A in any of this fields signifies "not applicable".
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.
| 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 username is usually limited by some arbitrary value.
By default, Radius supports usernames up to 32 characters long. This
value can be modified by redefining RUT_USERNAME macro in
include/radutmp.h file in the distribution directory and recompiling the
program.
Some NASes have peculiarities about sending long usernames. For example, Specialix Jetstream 8500 24 port access server inserts a `/' character after the 10th character if the username is longer than 10 characters. In such cases, we recommend to apply rewrite functions in order to bring username to its "normal" form (see section Rewrite functions -- `raddb/rewrite').
| Users: | L- |
| Hints: | -- |
| Huntgroups: | -- |
| Additivity: | N/A |
| Proxy propagated: | No |
This Password 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 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 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, to no more than 128 characters.
| 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.
| Users: | L- |
| Hints: | -R |
| Huntgroups: | LR |
| Additivity: | Append |
| Proxy propagated: | No |
This Attribute indicates the identifying IP address 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 NAS-IP-Address or NAS-Identifier attribute
section NAS-Identifier.
| Users: | LR |
| Hints: | -R |
| Huntgroups: | LR |
| Additivity: | Append |
| Proxy propagated: | No |
This attribute indicates the physical port number of the NAS which is authenticating the user. It is only used in Access-Request packets. Note that this is 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 MAX Ascend terminal server constructs
NAS-Port-Id concatenating line type (one-digit), line number
(two-digits), and the channel number (two-digits) thus producing
a 5-digit port number. In order to "normalize" such encoded
port numbers we recommend to use a rewrite function (see section Rewrite functions -- `raddb/rewrite').
A rewrite function for MAX Ascend servers is provided in the
distribution.
| 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 Framed-IP-Address) would
supply the IP address to be used.
Callback-Login-User
Callback-Framed-User
Outbound-User
Administrative-User
NAS-Prompt
Authenticate-Only
Call-Check
Callback-NAS-Prompt
| 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.
| 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 address.
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 address before replying. For example
Framed-IP-Address = 10.10.0.1+
Also section Add-Port-To-IP-Address.
| 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.
| 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.
| 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.
| 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.
| Users: | -R |
| Hints: | -- |
| Huntgroups: | -- |
| Additivity: | Append |
| Proxy propagated: | Yes |
This Attribute indicates text which 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 the
packet.
| 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.
| 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.
| 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.
| 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 of 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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 NAS-IP-Address.
| 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
which is authenticating the user. It can be used instead of or in
addition to the NAS-Port-Id section 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.
These are attributes the NAS sends along with accounting requests. These attributes can not be used in matching rules.
| 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.
| 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.)
| 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 the Acct-Status-Type is set to Stop.
| 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 the Acct-Status-Type is set to Stop.
| 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.
| 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.
| 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 the Acct-Status-Type is set to Stop.
| 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 the Acct-Status-Type is set to Stop.
| 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 the Acct-Status-Type is set to Stop.
| 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 the Acct- Status-Type is set to Stop.
These are attributes, used by GNU Radius during the processing of a request. They are never returned to NAS. Mostly, they are used in matching rules.
| 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 LHS of the user's profile. See section Authentication.
Radius interprets values of Auth-Type attribute as follows:
Local
Password attribute from the record is taken
as a cleantext password and is compared against the Password value
from the input packet.
System
Crypt-Local
Password attribute from the record is taken
as an MD5 hash on the user's password. Radius generates MD5 hash
on the supplied Password value and compares both strings.
Reject
Accept
SQL
Mysql
Mysql is an alias maintained for compatibility
with other versions of Radius.
Pam
| 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 0.96
of GNU Radius, this attribute may be used in conjunction with
SQL and Pam authentication types. When used with
Pam authentication type, this attribute holds the name
of 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 Authentication Server Parameters, for an example of
of using Auth-Data attribute in `raddb/sqlserver':
| 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
`RADIUS_DIR/menus/' directory (see section Login Menus -- `raddb/menus').
| 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 `RADIUS_DIR/menus/' directory
(see section Login Menus -- `raddb/menus').
| Users: | L- |
| Hints: | L- |
| Huntgroups: | LR |
| Additivity: | Append |
| Proxy propagated: | No |
The Prefix attribute indicates the prefix which the username
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 Prefix = "U", Auth-Type = System
Service-Type = Login-User
then usernames `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 username
contains both prefix and suffix specified.
section Suffix section Strip-User-Name
| Users: | L- |
| Hints: | L- |
| Huntgroups: | LR |
| Additivity: | Append |
| Proxy propagated: | No |
The Suffix attribute indicates the suffix which the username
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 usernames `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 username
contains both prefix and suffix specified.
section Prefix section Strip-User-Name
| Users: | L- |
| Hints: | L- |
| Huntgroups: | LR |
| Additivity: | Append |
| Proxy propagated: | No |
| 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 Auth-Type.
| Users: | L- |
| Hints: | -R |
| Huntgroups: | LR |
| Additivity: | Append |
| Proxy propagated: | No |
The Huntgroup-Name can be used either in LHS of the
`users' file record or in 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 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 contained the following attributes:
User-Name = "john",
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 would succeed since it contains
NAS-Port-Id attribute and its value is less than 32.
See section Huntgroups -- `raddb/huntgroups'.
| 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 surplus attempts to log in are rejected.
See section Checking Simultaneous Logins.
| 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 set to Yes the usernames would be logged and
accounted without any prefixes/suffixes.
A user may have several usernames for different kind of services. In this case differentiating the usernames by their prefixes and stripping them off before accounting would help keeping 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 SQL database logs in as `johns.ppp'. He then is provided the PPP service, and his PPP session is accounted under username `johns'. Later on, he logs in as `johns.slip'. In this case he is provided the SLIP service and again his session is accounted under his real username `johns'.
| 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 reply-list.
If its value is set to Yes in a particular record, it
indicates to Radius that it should continue looking up another records
even when this record 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 would add its RHS to the reply pairs for this request. The effect is, that if user `johns' authenticates successfully it 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
Please note that the attribute Fall-Through itself
is never returned to the NAS.
| Users: | -R |
| Hints: | -R |
| Huntgroups: | -- |
| Additivity: | Replace |
| Proxy propagated: | No |
VALUE Add-Port-To-IP-Address No 0
VALUE Add-Port-To-IP-Address Yes 1
If this attribute is present in the RHS and has the value
of Yes, then the value of NAS-Port-Id attribute from
the authentication request will be added to the value of
Framed-IP-Address attribute from the RHS, and
resulting value will be returned in Framed-IP-Address
attribute to the NAS.
This provides the simplest form of organizing IP address pools.
This attribute is implicitly added to the RHS when the
value of a Framed-IP-Address attribute ends with `+'
sign. For example the following:
Framed-IP-Address = 10.10.0.1+
is equivalent to
Framed-IP-Address = 10.10.0.1,
Add-Port-To-IP-Address = Yes
| Users: | -R |
| Hints: | -- |
| Huntgroups: | -- |
| Additivity: | Replace |
| Proxy propagated: | No |
When present in 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 Macro Substitution).
Before the execution of the program radiusd switches to
uid and gid of user daemon, group daemon. You can
override these defaults by setting variables exec-program-user
and exec-program-group in configuration file to proper values
section option block.
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 User-Name and Calling-Station-Id
attributes from the request pairs.
| Users: | -R |
| Hints: | -- |
| Huntgroups: | -- |
| Additivity: | Replace |
| Proxy propagated: | No |
When present in RHS, the Exec-Program-Wait 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 section Macro Substitution.
Before the execution of the program radiusd switches to
uid and gid of user daemon, group daemon. You can
override these defaults by setting variable exec-program-user
in configuration file to a proper value.
section option block.
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 non-zero 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 was 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 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.
| Users: | -- |
| Hints: | -R |
| Huntgroups: | -- |
| Additivity: | Replace |
| Proxy propagated: | N/A |
The Acct-Ext-Program attribute can be used in RHS of an
`raddb/hints' entry to specify the full path and attributes
of an external program to be executed for each accounting request.
The command line can reference any attributes from both check and reply pairlists using attribute macros (see section Macro Substitution).
Before the execution of the program radiusd switches to
uid and gid of user daemon, group daemon. You can
override these defaults by setting variables exec-program-user
and exec-program-group in configuration file to proper values
section option block.
The accounting program must exit with status 0 to indicate a successive accounting.
| Users: | L- |
| Hints: | -R |
| Huntgroups: | -R |
| Additivity: | Append |
| Proxy propagated: | No |
Use Hint attribute to specify additional matching criterium
depending on the hint (see section Request Processing Hints -- `raddb/hints').
Let the `hints' 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 username starts with `S'.
| 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.
| Users: | L- |
| Hints: | -- |
| Huntgroups: | -- |
| Additivity: | Append |
| Proxy propagated: | No |
The Login-Time attribute specifies the time range when the user
is allowed to log in. The attribute should be specified in LHS.
Format of the Login-Time string is the same as that of UUCP
time ranges. The following description of time range format is
adopted from the documentation for Taylor UUCP package:
A time string may be a list of simple time strings separated with a vertical bar `|' or a comma `,'.
Each simple time string must begin either with a day of week abbreviation (one of: `Su', `Mo', `Tu', `We', `Th', `Fr', or `Sa'), or `Wk' for any day between Monday and 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.
| 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 username from the incoming packet. The
Replace-User-Name can reference any attributes from both LHS
and RHS pairlists using attribute macros section Macro Substitution.
For example the following `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 usage of PPP service for username guest, coming from NAS
`11.10.10.11' with non-empty Calling-Station-Id attribute.
The string consisting of `#' character followed by
Calling-Station-Id value is appended to the username.
| 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
`hints' or `huntgroups' configuration files.
The corresponding function should be defined in `rewrite' as
integer name()
i.e. it should return integer value and should not take any arguments.
See section Rewrite functions -- `raddb/rewrite'. See section Request Processing Hints -- `raddb/hints'. See section Huntgroups -- `raddb/huntgroups'.
| 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 concatenating the RHS lists from both profiles. When used in 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 address 10.10.10.2, otherwise if he is coming from NAS
10.10.11.1 he is assigned IP address 10.10.11.2.
| Users: | -R |
| Hints: | -- |
| Huntgroups: | -- |
| Additivity: | Append |
| Proxy propagated: | N/A |
The Scheme-Procedure attribute is used to set the name
of Scheme authentication procedure. See section Authentication with Scheme, for
the information about how to write Scheme authentication procedures.
| Users: | -- |
| Hints: | -R |
| Huntgroups: | -- |
| Additivity: | Replace |
| Proxy propagated: | N/A |
The Scheme-Acct-Procedure attribute is used to set the name
of Scheme accounting procedure. See section Accounting with Scheme, for
the information about how to write Scheme accounting procedures.
| 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 OR'ed together
form a mask which is applied via XOR operation to the current log
mode. The value thus obtained is used as effective log mode.
| 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 to control which accounting methods
must be used for a given user or a group of users. In the absense
of this attribute, all currently enabled accounting types are used.
See section Accounting, for more information about accounting types.
It is possible you will encounter a bug in one of 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 [email protected]. Allow me a couple of days to answer.
The two places to look for any 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:
radlast, options
Jump to: $ - a - c - d - e - f - g - i - l - m - n - o - p - r - s - t - u - v
Jump to: a - c - g - h - i - l - m - n - r - s - u
logging statement
Jump to: % - a - d - i - l - r - s - u
Jump to: a - c - e - f - g - h - i - l - m - n - p - r - s - t - u - v
Jump to: a - b - c - d - e - g - h - i - l - m - n - p - r - s - u - w
raduse display
raduse, command line options
radwho, command line options
For compatibility with other implementations of radius, 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 reported by213.130.0.5
raduse, neither are they reflected in SNMP variables.
This document was generated on 26 December 2001 using the texi2html translator version 1.52.