🎸 Automate Zoom updates

[noahtalerman]

Zoom offers an enterprise solution for Zoom updates (Zoom docs here).

Zoom updates can take awhile...

Instead of making your employees late to their first Zoom calls of the day, Zoom can be autoupdated during Fleet's maintenance windows.

Imagine...

You're at your desk. It's 9a. Sipping your morning drink of choice.

You hop on your first Zoom call. Sigh, Zoom needs an update (again). It's taking over 5 minutes...arg, I'm late 😠

Imagine your laptop updating Zoom for you. When you're taking a break or wrapping up your day. No more being late to your first call.

"IT tools that make employees productive, not frustrated."

"When you stop working, let your laptop keep working."

Goal

User story
As an IT admin,
I want to automate Zoom updates
so that Zoom is patched while my co-workers (end users) take a break (not right when they hop on their first meeting of the day).

Context

• Requestor(s): @mikermcneil
• Product designer: @noahtalerman

Action items

• [x] Can we do update Zoom w/o prompting the user for a pwd? Maybe piggyback on Apple's prompt for the pwd. What about MDM migration? We also need a pwd for that. UPDATE: We think no (noahtalerman 2024-06-11)
  • Luke: Potential solution: Maybe we can ask the AI to open Keychain and read the pwd.
• [x] If we can't get the pwd w/o prompting the user, validate that we can put the password into the Keychain. UPDATE: We can. See Victor's video here (starting at 4:14) (noahtlerman 2024-06-11)
• [x] If we can't get the pwd w/o prompting the user, how do we know when the pwd changes? Is there some event we can listen to and then prompt again? UPDATE: No event but we can run a script on an interval. See comment here (noahtalerman 2024-06-11)

[noahtalerman]

Zoom offers an enterprise solution for Zoom updates (Zoom docs here).

Instead of making your employees late to their first Zoom calls of the day, Zoom can be autoupdated during maintenance window using this flow instead: https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0060716

Imagine...

You're at your desk. It's 9a. Sipping your morning drink of choice.

You hop on your first Zoom call. Sigh, Zoom needs an update (again). It's taking over 5 minutes...arg, I'm late 😠

Imagine your laptop updating Zoom for you. When you're taking a break or wrapping up your day. No more being late to your first call.

"IT tools that make employees productive, not frustrated."

"When you stop working, let your laptop keep working."

[noahtalerman]

Loom demo here (internal): https://www.loom.com/share/0ffa6884c70e4c44be377acd7babd9d8

[spokanemac]

Instead of just updating Zoom, this should be an action to update all third-party software using a patch manager (our own or munki/installomator/chocolatey). The workflow would be essentially silent and in the background to the user. Additionally, we'd adjust settings on the host not to have software like Zoom check for updates, because we're patching within maintenance windows.

To extend this idea, we'd have a policy to determine if third-party software CVEs exist for a host. That failing policy triggers a maintenance window to patch all third-party software. Then, rerun the policy to see if we caught everything. If we didn't catch everything, escalate.

[nonpunctual]

Also, once Zoom is installed these features can be enabled in Zoom. WHy would we need to inject Fleet into Zoom's auto-update process?

[noahtalerman]

That failing policy triggers a maintenance window to patch all third-party software.

@spokanemac Totally how we should dogfood updating/patching today.

This story is about exploring the future in which LLMs do the update. You can imagine that these models could also make sure the update worked and if it didn't try something else.

once Zoom is installed these features can be enabled in Zoom

@nonpunctual I assume you're talking about auto updated controlled by the IT team (Zoom docs here).

We've heard from many end users that auto updates are a poor experience. They log on for their first call of the day and are late because the update takes 5 mins.

[noahtalerman]

The Zoom update flow seen in this Loom video (1:35) requires the end user to enter their local pwd.

Automating MDM migration will also require the local pwd. I imagine updating other tools will also require the local pwd (ex. Docker)

To make this totally automated, how the model gets access to the end user's local pwd? Can the model get access w/o prompting the end user? Probably not.

How/where does Fleet store the local pwd? Probably on the local disk somewhere. Maybe it's encrypted and Fleet decrypts it for the LLM during the flow.

Noah: Need some engineering resources to help dig into how we would store it so we can talk about this confidently w/ prospects. Need a theory.

[spokanemac]

@noahtalerman, if we proactively update Zoom (in this example) in the background, we can turn off auto-updates for the user. In this scenario, users will never experience the Zoom update before a meeting.

The point is that the standard for admins is to have updates done seamlessly in the background with no user interaction (short of logging out).

Attempting to store the local user pwd is just begging for exploitation. We need to do everything we can as admins NOT to prompt users for credentials, as auth-window burnout is a vector for exploit.

[spokanemac]

