Issue with table RADGRUOPCHECK

[Alan DeKok]

On Nov 16, 2017, at 5:40 AM, Andrea Mucci <andrea.mucci at outlook.com> wrote:
> I would like to use the features of rlm_sql module, to send the correct VSA depending on the type of NAS that sent the Access-Request.

  That's possible.

>  5. For each group this user is a member of, the corresponding check items
>     are pulled from radgroupcheck table and compared with the request.  If
>     there is a match, the reply items for this group are pulled from the
>     radgroupreply table and applied.

  Yes, that's how it works.

> I found some inconsistencies:
> 1) I can't associate a user to multiple groups for ORACLE schema. Why there is a unique constraint on the USERNAME field of the RADUSERGROUP table.

  Hmm... that's an error.  It shouldn't be UNIQUE.  None of the other schemas have that restriction.  I'll fix it.

> 2) Obviously the select, that retrieves the attributes to reply, does not consider this eventuality and retrieves all the attributes of the groups that the user shares, even if the check on the RADGRUOPCHECK table is not positive.

  Hmm...  I don't see why that happens.

> 3) At the end it seems that the control on the RADGRUOPCHECK table does not work.

  It does work for other DBS.

> My idea was to create multiple groups with the VSAs of individual devices, associate the user with all the groups and define a check over the FreeRADIUS-Client-NAS-Type attribute in the table RADGRUOPCHECK.

  Update the schema to remove the UNIQUE constraint.  I've done this in the git repository.

  It works for all other DBs...

  Alan DeKok.