Inserting and/or replacing reply attributes on a proxy request

[Jarrod Sayers]

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