Can't rename the system, host, and localhost name on Apple M1 MacBook Pro laptop

[rnhurt]

I'm trying to update the host name of my M1 MacBook Pro laptop using the "Mac - Rename System HostName LocalHostName and ComputerName from JumpCloud.md" script. However, there appears to be a misconfiguration somewhere because it doesn't work. I tried debugging it a bit and it turns out that the curl command is failing:

search=$(
    curl -s\
        -X 'GET' "https://console.jumpcloud.com/api/systems/${systemID}" \
        -H 'Content-Type: application/json' \
        -H 'Accept: application/json' \
        -H "Date: ${now}" \
        -H "Authorization: Signature keyId=\"system/${systemID}\",headers=\"request-line date\",algorithm=\"rsa-sha256\",signature=\"${signature}\"" \
)

results in this output:

 {"message":"Unauthorized","error":"Unauthorized"}

I've compared the script with the official API documentation but I can't see anything wrong with it.

I used this same script before on a different Intel MacBook pro and it worked. Is this just a problem with M1 machines? Is this a problem with my Client key? If so, how do I correct it? Did the JC API change in some subtle way I'm not seeing?

[jworkmanjc]

@rnhurt Just curios if your issue relates to #320?

Systems that have been automatically enrolled using Apple's Device Enrollment Program (DEP) or systems enrolled using the User Portal Install are not eligible to use the System Context API. Systems enrolled in these ways are unable to use the System Context API to prevent unauthorized access to system groups and resources. If a script that utilizes the System Context API is invoked on a system enrolled in such a way, it will error with an unauthorized message.

I agree this should be called out on the API documentation. I can try to post an update to those descriptions.

[rnhurt]

@jworkmanjc that makes sense. The computer(s) that I used the script on in the past were all pre-DEP machines and the one it's failing on is fully enrolled in the DEP. And yes, it appears to be similar to #320 though not exactly the same (Windows vs. macOS).

Would using a R/O API key work for all systems (both DEP and non DEP)? If so, can you outline how to create such a key? I looked in the documentation but it looks like an API key is registered to a user and has the same permissions as that user. So, does this mean I'll have to create a new "R/O Admin" user or something? If so, will that user could against my license and cost $$$? If so, that seems like a sub-optimal solution.

[jworkmanjc]

@rnhurt Users in the user portal count toward your billable users. Administrators under Settings > Administrators do not count toward this limit.

Yes a read only API key should have access to read information about your JumpCloud org. Because the authorization source is an API key, not system Private Key, that user could read systems that were enrolled with DEP. There exists a KB that covers creating Admins, and their roles. You would have to create a read only admin in this case. I've added a note in our feature requests portal for both this and #320 for the ability to use the system context API after a system has gone through DEP or User Portal installation.

[rnhurt]

That's excellent! I was able to create a R/O Administrator user and obtain an API key which should do what I need for now. However, it would be great to be able to use the client key for this type of lookup and not have to worry about exposing a key with more access.