Profiles: Manage profiles

[noahtalerman]

User story

As an IT admin, I want to be able to add/remove configuration profiles to my macOS hosts so that I can enforce settings for my end users.

Requirements

• In UI and CLI, add/delete a profile. Automatically applied to all hosts (Fleet Free) or hosts on no team (Fleet Premium)
• In UI and CLI, add/delete a profile for a team (Fleet Premium)
• In CLI, edit a profile. Edit a profile for a team.
• In UI, download a profile so that I can see it and/or add it back later.
• Only global admins, global maintainers, team admins, and team maintainers can see and modify profiles.
• Managing profiles doesn't require deploying additional infrastructure (ex. file storage solution). Fleet can store the contents of the file instead.
• Transfer host between teams automatically kicks off updating profiles for this host.
• In docs, recommend iMazing to create profiles.
• Update the permissions documentation
• Document how to migrate profiles from old MDM solution. A v1 of these docs can be found in this comment: https://github.com/fleetdm/fleet/issues/8360#issuecomment-1424290304

Design

UI

https://www.figma.com/file/hdALBDsrti77QuDNSzLdkx/%F0%9F%9A%A7-Fleet-EE-(dev-ready%2C-scratchpad)?node-id=10517%3A316027

CLI

Update config YAML file

Example config YAML file:

apiVersion: v1
kind: config
spec:
  macos_settings:
    custom_settings:
      - /path/to/configuration_profile_B.mobileconfig
      - /path/to/configuration_profile_C.mobileconfig
    ...

• Add a custom_settings key under the macos_settings top level key in the config YAML file.
• custom_settings accepts an array of paths to profiles (.mobileconfig file). Path is relative to directory that the YAML file is in.
• For Fleet Free, this updates profiles on all hosts. For Fleet Premium users this updates profiles on all hosts with no team.
• If the user applies a profile with the same identifier (PayloadIdentifier) as a profile that already exists, the profile is edited.
  • Identifier is unique at the team (or no team) level. If a profile with the same identifier is applied at the team level, this profile is edited. If a profile with the identifier doesn't exist at the team level, a new profile is created.

Empty

• If the user applies a config file with an empty custom_settings the profiles are deleted from all hosts (for Premium: hosts on no team). Matches the behavior of agent_options.

Errors

• Error if the file does not exist. Error message matches the current behavior of fleetctl apply: Error: open does/not/exist: no such file or directory
• Error if Fleet is not connected to Apple (MDM is not turned on in Fleet)
• Error if the user tries to add more than 1 profile with the same name (PayloadDisplayName). Display this error message: Couldn’t edit custom_settings. More than one configuration profile have the same name (PayloadDisplayName).
  • Name is unique at the team (or no team) level.
• Error if the user tries to add more than 1 profile with the same identifier (PayloadIdentifier). Display this error message: Couldn’t edit custom_settings. More than one configuration profile have the same name (PayloadIdentifier).
• Error if the user tries to add a profile with FileVault related payloads. Display this error message: Couldn’t edit custom_settings. The configuration profiles can’t include FileVault settings. To control these settings, use the macos_settings.disk_encryption option.

User added profiles in UI

• If user added profiles in the UI, the custom_settings array doesn't include these configuration profiles when the user gets the config YAML.
• When applying the config file, the configuration files specified in custom_settings overrides the configuration files added in the UI. For example, if the user added configuration profile A in the UI and they apply configuration profile B and C using config YAML. Fleet deletes A and adds B and C.

Update config YAML file

Example team YAML file:

apiVersion: v1
kind: team
spec:
  team:
    name: Worksations
    macos_settings:
      custom_settings:
        - /path/to/configuration_profile_B.mobileconfig
        - /path/to/configuration_profile_C.mobileconfig
    ...

• Add a custom_settings key under the macos_settings top level key in the team YAML file.
• custom_settings accepts an array of paths to profiles (.mobileconfig file). Path is relative to directory that the YAML file is in.
• This updates profiles for all hosts assigned to the team.
• Use the same "Empty" behavior from the config file above (above).
• Use the same "Errors" behavior from the config YAML file (above).
• Use the same "User added profiles in the UI" behavior from the config YAML file (above).

