along at escapewire.com
Fri Nov 10 01:30:33 CET 2006
> On Thursday 09 November 2006 11:34, Andrew Long wrote:
>> also ran
>> from usergroup
>> where username = '4aroma70370';
>> and that also comes up null...
>> Does it make sense that radius is not recognizing the usernames as
>> belonging to the group 'aroma', thus not assigning the group-reply?
> Yes, because the radius server does what you configure it to do. You should
> have control over the usergroup table, so it shouldn't be difficult to add
> the missing records.
> If you're still stuck, try sending relevant output from all of your sql
> tables. The actual row data should be good enough, unless you've mangled the
> table structure to suit local needs.
>> This is my current thought on this, but I'm not sure why it would
>> still authorize the request, unless it's not necessary that users be
>> part of group.
> It isn't necessary. The cleartext password needed for CHAP was provided by a
> module (users, sql, ??), so the access request was accepted.
> Kevin Bonner
I have verified that there are indeed username-password pairs in
radreply where those unsernames do not exist in 'usergroups'. Here is
what I propose and I'd like confirmation that my thinking is accurate
before I do it...
First, I grabbed all the usernames from radcheck for the given
property. Then I write a script to insert them into usergroup (with
other appropriate values), which I run after clearing the usergroup
table of all records where the group is the one I am interested in.
DELETE FROM radius.usergroup WHERE GroupName = 'aroma'
INSERT INTO radius.usergroup (UserName, CreationDate, GroupName)
VALUES ('username0001', (CURRENT_DATE), 'aroma');
repeated for all 500 usernames...
I think this should work, as all the usernames in use are stored in
radcheck and I'm not touching that table at all. Worst case scenario,
users continue to authenticate without a session limit and I go back
DOES THIS SOUND RIGHT?
More information about the Freeradius-Users