Peter Nixon wrote:
Firstly let me explain how I am using it. I have the following defined:
exec radsqlkill { wait = yes program = "/usr/local/bin/radsqlkill.pl %{Calling-Station-Id}" shell_escape = yes output = none packet_type = Access-Request }
That could be replaced with rlm_perl, I think. That would remove most of the startup overhead of forking a separate program & starting perl.
I think that this functionality and more needs to be rolled into radiusd. Basically we need to be able to do the following things:
1) Receive a disconnect packet on port 1700 and check a shared secret (New listen type in radiusd.conf)
That's not hard.
2) Query the radacct table to find disconnect attributes based on a supplied attributes (username, callingstationid etc)
That's more complicated. I'll say why later.
3) Send disconnect packet(s) to NAS with a shared secret and return status
That's not hard.
Now the shared secret in 1) is different from the shared secret in 3). They are both NEW config options and need to be saved somewhere. I think to keep things simple 1) should be an additional option in each realm in proxy.conf (as Disconnect senders will _mostly_ correspond with home servers) and 3) should be an additional option in each client in clients.conf (as Disconnect receivers will _mostly_ correspond with client NAS)
Yes.
It is technically possible that we would want to allow disconnect packets from non home servers, and send them to NAS which are not clients (think where you have chained RADIUS proxies) but I think it will make things unnecessary complicated. What do others think?
As an admin, it's easier for me to send disconnect packets to a RADIUS server than try to figure out which NAS the user is on. But that's just my $0.02.
I think the 3 steps I have listed above will allow everyone to be able to do what they want with Disconnect packets. Basically in the situation where radius is acting as a proxy and you want to allow a home server to disconnect a user on a NAS client you will need all 3 steps (in order). To do what I am doing above with my perl script you will only need steps 2) and 3). People who want to generate disconnect attributes from arbitrary input (a script or custom module) will simply use 3).
Allowing home servers to disconnect people is horrid. Have you read the text in the RFCs's for how to handle trust? i.e. Is this home server really supposed to be sending a disconnect for that user? Or how to handle the whole reverse proxy chain? It's disgusting, and almost impossible to do right. If FreeRADIUS is the server the NAS talks to, disconnect is awkward, but not impossible. If it's a proxying server, disconnect is horrid. I have some ideas to make it easier, but they require all RADIUS servers to implement the same updated algorithm. If that's OK, we can move ahead. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog