We provide AAA services to a variety of client businesses across North America, and we use FreeRADIUS as the final piece of our authentication process. Because our clients' customers are unknown until they attempt to connect to the network, all user radius credentials are created dynamically, after an initial authentication via another method (typically, credit card charges, access codes, etc.); once that initial auth is complete, we create a credential using the user devices' MAC address to ensure uniqueness, and to facilitate the MAC auth feature of the gateway devices we employ, which permits immediate reconnection following idle time-out without having to open a browser (a limitation of the gateway devices). Of concern to us is that we don't want a user to authenticate in one place of business for which we provide service, then move to another client site, at which MAC authentication is enabled, and have the device automatically connected at the second location. This is mainly due to differences in service offerings at different client sites. What we're looking to do is create an additional table in the radius database. That table would contain the following fields: id primary table key callingstationid self-explanatory nasid identifies the specific site the user is at, and corresponds to our own internal site id nasportid the vlan the user is in groupname the group to which the user is assigned in radusergroup As we create each user's credentials, we'll populate this new table with the information indicated. For each VLAN the user connects to, there would be a separate row so that, as he moves from vlan to vlan, we can update the group assignment in radusergroup so that he'd get the proper group attributes. Does this sound like something that could work? If so, I need a bit of help understanding where we'd put the table query (and the construction of it) in whichever file it should be in (e.g., sites-enabled/default?). The goal is to perform the query, and if there's a corresponding row match, do an update on the username in radusergroup to set the proper group id, and then continue normal processing; if there is no match, we'd simply reject the connection, which would force the gateway to redirect to a captive portal server for initial authentication, as described above). For me, the sticking point is where and how to put the SQL query, so I'd appreciate any pointers I can get. And, too, if there's a better way of doing this, I'd welcome any advice! I hope I've provided enough information to start. Many thanks in advance! Jim