Yep. I use "attrs.pre-proxy" and "attrs" files to do what they say on the tin. (Strip unwanted pairs pre and post proxy) then I add back in the pairs I want with rewrite rule and/or module (Module order is important here). For example this lets me strip "Framed-IP-Address" and then add one from sqlippool.
Cheers Peter On Mon 16 Oct 2006 00:43, Jarrod Sayers wrote: > Thanks Peter, any tips on how you have done this? I'll look at > upgrading a development box to head today if it means I can resolve > this problem. > > Jarrod. > > On 16/10/2006, at 12:45 AM, Peter Nixon wrote: > > This is trivial to do on CVS head (We are using these features in > > production). > > 1.1.3 is pretty limited in this regard.. > > > > Cheers > > > > Peter > > > > On Sun 15 Oct 2006 15:23, Jarrod Sayers wrote: > >> The concept is close, but the effect I need is silently add or > >> replace > >> these attributes from any proxy reply. While I am slightly concerned > >> that a realm neighbor would have the power to alter what tunnel group > >> they land in, I am also concerned about proxy replies that come back > >> without those variables. Reason being is without those variables, > >> that username and realm pair can associate to any SSID where > >> FreeRADIUS is used to check their credentials. > >> > >> Picture Cisco Aironet 1200's with multiple SSID's, all pointing back > >> to a single instance of FreeRADIUS. The access point is relying on > >> the RADIUS reply to determine if the user should be moved to another > >> SSID and without it, assumes the one they are attempting to > >> connect to > >> is correct. > >> > >> Jarrod. > >> > >> On 15/10/2006, at 2:43 PM, Owen DeLong wrote: > >>> Seems to me that you need to know which RADIUS box you sent the > >>> proxy request > >>> to and which destinations it is allowed to return. Then, you should > >>> be able to map > >>> any responses which don't match those tuples to proxy-reject with an > >>> error > >>> indicating that the proxy returned nefarious content. > >>> > >>> Perhaps, however, I simply am not understanding the problem > >>> statement. > >>> > >>> Owen > >>> > >>> On Oct 14, 2006, at 9:59 PM, Jarrod Sayers wrote: > >>>> Hi, > >>>> > >>>> I have a FreeRADIUS 1.1.2 box which its only job in life is to > >>>> proxy requests based on realms, i.e., no local authentication is > >>>> done. One of the realms is internal to the organisation (lets call > >>>> that internal.org.com.au) and I trust the variables being returned, > >>>> however I have no control over one external realm (lets call that > >>>> some.other.org.net.au) and the default realm. The FreeRADIUS box > >>>> is used to proxy wireless requests which relies on the following > >>>> variables to dump users into their particular tunnel groups: > >>>> > >>>> Tunnel-Type:1 => VLAN > >>>> Tunnel-Medium-Type:1 => IEEE-802 > >>>> Tunnel-Private-Group-Id:1 => 1234 > >>>> > >>>> What I am trying to accomplish is to have replies from a certain > >>>> realm forced to be returned with set values either adding them in > >>>> if they are missing, or replacing them is they are not the same. > >>>> So, if the request is proxied to a trusted source then don't alter > >>>> the reply, though if its proxied to an external realm, force the > >>>> Tunnel-Private-Group-Id:1 attribute to be 1234, yet if its proxied > >>>> to the default realm, use 4321 instead. > >>>> > >>>> I had a go at this using the exec clause and had some success in > >>>> adding variables if they didn't exist in the reply, but it wouldn't > >>>> replace existing ones: > >>>> > >>>> modules { > >>>> ... > >>>> > >>>> exec vlan_assignment { > >>>> wait = yes > >>>> program = ${confdir}/vlan.sh > >>>> input_pairs = proxy-request > >>>> output_pairs = proxy-reply > >>>> packet_type = Access-Accept > >>>> } > >>>> } > >>>> > >>>> post-proxy { > >>>> vlan_assignment > >>>> ... > >>>> } > >>>> > >>>> The associated script that it ran: > >>>> > >>>> fruitbox# cat vlan.sh > >>>> #!/bin/sh > >>>> > >>>> # Set defaults. > >>>> TunnelType="VLAN" > >>>> TunnelMediumType="IEEE-802" > >>>> TunnelPrivateGroupId="200" > >>>> > >>>> # Only alter Wireless-802.11 requests. > >>>> if [ "${NAS_PORT_TYPE}" = "Wireless-802.11" -a "${REALM}" != > >>>> "internal.org.com.au" ]; then > >>>> # Determine VLAN to be used. > >>>> if [ "${REALM}" = "some.other.org.net.au" ]; then > >>>> # Force user into specific tunnel group. > >>>> TunnelPrivateGroupId="1234" > >>>> elif [ "${REALM}" = "DEFAULT" ]; then > >>>> # Force user into specific tunnel group. > >>>> TunnelPrivateGroupId="4321" > >>>> fi > >>>> > >>>> # Return actual VLAN assignment. > >>>> echo "Tunnel-Type:1 = ${TunnelType}" > >>>> echo "Tunnel-Medium-Type:1 = ${TunnelMediumType}" > >>>> echo "Tunnel-Private-Group-Id:1 = \"${TunnelPrivateGroupId}\"" > >>>> fi > >>>> > >>>> exit 0 > >>>> fruitbox# > >>>> > >>>> Allowing these variables to pass though from untrusted sources may > >>>> allow a user to be placed in another organisations tunnel group > >>>> which I cannot allow. > >>>> > >>>> Any help or ideas appreciated :) > >>>> > >>>> Jarrod. > >>>> -List info/subscribe/unsubscribe? See > >>>> http://www.freeradius.org/list/users.html > >>> > >>> - > >>> List info/subscribe/unsubscribe? See > >>> http://www.freeradius.org/list/users.html > >> > >> - > >> List info/subscribe/unsubscribe? See > >> http://www.freeradius.org/list/users.html > > > > -- > > > > Peter Nixon > > http://www.peternixon.net/ > > PGP Key: http://www.peternixon.net/public.asc > > - > > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ > > users.html > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
pgpxbPOoy6wCA.pgp
Description: PGP signature
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html