trivial problem?

[Yans van Horn]

Alan DeKok <aland at deployingradius.com> wrote:
> Yans van Horn wrote:
>
>> I'm trying to get EAP-TLS to work, and when using "file" setup
>> everything works as it's suppose to - only selected users can
>> authorize after meeteing check criteria.
>>
>> When i switch to SQL (postgresql) it seems that no matter what i
>> insert to radcheck and radreply tables *any user (if he has valid
>> cert) can authorize without any problems* :-(
>
>  The SQL module doesn't work in the same way as the users file,
> unfortunately.  So you can't just translate the "users" file entries
> to a bunch of SQL rows, and expect it to do exactly the same thing.

Thats for sure. According to docs:

  1. Search the radcheck table for any check attributes specific to the user
  2. If check attributes are found, and there's a match, pull the reply 
items
     from the radreply table for this user and add them to the reply
  3. Group processing then begins if any of the following conditions are 
met:
     a. The user IS NOT found in radcheck
     b. The user IS found in radcheck, but the check items don't match
     c. The user IS found in radcheck, the check items DO match AND
        the read_groups directive is set to 'yes'
  4. If groups are to be processed for this user, the first thing that is
     done is the list of groups this user is a member of is pulled from the
     usergroup table ordered by the priority field.  The priority field of
     the usergroup table allows us to control the order in which groups are
     processed, so that we can emulate the ordering in the users file.  This
     can be important in many cases.
  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.
  6. Processing continues to the next group IF:
     a. There was not a match for the last group's check items
     (The above is exactly the same as in the users file)
  7. Finally, if the user has a User-Profile attribute set or the Default
     Profile option is set in the sql.conf, then steps 4-6 are repeated for
     the groups that the profile is a member of.

If i understand correctly, setting:

sql
{
    ....
    default_user_profile = "DEFAULT"
}

And:

radius=> select * from radcheck order by id;
 id  | username |     attribute      | op |     value
-----+----------+--------------------+----+---------------
 410 | ajax     | Auth-Type          | := | EAP
 411 | ajax     | Calling-Station-ID | == | -----
 413 | revoked  | Auth-Type          | := | EAP
 414 | revoked  | Calling-Station-ID | == | -----
 420 | DEFAULT  | Auth-Type          | := | Reject
(5 rows)

radius=> select * from radreply order by id;
 id | username |   attribute   | op |     value
----+----------+---------------+----+---------------
  3 | DEFAULT  | Reply-Message | =  | ACCESS DENIED
(1 row)

radius=> select * from radgroupcheck order by id;
 id | groupname | attribute | op | value
----+-----------+-----------+----+--------
  2 | wifi      | Auth-Type | := | Reject
(1 row)

radius=> select * from radgroupreply order by id;
 id | groupname |   attribute   | op |     value
----+-----------+---------------+----+---------------
  1 | wifi      | Reply-Message | = | ACCESS DENIED
(1 row)

radius=> select * from usergroup order by id;
 id | username | groupname
----+----------+-----------
  1 | revoked  | wifi
  2 | ajax     | wifi
(2 rows)


This should prevent _any_ user from authenticating, but "ajax", "revoked" 
certs allow access. If i understand correctly auth should look like 
something like this:

- cert revocation should reject "revoked"
- users should not match
- groups should match and should reject
- default user should match and reject (if checked after group matched)

That's at least strange or above config is completely screwed. If so, please 
show me correct table contents for earlier "users" file.

-- 
regards,
Marcin 'Yans' Bazarnik