Closed jshirle2 closed 1 year ago
One could do this but it would fundamentally break the entire security model for your LAPS implementation.
Think about it... how does super
find out the local computer's LAPS password? In the example you gave, super
would be reading from the Jamf API. For this to work you'd have to give super
a Jamf API credential (which itself has no automated method to rotate/change) allowing it to read every single LAPS password for every single computer.
Congratulations, not only did you just undermine the entire point of LAPS (the Jamf API credential used by super
cannot be changed automatically), you actually created an even worse security vulnerability. This is because super
had to save that Jamf API credential to the local System keychain for future use. Every local administrator can read the System keychain. Thus, you just programmatically stored a Jamf API credential on every computer allowing any local administrator to find out the LAPS password for every Jamf-managed computer.
In other words, until Jamf allows for a limited per-computer authentication method to access the Jamf Pro API, giving super
the ability to read anything from your Jamf Pro database is fundamentally insecure.
Thanks for the response @Macjutsu. Guess I'm curious the alternative. A service account would require being granted volume ownership and cryptouser, which means it would show up on FV unlock, and now you've got a shared account across all machines with the same username and password. It seems like LAPS is the lesser of two evils here... (which, sadly, seems like a lot of what we do)... =/
@staze Incorrect. Assuming the default settings, the super
service account password is randomized on each computer, similar to the FileVault recovery key. https://github.com/Macjutsu/super/wiki/Apple-Silicon-Local-Credentials#local-super-service-account-details
Now the creation of a local super
service account via your LDAP account is technically interesting... In fact, that is already an open issue that I do plan on evaluating in the future: https://github.com/Macjutsu/super/issues/86
FWIW... the new super
v4 --auth-ask-user-to-save-password
option is currently, and will likely always be, the safest, most reliable, and performant authentication option.
Thanks @Macjutsu. I guess I'm just not sure here. Our goal is to be able to update unattended machines, so you can't prompt for credentials in that case. Our erase-install process, or self service upgrade processes also grab the laps credentials for running those processes.
It seems, if you ask me, like we have to work around Apple's "broken" update processes to get things to work, and asking that something be implemented in super to support either in our case EasyLAPS, or macOSLAPS, and letting the jamf/macOS admins to make that call on if they're comfortable granting those permissions, is reasonable.
The service account showing up on filevault login will sadly annoy/freak out many of our users who already think they "own" the devices provided to them by the institution. =/ So leveraging the existing LAPS enabled account for this, as mentioned, seems like (to use the phrase again) the lesser evil. =/
might be honestly barking up the wrong tree on this... while I think using the existing laps account is the way to go for unattended computers, the reality is Apple just needs to make updates more reliable so that unattended machines can get unattended installs, which isn't really Super's target audience.
We use EasyLAPS in our environment and for us to use Super on Apple Silicon we will need LAPS support. Could we get the ability to pass an EA ID to use for the password in Super? Thinking there would be a script option to enable LAPS support, and then another one to define where that password would come from (either EA ID or maybe support for JAMF LAPS in the future).
Thanks for all the work you do!