On Sep 9, 2017, at 2:20 PM, Dale Lloyd <dale.lloyd@gmail.com> wrote:
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.
OS distributions tend to be years out of date.
No... read the debug output. The error is something else.
When testing and specifying the full username on the client e.g. 'user@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.
You can configure the packet to get forwarded. My message suggested out to do that.
I read the output of radiusd -X and noticed the EAP error, but I don't know whether it is possible to overcome it?
Configure the server to forward those requests *without* editing them.
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.
That's common, but stupid. They MUST require full user + domain if the users connect to the Eduroam SSID. Otherwise the users will *never* be able to use Eduroam in other universities. Hint: It's better to fix a problem than to add work-arounds...
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.
So.. add the configuration I suggested. It should work. Alan DeKok.