Hi Artur,
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Artur
> Hecker
> Sent: Sunday, January 26, 2003 6:08 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Action to perform when EAP/TLS has finished successfully
>
>
> hi
>
>
> > well, the reason is that I want to base the decision to grant
> or deny access based on the outcome of some database queries,
> which I believe is a costly operation. To do this, I can hook
> somewhere into the process and to my queries for every
> access-request which I receive, or in other words I need to do it
> approximately 4-5 times for one single TLS attempt. If I'd know
> for example in exec-program-wait script I could call or in a
> corresponding perl-function, that the next packet which will be
> sent from the RADIUS server to the client is an access-challenge,
> then I'd not need to do the db-queries, but could wait until I
> see that the next packet would be an ACCESS-ACCEPT. This is a
> reason from the efficiency perspective since I'd be able to avoid
> many lookups.
>
>
> in this case, hook in in the very beginning of the process, on the
> arrival of the first request. what you need, is the user-name attribute.
where does this help me ? If I understood you correctly here, the only improvemnt
would apply to the athentication attempt, which would later on fail for sql-query
reasons. Since the reject-action would be determined very early in the process, we'd
avoid the 3-4 Request/challenge exchanges plus the corresponding TLS overhead. For
everything (which I hope is the majority anyhow) we'd still need to do the costly
db-queries 4-5 times. Or am I on the wrong road completely ?
>
>
>
> > Let's now further assume, that I don't have radius accounting
> and would like to perform some actions in case of an successful
> authentication (e.g. count credits etc.) , then I'd need to hook
> into the authentication packet exchange as well and at the same
> point in time, right before the access-accept is sent to my work.
>
> here i would do it after the last message, the accept. e.g. in
> post-auth. anyway, the both tasks are contradictory: in the first you
that is exactly what I tried to do. For testing reasons, I extended the experimental
perl-module with a post-auth function and implemented a post-auth perl-function, which
printed/logged/investigated the Attribute/Value pairs. Firstly, the post-auth function
is not only called when the TLS exchange is completed (which I perhaps naively
thought) but is called for each received request and secondly, investigating the AVPs
did not deliver any hint to determine when to do the action.
> want to influence the auth process and in the second you want to act
> upon its result, so you will need at least two queries anyway: one read
I don't think that this is contradictory - I see it as complementry - see next
comment.
> query saying if the user can or can not authenticate and the other write
> query in the case of success. you would do the first at the beginning as
> i said before and the second e.g. only if you see an accept message pass
> by.
>
> so sorry but i still don't see why you want to be "just before the end".
Very simplified, what I'm trying to do is to increment a counter for the user in case
he's authenticated successfully and I want do do it more elegantly than by permanently
reading the radiusd logfile and search for the corresponding message.
>
>
> > > i kind of think, that what you want to do is completely avoidable:
> > > - if you want to send a reject if some conditions are not
> fulfilled, why
> > > don't you check the database BEFORE processing TLS? tls is
> pretty costly
> > > in terms of CPU power etc., it might be even better to deny
> immediately
> > > if whatever condition is not ok.
> > > - if you tend to send the message as it is, as a result of the TLS
> > > exchange, i.e. indepedently of you database queries, than i don't get
> > > why you can't do it afterwards or what it would change anyway.
> >
> > I hope I was able to describe my intention well enough above.
>
> perhaps you should think in a more flexible way about what you want to
> achieve. you seem to have one possible solution figured out in your mind
You might be right (and I hope you are). Because I'm not recognising the wood, because
there are so many trees (sorry, german saying, roughly translated)
> and you try to pursue this solution at any cost. what if another
> possibility achieves exactly the same, why is it no good? :-)
I hope I did not leave the impression anywhere, that what I though out would be the
only way to go. I'll happily look into every variant to achive my goal.
Thanks again.
Andreas
>
>
> > > and finally, just as a first idea, you can easily achieve
> what you want
> > > (why ever you want it) by separating the EAP-TLS authenticator and the
> > > database-query-process, e.g. using proxying. when you receive
> an accept
> > > from the FR-instance to which you proxied the last request to, you can
> > > react using the post-proxying e.g....
> >
> > hmm, I did not look into this option yet. Sounds worth for me
> to investigate...
>
> it will work. that's what we do here (however, for a different reason)
>
>
>
> > Sure, the state must be there, but to be honest: I did not
> manage to find the location in the code and where I'd need to
> hook into. Hopefully someone can give me a pointer.
>
> yes, you need a developper to answer this question to you. (i'm not :-))
>
>
> ciao
> artur
>
>
>
>
> --
> Artur Hecker
> artur[at]hecker.info
>
> -
> List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
��b��?���r��{�����r��y'���i��0���z����(����ǫ�f
