ThomasL.38230 (Customer) asked a question.
The updated Okta Workflows documentation on how to "Execute On-Premise PowerShell with Okta Workflows" appears to assume that replacing the steps to set up the old agent-based Hybrid Runbook worker with the new extension-based workers while keeping everything else the same should work. However, there are two issues, especially with the sample script given.
- The lack of a service principal results in the inability to get the refresh token to retrieve a runbook job's output.
- The new extension-based workers do not have the ability to 'runas' a local/domain administrator, resulting in cmdlets requiring elevation like like New-ADUser and Set-ADUser hitting "Access is denied/Insufficient access rights to perform the operation"
The lack of a service principal can be resolved by adding the App Registration to the Automation Account's IAM, and the Resource Group to the Identity.
However, I am still unable to figure out a solution to elevate the runbook script.
Has anyone here been able to get on-premise Powershell with elevation working since moving to an extension-based worker?
I have tried adding the following to my script but it made no difference:
if(-not ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")) { Start-Process powershell.exe "-NoProfile -ExecutionPolicy Bypass -File `"$PSCommandPath`"" -Verb RunAs; exit }
I was using Okta Workflows to trigger creating new ADUsers when such a Jira service ticket came in, but it has since broken.
The guides I am referencing are below:
https://{{domain}}.workflows.okta.com/app/templates/execute_onpremise_powershell_with_okta_workflows
@ThomasL.38230 (Customer) -- I have reached out to the owner of this process. I cannot make any guarantees but will update this thread once I hear back.
@ThomasL.38230 (Customer) - I discussed this with the process owner and they are requesting the following:
Assuming you are available in my time frame I will like take ownership of the case to coordinate. If everything is setup correctly per the provided instructions and it is not functioning we will likely need to investigate with the process owner.
@TimL.58332 (Workflows)
I can confirm I've followed the instructions to ensure no steps were missed.
Any script not requiring elevation works (eg. Get-ADUser).
Scripts where elevation is required (eg. New-ADUser/Set-ADUser) have insufficient access/permissions.
I've tore down and recreated the automation account, resource group, and hybrid workers following the instructions in the link and have not had success.
Microsoft Azure support helped me figure out the inability to get the job status and output of a runbook job, but have so far been unable to help me figure out how to elevate the script.
I will a formal support case in Workflows, but this appears to be more of an Azure issue than Okta's.
Thomas
@TimL.58332 (Workflows)
After reaching out to multiple support avenues, others have confirmed that the documentation as written does not work, although we were able to find a resolution.
I hope this helps. If necessary, please forward this to @bryan.barrows1.5613819579051719E12 (Okta, Inc.) to update the documentation.
Thomas