Blank Password Problem

Satyam Mathura satz.sm at gmail.com
Sat Jan 23 15:46:02 CET 2010


a little help here guys???

On Fri, Jan 22, 2010 at 9:58 AM, Satyam Mathura <satz.sm at gmail.com> wrote:

> OK i'm back to my original question.
> How do i get FreeRadius working with a MySQL back-end to do the following:
> a. Reject a user if that user is in a group which is not allowed to access
> devices in a specific huntgroup.
> b. Allow a user if that user is in the appropriate group which is allowed
> to access devices in a specific huntgroup.
> c. Do not allow blank passwords for users.
>
> As stated before my huntgroup & radgroupcheck configs look like
>
> my radhuntgroup config:
> +----+-----------+------------
> ----+----------------+------------------+
> | id | groupname | nasipaddress   | nasportid      | usergroup        |
> +----+-----------+----------------+----------------+------------------+
> |  1 | admin     | 192.168.1.1           | tty            |
> engineeringadmin |
>
>
> my radgroupcheck config:
> +----+------------------+----------------+----+----------------+
> | id | groupname        | attribute      | op | value                 |
> +----+------------------+----------------+----+----------------+
> |  5 | engineeringadmin | Huntgroup-Name | == | admin     |
> |  6 | engineeringadmin | Auth-Type      | := | Accept         |
>
>
> Based on the help of previous posters, Rule 6 in radgroupcheck allows users
> to access a nas once their username is correct even if they supply a blank
> password.
> There must be a way around this. What am i doing wrong?
>
>
>
> On Thu, Jan 21, 2010 at 7:28 PM, Satyam Mathura <satz.sm at gmail.com> wrote:
>
>> Quick update.
>> Although the radius server no longer accepts blank passwords, i now have a
>> problem where users who belong to groups which are not allowed to access nas
>> devices in certain huntgroups can now do so.
>> Any ideas?
>>
>>
>> On Thu, Jan 21, 2010 at 7:14 PM, Satyam Mathura <satz.sm at gmail.com>wrote:
>>
>>> The reason i had those configs was because they were outlined as steps to
>>> reject authentication by default in the guide i was using.
>>>
>>> http://wiki.freeradius.org/SQL_Huntgroup_HOWTO
>>>
>>> "Note: If you want to reject authentication by default then edit the
>>> raddb/users file and add this:
>>>
>>> DEFAULT   Auth-Type := Reject
>>>
>>> Then add Auth-Type Accept with := as op in radgroupcheck for each group"
>>>
>>>
>>> I've commented out the DEFAULT   Auth-Type := Reject in the users file
>>>
>>> and removed the Auth-Type  :=  Accept from the radgroupcheck table and
>>> the server no longer accepts a blank password.
>>>
>>>
>>> Guide is incorrect or needs updating?
>>>
>>> Thanks for the help guys.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jan 21, 2010 at 6:58 PM, Bjørn Mork <bjorn at mork.no> wrote:
>>>
>>>> Satyam Mathura <satz.sm at gmail.com> writes:
>>>>
>>>> > Line 204 in my users file is the following:
>>>> > DEFAULT   Auth-Type := Reject
>>>>
>>>> You don't want that.  It removes the server's ability to figure it out
>>>> by itself.
>>>>
>>>>
>>>> > my radgroupcheck config:
>>>> > +----+------------------+----------------+----+----------------+
>>>> > | id | groupname        | attribute      | op | value
>>>> |
>>>> > +----+------------------+----------------+----+----------------+
>>>> > |  5 | engineeringadmin | Huntgroup-Name | == | admin     |
>>>> > |  6 | engineeringadmin | Auth-Type      | := | Accept         |
>>>>
>>>> Why? This will make the server act as you describe: Any username in the
>>>> engineeringadmin group will be accepted regardless of password.
>>>>
>>>>
>>>> Bjørn
>>>>
>>>> -
>>>> List info/subscribe/unsubscribe? See
>>>> http://www.freeradius.org/list/users.html
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20100123/ccbc110f/attachment.html>


More information about the Freeradius-Users mailing list