Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Host transferred to a team via the POST /api/v1/fleet/hosts/transfer endpoint remained in No Team #26879

Open
ddribeiro opened this issue Mar 5, 2025 · 0 comments
Labels
bug Something isn't working as documented customer-deebradel #g-orchestration Orchestration product group :incoming New issue in triage process. :reproduce Involves documenting reproduction steps in the issue

Comments

@ddribeiro
Copy link
Member

ddribeiro commented Mar 5, 2025

Fleet version: 4.63.1
Slack thread where this was reported: https://fleetdm.slack.com/archives/C075TURNLB0/p1741027763838929
Engineering Slack thread: https://fleetdm.slack.com/archives/C019WG4GH0A/p1741099768784259


💥  Actual behavior

customer-deebradel has an automation that detects when a macOS host becomes MDM enrolled and transfers it to a desired team in Fleet.

They are reporting an issue with this flow, where they used the API to transfer a host to a team, but the host did not transfer to the team. The API responded with a 200, the Flet server logs show the API call with seemingly no associated errors, and the global actives feed shows the host was transferred to the team. Yet, the host remained in No Team.

I have no reproduced this on my own yet and deebradel has seen it happen once so far.

🧑‍💻  Steps to reproduce

  1. Ensure your test host does not currently have a record created for it in your Fleet server.
  2. Enroll a macOS host into Fleet by installing the manual enrollment profile. This should send a mdm_enrolled event to the global activity webhook and enroll the host into your Fleet server.
  3. The mdm_enrolled webhook event should kick off your automation to transfer the host to another team.
  4. Check the Fleet API response, server logs, and activity feed to see that the transfer team action has taken place and was successful.
  5. Check whether the host still exists in No Teams or was actually transferred to the desired team.

🕯️ More info (optional)

  • I suspect whatever is causing this issue might be related to the timing of immediately transferring to a new team upon mdm_enrollment. Therefore it is important to build an automation that handles the transfer action via the API rather than doing it manually. Here's what deebradel is doing:
    • Build an automation that watches the Fleet global activity webhook.
    • Upon receipt of an mdm_enrolled audit event, capture the host_serial from the webhook payload.
    • Use the host_serial to make a call to the Get host by identifier endpoint (GET /api/v1/fleet/hosts/identifier/:identifier), using the serial number as the identifier. Capture the id from that response.
    • Use the id from the previous step to transfer the host to a new team by making a call to the Transfer hosts to a team endpoint (POST /api/v1/fleet/hosts/transfer).
    • Check if the host transferred to the correct team successfully.

Some other thoughts:
I am wondering if there is a potential race condition happening related to the timing of delivering MDM profiles, installing the fleet-base.pkg via InstallEnterpriseApplication command, and transferring the host via the API.

  1. The computer enrolled to Fleet in No Team via the end user installing the MDM profile. Fleet sends a Fleetd configuration profile to the host that contains the enrollment secret for No Team.
  2. The host is transferred to the desired team via the API after receiving the mdm_enrolled webhook.
  3. The Fleet agent gets delivered as a bootstrap package before the next MDM cron runs to update profiles. The old Fleetd configuration profile is still on the host.
  4. The host becomes fleet_enrolled when the agent installs and goes back to No Teams based on the information in the Fleetd configuration profile (which had not yet been updated on the host with the new team's information when the agent installed).
@ddribeiro ddribeiro added :incoming New issue in triage process. :reproduce Involves documenting reproduction steps in the issue bug Something isn't working as documented customer-deebradel labels Mar 5, 2025
@jmwatts jmwatts added the #g-orchestration Orchestration product group label Mar 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working as documented customer-deebradel #g-orchestration Orchestration product group :incoming New issue in triage process. :reproduce Involves documenting reproduction steps in the issue
Projects
None yet
Development

No branches or pull requests

2 participants