It’s generally not a great idea to have individual clients connect to the BES API - it means each of those clients has to be able to reach the root server directly. To reduce attack surface I generally recommend clients shouldn’t connect to the root at all, and only access to the infra is through Relays (specifically to block the API connectivity).
That said, it looks like your sessions are connecting since you see the errors in the server log.
This line where you retrieve credentials though -
$pair = "$($env:username):$($env:password)"
That looks like you’re reading the user name and password from environment variables? I expect when deployed through an MDM it won’t have the same environment as your logged-on user session - and if I’m reading that correctly, it is exceedingly dangerous to keep BigFix API credentials set in environment variables.
The $env: part is how Workspace ONE stores additional variables, described here in step 5. It’s deployed per-script, and not stored in the endpoint’s environment variables. VMWare specifically describes it as for API keys and service account names or passwords.
Is there any safe way for the endpoints to trigger an action themselves? I know I can have an always-on fixlet scanning for some type of tag, but I thought it would be cleaner to have the machines make the request themselves.
Ah, ok. In that case I expect that Workspace is performing the variable substitutions in-line and perhaps the script is dereferencing it too many times with the $ signs? I.e. if the username is ‘apiuser1’ with password ‘mypass’, I think perhaps this line
$pair = "$($env:username):$($env:password)"
Could evaluate as
$pair = "$(apiuser1):$(mypass)"
Try writing it as
$pair = "$env:username:$env:password"
(Or variations on that, maybe write the script out to a file. I’m not conversant on Workspace One but it might be useful to see whether the generated script is really what you expect, or to manually execute the script after they generate it)
I tried poking around to see if the variables were getting passed correctly, and they do seem to be. Also since I’m seeing successful logins that match the times of script executions, I suspect they indeed are, e.g.
I did have to change the double quotes in my .xml to single quotes, but otherwise no changes. I tried again with single quotes and Invoke-WebRequest, but it still failed.
So, I’ll consider this resolved for now. Thanks for looking into this!
This is the way. POSH 7 is much better at handling API calls and working with data.
At most I just have to do add param of “SkipCertificateCheck” = $true" depending if needed.
My guess is the OP may need to do something with setting protocols. We have to do this with just about every POSH 5 script.
$AllProtocols = [System.Net.SecurityProtocolType]‘Tls12’
[System.Net.ServicePointManager]::SecurityProtocol = $AllProtocols
Also I would recommend switching from from Invoke-WebRequest to Invoke-RestMethod