OpenRADIUS is a RADIUS server that runs on many variations of unix, and has
a number of interesting features:
Ability to get shared secrets, authentication information, policies and
user profiles from any available external data source;
Support for Unix password databases, including NIS/NIS+, Livingston-style
ASCII files, LDAP directories and SQL databases out of the box;
Fully customizeable authentication schemes and security policies, using
a built-in business rule language. This allows you to fully specify how
the server makes its decisions, based on any combination of internally and
externally available information;
Simple, scaleable and fully documented module interface. Modules may
supply data such as user information, and may also store data such as
logging and accounting.
Modules can be written in any language that supports ASCII or binary Unix
pipe I/O. They are pre-spawned and reused instead of executed for each
request, which preserves scaleability while still allowing the use of
simple external scripts. All external subprocesses are fully supervised by
the main server process and are automatically restarted if they crash.
The interface allows multiple module subprocesses to be started for
each data source, allowing modules to be single-threaded while retaining
support for multiple concurrent requests to the same data source. This
design also provides load balancing, transparent failover, scaleability
across multiple processors and connection pooling to backend databases;
Extremely flexible dictionary that can be made to support any type of
non-standard vendor-specific attribute, including multiple attributes
inside the same VSA, non-standard attribute IDs or length fields,
subfields, and much more;
Binds to a single or multiple IP addresses/network cards, and listen
on multiple ports;
Free to use, modify, and redistribute under the terms of the GNU General
If you have anywhere between 10 and ten million dialup users accessing
your network, you probably already use a RADIUS server to save you
from having to store and maintain their passwords and profiles on the
network access devices themselves.
OpenRADIUS has this exact same purpose. There are three things that
really distinguish it though:
its versatile interface to the outside world: this
allows you to talk to other RADIUS servers, to your existing Unix or NT user
databases, SQL databases, LDAP trees, or whatever type of database that you
write a client module for, in whatever programming language, and use the
retrieved information in any part of the decision-making process;
its flexibility in controlling that process and
defining user profiles, because its built-in expression language allows you
to define exactly how a request must be handled, from its reception to its
its powerful dictionary: it can be made to support
all types of vendor-specific attributes, whether they resemble standard
RADIUS attributes or not.
Many RADIUS servers support multiple types of backend databases. But
most will put big constraints on the way your database is layed out, or
are very limited in the types of information that may be retrieved
from external sources; in most cases only passwords and static profiles,
no RADIUS proxy targets, calling number restrictions, shared secrets, or
OpenRADIUS allows you to use external information for anything you
create a business rule for.
For example, if you only want to allow a type of users to use only a particular
set of access devices, and this list of NASes is available in any supported
database type or flat file format, you can easily write a business rule to
check if the IP address of the NAS that the user is trying to use occurs in
Of course you could do the same thing with the called phone number, port type,
time of day, or any other piece of information the server has available when an
access request comes in.
Better yet, it allows you to add new interface modules to talk to databases.
Using its open and simple module interface, you can get the business rules to
use any type of information that you can access using any programming language,
whether that is C, C++, Perl, Java, Awk, a Unix shell or whatever, as long as
it supports Unix pipe I/O.
Using external programs as interface modules does not come with the performance
hit you may expect, because they are only started once instead of being invoked
for every request, unlike other RADIUS servers do that support external scripts.
You can use the business rules described above not only to define
certain restrictions for certain users, but also to specify exactly what
information the server should put in its answer to the network access
In fact, the rules that you write govern all aspects of how requests are
handled, from their reception to their answering. And, because these rules have
external interfaces to your databases at their disposal, you can use their
information to define not only the server's answers, but almost every aspect of
the server's behaviour.
This means that you are in full control of the interface between your
databases and your network access devices. You define how OpenRADIUS
uses your databases to define the NASes operation.
Information from an external source can be used to determine what external
source is queried next. Or it can specify that the request should be left
unanswered. Or that the request should be logged somewhere. Anywhere, because
the external interfaces are bi-directional. Logging accounting information
also happens though the standard module interface.
That means that you can get your proxying destination tables from any type of
database. You can store your accounting information in any type of database.
You can keep track of who is logged in using a session database. You can have
your modules do on-line queries on your NASes to see if somebody is indeed
already logged in, before rejecting access.
If you're an ISP, and you're reselling ports on your access servers to
third parties whose users you can recognise by some prefix, suffix, or
a particular dialed number, you're probably already using a RADIUS proxy
of some kind.
Most proxies, have restrictions on how they decide upon their proxy
target, or are very inflexible if you want to specify what information
they forward to the remote server and what they accept in response.
With OpenRADIUS, you use your own business rules to decide when and
where to proxy to, and the extent to which you allow the remote server's
answer to define the response that's sent to the NAS.
The remote server may be chosen based on a part of the username, based
on the dialed phone number, or any other piece of information that's
available about a request. You can also get the IP addresses and shared
secrets for your remote server from any external source you like, so
that you can easily maintain these destinations.
Proxying can also be used for load balancing and to increase
availability: when you specify that a particular request is to be
proxied, you can specify multiple target servers.
This functionality is actually achieved by a RADIUS client module that
uses the standard module interface.
Many RADIUS users have come to know the annoying habits of vendors to
invent new ways to represent their information in RADIUS packets, even
when perfectly suitable encapsulation mechanisms already exist.
Sadly, RFC 2865 doesn't require the contents of the RADIUS vendor-
specific attribute (attribute 26) to contain the same fields as normal
attributes have to specify their attribute ID and length.
This has led to strange varieties like 2- and 4-octet attribute numbers,
length specifications that don't include the attribute- and length
fields, multiple vendor attributes inside one encapsulating attribute
Luckily, OpenRADIUS can receive and send all these types of attributes.
It even allows you take any part of the RADIUS packet, including fixed
fields such as the RADIUS Code and Authenticator, as standard attributes
for use in the business rules.