 |
Index for
Section 5 |
|
 |
Alphabetical
listing for U |
|
 |
Bottom of
page |
|
USERS(5)
NAME
users - Interlink AAA Server user security and configuration file
SYNOPSIS
../raddb/users
DESCRIPTION
The users file resides in the Interlink AAA Server configuration directory
(named .../raddb somewhere). It contains a list of users on which the
Interlink AAA Server will perform authentication. Comments are indicated
by leading pound sign ('#') characters. All such comment lines are ignored
(as are blank lines).
The file contains one or more lines of information for each such user. The
first line of each entry consists of one or more fields:
<users-name> <check-item> [, <check-item>] ...
For example:
george Password = "foobar"
There are four special user names, DEFAULT, dumbuser, pppuser and slipuser,
which are used 1) as the default entry for user names which do not match
any previous entries, 2) to hold non-framed reply-items, 3) to hold PPP
reply-items, and 4) to hold SLIP reply-items, respectively. The latter
three entries allow a user to authenticate with the same account name for
any of the framed or non-framed protocols. The DEFAULT entry specifies how
user names, not explicitly matched above it in this file, are to be
authenticated.
Additional lines associated with the first line described above, but
beginning with leading whitespace, follow the first line and indicate the
(attribute/value pairs) reply-items to be passed back to the requesting
RADIUS client or server. These may include things like PPP configuration
values, the name of the host to which the user wishes to connect or an
optional packet filter name. attribute/value pair names must be defined in
the dictionary file.
These additional lines consist of one or more fields:
<whitespace> <reply-item>, [<reply-item>,] ...
For example:
<TAB> Framed-Protocol = PPP,
The right hand side of the above expression may contain a string, an
integer, a date, and so forth. See the dictionary(5) man page for a
complete list of the various types for the right hand side value. The
string and tagged string attributes require the value to be surrounded by
quotation marks. Either single or double quote characters may be used to
allow for nesting flexibility, but the outermost quotes must be a matching
pair.
The integer and tagged integer attributes may use the value names
associated with the given attribute from the dictionary file as is the case
in the above example. The tagged attributes have a small (less than 256),
positive, integer value attached to the beginning of the value itself, but
separated from the value with a colon (':') character.
String type values may contain special characters as well as characters
represented using hexadecimal and octal digits. See the following table
for the given syntax:
Character Description Hexadecimal
_________________________________________
\a bell or alarm 0x07
\b backspace 0x08
\f formfeed 0x0A
\n linefeed 0x0C
\r carriage return 0x0D
\t tab 0x09
\\ backslash 0x5C
\' single quote 0x27
\" double quote 0x22
\x hexadecimal -
\X hexadecimal -
\0 octal -
Note that the first line (of check-items) for each entry does NOT end with
a comma (',') character while the reply-item lines of each entry begin with
a TAB or space character and end with a comma character, except for the
final reply-item of each entry, which omits the trailing comma.
There are two types of check-items: regular check-items and deny-items. A
deny-item is a regular attribute (identical in all respects to a check-item
except that instead of using an equals ("=") character, you may specify
not-equals by using the two character ("!=") sequence). The deny-items are
used to reverse the sense of the authentication-time check from "must
match" this attribute to "must not match" this attribute. In other words,
a deny-item causes an Access-Request to be rejected if it matches an
attribute in the request. You may also configure a denial message as a
deny-item (all on the first line) as follows:
Deny-Message = "Access to this port is not allowed"
This string would be returned to the user in the Access-Reject as a Reply-
Message if any deny-item for this user caused a rejection. You may also
use the special string ("*") consisting of just the asterisk character as
follows:
Deny-Message = "*"
This provides a canned message indicating which deny-item triggered the
rejection:
"Access denied, <attribute> = <value>"
Vendor specific attributes may be specified as <vendor>:<attribute> in
place of normal check-item and reply-item attributes, for example:
Ascend:Ascend-Metric
The users file is optionally read into internal tables by radiusd at
startup and whenever a HUP signal is received by radiusd. The Interlink
AAA Server detects any out-of-date configuration files upon receipt of a
Status-Server (or Management-Poll) request and re-reads all the
configuration files. The users file may be converted into a dbm(3)
database by using the builddbm(8) utility. This feature and the
builddbm(8) utility are not formally supported in the Interlink AAA Server
and may no longer function. This file is maintained by the system
administrator using a text editor.
FILES
../raddb/dictionary the file describing the possible attribute/value pairs.
../raddb/users this file.
../raddb/vendors the file describing known vendor names and their IETF
assigned enterprise numbers.
SEE ALSO
dbm(3), signal(3), dictionary(5), vendors(5), builddbm(8), radiusd(8),
radcheck(8), radpwtst(8)
|
Index for
Section 5 |
|
|
Alphabetical
listing for U |
|
 |
Top of
page |
|