3.4 Processing Requests

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 section 9. Logging).

The following checks are performed:

Check if the username is supplied.

If the packet lacks the User-Name attribute, it is not processed.

Check if the NAS is allowed to speak.

The source IP of the machine that sent the packet is looked up in the `clients' file (see section 5.3 Clients List -- `raddb/clients'). If no match is found, the request is rejected.

Compute the encryption key.

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.

Process user-name hints.

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 section 5.6 Request Processing Hints -- `raddb/hints').

Process huntgroup rules.

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 section 5.7 Huntgroups -- `raddb/huntgroups').

Determine whether the request must be proxied to another RADIUS server.

The requests pertaining to another realm are immediately forwarded to the remote RADIUS server for further processing. See section 3.4.2 Proxying, for the description of this process.

Process individual user profiles

This step applies only to authentication requests.

3.4.1 Checking for Duplicate Requests
3.4.2 Proxying
3.4.3 Hints
3.4.4 Huntgroups
3.4.5 User Profiles