Billing is made entirely through Azure, we (as in ‘coreMem Limited’) only appear as a line item on your Azure bill.

RADNAC is offered as a ‘Managed Application’ which is billed as a monthly flat fee. When you start the installation, you will be immediately billed for the month up front for every deployment.

Information on how to obtain a refund is described on Azure’s Marketplace pages which if the service is cancelled within 72 hours should be automatically refunded. If it is not, you need to contact Microsoft by opening a support ticket with them.

Managed Applications do not support free trials though you may make use of Microsoft’s refund policy or for longer periods use the ‘Home’ tier or ‘Team’ tier.

In addition to the listed price Marketplace pricing for RADNAC you will be charged Azure infrastructure costs for the resources created and used by RADNAC. These costs are not expected to be high and for most users it should be no more than $15/month for a single VM deployment:

Our comparison page on the main site includes a table describing expected real world monthly costings.

All tiers offer the same functionality and security features but the ‘home’ end has efficiency, compliance and reliability aspects considered useful to larger entities disabled in the following way:

The ‘team’ tier allows for:

The ‘enterprise’ tier further allows for:

If you expect a peak load of more than one hundred (100) requests per second (rps) then you should consider yourself a heavy load deployment.

You should only expect to see this rate in very large organizations 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:

Anything with at least two (2) vCPUs and 2GiB RAM is recommended; the install process recommends Standard_B2 instances.

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 updates 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.

Yes, B1-series instance types, in particularly Standard_B1ls instances, make for a great instance type for those sensitive to costs such as home tier users.

Yes, ephemeral OS disks are in fact recommended to improve performance and lower your infrastructure running costs.

Using an Azure region that is further from your site increases the round-trip time (RTT) which you may be more familiar with as your ping time.

This typically is a problem for EAP-(T)TLS authentications as for large certificate chains only about one thousand (1000) bytes can be transmitted in a single round trip; 2kiB to 5kiB in total is not uncommon which for a RTT of 100ms (‘width’ of the US or EU) immediately adds at 200 milliseconds (one fifth of a second) to the authentication time experienced by your users and this is before delays due to database or Microsoft Entra ID authentications are taking into consideration. This will only get work as the downside of solutions to Post-Quantum (PQ) attacks are large certificate chains, as much as three (3) to five (5) times larger.

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.

Not at this time. The focus of the service is to offer a RADIUS solution to those where if their Internet connection was down, no one would be able to work anyway.

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.

They are more expensive due to the banded pricing Azure use for managed disks and that RADNAC does not need more than 4GiB of disk space, as a summary pricing per month is:

In addition to being more expensive:

For RADNAC, this makes the SSD options always cheaper, better performing and more reliable than the non-SSD option.

Yes. You can configure by realm (eg. @example.com) which RADIUS server to forward authentication (Access-Request) and (optionally) accounting (Accounting-Request) packets to whilst sending all other realms to a pool of upstream federation RADIUS servers (such as eduroam® and OpenRoaming™).

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 licensing arrangements you may use there.

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

Yes, you can use RADNAC groups to apply a different policy to network and device requests.

RADNAC identifies network connections (wired and wireless) by inspecting the contents of the RADIUS attribute Service-Type in the Access-Request's it is sent for when it is set to Framed-User[2] or when NAS-Port-Type is set to Ethernet[15] or Wireless-802.11[19].

Access-Request's not matching these rules, including when both Service-Type and NAS-Port-Type are not, are treated as a request for a device login.

The API is served by an Azure Function hosted on a Flex Consumption plan that is configured to be serverless (scale-in to zero) to save costs. The effect is when the API is considered by Azure to be idle, resources are deallocated and you are no longer billed for it.

The disadvantage is cold starts that manifest as slow API calls that make the UI feel slow.

Unfortunately Microsoft do not expose controls to set our own idle time thresholds and so the only solution to this would be to use always ready instances which add a minimum of $5/month to your Azure bill.

As the API is expected to be only occasionally used, for some only once when you configure your deployment, we decided to lean towards cost savings.

No. They are known of and actively being addressed.

These issues can be grouped into a two classes:

If you have a particular concern that is blocking you using RADNAC, then do please contact us to describe why and we may be able to schedule work sooner to resolve it.

Yes, only if you use and your equipment supports Message-Authenticator when using UDP.

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

For RadSec (transport) and EAP-TLS, TLS version 1.3 is supported. For EAP-TTLS only TLS version 1.2 is enabled as supplicant (ie. device connecting) support is lacking and leads to interoperability issues; at some later stage this restriction may be lifted.

When configuring a device in the RADNAC user interface if you mark it as an ‘Intranet’ (enabled by default) device, for authentications using EAP-TTLS the inner User-Name attributed is copied to the Access-Accept response which allows you to directly monitor network and device usage from your equipment and know who is connecting.

For non-Intranet marked devices, something you should configure upstream federation proxies as, when your users roam and visit remote sites the User-Name attribute is removed and a Chargeable-User-Identity (CUI) takes its place. This opaque identity is the same for every connection the user makes on any device to a given Operator-Name site but its value changes each week. The purpose of the CUI is in aiding a visited site operator when handling abuse reports so that they may either communicate with which user requires an ‘intervention’ or they may choose to just block that CUI.

Linking a CUI back to the user responsible is only possible by the site operator of the user’s realm, and to do this they can query the logs held by Azure Monitor and create a lookup table between user_AuthenticatedId (holds PII) and user_Id (holds CUI).

It is important to configure your supplicants (end user devices) to present an anonymous user name as this is communicated in the clear over wireless networks, over your wired network (when not using RadSec) and by proxy servers located in other administrative domains of a federated service.

The solution is to split the identity into two parts:

As an example, when preserving the privacy for ‘bob@example.com’ the outer identity should be set to ‘@example.com’. Having an empty user component (the bit before the @) may look strange, but it is valid best practice.

To implement this, set the value of the field names listed below to the anonymous outer identity for your realm (domain):

No and it also does not use the metered billing APIs.

Your deployment is your own and private to you.

We have no visibility in how you use it, other than if you choose to use a 'co-administrator' plan which is not the default and not recommended for most users.

We do received lifecycle notifications described in our privacy policy.