Hello Chuck - I would strongly encourage you to use a separate instance of Radiator for each port you are listening on.
This will be _much_ easier to set up and maintain. regards Hugh On 2 Feb 2011, at 16:33, Linuxchuck wrote: > 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 > [email protected] > http://www.open.com.au/mailman/listinfo/radiator NB: Have you read the reference manual ("doc/ref.html")? Have you searched the mailing list archive (www.open.com.au/archives/radiator)? Have you had a quick look on Google (www.google.com)? Have you included a copy of your configuration file (no secrets), together with a trace 4 debug showing what is happening? -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows, MacOS X. Includes support for reliable RADIUS transport (RadSec), and DIAMETER translation agent. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
