Freeradius-Users Digest, Vol 8, Issue 82

[Dusty Doris]

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.