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

    1. 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.
For a new deployment I am receiving the error “no access to managed application resource identity” in the UI

This is an unfortunate affect of it taking up to 24 hours for permissions to propagate within Azure.

There is not much you can do other than wait it out and occasionally retry the UI.

Though undocumented, we have observed that when you add a new role for the Managed Application Resource identity (for example ‘Key Vault Certificate User’) to the subscription scope, this looks to flush the caching Azure does.

This means you may find it useful to:

  1. Set the roles for the Managed Application Resource identity as you wish.

    • Such as ‘Key Vault Certificate User’ on the Key Vaults you plan to use.

  2. Add any permission for the Managed Application Resource identity on all the subscriptions you wish to affect.

  3. Test that RADNAC now can access those resources.

  4. Remove the subscription scoped roles.
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.

My changes have not taken effect

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

Changes to Microsoft Entra ID user, group or device entities (such as user account being disabled or a group membership change) are checked every every fifteen (15) minutes, this is roadmapped to be resolved in a future release.
RADNAC uses an old Shared Secret for Devices

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

RADIUS over TCP and RadSec connections only check for an updated shared secret at connection time so you will need to either restart your RADIUS device or force a reload as described in our known issues (GH#362) page.

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

Consult the FAQ for a description on how RADNAC determines a network request is being made.

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 = "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 erroneous 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.
EAP-TLS works except for a handful of (older hardware) Microsoft Windows based workstations

The short answer is Microsoft Window’s secures the EAP-TLS certificate using the TPM chip in the workstation and then claims to the RADIUS server it can perform RSA-PSS signing operations (rsa_pss_rsae_sha{256,384,512}) but when it comes to actually doing so it is unable to due to an Microsoft Windows incompatibility with the TPM chip.

Other RADIUS vendor notes describing this issue may be found at Cisco CSCwb19635 and Clearpass CP‑49353 and CP‑50419 (found under ‘Policy Manager’).

This issue is not unique to RADIUS, it affects any service that uses a RSA based TLS client certificate including web sites and web based VPN’s.

This problem can only be confirmed by looking in Windows Event Viewer on the workstation under EapHost/Operational logs for:

EapHostPeerGetResult returned a failure.
Reason Text: The Local Security Authority cannot be contacted.
Error Code: 0x80090304

A common reoccurring theme looks to be the TPM implementation for Microsoft Windows 11 is listed as having an ‘TPM 2.0 sub-version 1.16’ though this is not officially confirmed anywhere.

The solutions available to you in descending order of preference:

  1. Update the TPM firmware, though due to the age of the TPM this may not be possible.

    • Microsoft could but have not taken the opportunity for Windows 11 to test for this deficiency using test vectors and disable RSA-PSS automatically.

  2. Use a ECDSA client certificate which also requires use of a ECDSA server certificate.

    ‘Home’ tier deployments only support RSA certificates.

  3. Replace the workstation with a newer one without problematic TPM hardware.

  4. Disable RSA-PSS on the workstation.

    • RSA-PSS is a requirement of TLS 1.3 (RFC9963 loosens that but vendor support is not widespread) and so attempting to use TLS 1.3 with a client certificate will break elsewhere.

    • For this to work you need to also explicitly disable TLS 1.3 and limit yourself to TLS 1.2 or lower otherwise Windows 11 presents "I can do TLS 1.2 and TLS 1.3 but not RSA-PSS" and the server reports "no shared ciphers" instead of dropping down to TLS 1.2; it is unclear if this is an OpenSSL bug or a countermeasure against a downgrade attacks.

    • This leads to problems such as Remote Desktop (RDP) no longer working as policy may enforce TLS 1.3; though interestingly RDP does not secure its client certificate using the TPM.

  5. Disable server side for EAP-TLS support for RSA-PSS and disable TLS 1.3.

    • RADNAC does not support this but roadmapped is functionality to allow you to target only affected workstations whilst retaining the stronger settings for all other workstations.

For any FreeRADIUS users that may have found their way here, you can identify if you are affected by this issue by inspecting the debugging logs which will show ‘recv TLS 1.3 Alert, fatal access_denied’. It is the access_denied which makes for the unique identifier that you may be affected by this. An example debugging log looks like:

eap_tls: (TLS) EAP Peer says that the final record size will be 24 bytes
eap_tls: (TLS) EAP Got all data (24 bytes)
eap_tls: (TLS) TLS - recv TLS 1.3 Alert, fatal access_denied
eap_tls: (TLS) TLS - The client is informing us that there is a failure inside the TLS protocol exchange.
eap_tls: ERROR: (TLS) TLS - Alert read:fatal:access denied
eap_tls: (TLS) TLS - Server : Need to read more data: error
eap_tls: ERROR: (TLS) Failed reading from OpenSSL: error:0A000419:SSL routines::tlsv1 alert access denied
eap_tls: (TLS) TLS - In Handshake Phase
eap_tls: (TLS) TLS - Application data.
eap_tls: ERROR: (TLS) Cannot continue, as the peer is misbehaving.
eap_tls: ERROR: [eaptls process] = fail
At some point in the past Microsoft Windows changed its behaviour differed and instead sent an all zeros signature that led to the debugging logs showing fatal alert by server - decrypt_error.
Workstations that run Virtual Machines (or containers) are unable to connect

802.1X, which WPA Enterprise utilizes, generally prevents use of virtualization software, such as Microsoft Hyper-V, as the switch or access point the workstation connects to expects only a single MAC address to be presented.

When using an Ethernet bridge topology for your virtual machines, each guest directly presents its MAC address to the switch or access point which leads to problems.

Your options here are:

  • Use a NAT network instead to share the connectivity of your workstation with its guests.

  • Disable 802.1X and use MAC based authentication (MAB) instead.

    • This is roadmapped though many switches and wireless systems natively support overloading this functionality to them that may be run alongside RADNAC.

  • Disable 802.1X or provide a WPA-PSK network for those workstations to connect to.

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 limits network connections and not device (such as connecting to a server) requests.

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 of the default of thirty (30) minutes; values lower than 60 seconds are set to 60 seconds.

    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`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. The minimum value of these is sixty (60) seconds (lower values are set to 60 seconds), but typically is a value between five (5) minutes and a maximum of 1770 seconds (Azure Application Insight sessions timeout after thirty minutes, so higher values will be brought down to 1770 seconds). 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 and nothing works.

RADNAC is broken, components this affects are:

  • Azure Key Vault access

    • Server certificates for EAP-(T)TLS and RadSec.

  • Microsoft Entra ID access

    • Information about your users, groups, devices and verified domains.

The most straight forward way to resolve this is to backup your configuration, deploy a new instance of RADNAC, restore the backup to it and migrate either the public IPs of your original instance to it or your RADIUS devices one by one; remember if you are using RadSec to update the IPs in the server certificate used by RADNAC too.

Completely unsupported and touch and go if this even works, you might be able to recover the original deployment by:

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

  2. Re-establish any IAM permissions to any Key Vault’s that had been granted to the original identity to the new identity.

  3. Re-establish, using the command line, the Microsoft Entra ID permissions so that the Principal Id of the Managed Application System Assigned Identity be allowed {User,Group,Device,Domain}.Read.All permissions to Microsoft Graph API.

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