ADE 0 touch enrollment does not work as expected when end user authentication is not set

[nonpunctual]

Fleet version: <!-- Copy this from the "My account" page in the Fleet UI, or run fleetctl --version -->

Web browser and operating system:

---

💥  Actual behavior

we tried to add fake End user authentication and actually it works So it's seem zero touch deployment doesn't work as expected when End user authentication is not set

🧑‍💻  Steps to reproduce

The expected behavior is : We do not activate the End User Authentication We do not put any data inside the End User Authentication field Whenever we start a device, we want the mobile device management screen to show & we want the device to be enrolled automatically

When we add End user authentication, remote management is enable but the login step is skipped

🕯️ More info (optional)

By reading your documentation, we saw we should enable the End user authentication by checking On but this option doesn't not exist. We finally enable it by using fleetctl CLI

https://github.com/fleetdm/fleet/assets/153771548/d7025acb-45b6-4164-83c2-bd849b32b83e

Finally, once the End user authentication was enabled via fleetctl CLI, we successfully have the authentication flow working as expected

The checkbox to enable/disable the End user authentication is missing in the UI

The Automatic enrollment flow is not working if there is no options filled in End user Authentication even if it is disabled (edited)

We are unable to have the device management screen at device’s startup UNLESS we put some random data in the End user Authentication field on the UI, this is not how it should work.

[sabrinabuckets]

@nonpunctual can you tell me more about how this was discovered and when? It sounds like it's being submitted on behalf of a customer, is that correct?

I test ADE enrollment constantly, both with and without auth enabled. The enrollment completes successfully regardless (some language in this ticket implies that it does not for you/the customer?), but what I have noticed is that there is often a delay between turning on in the UI and authentication populating on a newly enrolled device. Is it possible that's what you're seeing?

I've never treated that behavior as a bug, because it always eventually works, but I do think it's worth investigating if we can get that time reduced. I'm gonna get this moved onto the MDM board to look at, but any additional details/repro would be useful!

[nonpunctual]

Submitted on behalf of customer Preston. Please see this thread for context.

• The checkbox to enable/disable the End user authentication is missing in the UI
• The Automatic enrollment flow is not working if there are no options filled in End user Authentication even if it is disabled
• We are unable to have the device management screen at device’s startup UNLESS we put some random data in the End user Authentication field on the UI, this is not how it should work

The expected behavior is :

• We do not activate the End User Authentication
• We do not put any data inside the End User Authentication field
• Whenever we start a device, we want the mobile device management screen to show & we want the device to be enrolled automatically

[sabrinabuckets]

@nonpunctual gotcha! And have we confirmed with them when they say "the checkbox... is missing" they have navigated to Controls > Setup experience > and selected the team they want to turn it on for? It's a little unintuitive IMO that it's configured in settings but turned on here, so it's possible they missed it (also possible that they turned it on for a team that isn't their default ADE-team), but if it's legitimately not here then they've got somethign going on for sure:

[nonpunctual]

Will confirm this. Thanks!

[sabrinabuckets]

Excellent, thanks for digging into it for us!

[ksatter]

@sabrinabuckets @nonpunctual I'm re-opening this because the missing checkbox was only part of the issue, the underlying issue with zero-touch deployment is still in play.

[sabrinabuckets]

@ksatter can you get us more details on that underlying issue? I don't understand what the customer is experiencing from their description, and I am unable to repro any issues with ADE deployments.

[ksatter]

The customer enabled SSO, then later disabled it and deleted the values from the SSO configuration.

After this, devices were no longer enrolling in MDM during setup.

After putting in "dummy" information for the SSO settings, devices began enrolling.

[mna]

Will document my attempts to reproduce here.

1

Using the default setup assistant profile (i.e. no custom setup assistant uploaded) on "no team". Switching SSO enabled / disabled via fleetctl apply with the appconfig yaml (clearing the SSO configuration values when disabling), it seems to work as expected, updating the profile a few seconds after the change:

