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.
Go to the first, previous, next, last section, table of contents.