Hi Mike,

Mike McCauley schrieb:
> 
>[...]
> > > > 2. Question:
> > > > Is it possible, that the first host already sends the Accounting-Response
> > > > to the NAS, and the second host just stores the records and nothing else?
> > > Yes, that should be fine.
> >
> > The question is how? Is this done with the AuthByPolicy or how
> > can I do this? Can't find anything in the docu how to do this.
> > Sure, it is not the default behavior by 98% users needed.
> 
> OK, I see your question now. Sorry.
> 
> Normally, you would put the AuthBy RADIUS as the last AuthBy. It would then
> forward (just accounting in your case) to the other radius. And when that
> radius acknowledged, the first server would send that ack back to the original
> NAS.
>
 
Why do I get two replies only in this configuration and not always when
I have the "AuthByPolicy ContinueWhileAccept"?

My problem is the documentation under 6.18.1 AuthByPolicy:

The default is clearly described, but what happens
with "ContinueWhileAccept". If the first Auth Modul Accepts and the
second and so one, how many ACCESS-ACCEPTs are sent to the NAS,
or what module sends it, the first one, the last one or all?

What happens if only one modul (not the first) rejects,
what is sent to the NAS?

> But you are wondering how can you make the first server ack immediately,
> without waiting for the remote server to reply?
> 
> Well, we dont really recommend it, but you could put your <AuthBy RADIUS> as
> not the last AuthBy. That would make it forward to the remote server and then
> fall through to the next AuthBy (depending onthe AuthByPolicy, of course). The
> disadvantage of this is that _every_ accounting request from the NAS will get 2
> acknowledgements (one from the last AuthBy, and one from the AuthBy RADIUS when
> it gets its reply from the remote server)
> We dont really recomend this, since it better that if the accounting server
> dies, that the NAS gets no response and can try its secondard radius server.
> 
> [...]
> >
> > You solved my problem, but perhaps for you is this a hint that something
> > is strange with this behavior.
> 
> Well, its a standard dictionary attribute. I dont really understand why it was
> not in your dictionary. Which one were you using?

I concatenated Ascend and the newest RFC, in order to have first the Ascend specific
part and then overwrite the RFC defined Attributes.

But again, this is not the problem, I think the problem is my
bad english, therefore you don't understand it.

I'll try again to explain it:

Before I started to forward the accounting requests I had no
WARNINGS in the logfile, the AuthBy FILE didn't complain
about missing attributes, even there was no such attribute
in the dictionary. After I inserted the additional
AuthBy RADIUS I've seen the WARNINGS about the missing
ATTRIBUTE. 

The academic question is: Why do I see no such
warnings with AuthBy File and only with 
AuthBy RADIUS?

hope you understand it despite my english :-(


regards
        Charly

-- 
Karl Gaissmaier          Computing Center,University of Ulm,Germany
Email:[EMAIL PROTECTED]          Network Administration
Tel/Fax: ++49 731 50 22499/22471
pgp-key available: http://www.uni-ulm.de/urz/Netzwerk/uuca/keylist.html

===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Reply via email to