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...
_______________________________________________
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