API

TODO

Docs

Add a new macOS updates section to the Controls doc page

URL for section: fleetdm.com/docs/using-fleet/controls#macos-settings

Copy:

How to create a custom configuration profile:

1. Download and install [iMazing Profile Creator](iMazing Profile Creator). Fleet recommends using iMazing Profile Creator to create configuration profiles.
2. Open iMazing Profile Creator and select macOS in the top bar. This filters the list of settings to macOS only.
3. In your menu bar select File > Save As... and save your configuration profile. Make sure you save it as .mobileconfig.
4. Upload the configuration profile in Fleet.

Update the permissions documentation

[noahtalerman]

• User can tell Fleet which macOS settings to update

Where do you go to create profiles for settings?

• User can see which settings they told Fleet to update

Where do you go to check which settings you have configured?

• User can see which hosts have not updated settings

Do you ever check for hosts that have not updated settings?

Why don't we check all MDM settings in dogfood?

[noahtalerman]

• Fleet admins and maintainers know which settings are available

Document how to use profile generator application (ex. Apple Configurator)

• Fleet admins and maintainers can update settings
• Fleet admins, maintainers, and observers can see which settings are applied

Allow add, delete, view functionality in the UI and fleetctl

• Allow one or many profiles per team?

  • Allow one:
  • Profile generator app is the interface for modifying the profile.
  • UI and fleectl allows the user to upload/replace profile.
  • Profile file is likely to be over 1,000 lines.
    • Dogfood file would be ~1,250 lines (25 profiles x ~50 lines per profile).
  • This doesn't prevent us from Fleet UI becoming the interface for modifying the profile later

• Expose profile or settings in the UI?

  • Expose settings:
  • Eventually, we want the user to be able to update the settings in the Fleet UI

• Expose profile or settings in fleetctl?

  • Expose profile:
  • I think we want user to use fleetctl get as a tool to diff against a new profile.

• Fleet admins, maintainers, and observers can see which hosts have not updated settings

Document how to use policies in Fleet

[noahtalerman]

Zach: If we're headed towards 1 team to many profiles, this will impact the implementation of the data model.

[noahtalerman]

UPDATE: The plan is still 1 profile globally and 1 profile for each team (these override global profile). (noahtalerman 2022-11-10)

From product design review on 2022-11-07

Mike McNeil: Start with just 1 profile that applies to all hosts in Fleet. Come back to teams later (we think they will override the global). Move on to OS, scripts, and software. This way, we can implement experience around adding/editing 1 profile and have time to iterate on how teams will work.

[noahtalerman]

How should the Fleet UI enable adding/modifying macOS settings?

Proposal: The Fleet UI will allow the user to upload 1 profile (.mobileconfig file). Uploading the profile will replace the current profile.

Options:

• User uploads 1 profile
• User edits 1 profile (XML format) in a code editor

Reasoning:

• Usability: Uploading a profile is easier while editing a profile in a code editor is faster. Tradeoff between ease of use (mental energy + error prone) and speed (number of steps). We assume IT admins value accuracy when updating their organization's Macs. This means ease of use is more important than speed.
• Development time: TBD. I think both options will require a similar amount of effort.
• Flexibility: Both options are equally flexible. For both, the Fleet DB likely stores the XML. Next time a macOS checks in, it picks up the new profile. We can walk back out of both doors.
• Familiarity: Uploading a profile is more familiar to users of other MDM solutions. Jamf, Kandji, and SimpleMDM all support upload. Only SimpleMDM supports editing the profile in a code editor

@zhumo @mikermcneil what do you think?

[zhumo]

@noahtalerman so we're doing just one profile globally?

I agree with having a file upload rather than text editor. We should rely on the 3rd party apps to generate valid XML.

[noahtalerman]

Proposal: Fleet UI and docs will point users towards the iMazing Profile Creator app to create/modify profiles.

Options:

• iMazing Profile Creator: https://imazing.com/profile-editor
• ProfileCreator: https://github.com/ProfileCreator/ProfileCreator
• Apple configurator: https://support.apple.com/apple-configurator

