Unable to authenticate freeradius using PostgreSQL

[Ross McOwat]

Hi Kevin,

I am running debug with the -X flag - in this instance, I only included
the output I thought relevant (probably a mistake).  Complete output
from the radius authentication request (with 3 attempts set) is as
follows:

rad_recv: Access-Request packet from host 10.150.19.134:2250, id=0,
length=49
        User-Name = "ROSStest4"
        User-Password = "nntlpa401"
  Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 0
  modcall[authorize]: module "preprocess" returns ok for request 0
  modcall[authorize]: module "chap" returns noop for request 0
  modcall[authorize]: module "mschap" returns noop for request 0
    rlm_realm: No '@' in User-Name = "ROSStest4", looking up realm NULL
    rlm_realm: No such realm "NULL"
  modcall[authorize]: module "suffix" returns noop for request 0
  rlm_eap: No EAP-Message, not doing EAP
  modcall[authorize]: module "eap" returns noop for request 0
    users: Matched DEFAULT at 156
  modcall[authorize]: module "files" returns ok for request 0
radius_xlat:  'ROSStest4'
rlm_sql (sql): sql_set_user escaped user --> 'ROSStest4'
radius_xlat:  ''
rlm_sql (sql): Reserving sql socket id: 4
rlm_sql (sql): SQL query error; rejecting user
rlm_sql (sql): Released sql socket id: 4
  modcall[authorize]: module "sql" returns fail for request 0
modcall: group authorize returns fail for request 0
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 6 seconds...
rad_recv: Access-Request packet from host 10.150.19.134:2250, id=0,
length=49
Discarding duplicate request from client ROSSpc:2250 - ID: 0
--- Walking the entire request list ---
Waking up in 3 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 0 with timestamp 456c68e0
Nothing to do.  Sleeping until we see a request.
rad_recv: Access-Request packet from host 10.150.19.134:2250, id=0,
length=49
        User-Name = "ROSStest4"
        User-Password = "nntlpa401"
  Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 1
  modcall[authorize]: module "preprocess" returns ok for request 1
  modcall[authorize]: module "chap" returns noop for request 1
  modcall[authorize]: module "mschap" returns noop for request 1
    rlm_realm: No '@' in User-Name = "ROSStest4", looking up realm NULL
    rlm_realm: No such realm "NULL"
  modcall[authorize]: module "suffix" returns noop for request 1
  rlm_eap: No EAP-Message, not doing EAP
  modcall[authorize]: module "eap" returns noop for request 1
    users: Matched DEFAULT at 156
  modcall[authorize]: module "files" returns ok for request 1
radius_xlat:  'ROSStest4'
rlm_sql (sql): sql_set_user escaped user --> 'ROSStest4'
radius_xlat:  ''
rlm_sql (sql): Reserving sql socket id: 3
rlm_sql (sql): SQL query error; rejecting user
rlm_sql (sql): Released sql socket id: 3
  modcall[authorize]: module "sql" returns fail for request 1
modcall: group authorize returns fail for request 1
Finished request 1
Going to the next request
--- Walking the entire request list ---
Waking up in 6 seconds...
--- Walking the entire request list ---
Cleaning up request 1 ID 0 with timestamp 456c68e7
Nothing to do.  Sleeping until we see a request.


I may be missing something obvious, but for the life of me I cannot see
what it is.  My head is starting to hurt now!

Ross

-----Original Message-----
From:
freeradius-users-bounces+ross.mcowat=first-utility.com at lists.freeradius.
org
[mailto:freeradius-users-bounces+ross.mcowat=first-utility.com at lists.fre
eradius.org] On Behalf Of Kevin Bonner
Sent: 28 November 2006 16:40
To: FreeRadius users mailing list
Subject: Re: Unable to authenticate freeradius using PostgreSQL

On Tuesday 28 November 2006 11:00, Ross McOwat wrote:
> Other tables are empty.  Running freeradius in debug mode, the
following
> output is given when attempting an authentication request using
> NTRadPing:

That output is very brief for "debug" mode.  You are using the -X flag,
right?  
If not, do so and you'll see why it's dying in the rlm_sql module.

Kevin Bonner