@noahtalerman A scenario for this that might play better is automation behind logging out that properly acknowledges prompts to save and close out apps so OS and software updates can run. We could call this at the beginning of a maintenance window, and then trigger updates.

[nonpunctual]

I think the larger point is exactly that @noahtalerman I think what @spokanemac is driving at that, e.g., munki has this kind of behavior built in &, frankly, the self-service model of Mananged Software Center or Jamf Self Service obviates a lot of the fragile logic that has to be crafted around "auto-updates" because users install stuff when they want to.

There is still the problem of getting them to DO the updates, but, my opinion is the ENTIRE "nudge-y" model is predicated on there being a self service model in place, i.e., it's kind of nuts to enforce updates with something like Nudge UNLESS you have 1st given users a rock-solid, well-understood, safe way of installing things themselves, at a time of their own choosing.

[noahtalerman]

Actions items:

1. Can we do this without prompting the user for a pwd? Maybe piggyback on Apple's prompt for the pwd.

Luke: Potential solution: Maybe we can ask the AI to open Keychain and read the pwd.

2. If we can't get the pwd w/o prompting the user, validate that we can put the password into the Keychain.

3. If we can't get the pwd w/o prompting the user, how do we know when the pwd changes? Is there some event we can listen to and then prompt again?

cc @sharon-fdm

[nonpunctual]

@noahtalerman opening the keychain with some sort of AI I think is not a viable solution & seems to me to be equivalent to hacking the operating system's built-in security.

[getvictor]

@noahtalerman I'll start investigating potential solutions in ~2 hours, after I finish my current in progress task.

[noahtalerman]

@getvictor sounds good! Thanks.

FYI I moved the action items from the comment here in the issue description ("Action items" section).

That way, everyone's aware of what we're trying to learn during this investigation.

[mostlikelee]

Unless there are controls I'm not understanding with zoom auto-updates (maybe it can force a specific version?), then like @spokanemac mentioned, we do not need the end-user password because Fleet already runs scripts as root and can install zoom outside zoom's autoupdate process (something like installomator, or a simple script to download and install the application)

[getvictor]

@noahtalerman I agree with @mostlikelee and @spokanemac that software updates/installs are not a good use case for open interpreter. Run this script through Fleet to get the Zoom version you want:

pkill -x zoom.us
curl -L -o zoom.pkg 'https://zoom.us/client/6.0.11.35001/zoomusInstallerFull.pkg?archType=arm64'
installer -pkg zoom.pkg -target /

The script would need to be cleaned up for production.

[noahtalerman]

@getvictor @spokanemac and @mostlikelee, the Zoom updates resonates w/ end users. So, for now we're using it for illustrative purposes mainly.

We think MDM migrations are going to be the real kicker for OI.

[nonpunctual]

Any scripts that we use for direct downloads to Hosts should have at least minimal validation such as checking the Apple Dev Cert team identifier against the software vendor, whether or not the app is codesigned, whether or not the package is notarized, etc. These are basic, easy-to-perform checks that Installomator performs on all installs. Also, logic can be used that trivially handles all container types (i.e., .dmg, .pkg, .zip, etc...)

[getvictor]

Copying a password from Keychain requires a password:

[getvictor]

@noahtalerman Since this use case is for demo purposes, here are a couple options:

• Store the password in ENV variable
• Create a new custom keychain with a generic password (or password in ENV variable). Put the user password into that keychain. Use the generic password to retrieve the user password.
  • Perhaps the generic password can be held by Fleet and only retrieved via Fleet Desktop

[nonpunctual]

I really don't think we should be storing the a user password in a seaprate keychain that would be accessible to any admin user of the system, should we?

[getvictor]

I really don't think we should be storing the a user password in a seaprate keychain that would be accessible to any admin user of the system, should we?

I don't think an admin can access a password-protected keychain.

We can use a 3rd party tool like 1Password to share the password. We can use Fleet Desktop as a piece of the solution.

Or we can add a secret store to Fleet Desktop. The secret store can simply use the Keychain as the storage backend.

[noahtalerman]

@getvictor thanks!

Put the user password into that keychain.

Is there anyway to get the pwd and put it into the keychain without adding an extra, non-macOS prompt for the password?

I can imagine Fleet Desktop asking for the pwd but I'm curious if there's a way to avoid this.

Also, how do we know if/when the pwd changes? Is there some event we can listen to?

[getvictor]

Orbit or fleet desktop can store/retrieve passwords (or any secret) from the keychain. We would need to add a UI to do that.

Yes, there is a way to check when the user last changed the password:

dscl . read /Users/<username> accountPolicyData

[getvictor]

@noahtalerman, should we close this or reassign it back to you since I switched to working on the 'Migrate to Fleet' demo?

[noahtalerman]

Closing this one now that the action items (issue description) are wrapped up.

[fleet-release]

Automated Zoom refresh, While workers rest, updates mesh, Morning calls, no stress.