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