Inserting and/or replacing reply attributes on a proxy request
Peter Nixon
listuser at peternixon.net
Mon Oct 16 07:57:23 CEST 2006
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20061016/c71de2f6/attachment.pgp>
More information about the Freeradius-Users
mailing list