How to store decrypted password in an Object variable

[Srujan_Pathuri_9871]

Hi All,

- I have decrypted the prompted password using Job melder functions in a Unix Job and would like to store the password in an Object variable. Please let me know any example on how to get this done.

- Can I use this Job melder functions in Script object, instead of OS Jobs?

Thanks in advance,

-Srujan.

[Legacy User]

Hi Srujan,

Can I use this Job melder functions in Script object, instead of OS Jobs?

The Job melder (also known as job messenger) is a component of the OS Agent. For this reason it has to be used in an OS job.


Best regards,
Antoine

[Carsten Schmitz]

Srujan Pathuri said:

Hi All,

- I have decrypted the prompted password using Job melder functions in a Unix Job and would like to store the password in an Object variable. Please let me know any example on how to get this done.

If you used "Job Melder" (Melder is just the German word for "Messenger" btw), the password will be in your report I think. If so, you need to use PREP_PROCESS_REPORT, and parse the report for the password, then write that into a variable.

If I am mistaken however with my memory about the password being in the report, and the password is somehow in Linux, then you need to:

• write it into a file with Unix output redirection ( > or >> operators, or "tee" command), then read that file with PREP_PROCESS_FILENAME. If you do this, think about security, since you'll be writing a password to a file on disk in plain text.
  
• write it into a shell variable, and get it into Automic with:REGISTER_VARIABLE

- Can I use this Job melder functions in Script object, instead of OS Jobs?

No. No you can't, "Job Melder" is a function of the agent, so it only gets involved in JOBS OS jobs.

Hth,

Carsten

[Anon Anon]

Hi

1. you can use :REGISTER_VARIABLE to pass an OS variable to a Automic Script variable
hint: there is no need using begin_ext_int clauses....
Disadvantage: the decrypted password will appear in several reports so the process of encryption /decryption is kinda useless :-)

https://docs.automic.com/documentation/webhelp/english/ALL/components/AE/11.2/All%20Guides/help.htm#ucsaba.htm%3FTocPath%3DAutomation%2520Engine%2520Script%2520Guide%7COrdered%2520by%2520Function%7CScript%2520Structure%2520and%2520Processing%7C_____19


2. Yes of coure :-)
you can use (my personal old and new love) PREP_PROCESS + OS command for decrypting a password

https://docs.automic.com/documentation/webhelp/english/ALL/components/AE/11.2/All%20Guides/help.htm#ucaafp.htm%3FTocPath%3DAutomation%2520Engine%2520Script%2520Guide%7COrdered%2520by%2520Function%7CData%2520Sequences%7C_____7

some days ago I created an include to use this function in a script or OS job - if you are interested pls let me know.
! Pls be aware its still in a testing phase, so no liability for anything from my side :-)

cheers, Wolfgang

[Carsten Schmitz]

FrankMuffke

Dude, we need to split up the days between us, we keep posting the same things :D I propose we make a UC4 calendar, and you answer postings on Mondays and Wednesdays and Fridays, and I take Tuesday and Thursday ;)

On the plus side, at least we post the same things. It's precise like a quorum decision of the redundant systems in an Airbus :)

Best,
Carsten

[Srujan_Pathuri_9871]

Carsten_Schmitz_7883

Due to security reasons, I can't use prep_process_report and prep_process_filename as the password will be visible in logs. I tried with Register_Variable and am not getting the desired output. Could you please look into the following code and tell where did I make mistake? I am trying to store shell variable to the object variable.

password=$(&UC_JOBMD CMD="echo &PMFPWD#")

:REGISTER_VARIABLE "password#", password

The above code is placed in a Unix job and &PMFPWD# value is getting from promptset.

Thanks,
Srujan.

[Carsten Schmitz]

Hi,

this comes down less to checking code and more to trying it out, and apologies, I don't have the possibility to try it right now.

Just a hunch, maybe try

:REGISTER_VARIABLE "password#", $password

(note the dollar character to (hopefully) read the value of the UNIX variable).

Best regards,
Carsten

(edit: yes, I think the missing dollar sign is the problem, at least as per Michael Lowry's example for bash, found here).

[Anon Anon]

Heres a screenshot of my include working...
The PW output is a print to be removed in "live" version :-)
works on WIN and LINUX

https://us.v-cdn.net/5019921/uploads/editor/8t/5nd8k51zsob1.jpg" width="1238">

and yes, my sandbox env credentials are uc4/uc4  its way shorter than automic/automic o:)

...hope I do not have to rename it to CA/CA...  >:)

cheers, Wolfgang

[Srujan_Pathuri_9871]

Wolfgang Brueckler said:

1. you can use :REGISTER_VARIABLE to pass an OS variable to a Automic Script variable
hint: there is no need using begin_ext_int clauses....
Disadvantage: the decrypted password will appear in several reports so the process of encryption /decryption is kinda useless :-)

Yes, it's a huge disadvantage. Is there any other way that I can mask the password that is being displayed on all the reports or else can I turn off the logging for this part? 

Regards,
Srujan.

[Anon Anon]

Hi

turning off logging for some parts is not possible.

If its tested I can provide you with my JOBI to test, if you want.

Another possibility I can imagine would be writing the PW in a file temporary and reading it from this file whenn calling your application...

should work e.g. in powershell ...
snip:
SET /P password=<.tmp.txt
DEL .tmp.txt
...

cheers, Wolfgang

[Carsten Schmitz]

Or, you could take report permissions away from anyone who isn't entitled to see the password (pitty that "NOT" permissions are currently bugged and their usage is ill-advised, but theoretically a "not that particular job's report" for everyone might work).

But don't do this with anything older than a current 11.2.x, because there was also a bug where people could read job reports regardless of permissions.

Either way, it's probably best not to use this for, like, really sensitive passwords anyways. Domain admin passwords, the SSL pass-phrase for Amazon.com or the nuclear codes *) shall not be put into Automic. Ever! :)


*) personal experience. possibly. :p

[Srujan_Pathuri_9871]

FrankMuffke  Carsten_Schmitz_7883

Thanks for your time. Let me briefly tell you what our use case is all about.

1. Design a workflow which contains two Unix jobs. The workflow will have a promptset that would ask the user to enter his username and password.
2. Now before the first job gets started(Pre-Process), we need to create a login object (Login.Dynamic) based on the credentials given in the workflow promptset. We define the above mentioned login object in the object attributes of the first UNIX job. As a result, we make sure that the particular user will login to target machine and perform the jobs.
3. The second UNIX job will also use the same login object and execute the commands.
4. Once every job is successful, we would delete the login object.

For security and compliance ,we don't want a Generic user (AE) to get into the target host, instead we want the job gets executed with the job implementer credentials, such that it would easy for us to track any issue at server level and can identify the user effortlessly.

Appreciate if you let me know any new workarounds to do this.

Thanks,
Srujan.