[RADIATOR] Loading configuration dynamically from SQL database

[Heikki Vatiainen]

On 04/07/2011 12:58 PM, Remco van Noorloos wrote:

Hello Remco,

> Today I installed an evaluation version of Radiator and I'm trying to
> configure it in a way that matches the procedure of our current
> RADIUS server.

Please see below for my comments and an example of one way of recreating
your setup with Radiator.

> What happens in the current environment with an incoming RADIUS
> Request is the following:
> 
> 1) 	A so-called 'Realm' is selected based on the username. It first
> searches for a record with the complete username (user at domain.ext).
> If this doesn't exist it uses the last portion of the username
> (everything after the '@'). The realm to select is in an SQL
> database. An SQL query is executed with the username as parameter to
> determine the realm. (Realms include realmRADIUS / realmLDAP /
> realmSQL, in fact the different authentication backends used).

With Radiator that would be two AuthBy SQL clauses with policy of
ContinueUntilAccept

AuthColumnDef with type of request would put the information about
authentication backend into the request object.

It is very common to use the request for a "scratch space" for various
bits of information collected during authentication. See this for an
example.

http://www.open.com.au/radiator/faq.html#140

After the AuthBys, if either was able to match the user, you would have
the backend information in the request object.

> 2) 	After the realm is determined, the user is authenticated based on
> attributes like NAS-Port-Type, Service-Type, Username and Password.
> For example, if the realmLDAP is selected the user is authenticated
> against an LDAP backend. The settings for the LDAP server to
> authenticate by is stored in the same SQL database. Again, an SQL
> query is used to retrieve the LDAP server, LDAP bind user, LDAP
> search filter (and so on) with parameters gathered from the RADIUS
> request. Also group membership check using LDAP is performed. The
> same method is used for the realmRADIUS (which uses a query to
> retrieve RADIUS server details like shared secret instead of LDAP
> server details). realmSQL uses an SQL database to authenticate with.

Here I would use AuthBy SQL followed by AuthBy LDAP2. The SQL AuthBy
pulls LDAP data from the database and AuthBy LDAP2 then uses the SQL
retrieved information with something like this:

AuthDN %{authdn-from-sql}
BaseDN %{basedn-from-sql}
...

Here the "attribute" authdn-from-sql can be anything. Those are just
example names.

> 3) 	After the user gets authenticated other SQL queries are run to
> generate RADIUS attributes which are added to the Access-Accept
> message.

Here again you would be using AuthBy SQL with AuthColumnDef of type
reply. The data from SQL is now added to the RADIUS reply message which
is later sent to the NAS.

> So, what am I looking for? I'd like to reproduce the scenario above
> in Radiator.

I think the above would resemble your current setup.

> - 	I haven't find a way to dynamically determine the Realm (or
> Handler?) to use based on the properties described in step 1.

You can use AuthBy HANDLER to dynamically choose a handler.

> -	If a realm/handler gets selected, I'd like to dynamically set the 
> properties to use (for example the LDAP server and filter) for that 
> specific request based on information from an SQL database. The way
> I see it at the moment is that I need to create Handlers for all
> LDAP servers / RADIUS servers and other domains. Since I'd like to
> get this information from the database where it is in now, I doubt it
> is a good idea to add all these Handlers to the config file. Is there
> a way to get this info from a database?

As I wrote above, you can use the request object for passing along
information from the previous steps to the subsequent AuthBys.

> I hope you can help me out with these question and I look forward
> hearing from you.

Below is a summary:
- data is pulled from SQL primary based on username then by realm
- SQL data is used to select the handler that does authentication
- after authentication SQL is used to fill in RADIUS reply attributes

Additional points:
- request object is used to carry information between the steps
- attributes added to request object need not to be from RADIUS dictionary
- different policies are used to either go through all AuthBys or just
choose the one that matches

For %{} notation see ref.pdf section "5.2 Special characters". You can
pull data from reply message too.

For examples of AuthBy SQL, LDAP2 and HANDLER, see goodies/ directory.
The directory has index in README file. See especially ldap.cfg, sql.cfg
and authhandler.cfg.


<AuthBy SQL>
    Identifier sql-check-username
    # Something similar for Identifier sql-check-realm
    AuthSelect SELECT ...
    AuthColumnDef 0, backend, request
    AuthColumnDef 1, backend-var-1, request
    ...
</AuthBy>

<AuthBy SQL>
    Identifier sql-add-reply-attributes
    AuthSelect SELECT ...
    AuthColumnDef 0, reply-attr-1, reply
    ...
</AuthBy>

<Handler>
    AuthByPolicy ContinueWhileAccept
    <AuthBy GROUP>
        AuthByPolicy ContinueUntilAccept
        AuthBy sql-check-username
        AuthBy sql-check-realm
    </AuthBy>
    <AuthBy HANDLER>
        HandlerId auth-user-%{backend}
    </AuthBy>
    AuthBy sql-add-reply-attributes
</Handler>

<Handler>
    Identifier auth-user-ldap
    <AuthBy LDAP2>
        BaseDn %{backend-var-1}
        ...
    </AuthBy>
</Handler>

<Handler>
    Identifier auth-user-sql
    <AuthBy SQL>
        DBSource %{backend-var-1}
        ...
    </AuthBy>
</Handler>

-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.