Provide populated account creation screen during DEP unboxing

[lukeheath]

UPDATE: We recommend that only Fleet users who are prepared to programmatically release devices from await_device_configuration use this feature.

This is because this feature is only available if await_device_configuration is set to true in the DEP profile.

Currently, if await_device_configuration is set to true, Fleet doesn't automatically release devices. This feature is coming soon and is covered in this issue: #9147

(noahtalerman 2023-05-10)

Goal

As an IT admin, I want the local account creation pane in the macOS SetupAssistant to present the end user with their username in our identity provider (IdP) so that they create an account with a username that matches the username in our IdP.

Tasks

1

• [x] During local account creation step in set up flow, the username is set to the end user's username from the IdP
• To pre-populate the username, when we get the SAML response from the device, send an AccountConfiguration like we did in Okta integration: Demo #10210 using the email we get from the SAML response. Similarly to that issue too, we probably need to use the DB table mdm_idp_accounts to keep a reference of the host being authenticated.

2

• [x] During local account creation step in set up flow, the password field requires the password requirements set by a configuration profile (if there is one)
• For password enforcement, we need to deliver a profile before releasing the device, requires Install profiles and bootstrap package before user can use a new Mac #10577
• This requires #10577. For this task, just confirm that password is being enforced at this step.

[lukeheath]

Hey team! Please add your planning poker estimate with Zenhub @gillespi314 @roperzh

[georgekarrv]

For clarification the users full name should also be populated from the okta information as well. The username should be the Account Name (what becomes the home directory) as well as both Full name and Account name must be disabled so the user cannot edit either.

[roperzh]

@noahtalerman we need to define which SSO attributes use for the full name and the username, for this I think it would be nice to check with customers, especially considering that the username is also the name of the home directory in the machine.

I have a PR for this work https://github.com/fleetdm/fleet/pull/11557 that implements username as the email, but I don't really like that solution since it contains a @ and the email might contain other characters like ..

[roperzh]

@noahtalerman separately, could you confirm that this feature is enabled by default if the user has SSO enabled? my understanding is that at least for know we won't have a specific "knob" to tweak this behavior.

[noahtalerman]

cc @georgekarrv

[noahtalerman]

I don't really like that solution since it contains a @ and the email might contain other characters like .

@roperzh hmmm, yeah I agree. Is there a different SSO attribute what would the local username better? For example, I imagine Okta has something like a username attribute. I could be wrong..

confirm that this feature is enabled by default if the user has SSO enabled? my understanding is that at least for know we won't have a specific "knob" to tweak this behavior.

Yes, for now this will be the default behavior (not configurable).

[roperzh]

@noahtalerman thanks!

@roperzh hmmm, yeah I agree. Is there a different SSO attribute what would the local username better? For example, I imagine Okta has something like a username attribute. I could be wrong.

There are many for example here are two pages listing some common attributes/claims:

• https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims#what-are-claim-types
• https://wiki.library.ucsf.edu/display/IAM/Attribute+Definitions+for+SPs

And also you can specify any name you like, for example we ask users to set FLEET_JIT_USER_ROLE_TEAM_1 to define a team for JIT provisioning.

From the IT admin's perspective, for example, here's how I set an attribute in Okta:

If possible it might be a good idea to get user input, otherwise I suggest to pick one and move forward with that.

An obvious candidate is the username field, but we're already using that to get the email of the user.

[georgekarrv]

For now we decided to go with regex everything in the email before the '@' as the name to use for account name.

[noahtalerman]

cc @roperzh ^^

[noahtalerman]

Hey @roperzh @georgekarrv after our "AwaitDeviceConfiguration" call, I thought of another option:

Only support this feature if await_device_configuration is set in DEP profile. Support gating enrollment behind auth/SSO feature if await_device_configuration is not set in DEP profile.

This way, we don't create the problem we talked about on the call: folks who want the gate enrollment behind auth/SSO can't because they don't know how (or don't want to) to set await_device_configuration and programmatically release the host.

What do you think? How difficult would this be?

[roperzh]

@noahtalerman that will ease the migration path for when we actually implement the feature, I like it!

As far as I can tell it shouldn't be too difficult. I'll let you know if I find any blockers, but for now I'll proceed with the plan you outlined.

[noahtalerman]

