Longer, but more configurable.

As of Thursday's CVS, one of the "type" options for a server_pool is "type = client_balance", which maps N clients to one home server. It's not as good as real load balancing, but much less work than tracking individual EAP sessions. ...

Very nice feature :) Though using todays CVS (head revision for radiusd, checked out about 3 hours) , I still get Unknown type "client_balance". Also it doesn't let me put multiple servers in a server pool, and dies on runtime with /usr/local/freeradius-cvs060407/etc/raddb/radiusd.conf[147]: Ignoring duplicate home server jrs1_auth.

I hope not. An accounting pool needs to reference accounting servers, not authentication servers. Maybe I missed one sanity check. If so, I'll fix that.

Oh typo on my part, though yes might be good to check all the servers in the server pool are of the same type, and that accounting pools are not used for acct_pool declarations in realms and likewise for auth.

You'll have to specify a username && password, too. Yes, just realised that :) Many of these new configuration options can be left at the defaults.

Yes.

...

Very long, but I can see the advantages : Yes.

If many home servers are intended to be identical, it may be worth referencing the configuration from one to another, maybe via some kind of template. That would make it just as flexible, but less typing. Revised JRS 2 janet_servers { server0 = roaming0.ja.net server1 = roaming1.ja.net server2 = roaming2.ja.net secret = theirkey } ############## # Server Pools # realm jrs { auth_pool = jrs_auth_cb acct_pool = jrs_acct_cb nostrip }

############## # Server Pools # server_pool jrs_auth_cb { home_server = jrs0_auth #home_server = jrs1_auth #home_server = jrs2_auth type = fail-over #type = client_balance } server_pool jrs_acct_cb { home_server = jrs0_acct #home_server = jrs1_acct #home_server = jrs2_acct type = fail-over #type = client_balance } ############## # Home Servers home_server jrs0_auth { hostname = ${janet_servers.server0} $INCLUDE ${confdir}/jrs.auth.conf } home_server jrs0_acct { hostname = ${janet_servers.server0} $INCLUDE ${confdir}/jrs.acct.conf } home_server jrs1_auth { hostname = ${janet_servers.server1} $INCLUDE ${confdir}/jrs.auth.conf } home_server jrs1_acct { hostname = ${janet_servers.server1} $INCLUDE ${confdir}/jrs.acct.conf } home_server jrs2_auth { hostname = ${janet_servers.server2} $INCLUDE ${confdir}/jrs.auth.conf } home_server jrs2_acct { hostname = ${janet_servers.server2} $INCLUDE ${confdir}/jrs.acct.conf }

Alan DeKok wrote:

Arran Cudbard-Bell wrote:

...

Though using todays CVS (head revision for radiusd, checked out about 3 hours) , I still get Unknown type "client_balance".

Hmm.. I'll check the code && get back to you.

...

Also it doesn't let me put multiple servers in a server pool, and dies on runtime with

/usr/local/freeradius-cvs060407/etc/raddb/radiusd.conf[147]: Ignoring duplicate home server jrs1_auth.

That's not nice. I'll check that out, too.

More weirdness Sending Access-Request of id 190 to 0.0.0.0 port 1812 User-Name = "ac221@brighton.ac.uk" User-Password = "password" Service-Type = Framed-User NAS-IP-Address = 139.184.8.1 Proxy-State = 0x313532 Proxying request 4 to realm jrs, home server 0.0.0.0 port 1812 Sending Access-Request of id 190 to 0.0.0.0 port 1812 User-Name = "ac221@brighton.ac.uk" User-Password = "password" Service-Type = Framed-User NAS-IP-Address = 139.184.8.1 Stripped-User-Name = "ac221" Realm = "brighton.ac.uk" Realm = "jrs" Proxy-State = 0x313532 Seems to work fine when I define the host using ipaddr, as opposed to a hostname. Sending Access-Request of id 37 to 193.82.174.185 port 1812 User-Name = "ac221@brighton.ac.uk" User-Password = "password" Service-Type = Framed-User NAS-IP-Address = 139.184.8.1 Proxy-State = 0x313738 Proxying request 4 to realm jrs, home server 193.82.174.185 port 1812 Sending Access-Request of id 37 to 193.82.174.185 port 1812 User-Name = "ac221@brighton.ac.uk" User-Password = "password" Service-Type = Framed-User NAS-IP-Address = 139.184.8.1 Stripped-User-Name = "ac221" Realm = "brighton.ac.uk" Realm = "jrs" Proxy-State = 0x313738 Going to the next request Sorry, just another to add to the list :) TCP Dump shows 14:30:41.581211 IP arr-land.co.uk.nm-asses-admin > radius2.uscs.susx.ac.uk.radius: RADIUS, Access Request (1), id: 0xf 0 length: 72 14:30:41.581451 IP radius2.uscs.susx.ac.uk.tdp-suite > 0.0.0.0.radius: RADIUS, Access Request (1), id: 0x83 length: 77 Really is broken...

