I'm using EAP-TLS and authentication works well. I also sanitize Called-Station-Id, Calling-Station-Id and in the same process create Called-Station-Ssid. This also works very well. This is done at first in the authorize section. My mods-config/files/authorize file has two entries as below. tlsuser Tunnel-Medium-Type = "IEEE-802", Tunnel-Private-Group-Id = "43", Tunnel-Type = "VLAN" DEFAULT Tunnel-Medium-Type = "IEEE-802", Tunnel-Private-Group-Id = "1", Tunnel-Type = "VLAN" My switches support Dynamic VLAN Assignment so this current configuration is fine. My Wifi Access Points however do NOT support it, thus I have to use a unique SSID for each VLAN. Because of that I have to check to which SSID a user is connecting to and accept or reject him based on which VLAN he's allowed to access. I tried using (note the single = in the check item!) tlsuser Called-Station-Ssid = "vlan43" Tunnel-Medium-Type = "IEEE-802", Tunnel-Private-Group-Id = "43", Tunnel-Type = "VLAN" This allows me to connect to a switch (which doesn't cause the creation of Called-Station-Ssid) but also to an access point. However, it does not prevent me connecting to a forbidden SSID. If I use == in the check item it actually does prevent me from connecting to a forbidden SSID but also from connecting through switches. So, should I use a regex in the "users" file for each user entry or should I do this with a policy using unlang? And if using unlang is advised - I think using groups is the better approach than hardcoding usernames into the code - how do I create groups which contain a) the usernames that are part of that group and b) one or more Called-Station-Ssid entries the user is allowed to connect to? I thought about arrays but I couldn't find infos if it's supported or how it's used. I actually have a perfectly working unlang code for doing what I want to achieve but that checks LDAP and I want to get rid of it since it's kind of an overkill for just assigning users into groups. Thank you very much in advance! Ben
On May 25, 2015, at 10:41 AM, Ben Humpert <ben@an3k.de> wrote:
This allows me to connect to a switch (which doesn't cause the creation of Called-Station-Ssid) but also to an access point. However, it does not prevent me connecting to a forbidden SSID. If I use == in the check item it actually does prevent me from connecting to a forbidden SSID but also from connecting through switches.
The users file isn't well suited for complex policies.
So, should I use a regex in the "users" file for each user entry or should I do this with a policy using unlang?
Keep the users file simple.
And if using unlang is advised - I think using groups is the better approach than hardcoding usernames into the code - how do I create groups which contain a) the usernames that are part of that group and b) one or more Called-Station-Ssid entries the user is allowed to connect to?
See raddb/modules/etc_group, and "man rlm_passwd". The process of creating groups is documented for precisely this reason. :)
I thought about arrays but I couldn't find infos if it's supported or how it's used. I actually have a perfectly working unlang code for doing what I want to achieve but that checks LDAP and I want to get rid of it since it's kind of an overkill for just assigning users into groups.
Use the groups to set the list of allowed SSIDs as a new attribute, "Allowed-SSID". Have a special one for "no SSID". Then in "unlang" if ((!Called-Station-Ssid && (Allowed-SSID == "no-SSID")) || (Allowed-Station-SSID == "%{Called-Station-Ssid}")) { ... set VLANs ... } else { reject } Something like that should work. Alan DeKok.
2015-05-25 17:09 GMT+02:00 Alan DeKok <aland@deployingradius.com>:
On May 25, 2015, at 10:41 AM, Ben Humpert <ben@an3k.de> wrote:
This allows me to connect to a switch (which doesn't cause the creation of Called-Station-Ssid) but also to an access point. However, it does not prevent me connecting to a forbidden SSID. If I use == in the check item it actually does prevent me from connecting to a forbidden SSID but also from connecting through switches.
The users file isn't well suited for complex policies.
So, should I use a regex in the "users" file for each user entry or should I do this with a policy using unlang?
Keep the users file simple.
That's exactly what I secretly hoped :)
And if using unlang is advised - I think using groups is the better approach than hardcoding usernames into the code - how do I create groups which contain a) the usernames that are part of that group and b) one or more Called-Station-Ssid entries the user is allowed to connect to?
See raddb/modules/etc_group, and "man rlm_passwd". The process of creating groups is documented for precisely this reason. :)
Awesome! Thank you very much for pointing me to these. I hoped for something like this.
I thought about arrays but I couldn't find infos if it's supported or how it's used. I actually have a perfectly working unlang code for doing what I want to achieve but that checks LDAP and I want to get rid of it since it's kind of an overkill for just assigning users into groups.
Use the groups to set the list of allowed SSIDs as a new attribute, "Allowed-SSID". Have a special one for "no SSID". Then in "unlang"
/etc/freeradius/mods-enabled/groups passwd groups { moddir = ${modconfdir}/${.:instance} filename = ${moddir}/authorize format = "Group-Name:,Allowed-SSID:*,User-Name" hash_size = 50 ignore_nislike = yes allow_multiple_keys = yes delimiter = ":" } /etc/freeradius/mods-config/groups/authorize #Group-Name:Allowed-SSID:User-Name Base:base,small:Sony VAIO,Ben Small:small:Mike,Tim Large:large:Anastacia
if ((!Called-Station-Ssid && (Allowed-SSID == "no-SSID")) || (Allowed-Station-SSID == "%{Called-Station-Ssid}")) { ... set VLANs ... } else { reject }
Something like that should work.
I tried that but somehow I can't get it working. I know PHP so if-then-else stuff is not a problem at all but I have a problem reading the Attribute so I can compare it with %{Called-Station-Ssid}. I tried it with %{Allowed-SSID}, %Allowed-SSID, &Allowed-SSID, Allowed-SSID and stuff like %{config:Allowed-SSID} or %{config:modules.groups.Allowed-SSID} and in the debug log I see groups: Added Allowed-SSID: 'base,small' to config_items so I should be able to %{config:Allowed-SSID} == %{Called-Station-Ssid} but the attribute is always empty or I get "Config item "Allowed-SSID" does not exist". I also got the following warning Mon May 25 21:18:22 2015 : Warning: /etc/freeradius/policy.d/access[3] Please change %{Called-Station-Ssid}} to &Called-Station-Ssid} so what is the difference between %{Attribute-Name} and &Attribute-Name ? It's hard to google for just these special chars. I somehow feel stupid, just a little bit but still beyond acceptance :) and I hate asking for help but I can't solve this on my own. Thanks very much!
On May 25, 2015, at 3:41 PM, Ben Humpert <ben@an3k.de> wrote:
/etc/freeradius/mods-enabled/groups passwd groups { moddir = ${modconfdir}/${.:instance}
Is this for v3? If so, that's fine...
filename = ${moddir}/authorize format = "Group-Name:,Allowed-SSID:*,User-Name"
That's not correct. For one, you don't want to re-use the Group-Name attribute. It already has a meaning. You probably want: format = "~Allowed-SSID:*,User-Name"
/etc/freeradius/mods-config/groups/authorize
#Group-Name:Allowed-SSID:User-Name
Don't put comments into the files. It won't work. You should just use: SSID:user1,user2,user3
I tried that but somehow I can't get it working. I know PHP so if-then-else stuff is not a problem at all but I have a problem reading the Attribute so I can compare it with %{Called-Station-Ssid}.
You'll also need to *enable* the "groups" module. List it in raddb/sites-available/default, in the "authorize" section, and BEFORE the unlang statements which look for Allowed-SSID. And add Allowed-SSID to the dictionaries. See raddb/dictionary.
I tried it with %{Allowed-SSID}, %Allowed-SSID, &Allowed-SSID, Allowed-SSID and stuff like %{config:Allowed-SSID} or %{config:modules.groups.Allowed-SSID} and in the debug log I see
PLEASE don't try random things. The method of referencing attributes is documented. If the attribute can't be found, it's because something *else* is wrong.
groups: Added Allowed-SSID: 'base,small' to config_items
so I should be able to %{config:Allowed-SSID} == %{Called-Station-Ssid} but the attribute is always empty or I get "Config item "Allowed-SSID" does not exist".
I also got the following warning
Mon May 25 21:18:22 2015 : Warning: /etc/freeradius/policy.d/access[3] Please change %{Called-Station-Ssid}} to &Called-Station-Ssid}
That's fine.
so what is the difference between %{Attribute-Name} and &Attribute-Name ? It's hard to google for just these special chars.
<sigh> See "man unlang". This is documented. The documentation comes with the server.
I somehow feel stupid, just a little bit but still beyond acceptance :) and I hate asking for help but I can't solve this on my own. Thanks very much!
Do the fixes I suggested above. And read the debug output. Alan DeKok.
2015-05-25 22:23 GMT+02:00 Alan DeKok <aland@deployingradius.com>:
On May 25, 2015, at 3:41 PM, Ben Humpert <ben@an3k.de> wrote:
/etc/freeradius/mods-enabled/groups passwd groups { moddir = ${modconfdir}/${.:instance}
Is this for v3? If so, that's fine...
3.0.7 because you told me to upgrade from 2.1.12 ;)
filename = ${moddir}/authorize format = "Group-Name:,Allowed-SSID:*,User-Name"
That's not correct. For one, you don't want to re-use the Group-Name attribute. It already has a meaning. You probably want:
format = "~Allowed-SSID:*,User-Name"
/etc/freeradius/mods-config/groups/authorize
#Group-Name:Allowed-SSID:User-Name
Don't put comments into the files. It won't work. You should just use:
SSID:user1,user2,user3
I tried that but somehow I can't get it working. I know PHP so if-then-else stuff is not a problem at all but I have a problem reading the Attribute so I can compare it with %{Called-Station-Ssid}.
You'll also need to *enable* the "groups" module. List it in raddb/sites-available/default, in the "authorize" section, and BEFORE the unlang statements which look for Allowed-SSID.
Already had it enabled in my tests and also called it before the unlang statements. I'm not THAT stupid ;)
And add Allowed-SSID to the dictionaries. See raddb/dictionary.
Also had done that. If not I couldn't have started the server because of "Unknown attribute" error
I tried it with %{Allowed-SSID}, %Allowed-SSID, &Allowed-SSID, Allowed-SSID and stuff like %{config:Allowed-SSID} or %{config:modules.groups.Allowed-SSID} and in the debug log I see
PLEASE don't try random things. The method of referencing attributes is documented. If the attribute can't be found, it's because something *else* is wrong.
groups: Added Allowed-SSID: 'base,small' to config_items
so I should be able to %{config:Allowed-SSID} == %{Called-Station-Ssid} but the attribute is always empty or I get "Config item "Allowed-SSID" does not exist".
I also got the following warning
Mon May 25 21:18:22 2015 : Warning: /etc/freeradius/policy.d/access[3] Please change %{Called-Station-Ssid}} to &Called-Station-Ssid}
That's fine.
so what is the difference between %{Attribute-Name} and &Attribute-Name ? It's hard to google for just these special chars.
<sigh> See "man unlang". This is documented. The documentation comes with the server.
Until now I always checked http://freeradius.org/radiusd/man/unlang.html but this time I actually opened the man unlang on my linux server and wow, what a difference. The website just contains "&" six times; for three foo && bar samples. Are you going to only use the wiki for documentation, manpages, etc. or do you want to keep the website documentation stuff too? If not I guess it's ok if we (users) help improving the wiki ourselves?
I somehow feel stupid, just a little bit but still beyond acceptance :) and I hate asking for help but I can't solve this on my own. Thanks very much!
Do the fixes I suggested above. And read the debug output.
I did. I used the exact same code for the format setting in the /etc/freeradius/mods-enabled/groups you've posted above. It worked. Then I checked my code and saw the problem. I missed the ~ Instead of getting groups: Added Allowed-SSID: 'base,small' to config_items I now get groups: Added Allowed-SSID: 'base,small' to request_items I thought having it as an config attribute is fine. I was wrong. Thank you very much for your help!
On May 25, 2015, at 5:15 PM, Ben Humpert <ben@an3k.de> wrote:
3.0.7 because you told me to upgrade from 2.1.12 ;)
Sure.. I don't remember details about which email I send where. It's simpler that way.
Already had it enabled in my tests and also called it before the unlang statements. I'm not THAT stupid ;)
It never hurts to be clear.
And add Allowed-SSID to the dictionaries. See raddb/dictionary.
Also had done that. If not I couldn't have started the server because of "Unknown attribute" error
Good. Just making sure...
Until now I always checked http://freeradius.org/radiusd/man/unlang.html but this time I actually opened the man unlang on my linux server and wow, what a difference. The website just contains "&" six times; for three foo && bar samples.
I'll go update the web site. I think it's for v2, so it's out of date with respect to v3.
Are you going to only use the wiki for documentation, manpages, etc. or do you want to keep the website documentation stuff too? If not I guess it's ok if we (users) help improving the wiki ourselves?
I'm writing tons of documentation: http://networkradius.com/doc/current/unlang/ And: http://networkradius.com/doc/current/unlang/condition.html It's correct. Perhaps incomplete, but correct. The problem with the Wiki is that it gets edited by random people, and therefore can't be the official "correct" version of the documentation.
I did. I used the exact same code for the format setting in the /etc/freeradius/mods-enabled/groups you've posted above. It worked. Then I checked my code and saw the problem. I missed the ~ Instead of getting
groups: Added Allowed-SSID: 'base,small' to config_items
I now get
groups: Added Allowed-SSID: 'base,small' to request_items
I thought having it as an config attribute is fine. I was wrong.
It should ben but you then have to refer to it as a config item.
Thank you very much for your help!
It's what I do. Alan DeKok.
2015-05-25 23:27 GMT+02:00 Alan DeKok <aland@deployingradius.com>:
It never hurts to be clear.
[ ... ]
Good. Just making sure...
:-)
I'll go update the web site. I think it's for v2, so it's out of date with respect to v3.
Are you going to only use the wiki for documentation, manpages, etc. or do you want to keep the website documentation stuff too? If not I guess it's ok if we (users) help improving the wiki ourselves?
I'm writing tons of documentation:
http://networkradius.com/doc/current/unlang/
And:
http://networkradius.com/doc/current/unlang/condition.html
It's correct. Perhaps incomplete, but correct. The problem with the Wiki is that it gets edited by random people, and therefore can't be the official "correct" version of the documentation.
I know how time consuming it is so have your software well documented so that it's easy to read, that others can understand it and that it's nearly always up-to-date. So currently there are five, well six locations where documentation is available. freeradius.org website, freeradius.org wiki, networkradius.com, deployingradius.com, example config files and manpages. This not only means much more work for you (since you have to take care about all the sources) but also more hassle for users to find what they need since they have to search all these. I really would like to help you guys with the documentation stuff so that you have more time answering my questions here ... ehm, actually I meant to say "bugfixing and improving FreeRADIUS" ;-) I really like the versioning behind http://networkradius.com/doc/current/ but I think the easiest way would be to use the wiki, setting it up as read-only and only grant "good people" write access. Or grant write access to everybody but every change not made by "good people" has to be verified before it's published.
I thought having it as an config attribute is fine. I was wrong.
It should ben but you then have to refer to it as a config item.
How? Based on what I read in the doc it should be %{config:MyCustomAttribute} Also one last question about the rlm_passwd. The example config for passwd says
Field marked as ',' may contain a comma separated list of attributes. <<
I used this in my config but when I check the attribute it contains "ssid1,ssid2". /etc/freeradius/mods-enabled/groups format = "~My-Group-Name:,~My-Called-Station-Ssid:*,User-Name" /etc/freeradius/mods-config/groups/authorize Group:ssid1,ssid2:user1,user2,user3 I also tried it without the comma but then the attribute contains exactly the same. I thought it instructs FR to seperate the entry by commas and have each as a value for the given attribute. I also thought that maybe the format ([comma][tilde]<Attribute-Name>) is wrong because for User-Name it's [asterisk][comma]<Attribute-Name> but when I tried it, the Attribute isn't set at all so I guess the complete correct format is [asterisk][comma][tilde | equal sign]<Attribute-Name> Anyway, what does the comma actually should do? Thanks
On May 26, 2015, at 12:05 PM, Ben Humpert <ben@an3k.de> wrote:
I know how time consuming it is so have your software well documented so that it's easy to read, that others can understand it and that it's nearly always up-to-date. So currently there are five, well six locations where documentation is available. freeradius.org website, freeradius.org wiki, networkradius.com, deployingradius.com, example config files and manpages.
- freeradius.org contains HTML versions of the man pages, so there's little duplication there - wiki.freeradius.org is maintained by other people. It contains collections of things about FreeRADIUS, mostly how-to's I don't think I've made a serious edit in months - the example configs in raddb should ALWAYS be up to date, and document every configuration item - the "man" pages are up to date, and document syntax, etc. that isn't documented in the configs. The "man" pages rarely change. Keeping them up to date is easy - deployingradius.com contains a few how-to's for historical purposes. I don't think I've made a change in years. That documentation is correct, but doesn't need changing. - networkradius.com/doc/ is in process. It contains full documentation for all of the modules, config, concepts, etc. It already has 100's of pages, and will contain hundreds more. It's where the bulk of the new documentation is going.
This not only means much more work for you (since you have to take care about all the sources) but also more hassle for users to find what they need since they have to search all these.
For simple things, read the config. For a bit more complex things, read the man pages. For more detail... go to freeradius.org, and follow the links. People who google random topics, and then read 10 year-old third party web sites are wasting their time. We're also working on updating the freeradius.org web site. It should look more modern, and have clearer links to the documentation.
I really would like to help you guys with the documentation stuff so that you have more time answering my questions here ... ehm, actually I meant to say "bugfixing and improving FreeRADIUS" ;-)
Sure. www.freeradius.org is on github. Feel free to fork it, and submit pull requests. The same applies to all of the example configs and man pages.
I really like the versioning behind http://networkradius.com/doc/current/ but I think the easiest way would be to use the wiki, setting it up as read-only and only grant "good people" write access. Or grant write access to everybody but every change not made by "good people" has to be verified before it's published.
For a variety of reasons, that won't work. The people who understand FreeRADIUS usually don't have the time to write huge amounts of documentation. I've started doing it because FreeRADIUS is my full-time job. I've been investing real $$$ into the documentation. So that it looks good, is well organized, is copy edited, and is easy to find things. Maybe once that's all online, I can put it into "git" and accept patches. Until then, it's still in a state of change.
I used this in my config but when I check the attribute it contains "ssid1,ssid2".
/etc/freeradius/mods-enabled/groups format = "~My-Group-Name:,~My-Called-Station-Ssid:*,User-Name"
Use commas only at the end. And I'm not sure what you're doing there. The passwd module doesn't allow multiple values for multiple attributes. It allows multiple values for ONE attribute, and then ONLY at the end of the list. See raddb/mods-available/etc_group for an example. Use that format, while knowing that you don't need multiple ":": format = ~My-Group-Name:*,User-Name and in the file: groupA:user1,user2,user3 groupB:user3,user4,user5
Anyway, what does the comma actually should do?
It allows multiple values for the LAST attribute in a list. Just like the etc_group example. If you want something more complex, you'll have to use something else. I'd suggest keeping things simple. If users are allowed to connect to a restricted set of SSIDs, then put the users into groups: "permissive" and "restricted". Then, do group checking against the SSIDs. If you have 2-3 SSIDs, this is the simplest way to do it. If you have 100's of SSIDs, I have to question why that's done... Alan DeKok.
participants (2)
-
Alan DeKok -
Ben Humpert