Jamf Nation Community

etippett · ‎12-16-2015

Awhile ago I created a local JSS user that was solely for the purpose of using its credentials in scripts to perform actions via the API, namely updating the value for specific extension attributes within a computer record. I want this user to be as limited as possible since its credentials may be exposed in clear text in scripts.

In 9.62 this was working fine with the user only having create, read, and update privileges for computer objects. This broke when updating to 9.81. Is anyone doing something similar and can verify what privileges are needed? I tried adding delete for computer objects, as well as CRUD for computer extension attributes, but still no luck.

Here is the command I'm running and the associated output, which you can see states "Not authorized for a user PUT":

curl -k -v -u username:password
https://jss.url:8443/JSSResource/computers/name/TaggartJ-M0L5A
/subset/extensionattributes -T /tmp/ea.xml -X PUT
* Hostname was NOT found in DNS cache
  % Total    % Received % Xferd  Average Speed   Time    Time     Time
Current
                                 Dload  Upload   Total   Spent    Left
Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--
  0*   Trying ip.ip.ip.ip...
* Connected to jss.url (ip.ip.ip.ip) port 8443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
* Server certificate: jss.url
* Server certificate: Columbus College of Art & Design JSS Built-in
Certificate Authority
* Server auth using Basic with user 'api_upload'
PUT
/JSSResource/computers/name/TaggartJ-M0L5A/subset/extensionattributes
HTTP/1.1
Authorization: Basic YXBpX3VwbG9hZDpDYXNwZXIxNA==
User-Agent: curl/7.37.1
Host: jss.url:8443
Accept: */*
Content-Length: 200
Expect: 100-continue
< HTTP/1.1 100 Continue
} [data not shown]
* We are completely uploaded and fine
< HTTP/1.1 409 Conflict
< X-FRAME-OPTIONS: SAMEORIGIN
< Cache-Control: no-store, no-cache, must-revalidate, max-age=0,
post-check=0, pre-check=0
< Date: Wed, 16 Dec 2015 14:49:46 GMT
< Accept-Ranges: bytes
* Server Restlet-Framework/2.1.7 is not blacklisted
< Server: Restlet-Framework/2.1.7
< Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
< Content-Type: text/html;charset=UTF-8
< Content-Length: 417
< Connection: close
<
{ [data not shown]
100   617  100   417  100   200   1304    625 --:--:-- --:--:-- --:--:--
1307
* Closing connection 0
<html>
<head>
   <title>Status page</title>
</head>
<body style="font-family: sans-serif;">
<p style="font-size: 1.2em;font-weight: bold;margin: 1em 0px;">Conflict</p>
<p>Error: Not authorized for a user PUT</p>
<p>You can get technical details <a
href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.10">he
re</a>.<br>
Please continue your visit at our <a href="/">home page</a>.
</p>
</body>
</html>

mm2270 · ‎12-16-2015

It was noted another thread where others saw the same issue that for some unexplained reason the account now needs to have Update permissions to the Users record, or something like that. We aren't on 9.8x yet, still on 9.73 so we haven't seen this issue, but will need to do extensive testing with our API scripts before our upgrade to see what's needed. Here is the thread: https://jamfnation.jamfsoftware.com/discussion.html?id=17846

These kinds of changes with API privileges can be particularly frustrating since it doesn't seem like there is any actual documentation that notes the needed changes. Maybe its in the full 9.81 documentation, but I'm not sure. Anyway, lots of API scripts that do writes can end up breaking because of changes like this that aren't clearly communicated.

View solution in original post

mm2270 · ‎12-16-2015

It was noted another thread where others saw the same issue that for some unexplained reason the account now needs to have Update permissions to the Users record, or something like that. We aren't on 9.8x yet, still on 9.73 so we haven't seen this issue, but will need to do extensive testing with our API scripts before our upgrade to see what's needed. Here is the thread: https://jamfnation.jamfsoftware.com/discussion.html?id=17846

These kinds of changes with API privileges can be particularly frustrating since it doesn't seem like there is any actual documentation that notes the needed changes. Maybe its in the full 9.81 documentation, but I'm not sure. Anyway, lots of API scripts that do writes can end up breaking because of changes like this that aren't clearly communicated.

etippett · ‎12-16-2015

Wow, I'm not sure how that thread didn't come up when I searched for information relating to this! Thanks for pointing it out, @mm2270 ! Adding the Update privilege for Users solved the issue for me as well.

I agree with you whole-heartedly about the lack of documentation...

sgonschorek · ‎08-14-2023

Nice, 8 years old and still get me the answer.

LuisSP · ‎10-31-2023

The link no longer works in the accepted solution, and I cannot find the Users record in Privileges. @sgonschorek could you share what you did?

sgonschorek · ‎11-01-2023

@LuisSP

It´s noit recommended anymore using user + password within scripts. Bether use the API roles and clients available with Jamf Pro 10.49+ and provide the ID and secret as Script Parameter in a Policy.

Good example how to use: https://github.com/Macjutsu/super/wiki/Apple-Silicon-Jamf-Pro-API-Credentials

The Superman Script is actually working with that roles.

API Roles and Clients - Jamf Pro Documentation 11.0.0 | Jamf

Jamf Nation Community

Privileges Required to Update Computer Records