how group checks/replies work in rlm_sql

[Todd Williams]

I'm working towards implementing freeradius-1.0.5 with rlm_sql/mysql for
authorization and kerberos for authentication.  I've managed to work out
the basic configuration but have run into problem understanding exactly
how rlm_sql is designed to handle authorization.

According to the documentation in doc/rlm_sql it seems as though during
the group check/reply stage of authorization the group membership for a
user is looked up in the usergroup table, and then for each group the
check AV pairs are pulled and if the checks are passed the
group-relevant reply AV pairs are added to the packet.  However, during
my testing of this I was not getting the results that I expected under
the assumptions I had based off of the rlm_sql documention.

After further investigation (reading code and further testing) it
appears that the way rlm_sql really works is to just pull all the check
and reply AV pairs for all of the groups a user belongs to and create
two big linked lists-- one check, one reply-- containing all of these AV
pairs.  At that point if all of the check items are met then all of the
reply items are added without any granular sense of group membership.
Is my understanding of this correct?

If my understanding is correct then I come to a question of how to best
  approach the following problem.  A single user might be entitled to
consume VPN, dialup, and wireless service all of which are serviced by
different NASs that are under the control of different departments.
Each NAS will have a set of check and reply information that it expects
when transacting with the RADIUS server, and it seems that simply
putting users in the appropriate groups (in the usergroup table) will
likely yield potentially conflicting check and reply AV pairs being
pulled by rlm_sql and unnecessarily involved in the transaction.  Am I
still on the right track or am I missing a concept?

Anyway, it seems like one solution to this problem would be to use some
method of discriminating between NASs prior to entering the
authorization phase (perhaps with huntgroups) and adding an Autz-Type
attribute containing the name of a particular instance of rlm_sql that
is configured with service-specific radgroupcheck/reply tables.  Is this
the way to go?

Thanks in advance for the help.

-- 
Todd C. Williams
tcwill at ufl.edu
The Open Systems Group