Back in March 2024, a post by John Marcum caught the attention of some Intune professionals. He stated, that if you manually create an Autopilot configuration file and upload it to a personal device during the OOBE, the device is seen as a corporate device and enrollment can be completed to your tenant, thus bypassing any personal Windows device enrollment restrictions that may be in place. This of-course, caused quite a stir…
Previously, there were already some corporate device enrollment restrictions, whereby corporate devices were still blocked unless they were already registered with Autopilot, such as Automatic MDM enrollment through Entra join using the OOBE or Windows settings. Now, Microsoft have finally released a ‘fix’ and updated the documentation for what is just a logical flaw in the design of the service, which now ensures Autopilot for existing devices cannot bypass personal device restrictions.
Understanding the problem
There are varied opinions about whether this design problem is even an issue or not. Simply put, if personal device enrollment was set to blocked within Intune, someone with valid authentication information could enroll any supported Windows device they see fit into their organisation’s tenant.
Say a user took advantage of this issue and enrolled their personal laptop, the device has likely been reset, no longer contains any personal data and has all the same security policies and software installed compared to a corporate-owned device, so what is the issue?
In my opinion, the main issue is a lack of expectation and accountability, which could lead to poor performance by the employee and putting company data at risk. Here are some thoughts:
- The device will be treated as personal. Users may be more lax with treating a personal device, such as using it in public, leaving it unlocked and allowing friends or children to use it for unrelated activities.
- It may become more costly. Should the device break, need repair or need troubleshooting, while your IT department may have a duty to ensure you can work, they will not have an obligation to fix something that they don’t own, i.e. your laptop. This will cost you (the employee) money, lose the company money (time) and may even cause resentment.
- Your privacy is not protected. If you are using a personal device for work, it may need to be searched as part of a company investigation. Any personal information you hold on that device is no longer personal.
- Corporate devices are more secure. Generally speaking, a corporate vendor will have been vetted and assumed secure, and the hardware should hopefully be free of any major security concerns.
The list of problems against (and for) using personal devices for work could go on, while some argue flexibility, others argue security. Let me know what side you are on!
What has Microsoft changed in AutoPilot?
In the first week of April 2024, Microsoft began to silently update the documentation for existing device support with Autopilot. As stated in the Blocking personal Windows devices documentation.
Intune marks devices going through the following types of enrollments as corporate-owned, and blocks them from enrolling (unless registered with Autopilot) because these methods don’t offer the Intune administrator per-device control:
- Automatic MDM enrollment with Microsoft Entra join or hybrid Entra join via Windows Autopilot for existing devices.
To expand on this statement a little further, the method of uploading the Autopilot file to a device that isn’t already enrolled in the Autopilot service, falls under Autopilot for existing devices. What is made clear by Microsoft about Autopilot for existing devices, is that these methods do not support self-deploying or pre-provisioning mode, but user-driven mode only, as these methods require TPM attestation and the fact that the device isn’t already registered to the Autopilot service. Also, the methods within Autopilot for existing devices means that the device is registered to Microsoft Intune using the Entra user-token, instead of the device-token, which would be used if the device was already registered to Autopilot.
Testing AutoPilot for existing devices
To test that the behaviour of Autopilot for existing devices has changed (the device should be blocked), I built a new virtual machine using Hyper-V, then created a new disk which I can use to copy files to and from the operating system, like so:
To create the AutopilotConfigurationFile.json, use my example below and change the following information:
- CloudAssignedTenantId: Find your tenant ID with my tool.
- CloudAssignedTenantDomain: Your tenant’s primary domain name.
- ZtdCorrelationId: A random GUID (generated with an online tool).
{
"CloudAssignedTenantId": "YOUR TENANT ID",
"CloudAssignedForcedEnrollment": 1,
"Version": 2049,
"Comment_File": "Profile Autopilot Profile1",
"CloudAssignedAadServerData": "{\"ZeroTouchConfig\":{\"CloudAssignedTenantUpn\":\"\",\"ForcedEnrollment\":1,\"CloudAssignedTenantDomain\":\"YOUR DOMAIN NAME\"}}",
"CloudAssignedTenantDomain": "YOUR DOMAIN NAME",
"CloudAssignedDomainJoinMethod": 0,
"CloudAssignedOobeConfig": 1310,
"ZtdCorrelationId": "RANDOM GUID"
}Once the file is accessible from the test machine, copy and paste it to the following location and reboot the computer:
C:\Windows\Provisioning\Autopilot\When the computer next starts, you will be prompted to sign into the device with your corporate login details (only the organisation within the Autopilot profile). If you have personal device enrollment for Windows blocked within Intune, you will then be greeted with the following error message:
Impact to provisioning
Ideally, you should not be using this method for provisioning devices anyway as the preferred method should be to obtain the hardware hash and upload it to Autopilot. This can be done in a few ways, such as through your OEM or using the PowerShell scripts that utilise Microsoft Graph during the OOBE.
If you are using another operating system deployment method (such as SCCM) to inject the Autopilot configuration file into the system, then this will have a direct impact on you. In this case, you should consider alternative methods of deployment such as contacting your device vendor to either supply or upload device hashes to Autopilot for you in advance.