Reasoning:

• All settings (listed below) can be configured with iMazing. ProfileCreator can't configure "Prevent password sharing" setting. Apple Configurator can't configure settings for any third part apps (ex. Google Chrome):
  • PW Length and complexity
  • Screenlock
  • Enable FileVault
  • Disable camera
  • Disable iCloud
  • Disable Biometric
  • Disable Apple Watch Unlock
  • Prevent password sharing
• iMazing seems to be actively maintained/updated. ProfileCreator does not. These screenshots are from my Mac when I select Get Info for these apps in Finder:

Notes

• The Fleet default profile (link provided in this issue's description) includes all settings listed above.
• The "Auto-rotate FileVault keys every x days" cannot be controlled by any third party profile creator app. It looks like this is controlled via an MDM command and not a profile. I think we can add a feature to Fleet Desktop that rotates the key automatically by running this command:
  • Docs for this command can be found here in Apple's Mobile Device Management Protocol Reference (search doc for "using the rotatefilevaultkey command"): https://developer.apple.com/business/documentation/MDM-Protocol-Reference.pdf

[noahtalerman]

so we're doing just one profile globally?

@zhumo no. The plan is still 1 profile globally and 1 profile for each team (these override global profile).

Reviewing the UI changes that would enable this^ is on the agenda for today's product design review (2022-11-10).

I didn't do a good job communicating this plan to Mike during our last design review.

[noahtalerman]

Mo: If we expect the user to follow a specific workflow, we should be explicit about this. Drag and drop is more clear.

[noahtalerman]

Mike McNeil: I want to see how teams apply to script execution and OS upgrades before we start developing team profiles (product design review 2022-11-11)

[noahtalerman]

Mike and Mo, can you please provide feedback on the following proposed UI changes? After these changes are reviewed, this issue will be ready for estimation.

• A separate page for Ticket destinations. I'd like to separate the UI for the Jira and Zendesk integrations from the MDM integration so that the user.
• Name "Ticket destinations." I'd like to bucket the Jira and Zendesk integrations under "Ticket destinations." This allows the UI to later add separate pages for other buckets like "Log destinations" (Snowflake, Panther, etc.) and later "Data sources" (AWS, Google Cloud, etc.)

Below is a screenshot and here's a link to Figma: https://www.figma.com/file/hdALBDsrti77QuDNSzLdkx/%F0%9F%9A%A7-Fleet-EE-(dev-ready%2C-scratchpad)?node-id=10964%3A324560&t=cG50Zd2QwvOFtlKQ-1

[zhumo]

@noahtalerman @mikermcneil I think the IA looks good here. However, in its current position, I think that it's strange that you would go to Settings > Integrations > MDM in order to upload a profile for global or team. It seems buried. It seems like it should be more of a first class citizen.

Also, is there a CLI command to do this?

[noahtalerman]

Mo and Noah: Workflow for CLI shouldn't require pasting XML. Scroll back up to check indentation is one example of headache.

Noah: We might want to make friendly YAML later.

Mo: We were going to support custom XML later. Let's just support this now. Key to a bunch of XML documents.

[noahtalerman]

its current position, I think that it's strange that you would go to Settings > Integrations > MDM in order to upload a profile for global or team. It seems buried. It seems like it should be more of a first class citizen.

Good point. I think the UI could live on the Policies page. Two reasons…

• MDM features are a first class citizen
• I think policies will be used to achieve “see which hosts have not yet received the settings”

That said, I think we can move forward with UI living on Settings > Integrations > MDM. When we address OS updates, scripts, and commands (next) we can consider moving the UI for profiles.

This lets us move forward with implementing automatically push profiles. This doesn’t close doors for changing the UI later.

[noahtalerman]

Decision on CLI for replacing the configuration profile

Decision

• Option 4

Reasoning

• Interface is flexible. We can add teams in later iteration
• Workflow doesn't require pasting XML
• Workflow enables tracking/seeing what changed (audibility)

Unsolved problems

• How do you get the configuration profile with fleetctl?
• What happens in the output of fleetctl get config?
  • When you only used the UI to add a configuration profile? Potential solution: Always a new /tmp file that we generate
  • fleetctl get config should result in no changes to the working file

Option 1

$ fleetctl apply -f configuration-profile.yaml

configuration-profile.yaml file:

apiVersion: v1
kind: configuration profile
spec:
  profile: |
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
      <key>ProfileDescription</key>
      <string>Enforces automatic updates for OS, App Store apps, etc.</string>
      <key>ProfileDisplayName</key>
      <string>macOS Software Update Policy: Auto_Updates</string>
      <key>ProfileItems</key>
      <array>
        ...
      </array>
    </dict>
    </plist>

Pros

• User only has to check one YAML file into GitHub.
• User can easily see what changed when viewing commit history.

Cons

• Workflow for CLI shouldn't require pasting XML. Scroll back up to check indentation is one example of headache.

Option 2

$ fleetctl apply -f configuration-profile.yaml

configuration-profile.yaml file:

apiVersion: v1
kind: configuration profile
spec:
  profile: /path/to/configuration_profile.mobileconfig

Pros

• Simple YAML interface.

Cons

• Is this possible?
• User has to check the XML file and the YAML file into GitHub.
• User has to manage a new configuration profile YAML file

Option 3

$ fleetctl apply -f configuration_file.mobileconfig

No YAML file.

Pros

• User only has to check the XML file into GitHub
• Simple experience

Cons

• Overloading the fleetctl apply command adds complexity. This command only accepts YAML files today.

Option 4

$ fleetctl apply -f fleet-config.yaml

fleet-config.yaml file:

apiVersion: v1
kind: config
spec:
  mdm:
    macos_settings: /path/to/configuration_profile.mobileconfig

Path is relative to directory that YAML file.

Pros

• Simple YAML interface
• Uses the existing config YAML file

Cons

• User has to check the XML file and the YAML file into GitHub

This was discussed during the "Change macOS settings (profiles)" call on 2022-11-22.

[noahtalerman]

@zhumo @mna @roperzh @zwass during our "Change macOS settings" call we decided that option 4 in the above comment is the preferred solution for updating macOS settings via CLI (enable CI/CD workflow).

Then, we identified these unsolved problems:

• How do you get the configuration profile with fleetctl?
• What happens in the output of fleetctl get config?
  • When you only used the UI to add a configuration profile?
  • fleetctl get config should result in no changes to the working file

The proposed solution in this issue's description.

What do you think?

[mna]

@noahtalerman Nice! I like how clean the proposed solution is for fleetctl get mdm-macos-settings. Do I understand correctly that this would be the way to get the actual contents of the macos settings file? This way, the user is responsible for choosing to which file they send that content, if needed. And fleetctl get config would only return the file path that was used to save them (and nothing if it was set via the UI? Maybe with a comment added that it was set in the UI, if it was indeed set?).

I think this would also be consistent with fleetctl get <thing> returning an output that is valid for fleetctl apply -f (assuming, of course, that the file path used when they set the macos settings the last time is still present and at the same location, but it makes sense to me that this would be their responsibility).

One thing I didn't understand at first in the issue's description is:

If a user updates macOS settings in the UI, don't return a value for mdm.macos_settings

But re-reading this, I think it's meant to describe the behaviour of fleetctl get config, right? If so it's not obvious because it is in the fleetctl apply -f section.

Proposal looks great to me, seems to address all concerns that were raised!

[zhumo]

@noahtalerman LGTM.

How about the question from users: "how do I know that the profiles have been applied?"

[noahtalerman]

Do I understand correctly that this would be the way to get the actual contents of the macos settings file?

@mna yes, that's right.

fleetctl get config would only return the file path that was used to save them (and nothing if it was set via the UI?

Right. I think it makes sense to return nothing so that fleetctl get config follows the requirement this requirement: fleetctl get config should result in no changes to the working file.

it's meant to describe the behaviour of fleetctl get config, right?

That's right. I moved the following sentence to the fleetctl get config section of the issue description: If a user updates macOS settings in the UI, don't return a value for mdm.macos_settings

[noahtalerman]

How about the question from users: "how do I know that the profiles have been applied?"

@zhumo I propose that we instruct users to create a policy to check which hosts have not yet received macOS settings. Let's discuss during our 1:1 today.

I imagine the workflow will look like this: Upload configuration profile -> add a policies that checks if the host received a profile that turns on a specific macOS setting (ex. Screen lock).

I think we can add policy templates for all of the important settings (listed below) to the Policies page so that the user can quickly click and add these policies. Here's a wireframe that illustrates this idea: https://www.figma.com/file/hdALBDsrti77QuDNSzLdkx/%F0%9F%9A%A7-Fleet-EE-(dev-ready%2C-scratchpad)?node-id=11123%3A321097&t=rfwGebc26aguPiOX-1

Important settings:

• PW Length and complexity
• Screenlock
• Enable FileVault
• Auto-rotate FileVault keys every x days
• Disable camera
• Disable iCloud
• Disable Biometric
• Disable Apple Watch Unlock
• Prevent password sharing
• Block guest account

[noahtalerman]

Mo and Noah: Something like “Manage” as its own page (top level). Profile and non-MDM settings live here.

[RachelElysia]

@zhumo @noahtalerman Notes from 12/15 profiles call (video recording by Noah):

Empty state/UI comments: Mo: Controls settings empty state shouldn't have macOS version, macOS settings tabs as neither are setup Mo/Noah: Potentially hide Controls nav for observers since no need for observers to show empty state

When MDM apple apn connected: Mo: Wordsmithing needed for activity feed update "for all hosts" for fleet free, how might we say which hosts are being updated for Fleet premium? Mo: The word "Add" maybe the word "Upload" instead to be more explicit that it's going to open a file picker Robert: Download profile button in modal failing, maybe syntax error or something, acknowledge error state

Error on adding a non-valid profile: Zach: Where can we validate, can check legit XML, valid keys, but there might be some edgecase apple checks, apple will never see it until it's on someone's mac, the only thing apple sees is we sent a push notification sent to MDM Mo: Relying on iMazing profile to validate, but should understand what the user experience would be if they do get error states. Do they get error messages? Do we get error messages? What kind of UX are they having so we can help them? Noah: Would the old settings stay enforced until you give it a new valid profile? Zach: Need a timestamp or serial number or something to tell that there was a change

User need: Mo: "Did it work?" and the different levels of "Did it work?" a) did the file get sent down b) are the keys correct, what levels of failure will Apple tell us Roberto: MDM protocol will give us some of this data Two levels: 1. Did the profile get applied? 2. Did the settings change after the profile is applied? (There are settings that require user action) Roberto: All of the profiles will fail if some of them fail, the huge block. Mo: 1. The file got sent down 2. The file that you sent is being implemented Roberto: I've tried this use case, this is correct, but not documented. You will get all failing, or almost all applied. On the backend we will keep trying to applying, for example, if the network is unavailable Zach: Older macOS might fail as well Mo: Custom timestamp that it was submitted? Roberto: Can get on a per host basis if it failed.

