Nicolas Baradakis <nbk@sitadelle.com> wrote:
1. Allowing VSA in the reply packets is really a bug: if you have an existing username with a wrong password, the VSA useful to set up a connection were pulled from the database during autorize and are send in the reject packet.
That's more of a bug that the return attributes are set up before the user is fully authentication. They should be configured *after* authentication.
2. Making the option user-defined may bring more confusion. Too many options make the server more difficult to configure. Moreover the administrator may not figure out easily that turning this option on will hit the bug in (1).
I don't have a problem with using the attr_filter module.
3. Moving the function to a module is a bit dangerous. The modules are optional, and I don't want the server to do something crazy when removing one of the modules.
I agree But doing something dumb is different than doing something crazy. Sending attributes in an Access-Reject won't affect 99.9% of the clients, so there's no problem. Making the validation of Message-Authenticator optional is, however, not going to happen. Ever.
4. I like software that figure out themselves what to do ;-) Apparently the users complaining about the problem are using FreeRADIUS as a proxy for RFC-ignorant third party servers. That's why I think we could relax the filter on proxy replies *only*.
attr_filter should be able to do that.
The rationale is when FreeRADIUS is acting as a home server, it's hard to configure it to intentionally reply VSA in access-reject, therefore the current behaviour should be fine. When FreeRADIUS is acting as proxy, we are not really responsible if the incoming packets are not RFC-compliant. Then perhaps it makes sense to allow the VSA in the latter case.
Sure. But some NASes (rhymes with "bisco") need attributes in the Access-Reject, even locally. I'm not set on changing it, but I'm not set on the existing method, either. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog