Question about extension attributes

[jelockwood]

@PezzaD84 As far as I can see your macOSLAPS solution like some others stores the LAPS password in Jamf in an encrypted form. Arguably this is a good idea.

I have previously used https://github.com/NU-ITS/LAPSforMac which stores it as a plain text extension attribute. You do of course have to be a Jamf Pro admin to view it and the script does encrypt stuff when talking to Jamf.

I mention this because I am currently looking at another Mac admin requirement which is to automatically authorise installing macOS upgrades on Apple Silicon Macs and the MDM command is simply too unreliable so I will need to access and use a local admin credential. The goal is to avoid having the user themselves authorise this as too many will not bother to do this.

This would be easiest it seems by reading an extension attribute as plain text. See https://learn.jamf.com/bundle/jamf-pro-documentation-current/page/Computer_Extension_Attributes.html

One could then pass the script a script parameter like the following -

--admin-password=$EXTENSIONATTRIBUTE_5

where 5 is the number ID of the extension attribute, different setups will use a different number of course.

I would tend to suspect that it would not be feasible to use a script parameter that needs to decode the content of an extension attribute. I would presume it is not possible to embed script commands in a script parameter field.

What is your view on this? Any suggestions on how to solve this?

FYI - the other script I am planning to use for the macOS upgrades is Super

If you have no other suggestions, would you be open to adding an additional optional extension attribute to store it in plain text form?

[PezzaD84]

Hi @jelockwood

Thanks for reaching out about my LAPS script.

Having your upgrade script decode the encoded string is totally doable. You can have the secret key used to encode the password stored in the script or in an extension attribute similar to how I do it with my LAPS script. The other method you could consider, which a few other LAPS and OSupdate scripts use, is to have it stored in a local keychain item which is called and opened in the script to be used in the upgrade process.

Alternatively there is the Super script which is what I use and actually recommend to customers at the moment as it is the most comprehensive upgrade script out there. The logging is incredible and the community support out there is brilliant as well.

Hope that helps a little?

[jelockwood]

I could certainly myself decode your stored value in my own script, I could then create and fill in another extension attribute with a plain text value but that is clearly undesirable.

The author of Super could potentially build this decoding in to his script, I may discuss this with him. Do you have an example script he could base this on?

What about the possibility of building shell commands in to the Jamf Policy shall script parameter so that -

--admin-password=$EXTENSIONATTRIBUTE_5 might become --admin-password=$(echo "$EXTENSIONATTRIBUTE_5" | openssl enc -d base64) or similar

I do not want to use the keychain because firstly this makes it more vulnerable to users finding it, and secondly my IT team need to find it before logging in to the Mac so they can login to the Mac. Therefore the keychain would be a catch22.

[PezzaD84]

Thats actually one of the reasons I didn't go with the Keychain version because as you say if its needed before being logged in you are stuck.

So you wouldn't need to store the value in plain text. Once its in your script you can just pass the de-coded string to your variable. Something along these (very loose) lines: ENCODEDSTRING=$(Curl "Encoded string in Extension attribute")

DECODEDSTRING=$(openssl enc base64 "DECODE $ENCODEDSTRING")

--admin-password=$DECODEDSTRING

This way the logic in the script decodes the encoded string and you never need to store the plain text anywhere.