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:[EMAIL PROTECTED])@([[: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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
as your user ID,
Fall-Through = no
# Subdomains of sussex
DEFAULT Pre-Proxy-Realm =~ (.+)sussex.ac.uk.*, Auth-type := Reject
Reply-Message = Please use [EMAIL PROTECTED]
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
