FreeRADIUS Version 3.0.4 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. 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" } ... radiusd -X output: Ready to process requests Received Access-Request Id 0 from 10.10.200.254:36488 to 10.10.2.53:1812 length 148 User-Name = 'testuser' NAS-IP-Address = 6.71.67.224 Calling-Station-Id = '00-00-00-00-00-02' Called-Station-Id = '88-15-44-47-43-E0:TEST' Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 Connect-Info = 'CONNECT 11Mbps 802.11b' EAP-Message = 0x0200000d01756e697431323334 Message-Authenticator = 0xca24c7b4bfe0fa73b421bc8c9c1e29a5 (0) Received Access-Request packet from host 10.10.200.254 port 36488, id=0, length=148 (0) User-Name = 'testuser' (0) NAS-IP-Address = 6.71.67.224 (0) Calling-Station-Id = '00-00-00-00-00-02' (0) Called-Station-Id = '88-15-44-47-43-E0:TEST' (0) Framed-MTU = 1400 (0) NAS-Port-Type = Wireless-802.11 (0) Connect-Info = 'CONNECT 11Mbps 802.11b' (0) EAP-Message = 0x0200000d01756e697431323334 (0) Message-Authenticator = 0xca24c7b4bfe0fa73b421bc8c9c1e29a5 (0) # Executing section authorize from file /etc/raddb/sites-enabled/default (0) authorize { (0) if ("%{User-Name}" !~ /@/) (0) EXPAND %{User-Name} (0) --> testuser (0) if ("%{User-Name}" !~ /@/) -> TRUE (0) if ("%{User-Name}" !~ /@/) { (0) update request { (0) EXPAND %{User-Name}@uni.ac.uk (0) --> testuser@uni.ac.uk (0) User-Name := "testuser@uni.ac.uk" (0) Realm := 'eduroam' (0) } # update request = noop (0) } # if ("%{User-Name}" !~ /@/) = noop (0) filter_username filter_username { (0) if (!&User-Name) (0) if (!&User-Name) -> FALSE (0) if (&User-Name =~ / /) (0) if (&User-Name =~ / /) -> FALSE (0) if (&User-Name =~ /@.*@/ ) (0) if (&User-Name =~ /@.*@/ ) -> FALSE (0) if (&User-Name =~ /\\.\\./ ) (0) if (&User-Name =~ /\\.\\./ ) -> FALSE (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\\.(.+)$/)) (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\\.(.+)$/)) -> FALSE (0) if (&User-Name =~ /\\.$/) (0) if (&User-Name =~ /\\.$/) -> FALSE (0) if (&User-Name =~ /@\\./) (0) if (&User-Name =~ /@\\./) -> FALSE (0) } # filter_username filter_username = noop (0) [preprocess] = ok (0) [chap] = noop (0) [mschap] = noop (0) [digest] = noop (0) suffix : Request already has destination realm set. Ignoring (0) [suffix] = noop (0) eap : Peer sent code Response (2) ID 0 length 13 (0) eap : EAP-Identity reply, returning 'ok' so we can short-circuit the rest of authorize (0) [eap] = ok (0) } # authorize = ok (0) Found Auth-Type = EAP (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 (0) # Executing group from file /etc/raddb/sites-enabled/default (0) Post-Auth-Type REJECT { (0) attr_filter.access_reject : EXPAND %{User-Name} (0) attr_filter.access_reject : --> testuser@uni.ac.uk (0) attr_filter.access_reject : Matched entry DEFAULT at line 11 (0) [attr_filter.access_reject] = updated (0) eap : Identity does not match User-Name, setting from EAP Identity (0) eap : Failed to get handler, probably already removed, not inserting EAP-Failure (0) [eap] = noop (0) remove_reply_message_if_eap remove_reply_message_if_eap { (0) if (&reply:EAP-Message && &reply:Reply-Message) (0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (0) else else { (0) [noop] = noop (0) } # else else = noop (0) } # remove_reply_message_if_eap remove_reply_message_if_eap = noop (0) } # Post-Auth-Type REJECT = updated (0) Delaying response for 1 seconds Waking up in 0.3 seconds. Suggestions greatly appreciated.
On Sep 9, 2017, at 10:11 AM, Dale Lloyd <dale.lloyd@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.
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@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@deployingradius.com> wrote:
On Sep 9, 2017, at 10:11 AM, Dale Lloyd <dale.lloyd@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
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.
It's better to fix a problem than to add work-arounds.
I agree, but I don't think that they will fix the problem.
You can configure the packet to get forwarded.
Yes, I am now able to forward the packet, thanks to your suggestion, but I can only forward packets to the UK RADIUS Proxy Servers, and those servers won't know where to forward the packet if the domain is not included in the username. I asked our neighboring University if I could forward requests matching a certain pattern directly to them and they declined. I also tried both updating the User-Name and setting the Proxy-To-Realm, but the request gets denied by the remote RADIUS server, probably because by updating the User-Name, I am breaking EAP? Am I missing something, or is my work-around not possible?
On Sep 9, 2017, at 4:22 PM, Dale Lloyd <dale.lloyd@gmail.com> wrote:
Yes, I am now able to forward the packet, thanks to your suggestion, but I can only forward packets to the UK RADIUS Proxy Servers, and those servers won't know where to forward the packet if the domain is not included in the username. I asked our neighboring University if I could forward requests matching a certain pattern directly to them and they declined.
Then proxying won't work. You can't update the User-Name attribute. For various technical reasons that won't work, as you've seen. You can't proxy directly to them, because they won't allow it. Their users won't enter the full user + domain. So... you're stuck.
I also tried both updating the User-Name and setting the Proxy-To-Realm, but the request gets denied by the remote RADIUS server, probably because by updating the User-Name, I am breaking EAP?
Yes.
Am I missing something, or is my work-around not possible?
It's not possible. It's also not your responsibility. If they're not using eduroam correctly, their users won't get on the network. If their users call and complain they can't get on their network, tell them they're violating the eduroam spec. And that it's not your problem, it's their problem. Alan DeKok.
" I asked our neighboring University if I could forward requests matching a certain pattern directly to them and they declined." Good. At least they are doing something right. That request would break eduroam UK policy alan On 9 Sep 2017 9:23 pm, "Dale Lloyd" <dale.lloyd@gmail.com> wrote:
It's better to fix a problem than to add work-arounds.
I agree, but I don't think that they will fix the problem.
You can configure the packet to get forwarded.
Yes, I am now able to forward the packet, thanks to your suggestion, but I can only forward packets to the UK RADIUS Proxy Servers, and those servers won't know where to forward the packet if the domain is not included in the username. I asked our neighboring University if I could forward requests matching a certain pattern directly to them and they declined.
I also tried both updating the User-Name and setting the Proxy-To-Realm, but the request gets denied by the remote RADIUS server, probably because by updating the User-Name, I am breaking EAP?
Am I missing something, or is my work-around not possible? - List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
" I asked our neighboring University if I could forward requests matching a certain pattern directly to them and they declined."
Good. At least they are doing something right. That request would break eduroam UK policy
Amen! Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
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 is exceptionally bad behaviour. You should have a word with the uni next door, and if necessary, get eduroam UK (i.e. Jisc) involved to get them to prod the uni into sticking to protocol (which is that you use the full email-address-style username/NAI).
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
That's bad behaviour. It only lets them continue their bad behaviour which then causes the same problems elsewhere (wherever they encounter eduroam). As much as it is 'not my problem'(TM), having a word with the IT department at the uni can resolve this better.
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.
Well, precisely. The NRPS follows eduroam protocols, as should the university in question. Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
participants (4)
-
Alan Buxey -
Alan DeKok -
Dale Lloyd -
Stefan Paetow