Send Access-Reject when user does not match any group?

[Bogdan Enache]

Hi list,
I have managed to solve the last problem by replacing "Group" with 
"SQL-Group", like so:
DEFAULT SQL-Group == "disabled", Auth-Type := Reject
         Reply-Message := "Your account is disabled.",
         Fall-Through := No
Now users which are in the "disabled" group get Access-Reject, which is 
fine.

But SQL-Group doesn't seem to be documented anywhere, I only found it by 
accident on another thread from 2011. Searching the wiki for it yields 0 
results. I guess this should be documented somewhere.

Anyway, sending Access-Reject to users not belonging to any group still 
doesn't work. I've tried:
DEFAULT SQL-Group !* "", Auth-Type := Reject
         Reply-Message := "Your account is not in any usable groups.",
         Fall-Through := No

According to the wiki, the operator !* : "As a check item, it matches if 
the request does not contain the named attribute, no matter what the 
value is.". In this context the operator does not seem to be working as 
expected, it doesn't match, although it should.

Considering that the attribute SQL-Group might be present though, but 
empty, I also tried with SQL-Group == "", SQL-Group == null and 
SQL-Group == "NULL" and other variations, those aren't working either.

-- Bogdan E.


Pe 15.01.2013 11:47, Bogdan Enache a scris:
> Hi, I tried something else today.
>
> I created in SQL a group named "disabled", with no check items, only a 
> Reply-Message.
> A put a user in that group.
> I put a rule in the "users" file (commenting everything else out):
>
> DEFAULT Group == "disabled", Auth-Type := Reject
>         Reply-Message := "Your account has been disabled.",
>         Fall-Through := No
>
> But it isn't working, freeradius sends Acces-Accept because it does 
> not match the rule in the "users" file. The group in SQL is matched. 
> Attaching related output:
>
> rad_recv: Access-Request packet from host 10.0.100.108 port 50995, 
> id=72, length=118
>         Service-Type = Login-User
>         User-Name = "bogdan.enache"
>         CHAP-Challenge = 0x737b6524979d8782cb9615dab30a99d1
>         CHAP-Password = 0x005eaa980bfb70736d8f9028506f462f11
>         Calling-Station-Id = "172.16.108.30"
>         NAS-Identifier = "MKI"
>         NAS-IP-Address = 10.0.100.108
> [..........]
> [sql]   expand: %{User-Name} -> bogdan.enache
> [sql] sql_set_user escaped user --> 'bogdan.enache'
> rlm_sql (sql): Reserving sql socket id: 6
> [..........]
> [sql]   expand: SELECT id, groupname, attribute,           Value, 
> op           FROM radgroupcheck           WHERE groupname = 
> '%{Sql-Group}'           ORDER BY id -> SELECT id, groupname, 
> attribute,           Value, op           FROM radgroupcheck           
> WHERE groupname = 'disabled' ORDER BY id
> [sql] User found in group disabled
> [sql]   expand: SELECT id, groupname, attribute,           value, 
> op           FROM radgroupreply           WHERE groupname = 
> '%{Sql-Group}'           ORDER BY id -> SELECT id, groupname, 
> attribute,           value, op           FROM radgroupreply           
> WHERE groupname = 'disabled' ORDER BY id
> rlm_sql (sql): Released sql socket id: 6
> ++[sql] returns ok
> ++[files] returns noop
> [..........]
> Login OK: [bogdan.enache/<CHAP-Password>] (from client MKI port 0 cli 
> 172.16.108.30)
>
> And mind you, this is an example from the freeradius wiki: 
> http://wiki.freeradius.org/guide/faq#How-do-I-deny-access-to-a-specific-user,-or-group-of-users?
>
> What is wrong here?
>
> Note: If I eliminate the Group check requirement the "files" module 
> matches (and sends Access-Reject), so the file is processed. But 
> clearly the Group check isn't working...
>
> Thanks!
>
>
> Pe 14.01.2013 15:43, Bogdan Enache a scris:
>> Hi,
>>
>> Pe 14.01.2013 15:17, A.L.M.Buxey at lboro.ac.uk a scris:
>>> Hi,
>>>
>>>> As you can see, it matches the rule in "users" first, and then the
>>>> group named "login" in MySQL. There is no other match.
>>> because thats the order that you have them run in.... how can the users
>>> file know anything about the groups if you are doing the groups AFTER
>>> the users file?  change the order or put some other configuratin into
>>> place - eg use unlang after the sql section to check for group and 
>>> if one
>>> doesnt exist them reject - man unlang
>>>
>>
>> I already tried that, I put "sql" before "files" in "authorize" 
>> section in both "default" and "inner-tunnel":
>>
>> [sql]   expand: %{User-Name} -> bogdan.enache
>> [sql] sql_set_user escaped user --> 'bogdan.enache'
>> rlm_sql (sql): Reserving sql socket id: 5
>> [sql]   expand: SELECT id, username, attribute, value, op FROM 
>> radcheck           WHERE username = '%{SQL-User-Name}' ORDER BY id -> 
>> SELECT id, username, attribute, value, op FROM radcheck           
>> WHERE username = 'bogdan.enache'           ORDER BY id
>> [sql] User found in radcheck table
>> [sql]   expand: SELECT id, username, attribute, value, op FROM 
>> radreply           WHERE username = '%{SQL-User-Name}' ORDER BY id -> 
>> SELECT id, username, attribute, value, op FROM radreply           
>> WHERE username = 'bogdan.enache'           ORDER BY id
>> [sql]   expand: SELECT groupname           FROM 
>> radusergroup           WHERE username = '%{SQL-User-Name}' ORDER BY 
>> priority -> SELECT groupname           FROM radusergroup           
>> WHERE username = 'bogdan.enache' ORDER BY priority
>> [sql]   expand: SELECT id, groupname, attribute, Value, op           
>> FROM radgroupcheck           WHERE groupname = 
>> '%{Sql-Group}'           ORDER BY id -> SELECT id, groupname, 
>> attribute,           Value, op           FROM radgroupcheck           
>> WHERE groupname = 'login' ORDER BY id
>> [sql] User found in group login
>> [sql]   expand: SELECT id, groupname, attribute, value, op           
>> FROM radgroupreply           WHERE groupname = 
>> '%{Sql-Group}'           ORDER BY id -> SELECT id, groupname, 
>> attribute,           value, op           FROM radgroupreply           
>> WHERE groupname = 'login' ORDER BY id
>> rlm_sql (sql): Released sql socket id: 5
>> ++[sql] returns ok
>> [files] users: Matched entry DEFAULT at line 209
>> ++[files] returns ok
>> ++[expiration] returns noop
>> ++[logintime] returns noop
>> [pap] WARNING: Auth-Type already set.  Not setting to PAP
>> ++[pap] returns noop
>> Found Auth-Type = Reject
>> Auth-Type = Reject, rejecting user
>>
>> Still rejecting.
>>
>> Thank you.
>>
>> -
>> List info/subscribe/unsubscribe? See 
>> http://www.freeradius.org/list/users.html
>
> -
> List info/subscribe/unsubscribe? See 
> http://www.freeradius.org/list/users.html