Update User-Name

[Alan Buxey]

No no no

Please don't do this.

If users have incorrect configuration (missing realm) then those users need
to be corrected. If that org lets it's users get online without realm then
that is not  following best practice but means that those users won't work
at other eduroam sites anyway

So, not only do you cause confusion (but it works at my home org and place
down road but nowhere else - this will then waste other sites time/effort
'we must be doing something wrong as this user can work at another site
other than home' )

But you will also be causing other users problems... Those users from
elsewhere than that org who also don't have realm set ... Who will, instead
of being rejected as they should, will now be proxied to the completely
wrong site and end up with misconfiguration or sending their details to
wrong place.

Just REJECT misconfigured users

And check with eduroam UK policy to see if it's been updated yet that
eduroam auths MUST have the realm even for local auths ... Otherwise a
while can of worms gets opened up.

don't create policies just because of a bad neighbor. Get them to fix the
system. Contact eduroam UK if required to get channels of communication
established.

alan

On 9 Sep 2017 7:20 pm, "Dale Lloyd" <dale.lloyd at gmail.com> wrote:

Thank you, Alan, for taking the time to reply.

>  You should really use 3.0.15.

Apologies, I followed the example in the FreeRADIUS Technical Guide
and typed "yum install freeradius" and this is the version it
installed. I will go back and install 3.0.15 manually.

> No... read the debug output.  The error is something else.

When testing and specifying the full username on the client e.g.
'user at uni.ac.uk', everything works. Specifying just the short username
on the client 'user' fails. Using a packet capture, I see that the
request does not get forwarded as hoped. I read the output of radiusd
-X and noticed the EAP error, but I don't know whether it is possible
to overcome it?

> If they're your users, then you should authenticate them.  You don't need
to edit the User-Name.  You don't need to proxy.
> Describe the problem you're trying to solve.

We are a small entity next to a big university. The neighbouring
university allows its users to connect to eduroam locally without
specifying the realm in the username, but this can lead to problems
because their users are often not aware that they need to use the full
username if they wish to roam.

We get many visitors from the university and their perception is that
our wireless is broken. I want to make it easier for those visitors to
connect to eduroam, because I can't explain to all visitors that they
should user their full username. I need to proxy and I think that need
to add the realm to the username, otherwise the eduroam NRPS won't
know what to do with the request.


On 9 September 2017 at 18:03, Alan DeKok <aland at deployingradius.com> wrote:
> On Sep 9, 2017, at 10:11 AM, Dale Lloyd <dale.lloyd at gmail.com> wrote:
>>
>> FreeRADIUS Version 3.0.4
>
>   You should really use 3.0.15.
>
>> I wish to modify the User-Name attribute in access-requests by
>> appending the realm, but if I do that, FreeRADIUS refuses to proxy the
>> request.
>
>   No... read the debug output.  The error is something else.
>
>> I added the following to /etc/raddb/sites-enabled/default:
>>
>> authorize {
>>
>> if("%{User-Name}" !~ /@/) {
>>        update request {
>>                User-Name := "%{User-Name}@uni.ac.uk"
>> Realm := "eduroam"
>>        }
>
>   The better question is why do you think this is necessary?
>
>   If they're your users, then you should authenticate them.  You don't
need to edit the User-Name.  You don't need to proxy.
>
>   Or, if you do proxy, you can just set Proxy-To-Realm:
>
>         if("%{User-Name}" !~ /@/) {
>                 update control {
>                         Proxy-To-Realm := "my-other-server"
>                 }
>
>
>> radiusd -X output:
>>
>> (0) # Executing group from file /etc/raddb/sites-enabled/default
>> (0)   authenticate {
>> (0)  eap : Identity does not match User-Name, setting from EAP Identity
>> (0)  eap : Failed in handler
>> (0)   [eap] = invalid
>> (0)  } #  authenticate = invalid
>> (0) Failed to authenticate the user
>> (0) Using Post-Auth-Type Reject
>
>   That doesn't say "refused to proxy the request".  The message is
English, and should be clear.
>
>> Suggestions greatly appreciated.
>
>   Describe the problem you're trying to solve.  Don't ask why your
proposed solution doesn't work.
>
>   There are likely many other ways of getting the same result.
>
>   Alan DeKok.
>
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/
list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/
list/users.html