TODO: Success, fail, pending state from Roberto

[noahtalerman]

@RachelElysia thank you! Awesome notes.

[noahtalerman]

Hey @mike-j-thomas when you get the chance, can you please help me find an icon for the new Controls page?

I assigned you this issue and added it to the #g-marketing board so that you can track it.

The Controls page is where the IT admin remotely updates macOS and enforces macOS settings. Here's a link to the Figma page: https://www.figma.com/file/hdALBDsrti77QuDNSzLdkx/%F0%9F%9A%A7-Fleet-EE-(dev-ready%2C-scratchpad)?node-id=10517%3A316027

[noahtalerman]

@mike-j-thomas I checked out the style guide and it looks like we'd like to update the masthead to use these styles:

Maybe instead of adding an icon for the new Controls tab, we implement the new styles for the masthead? What do you think?

[noahtalerman]

Hey @mike-j-thomas in addition to my masthead question above, can you please help me with the layout of this page?

Here's a link to the Figma page: https://www.figma.com/file/hdALBDsrti77QuDNSzLdkx/%F0%9F%9A%A7-Fleet-EE-(dev-ready%2C-scratchpad)?node-id=11565%3A321978&t=QG4cXcxGd9IJZmW6-1

Context on the problems this page is solving:

• First, the user has to be able to change macOS settings they enforce. To do this in the UI, the user has to download their current configuration profile and upload a new one.
• Second, the user has to be able to know if the macOS settings worked. To do this in the UI, the user has to see which hosts have applied the macOS settings, which have yet to try (pending), and which failed.

