Previous: Matching Rule, Up: How Radius Operates [Contents][Index]
Upon receiving a request, radiusd 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 Logging).
The following checks are performed:
If the packet lacks the User-Name attribute, it is not processed.
The source IP of the machine that sent the packet is looked up in the clients file (see Clients List — raddb/clients). If no match is found, the request is rejected.
Using the data from the packet and the shared key value from the
clients file, Radius computes the MD5 encryption key that will
be used to decrypt the value of the User-Password attribute.
User-name hints are special rules that modify the request depending on the user’s name and her credentials. These rules allow an administrator to divide users into distinct groups, each group having its own authentication and/or accounting methods. The user-name hints are stored in raddb/hints (see Request Processing Hints — raddb/hints).
Huntgroup rules allow an administrator to segregate incoming requests depending on the NAS and/or port number they came from. These rules are stored in raddb/huntgroups (see Huntgroups — raddb/huntgroups).
The requests pertaining to another realm are immediately forwarded to the remote RADIUS server for further processing. See Proxying, for the description of this process.
This step applies only to authentication requests.
Previous: Matching Rule, Up: How Radius Operates [Contents][Index]