Splitting the password field in freeRADIUS

[Dan Geist]

I currently use SecurID as the auth back-end for a AAA system utilizing
Radius and TACACS+, both with the native linux PAM agent (as opposed to
integrating with the FUNK (now Juniper) daemon). 

I found it easier to troubleshoot if only native SecurID auth requests
were coming into the servers and only radius requests came into the
radius servers. It also simplifies the SecurID server administration and
configuration (if you're not familiar with its internals, there are a
lot of moving pieces already without adding additional listening
services).

As for combining the kerb/SID credentials, you may want to redirect all
your inbound radius auth requests to an external module (in perl for
example) that can chop the request in half and issue a PAM sequence for
each, etc. etc. then return the results to freeradius.

Dan


On Tue, 2007-01-23 at 16:04 -0500, Drumm, Daniel wrote:
> 
> As some of you may know, RSA SecurID servers now support RADIUS. The
> Auth Manager comes with the Funk RADIUS sever embedded into it, and
> supports a number of auth types, including EAP-OTP as well as the
> usual types such as CHAP.
> 
> Is it possible to front end this type of server with FreeRADIUS, so
> that NAS-Clients can send a tokencode prepended to, say, a Kerberos
> password - and have the FreeRADIUS server forward the first 6 digits
> of the field to the RSA server for tokencode validation - and the
> remaining charcters to another RADIUS server, one that front-ends a
> Kerberos system? Only when both fields return true is the
> authentication true.
> 
> Is this possible? I was looking at the various scripting options in
> radius.conf, and don't know of anyone who has done this. Or if it can
> be done. 
> 
> Thank you.
> 
> Dan.
> 
> 
> 
> # 
> #  Pre-accounting.  Decide which accounting type to use. 
> # 
> preacct { 
>         preprocess
> 
>         # 
>         #  Ensure that we have a semi-unique identifier for every 
>         #  request, and many NAS boxes are broken. 
>         acct_unique
> 
>         # 
>         #  Look for IPASS-style 'realm/', and if not found, look for 
>         #  '@realm', and decide whether or not to proxy, based on 
>         #  that. 
>         # 
>         #  Accounting requests are generally proxied to the same 
>         #  home server as authentication requests. 
> #       IPASS 
>         suffix 
> #       ntdomain
> 
>         # 
>         #  Read the 'acct_users' file 
>         files 
> }
> 
> plain text document attachment (ATT6015246.txt), "ATT6015246.txt"
> - 
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- 
Dan Geist | dan.geist at cox.com | (404) 269-6822
Cox Communications - Engineering Security