Powershell Orchestration - Running as Admin

[shawn_h]

Hi folks,

I've got a small script which should ideally populate users into the security tab of an active directory group object.

Unfortunately, the script only works locally when it is "Run as Administrator" when I try to run this locally in a Powershell Window.

The first few lines of my script are used to re-open a prompt as admin, which also works locally, but doesn't seem to work when initiating it as a powershell activity from ServiceNow.

The active directory credentials plugged into ServiceNow have admin rights but, alas, the script seems to return the same error as if I would run it without an elevated prompt.

Would anybody be able to help in either running a Powershell command as Admin from ServiceNow, or happen to know another solution that might help in doing the same thing?

[Rahul Shandily3]

Did you try running your script from Powershell Command Window to test if it works?

The ID that you used for Orchestration should have Admin rights on the MID Server from which your are invoking the Powershell script. It is the same IP or Hostname where the script is being executed. Also, your ID should have access to pull that data from Active Directory. 

Also, can you post the error that you are getting while running this script.

Thanks,

Rahul

[shawn_h]

Yep, I've run the script locally and it does work, but it only works if I "Run as Administrator" on the powershell window. I'm testing using the same account locally, as well as within ServiceNOW, so I know it has the correct rights.

Here's the error if i run the script in a non-elevated Powershell Window. (This is without the 3 lines commented out at the top of the script, which relaunches as an elevated prompt)

Here's the error I get back from ServiceNow.

As it's a very similar error, I'm thinking its the "Run as Administrator" bit that's causing the issue.

[Fernando Dunn]

With Orchestration, there are always a couple questions.

1) Is the activity's target host the MID server (e.g., localhost or 127.0.0.1) or is it your AD domain controller?

2) If using localhost or 127.0.0.1, does the account running the MID server service in Windows have the appropriate AD privileges to run your script?

Whenever you run an activity directly against the MID server, it is being run as the same account running the Windows service. Credential tagging comes into play only when you run an activity against a different target than the MID server.

It's a good practice to run your MID server service for Orchestration as a separate AD service account and then give that account the appropriate access that it needs to run it's various functions in your environment. It eliminates the need for ServiceNow storing the credentials which is sometimes a red flag for security admins.

[shawn_h]

I'm running the script against the Domain Controller, and I'm using an account that we already use to perform orchestration activities on the same target. The AD account has sufficient right to perform the changes locally too.

Couldn't agree more with the latter points, it's what we're partially doing and aiming to do more of in future once we're a bit more mature with our deployment!