I'm getting close to being able to commit some of the massive changes I've been talking about. No "magic" features yet, but the code is much better. However... as part of the changes, I think I've got to clean up the handling of realms. With a bit more work, I think I can make the old-style "realms" configurations map to the new method when the server starts up. The more complicated piece is the "realms" module. The whole "ignore_null" and "ignore_default" configuration is wrong. It can probably be done via the new "if/then/else" in the authorize section. I'll see if I can figure out a decent way of getting that to work. I'd also like to move the rlm_realm configs prefix/suffix && "delimiter" to the individual "realms" section in proxy.conf, but that might break things. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Mar 27, 2007, at 4:20 AM, Alan DeKok wrote:
I'm getting close to being able to commit some of the massive changes I've been talking about. No "magic" features yet, but the code is much better.
However... as part of the changes, I think I've got to clean up the handling of realms. With a bit more work, I think I can make the old-style "realms" configurations map to the new method when the server starts up.
That would be good. :)
The more complicated piece is the "realms" module. The whole "ignore_null" and "ignore_default" configuration is wrong. It can probably be done via the new "if/then/else" in the authorize section.
I'll see if I can figure out a decent way of getting that to work.
I'd also like to move the rlm_realm configs prefix/suffix && "delimiter" to the individual "realms" section in proxy.conf, but that might break things.
Hmm, the reason it's in the module/instance config now is that it made more sense to me to define the 'delimiter' as that's easier/faster to search for. If you define the delimiter in the realm/proxy.conf section, how does the realm search logic work? I could see a realm option added to define what type of realm each should be. IE, you could then have a separate config for a prefix and suffix realm of the same name ( as much as that might be confusing ). It could also reduce the scope of the number of realms that have to searched for a match. radiusd.conf: realm suffix { format = suffix delimiter = "@" } realm prefix { format = prefix delimiter = "/" } Then in proxy.conf: realm foo.com { type = radius instance = suffix authhost = LOCAL accthost = LOCAL } realm bar { type = radius instance = prefix authhost = LOCAL accthost = LOCAL } Then, you would find a match for 'user@foo.com' but not 'foo.com/ user', and you would find a match for 'bar/user' but not 'user@bar'. I think that could be a useful feature. -Chris -- Chris Parker Director, Systems StarNet - US LEC, now a PAETEC Company (888)212-0099 Fax (847)963-1302 Wholesale Internet and VoIP Services http://www.megapop.net NOTICE: Message is sent IN CONFIDENCE to addressees. It may contain information that is privileged, proprietary or confidential.
Chris Parker wrote:
However... as part of the changes, I think I've got to clean up the handling of realms. With a bit more work, I think I can make the old-style "realms" configurations map to the new method when the server starts up.
That would be good. :)
Yeah... but it's work. I'd rather not do it. It's probably a good idea, though.
Hmm, the reason it's in the module/instance config now is that it made more sense to me to define the 'delimiter' as that's easier/faster to search for. If you define the delimiter in the realm/proxy.conf section, how does the realm search logic work?
Top to bottom in proxy.conf? But yes, you have a point.
I could see a realm option added to define what type of realm each should be.
IE, you could then have a separate config for a prefix and suffix realm of the same name ( as much as that might be confusing ). It could also reduce the scope of the number of realms that have to searched for a match.
Sure. I don't know that it's critical, though. People have lived without it for long enough that it's probably not a high priority. The other thing is how to fix the "ignore_null" and "ignore_default" handling. The code is pretty horrid right now, and I'd rather delete it than maintain backwards compatibility. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Hi How can I make an EAP MD5 authentification process using radeapclient (username, challenge, ....). I mean how can I use radeapclient to send an EAP-MD5 Request and recieve a challenge from the Radius Server. Ashola --------------------------------- Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
ashola ashola wrote:
How can I make an EAP MD5 authentification process using radeapclient (username, challenge, ....). I mean how can I use radeapclient to send an EAP-MD5 Request and recieve a challenge from the Radius Server.
See src/tests. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Hi, I tried to use the attributes values in these files but radeapclient crashes Alan DeKok <aland@deployingradius.com> wrote: ashola ashola wrote:
How can I make an EAP MD5 authentification process using radeapclient (username, challenge, ....). I mean how can I use radeapclient to send an EAP-MD5 Request and recieve a challenge from the Radius Server.
See src/tests. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html --------------------------------- Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta.
ashola ashola wrote:
Hi,
I tried to use the attributes values in these files but radeapclient crashes
Read doc/bugs Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
I'd also like to move the rlm_realm configs prefix/suffix && "delimiter" to the individual "realms" section in proxy.conf, but that might break things.
If I understand, you would like to "merge" realm detection (made in a module) with server proxy configuration/code? My opinion is that it is not so interesting because having a module setting a specific attribute "Proxy-To-Realm" with the wanted value allows to proxy request with criteria not only based on the User-Name. For example, you can have one remote server FOO, managing User-Name of the form: foo/user@realm user@foo user@foo-test.com ... And with FR 1_1, if a specific detection is required, it can be implemented easily. One can also think about proxying based on Client-IP-Address (Yes it is possible, in our case, it could be used), and using rlm_files module to do it. Of course, is what I describe is still possible with what you propose, I don't have any objection. Else this would mean that FR 2_0 can do less than 1_1. Best regards, Geoff. ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Geoffroy Arnoud wrote:
If I understand, you would like to "merge" realm detection (made in a module) with server proxy configuration/code?
No. The confusion arises because right now, realms *are* home servers. That's wrong. In the new code, home servers are defined independently of realms. There are server pools for failover && load-balancing , which are again defined independently of realms. Realms are then defined to use the server pools. i.e. realm -> server pool -> list of home servers What's left in a "realm" section of "proxy.conf" is not much. The name, and pointers to the authentication && accounting pools. The proxy code currently proxies by realm, and it should really proxy by server pool. i.e. ideally, the only knowledge of realms should be in the configuration of the "realms" module. The "Proxy-To-Realm" should go away and/or be replaced with "Proxy-Using-Server-Pool", or "Proxy-To-Home-Server". The "realms" module can map "Proxy-To-Realm" to the appropriate new proxy configuration. However... changing all that requires a lot of updates to existing configurations. It may be easier just to fix the home server && server pool issues, and leave the proxying code with some knowledge of realms.
My opinion is that it is not so interesting because having a module setting a specific attribute "Proxy-To-Realm" with the wanted value allows to proxy request with criteria not only based on the User-Name.
Yes, that's useful. But proxying to a *realm* is wrong. Proxying to a *server* is correct.
Of course, is what I describe is still possible with what you propose, I don't have any objection. Else this would mean that FR 2_0 can do less than 1_1.
That's never the goal. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (4)
-
Alan DeKok -
ashola ashola -
Chris Parker -
Geoffroy Arnoud