Send Access-Reject when user does not match any group?
Bogdan Enache
enachebogdan at gmx.com
Fri Jan 18 10:34:00 CET 2013
Hi again.
Has anyone found a solution to this (always sending Access-Reject to
users not matching any group)?
Thanks!
Pe 15.01.2013 13:37, Bogdan Enache a scris:
> 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
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
More information about the Freeradius-Users
mailing list