...

...

...

If many home servers are intended to be identical, it may be worth referencing the configuration from one to another, maybe via some kind of template. That would make it just as flexible, but less typing.

Revised JRS 2 janet_servers { server0 = roaming0.ja.net server1 = roaming1.ja.net server2 = roaming2.ja.net secret = theirkey

...

...

home_server jrs0_auth { hostname = ${janet_servers.server0} $INCLUDE ${confdir}/jrs.auth.conf }

That's an interesting way of doing templates. I think I'll add similar examples to proxy.conf.

What would be really cool is if you made a minor change to the clients configuration section, so that it mirrored the format of the home_server declarations. So that you had the three ways of defining hosts like you do in home_server declarations ipaddr = 127.0.0.1 ipv6addr = ::1 hostname = localhost And then took the shortname from the instance name so client localhost{ hostname = localhost nastype = other secret = super_secret } As this would allow you to use variables defined elsewhere in the config. Which a) Keeps everything in a standard format b) Allows you to define certain variables centrally, so that if something changes such as the top level domain of a bi directional proxy, you don't have to go hunting through changing all the entries. Though I know this breaks compatibility with 1.1.* , and I don't know how much your trying to keep compatibility with 1.1.*. --- ####################################################################### # Allow the JRS proxy servers to talk to us. client jrs_roaming0 { hostname = ${jrs_config.server0} nastype = other secret = ${jrs_config.secret0} } client jrs_roaming1 { hostname = ${jrs_config.server1} nastype = other secret = ${jrs_config.secret1} } client jrs_roaming2 { hostname = ${jrs_config.server2} nastype = other secret = ${jrs_config.secret2} } Thanks, Arran

OK... two new features. server_pool foo { # hash the source IP, and pick one of the # home servers. type = client-balance ... } Nice, but not rocket science. Even nicer is the templates: # # Holds default configurations for other sections # best used when the data is repeated a lot. # templates { # # Default configurations for all home_servers. # Note: no second name. # Note: entries given here are over-ridden by # entries in a real home_server # home_server { zombie_period = 15 ... } # # Name a specific template home_server companyX { zombie_period = 13 ... } } # # And some examples... # home_server foo { ... # no zombie_period: choose zombie_period from the template } home_server bar { # over-rides what's in the template zombie_period = 20 } home_server dud { ... # # Choose a particular home_server template # template = companyX } I think this will do much the same thing you've been trying to do with include files, but with less work. It's ~80 lines of code, and very cool... Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog

Arran Cudbard-Bell wrote:

Very very cool, have these gone into CVS ? If so i'll recompile now and have a go :)

Yes, they're in CVS. Also see raddb/templates.conf for some minimal documentation.

And i'm guessing templates are global too :) ? So they can also be used in clients and anywhere else you have to repeat something over and over again ??

Almost anywhere. Sub-sections aren't supported yet (e.g. multiple SQL modules).

Excellent work !

Thanks. It's a great feature, and it should make life much easier with the amount of configuration that the home_server section takes. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog

Arran Cudbard-Bell wrote:

...

Yes, they're in CVS. Also see raddb/templates.conf for some minimal documentation.

Hmm didn't come through in the install :(

See the distribution directory, not the install directory. I haven't had a chance to update the Makefiles yet.

...

Almost anywhere. Sub-sections aren't supported yet (e.g. multiple SQL modules).

Aww, would be cool if they were. I do actually use multiple sql configurations, but they're just selecting data from different databases so much of the configuration is the same. But still very nice :)

Yes. It's probably not much more code to do sub-sections, but I want to be sure it's done right.

Now if only I could enable multiple home servers in the same pool ;-)

I think the problem is you're still using hostname in home_servers.. Don't. It doesn't work, and it won't work until I find some time to fix it.

I've been thinking about the DNS issue, if every time a hostname string is used then a hostname lookup must be performed then your right thats really icky. A possible solution would be something resembling the expressions module,

ipaddr = '%{lookup:hostname.com}

That's interesting. It would definitely be more generic than the current method.

If you don't feel like writing the code i'd be happy to do it, would make a nice starting project.

Sure. The main problem is that the configuration variables get expanded before the modules are loaded. Doing DNS lookups via another hook is therefore hard. Useful as heck, but hard. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog

Arran Cudbard-Bell wrote:

