Powershell interpreter - use of Automic encrypted passwords?

[Pete Wirfs]

 

I want to use Automic encrypted passwords inside of a PowerShell interpreter job.  After I retrieve the encrypted password, I want to use it in the construction of a credential object.  However I can't seem to get the&UC_JOBMD CMD= method to work, presumably because the PowerShell interpreter sees it first and doesn't like it.  I only get PowerShell errors.

Is there a trick that will make this work?  Or should I be using a different technique?

 

Pete (V9-SP5)

[PhilippElmer610374]

Hey Pete,

long time no talk, how are you?

Since I wrote the short tutorial on how to use encrypted passwords recently on AutomicBlog.com, your problem caught my interest. I hope I can help you out:

1. Check if &UC_JOBMD is set! If it isn't, hardcode the job messenger location into your script (or in some include, as you want ;-)

2. If you need the encrypted password in an .EXE call out of a powershell script, then you need to prefix the commandline with an ampersand in order for powershell to recognize it as an external command. See "Case 1" below.

3. If you need the password inside powershell, you need a command substitution.
   See "Case 2" below.

So here's the two solution proposals:

Case 1:

!Case 1: Use password in external command out of a powershell script

!the "echo" here is the windows command "echo"

:JCL_SUBSTITUTE "$", "&"  

$ &UC_JOBMD CMD='echo &PASS#'

:JCL_SUBSTITUTE

Case 2:

!Case 2: Use password inside the powershell script (command substitution)

Write-Output "THe password is $( &UC_JOBMD CMD='echo &PASS#' )"

Let me know if this helps!

Regards,

Philipp
AutomicBlog.com

[Pete Wirfs]

Hey Philipp, I'm sorry that I won't be going to the USA Automic conference this year.  I think you plan to go to that one?  I learned a lot by going to last years in Savanna GA.

I tried case1 and case2 and they didn't work for me.  I think the "&UC_JOBMD" is still not getting resolved.   So next I plan to "hard code" the path to UCXJWI3M.EXE and run it explicitly instead of using &UC_JOBMD. (I plan to open up a share to the uc4 folder on my uc4 server for this purpose)

I've been busy fighting alligators today so I haven't been able to try this out yet.  I will post my findings when I get a chance.

Pete

[PhilippElmer610374]

Hi,

that's right, I plan to attend this year's Innovate in the USA. I hope to get the details set up with Automic soon because I want to offer a Database Training at the conference.
I'm sorry yuo can't come, maybe (hopefully) we'll meet in person in 2015!

I also have Agents where &UC_JOBMD isn't set. In order for the code to work, you can just 

:SET &UC_JOBMD = "C:\Path\to\UCXJWI3M.EXE"

Philipp

[Pete Wirfs]

 

I discovered UC_JOBMD was empty so I populated it.  I then tried your case1 example inside of the PowerShell script and it worked!

:JCL_SUBSTITUTE "$", "&"  

$ &UC_JOBMD CMD='echo &PASS#'

:JCL_SUBSTITUTE

However the very next powershell command (a simple echo) failed.  I googled the error message ("The OS handle's position is not what FileStream expected")  and discovered I was running into a known bug inside of PowerShell;

"When PowerShell sends output to its output stream the first time, it keeps a reference to the output stream for future use. However, this output stream is really a wrapper around a lower-level stream. When cmd.exe writes to the output stream, it writes to the lower-level stream. This makes the .NET wrapper complain that the underlying stream has changed from beneath it."

 

I discovered a PowerShell workaround on the following site that works for me so I have everything I need now;

http://www.leeholmes.com/blog/2008/07/30/workaround-the-os-handles-position-is-not-what-filestream-expected/

 

Why can't these things just "work" on the first try?  LOL

 

Pete

[Pete Wirfs]

This is how I get the unencrypted password into a powershell variable;

 

$SecurePassword = (&UC_JOBMD CMD="echo &ServerPassword#")

[PhilippElmer610374]

Hi Pete,

great! :smile: 

I totally agree with you regarding "why can't theses things just work...".
Funny, you found the same workaround on the net as I did in 2011 when I wrote http://www.automicblog.com/automicblog/uc4-and-ms-powershell-part-2/ 

Philipp

[Pete Wirfs]

 

Now the issue of PowerShell ExecutionPolicy has come up.  We'll be having a meeting with our security manager to discuss the subject, so I wanted to prepare by exploring our options.

I had been setting my target servers to RemoteSigned which seems to be sufficient for running PowerShell from Automic.

And just to see if it would work, I have also set my target servers to Restricted and proved that Automic can still run PowerShell commands on these servers provided I configure the agent like so;

ECPEXE=c:\windows\system32\windowspowershell\v1.0\powershell.exe -NonInteractive -ExecutionPolicy bypass

What I haven't tried is setting the target servers to AllSigned and figuring out how to configure Automic to support signing the powershell script before executing it.  Has anyone else tried to do this this?  I don't know what would be gained by choosing AllSigned, but I thought I should explore it anyway?

 

[Pete Wirfs]

 

Had our meeting with our security expert.  Everyone agreed that PowerShell's ExecutionPolicy does not add any security to the process.  We have decided to leave all servers set to Restricted, and Automic will always run PS scripts with the Bypass option.