(community note: this page is still under construction and subject to changes)
Currently, when deploying eduroam, you require a RADIUS (or RADIUS/TLS) server. Traditionally, deploying a Linux or BSD server has been the standard option. This gives you access to a variety of products that speak RADIUS (and RADIUS/TLS).
However, as the eduroam community, and indeed its technology estate, changes, Windows servers have grown to become one of the major platforms that are currently being used.
On Windows, you are limited to very few options:
Most of the above options rely on deploying something that is not quite native to Windows. Perl for example is a Linux package, but it has been built to work on Windows, and thus, Radiator technically is Windows native. Virtual appliances are just virtual machines, based on some flavour of Linux (or BSD), which you deploy into your Hyper-V hypervisor and control from a browser. They are a machine within a machine, if you will. The same applies to the Windows Subsystem for Linux. It does almost the same.
This is about to change.
One of the most popular lightweight RADIUS proxying packages in the Linux world, radsecproxy, will be coming to Windows in the sense that it runs as a native Windows executable with only a few additional DLLs.
Right now, radsecproxy in its most basic state, i.e. speaking only to specific RADIUS or RADIUS/TLS servers defined in a configuration file, is ready and deployable. Work is in progress to document what is needed to build radsecproxy on Windows and how to deploy it.
For those running visited-only eduroam services, this will probably be even easier to use than deploying NPS, but this will also enable those with existing NPS servers to bolt RADIUS/TLS, a more secure transport for RADIUS, in front of their NPS servers, and also enable the use of the Status-Server protocol (RFC 5997) for your NPS instances.
The build environment for radsecproxy to build successfully on Windows requires Cygwin to be installed (any x64 version will do).
The Linux-native code for radsecproxy currently includes some functionality that is used by more advanced operators (notably eduroam national operators) who want to use DNS-based dynamic peer discovery. That part of the code is currently not Windows compatible and won't build on Cygwin either. Additional work to add alternative code for Windows is in progress. A pull request to exclude the Linux-native dynamic peer discovery code on Windows is here: https://github.com/radsecproxy/radsecproxy/pull/161
Applying the pull request as a patch, and then building radsecproxy with Cygwin will yield executables that will run on Windows when deployed with specific Cygwin DLLs next to the binaries. The list of DLLs is being established.
A 'beta' binary build is available here (the location will eventually change to a more established Github link): https://www.dropbox.com/scl/fo/2bew85046oi5xmqbyyoji/AJTD9DoQapvKANo6cLkpCU8?rlkey=hekljb7487om56c3nvr9em2h9&dl=0
Running radsecproxy on Windows will simply require you to run the radsecproxy.exe executable with the -c parameter to indicate a configuration file that it should read. It will go into the background and remain running there until terminated (through the Windows Task Manager). Code to add a Windows service 'stub' (which launches and manages the radsecproxy process as a Windows service) is in progress.
The logging for Windows uses correct Windows line endings, so you can open the radsecproxy log file with Notepad.
Some functionality is probably not available, mostly because it's not been tested on Windows before. This includes posting events to the event log (the Windows version of the syslog).
F-TICKS is currently not available because it is currently limited to syslogging only.
C:\radsecproxy C:\radsecproxy\radsecproxy.conf-example to radsecproxy.conf radsecproxy.confcmd.exe (as user or admin)cd C:\radsecproxyc:\radsecproxy\radsecproxy.exe -c ./radsecproxy.conf
It'll take a little while to start, but then should return to command-line. You might see two warnings about secret length if you used short secrets (like 'testing' or 'testing123'). Windows servers come with an application firewall. On Windows 2019 in particular, a bug prevents NPS from properly accepting (and sending) packets over RADIUS (see Meraki Community and Microsoft topics on this). You should probably define four new policies (two inbound, two outbound) in the Windows Firewall:
By explicitly setting these four policies, both NPS (if you use it) and radsecproxy should be able to build to the ports correctly and send and receive traffic.
Most functionality in radsecproxy remains unchanged. If you are familiar with radsecproxy configuration files, then this should be easy to deploy. On Windows, as documented in existing code, the CACertificatePath option is unavailable. Use a certificate bundle with the CACertificateFile option instead.
To point to paths, use the file:///C:/This/Windows/Path/To/File.ext format instead (for a drive-less path, you will end up with file://// instead). This is particularly important for the radsecproxy log file and any certificates that you may have.
You may want to check that your radsecproxy instance is up by using a heartbeat to an internally defined port in your configuration. If it times out, it's either radsecproxy that is dead, or it is your server (or your national proxy) that may have died. Either way, you would have a problem.
To see how to set up a heartbeat for Windows, look at the Jisc topic here: https://community.jisc.ac.uk/library/network-and-technology-service-docs/configuring-eduroam-heartbeat-your-visitor-network