I have a doubt regarding the password type and encryption as well as decryption. Can we decrypt the password (not in servicenow), in scripts such that the passwords wont be visible in the ECC Queue

[njay]

Hi All,

I have a doubt regarding the password type and encryption as well as decryption. Can we decrypt the password (not in servicenow) but in scripts such that the passwords won't be visible in the ECC Queue of the Servicenow.

I have given the field type of password as password2 and I want to decrypt the password in powershell script, can we do that?

Please help me its bit urgent.

[tim_broberg]

Nikhil, there is some support within the mid server for encrypted parameters in Geneva, but it has not yet been connected to orchestration, so you're a little "bleeding edge" here.

If you open an incident and ask for me, "Tim Broberg," I can walk you through what it would take, but it's premature to publish details to the world.

[njay]

Hi Tim,

Thanks for the reply, I will raise the incident in Service Now regarding the query.

[mustaphafilahy]

Hi Tim

Any update about how to Hide the password in the ECC queue ?

Best regards

[Joshua Chapman]

This post is a bit old but yes you can encrypt ECC queue outgoing messages.

See:
https://docs.servicenow.com/bundle/quebec-servicenow-platform/page/product/mid-server/reference/mid-...

However there is a large caveat to using this API. It'll only encrypt one-way. Meaning if you're sending an ECC queue message to the MID server it'll work just fine. If your MID server is performing an action and sending back information however in the input (returning) ECC message your original outbound ECC queue message will show up in the XML unencrypted. (I don't know why servicenow does this... but to me it defeats the purpose...)

An example might be if you're sending a command line command for the MID server to perform, or directly invoking a powershell or other application via the command line. If you're passing in credentials that are required for the command or application to do what it needs to do then you'll need to ensure that the application or command does not return an ECC queue response, otherwise the original command will appear in the response ECC queue entry in the clear... even though you used the automation API to encrypt the output (outbound) message.

Potential workarounds if you're using an application or powershell: use orchestration obviously is one it's the most simple solution and the most recommended if it meets your needs/budget.

Returning a response via a REST call or other side-channel from your MID server script/application might be another approach.

More complicated might be to symmetric encryption (AES) via a framework like Crypto-JS (https://github.com/brix/crypto-js) and/or asymmetric encryption via a framework like jsencrypt (https://github.com/travist/jsencrypt) to ensure that anything going over the ECC queue is encrypted separate from ServiceNow. Completely possible, whether desirable though...