"last_enrolled_at" key does not reflect MDM enrollment date

[pintomi1989]

Fleet version: <!-- Copy this from the "My account" page in the Fleet UI, or run fleetctl --version --> Reported in Fleet Fleet 4.47.0 Go go1.21.7 osquery 5.11.0 Fleetd 1.22.0 Web browser and operating system: Current version

---

💥  Actual behavior

Unexpected behaviour in the DEP / fleet sync flow on the getHost api data here are the steps we took:

• Enroll a mac using 0 touch deployment process
• Wait that the device is well synced and appears on fleet UI as enrolled
• Wipe this computer & delete it from the fleet UI
• The device is deleted from the UI but instantly comes back since fleet detect it’s in the ABM
• Device is on the FleetUI but greyed-out
• When I run the getHost route on this device I get the following data, with some dates reset and some other not:

  {
  "host": {
      "created_at": "2024-03-19T10:41:34Z",
      "updated_at": "2024-03-19T10:48:05Z",
      "software_updated_at": "2024-03-19T10:41:34Z", // still has the old date - shouldn't be either null or a new date ?
      "id": 88,
      "detail_updated_at": "2024-03-19T10:35:34Z", // still has the old date - shouldn't be either null or a new date ?
      "label_updated_at": "2000-01-01T00:00:00Z",
      "policy_updated_at": "2000-01-01T00:00:00Z",
      "last_enrolled_at": "2024-03-19T10:34:00Z", // still has the old date - shouldn't be either null or a new date ?
      "seen_time": "2024-03-19T10:41:34Z",
      "refetch_requested": true,
      "hostname": "",
      "uuid": "08312B65-B905-5AA3-A30F-BEEF43679E3B",
      "platform": "darwin",
      "osquery_version": "", // everything is empty which is expected since we deleted the device beforeha,ds
      "os_version": "", 
      "build": "",
      "platform_like": "",
      "code_name": "",
      "uptime": 0,
      "memory": 0,
      "cpu_type": "",
      "mdm": {
          "enrollment_status": "Pending", // This is in pending state -> that's expected
          "dep_profile_error": false,
          "server_url": "https://primo.mdm.getprimo.com/mdm/apple/mdm",
          "name": "Fleet",
          "encryption_key_available": false,

  Then, after a while, the last_enrolled_at date is changed again to a correct timestamp (the new “enrollment” date)

What customer expected was the last_enrolled_at to be also null or empty whenever a device is deleted from Fleet.

Customer "internal sync & flow rely on this." Are they wrong on this assumption?

Also, we feel like the last_enrolled_at (or soon mdm_turned_on https://github.com/fleetdm/fleet/issues/17710) should update at the same time you update the “mdm” values (edited)

🧑‍💻  Steps to reproduce

1. Enroll a host in a different Windows MDM.
2. Attempt to migrate MDM enrollment to Fleet.

Questions to #g-mdm from @nonpunctual:

When an MDM enrolled device is deleted from Fleet should the "last_enrolled_at" date be "null" post deletion? Do we intentionally keep the "last_enrolled_at" date assuming that it might be necessary information if the same device enrolls again?

Customer assumes the field would be null post-deletion. I think this assumption is probably not aligned with with was built.

follow up on this: the customer is asking if they are seeing dates OTHER than 2000-01-01 00:00:00 in the last_enrolled_at field after deletion from Fleet, is that a bug? The way I read what you said above 2000-01-01 00:00:00 is the default for NEW records, not for devices that have records that have been deleted & re-added. Is that correct?

Answer from #g-mdm

Heads-up: last_enrolled_at is about osquery enrollment, not MDM!

When we create a new host entry after ingesting hosts from ABM, the last_enrolled_at value is set to 2000-01-01 00:00:00, which is our "zero" enrollment time. Could that be the "old" value they see?

Fleet defines enrollment as referring only to the fleetd agent installation/enrollment to the Fleet server.

By contrast, Fleet deliberately tries to avoid referring to MDM enrollment. Instead features are “turned on” in Fleet (which corresponds to MDM protocol enrollment).

For customers and other folks focused on MDM integrations (myself included), disambiguating the terminology we use is a big challenge

https://fleetdm.com/handbook/company/why-this-way#why-does-fleet-use-mdm-on-off-instead-of-mdm-enrolled-unenrolled

after a quick look, I don't see how that's happening, which makes me think it's a bug.

a long shot: maybe they have duplicate enrollments?

even if it's not a bug, it's at least a documentation improvement, because seems confusing.

[valentinpezon-primo]

Hi, typically it could corresspond to

MacOS:

• mdm_turned_on_at: set whenever the profile is installed

Windows :

• mdm_turned_on_at: set whenever Fleet is connected and activated in the "Work or school account"

[JoStableford]

Related to a Slack conversation

[nonpunctual]

Please see https://fleetdm.com/docs/rest-api/rest-api#default-response30 json example to view the key / value that is being requested for changes. Thanks.

[JoStableford]

Related to a Slack conversation

[nonpunctual]

Whatever we call things works behind the scenes if customers are only using Fleet UI. I think once people are building integrations with the API, disambiguating the fields becomes more critical so maybe we need to revisit?

[noahtalerman]

Hey @pintomi1989, heads up, we brought this into the upcoming design sprint (4.49).