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.
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
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
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
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
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 - 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
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 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
--
Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Dear All, I want to integrate our billing code in freeradius. and i wants to make a code in c language with mysql database connectivity and i wants to make a so file also . Please help me. Thanks A. K. Anand Kumar Software Engineer(VoIP) --------------------------------- How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates.
anand kumar wrote:
Dear All,
I want to integrate our billing code in freeradius. and i wants to make a code in c language with mysql database connectivity and i wants to make a so file also . Please help me.
Thanks A. K.
Anand Kumar Software Engineer(VoIP)
Hi Anand, I'm not quite sure what you mean. Are you trying to get freeradius to deny authorization when a user meets certain billing-related criteria, eg: haven't paid their bill for x months, have used up all their pre-paid usage, etc? Or, are you trying to log accounting data into a database in some way that the rlm_sql accounting code doesn't already allow you to do? The standard approach is to simply use sql accounting, which will log accounting data to an SQL (MySQL, PostgreSQL, Oracle etc) database, then use billing software to generate bills based on the data in your accounting table, or a capture of that data at a particular instance, or something similar. If you have usage meters or other such software, you'd have those querying the accounting table. Did that help, or am I way off? Cheers, -- James Wakefield, Unix Administrator, Information Technology Services Division Deakin University, Geelong, Victoria 3217 Australia. Phone: 03 5227 8690 International: +61 3 5227 8690 Fax: 03 5227 8866 International: +61 3 5227 8866 E-mail: james.wakefield@deakin.edu.au Website: http://www.deakin.edu.au
HI, i want to configure the billing server(mysql database) with freeradius. Hi Anand, I'm not quite sure what you mean. Are you trying to get freeradius to deny authorization when a user meets certain billing-related criteria, eg: haven't paid their bill for x months, have used up all their pre-paid usage, etc? Or, are you trying to log accounting data into a database in some way that the rlm_sql accounting code doesn't already allow you to do? The standard approach is to simply use sql accounting, which will log accounting data to an SQL (MySQL, PostgreSQL, Oracle etc) database, then use billing software to generate bills based on the data in your accounting table, or a capture of that data at a particular instance, or something similar. If you have usage meters or other such software, you'd have those querying the accounting table. Did that help, or am I way off? Cheers, -- James Wakefield, Unix Administrator, Information Technology Services Division Deakin University, Geelong, Victoria 3217 Australia. Phone: 03 5227 8690 International: +61 3 5227 8690 Fax: 03 5227 8866 International: +61 3 5227 8866 E-mail: james.wakefield@deakin.edu.au Website: http://www.deakin.edu.au - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Anand Kumar Software Engineer(VoIP) --------------------------------- Get your email and more, right on the new Yahoo.com
anand kumar wrote:
HI,
i want to configure the billing server(mysql database) with freeradius.
Include sql in the accounting { } section towards the end of your radiusd.conf. If you're working with the default radiusd.conf, all you have to do is uncomment that line. Then configure sql.conf so that freeradius can connect to your MySQL server (username, password, database name) and so that the accounting queries match the schema on your billing server. -- James Wakefield, Unix Administrator, Information Technology Services Division Deakin University, Geelong, Victoria 3217 Australia. Phone: 03 5227 8690 International: +61 3 5227 8690 Fax: 03 5227 8866 International: +61 3 5227 8866 E-mail: james.wakefield@deakin.edu.au Website: http://www.deakin.edu.au
Jarrod Sayers <jarrod@netleader.com.au> 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
participants (6)
-
Alan DeKok -
anand kumar -
James Wakefield -
Jarrod Sayers -
Owen DeLong -
Peter Nixon