Yes, you can easily support local machine authentications on eduroam by configuring service rules that check for BEGINS_WITH host\ and ENDS_WITH .domain.edu. I deployed this at a university in a previous life. Worked well.
Even if there was some way to support machine authentication at another university, there is really no value as user auth will kick in when the user logs in regardless. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Trinklein, Jason R Sent: Wednesday, February 8, 2017 14:34 To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Windows 10 eduroam EAP/TLS adding "host/" before username in RADIUS request? We are using eduroam on our campus using FreeRADIUS 3. We will be sunsetting our college-branded secure wireless network and shifting all users to the eduroam SSID in the future. Presently, we have domain member wireless windows systems performing machine authentication with the wireless network. We only had to make one accommodation for this. There are two methods by which FR can authenticate a user with Active Directory: ntlm_auth and with winbind. We found that ntlm_auth is an order of magnitude slower than winbind. However, the latest winbind feature in FR3 does not support machine auth. We didn’t want to slow down all authentications across the network to accommodate machine auth, so we created two “mschap” configs, one configured for ntlm_auth and the other for winbind. The following code in sites-enabled/default in the authenticate{} section differentiates the machine authentication: # MSCHAP authentication. Auth-Type MS-CHAP { if (User-Name =~ /^host\//) { mschap_host } else{ mschap } } Our current eduroam servers do not accept authentications from usernames without an @domain postfix (as is best practice as recommended by eduroam). To accommodate machine accounts on eduroam, instead of rejecting all authentications without the @domain, one could put it through a second check to see if the account is a “host\name" machine account, and allow that to authenticate with AD. However, supporting machine authentication on a roaming domain member machine is probably not possible. One of the reasons for this is that from the RADIUS perspective, “host\system_name” already appears to be a system from the domain called “host”. A username “host\system_n...@school.edu” is therefore ambiguous and not all eduroam ServiceProvider RADIUS systems will handle it gracefully or in a way you expect. I believe you can get on-prem machines to work with machine auth, but almost certainly not roaming systems. I’d be interested to know if anyone knows otherwise. -- Jason Trinklein Wireless Engineering Manager College of Charleston 81 St. Philip Street | Office 311D | Charleston, SC 29403 trinkle...@cofc.edu<mailto:trinkle...@cofc.edu> | (843) 300–8009 From: The EDUCAUSE Wireless Issues Constituent Group Listserv <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> on behalf of Scot Colburn <colb...@ucar.edu<mailto:colb...@ucar.edu>> Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Date: Wednesday, February 1, 2017 at 6:55 PM To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Subject: [WIRELESS-LAN] Windows 10 eduroam EAP/TLS adding "host/" before username in RADIUS request? Is anybody else seeing Windows 10 prepending "host/" to eduroam usernames in EAP/TLS auth? We've had trouble getting our Windows 10 machines authenticating onto our eduroam SSID using EAP/TLS. We seem to have two outcomes, neither of which work: 1) if we create a "Manual Profile" then no authentication traffic ever hits the RADIUS server. 2) if we do NOT create a manual profile then an authentication request does hit the RADIUS server, but with "host/" prepended to the hostname. Our RADIUS server rejects the authentication with "host/" prepended; I imagine a roaming user would have often have the same issue. I have a theory: The eduroam auth requires a "realm" to be appended to the username so eduroam service-providers and federated RADIUS servers know to proxy a roaming RADIUS auth to the correct server. In our case, we append "@ucar.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__ucar.edu&d=DwMFaQ&c=7MSSWy9Bs2yocjNQzurxOQ&r=AuveJXIorHW4s-aGSHEbnQZt5LubWGCZik-5HxxaRqU&m=Z7DXY-9v4Rp-zSAfLau-lHP7ASC7AC14QzOfNfY5Bus&s=9tfGcY3SOr77sukgWphG_-SEJYPjqc6_m3YpzZVP2gk&e=>" to the username. Maybe that "@ucar.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__ucar.edu_&d=DwMFaQ&c=7MSSWy9Bs2yocjNQzurxOQ&r=AuveJXIorHW4s-aGSHEbnQZt5LubWGCZik-5HxxaRqU&m=Z7DXY-9v4Rp-zSAfLau-lHP7ASC7AC14QzOfNfY5Bus&s=sYbdPjMMm8tOqSTFThQiHGPbONUXchl4_9R7_uzr9TU&e=>" is provoking Windows10 to prepend the "host/" prefix. Authentication to our internal SSID without the "@ucar.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__ucar.edu&d=DwMFaQ&c=7MSSWy9Bs2yocjNQzurxOQ&r=AuveJXIorHW4s-aGSHEbnQZt5LubWGCZik-5HxxaRqU&m=Z7DXY-9v4Rp-zSAfLau-lHP7ASC7AC14QzOfNfY5Bus&s=9tfGcY3SOr77sukgWphG_-SEJYPjqc6_m3YpzZVP2gk&e=>" is working normally. Any clues? I think we can build a workaround to rewrite the username on the RADIUS server, but that won't help our roaming eduroam EAP/TLS users if other eduroam service-providers are having the same issue. Scot Colburn Network Engineer NCAR/UCAR/NETS/FRGP ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.educause.edu_discuss&d=DwMFaQ&c=7MSSWy9Bs2yocjNQzurxOQ&r=AuveJXIorHW4s-aGSHEbnQZt5LubWGCZik-5HxxaRqU&m=Z7DXY-9v4Rp-zSAfLau-lHP7ASC7AC14QzOfNfY5Bus&s=gx76LylVmOOCebur1CjeYWaqjdkMj0nnZHVLfZcGLQA&e=>. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