[noahtalerman]

@lukeheath FYI I added a note about MIME type validation (for file type validation) to a Figma dev note here in Figma: https://www.figma.com/file/hdALBDsrti77QuDNSzLdkx/%F0%9F%9A%A7-Fleet-EE-(dev-ready%2C-scratchpad)?node-id=11565%3A321934&t=MEFtxIHpUDw6j8wo-1

[noahtalerman]

Notes from product design review on 2022-12-19

Noah: We are confident that we want to solve the “is the profile installed?” problem now (problem A). Solve the “are the profile settings enforced” problem later (problem B).

• Noah: I’m working on validating this with users.

Technical question, is solving problem A via MDM or osquery more accurate?

• Roberto: MDM command is an accurate reflection of whether the profile is installed successfully.

[mike-j-thomas]

@noahtalerman, ready for you to look at. Thanks. https://www.figma.com/file/hdALBDsrti77QuDNSzLdkx/%F0%9F%9A%A7-Fleet-EE-(dev-ready%2C-scratchpad)?node-id=10517%3A316027

[noahtalerman]

From Mike Thomas: It's confusing to show the platform filter on the Hosts page when the macOS settings filter is applied. This is demonstrated in a Loom video here: https://www.loom.com/share/6b1c6d9f8e374e1d991026f0939dc125

