9.81 issue with API update

dfarnworth
New Contributor III

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

1 ACCEPTED SOLUTION

dfarnworth
New Contributor III

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.

d90a557f06e74ecd946874b382aa78af

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>

View solution in original post

8 REPLIES 8

dfarnworth
New Contributor III

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.

d90a557f06e74ecd946874b382aa78af

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>

cvgs
Contributor II

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

NightFlight
New Contributor III

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

BrysonTyrrell
Contributor II

@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".

dfarnworth
New Contributor III

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

NightFlight
New Contributor III

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.

SamF
Contributor II
Contributor II

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".

TimArnold
New Contributor II

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