ESP Workload Automation

We currently have a Windows domain ID that we use to run windows distributed jobs from ESP. This ID has a non-expiring password that has been defined to ESP using the ESP PASSWORD command.  Now I am being asked by the security team if that ID could be changed to have the password changed every 30 days. At first I said no, because we have to define that password to ESP and so windows jobs would fail after it changed.  So now they are asking me if we could have an automated process to pick up the new password somehow and redefine it in ESP every 30 days. 

So, my question is 2-fold.

Can this be done and if so, does anyone have an automated process they are using to do this?

Since the PASSWORD command is a Page Mode command I would say yes that it can be done.

My question to you is how does the PASSWORD command know what to use as a password?

What will be creating the new password every 30 days?

I have no idea. I asked my security guy that very question and he couldn't tell me. But, he keeps telling me that when auditors find out we have a windows domain ID that has a non-expiring password, they won't like it.

So, if that is the true, I would think other companies have the same issues since I am sure other companies get audited.  So, has anyone else out there had to deal with this?  If so, what did they do? 

Or maybe someone from CA could respond to let me know what they think. Maybe it cannot be done and if so, then let me know so I can let my security team know that.

Disclaimer: This has not been tested, but I think it could be a starting point.

Assuming you have a Linux server with an ESP Agent installed.

This method uses SHA to hash the date, runs through base64, and then outputs the top 32 characters.

    date +%s | sha256sum | base64 | head -c 32

Variable Sub-string notation like this %symbolic(start_position:end_position).

  %ESPFTFILE(<%StartPosition>:%LENGTH(%ESPFTFILE))                   

This is a rough draft of what you could do:

1. Create a directory on the Linux server ( /home/<user>/password )

2. Create an ESP PROC with the following:

      /* Define Symbolic Variables */    

   AgentName="<Valid Agent Name>"  

   GenPass="date +%s | sha256sum | base64 | head -c 32"
   PassDir="/home/<user>/password"      /* replace <user> with valid user */
   StartPosition="<calculate offset>"

   LINUX_JOB CREATEPW     /* to create the file with the password */

     AGENT %AgentName

     CMDNAME <Valid Shell>
     USER <Valid User>
     ARGS -c 'touch %PassDir/password_$(%GenPass)'  
     RUN ANYDAY
     RELEASE GETPW
   ENDJOB                   
                               
   FILE_TRIGGER GETPW  /* to 'find' the file, password will be in ESP variable %ESPFTFILE */

     AGENT %AgentName
     FILENAME 'PassDir/password_*' EXIST
     RUN ANYDAY    ENDJOB                                                   
   ENDJOB

   JOB SETPASS LINK PROCESS                              
     ESPNOMSG PASSWORD DEFINE USER(jdoe) PASSWORD('%ESPFTFILE(<%StartPosition>:%LENGTH(%ESPFTFILE))')
     RUN ANYDAY                                             
   ENDJOB

3. Create an ESP Event to INVOKE PROC 

Let me know if you think something like that would work.  

Thanks for the update Rick.  I apprciate it.

But, I really just want to know if anyone is having to do this and if so, what are they doing to fix this. I really don't want to do this. I think it will be a major pain to have set something like this up and I would hope if this is something people are going to have to start doing, then CA would have a solution. Is anyone else out there having to do this? 

If not, what do you tell the auditors when they ask?

For what it's worth, we are struggling with this as well.  What makes it worse for us is that we have a Windows ID that has more rights that God because it runs all of the Windows agents, ergo it is running all of the Windows jobs, ergo it needs access to shares, databases, executable, etc.

We were looking at using a processes whereby the PASSWORD command could be issued via JCL/REX or via a Windows agent using ESPlmi.  The idea is that we would have a file watcher or ETT event watching a directory for a file.  When the password gets changed, Security puts a file in the directory and ESP reads it in to script that would issue PASSWORD using variables found in the file, then delete the file.  The idea is that the password could get changed before the next run of a job.

Our organization is in the process of adopting PasswordVault by CyberArk, which adds some additional complexity to this.  We are currently working with their APIs that will supposedly allow us to do this at the job (script) level. 

I've wanted to keep everyone updated on our progress, and now that this thread has been started, perhaps I will use this one for that purpose.

Jonathan

Thanks Johnathan. So in your solution, someone has to put a file in the directory that is being watched? Would that be done automatically or does someone have to kick off a job?

In other words, how does something or someone know to do that?

If this is going to be a problem for a lot of customers, I would think CA would need to address this somehow.

The idea was that Security would place the file whenever the password was changed.  This would cause either JCL+REX or ESPimi to issue PASSWORD command with the variables from the file. 

In fact, I have sample JCL+REX that Don Powell provided, if you are interested. 

This solution was "shot down" by our Security staff because they felt that means the password would get "passed" (i.e. written to the file) in the clear.  That's why we are investigating placing this burdon on the developers by having them call the API's, and get the password information on their own, taking the burden off of us.