Unable to authenticate locally when remote proxy server is unavailable

[Jyoti Chatterjee]

Hello Alan,

Thank you for your prompt response. If you don't mind I have a few
follow up questions mentioned below. I would appreciate if you could
answer them.

Thanks again for your help.
Regards,

Jyoti.

On Mon, 2011-06-06 at 07:26 +0200, Alan DeKok wrote:
> jch2006 at verizon.net wrote:
> > The questions I want to ask are as follows:
> >
> > 1. Is this the right method to perform this operation or there could be
> > a simpler way to do this,
> > i.e. authenticate the request using backup cache or database when remote
> > Radius server is down?
> 
>   If you can authenticate the request with a DB, then the remote RADIUS
> server is not needed.  Get rid of it.
> 
>   If you can't get a local DB, then when the remote RADIUS server is
> down, users cannot authenticate.
> 

Actually, the requirement states that if the remote proxy server should
authenticate all associate requests when it is up. When the remote
proxy server is down only then the authentication can be done locally
with the information cached from a previous successful request. 

I might be able to perform local authentication for an EAP-PEAP request
coming from the client using self-signed certificates. Do you agree?

> > 2. Is there a way to know (by ping or other methods) if the remote
> > radius server is down so
> > that I can perform the local authentication right away when the 802.1x
> > request is received
> > instead of proxying the request a few times and then determining that
> > the remote proxy Radius server
> > is not alive or not available?
> 
>   See raddb/proxy.conf.  Look for "status-server".

Is there a specific configuration that you are talking about? I was
never able to capture "status-server" packets using a tool like
ethereal.

> 
>   In short, the only way to see if it's up is to send it RADIUS packets.
> 
> > 3. If somehow  I determine that the remote Radius server is unavailable
> > and I get a 802.1x request
> > (EAP-PEAP) can I verify the authenticity of the request using the local
> > cache and send an
> > Access-Accept somehow tricking the NAS to open the port?
> 
>   No.
> 
> > 4. Is it possible to reduce the time for e.g. "Waking up in 119.8 seconds"?
> 
>   No.  For one, you haven't explaing why that time is a problem.  For
> two, those timers are determined by the servers configuration.  If you
> want that time to change, change the configuration.
> 
>   Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html