iOS/iPadOS hosts getting stuck during automatic enrollment (ADE)

[ddribeiro]

Fleet version: 4.63.1

Web browser and operating system: iOS 18.3.1

Slack thread with troubleshooting: https://fleetdm.slack.com/archives/C075TURNLB0/p1739978778460909

Zoom recording of troubleshooting: https://fleetdm.zoom.us/rec/share/nfEsDgLyglH4i7Dl6MUbn2QU1GJbj3VvNEOBCST5UtJjHzl_rWymCGs3O3vzZROt.dr52lBNLRjlAXz6a

Slack thread with customer-beatrix: https://fleetdm.slack.com/archives/C08AH3PSBK5/p1742671928015029

---

💥  Actual behavior

When enrolling iOS devices to Fleet via ABM, the web view that briefly appears during enrollment does not automatically dismiss and there is no way to manually dismiss it. This prevents the end user from continuing with the enrollment. The device needs to be restarted to dismiss the web view.

🧑‍💻  Steps to reproduce

I have not reproduced this on my own yet, but I do not have an iPhone to test with.

1. Assign an iOS device in ABM to your Fleet server. Delete any existing host record on your Fleet server for that device, wait for the next ABM sync to complete so you see the "ghost host" record in Fleet.
2. For your test team in Fleet, use the default enrollment.json profile and make sure end-user authentication is turned off.
3. Power on the iOS device and connect it to Wi-Fi. Proceed through the setup assistant to enroll the device. After tapping "Enroll this iPhone" the sheet with the web view will appear and not dismiss. Tapping the dismiss button in the top left does not work, nor does slide down on the sheet. If the sheet dismisses, the issue has not been reproduced. The device will stay at this state indefinitely.
4. If the issue is reproduced, the iOS device will still enroll in Fleet. The ghost host record will become a full device record with its own host details page.

🕯️ More info (optional)

• So far, it seems this only affects iOS devices. iPadOS devices enrolled into the same team do not experience this issue.
• The team the iOS device is getting enrolled in does not have end user authentication enabled. My understanding is with this setup, Fleet uses /api/mdm/apple/enroll?token=<redacted_token_here> for the values for ConfigurationURL and ConfigurationWebURL in the enrollment profile.
  • Navigating to this URL in a browser on a Mac downloads the enroll.mobileconfig profile as expected.
• MDM commands appear to be sent to the device while the device is stuck at the web view, including DeviceConfigured.

[ddribeiro]

@lukeheath Because this is preventing customer-deebradel from enrolling iOS devices via ADE into Fleet, I think this should have a P2 label.

cc: @zayhanlon

[PezHub]

QA Reproduce notes

No luck reproducing yet. So far I've successfully enrolled an iPhone running iOS 18.1.1 and 18.3.1 on Fleet versions 4.63.1 and 4.65.0.

[lukeheath]

@ddribeiro Agreed, this is a P2.

[ddribeiro]

Some updates:

• Deebradel uploaded a custom enrollment profile that contains a ConfigurationURL that points to an enrollment URL they host. They do not have this issue when they use their ConfigurationURL. They can consistently reproduce when using the default value that points to their Fleet server.
  • Because of this, they are technically unblocked and can now enroll iOS devices. However, I still think we need to at least identify the root cause of this issue in case deebradel or other customers run into it.
• They are seeing this in their staging (4.65) and production (4.63.1) environments.

[PezHub]

Hi @ddribeiro , any luck setting up a time for @gillespi314 and I to meet with the team?

[ddribeiro]

@georgekarrv @lukeheath customer-beatrix is reporting this as well. I think we need to escalate this to a P1 as it is blocking many iOS and iPadOS enrollments for them.

They are managed cloud and have given us permission to look at logs and access their environment to get whatever information we need to help resolve this.

cc: @zayhanlon

[lukeheath]

Thanks for the heads up, @ddribeiro. I agree, escalating to P1. @georgekarrv Please let me know if additional support is helpful. I believe @lucasmrod built this feature initially.

[georgekarrv]

@ddribeiro Have you filed an apple feedback ticket yet and can we have it linked here?

[ddribeiro]

@georgekarrv Just got it filed now. It doesn't seem to exist anywhere outside my Feedback.app on my computer, so I don't think I can link to anything. Feedback number is FB17256199.

[PezHub]

QA Repro notes

I was able to reproduce in our hosted Render instance with personal devices (iPhone & iPad) enrolled in an ABM other than Fleet's. I'll pair with Sarah to review logs and am adding this screenshot of the stuck screen for reference.

[georgekarrv]

I have also been attempting to reproduce this to get more debug information (http sniffing) but still no luck. Will continue Monday

[georgekarrv]

Gabe was able to reproduce again today.

