Feature Request: Jamf Pro 10.46.0 provides API access to management account name and password

[wakco]

Change in Jamf Pro 10.46.0 … Local Administrator Password Solution (LAPS) provides API access to look up an existing account and password.

Obviously we would still need to make sure the account has a Secure Token, but that is relatively easy to do, this would enable super to collect a known changing password and use that to trigger softwareupdate.

[Macjutsu]

Not saying no... but this would significantly increase the potential attack surface for whatever Jamf API account is stored by super in the System Keychain. There is potential to gain an admin password for not just the local computer... but for every computer in an organization.

[wakco]

Thankfully admin access is required to look at that keychain entry, but I agree, that said, the security issues are something Jamf will need to consider regarding their API.

I had written something else, but you have given me an idea for a decent feature request for Jamf, for the jamf command, be able to do something like jamf adminLogin softwareupdate --install --all --restart, and then the jamf command could on Apple Silicon Macs, automatically add or pass the admin login credentials to softwareupdate, and perhaps the same for sysadminctl as well as any other command we could have it handle. Perhaps adding something from the policy to allow a script to use the command (for sysadminctl).

Jamf "Idea" JN-I-27135

[Macjutsu]

Digging into this new feature... there are a lot of dependencies and several outstanding issues that make it unsuitable for deployment at this time. I will reevaluate as Jamf makes improvements.

[jelockwood]

@wakco
I have been trying on Apple Silicon Macs to get the MDM workflow for upgrades to work, so far unsuccessfully and I am willing to believe this is mainly down to Apple. ☹️

As such I am now considering the possibility of using a local admin account like you appear to be. I have recently joined an organisation and currently they have the same credentials on all Macs which is on my list of things to fix, i.e. to implement LAPS. I have had a brief look at Jamf's new LAPS feature but I get the impression it is not adequate yet to the purpose. I have previously used a script which stores the LAPS password in an extension attribute.

It looks like it might be possible to use the value of this extension attribute as a parameter to a policy script parameter. If so I could then run the Super policy with parameters which pass the LAPS user name and password to Super during deployment and allow super to then create a local account.

According to the Jamf docs, this is done by using a Jamf variable in the script parameter so it might looks something like the following -

--admin-password=$EXTENSIONATTRIBUTE_5

Note: The 5 refers to the number of the extension attribute so will be dependent on your setup.

I have a string suspicion however that the eventually (hopefully) created local credential will lack the required volume owner etc. permissions as Apple for example make it difficult to script giving a secure token to a script created user account. (Another Apple issue.)

[Macjutsu]

You can not set the value of a script parameter via that mechanism. It's only designed for Configuration Profiles.

[jelockwood]

@Macjutsu
The $EXTENSIONATTRIBUTE was to read the LAPS password for the Mac that Jamf was running the policy and script on, not to set it. It would be set by the LAPS script using the Jamf API.

The idea was to read the LAPS password from the extension attribute and pass it to Super. As mentioned I have previously used a LAPS script which stored the password in plain text in the extension attribute and hence should work as is. However these days it is considered better to store the password in an encrypted form even though you have to be an approved Jamf user to access it.

I have had a look at some other LAPS solutions for Jamf and the following one looks better to me.

macOSLAPS

The author has provided an example script to retrieve and decode the LAPS password. In theory Super could be enhanced to use the $JSSID to look up the relevant extension attribute and decode its contents and then have the correct LAPS password for the Mac in question and hence be able to use it to do the required authentication locally.

LAPS Decode Password Script

The script will need some modifying for this purpose to make it fully automated and hence remove some of the interactive aspects. (Basically strip out everything except reading and decoding the extension attribute.) I could myself build this in to Super but I would have to do this each time you updated it. Ideally Super would be modified to have an additional script parameter e.g.

--use-macOSLAPS
and
--use-macOSLAPS-off

And accordingly use this or not. It should be possible to put this modified script in the Super folder and call it based on this additional parameter. I could create the modified script for you if you are willing to add it to Super.

[Macjutsu]

I am aware of LAPS solutions... but there are two fundamental security problems with leveraging them in any local process or script like super.

1. Just because you have a local admin account, doesn't mean it can authenticate a macOS update/upgrade. The account requires Volume Ownership permissions which can not be programmatically given to a new account without first providing the credentials of an existing Volume Owner user. So even the act of creating a LAPS account capable of performing a macOS update/upgrade can not be automated. It's my understanding that the new Jamf LAPS solution will suffer from this same macOS security design choice.
2. In order to lookup any EA value super must authenticate to the Jamf Pro API... this means that super would be storing that credential in the System Keychain. Because of Jamf Pro's security model, that credential, if discovered, would allow anyone to have full read access to your entire Jamf Pro inventory database. Obviously, this would be a significant security risk.

[jelockwood]

@Macjutsu
Yes, I am aware of the volume ownership requirement. I have previously had Jamf run a policy which gets the user to authenticate locally giving an IT admin account a secure token if needed and then previously had a Jamf policy which does the LAPS function. (I am looking at a new way which piggybacks on Jamf Connect to automate creating a local admin account with an initial password and secure token/volume ownership.) So I would be ensuring that the local admin account is up to the job for Super and hence can be used by Super to create the Super service account.

I in fact did use this today to get Super to work for doing the upgrade successfully. I passed the password for the local admin account in a Jamf policy with the Super install script, it used the password to create the Super service account, I had also a Jamf Profile setting for Super to failover (ALWAYS) in the event of an MDMworkflow failure and it then successfully installed the macOS Ventura upgrade.

Super is already setup as per your instructions to authenticate to Jamf API - this is working. It can therefore potentially use the same approach to authenticate reading an extension attribute which is storing a LAPS password. I am using the $JSSID approach recommended by your instructions which supposedly means it cannot read the entire inventory. (Although I would have thought it would be possible to emulate this by looping through all possible JSSID values.)

All the LAPS solutions for Jamf rely on using the API to set and to read the values and I would presume this includes Jamf itself. However the one I am referring to like several others does encrypt the contents. This encryption key could be passed to Super via a script parameter.

[Macjutsu]

Yes... but due to the limitations of Jamf Pro's security model... the permissions required for the Jamf Pro API account used by super to read EAs would also allow it read EVERY SINGLE EA for ALL of your computer records.

And it doesn't matter if you have added the extra (technically not actually more secure "encrypted" strings) method because super would have to store the decryption secrets in the Keychain as well. In other words, you just made it slightly more complicated but no more secure.

In short, because of limitations in Jamf Pro and because super has to store the secrets, if someone can view their local System Keychain (default for admin), then they can know all the LAPS passwords for your entire environment.

[jelockwood]

@Macjutsu
I see your point about Super directly reading EA fields.

However I think if we used as a script parameter something like -

--admin-password=$EXTENSIONATTRIBUTE_5

This would not require giving the SuperApi credentials full EA access and the content of the designated EA would be passed to your script. A Jamf admin would like all the other script parameters specifically set this up so it cannot be auto scraped and it would also be for a specific script i.e. Super. Furthermore the content of the EA in this case would be in encrypted form and would need decrypting in your script to utilise. This likely will require using two script parameters one for the encryption key and one for the encrypted admin password as above. Basically the same way that the macOSLAPS script works except your script would not have full EA access.