Automic Workload Automation

 View Only
Expand all | Collapse all

Extract password from LOGIN object and put it into script environment variable

  • 1.  Extract password from LOGIN object and put it into script environment variable

    Posted Feb 04, 2016 04:39 AM
    We are investigating using LOGIN objects as secure stores for application passwords, We have set up a custom login type called TSM_TEST. We are able to get unencrypted passwords from a LOGIN object called TSM.LOGIN using the job messenger daemon. The following commands are in a Windows BAT job:

    :SET &PW#    = GET_LOGIN(TSM.LOGIN,"*",TSM_TEST,PASSWORD) :PRINT Encrypted password: &PW# &UC_JOBMD CMD="echo &PW#"

      This echoes the password in the job report. What we would like to do next is to capture the password in an environment variable so that we can use the password later in the BAT script. Has anyone ever done this? Ideally we would like to do this in a PowerShell interpreter job, not a BAT job. I have not found a way to run the job messenger daemon from within a PowerShell script though. Has anyone found a way to do this?


  • 2.  Extract password from LOGIN object and put it into script environment variable

    Posted Feb 04, 2016 04:52 AM
    For what it’s worth, I was able to do this in a UNIX bash script like this:
    :SET &PW# = GET_LOGIN(TSM.LOGIN,"*",TSM_TEST,PASSWORD)
    password=$(&UC_JOBMD CMD="echo &PW#")
    echo "Password: ${password}"


  • 3.  Extract password from LOGIN object and put it into script environment variable

    Posted Feb 04, 2016 05:41 AM
    I think I have figured out why I was having difficulty getting it to work in a PowerShell interpreter job. It appears that &UC_JOBMD is not set in interpreter jobs. The solution I found is to hard-code the path to the job messenger daemon in the script:
    :SET &PW#      = GET_LOGIN(TSM.LOGIN,"*",TSM_TEST,PASSWORD)
    $jobMessenger  = "C:\Program Files\uc4\agent\bin\ucxjwx6m.exe"
    $password      = & $jobMessenger "CMD=echo &PW#" 2>&1
    Write-Host $password
    Does anyone know why &UC_JOBMD is not set in interpreter* jobs?

    * This problem affects only Windows jobs of type Interpreter. It does not affect Windows or UNIX jobs that run external interpreter statements via a :BEGIN_EXT_INT ... :END_EXT_INT block.


  • 4.  Extract password from LOGIN object and put it into script environment variable

    Posted Feb 04, 2016 04:16 PM
    I had this same issue setting up PowerShell support in V9.  Rather than setting up a new variable like $jobMessenger, I discovered I could modify the contents of &UC_JOBMD myself, and then I used it like normal.   It does not make sense to me that PowerShell interpreter jobs do not populate this variable for us(?)

    I think the SET instruction is how you modify a windows environment variable?



  • 5.  Extract password from LOGIN object and put it into script environment variable

    Posted Feb 05, 2016 07:51 AM
    Pete Wirfs said:
    I had this same issue setting up PowerShell support in V9.  Rather than setting up a new variable like $jobMessenger, I discovered I could modify the contents of &UC_JOBMD myself, and then I used it like normal.   It does not make sense to me that PowerShell interpreter jobs do not populate this variable for us(?)
    As I see it, the point of the &UC_JOBMD variable is that it can be relied upon to point to the job messenger daemon, regardless of on which agent the job is run. The usefulness of the variable is somewhat negated if one has to set it manually. :smile:
    I think the SET instruction is how you modify a windows environment variable?
    Yes, and I’m still trying to find the best way to set a variable to the output of another command. The following approach works:
    :SET &JMD#   = "C:\PROGRA~1\uc4\agent\bin\UCXJWX6M.EXE"
    :SET &PW#    = GET_LOGIN(TSM.LOGIN,"*",TSM_TEST,PASSWORD)
    FOR /F "tokens=* delims=§" %%i IN ('&JMD# ^"CMD^=echo &PW#^" 2^>nul') DO SET pw=%%i
    ECHO %pw%
    Unfortunately, this approach once again depends on hard-coding the pathname of the job messenger daemon — and in particular, the 8.3 pathame. If I use &UC_JOBMD instead, it does not work. If I use the long path name in a UC4 script variable or BAT environment variable, it does not work.

    It seems that at least for ordinary Windows jobs, &UC_JOBMD contains the long path name enclosed in double quotation marks. E.g.,
    "C:\Program Files\uc4\agent\bin\UCXJWX6M.EXE"
    I have not found a way to use &UC_JOBMD instead of the hard-coded 8.3 pathname. The FOR loop does not behave as desired, and I think this is due to the quotation marks, the space between Program and Files, or both. Perhaps someone can suggest a way to around this obstacle. Alternatively, perhaps someone can provide a quick and reliable way to convert the long pathname to an 8.3 pathname.


  • 6.  Extract password from LOGIN object and put it into script environment variable
    Best Answer

    Posted Feb 05, 2016 11:26 AM
    Ok, I figured it out. The trick was using the USEBACKQ option, and enclosing the whole command in back-ticks (`). There are two ways to make it work.

    1. Insert CALL before the command to run.
    :SET &PW# = GET_LOGIN(TSM.LOGIN,"*",TSM_TEST,PASSWORD)
    @ECHO OFF
    FOR /F "usebackq tokens=* delims=§" %%i IN (`CALL &UC_JOBMD ^"CMD^=echo &PW#^" 2^>nul`) DO SET pw=%%i
    ECHO %pw%
    2. Enclose the whole command in double quotations marks ("), and also enclose each part of the command in double quotes.
    :SET &PW# = GET_LOGIN(TSM.LOGIN,"*",TSM_TEST,PASSWORD)
    @ECHO OFF
    FOR /F "usebackq tokens=* delims=§" %%i IN (`"&UC_JOBMD "CMD^=echo &PW#" "2^>nul""`) DO SET pw=%%i
    ECHO %pw%
    Remember that &UC_JOBMD will expand to a string that includes a leading and trailing " character, so in both of the examples above, this part of the command does not need (and should not be enclosed in) additional " characters.

    I found both of these solutions in this StackOverflow thread.


  • 7.  Extract password from LOGIN object and put it into script environment variable

    Posted Feb 05, 2016 01:02 PM
    When I first encountered the issue of &UC_JOBMD being empty, I had windows agents running on both 32bit and 64bit operating systems.  So I had to use an IF statement to populate &UC_JOBMD based upon the agent name.  This code had to be corrected as our 32bit servers were upgraded one at a time.  



  • 8.  Extract password from LOGIN object and put it into script environment variable

    Posted Feb 06, 2016 11:43 AM
    I answered my own question. Would some kind soul with admin privileges please mark this comment as the accepted answer?


  • 9.  Extract password from LOGIN object and put it into script environment variable

    Posted Feb 10, 2016 07:31 AM
    For those of you who use Perl interpreter jobs, here is how to capture a password into a Perl variable.
    :SET &PW# = GET_LOGIN(TSM.LOGIN,"*",TSM_TEST,PASSWORD)
    $password = `&UC_JOBMD CMD="echo &PW#"`;
    print "Password: $password";



  • 10.  Extract password from LOGIN object and put it into script environment variable

    Posted Feb 20, 2016 06:12 AM
    In case anyone is interested, here is the use-case for which I was investigating this topic. We have a few tasks that must run on basically all nodes in the enterprise. One example is nightly backups. We could install an agent on every node; but for almost all of these nodes, the nightly backup is the only scheduled activity that will run. We didn't think it made sense to install an extra piece of software just to run one job per day; so we opted for an alternative approach based on OS-level remote execution facilities. On UNIX, we chose SSH. On Windows, we opted for PowerShell.

    Among the Windows nodes, there is a small number of nodes in a so-called DMZ. These nodes are not in the corporate Active Directory domain; all users are all defined locally. There is a special DMZ user that we can use when connecting to these nodes. I wanted to keep the username and password of this user in a secure location, but to have a way to read the information programmatically.
    :IF &DMZ# = "Y"
    ! If this is a DMZ node, set up the remote session using different credentials
    :SET &LOGIN_OBJ# = "TSM.LOGIN.DMZ"
    :SET &LOGIN# = GET_LOGIN(&LOGIN_OBJ#,"*",TSM_TEST,LOGIN_INFO)
    :SET &PW#    = GET_LOGIN(&LOGIN_OBJ#,"*",TSM_TEST,PASSWORD)
    $userName = "&LOGIN#"
    $jobMessenger = "C:\Program Files\uc4\agent\bin\ucxjwx6m.exe"
    $password = & $jobMessenger "CMD=echo &PW#" 2>&1
    $SecurePassword = $password | ConvertTo-SecureString -AsPlainText -Force
    $Credentials = New-Object System.Management.Automation.PSCredential -ArgumentList $userName, $SecurePassword
    $remoteSession = New-PSSession -ComputerName $computername -Credential $Credentials -Port 5986 -UseSSL -SessionOption (New-PSSessionOption -SkipRevocationCheck)
    :ELSE
    ! If this is not a DMZ node, set up the remote session using the credentials of the current user.
    $remoteSession = new-pssession -computername $computername -ErrorAction Stop
    :ENDIF
    • If &DMZ# variable is set to "Y", then the DMZ user name and password are extracted from a login object, and the remote session is set up using the credentials of this DMZ user.
    • Otherwise, the remote session is set up using the credentials of the current user (the one defined in the LOGIN object of the job.)
    Then a bit later in the script, we use the remote session to run the stuff that we actually want to run (i.e., starting the backup):
    Invoke-Command -Session $remoteSession -scriptblock {
    ...
    }
    This approach works well, and lets us easily run arbitrary commands on remote nodes, both inside and outside of the corporate Active Directory domain. This approach could be useful in other situations in which one must run commands on nodes where it is impractical or impossible to install the agent.


  • 11.  Extract password from LOGIN object and put it into script environment variable

    Posted Feb 22, 2016 01:04 PM
    We also use PowerShell remote execution to avoid having to spin up additional windows agents.

    While we are on the subject of PowerShell, we use a UC4 INCLUDE for error handling our PowerShell scripts.  This include checks the most recent PowerShell result, and if it isn't zero, it stops the script.  As an added feature, it also executes an echo command to display the return code along with a counter, so if it does detect a problem, you'll know exactly which instance of the include detected the problem.
    ! ********************************************************
    ! If PowerShell result is not "True",
    !    Set RC=0001
    !    And stop the script
    ! ********************************************************
    :set &POWERSHELLERRORCOUNT# = str_cat(&POWERSHELLERRORCOUNT#,"")
    :set &POWERSHELLERRORCOUNT# = &POWERSHELLERRORCOUNT# + 1
    $RC = $?
    echo "POWERSHELL RC=$RC (&POWERSHELLERRORCOUNT#)"
    switch ($RC)
        {
            True    { $EXIT_CODE = 0 }
            False   { $EXIT_CODE = 1 ; echo "Aborting script!" ; exit $EXIT_CODE }
            default { $EXIT_CODE = 1 ; echo "Aborting Script!" ; exit $EXIT_CODE }
        }




  • 12.  Extract password from LOGIN object and put it into script environment variable

    Posted Mar 30, 2016 11:19 AM
    We are doing the same thing here (use of powershell for remote commands...), but I have problems when tasks run for a long time (2-3 hours). Sometimes, the PSSession seems to lost the connection. Did you ever experience something like that? And how do you use the Invoke-Command? I had to do some tricks to be able to catch the status code of the remote-command...

    J-F


  • 13.  Extract password from LOGIN object and put it into script environment variable

    Posted Mar 30, 2016 11:54 AM
    We get the last exit code like this:
    $LastExitCodePSR = invoke-command -ScriptBlock {$lastExitCode} -Session $remoteSession
    We are also experimenting with storing the exit codes of individual steps of the remote script in an object, and passing that object as a return value when the script block terminates.

    We have remote sessions that stay open for several hours, and have not had problems with disconnections, at least not yet.


  • 14.  Extract password from LOGIN object and put it into script environment variable

    Posted Mar 30, 2016 11:59 AM
    Does anyone know why &UC_JOBMD is not set in interpreter jobs?
    I received an answer in a support ticket:
    Use of the &UC_JOBMD in anything but the default batch mode will require modifications to the windows header and footer.You can see an example of this in the default HEADER.WINDOWS:
    :IF &UC_WIN_TYP = "BAT"
    :set &UC_JOBMD = get_var(UC_EX_JOB_MD)
    :set &UC_IP_PORT = get_var(UC_EX_IP_PORT)
    :set &UC_IP_ADR = get_var(UC_EX_IP_ADDR)
    Modifications to HEADER.WINDOWS and TRAILER.WINDOWS would not survive an AE Initial Data load, so that’s probably not the best way to handle this.

    Are variables like UC_EX_JOB_MD accessible in ordinary scripts?


  • 15.  Extract password from LOGIN object and put it into script environment variable

    Posted Mar 30, 2016 12:14 PM
    Michael Lowry said:

    Are variables like UC_EX_JOB_MD accessible in ordinary scripts?
    These variables are accessible in ordinary scripts using :GET_VAR. They are set in the agent INI file.


  • 16.  Extract password from LOGIN object and put it into script environment variable

    Posted Mar 30, 2016 01:52 PM
    On the point of making modifications to the HEADER and TRAILER includes....  Losing modifications to some objects that normally live in client 0 is a small thing.  We made modifications to these objects frequently and other than needing to keep track of the changes and re-applying after an upgrade (just make it another step in the process) this never had any negative impact to us.  Another alternative is to copy those objects to the specific clients.  The system checks there first and then in client 0.  This option means you won't have to re-apply changes after an upgrade which is nice, but also means some extra maintenance - if you have 20 clients you'll have to copy those objects to all 20 clients and keep them all in sync in case updates are made.  So it's not the end of the world if you have to do this.



  • 17.  Extract password from LOGIN object and put it into script environment variable

    Posted Mar 31, 2016 09:52 AM
    Hi Michael_Lowry 
    I'm curious about this case you've explained and I'm digging deeper to understand it.

    Is it right to say that you use the Job messenger just to decrypt the password that is stored in the Login object?

    Based on the CMD parameter of job messenger daemon -> "The Job Messenger automatically identifies and decrypts the passwords."

    And the Login object info ->
    "The password is returned in encrypted form. You can use the password with the Job Messenger (start parameter CMD) where it will be decrypted."

    Also, you can't decrypt passwords for AE defined Login Types, like Windows or Unix (I've tried and got the error "The provided type 'WINDOWS' is not allowed").

    So, you created a custom Login type to store the password and use the Job messenger to decrypt it before passing it to your new powershell session and finally running what you need. Is this correct?


  • 18.  Extract password from LOGIN object and put it into script environment variable

    Posted Mar 31, 2016 10:54 AM
    Roney said:
    Hi Michael_Lowry 
    I'm curious about this case you've explained and I'm digging deeper to understand it.
    ...

    So, you created a custom Login type to store the password and use the Job messenger to decrypt it before passing it to your new powershell session and finally running what you need. Is this correct?
    Correct. It’s just a way of storing passwords securely.

    In our system, we allow everyone to read all objects, so we cannot permit passwords to be stored in VARA, SCRI, JOBS, or other ordinary objects. The responsible batch developer for a project may read but not write the LOGIN object(s) for that project. Given these conditions, LOGIN objects offer some advantages:
    • passwords are not displayed, and cannot be copied;
    • passwords are not stored in clear text in the DB;
    • LOGIN objects cannot be accidentally or intentionally altered by normal users; and
    • passwords can still be accessed programmatically by authorized users, via the circuitous method described above.


  • 19.  Extract password from LOGIN object and put it into script environment variable

    Posted Aug 21, 2017 09:10 AM
    Hello all,

    I'm trying to setup password decryption in application specific job (Siebel job), but it is not possible by default because password can only be decrypted with Job Messenger of OS agent.

    My idea is to set up script in Siebel job to use Job Messenger of OS agent, that is installed on the same host. I have tried to achieve this with PREP_PROCESS command, that uses EVENT.WINCMD to execute command on desired OS agent, but with no luck so far. I'm not sure how to pass command to desired exe and use &PASSWORD# variable, that is not defined at the time when PREP_PROCESS command is executed. There is also syntax error with double quotes.
    ! Loads password of custom defined login object: :SET &PASSWORD# = GET_LOGIN(LOGIN.SIEBEL,"*","*",PASSWORD) ! Successfully prints encripted password: :PRINT Encrypted pasword: &PASSWORD# ! Defines Job Messenger of Windows OS agent (WINHOST) on the same host: :SET &JM# = "d:\Automic\v11\Agents\windows\bin\ucxjwx6m.exe" :SET &HND# = PREP_PROCESS("WINHOST","WINCMD",,"&JM# "CMD=echo &PASSWORD#" 2>&1","UC_LOGIN=AUTOMIC.LOGIN") :PROCESS &HND# :  SET &RETURN# = GET_PROCESS_LINE(&HND#) :  P &RETURN# :ENDPROCESS

    Below simplified command successfully captures output of command line, but it doesn't use Job Messenger that is required here.
    :SET &HND# = PREP_PROCESS("WINHOST","WINCMD",,"CMD='CMD=echo hostname","UC_LOGIN=AUTOMIC.LOGIN")
    :PROCESS &HND# :  SET &RETURN# = GET_PROCESS_LINE(&HND#) :  P &RETURN# :ENDPROCESS

    Mabye my approach is wrong and some other commands should be used.
    I know that two independent jobs may be used: One to decrypt password on OS agent and pass it to Siebel job that will use it, but if possible, I would like to perform all the processing in Siebel job.

    Any sugestions are welcome because you already have expirience with decryption on custom defined Job Messenger.

    Thanks in advance.