[noahtalerman]

@mike-j-thomas, thanks! The changes look great. I will bring them to today's design review (morning EST).

Also, I checked out the style guide and it looks like we'd like to update the masthead to use these styles:

I think instead of adding an icon for the new Controls tab, we implement the new styles for the masthead. What do you think?

[noahtalerman]

@mike-j-thomas I brought the UI to today's design review.

Mo provided some great feedback: it makes more sense for the "updated at" time stamps to be pulled up and out of the "Custom settings" and "Disk encryption sections." This is because we want the user to know the last time they updated my macOS settings as a whole.

Can you please help me with this UI?

We think it's less important to tell the user when they updated an individual setting (disk encryption or custom)

I describe this in more detail in a Loom video here: https://www.loom.com/share/7ce34dcb474947a39fe00489b2ff55f0

[mike-j-thomas]

I think instead of adding an icon for the new Controls tab, we implement the new styles for the masthead. What do you think?

Perfect. Thanks, @noahtalerman.

[mike-j-thomas]

Can you please help me with this UI?

@noahtalerman, I'll check it out today. Loom videos are really helpful, btw. Thanks.

[mike-j-thomas]

@noahtalerman. I moved the time timestamp placement, and I've made some more changes to the UI after looking at it with fresh eyes.

The previous layout made uploading a custom profile seem more complicated than needed. I felt I needed to read all the instructions to understand what was happening when I only needed to upload my configuration profile.

So for the benefit of a cleaner, more consistent UI, I've assumed that it's not the user's first rodeo with MDM and custom configuration profiles and suggested that only having the instructions in the modal is sufficient for newcomers.

I've also suggested some verbiage changes to cut back on word count and remove the inline links from the modal (except for iMazing Profile Creator). Again, the extra links added another layer of thought. "Which download button should I press? Are they different?"

I hope you can bring it up in the product design review, and I'm keen to hear your thoughts.

~Edit: Please roll back in Figma history if I'm off the ball with this.~ Scratch that. I dropped the previous version below, in case you need it 👍🏻

[mike-j-thomas]

@noahtalerman, one more thing. 

