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.
Microsoft Entra ID Authentication is not working as I expect

Immediately after configuring authentication for Microsoft Entra ID, the user interface may report that it has been configuration but is still unable to complete the integration. This is usually due to it taking up to 24 hours for permissions to propagate within Azure.

During this period, and due to the distributed nature of Microsoft Entra ID, some requests may be authorized whilst others are not so expect some settling in wait time to be involved as though it may look at first to work, it may intermittently break within this period before returning once again.

From the user interface you see the results of the configuration service testing Microsoft Entra ID but this same situation also affects the backend RADIUS service its-self.

Unfortunately there is nothing that can be done here other that wait for now.

Multi-Factor Authentication (MFA) is not working as I expect

Please see the ‘Troubleshooting’ section of the Microsoft Entra ID MFA documentation.

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.

I am unable to get RadSec TLS-PSK (RFC 9813) connections to work

Supporting RadSec X.509 and PSK for both TLS versions 1.2 and 1.3 all on the same port is difficult so until this problem can be solved you need to configuration your equipement to connect to RADNAC on port 2084/tcp for RadSec TLS-PSK connections.

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.

I added a new reply attribute to a group and authentications no longer work

RADIUS uses dictionaries to map friendly readable names back to and from numbers that the RADIUS protocol uses. If your attribute name is not in the dictionaries that come with FreeRADIUS then it will be unable to send that attribute over the wire.

To determine if this is the case, use radclient or ‘NTRadPing’ (does not support Message-Authenticator!) to send a (non-EAP) request to confirm if the Reply-Message provides the reason for the failure due to an unknown attribute (you may also look for this in Azure Monitor):

$ printf 'User-Name = %s\nUser-Password = "%s"\nService-Type = Framed-User\n' bob hello | radclient -x 192.0.2.1 auth testing123
Sent Access-Request Id 22 from 0.0.0.0:42855 to 192.0.2.10:1812 length 67
	Message-Authenticator = 0x
	User-Name = "bob"
	User-Password = "hello"
	Service-Type = Framed-User
	Cleartext-Password = "hello"
Received Access-Reject Id 22 from 192.2.0.10:1812 to 192.0.2.1:42855 length 106
	Message-Authenticator = 0x77b6b1440019b3bb21fd9cea4555588f
	Reply-Message = "radnac_users: Failed to create the pair: Unknown name \"My-Unknown-Reply-Attribute\""
(0) -: Expected Access-Accept got Access-Reject

The fix is to correct (or remove) the erronious reply attribute.

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.
I have less than ten devices but keep hitting the session limit on the Home tier

RADNAC tracks sessions by using:

  • The device’s MAC address (Calling-Station-Id) see in the Access-Request (authentication) and Accounting-Request (accounting) packets.

    Devices may change their MAC address over time (this is recommended, best current practice and should be left enabled) though the period is typically measured in days and should not impact this mechanism, however you may wish to read more about this behavior for your operating systems such as Android, Apple and Microsoft Windows.

  • Accounting (session) data to determine more accurately when devices connect and disconnect

  • Only considering in scope are network (such as wireless network connections) and not device (such as connecting to a server) requests.

    • Considered a network request when the value of the RADIUS attribute Service-Type is set to Framed-User.

If you have not configured, or your equipment does not implement correctly, sending accounting data to RADNAC it will be unable to accurately track the number of simultaneous sessions in use. In this situation it will fallback to a using the time of the last authentication for a given MAC address and consider its online period to be thirty (30) minutes.

This behavior is configurable with two complementary mechanisms:

  • If you are unable to send accounting data, sending Session-Timeout on Access-Accept means the value provided here will be used instead (treated with a minimum value of 60) of the default of thirty (30) minutes.

    To do this, create a group, associate all your users to it and configure the sending of the following RADIUS attributes:

    Session-Timeout = 300
Termination-Action = RADIUS-Request

    The value of Session-Timeout is measured in seconds and use of multiple values leads to unspecified behavior for your equipment though RADNAC will choose the maximum value. It is strongly recommended as shown you also include Termination-Action otherwise your devices will reconnect in a non-transparent way leading to a very poor experience.

  • If your wireless equipment does not implement sending accurate accounting data (such as the attribute Acct-Status-Type for the values Accounting-On and Accounting-Off), then you should configure the equipment to send updates faster or send Acct-Interim-Interval on Access-Accept for RADNAC to determine if the equipment is potentially buggy where it will close a session after an interval of more than three (3) times the value of Acct-Interim-Interval (treated with a minimum value of 60) which when not supplied is assumed to be ten (10) minutes.

    To do this, create a group, associate all your users to it and configure the sending of the following RADIUS attributes:

    Acct-Interim-Interval = 300

    This value is measured in seconds and use of multiple values leads to unspecified behavior for your equipment though RADNAC will choose the maximum value. You should not set this value lower than sixty (60) seconds, but typically is a value between five (5) minutes and sixty (60) minutes. The value provided here affects the granularity of the monitoring in particularly the amount of data the device transfers during each update. It does not affect session duration time as the wireless equipment should immediately inform RADNAC of disconnections.

I turned off the Managed Application System Assigned Identity, what now?

Services that access will now no longer be working:

  • Azure Key Vault

    • Server certificates for EAP-(T)TLS and RadSec will be broken

  • Microsoft Entra ID

    • Information about your users, groups, devices and verified domains will be broken

    • This only applies if you used the recommended non-application integration

To resolve, the service should recover if you:

  1. Turn back on the System Assigned Identity for the Managed Application.

  2. Re-establish any IAM permissions (Key Vault and Microsoft Entra ID) that had been granted to the original identity to the new identity.

  3. Go to each VM in the managed resource group, and click on 'Restart'.

After five to ten minutes, the service hopefully will recover, though with the caveat where it does not you may be required to wait up to 24 hours for permissions to propagate within Azure.