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
