Android 13 devices unable to connect to 802.1x EAP-TLS

Recently I encountered a situation where a number of Android devices were unable to connect to a wireless network using EAP-TLS authentication, Intune was reporting an Error state for the Configuration Profile however the error message (as usual) didn’t allude to a cause.

The error code displayed within Intune admin centre when drilling down to an affected user’s device was “942518331” and when drilling further it provided a different code of “0x7d24fc5”.

Without access to an impacted device on hand, I was able to find a few articles online where users had reported similar behaviour and a suggested fix stood out as something we hadn’t yet configured (defining a Radius Server name rather than leaving this blank).

InTune fails to deploy Enterprise Wi-Fi profile to fully managed Android (OS 13) devices. – Microsoft Q&A

Android WiFi policy giving error 0xc7d24fc5 and -942518331. Does anyone have any info on this error? – Microsoft Q&A

Defining a Radius Server name within the Configuration profile ensures that during authentication the device only interacts with a specified server rather than negotiating with any Radius server.

According to the comment left on the Microsoft Q&A it appears that a change was introduced to Android 13 where the June (or newer) security update is installed which requires a Radius Server to be defined when connecting to an enterprise Wi-Fi network.

After adding the Radius Server entry and re-syncing on an impacted device it was then able to successfully connect to a corporate wireless network, I was unable to find any notifications from the Intune Support team and/or notes in the Android security update changelog to show that this change was made however there definitely looks to be a link between the June 2023 security update and lack of having a Radius server name defined in your Wi-Fi configuration profile.

Azure AD Joining an Azure Virtual Desktop Multi-user Image

Note – In this blog, all references to AVD are utilizing Windows 10 multi-session.

I’d like to preface this by saying the following is a workaround and is not officially supported by Microsoft, in saying that I am yet to stumble upon any negative implications of doing the below, hence I thought I’d do a writeup on it.

In a virtual desktop environment its common to build your workload from a common image, meaning application, configuration and updates are applied to the image that is then used by the workload to scale out VMs that users access.

This ensures that should users access a different VM their experience will be as identical as possible given the same applications and configuration is present between the two hosts.

Recently I’ve been taking a look at Azure Virtual Desktop making use of all the recent advances including Azure AD Join and enrollment in Microsoft Endpoint Manager (Intune), in addition we’ve been using Nerdio Manager for Enterprise to reduce the friction of setting up this environment, and automating it to scale based on usage.

Nerdio uses a different terminology for Images, calling them Desktop Images; although behind the scenes there is no difference between this and the native Azure toolset.

At the time of writing Microsoft allows you to perform an Azure AD join (AADJ) of Session Hosts within a Host Pool as well as enrollment in Endpoint Manager, this allows you to deploy applications, configuration and scripts.

Deploy Azure AD joined VMs in Azure Virtual Desktop – Azure | Microsoft Docs

Using Azure Virtual Desktop multi-session with Microsoft Intune | Microsoft Docs

However what isn’t currently documented as supported is the ability to join a Image (Desktop Image) to Azure AD and enroll in MEM, this post outlines a workaround that can be used to join an Image to Azure AD and MEM where it can then be targeted for application deployment and updates.

Firstly, we need to enable the System Identity option on the Virtual Machine, this provides a device credential that the Azure AD Join VM Extension will later use to join the domain.

Navigate to the Image VM in the Azure Console, under the Settings header select Identity and enable the System assigned identity.

Option to enable system assigned identity in Azure Console

Next, we can enable a VM Extension that performs the Azure AD join and enrollment with Microsoft Endpoint Manager, at this time this can only be done via the CLI, the following is a PowerShell script that can be imported as a Scripted Action in Nerdio or altered to be run in Cloudshell.

#description: Enables System Identity on VM and Adds AADLoginForWindows Extension

<# Notes:

This Scripted Action will enable System Identity on the targeted Virtual Machine and addition of VM Extension which will perform an AAD Join of the VM and subsequently an enrollment in Microsoft Endpoint Manager

To run this script, find the desktop image in Nerdio, and use the menu to the right of the host to 
select "Run script"


$ErrorActionPreference = 'Stop'

$subscriptionID = $AzureSubscriptionId
$rgname = $AzureResourceGroupName
$vmname = $AzureVMName

#Log in to your subscription
Select-AzSubscription -Subscription $subscriptionID
Set-AzContext -Subscription $subscriptionID

# Enable System Identity
$VirtualMachine = Get-AzVM -ResourceGroupName $rgname -Name $vmname
Update-AzVM -ResourceGroupName $rgname -VM $VirtualMachine -IdentityType SystemAssigned | Out-Null

#Setup Variables for VM Extension
$AzVM = Get-AzVM -Name $AzureVMName -ResourceGroupName $AzureResourceGroupName
$Type = "AADLoginForWindows"
$PublisherName = "Microsoft.Azure.ActiveDirectory"

$ExtensionSettings = @'
     "mdmId": "0000000a-0000-0000-c000-000000000000"

$ExtensionVersion = "1.0"