The last updated timestamp previously acted as feedback for successfully uploading the profile. We should consider including a toast message (or something similar) now that we’ve moved it.

[mike-j-thomas]

@noahtalerman. I've changed my mind. I don't like my previous assumption. You're right to include the instructions on the page. I added a second version for you to consider. The messaging in this version also solved the success feedback problem I mentioned above.

[noahtalerman]

You're right to include the instructions on the page. I added a second version for you to consider.

@mike-j-thomas I agree. It's likely not the users first rodeo with custom configuration profiles. However, it's likely this is the specific workflow we'd like them to use: upload a single profile for many settings.

I prefer your second version.



The last updated timestamp previously acted as feedback for successfully uploading the profile. We should consider including a toast message (or something similar) now that we’ve moved it.

I still think we should add a toast message for feedback. Without it, there's no feedback when you upload a new configuration profile.

[noahtalerman]

Hey @roberto there are a couple outstanding technical questions that impact the UX for macOS settings (profiles) in Fleet:

• If we roll up the failed status, are we able to tell the user what the specific error is? Will there ever be more than 1 error? If so, are we able to show all these errors to the user?
• Can we even do 1 profile? Are there side effects we don’t know about? Ex. Momentarily cutting off the end users wifi
  • I messaged Brock to try to get him on a call to try to dig into these side effects

[noahtalerman]

Summary of decisions and actions items from today's product design review (2022-01-03)

• DECISION: When add/edit/delete profiles, only send the profiles that changed. Why? See argument for option 3 in this presentation
• DECISION: Periodically, Fleet checks if host’s profiles don’t match what's expected and sends commands to bring it up to date Why? See this presentation
• TODO Noah: In UI, inform user what a "Pending" profile means. Inform user whether an install or unsintall is pending.
• TODO Noah: Why did we choose to have a separate cell for "Errors?" Instead, these hosts could also live under "Out of date."
• TODO Noah: Are there advantages to having osquery check the hosts state instead of using MDM protocol? Maybe live querying the state is powerful/valuable
  • Mike: User can live query the expected state of the device. Powerful for selling Fleet against MDM v2.
  • Roberto: Large/unknown level of effort. Likely build an extension. Hosts with pending profiles will likely not be reachable via live query because they're offline.

cc @roperzh @mikermcneil @zhumo @zwass

[noahtalerman]

Summary of decisions and actions items from today's product design review (2022-01-05)

Cut top level "Updated" timestamp. Why? Not an essential part of the UI (add later). The user can see when the added the latest profile in the activity feed.

Cut rename. Why? Adds complexity and is not an essential feature (add later). Instead use name embedded in .mobileconfig file.

Cut replace/edit profile functionality. Why? Complex. We decided address the edit a profile problem later. We'll solve it directly later.

Cut validation of the .mobileconfig. Solving this directly later.

Add enforce uniqueness for profile name and identifier across teams. Why? We don't support edit functionality now. We'll solve this directly later.

Add “Pending (add)” and “Pending (delete)” states to Host details page. Why? We want to tell the user if the setting is being added or removed.

Add activity feed items for add/delete profile in the UI and edit profiles (plural) via CLI.

Remove instructions for using iMazing a link out to docs instead. Why? Can add this in UI later. Can iterate faster on instructions in docs.

TODO Noah: In "that's not a mobileconfig file" error- also lint the XML (could even be in the browser whatever) and if not valid xml, then show error and prevent "upload"

TODO Noah: If uploading a mobileconfig file that includes filevault related payloads, show custom error message and prevent "upload"

TODO Noah: If we include latest/pending/error panel when there are no profiles? what does it say the host count is? Consider...

TODO Noah: What happens if someone with disk encryption turned on enrolls, but the checkbox for encryption is disabled?

TODO Noah: Proposal, add a macos_settings top-level key and 2 configuration_profiles and ui_custom_settings keys. Why? We want to cover the case in which fleetctl user has modified profiles in the UI and vice versa. Mike: Could it come later?

[noahtalerman]

cc @zhumo @roperzh ^

[noahtalerman]

Summary of decisions from today's product design review (2022-01-03)

