Inserting and/or replacing reply attributes on a proxy request

[Jarrod Sayers]

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