Troubleshooting

Deployment failure due to one or more Resource Providers not being in the ‘Registered’ state

During deployment Azure should automatically enable those required resource providers during the installation process however it occasionally fails to do so correctly, particularly for newly created subscriptions, and may require you to do this process manually.

When using the installation wizard, if you are presented with a warning about unregistered Resource Providers, you will be presented with a checkbox labeled ‘Register Resource Providers’ that when checked will immediately attempt to register these on your behalf. Alternatively this process may be done manually by reading below.

Fortunately the process is straight forward:

  1. Navigate to your subscription within the Azure portal.

  2. From the panel on the left, go to the menu section Settings  Resource providers.

  3. For each of the following resource providers, search for it, select it and if necessary click on the Register button at the top; there is no need to wait for each one to complete before moving onto the next one.

    • Microsoft.AlertsManagement

    • Microsoft.Authorization

    • Microsoft.Compute

    • Microsoft.ContainerInstance

    • Microsoft.Insights

    • Microsoft.KeyVault

    • Microsoft.ManagedIdentity

    • Microsoft.Network

    • Microsoft.OperationalInsights

    • Microsoft.Resources

    • Microsoft.ServiceBus

    • Microsoft.Solutions

    • Microsoft.Storage

    • Microsoft.Web

  4. Change the ‘Status’ filter at the top to show ‘Registering’ and refresh the page until they all complete, this should take no more than five (5) to ten (10) minutes.

    Occasionally some entries may seemingly remained stuck in the ‘Registering’ state which usually can be resolved by selecting the resource provider and pushing the Re-register button at the top; if not open an Azure support ticket.
Multi-Factor Authentication (MFA) is not working as I expect

In addition to the client side supplicant limitations, the Microsoft Entra ID integration also has its own limitations when used with RADIUS that you should consult.

Another common issue is that by default RADIUS clients (eg. wireless access points, VPN appliances and networking switches) expect replies to an authentication to complete within a few seconds which is not long enough for a push notification to make it to a user’s phone, for it to be interactively reviewed and confirmed and then response to make it back to the RADIUS service. This leads to timeouts and authentication failures. The workaround is to increase any RADIUS timeout values to thirty (30) seconds, any higher will have no effect; for MikroTik equipment the configuration parameters are called timeout and radsec-timeout.

Changes have not taken effect

Usually changes are picked up instantly upon the change being made but in the event of a temporary error, the service checks for any missed changes every fifteen (15) minutes.

RADNAC uses an old Shared Secret for Devices

RADNAC uses a cache for RADIUS over UDP and TCP that remains valid for ten (10) seconds after a configuration reload has been picked up.

For RadSec using PSK no caching is used and changes are immediately applied upon a configuration reload.

My device authentications are being treated as network access requests

RADNAC considers the request to be for network connectivity (eg. wireless network access) where the value of the Service-Type attribute is set to Framed-User (or when not present) in the RADIUS Access-Request whilst any other value is considered a device (eg. managed switch) request.

Unreliable EAP-TLS Authentications

Azure is unreliable for EAP-TLS authentications when using RADIUS over UDP due to it dropping out-of-order IP fragments, and as such the only practical solution, and strongly recommended, is to use RadSec where possible (or TCP where not) to avoid this issue completely.

For those interested in the why, this occurs as there is no provision in EAP to control the size of messages sent from the ‘supplicant’ (client, such as Microsoft Windows, macOS, …​) to the authenticator (server, where RADNAC fits in this picture). The issue is EAP-TLS requires the client to send large messages to the server which leads to IP packet fragmentation due to the transition from EAPOL-over-Ethernet to EAP-over-RADIUS. These packets tend to arrive out of order when traversing the Internet as routers will send the first packet down one link and the subsequent down potentially different links (as there is no Layer 4 tuple to pin to). This is not a problem for EAP-TTLS as the server does not deal with EAPOL and can administratively set the message size to a lower value (at the cost of more round trips and a slower authentication); also helping here the an unofficial standard where the RADIUS client includes a Framed-MTU attribute to suggest dynamically to server a maximum EAP-Message size it knows will work locally to avoid the issue though only for messages flowing in the direction from the server to the client.

This is made worse if you use an Azure VPN Gateway as it further lowers the MTU of the connection which increases fragmentation.
It is rumoured you may open a ticket with Azure to attempt to resolve this though it comes with a long list of caveats. Currently RADNAC does not support being installed to an existing VNet though if you require this do get in touch and we will should be able to work something out.