Multiple incoming requests from unknown clients
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 thoughts: - route based on client configured DNS: SOMEPREFIX.mydomain.com - accept all and pass other RADIUS attributes down (not preferred) Thanks, Diego
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 careful with terminology.
Was thinking there may be a to setup virtual servers which listen on different server IPs somehow?
Read the "dynamic_clients" documentation. That is how you deal with clients which are not pre-configured. That is the only way it can be done. Alan DeKok.
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 from unknown clients with different policies. By different policies I mean different authentication methods. I thought the secret key could be used to differentiate the calls and apply the correct policy. Have I missed something here? The domain names and potentially IP addresses clients use to configure the target RADIUS server could differ. However, in the backend there would be a single server servicing requests. Not a big fan of this approach. Another way would be requiring the client to configure additional attributes to be passed down in the request. Also not a fan of this approach. Diego On Tue, Aug 14, 2012 at 2:52 AM, Alan DeKok <aland@deployingradius.com>wrote:
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 careful with terminology.
Was thinking there may be a to setup virtual servers which listen on different server IPs somehow?
Read the "dynamic_clients" documentation. That is how you deal with clients which are not pre-configured.
That is the only way it can be done.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Tue, Aug 14, 2012 at 8:40 PM, Diego Matute <dmatute@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 differentiate the calls and apply the correct policy. Have I missed something here?
what "different authentication methods"? Did you mean something like PAP vs EAP? If yes, FR does that automatically.
The domain names and potentially IP addresses clients use to configure the target RADIUS server could differ. However, in the backend there would be a single server servicing requests. Not a big fan of this approach. Another way would be requiring the client to configure additional attributes to be passed down in the request.
realms and NAS IP address are also attributes. You can (for example) select which backend to use (e.g. which sql server, or whether to use LDAP vs perl) based on certain attributes (including realm and NAS IP address) using unlang: http://freeradius.org/radiusd/man/unlang.html -- Fajar
"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 declare their IP address. I was hoping for a solution where the client IP is not known and the right thing is done based on some attributes not cumbersome for a client to supply. On Tue, Aug 14, 2012 at 9:58 AM, Fajar A. Nugraha <list@fajar.net> wrote:
On Tue, Aug 14, 2012 at 8:40 PM, Diego Matute <dmatute@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 differentiate the calls and apply the correct policy. Have I missed something here?
what "different authentication methods"? Did you mean something like PAP vs EAP? If yes, FR does that automatically.
The domain names and potentially IP addresses clients use to configure
the
target RADIUS server could differ. However, in the backend there would be a single server servicing requests. Not a big fan of this approach. Another way would be requiring the client to configure additional attributes to be passed down in the request.
realms and NAS IP address are also attributes. You can (for example) select which backend to use (e.g. which sql server, or whether to use LDAP vs perl) based on certain attributes (including realm and NAS IP address) using unlang: http://freeradius.org/radiusd/man/unlang.html
-- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Tue, Aug 14, 2012 at 9:06 PM, Diego Matute <dmatute@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 data store to use.
I could use NAS, but that would require the client to declare their IP address. I was hoping for a solution where the client IP is not known and the right thing is done based on some attributes not cumbersome for a client to supply.
Usually that's the realm. Or the user name (e.g. username starting with "1" belong to x group, while username containing the words "test" belong to y group). If you can't use that, then you need to plan your solution more. -- Fajar
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 require the client to declare their IP address.
Which is how RADIUS works.
I was hoping for a solution where the client IP is not known and the right thing is done based on some attributes not cumbersome for a client to supply.
Like... what? Some random attribute? Do you even know? Alan DeKok.
The attributes I've mentioned are either server domain or IP address. On Tue, Aug 14, 2012 at 10:17 AM, Alan DeKok <aland@deployingradius.com>wrote:
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 require the client to declare their IP address.
Which is how RADIUS works.
I was hoping for a solution where the client IP is not known and the right thing is done based on some attributes not cumbersome for a client to supply.
Like... what? Some random attribute? Do you even know?
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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 <dmatute@cyphercor.com>wrote:
The attributes I've mentioned are either server domain or IP address.
On Tue, Aug 14, 2012 at 10:17 AM, Alan DeKok <aland@deployingradius.com>wrote:
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 require the client to declare their IP address.
Which is how RADIUS works.
I was hoping for a solution where the client IP is not known and the right thing is done based on some attributes not cumbersome for a client to supply.
Like... what? Some random attribute? Do you even know?
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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) when youwrite "client"?
Am 14.08.2012 00:40, schrieb Diego Matute:
What is the best practice for handling incoming requests which require different policies (i.e. secret keys) whereby the client IP is unknown? Pls. clarify "the client IP is unknown". Is this the IP of the NAS which sends an authentication request to the FreeRADIUS server ? Do you mean that you don't know through which configured NAS the authentication will take place? Do you refer to the IP of a supplicant?
Cheers, Klaus
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.klein@gmx.de> wrote:
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) when youwrite "client"?
Am 14.08.2012 00:40, schrieb Diego Matute:
What is the best practice for handling incoming requests which require
different policies (i.e. secret keys) whereby the client IP is unknown?
Pls. clarify "the client IP is unknown". Is this the IP of the NAS which sends an authentication request to the FreeRADIUS server ? Do you mean that you don't know through which configured NAS the authentication will take place? Do you refer to the IP of a supplicant?
Cheers, Klaus
- List info/subscribe/unsubscribe? See http://www.freeradius.org/** list/users.html <http://www.freeradius.org/list/users.html>
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 policies off of *unknown* client IPs is bad.
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 differentiate the calls and apply the correct policy. Have I missed something here?
Yes. RADIUS doesn't work like that. You're confused in your terminology. There's no "secret key". It's the "shared secret". Precision matters. If you ask for a cup of coffee when you really wanted a glass of water, you won't get what you want.
The domain names and potentially IP addresses clients use to configure the target RADIUS server could differ.
RADIUS doesn't use domain names. Domain names *cannot* be trusted. RADIUS uses source IP addresses. And it doesn't even trust those. The client still needs the shared secret.
However, in the backend there would be a single server servicing requests. Not a big fan of this approach. Another way would be requiring the client to configure additional attributes to be passed down in the request. Also not a fan of this approach.
All of your approaches are based on fundamental misunderstandings of how RADIUS works. The client IPs have to be known. The client IPs are used to select a shared secret. The shared secret is used to verify that the packets aren't forged. Once the server has decided that the packet is OK, the packet is proceses through the various policies. These policies determine which databases are used, whether or not to proxy the request, what goes in the reply, etc. That's how RADIUS works. I have no idea what you are trying to do.
From what little I understand, it's much more complicated than necessary.
Alan DeKok.
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 connect to a single server and be served off of different user stores. On Tue, Aug 14, 2012 at 10:16 AM, Alan DeKok <aland@deployingradius.com>wrote:
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 policies off of *unknown* client IPs is bad.
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 differentiate the calls and apply the correct policy. Have I missed something here?
Yes. RADIUS doesn't work like that. You're confused in your terminology. There's no "secret key". It's the "shared secret".
Precision matters. If you ask for a cup of coffee when you really wanted a glass of water, you won't get what you want.
The domain names and potentially IP addresses clients use to configure the target RADIUS server could differ.
RADIUS doesn't use domain names. Domain names *cannot* be trusted. RADIUS uses source IP addresses. And it doesn't even trust those. The client still needs the shared secret.
However, in the backend there would be a single server servicing requests. Not a big fan of this approach. Another way would be requiring the client to configure additional attributes to be passed down in the request. Also not a fan of this approach.
All of your approaches are based on fundamental misunderstandings of how RADIUS works.
The client IPs have to be known. The client IPs are used to select a shared secret. The shared secret is used to verify that the packets aren't forged.
Once the server has decided that the packet is OK, the packet is proceses through the various policies. These policies determine which databases are used, whether or not to proxy the request, what goes in the reply, etc.
That's how RADIUS works. I have no idea what you are trying to do. From what little I understand, it's much more complicated than necessary.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (4)
-
Alan DeKok -
Diego Matute -
Fajar A. Nugraha -
Klaus Klein