Skip to main content

Hi,



Has anyone seen any permissions issues with API updates of computer records since upgrading to 9.81?



We have a pre-existing script that changes the status of an extension attribute for a computer record. It seems that since we upgraded to v9.81, this has ceased working.



The most useful part of the API output seems to be the line:



<p>Error: Not authorized for a user PUT</p>


I have checked the privileges for the API user and there seem to be 2 newer privileges: Computer Extension Attributes & User Extension Attributes. I have allowed Update for both of these (along with update on Computers already set), but still no joy.



Any thoughts?
Dan

Found it...



It seems that you now need to have Update enabled for Users in order to be able to PUT and update for a computer record. Seems odd.





FWIW, this is what we were trying to do:



curl -k -v -u "$USERNAME":"$PASSWORD" "$JSS_SERVER/JSSResource/computers/serialnumber/$SERIAL_NUMBER/subset/extensionattributes" -T "$TMPFILE" -X PUT


Where $TMPFILE's contents are:



<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<computer>

<extension_attributes>

<attribute>

<name>$EXT_ATTR_NAME</name>

<value>$EXT_ATTR_VAL</value>

</attribute>

</extension_attributes>

</computer>

We had the same problem and the same solution. Apparently access to "Users" is now needed.

Me too. We should report this as a 'defect'. I don't agree that this should be expected behaviour.

@danf_b - This is a minor thing, but you should only need the "Update" permission for User objects on the account and not have to include "Read".

Hi @brysontyrrell



It is a minor thing yes, but it is deeply frustrating that we seem to be seeing this regularly with updates and that the newly required permissions are not mentioned in the release notes.



This is not the first time this has happened and once again, it broke production policies. We were not aware of this for some time as it was a subtle (but crucial) change that occurred to newly deployed machines. When we did become aware of it I had to work my way through the permissions one by one testing to discover which had caused it.



Could you please pass this along the chain to ensure that end-users are made aware of any permissions changes required in future releases?



Regards
Dan

This requires clarification.



The users server object. This refers to the server user accounts, or just the users data collected in a record?
Because if the former, then this is a gigantic security hole, given the nature of how API executes on the endpoint.



Discuss.

This refers to the latter, in your example. The privilege for accounts accessing Jamf Pro in an administrative capacity is called "Jamf Pro User Accounts & Groups".

FYI - You still need to allow Read for 'Users' and 'Computers' to update computer records.

Terms & ConditionsCookie settings