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