Inserting and/or replacing reply attributes on a proxy request

[Owen DeLong]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20061014/3d99d453/attachment.pgp>