Re: suggestions for multiple vlans in hundreds of switches
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
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:[EMAIL PROTECTED]" FreeRADIUS-SubjectAltName = "email:[EMAIL PROTECTED]" ..etc. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
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
Re: suggestions for multiple vlans in hundreds of switches
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 > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
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 3000string > ATTRIBUTE MyVlanType 3001string > > 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 = '01001000' DEFAULT Packet-Src-IP-Address == roaming1.ja.net NAS-Feature-Set = '01001000' DEFAULT Packet-Src-IP-Address == roaming2.ja.net NAS-Feature-Set = '01001000' # # Debug entry for home testing. #DEFAULT Packet-Src-IP-Address == arr-land.co.uk #NAS-Feature-Set = '01001000' # # 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 =~ 01001000 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 $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;
Re: suggestions for multiple vlans in hundreds of switches
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 3000string ATTRIBUTE MyVlanType 3001string This could also be done cleaner (but slower) with cleverly designed SQL tables or stored procedures - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: suggestions for multiple vlans in hundreds of switches
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 [EMAIL PROTECTED] -Original Message- From: robinson santos [mailto:[EMAIL PROTECTED] Sent: April 19, 2007 12:31 PM To: [EMAIL PROTECTED]; 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 [EMAIL PROTECTED] On 4/19/07, Matt Ashfield <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] - 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: suggestions for multiple vlans in hundreds of switches
I was afraid someone would say that! Haha Matt -Original Message- From: Donny Jekels [mailto:[EMAIL PROTECTED] Sent: April 19, 2007 10:57 AM To: [EMAIL PROTECTED]; 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] - 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: 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 [EMAIL PROTECTED] On 4/19/07, Matt Ashfield <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] - 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: 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html