FAQs: Frequently Asked Questions

You should only expect to see this rate in very large organisations first thing in the morning as staff arrive as well as possibly early afternoon as staff return from lunch. Universities often see this level of load as students place their devices to sleep and wake them up moving between lectures.

In practice servicing more than 10,000 rps per core is relatively easy for a RADIUS server, but slow downs occur when:

RAM primarily used to support running the Azure Monitor Agent and providing more than 2GiB of RAM is unnecessary.

More than a single vCPU is useful so that OS update or Azure Monitor Agent events do not impact the actual RADIUS handling components running on the server. Running a single vCPU is likely to cause latency issues if you have a large number of requests.

On a related note, where possible you should use Ephemeral OS disks as they are cheaper and faster otherwise at least a Standard SSD is recommended.

This typically is a problem for EAP-(T)TLS authentications as for large certificate chains only about five hundred (500) bytes can be transmitted in a single round trip; 5kiB to 10kBi in total is not uncommon which for a RTT of 100ms (‘width’ of the US or EU) immediately adds at least one (1) second to the authentication time experienced by your users and this is before delays due to database or Entra ID authentications are taking into consideration.

Using TLS session resumption masks this latency problem (except for the initial TLS handshake) and so is always recommended.

Best is to make sure you pick a region that is always close to you.

The service requires Trusted Launch which is not supported by Azure for their ARM based instances.

This is not a technical limitation of the service as internally we deploy to on-premise equipment during development, but it is done this way so to protect our Intellectual Property.

If this is a blocker for you, then do please contact us to describe why and maybe we can work something out.

The resources are placed in a resource group with a read-only deny assignment blocking access to most changes. Some permissions have been allowed, including:

To do this you would use EAP-TTLS with EAP-GTC as your inner method but unfortunately the OS vendors (Android, Microsoft Windows, …​) have broken implementations of EAP-GTC as from a user-interface perspective it is treated as a generic ‘prompt for password’ field that leads to:

It is recommended you use RadSec where possible for reasons of security as well as user privacy.

This is useful if you already have a RADIUS service you are happy with but are seeking a solution to allow visitor access without igniting your bank account on any per-user/device licencing arrangements you may use there.

The typical solution here would be to deploy something like FreeRADIUS to handle this for you, which requires either inhouse expertise or the use of a consultant.

In the spirit of not harming functionality, proxying (either authentication or both authentication and accounting) for the purposes of federation based access is allowed on the team tier but of note the home tier does not allow proxying.

For non-Intranet marked devices, typically upstream federation proxies, your own users roaming will have the User-Name attribute removed from any Access-Accept responses and instead a Chargeable-User-Identity (CUI) in its place. This identity is fixed for all devices the user uses but is rotated once a week. The purpose of the CUI is to aid abuse reports so an operator of a remote site can communicate to you that a particular user has caused them problems and to have you take action or alternatively choose to block that CUI to deny local service.