proxy and attribute overrides
Hello Sorry if this is a FAQ, but I have not found the answer, so here I am: I use freeradius-1.1.6. The server do authorization and authentication for a few NAS. Some users have logins in the local realm and others have logins in proxied realms. When a user passes authorization, the server returns a Framed-IP-Address to the NAS. The address depends of the NAS and is selected using huntgroups. I have a problem with users in proxied realms: after proxy authentication is successful, radiusd sends a packet to the NAS with no Framed-IP-Address, or with a Framed-IP-Address taken from the proxy RADIUS server. I want my radius server to choose the Framed-IP-Address and ignore what proxied servers send. This can be acheived uwing the attr_filter module, but that module will only allow selection the address based on the realm. I cannot select through huntgroups, which is what I'm looking for. The workaround I found is to add post_proxy_authorize = yes in the server secion of proxy.conf. That causes the proxied reply to go to the authorization stage again and to have a correct Framed-IP-Address added. That post_proxy_authorize option is documented as depreacted and scheduled for future removal. How can I acheive my setup without it? I'm pretty confident there is a way of doing it, but I have not been able to find it. -- Emmanuel Dreyfus manu@netbsd.org
Emmanuel Dreyfus wrote:
That post_proxy_authorize option is documented as depreacted and scheduled for future removal. How can I acheive my setup without it? I'm pretty confident there is a way of doing it, but I have not been able to find it.
In CVS head (what will be 2.0), this is much easier. See "man unlang". You have complete control over everything, including editing attributes. Alan DeKok.
On Wed, Aug 08, 2007 at 09:38:15AM -0400, Alan DeKok wrote:
That post_proxy_authorize option is documented as depreacted and scheduled for future removal. How can I acheive my setup without it? I'm pretty confident there is a way of doing it, but I have not been able to find it.
In CVS head (what will be 2.0), this is much easier. See "man unlang". You have complete control over everything, including editing attributes.
Right, I'll wait for the next release. I just hope that the deprecated feature won't go away at the same release the much easier feature gets in. That would be painful. -- Emmanuel Dreyfus manu@netbsd.org
Emmanuel Dreyfus wrote:
Right, I'll wait for the next release. I just hope that the deprecated feature won't go away at the same release the much easier feature gets in. That would be painful.
The deprecated feature *will* be going away. It's not necessary, and it's wrong. There is *no* need for it in 2.0. Everything that "feature" does can be done better, and easier with the new methods. Alan DeKok.
On Wed, Aug 08, 2007 at 10:14:45AM -0400, Alan DeKok wrote:
Right, I'll wait for the next release. I just hope that the deprecated feature won't go away at the same release the much easier feature gets in. That would be painful.
The deprecated feature *will* be going away. It's not necessary, and it's wrong.
Agreed, but it could be quite useful as a migration path, couldn't it? -- Emmanuel Dreyfus manu@netbsd.org
Emmanuel Dreyfus wrote:
The deprecated feature *will* be going away. It's not necessary, and it's wrong.
Agreed, but it could be quite useful as a migration path, couldn't it?
There are lots of other features which are in 2.0 for backwards compatibility. This feature isn't one of them. It's *easier* to do things the new way. Once you spend the time to migrate *once*, your configuration becomes enormously simpler. Alan DeKok.
Emmanuel Dreyfus said:
On Wed, Aug 08, 2007 at 10:14:45AM -0400, Alan DeKok wrote:
The deprecated feature *will* be going away. It's not necessary, and it's wrong.
Agreed, but it could be quite useful as a migration path, couldn't it?
If this was a minor version update, I might agree. But 2.0 is a major update, with some significant changes and new features. Even with the changes, Alan has done a great job of backward compat, such that most "normal" 1.x setups will just work in 2.x. But there are inevitably a number of corner cases that will require changes. Most of these will be where a given feature of 1.x can be achieved in a more elegant way using the new 'unlang' ("no no, it's not a new scripting language, really"). I see it as a trade off. Our time as users testing and if necessary upgrading our configuration, versus Alan's time coding up backward compat features for our convenience. If it's something affecting many users ... sure, lobby Alan to fix it ... but if it's just a handful, I know whose time gets my vote. Especially in this case, where you have plenty of warning that the feature you need is going away. So I'd recommend that your migration path would be to fire up a test install of the 2.0 CVS head, and play with unlang. You'll like it. :)
Emmanuel Dreyfus manu@netbsd.org
-- hugh
On Wed, Aug 08, 2007 at 11:53:43AM -0500, Hugh Messenger wrote:
Especially in this case, where you have plenty of warning that the feature you need is going away.
Well, that's not realy fair, since the current release does not seems to offer me a way without using the deprecated feature. -- Emmanuel Dreyfus manu@netbsd.org
Emmanuel Dreyfus wrote:
On Wed, Aug 08, 2007 at 11:53:43AM -0500, Hugh Messenger wrote:
Especially in this case, where you have plenty of warning that the feature you need is going away.
Well, that's not realy fair, since the current release does not seems to offer me a way without using the deprecated feature.
What's unfair? It works in 1.1.7. You have different ways to achieve the same goal in 2.0. You seem to be treating "deprecated" as "no longer works in 1.1.7". As you have seen, it *does* work in 1.1.7. Instead, "deprecated" means "going away in a future release". Since there is nothing currently released after 1.1.7, there isn't a problem. If you are unhappy with features changing in a major version upgrade, I suggest you stick with 1.1.7. Alan DeKok.
participants (3)
-
Alan DeKok -
Emmanuel Dreyfus -
Hugh Messenger