I believe the reason these SQL Group discussions die is that it is hard to explain what it really happening. I will attempt to do so but cannot devote much time to followups if this is not clear. Also my understanding is based on FR 1.0.0 as we haven't moved up to 1.0.2 yet.
FreeRADIUS' use of groups in the sql module is not the same as using Unix groups in the users file. You cannot create separate check conditions in separate SQL groups and then send only the reply elements from that same group. Look at the SQL queries in sql.conf - specifically, the authorize_group_check_query and authorize_group_reply_query settings. These queries return check and reply attributes for a user based on the settings in usergroup. IT DOES NOT RETURN THE GROUP NAMES THEMSELVES. As far as FreeRADIUS is concerned this is one large group of check and reply attributes. I have implemented two possible solutions and I'm sure there are plenty of others. One solution is to use Autz-Type and implement a different sql.conf definition for each Autz-Type. The downside is that many more SQL connections are opened when FR starts up. Another solution is to redefine the SQL queries in sql.conf. I have implemented this approach by adding a HuntGroup column to the table definitions. I then add the appropriate clients to the huntgroup file and have the SQL queries use the HuntGroup name as part of the query to find the appropriate check and reply attributes to return to FreeRADIUS. As example of our setup is as follows: +-----------+-----------+----+--------+-----------+ | GroupName | Attribute | op | Value | HuntGroup | +-----------+-----------+----+--------+-----------+ | DEFAULT | Auth-Type | = | Local | wlusers | | DEFAULT | Auth-Type | = | Reject | dial800 | | tollfree | Auth-Type | := | Local | dial800 | +-----------+-----------+----+--------+-----------+ +-----------+--------------------+----+---------------------+-----------+ | GroupName | Attribute | op | Value | HuntGroup | +-----------+--------------------+----+---------------------+-----------+ | DEFAULT | Service-Type | = | Framed-User | wlusers | | DEFAULT | Framed-Protocol | = | PPP | wlusers | | DEFAULT | Framed-IP-Address | = | 255.255.255.254 | wlusers | | DEFAULT | Framed-IP-Netmask | = | 255.255.255.255 | wlusers | | DEFAULT | Framed-Compression | = | Van-Jacobson-TCP-IP | wlusers | | tollfree | Service-Type | = | Framed-User | dial800 | | tollfree | Framed-Protocol | = | PPP | dial800 | | tollfree | Framed-IP-Address | = | 255.255.255.254 | dial800 | | tollfree | Framed-IP-Netmask | = | 255.255.255.255 | dial800 | | tollfree | Framed-Compression | = | Van-Jacobson-TCP-IP | dial800 | +-----------+--------------------+----+---------------------+-----------+ A similar approach could be implemented using IP addresses, hints or realms. Cheers, _Mike (not a FreeRADIUS developer) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
