(RADIATOR) Radiator Thinks User Password Should be "update"
Hugh Irvine
hugh at open.com.au
Thu Sep 21 18:45:02 CDT 2006
Hello Jason -
The default behaviour of Radiator is to check a user and if there is
a reject to then go on and check the DEFAULT user(s).
If you are not using the DEFAULT user, you should add NoDefault to
your AuthBy clause.
<Handler Realm=pxs>
AuthByPolicy ContinueWhileAccept
RewriteUsername s/\@pxs//
AuthBy PxsFilterAndAccounting
SessionDatabase sessionDB
FramedGroup 2
AuthLog globalauthlog
PasswordLogFileName /var/log/radiator/norlm-pass.log
</Handler>
<AuthBy SQL>
Identifier PxsFilterAndAccounting
AccountingTable accounting
AcctColumnDef USERNAME, User-Name
AcctColumnDef TIME_STAMP Timestamp, timestamp
AcctColumnDef ACCTSTATUSTYPE, Acct-Status-Type
AcctColumnDef ACCTDELAYTIME, Acct-Delay-Time, integer
AcctColumnDef ACCTINPUTOCTETS, Acct-Input-Octets, integer
AcctColumnDef ACCTOUTPUTOCTETS, Acct-Output-Octets, integer
AcctColumnDef ACCTSESSIONID, Acct-Session-Id
AcctColumnDef ACCTSESSIONTIME, Acct-Session-Time, integer
AcctColumnDef ACCTTERMINATECAUSE, Acct-Terminate-Cause
AcctColumnDef NASIDENTIFIER, NAS-IP-Address
AcctColumnDef NASPORT, NAS-Port, integer
AcctColumnDef FRAMEDIPADDRESS, Framed-IP-Address
AcctColumnDef CONNECTINFO, Connect-Info
AcctColumnDef CALLERID, Calling-Station-Id
AcctColumnDef CALLEDID, Called-Station-Id
AcctColumnDef TERMINATEDETAIL, LE-Terminate-Detail
AuthColumnDef 0, Password, check
AuthColumnDef 1, Idle-Timeout, reply
AuthColumnDef 2, Session-Timeout, reply
AuthColumnDef 3, Simultaneous-Use, check
AuthColumnDef 4, Framed-IP-Address, reply
AuthColumnDef 5, Framed-Route, reply
AuthColumnDef 6, Framed-Routing, reply
AuthSelect select PASSWORD, IDLETIME, MAXLOGTIME, SIMULTANEOUS,
IPADDR, FRAMEDROUTE, FRAMEDROUTING from subscribers where USERNAME='%n'
and STATE!='1'
DBSource dbi:mysql:radius:localhost
DBUsername *removed*
DBAuth *removed*
FailureBackoffTime 30
Timeout 30
CaseInsensitivePasswords
DefaultSimultaneousUse 2
# turn off DEFAULT lookups
NoDefault
</AuthBy>
hope that helps
regards
Hugh
On 22 Sep 2006, at 08:26, Jason Haltom wrote:
> Howdy all,
>
> Not sure on the best way to show logs for this. But some time within
> the last month or so Radiator has randomly started thinking some
> people
> should be using the password "update" even though the user's password
> clearly is not. It is not consistent with who it does this too. It
> does this across all of our realms that use the authby sql clause.
>
> Example password log file:
> Mon Sep 11 14:39:41 2006:1158003581:bjs66:bjohn:bjohn66:FAIL
> Mon Sep 11 14:39:41 2006:1158003581:bjs66:bjohn:update:FAIL
> Mon Sep 11 14:40:29 2006:1158003629:bjs66:bjohn66:bjohn66:PASS
>
> As you can see the first time the customer tried logging in
> Radiator was
> looking at the correct password but the user typed the wrong one. The
> second time it thought the password should be "update" and the third
> time the password was ok with both the user and Radiator.
>
> Follow the user "alliswell", you can see only they had problems for a
> 6min period in this log.
> Tue Sep 19 16:54:05 2006:1158702845:surface:nikki:nikki:PASS
> Tue Sep 19 16:55:26 2006:1158702926:alliswell:kalani1:update:FAIL
> Tue Sep 19 16:55:30 2006:1158702930:snapps:tiki13:tiki13:PASS
> Tue Sep 19 16:56:26 2006:1158702986:alliswell:kalani1:update:FAIL
> Tue Sep 19 16:56:27 2006:1158702987:olnb:orasa76:orasa76:PASS
> Tue Sep 19 16:56:48 2006:1158703008:kooljax:wyoming79:wyoming79:PASS
> Tue Sep 19 16:57:22 2006:1158703042:alliswell:kalani1:update:FAIL
> Tue Sep 19 17:01:25 2006:1158703285:njs6415:pepper:pepper:PASS
> Tue Sep 19 17:01:28 2006:1158703288:hldalke:herman:herman:PASS
> Tue Sep 19 17:01:29 2006:1158703289:br16:cclr0301:cclr0301:PASS
> Tue Sep 19 17:03:38 2006:1158703418:alliswell:kalani1:kalani1:PASS
> User tried 4 times, the first 3 failed as the system thought their
> password should be "update".
>
> We are using a simple MySQL query to pull the user info and
> authenticate.
> There is only 1 user in the database with the password of "update",
> username is "default". Not sure where that username is from, maybe it
> just got left in from the initial database setup. However it
> should not
> be pulling that password for random users.
>
> Config:
> <Client 192.168.10.202>
> PacketTrace
> Description Some NAS
> FramedGroupBaseAddress 192.168.10.210
> FramedGroupBaseAddress 192.168.10.220
> FramedGroupBaseAddress 192.168.10.230
> Secret SomeSecret
> DefaultRealm pxs
> NasType unknown
> </Client>
> <Handler Realm=pxs>
> AuthByPolicy ContinueWhileAccept
> RewriteUsername s/\@pxs//
> AuthBy PxsFilterAndAccounting
> SessionDatabase sessionDB
> FramedGroup 2
> AuthLog globalauthlog
> PasswordLogFileName /var/log/radiator/norlm-pass.log
> </Handler>
> <AuthBy SQL>
> Identifier PxsFilterAndAccounting
> AccountingTable accounting
> AcctColumnDef USERNAME, User-Name
> AcctColumnDef TIME_STAMP Timestamp, timestamp
> AcctColumnDef ACCTSTATUSTYPE, Acct-Status-Type
> AcctColumnDef ACCTDELAYTIME, Acct-Delay-Time, integer
> AcctColumnDef ACCTINPUTOCTETS, Acct-Input-Octets, integer
> AcctColumnDef ACCTOUTPUTOCTETS, Acct-Output-Octets, integer
> AcctColumnDef ACCTSESSIONID, Acct-Session-Id
> AcctColumnDef ACCTSESSIONTIME, Acct-Session-Time, integer
> AcctColumnDef ACCTTERMINATECAUSE, Acct-Terminate-Cause
> AcctColumnDef NASIDENTIFIER, NAS-IP-Address
> AcctColumnDef NASPORT, NAS-Port, integer
> AcctColumnDef FRAMEDIPADDRESS, Framed-IP-Address
> AcctColumnDef CONNECTINFO, Connect-Info
> AcctColumnDef CALLERID, Calling-Station-Id
> AcctColumnDef CALLEDID, Called-Station-Id
> AcctColumnDef TERMINATEDETAIL, LE-Terminate-Detail
> AuthColumnDef 0, Password, check
> AuthColumnDef 1, Idle-Timeout, reply
> AuthColumnDef 2, Session-Timeout, reply
> AuthColumnDef 3, Simultaneous-Use, check
> AuthColumnDef 4, Framed-IP-Address, reply
> AuthColumnDef 5, Framed-Route, reply
> AuthColumnDef 6, Framed-Routing, reply
> AuthSelect select PASSWORD, IDLETIME, MAXLOGTIME, SIMULTANEOUS,
> IPADDR, FRAMEDROUTE, FRAMEDROUTING from subscribers where
> USERNAME='%n'
> and STATE!='1'
> DBSource dbi:mysql:radius:localhost
> DBUsername *removed*
> DBAuth *removed*
> FailureBackoffTime 30
> Timeout 30
> CaseInsensitivePasswords
> DefaultSimultaneousUse 2
> </AuthBy>
>
>
> Anyone have any ideas on this?
>
> Thanks,
> Jason
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.405 / Virus Database: 268.12.6/453 - Release Date:
> 9/20/2006
>
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
NB:
Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.
--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
More information about the radiator
mailing list