Tag: 802.1x

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.

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.

Microsoft tip – Configure 802.1x wired network settings for macOS and Windows devices in Microsoft Intune | Microsoft Docs

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