Setting internal attributes per client

[Nathan Ward]

> On 30/10/2017, at 2:04 PM, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On Oct 29, 2017, at 8:54 PM, Nathan Ward <lists+freeradius at daork.net> wrote:
>> Right now I have some policies that match request:NAS-IP-Address against a list of IPs. It’s a bit annoying to have to add clients in clients.conf and in the policy config. Manageable sure, but, I’m wondering if there’s a better way.
>> 
>> Is there a way to have some sort of per-client policy, other than matching NAS-IP-Address or similar? Can I look at shortname as configured in clients.conf (I could add tokens to this, for example, ‘iosxrbng_<original hostname>’.
> 
>  There's no real way to do this unfortunately.

I’m sort of reaching back here, and the solution discussed latter is better for me, but it looks like %{client:shortname} works:

(0) Received Access-Request Id 150 from 127.0.0.1:35491 to 127.0.0.1:1812 length 27
(0)   User-Name = "hello"
(0) # Executing section authorize from file /etc/raddb/sites-enabled/default
(0)   authorize {
(0)     update control {
(0)       EXPAND %{client:shortname}
(0)          --> localhost
(0)       Tmp-String-0 = localhost
(0)     } # update control = noop
<snip>

>  The usual way is to put clients into groups, and then return attributes based on that.
> 
>> It occurred to me that a useful thing would be setting attributes in clients.conf, i.e.:
>> 
>> client example.org {
>> 	ipaddr		= radius.example.org
>> 	secret		= testing123
>>       Tmp-String-0   = BNGFlavourPurple
>> }
>> 
>> Maybe. :-)
> 
>  Almost:
> 
> client example.org {
> 	ipaddr		= radius.example.org
> 	secret		= testing123
>        mygroup		= "cisco"
> }
> 
>  And then:
> 
> authorize {
> 	...
> 	if ("%{client:mygroup}" == "cisco") {
> 		... add reply attributes ...
> 	}
> 	...
> }
> 
>  Not quite perfect, but it does work.

That would work great, it’s almost exactly what I want.

Looking at the code I didn’t find anything with “mygroup” or anything, and having a bit of a test, it looks like anything specified under a client section can be requested this way, whether it’s a permitted configuration or not. I can do:

client blah {
  hello = “test”
}

Then retrieve it with %{client:hello}.

I presume this is by design? Can I use any arbitrary name here? (Of course, I’ll make it something specific to my installation, so there’s no conflict with future client parameters).
The client Xlat looks very useful.

I don’t see this documented anywhere other than the Xlat code, and a couple of examples where it’s used but not explained. I tried to edit https://wiki.freeradius.org/config/Xlat <https://wiki.freeradius.org/config/Xlat> to add this, but it doesn’t seem to get access to my email address from the Github OAuth thing so I can’t get edit access. Can I contribute this somehow?

--
Nathan Ward