Blocking a user before proxy

[Lovaas,Steven]

Hello - I'm new to the list, because I've encountered a question I can't find the answer to in the wiki or the archives.

We've had a stable Freeradius implementation for several years, and we love it! Authentication decisions are being made on a group of linux servers; some locally, some handed off via ldap, and more recently some via peap-mschapv2. Now, we are in a position where we'd like to implement proxying with realms, to hand off the 802.11i decision to a Microsoft NPS (IAS) server we don't control, but we want to retain the ability to reject a user on the linux boxes before handing the question to NPS. Up until now we've rejected individual users by an $INCLUDE of a bad-users file into the USERS file.

My question is about what step in the sequence is most efficient to get this done, and if there are any implications for which tool works best in the different steps. It makes sense to me (and with what I've seen written on the lists) to make that decision BEFORE proxying, and if possible before even making the decision to DO proxying. If I understand the process correctly...

1)      It would be nice to do it during the Authorization phase (so as not to waste time with proxying activities)
2)      The existing files in Preprocess (hints, huntgroups) don't seem to be set up for individual user blocking
3)      Checkval doesn't take non-matches, so we can't use that.

So I guess I'll need to insert some conditional logic evaluating against a list of bad usernames in one of those areas, using the language of radiusd.conf or with Perl or write a custom module. Anyone have any advice about what the best approach would be? Or am I missing something a lot easier?

Thanks!

Steve Lovaas