Skip to main content
Answer

9.81 issue with API update

  • November 16, 2015
  • 8 replies
  • 43 views
D
Forum|alt.badge.img+7

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

Best answer by dfarnworth

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>

    8 replies

    D
    Forum|alt.badge.img+7
    • dfarnworth
    • Author
    • Contributor
    • Answer
    • November 16, 2015

    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>
    T
    C
    Forum|alt.badge.img+9
    • cvgs
    • Contributor
    • November 16, 2015

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

    N
    Forum|alt.badge.img+7
    • NightFlight
    • Contributor
    • December 2, 2015

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

    BrysonTyrrell
    Forum|alt.badge.img+19
    • BrysonTyrrell
    • Valued Contributor
    • December 3, 2015

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

    D
    Forum|alt.badge.img+7
    • dfarnworth
    • Author
    • Contributor
    • December 4, 2015

    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

    N
    Forum|alt.badge.img+7
    • NightFlight
    • Contributor
    • March 1, 2019

    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.

    S
    Forum|alt.badge.img+20
    • SamF
    • Employee
    • March 4, 2019

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

    T
    Forum|alt.badge.img+6
    • TimArnold
    • New Contributor
    • October 9, 2020

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

    Terms & ConditionsCookie settingsAccessibility statement