On 11 Dec 2012, at 03:14, Mike Diggins <[email protected]>
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. "[email protected]"
#
if (User-Name =~ /@\\./) {
Broken ones have:
#
# Realm begins with a dot
# e.g. "[email protected]"
#
if (User-Name !~ /@\\./) {
To call filter_username policy just add "filter_username" to your authorise
section.
Regards
Scott Armitage
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
