AUTHFILE(5)AUTHFILE(5)NAMEauthfile - Merit AAA server realm to authentication-type
mapping file
SYNOPSIS
../raddb/authfile
DESCRIPTION
The authfile file resides in the Merit AAA server configu-
ration directory (named .../raddb somewhere). It contains
a list of realm names which the Merit AAA server uses to
authenticate incoming RADIUS requests with the user@realm
pattern as the user name (in the User-Name attribute of
RADIUS). Comments are indicated by leading pound sign
('#') characters. All such comment lines are ignored (as
are blank lines).
The file contains one line of information for each realm
entry. Each entry has several, white-space delimited
fields. The syntax of each entry is as follows:
<realm-name> [( <alias> [, <alias>])] [ -<proto-
col>] <type> [ <realm/DNS/file>] [ <filter-id>]
For example:
umich.edu AFS-KRB UMICH.EDU
umich
flatland.org FILE flatland
where the latter is only available with the Merit
ehnanced server license.
The <realm-name> is any appropriate symbol or name for the
realm to which the user "belongs." Note that this does
not have to be a Domain Name System (DNS) host name,
although it is highly recommended that the realm name
match a domain name so the user recognizes the user@realm
syntax which resembles their email address. A single,
final DEFAULT entry may be included in the file which
indicates how to handle authentication requests specifying
authenticating realms not found in this file. Usually, a
remote RADIUS server will handle these requests which this
server will relay to the remote server. A user is not
allowed to use the name DEFAULT as their actual realm
name. The NULL entry may be used to indicate how to han-
dle user names without an attached realm name.
There is also a "wild card" syntax, *.realm, which may be
included as the primary (non-alias) realm name on an entry
in the authfile. Its purpose is to provide a shorthand
way of indicating several related realms which are to be
handled by one entry (one authentication type) in the
15 May 1998 1
AUTHFILE(5)AUTHFILE(5)
authfile. For example, a company may have several
branches, eastern.foobah.com, western.foobah.com and cen-
tral.foobah.com, so that an entry *.foobah.com would
"match" all three of these realms. It is highly recom-
mended that any such wild card entry be listed toward the
end of the authfile. This allows for preceding, specific
entries to override the wild card entry.
The <alias> field is an optional, comma separated list of
realm names enclosed within parentheses. Each realm alias
is equivalent to the "main" realm name and may be provided
for user convenience or other purposes, such as to save
typing. Aliases are allowed on wild card entries and are
interpreted as meaning *.alias rather than alias.realm or
just alias.
The <protocol> field is one of -PW, -CHAP, or -DFLT. It
may be used to force the processing order of authfile
entries which would otherwise be identical.
Valid authentication <type>s include PASSWD, UNIX-PW, BSD-
AUTH, RADIUS, MIT-KRB, AFS-KRB, FILE, TACACS, TACPLUS, and
KCHAP. These authentication types are case insensitive.
The FILE and TACPLUS types are only available with the
Merit enhanced server license.
The PASSWD <type> is the same as the UNIX-PW <type>.
Either refers to authentication using the UNIX password
file (usually found in the /etc/passwd file). The Merit
AAA server checks to see if the <realm/DNS/file> field
contains the host identifier as returned by the host-
name(1) command or is blank, in either case the request is
handled as a local UNIX request.
The BSD-AUTH <type> refers to authentication using BSD
Authentication. The RADIUS class entry in the
/etc/login.conf file determines the available types of
authentication which may be used. When BSD Authentication
is being used the authentication style may be supplied by
appending it to the username with a colon (':') character,
for example:
user:style
The RADIUS <type> indicates the authentication is to be
performed by a remote RADIUS server. The authorization
Attribute/Value Pairs returned by the remote RADIUS server
are propagated back to the requesting RADIUS system. See
the dictionary(5) man page.
For the remaining <type>s, the entries in the
<realm/DNS/file> field depend on how the Merit AAA server
was configured. For servers built to use the Kerberos
model for authentication, these entries correspond to the
15 May 1998 2
AUTHFILE(5)AUTHFILE(5)
Kerberos realm name which helps select which Kerberos
server to contact for that realm. Note that the
/etc/krb.conf file must have valid entries for the various
supported Kerberos realms. For servers built to use the
FILE model, this field contains the "prefix" of a compound
file name: prefix <period> users (for example, flat-
land.users). The FILE type is only available with the
Merit enhanced server license.
The optional <filter-id>s are names of packet filters to
be returned to the requesting RADIUS system. This filter
name, if present, overrides any filter name a remote
RADIUS server may have set in its reply to this server.
The optional server strings, DEFAULT_RADIUS_SERVER and
DEFAULT_RADIUS_SERVER specify default server names to use
for Authentication-Type entries of type RADIUS or TACACS
and TACPLUS, respectively. Note that the second string
serves to identify both TACACS and TACACS+ servers. It is
felt that it is unlikely to need both TACACS client AATVs
(both of which need to point to different TACACS servers)
operating in one Merit AAA server simultaneously. These
strings override the corresponding C pre-processor #define
directives in the radius.h include file. Normally, these
two lines may be left commented out.
The authfile file is read by radiusd at startup and when-
ever a HUP signal is received by radiusd. The Merit 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. This file is
maintained by the system administrator using a text edi-
tor.
FILES
../raddb/authfile
../raddb/dictionary
../raddb/users
/etc/krb.conf
/etc/minostab
SEE ALSOhostname(1), signal(3), dictionary(5), users(5),
radiusd(8), radcheck(8), radpwtst(8)
15 May 1998 3