System Context Authorization on Windows not working - Unauthorized error

[avivek]

We are using the sample script from this repo.
A sample one which we tried was from the below url:
https://github.com/TheJumpCloud/support/blob/master/scripts/api/system_context/windows_examples/system_get_self.ps1

No changes made just the entire script used as is but still we get an Unauthorized error.
Can you please help??

[jworkmanjc]

Hi @avivek. If the system you have tested this script on has installed JumpCloud using the user portal installation, the system would be unable to use system context API.

In those cases that system has what's called a provisionerID - the JumpCloud UserID of the person who installed the agent on the system.

Using the JumpCloud powershell module I can see all the systems installed in this way.
get-jcsdksystem | where-object {$_.provisionerID}

If the system was enrolled in JumpCloud in this way it would make sense that the system context API is not available for this system. If that's the case, a read-only API key may be of interest.

[avivek]

Thanks for the quick response @jworkmanjc .
I will check how the agent was installed.

I have some questions:

• The behaviour you are mentioning is not mentioned anywhere in the jump cloud articles or am I missing something??
• This will be a big drawback since the jumpcloud commands will be commonly written and differentiating the authentication this way would be pretty difficult.
• I was thinking that a system should always have a way to authenticate itself to the Jumpcloud servers be it user portal installation or otherwise. There should be an inherent authentication scheme using which the agent talks to the server.

[jworkmanjc]

Hi @avivek,

There are some changes to our API documentation in flight, docs.jumpcloud.com should see a refresh soon. I also just placed a request to update the KB article to address this documentation debt.

I agree that this is a drawback for some workflows. Most importantly if you need to use the system context API to write changes to a system (group membership) then they system must be enrolled with an Administrators connect key (not user portal installed). The advantage to using the system context API is that the systems themselves can move between system groups for automation workflows.

If you need to move a system to another group without the system context API you'd need to use an API key with write access.

The design decision behind preventing systems from using system context API through the user portal was in short made to prevent unauthorized access to resources. If for example, an employee installed JumpCloud on their personal computer and managed to use the system context API to move their system into a group which provided access to software, this would be an example of unintended resource granting. As such those systems enrolled through user portal installation are ineligible to use the system context API. Long story short the alternative scenario where a user gained access to resources they were not explicitly granted was a less desirable outcome.

It would be nice if there was a switch or flag you could set on systems after enrollment which would enable use of the System Context API even after user portal install. This could exist as a feature request.

Lastly did you find out if the system in question was enrolled with user portal installation or DEP?

[avivek]

Thanks a lot for a detail explanation @jworkmanjc .
The device I tested on was indeed a device which was enrolled through user portal installation.
I follow what you are saying.I am not fully convinced as I can say that system context opens the same scenarios that are classified as not good , no matter the installation type.
I am not very sure that such a long term limitation would be desirable just cause a device was enrolled in a particular fashion.

1. As you mention, I absolutely think that a way to say I trust this device and an ability to clear this restriction would be needed.
2. There is already a need for an admin to bind a system to a user in case of a user installation. Maybe that can be the internal switch to indicate a trusted device.
3. Is there a way using the API/poweshell I have to ability to clear the provisioner Id field thereby removing this restriction.
4. Is this restriction only for User Portal Installation or also for Mac DEP??

Again thanks for the clarifications.