Skip to main content
Solved

How to push device specific settings/content to a machine?

  • July 28, 2023
  • 3 replies
  • 68 views
N
Forum|alt.badge.img+2

Does anyone have an example of pushing device specific configuration to a machine?

Scenario: I'd like to populate a file on every laptop device that contains the content of certain extension attributes that are centrally defined and keep that regularly up to date when I make changes in the admin portal.

Is there any means to do this? Everything I am seeing all seems to be geared around "shared" or "common" policies that are associated to machines/groups. I'm not looking to create 100 different policies each associated to one machine. I'm looking to populate based on actual attributes set on the device itself in the portal.

 

Another way of looking at this - is it possible to have a policy that has "templated content" in it where the template values come from EA's set on the device?

Best answer by mm2270

Unless JAMF is providing "per device" credentials 'to talk to the api' on the device, that would require putting actual API credentials ON THE DEVICE which would be pretty bad from a security model standpoint.

In my case the EA's would be populated manually by administrators/portal users and/or external applications using the API. It's not determined from the machine. Think attributes that are defined centrally like "These are the list of users that should exist on the machine" or "This particular machine should have a config file with this content in it that was set centrally.". 

Are there JAMF API credentials that exist on the box that allow the machine to authenticate to JAMF for operations like this? (How does the jamf CLI authenticate itself to the server?)


The API credentials would not have to be put on the device. They can be obscured to a degree within the script, but the script is only downloaded during policy runtime, executed and then removed, so nothing sticks around on the machine itself. Also, in the new API model, the credentials actually become tokenized when doing the actual call back to Jamf, so it's an individualized encoded string that then gets discarded. It only works per session.

I'll admit it's not perfect, but it's all we have. Also, you can make things a little more secure by creating a special account in Jamf that is not an admin, but can only read specific objects in Jamf. Use those credentials in the API call, so you aren't using something like your overall Jamf Pro admin account that can do everything in the console.

    3 replies

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • July 28, 2023

    Yes, this is possible, but only when using the Jamf API.

    Basically, you'd need to write a script that would run on the device, but call back to the Jamf Pro server using API calls, to get the specific machine's details and/or Extension Attribute information, then place that back into a file.

    Another thought - if the EA values you're talking about are something that can just be gathered live in a script, much in the same way you might gather them now in your EA, then I would go that path instead. IOW, if your EA uses a script to pull some local data, then just use the same script syntax to pull the same data when run from a regular Jamf Pro policy script.

    But, I suspect what you might be asking about is information that is ONLY within Jamf Pro, like an EA that uses a drop down value, or a text field entry. In that case, you would need to do this using the Jamf API to query Jamf on what the value is for the Mac the script is running on.

    aparten11
    N
    Forum|alt.badge.img+2
    • nneul_mst
    • Author
    • New Contributor
    • July 28, 2023

    Unless JAMF is providing "per device" credentials 'to talk to the api' on the device, that would require putting actual API credentials ON THE DEVICE which would be pretty bad from a security model standpoint.

    In my case the EA's would be populated manually by administrators/portal users and/or external applications using the API. It's not determined from the machine. Think attributes that are defined centrally like "These are the list of users that should exist on the machine" or "This particular machine should have a config file with this content in it that was set centrally.". 

    Are there JAMF API credentials that exist on the box that allow the machine to authenticate to JAMF for operations like this? (How does the jamf CLI authenticate itself to the server?)

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • Answer
    • July 28, 2023

    Unless JAMF is providing "per device" credentials 'to talk to the api' on the device, that would require putting actual API credentials ON THE DEVICE which would be pretty bad from a security model standpoint.

    In my case the EA's would be populated manually by administrators/portal users and/or external applications using the API. It's not determined from the machine. Think attributes that are defined centrally like "These are the list of users that should exist on the machine" or "This particular machine should have a config file with this content in it that was set centrally.". 

    Are there JAMF API credentials that exist on the box that allow the machine to authenticate to JAMF for operations like this? (How does the jamf CLI authenticate itself to the server?)


    The API credentials would not have to be put on the device. They can be obscured to a degree within the script, but the script is only downloaded during policy runtime, executed and then removed, so nothing sticks around on the machine itself. Also, in the new API model, the credentials actually become tokenized when doing the actual call back to Jamf, so it's an individualized encoded string that then gets discarded. It only works per session.

    I'll admit it's not perfect, but it's all we have. Also, you can make things a little more secure by creating a special account in Jamf that is not an admin, but can only read specific objects in Jamf. Use those credentials in the API call, so you aren't using something like your overall Jamf Pro admin account that can do everything in the console.

    aparten11
    Terms & ConditionsCookie settingsAccessibility statement