Hi Artur,
firstly, thanks for taking the time to read my message and reply to it.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Artur
> Hecker
> Sent: Sunday, January 26, 2003 5:11 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Action to perform when EAP/TLS has finished successfully
>
>
> hi
>
>
> i don't think i can really help you, but i want first to understand why
> you want to do that? i mean do you want to send a reject if your prior
> checks are wrong? or why are you trying to do something before the last
> accept message? what's the reason?
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.
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.
>
> 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.
>
> 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...
>
> i'm sure it's also possible to achieve the same behaviour by taking a
> look at the eap/tls module state when it processes received messages. it
> alone knows when the message is going to be accepted. alan sure has a
> lot of more intelligent ideas about it since he knows exactly in which
> order the messages are treated by freeradius and when it is finally
> sent.
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.
Thanks very much so far.
Andreas
>
>
> ciao
> artur
>
>
> Andreas Trilling wrote:
> >
> > Hello freeradius community,
> >
> > I submitted the following question already 3 weeks ago, but did
> not see any follow up. Since there are lots of knowledgeble
> people here on the list I though this might have been due to the
> holidays and therefore I'm trying to post my question again.
> >
> > I've got a general question regarding freeradius >= 0.8 and EAP/TLS.
> >
> > What I want to do in general is to perform an action (e.g.
> update a database) when an ACCESS-ACCEPT has been sent or
> directly prior to that.
> >
> > This should not be an issue with authentication methods other
> than EAP/TLS, but with EAP/TLS 4-5 ACCESS-REQUEST,
> ACCESS-CHALLENGE messages are exchanged (which carry EAP/TLS
> information) and I'd need to find out which of the 4-5
> ACCESS-REQUEST received will result in an ACCESS-ACCEPT message
> sent out in return.
> >
> > I've tried out several things, e.g. using the Exec-Program-Wait
> attribute to call an external program and evaluate the
> environment variables to determine what will come next, but I've
> not been able to figure out the difference, which makes
> freeradius return an ACCEPT next. I've also extended the
> experimental perl-module and added a post-auth function which
> extracted the eap-messages into one long string for further
> evaluation, but without completely decoding and following the TLS
> exchange and looking for the TLS success-message (which might be
> an indicator) I've also not reached a better insight.
> >
> > Does someone have an idea what could be done here ?
>
> --
> Artur Hecker
> artur[at]hecker.info
>
> -
> List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
.+-�w��˛���m��˛���m�zm�����y��v+���?�+-�� ��m�
