[RADIATOR] Large number and variety of NAS devices with HOTP, SQL Group Validation, and custom SQL Reply Attributes

[Linuxchuck]

Hello all,

I've done considerable searching and have a few gaps left to fill in my Radiator configuration.  I'm hoping the Radiator users out there can help me avoid re-inventing the wheel.

I'm currently evaluating Radiator as a replacement to our 3rd-party Active-Directory integrated Windows-based RADIUS solution.  The existing implementation I "inherited" is restrictive, inflexible, and does not scale well.  It works, but consumes entirely too much time to maintain, and has a tendency to crash.  I am hoping Radiator is able to provide a better solution that can ease some of these issues.

I am quite comfortable writing both PHP or Python scripts, but unfortunately have never written a single line of Perl code of my own.  I can probably write functional Perl, but am not comfortable enough with it to use my own code in a production environment.

Here is the scenario:

We manage literally hundreds of remote systems using RADIUS as our primary AAA method.  These systems include Cisco routers, switches, VPN Concentrators, ASA Firewalls, older PIX Firewalls, FortiGate appliances, Raritan KVM devices, APC KVM devices, WTI serial console and power switches, Uplogix appliances, RADIUS-enabled Apache web servers, ad infinitum.  I'm sure you get the idea.

It is also common for some of these devices to be added, moved, and removed dynamically per the customer's needs.  This means the only viable way to ensure we are always ready for an incoming Access-Request packet is to listen for them from every subnet we control.  Adding each and every individual device on a per-IP basis will be a very time-consuming process that will require continuous maintenance, and I need to find a way to save some time with this system.

I already have a system in place to discern between each category of NAS since we don't categorize them by source-IP.  Each NAS is configured to use a distinctive RADIUS server port.  For example, when our RADIUS server receives an access-request packet from one of our authorized subnets on port 50000, it uses that port to identify the client NAS as a Cisco Switch for the purposes of determining which attributes it should respond with.  If a request comes in on port 50001, the NAS is a router.  50002 means an ASA, and so-on and so-forth.

This brings me to my first question:  Can I get Radiator to perform the same attribute customization based on which port the request comes in on?
If not, what are my options?

We use OTP tokens (both HOTP and DigiPass) to provide customer and employee access.  The customers are given appropriately restricted portal access through the tokens.  The employees are given access to various respective company services, and if they are from the proper department (read "in the right AD group") are also given management permissions to the various infrastructure devices as well.

Some of the devices we utilize are quite sensitive to the RADIUS payload they *expect* to be sent in reply packets from the RADIUS server, and have a tendency to reject access when the reply contains attributes they have no use for.  This means the reply packets sent from the RADIUS server should only contain the reply attributes respective to each NAS.

I have built a MySQL database for storing all of the existing Active-Directory RADIUS groups, as well as an LDAP-based script to periodically update the database and keep it in sync with AD.  I would like to use this database to validate group membership for the requesting user, and assign the needed reply attributes for sending back to the NAS, then validate OTP authentication.

Is there a working example of this implementation I could use?  Or maybe even just a suggested configuration for it?

In this config, I can't check for appropriate group yet, because I am unsure how to pull the UDP port used for the incoming request.  Here is what I have so far.  It should successfully validate an existing user from the SUBSCRIBERS table of my database first, then push them through OTP authentication.  The pieces I am trying to figure out are group requirements for the NAS type, and implementing the appropriate reply attributes based on the combination of assigned group and NAS type.

<Realm DEFAULT>
        <AuthBy SQL>
                DBSource        dbi:mysql:radius
                DBUsername      *****
                DBAuth          *****
#                GroupMembershipQuery    SELECT groupname FROM v_usergroups WHERE username=%0 AND groupname=%1
                AuthColumnDef   0, Class, request
        </AuthBy>
        <AuthBy GROUP>
                AuthByPolicy            ContinueUntilAccept
                <AuthBy SQLHOTP>
                        DBSource        dbi:mysql:radius
                        DBUsername      *****
                        DBAuth          *****
                        ResyncWindow    50
                </AuthBy>
                <AuthBy SQLDIGIPASS>
                        DBSource        dbi:mysql:radius
                        DBUsername      *****
                        DBAuth          *****
                        AutoMPPEKeys
                </AuthBy>
        </AuthBy GROUP>
</Realm>

I'd greatly appreciate any suggestions, ideas, or insight into how I should proceed with this config.  I'd really love to validate Radiator as a solution to our needs.

Thanks in advance...