pass credentials into powershell activity

[chadlockwood]

I'm trying to build a custom PowerShell activity that will run Invoke-RestMethod against my instance to pull an attachment to the MID server. I have a service account built in ServiceNow with permissions to do this. When I run my PowerShell script on the MID server from the PowerShell ISE, the script/credentials work fine.

Now I need to figure out how to get the credentials of the service account into my custom PowerShell activity so that my code can use them. The PowerShell script is being executed on the MID server using the MID Server Service account, but those credentials will not work for the REST request.

I believe that there will be an issue with getting the appropriate password data type from the JavaScript in the workflow, into the PowerShell. In my script, I am generating a credential object like this:

$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $env:SNC_restUser, (ConvertTo-SecureString -String $env:SNC_restPass -AsPlainText -Force)

This works perfectly if I hard-code the username and password into the script in clear text.

I have tried Credential Tagging, but I believe that is only used as the account that is running the whole script, not individual cmdlets within the code.

Does anyone have experience doing this or could tell me how to convert a password object in JavaScript into an appropriate PowerShell password object?

[chadlockwood · Accepted solution]

The solution that I found turned out to be significantly simpler than I expected, thanks to the REST API Explorer.

In the explorer, you have the option of running a REST request as yourself or another user:

Select Send as another user, enter the credentials for your service account and click Send. You will then see your Request, the Response and the Response Body. In the Request headers, you will see an Authorization key with a basic authentication hash:

The hash, including the word 'Basic' is all you need. It is important to note here that once you have run this request you have essentially impersonated your service account and you will have to logout of your instance and back in.

  There are a couple of ways you can use the basic authentication hash. For testing purposes, I hardcoded it into my PowerShell code:

$basicAuth = "Basic YWJlbC50dXRlcjpQYXNzd29yZDEyMyE="
$headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
$headers.Add('Authorization',$authorization)
$headers.Add('Accept','application/json')

Invoke-RestMethod -Uri $uri -Headers $headers

You could also code it into your workflow and pass it as a string to your PowerShell activity or, better yet, create a system property to hold the hash value, and getProperty in your workflow to pass the value to your activity. That way, it is easier to maintain should you need to change the credentials you are using.

[Anders Pr_stega]

Hi Chadloclwoord

Base64 is a reversible encoding. With that token you implicitly have the password if you are a savvy.

ServideNow really should provide a solution that pulls the credentials from the Credential table, like it it does for other credentials.

I have the exact same headache..

-Anders

[Anders Pr_stega]

Check this one out!

AD orchestration authentication $cred is null

function getAdminCredentials() {

  var gr = new GlideRecord('basic_auth_credentials');

  gr.addQuery('name', "O365Admin");

  gr.query();

  if (gr.next()) {

  workflow.scratchpad.adminUserName = String(gr.user_name);

  var Encrypter = new GlideEncrypter();

  var encrypted = gr.password; // current.<<your field name>>

  var decrypted = Encrypter.decrypt(encrypted);

  workflow.scratchpad.adminPassword = String(decrypted);

  }

}

[kroychow]

@Anders Præstegaard- Actually I have tried what you have said in run script. But my doubt is --the credentials- will be still visible in scratchpad field in the table "Workflow All contexts, how to avoid that?