Command line issues resolving users group memberships after EEM User store changes
Article ID: 220279
Updated On:
Products
Issue/Introduction
We changed our identities. Doing commands in WCC work but on the linux servers we are getting errors. see example.
sendevent -J eco23 -E FORCE_STARTJOB
CAUAJM_W_10425 Machine Execute Access Denied!
CAUAJM_W_10439 No policies granting access to resource.
CAUAJM_W_10440 Class: as-machine Resource: DEV.machine123 User: autosys Access: execute
CAUAJM_W_10442 Time: 1626363543 Delegator: None
Environment
Workload Automation AE (AutoSys)
Resolution
The environment previously had a single domain defined in EEM.
The policies made use of global groups granting the users the desired access.
Domain changes within the company are happening.
IDs are being moved from x to y etc...
As a stop gap multiple domains have been added to EEM's user store.
As a result EEM no longer sees "Paul" as just "Paul" it is seen as "TEST123.com/Paul".
Currently from WCC things are fine as adjustments were made to the policies to include prefixes for the global groups.
The problem occurs from a linux command line as by default the ID seen is just "Paul" and "Paul" no longer exists or is seen within EEM.
It needs the domain prefix so the group memberships can be resolved and they get the desired access.
NOTE - later EEM will be reconfigured back to a single basic ldap once all users have been moved.
You have multiple ways you could try to address the issue.
You could define "Paul" directly in a dynamic user group without any prefix and then use that dynamic user group in the policies.
Or you could use extra options on the command line to pass the desired userid including the domain.
Options:
-usr username -pw password
-usr username -pwx encryptedpassword
For details see:
https://techdocs.broadcom.com/us/en/ca-enterprise-software/intelligent-automation/workload-automation-ae-and-workload-control-center/11-3-6-SP8/reference/ae-commands/define-workload-objects/jil-command-run-the-job-information-language-processor.html
NOTE - Need to use qoutes around the ID so the backslash is not treated as an escape character.
Options going forward...
1) filters in policies where you would use where global group contains *--* and then the global group name.
2) setup dynamic user group policies, and then reference the global groups in those policies.
Then use the dynamic user group policies in the other AE and WCC policies.
Both the above would help reduce the amount of reconfiguration you would have to do should you again have to go thru domain changes.
Feedback
