RLM_Rest and Dynamic Clients
Nick Cappelletti
nick at switchtower.com
Mon Jul 20 15:03:08 CEST 2015
Alan,
I know you’re a busy man, and given the number of question and answers you provide, have better things to do then answer the silly questions I have, but if you could briefly explain how the ‘mapping’ works in the dynamic clients, given a single REST call to a server, I would be immensely in your debt. :)
Thanks again, and any information, links, or comments are much appreciated.
—Nick
> On Jul 17, 2015, at 8:51 AM, Nick Cappelletti <nick at switchtower.com> wrote:
>
> Alan,
>
> Thanks again, perhaps I’m over thinking the simplicity of the dynamic clients. I’d like to utilize the 3.1 branch’s map function, so I’ll be upgrading and will try to figure that out.
>
> Thanks for the information and work on FreeRADIUS! :)
>
>
>> On Jul 17, 2015, at 8:31 AM, Alan DeKok <aland at deployingradius.com> wrote:
>>
>> On Jul 17, 2015, at 8:08 AM, Nick Cappelletti <nick at switchtower.com> wrote:
>>> Thanks for the response. I’ve read over the dynamic clients a few times, and understand how reading from a file, reading from a DB, and how the LDAP integration works, but I’m still trying to grasp the concept of the REST integration and how to keep the number of requests down to a minimum. With the LDAP and SQL integration, I know that to grab the FreeRADIUS-Client-Shortname and FreeRADIUS-Client-Secret that we need for our clients, they’re all separate queries and with the number of devices we have on our network (2000+), and the large number of logins we have, I’m afraid I would end up DOS’ing the web server the API sits on with said requests.
>>
>> The dynamic clients are cached for a period of time. This is documented. So the rest API will get hit for *one* packet, and then never again for 5-10 minutes, or whatever you set the timeout as.
>>
>> You're free to set the timeout for an hour. In which case the API will get hit about every 2 seconds on average.
>>
>>> The other questions I have is: how to configure the rest module. I’ve seen the demo perl server, found a server fault pages explaining how to get ‘authorize’ to work (http://serverfault.com/questions/597393/configuring-rlm-rest-module-in-freeradius <http://serverfault.com/questions/597393/configuring-rlm-rest-module-in-freeradius>), and read through the comments in the source, and I could make an educated guess on how to configure the dynamic-clients, but without knowing for sure, I’d be grasping at straws trying to get it to work.
>>
>> I don't understand what the issue is... there is *nothing* magic about dynamic clients. Just make sure that you set the right attributes with the right values. Where those values come from is a separate step.
>>
>>> The best that I could come up with was:
>>>
>>> server dynamic_clients {
>>> authorize {
>>> if ("%{rest: https://url?ipaddress='%{Packet-Src-IP-Address}'}") {
>>> update control {
>>> &FreeRADIUS-Client-IP-Address = "%{Packet-Src-IP-Address}"
>>> &FreeRADIUS-Client-Shortname = "%{rest: https://url?ipaddress='%{Packet-Src-IP-Address}'&return=shortname}"
>>> &FreeRADIUS-Client-Secret = "%{rest: https://url?ipaddress='%{Packet-Src-IP-Address}'}&return=secret"
>>
>> That should probably work.
>>
>> One thing we've done in the 3.1 branch is to add a "map" capability. The rest module can return a set of values at once, and they can get mapped to a set of RADIUS attributes. That lowers the number of API calls.
>>
>> But for your case, loading a dynamic client every 2 seconds shouldn't be a problem. If that's a problem, you can set the timeout to 10 hours. And then use "radmin" to manually delete the client if you need to do that.
>>
>> 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
More information about the Freeradius-Users
mailing list