Re: Freeradius-Users Digest, Vol 8, Issue 82
Hey, guys! Thanks for the great replies!! I like what you suggested better than what I've come up with in the mean time. I think what I came up with will work, it just seems messy/wrong/inefficient. What do you think? modules { ldap { : filter = "(&(uid=%{Stripped-User-Name:-%{User-Name}})(radiusGroupName=%{Called-Station-ID}))" : } attr_rewrite getssid { attribute = Called-Station-Id searchin = packet searchfor = ".................:" replacewith = "" ignore_case = yes new_attribute = no } } authorize { # for WinXP, 802.1x, EAP-PEAP, MS-CHAPv2 preprocess eap getssid ldap } This cuts off the first 17 bytes and then a colon of the Called-Station-ID (My AP transmits a dash separated MAC followed by a colon and then the SSID). Then it uses this rewritten Called-Station-ID and uses that as a filter in the LDAP search. Therefore, if the SSID a user tries to connect to is not listed as an attribute of the user's LDAP object, the user is denied. Does that make sense? But I am definitely going to try implementing the suggestions from Dusty and Alan (below). Thanks, guys!! Stefan
Date: Mon, 19 Dec 2005 11:02:33 -0500 (EST) From: Dusty Doris <freeradius@mail.doris.cc> Subject: Re: Authorization To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Message-ID: <20051219104900.T19542@mail.doris.name> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Let's say I have 2 groups: students and faculty. I want to authorize authenticated members of the LDAP group cn=students,ou=Groups IFF their Access-Request Called-Station-ID =~ "/:StudentWLAN$/" I want to authorize authenticated members of the LDAP group cn=faculty,ou=Groups IFF their Access-Request Called-Station-ID =~ "/:FacultyWLAN$/"
You left out your ldap part? Anyway it should look something like this.
groupname_attribute = cn groupmembership_filter = "(&(objectclass=GroupOfNames)(member=%{Ldap-UserDN}))"
Of course you'll have to change that to fit with how your directory is structured. Once you've got that part down, then in the users file you could do something like this.
DEFAULT Called-Station-ID =~ "/:StudentWLAN$/", Ldap-Group == "students"
DEFAULT Called-Station-ID =~ "/:FacultyWLAN$/", Ldap-Group == "faculty"
DEFAULT Auth-Type := Reject
That would look to see if Called-Station-ID matches that regex. If so, it would look to see if they are in the Ldap-Group of students. Your groupmembership filter and groupname_attribute should look for a group named cn=students and then see if the DN of the user is in it.
If not, it would fall through to the Reject statement. Now, there are other things going on outside of ldap that I don't really know about, so a copy/paste of what I wrote might not work. But, it should help lead you in the right direction.
I'd give it a shot running in debug mode (radiusd -X) and then you can see the exact queries that are taking place and what is happening. You can then go back and modify those ldap group statements and the users file to fit what you need.
Once you've got it started if you need more help, please post debug output and what you would expect vs what you got and we can probably help sort it out.
------------------
Message: 6 Date: Mon, 19 Dec 2005 11:47:24 -0500 From: "Alan DeKok" <aland@ox.org> Subject: Re: Authorization To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Message-ID: <20051219164724.55C0717115@mail.nitros9.org>
Stefan Adams <stefan@borgia.com> wrote:
I have read all the man pages and /docs and am having a difficult time understanding the authorization. I keep wanting to write "if...elseif...else" stuff but I'm pretty sure that doesn't apply to FreeRADIUS config files.
Unfortunately, yes.
How would I configure the checkval module? Is it even necessary to use the checkval module? How would I conifgure the users file? Is the users file even necessary?
I wouldn't configure the checkval module. Just the "users" module, something like:
DEFAULT LDAP-Group == faculty, Called-Station-Id != "faculty", Auth-Type := Reject
DEFAULT LDAP-Group == students, Called-Station-Id != "students", Auth-Type := Reject
P.S. I don't know who to direct compliments to, but the FreeRADIUS code is probably the most beautifully structured source code I have ever read. It is SO easy to read and extremely consistent! It's phenomenal!
You can thank everyone who contributed so far. :)
Alan DeKok.
On Mon, 19 Dec 2005, Stefan Adams wrote:
Hey, guys! Thanks for the great replies!! I like what you suggested better than what I've come up with in the mean time. I think what I came up with will work, it just seems messy/wrong/inefficient. What do you think?
modules { ldap { : filter =
"(&(uid=%{Stripped-User-Name:-%{User-Name}}) (radiusGroupName=%{Called-Station-ID}))" : } attr_rewrite getssid { attribute = Called-Station-Id searchin = packet searchfor = ".................:" replacewith = "" ignore_case = yes new_attribute = no } }
authorize { # for WinXP, 802.1x, EAP-PEAP, MS-CHAPv2 preprocess eap getssid ldap }
This cuts off the first 17 bytes and then a colon of the Called-Station-ID (My AP transmits a dash separated MAC followed by a colon and then the SSID). Then it uses this rewritten Called-Station-ID and uses that as a filter in the LDAP search. Therefore, if the SSID a user tries to connect to is not listed as an attribute of the user's LDAP object, the user is denied.
Does that make sense?
That's a pretty neat idea. The benefit of that is if you had multiple ldap instances and wanted to implement fail-over within freeradius. To do it the traditional way, you would need this for fail-over with ldap-group checks if say you had two ldap instances. DEFAULT Called-Station-Id =~ /studentregex/, ldap1-Ldap-Group == "students" DEFAULT Called-Station-Id =~ /studentregex/, ldap2-Ldap-Group == "students" That is so it will check with ldap1 instance first. If that fails, then check ldap2. By doing it your way, you won't need to do that anymore. Instead a redundant block in authorize would get you what you need already since the radiusGroupname inside your search filter takes care of the Ldap-Group check. I wonder if you could use regex matches of Called-Station-ID in the huntgroups file. You'll have to test this out, I doubt it would work, but its another interesting idea. I don't know if huntgroups excepts regex and if it can use things like Called-Station-Id in huntgroups students Called-Station-Id =~ /studentregex/ faculty Called-Station-Id =~ /facultyregex/ Then in users file. DEFAULT Ldap-Group == %{Huntgroup-Name} Or you're way. (&(uid=%{Stripped-User-Name:-%{User-Name}})(radiusGroupName=%{Huntgroup-Name}))" See doc/configurable_failover and doc/rlm_ldap to see what I'm talking about with the failover. If you have a load balancer in front of that ldap server, you won't need to worry about it. But if you don't and you want to add redundancy, then its something you'll need to think about some day. Freeradius can do the redundancy for you w/out a load balancer or shared IP using configurable failover. Actually in the upcoming 1.1 release it will also do load balancing for you in addition to failover inside your ldap blocks. Hope I'm not too confusing. My point is I like your idea and if its working for you, it doesn't sound like a bad one to me. You might want to try hitting it hard to see if the rewrite slows anything down, but I would bet it doesn't. I'd also make sure to add an eq index to radiusgroupname, since you'll be using that as part of your search filter.
participants (2)
-
Dusty Doris -
Stefan Adams