Inserting and/or replacing reply attributes on a proxy request

[Jarrod Sayers]

An example would be handy :)

Jarrod.

On Mon, 16 Oct 2006, Peter Nixon wrote:

> 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
>