Hello Christian -
We have occasionally seen similar problems that appear to be caused by race
conditions when a file is overwritten in place and the modification time
changes before the file is completely copied. My suggestion in the past has
been to copy the new file onto the machine with a different name and then
rename both files. Can you tell me what hardware and software platform you are
running on?
thanks
Hugh
On Wed, 23 Aug 2000, Christian Hammers wrote:
> Hello list
>
> We're using the AuthBy block which is attached below. As we're using two
> radiator servers we modify one users file in a third machine and then
> let scp distribute it (after some slightly automated modfications) to our
> two radiator servers which then reload them automatically.
>
> This normally works very well.
>
> Now we encountered a problem twice times in the last week: After reloading
> the Files at 09:00h in the morning
> Wed Aug 23 09:00:23 2000: DEBUG: Reading users file /etc/radiator/export.parrot0
> the radiator servers refused to authenticate our dialin users. They got a
> correct AuthRequest:
> Code: Access-Request
> ...
> User-Name = "pp10209a"
> CHAP-Password = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
> Service-Type = Framed-User
> Framed-Protocol = PPP
> State = ""
> Calling-Station-Id = "xxxxxxxxxx"
> Called-Station-Id = "xxxx70"
> Framed-IP-Address = 212.117.65.46
> Acct-Session-Id = "287612748"
> Then the passwords file shows me the following:
> Wed Aug 23 09:00:29 2000:967014029:pp10209a:UNKNOWN:xxxxxxxx:PASS
> Wed Aug 23 09:00:29 2000:967014029:pp10209a:UNKNOWN:xxxxxxxx:PASS
> Wed Aug 23 09:00:29 2000:967014029:pp10209a:UNKNOWN:xxxxxxxx:PASS
> Yes, three times! And here is what radiator does then:
> Wed Aug 23 09:00:29 2000: DEBUG: Handling with Radius::AuthFILE
> Wed Aug 23 09:00:29 2000: DEBUG: Radius::AuthFILE looks for match with pp10209a
> Wed Aug 23 09:00:29 2000: DEBUG: Handling with Radius::AuthFILE
> Wed Aug 23 09:00:29 2000: DEBUG: Radius::AuthFILE looks for match with pp10209a
> Wed Aug 23 09:00:29 2000: DEBUG: Radius::AuthFILE REJECT: Check item Called-Stat
> ion-Id expression '91837' does not match '918370' in request
>
> You see, in the first AuthFile line it MUST have found the entry because
> it knew the right password and wrote PASS into the password logfile.
> But there was neither an accept nor an deny.
> The following Files correctly deny the user as we don't allow every user
> to dialin every nummer (we have tollfree and normal dialins!)
>
>
> So why gives AuthFILE no answer?!
> My collegues told me that after a simple "kill -HUP" of the radiator it
> worked again.
>
> bye,
>
> -christian-
>
>
>
> Here the radiator.conf block:
> ...
> AuthByPolicy ContinueUntilAccept
> <AuthBy FILE>
> Filename %D/export.parrot0
> </AuthBy>
> <AuthBy FILE>
> Filename %D/export.parrot
> </AuthBy>
> <AuthBy FILE>
> Filename %D/export.magpie0
> </AuthBy>
> <AuthBy FILE>
> Filename %D/export.magpie
> </AuthBy>
> <AuthBy LDAP2>
> ...
>
>
> --
> Christian Hammers WESTEND GmbH - Aachen und Dueren Tel 0241/701333-0
> [EMAIL PROTECTED] Internet & Security for Professionals Fax 0241/911879
> WESTEND ist CISCO Systems Partner - Premium Certified
>
> ===
> Archive at http://www.starport.net/~radiator/
> Announcements on [EMAIL PROTECTED]
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body of the message.
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
