On 30/10/2017, at 2:04 PM, Alan DeKok <aland@deployingradius.com> wrote:

On Oct 29, 2017, at 8:54 PM, Nathan Ward <lists+freeradius@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

On Oct 29, 2017, at 10:25 PM, Nathan Ward <lists+freeradius@daork.net> wrote:

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}.

Yes.

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.

It's by design. The configuration files are a read-only key-value database.

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?

I'll take a look. Alan DeKok.