In the DB, we can see the profile_uuid changing on enable/disable (interestingly, it seems it's more a hash of the profile than a uuid, as it uses the same values when enabled and disabled, this is fine - it's a value internal to Apple and opaque to us - just an interesting observation):

mysql> select * from mdm_apple_default_setup_assistants;
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
| id | team_id | global_or_team_id | profile_uuid                     | created_at          | updated_at          |
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
|  1 |    NULL |                 0 | 2B4D8AD580425CDB4C6CD4A0E3B32680 | 2024-04-10 14:36:37 | 2024-04-10 14:40:00 |
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
1 row in set (0.00 sec)

mysql> select * from mdm_apple_default_setup_assistants;
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
| id | team_id | global_or_team_id | profile_uuid                     | created_at          | updated_at          |
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
|  1 |    NULL |                 0 | 1D60ADAA10EED9A242720C4C1D96A55F | 2024-04-10 14:36:37 | 2024-04-10 14:42:00 |
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
1 row in set (0.00 sec)

mysql> select * from mdm_apple_default_setup_assistants;
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
| id | team_id | global_or_team_id | profile_uuid                     | created_at          | updated_at          |
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
|  1 |    NULL |                 0 | 2B4D8AD580425CDB4C6CD4A0E3B32680 | 2024-04-10 14:36:37 | 2024-04-10 14:46:00 |
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
1 row in set (0.00 sec)

mysql> select * from mdm_apple_default_setup_assistants;
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
| id | team_id | global_or_team_id | profile_uuid                     | created_at          | updated_at          |
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
|  1 |    NULL |                 0 | 1D60ADAA10EED9A242720C4C1D96A55F | 2024-04-10 14:36:37 | 2024-04-10 14:48:00 |
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
1 row in set (0.00 sec)

mysql> select * from mdm_apple_setup_assistants;
Empty set (0.00 sec)

I also logged the JSON and could validate visually that the ConfigurationURL value of the profile was properly updated with/without SSO on each change.

2

Using the UI, setting the SSO configuration but not enabling it just yet causes the profile to re-register with Apple, but the profile_uuid stays the same (as nothing changed). We can see that it did re-register and update by the updated_at timestamp in the DB:

mysql> select * from mdm_apple_default_setup_assistants;
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
| id | team_id | global_or_team_id | profile_uuid                     | created_at          | updated_at          |
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
|  1 |    NULL |                 0 | 1D60ADAA10EED9A242720C4C1D96A55F | 2024-04-10 14:36:37 | 2024-04-10 14:48:00 |
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
1 row in set (0.00 sec)

mysql> select * from mdm_apple_default_setup_assistants;
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
| id | team_id | global_or_team_id | profile_uuid                     | created_at          | updated_at          |
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
|  1 |    NULL |                 0 | 1D60ADAA10EED9A242720C4C1D96A55F | 2024-04-10 14:36:37 | 2024-04-10 14:55:00 |
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
1 row in set (0.00 sec)

Enabling SSO via the UI also correctly triggers re-registering (and this time, updates the profile_uuid as the JSON actually changed):

mysql> select * from mdm_apple_default_setup_assistants;
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
| id | team_id | global_or_team_id | profile_uuid                     | created_at          | updated_at          |
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
|  1 |    NULL |                 0 | 2B4D8AD580425CDB4C6CD4A0E3B32680 | 2024-04-10 14:36:37 | 2024-04-10 14:59:00 |
+----+---------+-------------------+----------------------------------+---------------------+---------------------+
1 row in set (0.00 sec)

Disabling via the UI similarly resulted in the expected update.

So the issue doesn't seem to be caused by the profile's registration (or at least not in this scenario without a custom setup assistant).

[mna]

@nonpunctual or @ksatter do you have the following information available?

