Diego Matute wrote:
What is the best practice for handling incoming requests which require
different policies (i.e. secret keys) whereby the client IP is unknown?
If the client IP is unknown, then the client is unknown, and you don't
have a secret key.
And keys aren't policies. Please be
Thanks Alan.
I've reviewed the documentation and I'm not sure how to make it work.
The only attributes passed to the server config are related to the source
IP address, which is not enough information to determine which policy to
apply.
The use case is configuring FreeRADIUS to accept requests
On Tue, Aug 14, 2012 at 8:40 PM, Diego Matute dmat...@cyphercor.com wrote:
The use case is configuring FreeRADIUS to accept requests from unknown
clients with different policies. By different policies I mean different
authentication methods. I thought the secret key could be used to
different authentication methods I really mean different user data stores
and different methods like an optional second factor. I can wrap everything
is a custom auth module, however I will still need a way to know which data
store to use.
I could use NAS, but that would require the client to
Diego Matute wrote:
The only attributes passed to the server config are related to the
source IP address, which is not enough information to determine which
policy to apply.
I think you don't understand how RADIUS works.
Keying policies off of client IP is not always good. Keying
On Tue, Aug 14, 2012 at 9:06 PM, Diego Matute dmat...@cyphercor.com wrote:
different authentication methods I really mean different user data stores
and different methods like an optional second factor. I can wrap everything
is a custom auth module, however I will still need a way to know which
Diego Matute wrote:
different authentication methods I really mean different user data
stores and different methods like an optional second factor. I can wrap
everything is a custom auth module, however I will still need a way to
know which data store to use.
I could use NAS, but that would
I guess I misunderstand why knowing the client IP matters, if the shared
secret is passed isn't that enough. The IP address isn't secure either.
Shared secrets are for client-server pairs hence you can have multiple
shared secrets.
What I am trying to do is enable multiple unknown clients to
The attributes I've mentioned are either server domain or IP address.
On Tue, Aug 14, 2012 at 10:17 AM, Alan DeKok al...@deployingradius.comwrote:
Diego Matute wrote:
different authentication methods I really mean different user data
stores and different methods like an optional second
Ok I've re-read the docs.
I'm going to require the client IP. It doesn't look like this know-nothing
approach will work.
Thanks Alan and Fajar.
On Tue, Aug 14, 2012 at 10:37 AM, Diego Matute dmat...@cyphercor.comwrote:
The attributes I've mentioned are either server domain or IP address.
On
Hi Diego,
Am 14.08.2012 16:06, schrieb Diego Matute:
I could use NAS, but that would require the client to declare their IP
address.
From a FreeRADIUS server point of view the NAS is the _client_!
Could it be that you meant the supplicant (the user or machine which wants to be
authenticated)
Klaus,
Yes I did mean the server sending the request, not the supplicant. I
misunderstood how to handle adding additional user stores off the same
RADIUS server. I will be requiring the IP of the connecting service.
On Tue, Aug 14, 2012 at 5:43 PM, Klaus Klein k.kl...@gmx.de wrote:
Hi Diego,
Looked at the docs and am still unclear here.
What is the best practice for handling incoming requests which require
different policies (i.e. secret keys) whereby the client IP is unknown?
Was thinking there may be a to setup virtual servers which listen on
different server IPs somehow?
Few
13 matches
Mail list logo