$VMExtension = @{
ResourceGroupName = $AzVM.ResourceGroupName
Location = $AzVM.Location
VMName = $AzureVMName
Name = $Type
Publisher = $PublisherName
ExtensionType = $Type
SettingString = $ExtensionSettings
TypeHandlerVersion = $ExtensionVersion

#Perform VM Extension addition
Set-AzVMExtension @VMExtension

To breakdown the above, this is a standard Azure AD Join VM Extension however it also includes a mdmId value which is a global GUID for Microsoft Intune, this instructs the VM to not only join the domain; but also enroll in MEM.

Great! we’ve now joined our AVD Image to Azure AD and enrolled it in Microsoft Endpoint Manager, what’s next?

From here you can create an Azure AD Group to us in Microsoft Endpoint Manager for the image.

I would only recommend using this method to allow for Microsoft Endpoint Manager to deploy Win32 applications to the Image, any configuration profiles should be targeted to the running Session Hosts rather than the Image.

Upon testing this, I stumbled upon the fact that a sysprep of the Image (which is handled automatically by Nerdio) does not clean up any references to the device being joined to Azure AD or enrolled in Microsoft Endpoint Manager, and in fact Microsoft warns of this:

Sysprep will not run correctly on a Windows 10 device that has been MDM enrolled – Intune | Microsoft Docs

To get around this, you’ll need to remove the image from Azure AD and de-enroll from MEM on each commit to the image, this will clear any certificates and references on the image that it was ever joined to an Azure AD domain and was enrolled in Intune, a failure to do this will mean that when you power on your Session Hosts based on this image it will state that the VM has already been Securely joined to the domain and will either appear as a duplicate of the image and/or interfere with the join status of the image.

In order to do this we will need to gracefully leave the domain using dsregcmd and remove the AADJ VM Extension, this script (also designed for a Nerdio Scripted Action) can be retrofit to be run to automate these steps.

#description: Run this on the VM itself to de-register it from Azure AD

Start-Process dsregcmd -ArgumentList "/leave"
#description: Removes the device from Azure AD and Intune for sysprep

<# Notes:

This Scripted Action will remove the VM Extension for AAD Join.

To run this script, find the desktop image in Nerdio, and use the menu to the right of the host to 
select "Run script"


$ErrorActionPreference = 'Stop'

$subscriptionID = $AzureSubscriptionId
$rgname = $AzureResourceGroupName
$vmname = $AzureVMName

#Log in to your subscription
Select-AzSubscription -Subscription $subscriptionID
Set-AzContext -Subscription $subscriptionID

#Setup Variables for VM Extension removal
$ExtensionName = "AADLoginForWindows"

#Perform VM Extension removal
Remove-AzVMExtension -ResourceGroupName $AzureResourceGroupName -Name $ExtensionName -VMName $AzureVMName -Force

When building a Session Host from this image, select the option to perform an Azure AD Join and the device will re-join Azure AD under the new hostname and will leave the preinstalled applications intact, should you have the need to target the same Win32 application to install; it will make use of your detection script to identify whether its already installed in the base image and will skip installation if this is the case.

I hope this helps you make use of Azure AD in your Azure Virtual Desktop environment while still maintaining a common state between Session Hosts.

Wired Network Profile stuck on Pending

Recently I encountered situation where it was discovered that we were missing a RADIUS server FQDN in the allowed servers list on some machines which was causing them to fail to connect to the 802.1x secured network and as a result they were stuck with connectivity on our Guest/Remediation VLAN.

Historically we had this configuration deployed through a Win32 app containing a PowerShell script and the exported XML of a functioning Ethernet Adapter connected to 802.1x, it appeared that we had two revisions of this file with the newer one containing the missing FQDN. Turns out it had been deploying to new machines but was failing silently to update the XML on existing machines with the older file revision.

Earlier this year Microsoft made available a new configuration profile called Wired network, this profile allows you to more easily configure these settings without having to export the XML file from a working machine.

This new policy in addition also provides a graphical means to set the Root certificates for server validation and select the Client certificate if using SCEP or PKCS.

In our environment the Trusted Certificate and SCEP configuration profiles that import/generate these certificates are bound to a dynamic user group, originally the Win32 app applying the XML was bound to a dynamic device group.

When we tried to migrate devices from the Win32 app to a Wired network configuration profile we encountered an issue where devices were stuck with a pending status and were not receiving the profile, this remained the case for 96+ hours.

After chatting to Microsoft Support and trying a few other options we found that when scoping a Wired network configuration profile to a device group where the linked trusted certificates and SCEP configuration is scoped to a user group it prevents the configuration from being deployed at all.

Wired configuration profile including Root certificates and Client certificates targeted to User Groups (indicated by “_U_”)

Microsoft do recommend in their Knowledge article for Wired networks to use the same groups across the configuration profiles to ensure that the certificates are present when referenced by the Wired network profile however it did not highlight the behavior when mixing device and user groups between these.

In closing, if you’re encountering an issue where a Wired Network configuration profile (or likely a Wireless one too for that matter) just isn’t deploying to endpoints, make sure you are using either device group targeting or user group targeting across all policies involved (Trusted Certificate/SCEP/Wired Network) .