Re: Inserting and/or replacing reply attributes on a proxy request
Jarrod Sayers [EMAIL PROTECTED] wrote: 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. See the Calling-Station-Id attribute. As per the RFC's, it should contain MAC:SSID. Rather than accepting the user then trying to reject them some time later, just look at the SSID they're using. If it isn't correct, reject them. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Inserting and/or replacing reply attributes on a proxy request
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
-
Re: Inserting and/or replacing reply attributes on a proxy request
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
Re: Inserting and/or replacing reply attributes on a proxy request
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
Re: Inserting and/or replacing reply attributes on a proxy request
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
Re: Inserting and/or replacing reply attributes on a proxy request
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
Inserting and/or replacing reply attributes on a proxy request
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
Re: Inserting and/or replacing reply attributes on a proxy request
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
PGP.sig
Description: This is a digitally signed message part
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
