Inserting and/or replacing reply attributes on a proxy request

[Peter Nixon]

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