Alexander Clouter wrote:
I thought I remembered this popping up recently, I would have mentioned it earlier but my Google-Fu at the time was weak and I though I was imagining things.
If you checkout v2.1.x[1] and then type: ---- $ git checkout -b foreach $ git cherry-pick a3221304 $ git cherry-pick 11aa4442 $ git cherry-pick ba18f024 $ git cherry-pick de60e732 $ <mumble, compile, mumble, install, mumble> ----
It will either: * give you foreach[2] ('man 5 unlang') * make your pants explode[3]
Cheers
[1] http://git.freeradius.org/ [2] http://freeradius.1045715.n5.nabble.com/regex-matching-can-be-convinced-to-b... [3] http://www.youtube.com/watch?v=Ysw4Xv6JI_w (0:00 -> 0:30 seconds)
Thanks for the heads-up. I know this won't be of much help to anyone else as a generic solution, but in a rlm_perl-induced fit of rage (I have about as much experience with and fondness for perl as ... someone who has nothing of something) I decided to step back and whiteboard the problem. I ended up managing to get a hold of the department that runs LDAP, got a list of all of the possible attribute values, and just did a update reply { employeeType -= badValueHere } to get rid of the values I don't want, before doing case-insensitive regex string comparisons on reply:employeeType[*]. With a default of reject (oversimplified) this works fine. But thanks to everyone for the advice... hopefully it will be useful for the next person with these questions. -Jason Antman PS - Unfortunately my overcomplicated unlang authenticate{} section is because I'm required to log to SQL in realtime (i.e. not parsing text log files) the result of each authentication attempt, and *why* - i.e. what specific rule was used to deny someone access, or what rule triggered successful authentication. FreeRadius doesn't seem to have any support for this, other than lots of updates{} to custom local attributes.