1. In the UI, update status renaming (same rename as in the FileVault story):

   • "Enforcing setting" to "Enforcing (pending)" and "Removing setting" to "Removing enforcement (pending)". Why? The "pending" language makes it clearer.

2. In the CLI, support editing a configuration profile:

   • If the user applies a profile with the same identifier (PayloadIdentifier) as a profile that already exists, the profile is edited. Why? We're confident this is the expected behavior for an IT admin. We think implementing this behavior is a medium amount of work (not large).

@roperzh is this right?

3. In CLI, add 2 new errors (added to this issue's description":
   • Error if the user tries to add more than 1 profile with the same name (PayloadDisplayName) is added. Display this error message: Couldn’t edit custom_settings. More than one configuration profile has the name (PayloadDisplayName) already exists.
   • Error if the user tries to add a profile with the same name (PayloadDisplayName) as a profile that already exists. This might happen if they already added a profile with the same name to a different team. Display this error message: Couldn’t edit custom_settings. A configuration profile with the same name (PayloadDisplayName) already exists. Name is unique across teams.

cc @zhumo

[noahtalerman]

@lukeheath this story is ready for specs. I assigned you and added it to the designed column in Zenhub.

We want to prioritize this after the OS updates and FileVault stories.

[lukeheath]

@lukeheath Break into two user stories: one for writing macos settings and activity feed, and another for retrieving status details on manage hosts and host details.

[noahtalerman]

@roperzh @lukeheath I updated this story's specs. We want to enforce profile name and identifier uniqueness at the team (or no team) level. This is a change from enforcing uniqueness across teams.

I made these updates to CLI specs in the issue description:

• Identifier is unique at the team (or no team) level. If a profile with the same identifier is applied at the team level, this profile is edited. If a profile with the identifier doesn't exist at the team level, a new profile is created.
• Name is unique at the team (or no team) level. If a profile with the same name is applied at the team level and its identifier doesn't exist, the error is shown. If a profile with the same identifier exists, the profile is edited. If a profile with the name doesn't exist at the team level, a new profile is created.

I updated this dev note in Figma:

• 

Please feel free to change/tweak the above specs.

Why did we change this?

Problem with name uniqueness across teams: Let’s say I added a profile to Team A using the CLI. When I go to add the same profile to Team B (reference the same file path), I see an error: A configuration profile with the same name (PayloadDisplayName) already exists.

[noahtalerman]

The below is from design review (2022-01-25). I added it here for reference:

McNeil: Did we do something already to deal with presenting users with an error when they attempt to use conflicting payloads, whether in the same or different profiles? (context: was watching this: https://www.youtube.com/watch?v=NpyeLY3oWpo)

Noah: I don't think we present an error if they use conflicting payloads yet. We present an error if the user tries to add duplicate profiles (same name or identifier) Roberto, am I right?

McNeil: Worth evaluating how easy it would be. It's messy in Jamf Pro and something people are used to fighting with. Our blueprint-like approach is easier and avoids problems, but if we don't protect people from themselves with their multiple profile uploads, people are likely to get into trouble, especially since scoping is so all-over-the-place in Jamf and they're likely to be importing profiles from Jamf

Noah: We have to take time to decide which can be duplicate (ex. Wifi, certificates, and VPN). Then we have to implement the diff’ing. This is a good next step for the feature that we may address later.

[lukeheath]

@ghernandez345 @roperzh I have broken this user story up into the required sub-tasks. Will you please review the sub-tasks associated with the story before estimation tomorrow, and let me know if you spot any gaps? Thanks!

[noahtalerman]

Migrating Profiles docs

How to migrate configuration profiles from your old MDM solution:

1. Download the configuration profiles from your existing MDM solution.

2. Visit the Controls > macOS settings tab.

3. Upload the downloaded configuration profiles to Fleet. You can also customize which teams the profiles apply to by using the team picker.

Note that occasionally there will be some profile keys which are rejected. This is because Fleet handles those keys separately, so they should be removed from the raw profile.

[fleet-release]

Quickly manage profiles
From the clouds to the earth below
Effortless security