Enforce IdP authentication before BYOD iOS/iPadOS enrollment

[harrisonravazzolo]

• customer-pingali: Gong snippet:
  • https://us-65885.app.gong.io/call?id=1989192898666666867&highlights=%5B%7B%22type%22%3A%22SHARE%22%2C%22from%22%3A1043%2C%22to%22%3A1102%7D%5D
  • https://us-65885.app.gong.io/call?id=1989192898666666867&highlights=%5B%7B%22type%22%3A%22SHARE%22%2C%22from%22%3A1775%2C%22to%22%3A1986%7D%5D
• @noahtalerman: Security requested this because BYOD enrollment is that last thing that requires basic auth (aka password-based auth) and I want to say my organization is totally password-less.
  • @noahtalerman: In the interim the user can use a third-party tool (ex. Confluence) to host a custom webpage (behind their IdP that enforces MFA) where the end user is forced to authenticate before then can download an enrollment profile. The end user uses their Mac to find their IdP password and approve the login w/ a second factor.
    • @noahtalerman: Is there a way to use your Mac as a second factor w/ Okta?
  • @noahtalerman: On second though the end user might not be able to
  • @noahtalerman: Eventually Fleet can enforce end users enrolling a BYOD iPhone or iPad to authenticate with their IdP before they're allowed to enroll.
  • @allenhouchins: This would allow Fleet to support any IdP that supports SAML. Instead of the customer having to build their own MFA workflow w/ Slack.
  • @allenhouchins: Some users shouldn't be allowed to enroll their BYOD iPhone. For example, we don't want to give contractors the ability to use the organization email or Slack on their BYOD iPhone.

    • @allenhouchins: The IT admin could create this exclude group in their IdP.

[noahtalerman]

Moved the original issue description here for safekeeping:

@harrisonravazzolo asks: When a user goes to enroll a BYOD device and pulls a profile, what is the first point in which Fleet will capture who the user of that device is?

Problem

As a CPE and Security Team Member, I want to authenticate users before they can enroll in MDM so that I can associate a user and a device and better secure BYOD enrollment.

A problem with the current iteration of BYOD is that this uses the user-initiated enrollment style with an URL endpoint to pull a configuration profile. Alternatively, Apple recommends the 'User Enrollment' approach where after authentication happens the profile can then be pulled down to the device. Screenshot of the device setting:

When this flow occurs, the mechanism will be similar to the end user authentication part of MacOS enrollment and the device will have a user associated with it.

The current enrollment method leaves a lack of authentication and prevents a sys admin from being able to associate a device and restrict enrollment to known users on an approved domain.

There are other data segmentation and management features with this enrollment style but I think a separate ticket is more appropriate.

What have you tried?

Tried other methods of capturing this user data but none exist.

Potential solutions

Support Apples User Enrollment through Work or School flow of device enrollment which has an authentication component.

What is the expected workflow as a result of your proposal?

Instead of a user hitting an endpoint to grab a profile, they will leverage iOS's enrollment profile flow in the Settings.

[noahtalerman]

Hey @ambrusps, when you get the chance can you please add the Gong snippet or Slack thread for banshear? Thanks!

[noahtalerman]

Hey @ambrusps just giving you another ping! Can you please share the Gong snippet for banshear? Thanks :)

[ambrusps]

@noahtalerman thank you!! fell thru the cracks. I've reached out to the team for an update on this feature as I'm not sure we have a good gong snippet to attach at the moment. I'll update once I hear back

[noahtalerman]

Hey @ambrusps just checking, do we have an update for banshear?

[ambrusps]

@noahtalerman removed the prospect-brashear label as I haven't heard back. This is still a very important requirement for customer-pingali. Harrison added gong snippets above for reference. Thanks for checking!