Extension attribute value as a script parameter?

[MatG]

We have a EA script pulling in a value that we would then like to use in a script.

The script is currently set with a $4 value so it uses the Parameter Value set in the first field when adding the script as payload to a policy, anyway to allow this $4 value to be the EA value?

[mm2270]

Not directly. You would have to use an API call in your script to grab the value from the endpoint the script is being executed on from the Jamf console.

The other option, of course, would be to use the same commands that are being used in your EA script in your normal policy script. Assuming that's what you're doing in that EA and it's not a manually set value. It seems like it from what you mentioned.

It would actually be great if there was some way for the jamf binary to know EA values so they could be used as script parameters or values in policies, without needing to run the same commands again within the script or using an API call.

[MatG]

Thanks, the API route was the exact route I was going down and I have it working.

I added to the top of my original script an API call that grabs the EA value I required, makes it a variable and then its used in the script. Works well.

[sdagley]

@MatG Do you care if the value is user visible? If you're looking to pass an EA value without using the API you could embed the EA into a Configuration Profile with an Application & Custom Settings payload that uses a string in the format "$EXTENSIONATTRIBUTE_<EA_ID>" as the value for a key in a domain you define, then have your script read the .plist for that domain which will be found in /Library/Managed Preferences/ once the profile is installed (if it's a Computer Level profile).

A downside to this approach is the profile won't be updated automatically if you change the value of the EA, so you have to force an update by editing the profile, saving it (no change actually required), then selecting Distribute to All.

[MatG]

Interesting idea but I have it via API which is working, odd though to do an API call for a value that's in Jamf when running a script from Jamf but it works.

[sdagley]

Just as an FYI Jamf does discourage use of the API on client side scripts because the credentials can't be truly secured, just obscured.

And if you've got any IP address restrictions in place for access to a Jamf Pro console then those same restrictions apply to the API endpoint as well (i.e. the API isn't accessible to my Macs all the time so I like to find ways to do things without the API)

[NateES]

If Jamf provided $AssetTag as a profile variable I'm sure that would remove a significant need for API use on the client-side.