"This was a result of me backing out of what would have been a successful ADE enrollment, changing the OS Updates settings, then retrying to enroll without a restart or wipe and eventually hitting this blank screen. So maybe we have a way to repro...but thats a big maybe."

[PezHub]

I went thru the exact same steps and was able to reproduce on my iPhone:

1. Add your ABM device to a team with OS Updates configured with a minimum version set to something higher than the existing iOS installed. example: 18.5
2. Set the deadline to a past date
3. Enroll the device and continue thru the steps until you see the Software Update page notifying that you must upgrade
4. hit the < back button until you are at the beginning of the setup process
5. Go back to your Fleet UI and remove the OS Update setting, click Save
6. On your device, go thru the setup steps again and click Enroll
7. This is where you should see the blank Remote Management screen

Note: you will most likely need to restore your device using Apple Configurator to get it back to a functioning state which will automatically install the latest iOS so you only get once chance to repro 🫠

[getvictor]

@ddribeiro A potential workaround is to force the iOS device to restart. Does the enrollment successfully complete then? https://support.apple.com/guide/iphone/force-restart-iphone-iph8903c3ee6/ios

[getvictor]

@ddribeiro Does this issue happen if they set up iOS update to latest (18.5)? When the customer is using a custom configuration_web_url, I assume they're sending a custom enrollment profile to the device from that URL. Can they share that profile?

[ddribeiro]

@getvictor

A potential workaround is to force the iOS device to restart. Does the enrollment successfully complete then?

After rebooting, the device doesn't get stuck on the web view, but the device does get stuck waiting for a DeviceConfigured command. If we send the DeviceConfigured command manually, it will proceed through the setup assistant and become enrolled.

Does this issue happen if they set up iOS update to latest (18.5)?

Anecdotally, I feel like we ran into this issue _a lot in iOS 18.2 and 18.3. It seemed to stop when iOS 18.4 came out. I have personally seen any devices running 18.4+ experience this issue.

When the customer is using a custom configuration_web_url, I assume they're sending a custom enrollment profile to the device from that URL. Can they share that profile?

Do you want the DEP enrollment profile (JSON) or the MDM enrollment profile (.mobileconfig)? I think they would be willing to share either. I'm certain they are using the Fleet provided MDM enrollment profile with no modifications.

[getvictor]

I'm able to reproduce this issue in iOS 18.4.1. Occasionally, I'm able to restart the device and finish the setup.

I think there is a timing issue as well. If I follow Gabe's instructions but I wait for a long time before trying to go through the flow a second time, then I don't see the issue.

[getvictor]

I filed a feedback case with Apple: FB17627420

[getvictor]

@georgekarrv @gillespi314 I was able to get rid of the popup by:

• Clearing the configuration_web_url and setting the url to the enroll URL, like http://example.com/api/mdm/apple/enroll?token=123
• Allowing /api/mdm/apple/enroll endpoint to accept POST requests

I was able to enroll my iOS device with these changes. So, the scope of this change doesn't seem that big. I can take a look some more on Tuesday.

Request from device for enrollment profile:

POST /api/mdm/apple/enroll

Headers
Accept	*/*
Accept-Encoding	gzip, deflate, br
Accept-Language	en-US,en;q=0.9
Content-Length	3760
Content-Type	application/pkcs7-signature
Host	<server>
User-Agent	CloudConfiguration/1.0
X-Forwarded-For	<IP>
X-Forwarded-Host	<server>
X-Forwarded-Proto	https

[gillespi314]

• Clearing the configuration_web_url and setting the url to the enroll URL, like http://example.com/api/mdm/apple/enroll?token=123
• Allowing /api/mdm/apple/enroll endpoint to accept POST requests

I was able to enroll my iOS device with these changes. So, the scope of this change doesn't seem that big. I can take a look some more on Tuesday.

@getvictor, thanks for digging into this!

Does the POST request include the x-apple-aspen-deviceinfo header?

[getvictor]

@gillespi314 I didn't see that header.

[PezHub]

@getvictor did you come up with another way to reproduce the blank remote management window? Both my devices are on the latest OS version so i'm looking for a different way to test if possible.

[getvictor]

There's a way to install the previous (still supported) version on your iOS device. I don't recall the details, but I had to download the image and then put my device into a special state for this, I believe.

[PezHub]

QA Test Results

I tested the fix using the only method we've been able to consistently reproduce this issue... and I am no longer seeing the blank screen.

@ddribeiro it would be great for the customers to test on their end when able (maybe some of them have a staging env where they can pull the current RC) before we close this ticket. I'm moving to "ready for release" but we can pull it back if needed.

[ddribeiro]

@PezHub I've confirmed with at least one customer who experienced this issue that 4.69 seems to fix the issue.

[fleet-release]

Enrollment stumbles, Fleet's gentle fix unfurls, Devices now hum, no fumbles.