As far as I can tell it shouldn't be too difficult. I'll let you know if I find any blockers, but for now I'll proceed with the plan you outlined.

Ok! @roperzh to over communicate / double check, in Fleet 4.32.0 (this release), a Fleet user will be able to gate automatic enrollment behind SSO regardless of whether they set await_device_configuration to true or not.

Only Fleet users that set await_device_configuration to true will be able to populate account creation screen.

Is that right?

[roperzh]

@noahtalerman that sounds right 👍

[noahtalerman]

UPDATE: We recommend that only Fleet users who are prepared to programmatically release devices from await_device_configuration use this feature.

This is because this feature is only available if await_device_configuration is set to true in the DEP profile.

Currently, if await_device_configuration is set to true, Fleet doesn't automatically release devices. This feature is coming soon and is covered in this issue: #10577

@roperzh I added the above to this issue description. Does this look right? If yes, I'll notify other folks on the team.

[roperzh]

@noahtalerman that looks good to me!

[roperzh]

For now we decided to go with regex everything in the email before the '@' as the name to use for account name.

@noahtalerman @georgekarrv should we also sanitize special characters? it's common on big companies for emails to be firstname.lastname@company.com, which will create a home directory named ~/firstname.lastname

[noahtalerman]

@roperzh I don't think we need to sanitize the email. The customer was ok with the dot (.) being present in the home directory.

[roperzh]

@noahtalerman nice! thank you!

[xpkoala]

I'm seeing this error when attempting to configure await_device_configured

Error: applying fleet config: POST /api/latest/fleet/mdm/apple/enrollment_profile received status 422 Validation Failed: Couldn’t edit macos_setup_assistant. The automatic enrollment profile can’t include await_device_configured.

[roperzh]

I'm seeing this error when attempting to configure await_device_configured

Error: applying fleet config: POST /api/latest/fleet/mdm/apple/enrollment_profile received status 422 Validation Failed: Couldn’t edit macos_setup_assistant. The automatic enrollment profile can’t include await_device_configured.

@xpkoala PR #11789 has been merged with a fix for this, could you please try again? thanks and apologies!

[fleet-release]

Awaiting DEP screen, Filled with IdP usernames, Ease for IT admins.

[noahtalerman]

UPDATE: Docs are in an open PR here: #14217

Re-opening this and bringing it back to confirm and celebrate column because we don't have docs.

[ireedy]

C&C: @noahtalerman to talk to Mike about docs.

[noahtalerman]

C&C: @noahtalerman to work with JD to get the doc content into an article. Mike and I decided to put a freeze on committed learning docs. We still want to be able to point the user somewhere to learn.

[noahtalerman]

C&C: @noahtalerman need to pull this into a PR so JD can make it into an article.

[noahtalerman]

C&C: @noahtalerman need to pull this into a PR so JD can make it into an article.

[noahtalerman]

C&C: @noahtalerman need to pull this into a PR so JD can make it into an article.

[noahtalerman]

C&C: Let's turn this PR into a guide.

@spokanemac can you please help me pull the PR linked above into a guide that can go on fleetdm.com/guides?

@jd

Whoops! Sorry @jd

[noahtalerman]

@spokanemac ping! When you get the chance, can you please help me pull this PR into a guide?

Happy to jump on a call if it's helpful.

[spokanemac]

@spokanemac ping! When you get the chance, can you please help me pull this PR into a guide?

@noahtalerman Back in the office. I'll get this in the queue.

[noahtalerman]

@spokanemac nice! Please ping me when it's ready for review.

[noahtalerman]

C&C: Leaving this one open until we have an article published.

cc @noahtalerman and @spokanemac

[noahtalerman]

C&C:

@spokanemac I think we can abandon the article.

To document this quickly, I'm going to pull this PR into the contributor docs: https://github.com/fleetdm/fleet/pull/14217

I learned from Rachael that we can use contributor docs if we think docs/feature is more experimental and we don't know how it's going to fit into the current docs in less words.

cc @noahtalerman

[rachaelshaw]

C&C: needs contributor doc update @noahtalerman

[noahtalerman]

@rachaelshaw decided not to document this one for now. The steps will change after we ship #9147

The plan is to document the instructions after we ship #9147

[fleet-release]

Setup in the clouds, IdP mirrored below, Fleet streamlines the flow.