On Apr 7, 2022, at 10:58 AM, Brian Julin <BJulin@clarku.edu> wrote:
That's been a longstanding limitation of originate_coa. In many deployments a common secret is not used and the NAS data is taken from a flat file or database. IIRC there may be support for doing corresponding home server definitions like this. Possibly this will be enhanced in FreeRADIUS4 since ISTR talk of a dynamic home server mechanism and this feature could potentially be a beneficiary of that.
Given that we have 3.2.x now, it would be useful to add *small* changes to support this functionality. Even allowing a network/mask for CoA "home_server" definitions would help a lot. Allowing for custom shared secrets would be harder, unfortunately.
It is indeed a pain to have to sync up records on other systems every time you add move or change a NAS when you have hundreds of them. If you have the time to tool that into your NAS onboarding procedure it's a lot less painful, but then you have to maintain that tooling over the long term.
It's likely not too hard to add functionality which gets the "CoA" fields from SQL. That just has to have a schema / queries defined, and maybe 100 lines of code.
Note that, depending on the NAS, CoA can often use a different secret and/or be entirely different servers than the one that took the auth+acct, as long as they get the session ID from accounting. So there are two workaround options: generate the CoA from a shelled out script instead, or relay to a 3rd party product which can usually send CoAs directly to the NAS. (If this is HPEAruba, there's a special nuanced trick to that.)
See also sites-available/coa-relay, which makes it much easier to send coa / disconnect packets to a NAS. You don't even need to know where the user is, the virtual server figures it out. Alan DeKok.