suggestions for multiple vlans in hundreds of switches
Hi, We'd like to use FR to assign users on our wired network to one of 30 different vlans on campus, based on an LDAP field. Currently, we are doing this with huntgroups. Namely, we create a huntgroup for the NAS (in our case, a network switch), and then in the users file, we put the following: DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == staff User-Name=`%{User-Name}`, Tunnel-Private-Group-Id=176, Tunnel-Type=VLAN, Fall-Through = no DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == student User-Name=`%{User-Name}`, Tunnel-Private-Group-Id=177, Tunnel-Type=VLAN, Fall-Through = no And so on...for other groups of user like faculty, admin, etc.. This seems to work. The issue is scale. I have would conceivably have to have a huntgroup definition in the huntgroups file for each NAS. And if I wanted 30 vlans, I'd have to have 30 definitions like the ones above in my users file for EACH one of my NAS's. I'm sure there's a simpler way of doing things that I'm missing. Any advice is appreciated. Thanks Matt mda@unb.ca
you could extend your ldap schema and add a field for the vlan a user should belong too. then all you would need is to query that field and propogate the variable. "Tunnel-Private-Group-Id=`%{private-vlan}`" On 4/19/07, Matt Ashfield <mda@unb.ca> wrote:
Hi,
We'd like to use FR to assign users on our wired network to one of 30 different vlans on campus, based on an LDAP field. Currently, we are doing this with huntgroups. Namely, we create a huntgroup for the NAS (in our case, a network switch), and then in the users file, we put the following:
DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == staff User-Name=`%{User-Name}`, Tunnel-Private-Group-Id=176, Tunnel-Type=VLAN, Fall-Through = no
DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == student User-Name=`%{User-Name}`, Tunnel-Private-Group-Id=177, Tunnel-Type=VLAN, Fall-Through = no And so on...for other groups of user like faculty, admin, etc..
This seems to work. The issue is scale. I have would conceivably have to have a huntgroup definition in the huntgroups file for each NAS. And if I wanted 30 vlans, I'd have to have 30 definitions like the ones above in my users file for EACH one of my NAS's.
I'm sure there's a simpler way of doing things that I'm missing. Any advice is appreciated.
Thanks
Matt mda@unb.ca
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I was afraid someone would say that! Haha Matt -----Original Message----- From: Donny Jekels [mailto:djekels@gmail.com] Sent: April 19, 2007 10:57 AM To: mda@unb.ca; FreeRadius users mailing list Subject: Re: suggestions for multiple vlans in hundreds of switches you could extend your ldap schema and add a field for the vlan a user should belong too. then all you would need is to query that field and propogate the variable. "Tunnel-Private-Group-Id=`%{private-vlan}`" On 4/19/07, Matt Ashfield <mda@unb.ca> wrote: Hi, We'd like to use FR to assign users on our wired network to one of 30 different vlans on campus, based on an LDAP field. Currently, we are doing this with huntgroups. Namely, we create a huntgroup for the NAS (in our case, a network switch), and then in the users file, we put the following: DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == staff User-Name=`%{User-Name}`, Tunnel-Private-Group-Id=176, Tunnel-Type=VLAN, Fall-Through = no DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == student User-Name=`%{User-Name}`, Tunnel-Private-Group-Id=177, Tunnel-Type=VLAN, Fall-Through = no And so on...for other groups of user like faculty, admin, etc.. This seems to work. The issue is scale. I have would conceivably have to have a huntgroup definition in the huntgroups file for each NAS. And if I wanted 30 vlans, I'd have to have 30 definitions like the ones above in my users file for EACH one of my NAS's. I'm sure there's a simpler way of doing things that I'm missing. Any advice is appreciated. Thanks Matt mda@unb.ca - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Matt, how about the configuration that you have to have in the switch???? Can you Help me???? Robinson robinson.a.s.santos@gmail.com On 4/19/07, Matt Ashfield <mda@unb.ca> wrote:
Hi,
We'd like to use FR to assign users on our wired network to one of 30 different vlans on campus, based on an LDAP field. Currently, we are doing this with huntgroups. Namely, we create a huntgroup for the NAS (in our case, a network switch), and then in the users file, we put the following:
DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == staff User-Name=`%{User-Name}`, Tunnel-Private-Group-Id=176, Tunnel-Type=VLAN, Fall-Through = no
DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == student User-Name=`%{User-Name}`, Tunnel-Private-Group-Id=177, Tunnel-Type=VLAN, Fall-Through = no And so on...for other groups of user like faculty, admin, etc..
This seems to work. The issue is scale. I have would conceivably have to have a huntgroup definition in the huntgroups file for each NAS. And if I wanted 30 vlans, I'd have to have 30 definitions like the ones above in my users file for EACH one of my NAS's.
I'm sure there's a simpler way of doing things that I'm missing. Any advice is appreciated.
Thanks
Matt mda@unb.ca
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Yeah, there's that too. We need to create these vlans within the edge switches as well. Once created, you shouldn't have to touch them again. Or you don't create them at the edge, and instead just create them in the core, however that kind of kills the advantage of extending your vlans to the edge. Matt Ashfield Network Analyst Integrated Technology Services University of New Brunswick (506) 447-3033 mda@unb.ca -----Original Message----- From: robinson santos [mailto:robinson.a.s.santos@gmail.com] Sent: April 19, 2007 12:31 PM To: mda@unb.ca; FreeRadius users mailing list Subject: Re: suggestions for multiple vlans in hundreds of switches Matt, how about the configuration that you have to have in the switch???? Can you Help me???? Robinson robinson.a.s.santos@gmail.com On 4/19/07, Matt Ashfield <mda@unb.ca> wrote: Hi, We'd like to use FR to assign users on our wired network to one of 30 different vlans on campus, based on an LDAP field. Currently, we are doing this with huntgroups. Namely, we create a huntgroup for the NAS (in our case, a network switch), and then in the users file, we put the following: DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == staff User-Name=`%{User-Name}`, Tunnel-Private-Group-Id=176, Tunnel-Type=VLAN, Fall-Through = no DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == student User-Name=`%{User-Name}`, Tunnel-Private-Group-Id=177, Tunnel-Type=VLAN, Fall-Through = no And so on...for other groups of user like faculty, admin, etc.. This seems to work. The issue is scale. I have would conceivably have to have a huntgroup definition in the huntgroups file for each NAS. And if I wanted 30 vlans, I'd have to have 30 definitions like the ones above in my users file for EACH one of my NAS's. I'm sure there's a simpler way of doing things that I'm missing. Any advice is appreciated. Thanks Matt mda@unb.ca - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
This seems to work. The issue is scale. I have would conceivably have to have a huntgroup definition in the huntgroups file for each NAS. And if I wanted 30 vlans, I'd have to have 30 definitions like the ones above in my users file for EACH one of my NAS's.
that would depend on what scale this would have to go to. certainly if each switch were to hav different VLANs for each of the types of users eg switch 1 vlan 200 for staff, vlan 201 for researchers switch 2 vlan 300 for staff, vlan 301 for researchers this woul dget very big very quickly. however, if each switch only needs to feed the same VLAN depending on the class of user - ie those 30 VLANs are are the same on each switch, then you can simply define a normal huntgroup for the switch eg in $place/raddb/huntgroup my-switches NAS-IP-Address == 231.123.241.123 my-switches NAS-IP-Address == 231.123.241.124 my-switches NAS-IP-Address == 231.123.241.125 my-switches NAS-IP-Address == 231.123.241.126 etc etc. then, in your example , the entry looks like DEFAULT Huntgroup-Name == my-switches, Ldap-Group == student User-Name=`%{User-Name}`, Tunnel-Private-Group-Id=177, Tunnel-Type=VLAN, Fall-Through = no (plus the others for each class of user) a 'clear scale' way would otherwise to be having an SQL table which defines each VLAN for each Ldap-group for each switch (or NAS) and use Perl or python to extract that info and return the attributes based on the request. alan
Matt Ashfield wrote:
Hi,
We'd like to use FR to assign users on our wired network to one of 30 different vlans on campus, based on an LDAP field. Currently, we are doing this with huntgroups. Namely, we create a huntgroup for the NAS (in our case, a network switch), and then in the users file, we put the following:
Credit to Alan DeKok for this idea - it was one of the first questions I asked on the list. Use two rlm_passwd modules to add "fake" items to the *request*: passwd nas2building { file = /etc/raddb/nas2building format = "*NAS-IP-Address:~MyBuilding" hashsize = 100 } passwd user2vlantype { file = /etc/raddb/user2vlantype format = "*User-Name:~MyVlanType" hashsize = 100 allowmultiplekeys = yes } ...then in the users file you reduce NxM to AxB which is a hopefully smaller combination: DEFAULT MyBuilding == "facility1", MyVlanType == "guests" ... DEFAULT MyBuilding == "facility1", MyVlanType == "staff" ... Note that if you're caching the files, FreeRadius will need to be HUPed to re-read them (boo!). Also, you'll need to add the MyXXX attributes to the dictionary like so: ATTRIBUTE MyBuilding 3000 string ATTRIBUTE MyVlanType 3001 string This could also be done cleaner (but slower) with cleverly designed SQL tables or stored procedures
Phil Mayers wrote:
Matt Ashfield wrote:
Hi,
We'd like to use FR to assign users on our wired network to one of 30 different vlans on campus, based on an LDAP field. Currently, we are doing this with huntgroups. Namely, we create a huntgroup for the NAS (in our case, a network switch), and then in the users file, we put the following:
Credit to Alan DeKok for this idea - it was one of the first questions I asked on the list.
Use two rlm_passwd modules to add "fake" items to the *request*:
passwd nas2building { file = /etc/raddb/nas2building format = "*NAS-IP-Address:~MyBuilding" hashsize = 100 } passwd user2vlantype { file = /etc/raddb/user2vlantype format = "*User-Name:~MyVlanType" hashsize = 100 allowmultiplekeys = yes }
...then in the users file you reduce NxM to AxB which is a hopefully smaller combination:
DEFAULT MyBuilding == "facility1", MyVlanType == "guests" ... DEFAULT MyBuilding == "facility1", MyVlanType == "staff" ...
Note that if you're caching the files, FreeRadius will need to be HUPed to re-read them (boo!). Also, you'll need to add the MyXXX attributes to the dictionary like so:
ATTRIBUTE MyBuilding 3000 string ATTRIBUTE MyVlanType 3001 string
This could also be done cleaner (but slower) with cleverly designed SQL tables or stored procedures
Yeah, complex sql really can be quite slow, specially when the queries are being run multiple times for all the rounds required in eap authentication.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I use a second instance of preprocess to read a second hints file called 'nas_hints' this uses dynamic sql queries to grab extra nas_attributes from the server. I actually use a really quick and dirty way of getting multiple values from a very simple query. You store multiple bool vars as a binary string representation of a 6 digit integer... can then use pattern matching in group check items to select required values and values you dont care about. authorization { nas_hints } preprocess nas_hints { hints = ${confdir}/nas_hints } Here is my nas_hints file ############################################################# # Should speed things up when proxying peap to itself DEFAULT Packet-Src-IP-Address == localhost ############################################################# # Set the 'PROXY' flag in the feature set for the JRS proxies DEFAULT Packet-Src-IP-Address == roaming0.ja.net NAS-Feature-Set = '00000100100000000000' DEFAULT Packet-Src-IP-Address == roaming1.ja.net NAS-Feature-Set = '00000100100000000000' DEFAULT Packet-Src-IP-Address == roaming2.ja.net NAS-Feature-Set = '00000100100000000000' ############################################################# # Debug entry for home testing. #DEFAULT Packet-Src-IP-Address == arr-land.co.uk # NAS-Feature-Set = '00000100100000000000' ############################################################# # Retrieve the feature set for all none recognised clients # from the NetReg3 Database # Note: Doing the initial pattern match is a far quicker was of doing things # rather than concatinating the db columns and comparing with client ip ! DEFAULT Packet-Src-IP-Address =~ "^([0-9]+)[.]([0-9]+)[.]([0-9]+)[.]([0-9]+)$" NAS-Feature-Set = "SELECT EXPORT_SET(master.nas_flags,'1','0','',20) FROM `master` WHERE ip1 = '%{1}' AND ip2 = '%{2}' AND ip3 = '%{3}' AND ip4 = '%{4}' LIMIT 0,1" Heres some group examples... SQL result *Host:* localhost *Database:* radius *Generation Time:* Apr 20, 2007 at 10:20 PM *Generated by:* phpMyAdmin 2.9.2 / MySQL 4.1.10a-standard-log *SQL query:* SELECT * FROM `radgroupcheck` LIMIT 0, 30 ; *Rows:* 5 id GroupName Attribute op Value 1 nas_admins Service-Type <= NAS-Prompt-User 2 nas_admins Service-Type >= Administrative-User 3 nas_operators Service-Type == NAS-Prompt-User 20 jrs_offsite_ao Huntgroup-Name == jrs-proxy 19 jrs_offsite_ao NAS-Feature-Set =~ 00000100100000000000 Heres a fun little php script to take a list of features and produce a bit string or integer value. #!/usr/local/php/bin/php <?php if(isset($argv[1])){ if(!isset($argv[2]) ){$argv[2] = false;} echo calc_nas_features($argv[1],$argv[2],20)."\n"; }else{ echo "/* Authentication Mediums */ '802.1', # 802.1 (Wired LAN) '802.11', # 802.11 (Wireless LAN) 'IPSEC', # IPSEC (VPN) 'SSH', # Secure Shell/Nas Prompt Login 'HTTPS', # Captive Portal/Nas Web Interface 'PROXY', # Client Isn't a NAS it's an offsite Proxy 'unused', # For future use 'unused', # For future use /* Extended Features */ 'RADACCT',# NAS Can do RADIUS Accounting 'D802.Q', # NAS Can do Dynamic Vlan Assignment 'MULTIBESSID'); # NAS Can have multiple SSIDs / BSSIDs "; } function calc_nas_features($flags,$dec = true,$pad_to = null){ $def = array('802.1', '802.11', 'IPSEC', 'SSH', 'HTTPS', 'PROXY', 'unused', 'unused', 'RADACCT', 'D802.Q','MULTIBESSID'); return calc_feature_bm(explode(',',strtoupper($flags)),$def,$dec,$pad_to); } /** * Convert feature flags to base10/Little Endian binary representation * * * @param string $flags * @param string $flags_def * * @return string */ function calc_feature_bm($flags = array(),$flags_def = array(),$dec_out = true,$pad_to = null){ $def_flags = array_flip($flags_def); # Use arrays value as key, and posistion as BIT posistion. if((!$pad_to) || (count($flags_def) > $pad_to)){ $bit_array = array_fill(0,count($flags_def),0);# Create an array equal to the maximum amount of possible flgs }else{ $bit_array = array_fill(0,$pad_to,0);# Create an array equal to pad value, if created than maximum flags } foreach($flags as $value){ # For each of the flags, see if it's value matches one of the keys if(key_exists($value,$def_flags)){ # If it does then set that BIT to true $bit_array[$def_flags[$value]] = 1; }else{ # If it doesn't warn the user trigger_error('Flag not found in flag definitions.',E_USER_NOTICE); } } $bin = implode('',array_reverse($bit_array)); if($dec_out == true){ return bindec($bin); }else{ return implode('',$bit_array); } } ?> If someone actually wants to do it this way, i'll put together some proper functions for generating the bit strings and stuff...
Arran Cudbard-Bell wrote:
Yeah, complex sql really can be quite slow, specially when the queries are being run multiple times for all the rounds required in eap authentication.
If you're using the TLS variants of EAP, you can do: DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Autz-Type := "internal" Then in the "authorize" section, add: ... Autz-Type internal { ... do DB lookups here } If you're doing password lookups in LDAP, put "ldap" in that section. Then, the LDAP lookups will only be done when they're needed. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Yeah, complex sql really can be quite slow, specially when the queries are being run multiple times for all the rounds required in eap authentication.
If you're using the TLS variants of EAP, you can do:
DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Autz-Type := "internal"
Then in the "authorize" section, add:
... Autz-Type internal { ... do DB lookups here }
If you're doing password lookups in LDAP, put "ldap" in that section. Then, the LDAP lookups will only be done when they're needed.
Yeees, and have a similar one checking for the existence of User-Password attribute and settings the Autz-Type to LDAP ! Wow this is going to speed stuff up so much ! Thankyou :) Ahh yes, I just got how this could work... because to deal with the contents of the eap tunnel freeradius proxies it to itself... And though your only writing the reply attributes to the tunnel , when the tunneled request comes back, the attributes will be used in the main packet sent back to the NAS, including the eap message from the proxied request ... Is the proxying to self new behaviour ? I know the Authz-Type and Auth-Type stuff is only in CVS so you must not have been able to do it in 1.1* ?
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
Arran Cudbard-Bell wrote:
Wow this is going to speed stuff up so much !
We use this trick extensively. It works really well.
Ahh yes, I just got how this could work... because to deal with the contents of the eap tunnel freeradius proxies it to itself...
Yes. And if you set "copy_request_to_tunnel = yes" the attributes from the real packet get copied to the tunneled one - e.g. NAS-IP-Address, NAS-Port, etc. so you can still act on those attributes.
And though your only writing the reply attributes to the tunnel , when the tunneled request comes back, the attributes will be used in the main packet sent back to the NAS, including the eap message from the proxied request ...
Provided you have "use_tunneled_reply = yes"
Is the proxying to self new behaviour ?
No
I know the Authz-Type and Auth-Type stuff is only in CVS so you must not have been able to do it in 1.1* ?
Erm, no. They've been around a long time.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Yeah, complex sql really can be quite slow, specially when the queries are being run multiple times for all the rounds required in eap authentication.
If you're using the TLS variants of EAP, you can do:
Except if you're using plain EAP-TLS where there's no inner tunnel IIRC? I have wondered where it might be sensible to fake a PAP request with the certificate details for EAP-TLS. This would provide (I think) quite a good way for people to do certificate checking and logging etc. User-Name = "theCN" User-Password = "theCN" FreeRADIUS-Cert-Subject = "cn=theCN,o=Foo,c=GB" FreeRadius-Cert-Issuer = "ou=ICT,o=Foo,c=GB" FreeRADIUS-SubjectAltName = "email:theCN@foo.co.uk" FreeRADIUS-SubjectAltName = "email:forname.surname@foo.co.uk" ..etc.
Phil Mayers wrote:
Except if you're using plain EAP-TLS where there's no inner tunnel IIRC?
Yes.
I have wondered where it might be sensible to fake a PAP request with the certificate details for EAP-TLS. This would provide (I think) quite a good way for people to do certificate checking and logging etc.
It's not a bad idea. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Arran Cudbard-Bell wrote:
This could also be done cleaner (but slower) with cleverly designed SQL tables or stored procedures
Yeah, complex sql really can be quite slow, specially when the queries are being run multiple times for all the rounds required in eap authentication.
You've seen Alans hint re: only running on the tunnel so that helps there.
I use a second instance of preprocess to read a second hints file called 'nas_hints' this uses dynamic sql queries to grab extra nas_attributes from the server.
That's a clever trick. One of the main advantages of the rlm_passwd module is that it can add items to the *request* as well as the config and reply items. It would be extremely handy if the SQL module could do this too. Specifically I can think of uses for 2-pass SQL queries where one would want to use data returned from the 1st query in the 2nd. This is basically impossible to do without using stored procedures at the moment. Regarding your bitmask trick - maybe there's a use for bitwise operators, e.g.: # NAS-Features - integer bitfield # 128 - router, admins only # 64 - do vlan assignment # 32 - do IP assignment DEFAULT NAS-Features & 128, SQL-Group != "ADMINS", Auth-Type := Reject Reply-Message = "admins only" DEFAULT NAS-Features & 64 Tunnel-Private-Group-Id = `%{sql:select vlan('%{NAS-IP-Address}', '%{User-Name}')}` Fall-Through = Yes DEFAULT NAS-Features & 32, Pool-Name := "something" ...and so on
Phil Mayers wrote:
Arran Cudbard-Bell wrote:
This could also be done cleaner (but slower) with cleverly designed SQL tables or stored procedures
Yeah, complex sql really can be quite slow, specially when the queries are being run multiple times for all the rounds required in eap authentication.
You've seen Alans hint re: only running on the tunnel so that helps there.
I use a second instance of preprocess to read a second hints file called 'nas_hints' this uses dynamic sql queries to grab extra nas_attributes from the server.
That's a clever trick.
One of the main advantages of the rlm_passwd module is that it can add items to the *request* as well as the config and reply items. It would be extremely handy if the SQL module could do this too.
Specifically I can think of uses for 2-pass SQL queries where one would want to use data returned from the 1st query in the 2nd. This is basically impossible to do without using stored procedures at the moment.
Regarding your bitmask trick - maybe there's a use for bitwise operators, e.g.:
# NAS-Features - integer bitfield # 128 - router, admins only # 64 - do vlan assignment # 32 - do IP assignment
DEFAULT NAS-Features & 128, SQL-Group != "ADMINS", Auth-Type := Reject Reply-Message = "admins only"
DEFAULT NAS-Features & 64 Tunnel-Private-Group-Id = `%{sql:select vlan('%{NAS-IP-Address}', '%{User-Name}')}` Fall-Through = Yes
DEFAULT NAS-Features & 32, Pool-Name := "something"
...and so on - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Yes !!! I didn't know freeradius supported bitwise operators ! They're not listed anywhere so I assumed you couldn't use them ?! Ohh this makes things so much neater :) Thanks Phil
Hi, Just wondering if theres any way of checking the existence of User-Password in users... =* ANY always matches even if User-Password attribute isn't in the request.. which is not the correct behaviour. Thanks, Arran
Arran Cudbard-Bell wrote:
Just wondering if theres any way of checking the existence of User-Password in users... =* ANY always matches even if User-Password attribute isn't in the request.. which is not the correct behaviour.
That was done historically because the server didn't have Cleartext-Password. Now that it does, I think that should be fixed in 1.1.7. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Just wondering if theres any way of checking the existence of User-Password in users... =* ANY always matches even if User-Password attribute isn't in the request.. which is not the correct behaviour.
That was done historically because the server didn't have Cleartext-Password. Now that it does, I think that should be fixed in 1.1.7.
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
And cvs head ? :) Could the check_val module be used in the mean time ? I was just looking to implement your trick with the authz sections, unfortunately I also need to support ClearText passwords for administrative logins to the switches... so I needed to check the existence of a User-Password attribute and send the request through the right authz section. Oh btw, any news on the radclient bug ? Thanks, Arran
Might be worth trying: =~ "." Maybe regexp operator will sift those that don't exist. Ivan Kalik Kalik Informatika ISP Dana 22/4/2007, "Arran Cudbard-Bell" <A.Cudbard-Bell@sussex.ac.uk> piše:
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Just wondering if theres any way of checking the existence of User-Password in users... =* ANY always matches even if User-Password attribute isn't in the request.. which is not the correct behaviour.
That was done historically because the server didn't have Cleartext-Password. Now that it does, I think that should be fixed in 1.1.7.
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
And cvs head ? :)
Could the check_val module be used in the mean time ?
I was just looking to implement your trick with the authz sections, unfortunately I also need to support ClearText passwords for administrative logins to the switches... so I needed to check the existence of a User-Password attribute and send the request through the right authz section.
Oh btw, any news on the radclient bug ?
Thanks, Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
tnt@kalik.co.yu wrote:
Might be worth trying: =~ "." Maybe regexp operator will sift those that don't exist.
Ivan Kalik Kalik Informatika ISP
Dana 22/4/2007, "Arran Cudbard-Bell" <A.Cudbard-Bell@sussex.ac.uk> piše:
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Just wondering if theres any way of checking the existence of User-Password in users... =* ANY always matches even if User-Password attribute isn't in the request.. which is not the correct behaviour.
That was done historically because the server didn't have Cleartext-Password. Now that it does, I think that should be fixed in 1.1.7.
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
And cvs head ? :)
Could the check_val module be used in the mean time ?
I was just looking to implement your trick with the authz sections, unfortunately I also need to support ClearText passwords for administrative logins to the switches... so I needed to check the existence of a User-Password attribute and send the request through the right authz section.
Oh btw, any news on the radclient bug ?
Thanks, Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
No sadly not tried it already, still matches.
Arran Cudbard-Bell wrote:
I didn't know freeradius supported bitwise operators ! They're not listed anywhere so I assumed you couldn't use them ?!
It doesn't support them. But it shouldn't be too hard to add. In the CVS head, I'm doing some large cleanups to make features like this much easier. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (8)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Donny Jekels -
Matt Ashfield -
Phil Mayers -
robinson santos -
tnt＠kalik.co.yu