Re: Multiple incoming requests from unknown clients
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 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> > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple incoming requests from unknown clients
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 wrote: > The attributes I've mentioned are either server domain or IP address. > > On Tue, Aug 14, 2012 at 10:17 AM, Alan DeKok 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 >> > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple incoming requests from unknown clients
The attributes I've mentioned are either server domain or IP address. On Tue, Aug 14, 2012 at 10:17 AM, Alan DeKok 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 > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple incoming requests from unknown clients
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 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 > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple incoming requests from unknown clients
"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 wrote: > On Tue, Aug 14, 2012 at 8:40 PM, Diego Matute > 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 > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple incoming requests from unknown clients
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 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 > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl module not executing authenticate
Got it. Thanks. On Wed, Jun 13, 2012 at 1:57 AM, Alan DeKok wrote: > Diego Matute wrote: > > What is the best practice for this? Should the Auth-Type be set in > > /etc/raddb/users, within the module, /etc/raddb/sites-available/*? > > It should be set wherever you want. > > Alan DeKok. > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl module not executing authenticate
Fajar. Thanks for the tip.
This indeed works. In fact as Alan alluded to, placing the configuration in
either users or the module will work. Here are the configurations that
worked:
/etc/raddb/users:
DEFAULT Auth-Type = Perl
Fall-Through = yes
OR
/etc/raddb/example:
# Function to handle authorize
sub authorize {
# For debugging purposes only
&log_request_attributes;
# Here's where your authorization code comes
# You can call another function from here:
&test_call;
$RAD_CHECK{'Auth-Type'} = "Perl";
$RAD_CHECK{'Fall-Through'} = "yes";
return RLM_MODULE_OK;
}
Cheers and thanks!
Diego
On Tue, Jun 12, 2012 at 10:16 PM, Fajar A. Nugraha wrote:
> On Wed, Jun 13, 2012 at 6:01 AM, Diego Matute
> wrote:
>
> >> > 2/ How does Auth-Type get set? I've read a bunch of forum threads and
> it
> >> > looks like best practice nowadays is to let the server figure it out
> and
> >> > not set it explicitly in /etc/raddb/users, however it isn't being set.
> >>
> >> It isn't being set because the default distribution doesn't use
> rlm_perl.
> >>
> >> If you want to *force* usage of rlm_perl, you need to set Auth-Type.
> >> If you want to let the server just do the right thing, leave everything
> >> alone.
> >>
> >
> > What is the best practice for this? Should the Auth-Type be set in
> > /etc/raddb/users, within the module, /etc/raddb/sites-available/*?
>
> Why do you want to set Auth-Type? As Alan already said, if you want
> to let the server just do the right thing, leave everything alone.
> Meaning, you leave auth-type alone, use rlm_perl to supply user data
> (e.g. cleartext-password) as needed during authorization, and let the
> default authentication methods (pap, mschap, etc) does its job. If you
> force set auth-type, then you're not following best practice.
>
> That being said, from within rlm_perl you could probably set the
> attribute on %RAD_CHECK (or is it %RAD_CONFIG?). If ALL your users
> will use perl to authenticate then something like the default section
> on /etc/raddb/users should do.
>
> --
> Fajar
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl module not executing authenticate
Thanks for the quick response. Inline. On Tue, Jun 12, 2012 at 10:44 AM, Alan DeKok wrote: > Diego Matute wrote: > > I've installed freeradius and other packages on a vanilla amazon ec2 > > instance and am trying to get the rlm_perl module working. Ultimately > > the authenticate function in the perl script is not being run. Here are > > the details. > ... > > 1/ Request comes in and authorize is being called within rlm_perl. The > > print statement is not outputting on the server side? > > The modules aren't permitted to print to STDOUT or STDERR. > Got it. > > > 2/ How does Auth-Type get set? I've read a bunch of forum threads and it > > looks like best practice nowadays is to let the server figure it out and > > not set it explicitly in /etc/raddb/users, however it isn't being set. > > It isn't being set because the default distribution doesn't use rlm_perl. > > If you want to *force* usage of rlm_perl, you need to set Auth-Type. > If you want to let the server just do the right thing, leave everything > alone. > > What is the best practice for this? Should the Auth-Type be set in /etc/raddb/users, within the module, /etc/raddb/sites-available/*? > Alan DeKok. > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