1. Was this for a team or "No team"?
2. Was a custom setup assistant uploaded for that team/no team? (i.e. did they upload a profile in Controls->Setup experience->Setup assistant, "Add profile")
3. If I understand correctly the ticket and the subsequent comments:
   • initially SSO was enabled (was it via UI or fleetctl apply?), devices were properly enrolling,
   • then SSO was disabled AND settings cleared/emptied (again if you know, was it UI or fleetctl apply?) and at this point devices stopped enrolling,
   • setting dummy SSO values without enabling it (UI or fleetctl apply?), and after that devices started enrolling again (without SSO).

One thing to keep in mind, if this was done with the same device that was wiped and re-enrolled to test the setup process, we found during testing that sometimes the device would get in a weird state and would not enroll with the Fleet server, and in this case it needed a sudo profiles renew --type enrollment command to be issued on the device before resetting it: https://github.com/fleetdm/fleet/issues/9147#issuecomment-2018243068

[nonpunctual]

Thanks so much @mna for the detailed troubleshooting! I think we need to let the customer digest your results & hopefully respond on the issue here.

[valentinpezon-primo]

@nonpunctual or @ksatter do you have the following information available?

1. Was this for a team or "No team"?
2. Was a custom setup assistant uploaded for that team/no team? (i.e. did they upload a profile in Controls->Setup experience->Setup assistant, "Add profile")

3. If I understand correctly the ticket and the subsequent comments:

   • initially SSO was enabled (was it via UI or fleetctl apply?), devices were properly enrolling,
   • then SSO was disabled AND settings cleared/emptied (again if you know, was it UI or fleetctl apply?) and at this point devices stopped enrolling,
   • setting dummy SSO values without enabling it (UI or fleetctl apply?), and after that devices started enrolling again (without SSO).

One thing to keep in mind, if this was done with the same device that was wiped and re-enrolled to test the setup process, we found during testing that sometimes the device would get in a weird state and would not enroll with the Fleet server, and in this case it needed a sudo profiles renew --type enrollment command to be issued on the device before resetting it: #9147 (comment)

hi @mna

1 - We do not used any team, so "no team" 2 - No custom setup assistant uploaded 3 - We never used fleetctl, only the UI 4 - We indeed used the same device over and over again to test it

The problem was the following :

• We could not make the ADE 0 touch work without having the "End user authentication" inputs filled in the UI

If you managed to enroll a device using ADE 0 touch without having the "End user authentication" ON and without having anything on the "End user authenticaiton" fields, this issue was probably related to #9147 as you said

[mna]

@valentinpezon-primo Thanks for the response! We will double-check some things this week, I'll post back here whatever we find. It does look possible that it is the issue I mentioned in https://github.com/fleetdm/fleet/issues/9147#issuecomment-2018243068, but there are a few things we want to verify.

Meanwhile, if you do get into that broken state again, can you give that sudo profiles renew --type enrollment command a try and see if that fixes the issue?

[mna]

@valentinpezon-primo we did some more testing and I can confirm that the enrollment profile properly gets updated when the enable/disable end user authentication setting for Automatic MDM setup is changed (it does take a few seconds/up to a minute as it is a background job), and it gets applied to the device pending enrollment. We did a full enrollment test with the settings enabled and disabled.

There's one thing you mention that is not clear to me, when you say "We never used fleetctl, only the UI", but also that "We could not make the ADE 0 touch work without having the "End user authentication" inputs filled in the UI", but there's no way to clear the "End user authentication" settings via the UI once they are entered (the "Save" button is disabled if the settings are empty). Maybe there was some confusion with the SSO settings at the organization level, which are settings for a different concept? I made a video to try to make this clearer: https://www.loom.com/share/ff35fd07a957495a8dff230270b74431?sid=27991161-5591-4109-ab77-eb0be595eacb , hopefully this is helpful.

But from what I can tell, it looks like you're running into the issue mentioned in the previous comment. I'll leave this ticket open a bit in case you have more details or new information in light of this additional information, but otherwise I think we can close this in the next few days.

[mna]

Closing as planned in https://github.com/fleetdm/fleet/issues/17133#issuecomment-2059839213.

[fleet-release]

Touch enrollment glitch, Fixed, now flows without hitch, Fleet grows, without switch.