17.2 Deficiencies of Current Operation Model and Configuration Suite

The main deficiencies are inherited with the traditional configuration file suite. The rules for processing each request are split among three files, each of which is processed differently, despite of their external similarity. The administrator has to keep in mind a set of exotic rules when configuring the system(9). When matching incoming requests with configuration file entries (LHS, see section 3.3 Matching Rule), some attributes are taken verbatim, whereas others are used to control radiusd behavior and to pass additional data to other rules (see section 14.3 Radius Internal Attributes). The things become even more complicated when RADIUS realms come into play (see section 3.4.2.1 Proxy Service). Some attributes are meaningful only if used in a certain part of a certain configuration file rule.

So, while being a lot more flexible than the approach used by other RADIUS implementations, the current system is quite difficult to maintain.

Another deficiency is little control over actions executed on different events. For example, it is often asked how can one block a user account after a predefined number of authentication failures? Currently this can only be done by writing an external authentication procedure (either in Scheme, using Guile, or as a standalone executable, using Exec-Program-Wait). The proper solution would be to have a set of user-defined triggers for every RADIUS event (in this case, for authentication failure).

Another commonly asked question is how to make radiusd execute several SQL queries when processing a request. While GNU Radius is not supposed to compensate for deficiencies of some SQL implementations that do not allow for nested queries, such a feature could come quite handy.