On 11 Dec 2012, at 03:14, Mike Diggins <mike.diggins@mcmaster.ca> wrote:
On Sun, 9 Dec 2012, Alan Buxey wrote:
Hi,
This looks like something I should be doing but I have no idea where to insert this section. Is it in proxy.conf or somewhere else? And
in the authorize section of your virtual server, straight after the preprocess/suffix/realm module calls (ie before any real authorization action)
With this configuration, I guess I don't need realm's LOCAL or NULL?
correct - you will deal with your LOCAL realm by handling your defined realm, with eduroam you dont want to EVER authenticate a user you hasnt provided a realm - because , for your own users, they may work fine....when they are at your site....they then think/believe their configuration works...and then find it doesnt work when they go to another eduroam site...and then they'll blame that site, your site or eduroam. best policy for eduroam is ALWAYS ensure a realm is defined on the client
ok, both the default and inner-tunnel, I assume?
I added the section to "authorize", but the DEBUG output indicates the regular expression is rejecting a valid user. Is there someone that could confirm the RE?
if (User-Name =~ /^([^@]*)@([-A-Z0-9]+(\\.[-A-Z0-9]+)+)$/) { ...
Why not just use the filter_username policy in the policy.conf In filter_username in policy.conf you probably want to comment out the "reject mixed case" test and make sure your version has the fixed "realm begins with a dot" # # Realm begins with a dot # e.g. "user@.site.com" # if (User-Name =~ /@\\./) { Broken ones have: # # Realm begins with a dot # e.g. "user@.site.com" # if (User-Name !~ /@\\./) { To call filter_username policy just add "filter_username" to your authorise section. Regards Scott Armitage