Hmm looks good, failing over as expected, pinging all dead servers to check if they're alive.... cool.

<g> Much better than before. There are a few other things to add, but they're minor. I think I'll also re-name the "ping" checks to "live" checks, because pings will confuse people. After that, 2.0 looks to be pretty good.

Ah, ok... so it might be better as an extension to the expressions module possibly.... As that must already have hooks, to write the values to the configuration variables during expansion.

Maybe.

On a completely unrelated subject, whats the standard checking behaviour when you have multiple instances of the same attribute, will each of the instances be checked in turn ?

Yes. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog

Due to the complicated filtering required for JRS, the standard way of doing proxying with the realms module is not sufficient. Most institutions will just use rlm_realm to strip the user name and realm out, and proxy the user to the default realm, Then explicitly define a realm for themselves to catch local users. This is fine, as locally terminated realms don't get sent through the pre-proxy and post-proxy sections, and so the stringent attribute filters required for JRS don't affect locally proxied data. The issue comes when you have a set of RADIUS servers in front of your home_servers. Because you have to use DEFAULT in the attribute filter to match users going off to JRS (as you have no idea what their realm will be), the data flowing through the front end servers will also have the DEFAULT filters applied, which is not good ! The obvious solution is to actually direct users at a realm, instead of relying on DEFAULT entries... But as soon as a user hits the rlm_realm they will be proxied... The solution I found is to ignore the standard front end for rlm_realm, and instead use the Proxy-To-Realm and Replicate-To-Realm in the users file. 1. User hits hints file. # Writes stripped user name to use in authorization DEFAULT User-Name =~ "^([[:alnum:]^@]+)@([[:alnum:].]*)$" Stripped-User-Name = "%{1}", Pre-Proxy-Realm = "%{2}" You split the user name into two sections using a generic regular expression, user name goes into Stripped-User-Name, second part goes into a custom Attribute Pre-Proxy-Realm. 2. User hits users file. ############################################################################ # Reject annoying users who use the wrong realm, so we don't have to bother JRS with them. # Shorthand sussex DEFAULT Pre-Proxy-Realm =~ ".*susx.ac.uk.*", Auth-Type := Reject Reply-Message = "Please use %{Stripped-User-Name}@sussex.ac.uk as your user ID", Fall-Through = no # Freeman centre users DEFAULT Pre-Proxy-Realm =~ ".*freeman-centre.ac.uk.*", Auth-Type := Reject Reply-Message = "Please use %{Stripped-User-Name}@sussex.ac.uk as your user ID", Fall-Through = no # Subdomains of sussex DEFAULT Pre-Proxy-Realm =~ "(.+)sussex.ac.uk.*", Auth-type := Reject Reply-Message = "Please use %{Stripped-User-Name}@sussex.ac.uk as your user ID", Fall-Through = no # Proxy user to JRS. DEFAULT Pre-Proxy-Realm != "sussex.ac.uk", Pre-Proxy-Realm !="", Proxy-To-Realm := "jrs" Fall-Through = no # Or to backend servers. DEFAULT Proxy-To-Realm := "sussex" Fall-Through = no You can then black hole users using incorrect domains. And proxy users who don't belong to your local domain, directly to the jrs realm. You can then define specific attribute filters for JRS users :) 3. Acct_users ############################################################################ # Replicate none sussex users accounting packets to jrs realm # (allows us to use attr_filter properly!) DEFAULT Pre-Proxy-Realm != "sussex.ac.uk", Pre-Proxy-Realm !="", Replicate-To-Realm := jrs Fall-Through = yes DEFAULT Proxy-To-Realm := "sussex" Just thought it was quite a neat way or doing it, as opposed to all the weirdness with prefixes and suffixes and using rlm_realm in the authorize and accounting section. Also rely's on *standardish* behaviour. Also heard talk to deprecating Proxy-To-Realm and Replicate-To-Realm... which is a really bad idea as using Proxy-To-Realm and Replicate-To-Realm is far more powerful , and can be configured from sql :) --- Arran

Alan DeKok wrote:

Arran Cudbard-Bell wrote:

...

The obvious solution is to actually direct users at a realm, instead of relying on DEFAULT entries... But as soon as a user hits the rlm_realm they will be proxied...

Only if you define "authhost" and "accthost". If those don't exist (or are set to LOCAL), then the realm will be recognized, but the request will not be proxied.

Yes well in my case there would be realms defined, one for JRS and one secondary RADIUS servers.

...

The solution I found is to ignore the standard front end for rlm_realm, and instead use the Proxy-To-Realm and Replicate-To-Realm in the users file.

Replicate-To-Realm does something? I don't think so. It's not referenced in the source anywhere.

