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-be-TRUE-if-you-re-insistive-enough-td4422200.html
[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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
