[RADIATOR] [ "WARNING: Bad authenticator in request from .." on CentOS host]

Hugh Irvine hugh at open.com.au
Sun May 20 18:04:18 CDT 2012


Hello Traiano -

For your testing you should be using a separate configuration file using only the minimum you are trying to test.

You can do this either on a lab machine (preferable), or using different port numbers.

The idea being to use only the configuration file elements you are trying to test.

I generally start with "goodies/simple.cfg" on my laptop for first pass testing.

BTW - what version of Radiator are you running?

regards

Hugh


On 20 May 2012, at 21:54, Traiano Welcome wrote:

> 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 [hugh at open.com.au]
> Sent: Sunday, May 20, 2012 2:26 AM
> To: Traiano Welcome
> Cc: radiator at open.com.au
> 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 [hugh at open.com.au]
>> Sent: Saturday, May 19, 2012 6:45 AM
>> To: Traiano Welcome
>> Cc: radiator at open.com.au
>> 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
>>> radiator at open.com.au
>>> http://www.open.com.au/mailman/listinfo/radiator
>> 
>> 
>> --
>> 
>> Hugh Irvine
>> hugh at open.com.au
>> 
>> 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
> hugh at open.com.au
> 
> 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
hugh at open.com.au

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.



More information about the radiator mailing list