MAC Auth Question

[J Kephart]

Thank you, Alan.  We'll give things a look and see what we can come up
with.  These are some helpful hints, though, and I appreciate it.

Jim

On 06/16/2015 03:52 PM, Alan DeKok wrote:
> On Jun 10, 2015, at 4:25 PM, J Kephart <jkephart at safetynetaccess.com> wrote:
>> We use FR to handle AAA services at a number of client sites, though
>> we've not done anything "fancy" with it as yet.  However, we've recently
>> started using MAC authentication, but one thing we don't want to have
>> happen is for a user to sign up for service in one location and then
>> move to another and be able to use the network without signing in (both
>> sites would be configured for MAC auth).
>   This means the user information needs to be tied to a site.
>
>> To that end, we're thinking we might do something like the following:
>>
>> 1.  Combine the NAS-Identifier with the User-Name (e.g., "1234-samjones").
>   I'd suggest using a site name.  Tie NAS-Identifier to a site, and then a site to a user.  The problem is that one site may have multiple NASes.
>
>> 2.  Do an sql lookup in radgroupreply (all users are assigned to groups
>> based on NAS-ID and username) to determine if the group exists.
>> 3.  If it does, permit MAC auth to succeed; otherwise, reject.
>   This seems like a complicated way to put new data into the existing schema.  I'd suggest just creating a new table.
>
>   Have the table contain NAS identifier, site name, and user name.  Look up the user and NAS identifier in the table.  If the query succeeds, they're allowed in.  Otherwise the user is rejected.
>
>   And I'd suggest modifying the *queries*, not the User-Name.  The User-Name is what the user entered.  It probably shouldn't be changed.
>
>   It's probably OK to use "NAS-ID-user" for the "username" column of the SQL tables.  But I would suggest modifying the queries, not the User-Name.  It's more work, but arguably more correct.  Mangling the User-Name is not a good idea.
>
>> My first question is, does this seem a good way to prevent users from
>> automatic roaming between sites, given that our clients are different? 
>> Does the method seem sound?
>   It works, but I'd recommend something a bit different.
>
>>  Can we generate our own variable names
>> within the raddb files for later use in the sql lookup?
>   Yes.  You can create your own attributes.  See raddb/dictionary
>
>>  And, most
>> importantly, where and in what file would be the best place to do this?
>   All over the place... you've got to modify a number of things.  Probably the dictionary, sites-enabled/default, and the SQL queries.
>
>> Also, for accounting purposes, we'd like to prepend the same nas-id to
>> the username.  Any recommendations on how best to approach that?
>   I'd suggest that you don't do that.  The NAS-Identifier is already a field in the accounting tables.  Just rely on the existing tables to do their job,
>
>> We're stepping off the edge of the world here, well outside our comfort
>> zone, so we want to be sure we do this correctly.  I appreciate any and
>> all pointers, especially to docs that might describe how to do this.
>   There's no documentation describing how to create your custom solution, unfortunately.
>
>   There is documentation on how the server works, and how to put the pieces together.
>
>   The main recommendation is to keep it simple.  If you have custom data, put it into a custom table in SQL.  Then write a custom query to validate that information.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html