Re: [Help-gnu-radius] Defining custom attributes

[Sergey Poznyakoff]

Charles Sprickman <address@hidden> wrote:

> So I added two more attributes of my own patterned after Auth-Data:
> 
> ATTRIBUTE       Auth-Gid                4000    string  - [L--R-R]=
> ATTRIBUTE       Auth-Dom                4001    string  - [L--R-R]=

That's correct.

> 
> Auth-Data was used in three files to supply a slightly different query
> depending on where the request came from.  Below are the relevant config
> snippets.
>
> huntgroups:
[...]

It is correct as well.

> users:
> 
> # also see "huntgroups"...  Here we are using tags from huntgroups to
> # assign extra "Auth-Data" to a request based on which nas the request
> # comes from.
> 
> DEFAULT         Huntgroup-Name = LOCAL,
>                 Auth-Type = SQL,
>                 Auth-Gid = "64"
>                 Service-Type = Framed-User

This is *syntactically* correct. Notice, however a semantical difference
between using Auth-Data and custom Auth-Gid. The semantic sense of
left-hand side attribute list (in the above entry it is Huntgroup-Name =
LOCAL, Auth-Type = SQL, Auth-Gid = "64") is dual. The internal
attributes, encountered in this attribute list, control radiusd behavior
(e.g. Auth-Type selects appropriate authentication type), whereas
other attributes are compared with the incoming request. A raddb/users
entry matches the request only if all non-internal attributes in its
LHS are encountered (and have the same values) in the request.

Now, Auth-Data is an internal attribute, therefore it does not take
part in comparisons. Instead, when doing authentication,
radiusd temporarily appends it to the incoming request before constructing
SQL query, that is why it is available as %C{Auth-Data} in your
auth_query (%C denotes attributes from the request). On the other
hand, Auth-Gid is a usual attribute (albeit a custom one), so it
takes part in comparisons. In short, a request will match the above
raddb/users entry only if it contains

      Huntgroup-Name = LOCAL *and* Auth-Gid = "64"

Huntgroup-Name is added to requests coming from host 127.0.0.1 by
the first huntgroup entry (it appears commented out in your posting,
but let's assume it weren't), but no rule adds Auth-Gid to the request,
so it has no chances of matching any of the two raddb/users entries.
That explains the change in the behavior you have noticed.

For your custom attributes to take effect, use the following
approach

1) Add the following rewrite function:

integer
add_auth_gid()
{
        if (%[NAS-IP-Address] = 127.0.0.1)
                %[Auth-Gid] = "64";
        else if %[NAS-IP-Address] = 216.220.9.7
                %[Auth-Gid] = "256";
}

(I used arbitrary IP addresses and Gids for the sake of example).
It adds appropriate values of Auth-Gid to the request, depending
on the value of NAS-IP-Address attribute. Of course, you will need
to modify it to suit your needs. For instance, it may also add
Auth-Uid attribute when necessary, etc.

2) Invoke it from your huntgroups, e.g.:

DEFAULT Rewrite-Function = add_auth_gid         NULL

For the configuration described in your posting, this will be the
only huntgroup entry.

3) Modify your raddb/users:

DEFAULT Auth-Type = SQL
        Service-Type = Framed-User

As you see it is reduced to a single entry, since all the selection
work is done by add_auth_gid.

Again, notice that these are only guidelines. Your particular
configuration may require some changes to these.

Regards,
Sergey