Users see inconsistent access related to their jobs.
Article ID: 199713
Updated On:
Products
CA Workload Automation AE - Business Agents (AutoSys)
CA Workload Automation AE - System Agent (AutoSys)
CA Workload Automation AE - Scheduler (AutoSys)
Workload Automation Agent
CA Workload Automation AE
Issue/Introduction
UserX would have access to jobX one day and then lose it the next.
Environment
Release : 11.3.6
Component : CA Workload Automation AE (AutoSys)
Resolution
The environment was configured with two EEM servers but the EEM servers' multi-write/trust was broken some time ago.
As a result the EEM policies in the two EEM servers were not equal leading to inconsistent allow/deny results.
To resolve the issue:
Re-establish EEM in multi-write mode.
Re-generate the EEM certificates for Autosys and WCC.
pre-req variables:
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-identity-and-access-management/ca-embedded-entitlements-manager/12-6/configuring/failover-configuration/failover-configuration-prerequisites.html
Remove secondary from primary and reset primary:
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-identity-and-access-management/ca-embedded-entitlements-manager/12-6/configuring/certificates-with-custom-key-length-for-ca-eem-server/generate-certificates-with-custom-key-length-for-ca-eem-servers-in-failover-or-cluster-environment/remove-secondary-ca-eem-servers-from-primary-ca-eem-server-and-reset-primary-ca-eem-server.html
Reset primary on shadow:
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-identity-and-access-management/ca-embedded-entitlements-manager/12-6/configuring/certificates-with-custom-key-length-for-ca-eem-server/generate-certificates-with-custom-key-length-for-ca-eem-servers-in-failover-or-cluster-environment/reset-the-secondary-ca-eem-servers.html
Make sure each EEM works independantly.
Login, check some policies etc...
Then re-establish the EEM multi-write configuring primary and shadow:
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-identity-and-access-management/ca-embedded-entitlements-manager/12-6/configuring/failover-configuration/how-to-set-up-a-failover-environment/configure-a-primary-server.html
TEST your EEM multi-write.
Create a policy in host1 and confirm it gets replicated to host2.
Then update that policy in host2 and go back to host1 to confirm that change was replicated back.
Assuming that all the above works well...
After that is completed you should go into autosys_secure
->[2] Manage CA EEM security settings.
-->[1] Manage CA EEM server settings.
--->[2] Set CA EEM server location and regenerate certificate.
then enter the two eem hosts separated by a comma without any spaces
and enter the eiamadmin id/password and regenerate the certificate.
For WCC, follow the steps "Regenerate Security Certificates" at the following url:
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/intelligent-automation/workload-automation-ae-and-workload-control-center/11-3-6-SP8/installing/ca-wcc-installation/ca-eem-policy-migration/export-and-import-eem-policies-using-the-gui-wcc.html
NOTE - you only have to perform the autosys_secure steps on one autosys instance server as the eem details are stored in the database.
NOTE - if you have more than one autosys instance working with these EEM hosts then you would perform the autosys_secure on one host in each of the unique AUTOSERV configurations.
NOTE - you will need to perform the wcc steps (safex and moving of wcc.key and wcc.pem files) on each wcc host working with these EEM hosts.
As a result the EEM policies in the two EEM servers were not equal leading to inconsistent allow/deny results.
To resolve the issue:
Re-establish EEM in multi-write mode.
Re-generate the EEM certificates for Autosys and WCC.
pre-req variables:
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-identity-and-access-management/ca-embedded-entitlements-manager/12-6/configuring/failover-configuration/failover-configuration-prerequisites.html
Remove secondary from primary and reset primary:
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-identity-and-access-management/ca-embedded-entitlements-manager/12-6/configuring/certificates-with-custom-key-length-for-ca-eem-server/generate-certificates-with-custom-key-length-for-ca-eem-servers-in-failover-or-cluster-environment/remove-secondary-ca-eem-servers-from-primary-ca-eem-server-and-reset-primary-ca-eem-server.html
Reset primary on shadow:
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-identity-and-access-management/ca-embedded-entitlements-manager/12-6/configuring/certificates-with-custom-key-length-for-ca-eem-server/generate-certificates-with-custom-key-length-for-ca-eem-servers-in-failover-or-cluster-environment/reset-the-secondary-ca-eem-servers.html
Make sure each EEM works independantly.
Login, check some policies etc...
Then re-establish the EEM multi-write configuring primary and shadow:
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-identity-and-access-management/ca-embedded-entitlements-manager/12-6/configuring/failover-configuration/how-to-set-up-a-failover-environment/configure-a-primary-server.html
TEST your EEM multi-write.
Create a policy in host1 and confirm it gets replicated to host2.
Then update that policy in host2 and go back to host1 to confirm that change was replicated back.
Assuming that all the above works well...
After that is completed you should go into autosys_secure
->[2] Manage CA EEM security settings.
-->[1] Manage CA EEM server settings.
--->[2] Set CA EEM server location and regenerate certificate.
then enter the two eem hosts separated by a comma without any spaces
and enter the eiamadmin id/password and regenerate the certificate.
For WCC, follow the steps "Regenerate Security Certificates" at the following url:
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/intelligent-automation/workload-automation-ae-and-workload-control-center/11-3-6-SP8/installing/ca-wcc-installation/ca-eem-policy-migration/export-and-import-eem-policies-using-the-gui-wcc.html
NOTE - you only have to perform the autosys_secure steps on one autosys instance server as the eem details are stored in the database.
NOTE - if you have more than one autosys instance working with these EEM hosts then you would perform the autosys_secure on one host in each of the unique AUTOSERV configurations.
NOTE - you will need to perform the wcc steps (safex and moving of wcc.key and wcc.pem files) on each wcc host working with these EEM hosts.
Feedback
Yes
No
Powered by
