Hi Hugh
I'm currently handling radius requests with the following clause:
----
#test clause for debugging bad authenticator errors
<Client 41.181.89.29>
Secret r4nd0m1
IgnoreAcctSignature
<AuthBy SQL>
DBSource dbi:Pg:dbname=dbrecords;host=localhost
DBUsername xxxxxx
DBAuth yyyyyyyy
AuthSelect
AccountingTable tablerecords
AcctColumnDef nasidentifier,NAS-Identifier
AcctColumnDef timestamp,Timestamp
SQLRecoveryFile /var/log/radius/acmemissedacctlog.%Y-%m-%d
</AuthBy>
</Client>
---
But I'm still seeing the error message, and no accounting responses to the
NAS/LB. The IgnoreAcctSignature doesn't seem to have any effect.
(I'm also noticing another oddity here, when I don't explicitly use the "Secret
...." statement in the Client clause, Radiator authentication of the client
fails with "ERR: No Secret or TACACSPLUSKey defined for Client", even though I
can see from the debug that Radiator is successfully selecting the secret from
the postgresql database)
Is it possible this error is due to another auth failure other than a packet
signature check failure?
Let me know if there's any further information I can send through that might
shed more light on the issue!
Thanks,
Traiano
PS.: I tried the ignoreacctsignature paramater in the ClientListSQL clause,
changing the postgresql column data type to "text" and setting it to a value
of 1, but it seems the parameter has no effect.
________________________________________
From: Hugh Irvine [[email protected]]
Sent: Sunday, May 20, 2012 2:26 AM
To: Traiano Welcome
Cc: [email protected]
Subject: Re: [RADIATOR] [ "WARNING: Bad authenticator in request from .." on
CentOS host]
Hello Traiano -
For testing purposes I would suggest using a Client clause in the configuration
file so you know exactly what is happening.
For your ClientListSQL I'm not sure about using boolean for the field - I would
suggest text instead.
regards
Hugh
On 19 May 2012, at 19:47, Traiano Welcome wrote:
> Hi Hugh
>
> Thanks for your response!
>
> I don't use the Client clause (I'm using the Handler clause to match
> NAS-Identifiers), but I see one can use this in the ClientListSQL clause as
> I've done below:
>
> ---
> <ClientListSQL>
> DBSource dbi:Pg:dbname=<hidden>;host=localhost
> DBUsername <redacted>
> DBAuth <obscured>
> GetClientQuery select nas_ip,secret,ignoreacctsignature,dupinterval
> from naslist
> </ClientListSQL>
> ---
>
> ... with a corresponding modification from my "naslist" table as follows:
>
> ---
> Table "public.naslist"
>
> Column | Type | Modifiers
> ---------------------+---------+--------------
> nas_ip | inet | not null
> secret | text | not null
> ignoreacctsignature | boolean | default true
> dupinterval | integer | default 2
> hostname | text |
> description | text |
> ---
>
> Example:
>
> --
> nas_ip | secret | ignoreacctsignature | dupinterval
> ----------------+-----------+---------------------+-------------
> loa.dba.lan.cer | <redacted> | t | 2
> --
>
>
> However I'm still seeing the "WARNING: Bad authenticator in request from ..."
> messages after restarting radius several times. How can I debug this further
> ?
>
> I see the "IgnoreAcctSignature" is not supported in the Handler statement.
>
> Traiano
>
>
>
> ________________________________________
> From: Hugh Irvine [[email protected]]
> Sent: Saturday, May 19, 2012 6:45 AM
> To: Traiano Welcome
> Cc: [email protected]
> Subject: Re: [RADIATOR] (no subject)
>
> Hello Traiano -
>
> You can try setting "IgnoreAcctSignature" in the client clause in the Centos
> Radiator configuration.
>
> See section 5.7.3 in the Radiator 4.9 reference manual ("doc/ref.pdf").
>
> regards
>
> Hugh
>
>
> On 19 May 2012, at 10:15, Traiano Welcome wrote:
>
>> Hi List
>>
>> I have a a 'cluster' of 5 Radiator radius servers behind a FreeBSD server
>> running Radiator in load balancing configuration. The radius servers behind
>> the load balancer do authentication and accounting, 4 of them are freebsd
>> running in vmware VMs and the fifth is a CentOS physical host. While I see
>> the FreeBSD radius auth/acct servers are handling requests correctly,
>> logging accounting to a postgresql database, I am seeing all the accounting
>> requests proxied via the load-balancer to the CentOS host fail with the
>> following error in the logs:
>>
>> ---
>> Sat May 19 00:50:51 2012: WARNING: Bad authenticator in request from
>> lo.ad.bal.ancer (na.s.100.20)
>> Sat May 19 00:50:51 2012: WARNING: Bad authenticator in request from
>> lo.ad.bal.ancer (na.s.100.20)
>> Sat May 19 00:50:51 2012: WARNING: Bad authenticator in request from
>> lo.ad.bal.ancer (na.s.0.100)
>> Sat May 19 00:50:52 2012: WARNING: Bad authenticator in request from
>> lo.ad.bal.ancer (na.s.0.100)
>> ---
>>
>> No accounting packets are being logged to the postgresql database on the
>> CentOS host, as a consequence (?)
>>
>> Normally I would expect this to be due to a mismatch in secrets between the
>> NAS (here being the Radiator load balancer?) and the auth'ing/accounting
>> radiator server, however the secret configured on the freebsd server is
>> identical to that on the CentOS host and the radiator load balancer, and the
>> FreeBSD radius server is auth'ing and accounting successfully.
>>
>> Running tcpdump on each system, I can see the following:
>>
>> - The FreeBSD load-balancer is sending accounting requests to the CentOS
>> load balancer, but is seeing no responses in return
>> - The CentOS auth/acct server is seeing requests from the load-balancer is
>> not sending accounting response packets back to the load balancer
>> - The FreeBSD auth/acct server is happily receiving accounting requests and
>> sending responses from the load-balancer
>>
>> So free flow of radius packets between the load-balancer and the CentOS
>> radiator server is unlikely to be the issues ... After, all, no responses
>> are being sent out by the CentOS host in the first place.
>>
>> The details of the load balancer and the two radius accounting/auth servers
>> behind it are as follows:
>>
>> 1) FreeBSD Load Balancer server (Radiator Configured as a load balancer)
>>
>> - FreeBSD 8.2-RELEASE-p6 #0
>> - PERL (v5.12.4) built for amd64-freebsd
>> - p5-Digest-MD5-2.51
>>
>> 2) FreeBSD Radiator server handling RADIUS packets from the Load Balancer
>> (Radiator configured to auth from and account to a local postgresql database)
>>
>> - FreeBSD 8.2-RELEASE-p4 #2
>> - PERL (v5.12.4) built for amd64-freebsd-thread-multi
>> - postgres (PostgreSQL) 8.4.10
>> - p5-Digest-MD5-2.51
>>
>> 3) CentOS Radiator Server handling RADIUS packets from the Load Balancer
>> (Radiator configured to auth from and account to a local postgresql database)
>>
>> - CentOS release 6.2 (Final), 2.6.32-220.el6.x86_64 #1 SMP
>> - v5.10.1 (*) built for x86_64-linux-thread-multi
>> - (PostgreSQL) 8.4.10
>> - Digest::MD5 (2.51)
>> - perl-Net-SSLeay-1.35-9.el6.x86_64
>> - perl-Digest-HMAC-1.01-22.el6.noarch
>> - perl-DBI-1.609-4.el6.x86_64
>> - perl-DBD-Pg-2.15.1-3.el6.x86_64
>>
>> Attached are the radiator configurations for each of the above servers:
>>
>> 1. My FreeBSD Load balancer's Radiator configuration:
>> 2. The Radiator configuration on a working freebsd server:
>> 3. The Radiator configuration on the CentOS server:
>>
>> I've tried the following tests to confirm if this isn't a software/library
>> issue:
>>
>> - reinstalled postgresql, Radiator and the associated PERL libraries a
>> number of times, testing different combinations of package versions - no luck
>> - tried CPAN perl libraries instead of the centos yum perl modules
>> - installed radiator from source and using the rpm package
>> - tried radiator 4.8 and 4.9
>> - Postgresl 8.4 and 9.2 from source and rpm
>> - Confirmed database connectivity between Radiator and Postgresql
>> - Upping the radiator Trace level to 5 doesn't reveal any actual details of
>> possible cause of failure other than a dump of the radius accounting-request
>> packet (that I can recognise anyway :p)
>>
>> I'd be grateful if someone could point out a likely cause of the CentOS
>> Radiator servers non-response to accounting-requests, or suggest some
>> additional detailed debugging techniques I could use?
>>
>> Let me know if I should send some packet traces in addition to the above!
>>
>> Many Thanks in advance!
>> Traiano
>>
>>
>>
>> <freebsd-auth-acct-host-radiusd.cfg><freebsd-load-balancer-radiator.cfg><centos-host-radiusd.cfg>_______________________________________________
>> radiator mailing list
>> [email protected]
>> http://www.open.com.au/mailman/listinfo/radiator
>
>
> --
>
> Hugh Irvine
> [email protected]
>
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
> DIAMETER etc.
> Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
>
--
Hugh Irvine
[email protected]
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc.
Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
_______________________________________________
radiator mailing list
[email protected]
http://www.open.com.au/mailman/listinfo/radiator