Oh... damn I saw someone had submitted a patch for it a long time ago during my google searching, and had assumed it had been included.

...

# Shorthand sussex DEFAULT Pre-Proxy-Realm =~ ".*susx.ac.uk.*", Auth-Type := Reject Reply-Message = "Please use %{Stripped-User-Name}@sussex.ac.uk as your user ID", Fall-Through = no

It's probably time for a "regex map", like Postfix has. That would simplify this configuration quite a bit.

Yeah that would be nice, make this kind of stuff much neater , especially if your checking for loads of Regexp based conditions.

...

Just thought it was quite a neat way or doing it, as opposed to all the weirdness with prefixes and suffixes and using rlm_realm in the authorize and accounting section.

The realm module is there to handle the people who need it's functionality. :)

Bless their little cotton socks.

...

Also heard talk to deprecating Proxy-To-Realm and Replicate-To-Realm... which is a really bad idea as using Proxy-To-Realm and Replicate-To-Realm is far more powerful , and can be configured from sql :)

Replicate-To-Realm doesn't do anything... Proxy-To-Realm is useful, but wrong. Let me explain.

RADIUS proxies send packets to RADIUS servers... not to realms. So the simplest way to set proxying is "proxy to server X". Note that there's no mention of a realm.

But we also want fail-over and load-balancing. So in 2.0, we have the concept of "server pools", which aggregate many RADIUS servers into one pool. The pool is then treated as one logical server. So we can also set "proxy to server pool Y". Note that there's no mention of a realm.

Finally, servers and/or pools often handle realms. So it's useful to say that "this realm is handled by server X, or server pool Y". It's also useful to say "proxy the request to the server/pool that handles realm FOO." That is a logical abstraction that simplifies the administrators thinking. It's a layer of indirection that means he can work conceptually with what the user types in (name + realm), and what he sees in the packet (name + realm), rather than dealing with the details of the protocol.

Historically, FreeRADIUS did not have home_servers or server_pools. They were shoved into realms, which was wrong. But it's what we had, which is where the confusion between realms & pools & servers comes from.

So... Replicate-To-Realm doesn't work. I'd be curious to know what it does for you.

Well obviously nothing :( , I hadn't got around to testing it yet I just assumed it would as acct_users didn't have any parsing errors thrown. But that would be because it's defined as attribute 1049 in dictionary.freeradius.internal ATTRIBUTE Replicate-To-Realm 1049 string Damn.. Well obviously someone wanted to implement it once, but never got round to it *sigh*. I had assumed that it would copy the incoming packet to the realm specified but also continue processing locally. This would really only be of use for accounting packets.

Proxy-To-Realm won't be going away, it's still useful. But Proxy-To-Server-Pool && Proxy-To-Home-Server are useful, too. Once we have those, Proxy-To-Realm becomes "look up realm, find auth/acct server, and then use that for Proxy-To-Server-Pool".

Yes so the actual function is fine, it's just the terminology. A more accurate name might be 'Assign-To-Realm', and then once it's been 'assigned' the internet logic of the realm will decide where it's actually proxied to. Well thanks for explaining all that, had a pretty good idea of what was happening, but you helped solidify it. If you do feel like adding replicate-to-realm in.. would be most appreciated :) Thanks, Arran

There was an implementation of it in 0.1 or 0.2, but it was removed because is caused a great many problems in the server core.

I had a feeling it might be that, it seems it would break with the rather linear flow of freeradius.

...

I had assumed that it would copy the incoming packet to the realm specified but also continue processing locally. This would really only be of use for accounting packets.

Yes. The suggestion now is to use "radrelay". It's more work, but it does the same thing.

*looks at man page* yes that'd do it ! Ah but this would send all the accounting data out to the jrs proxies, for which jrs might not look on us too kindly for . Only a relatively small amount of accounting data would actually need to go off site... for users from other institutions using our wireless AP's but authenticating back at there home institutions. The advantage of using a 'replicate-to-realm' like feature is that you can filter the data being replicated, and direct it to the proper home servers. I was considering setting up an exec instance pointing to a shell script which would forward the data via radclient.

I *think* in 2.0 we can get radrelay to duplicate the functionality of Replicate-To-Realm without too much effort, but I'll have to spend some more time looking into it.

Yeah that would be cool, then you could synchronize all your accounting data with multiple off/on-site radius servers. Especially good for people relying on flat files as opposed to SQL databases.

...

Yes so the actual function is fine, it's just the terminology. A more accurate name might be 'Assign-To-Realm', and then once it's been 'assigned' the internet logic of the realm will decide where it's actually proxied to.

*internal logic

I swear my spell checker hates me. Thanks, Arran