search cancel

Product related userids for AutoSys in EEM

book

Article ID: 239118

calendar_today

Updated On:

Products

CA Workload Automation AE

Issue/Introduction

How to identify all service accounts within EEM that are included with the product and ancillary products?

This is for a security review, does not include service accounts that are in Active Directory or part of unix/linux domains.

Environment

Release : 11.3

Component : WA AE/AUTOSYS RELATED EEM

Resolution

General info:
If you install EEM on its own the only user in EEM itself is eiamadmin.
If you install AE it does not create any additional ids in EEM.
If you install WCC then it creates the following internal users in EEM:
 ejmexec
 ejmoperator
 ejmadmin
 ejmsupervisor
 ejmcommander
 ejmscheduler
If you toggle EEM to use LDAP then those ids are essentially disabled/orphaned.
They will not be seen by EEM as it would only see the ids you are pointing to 
via your LDAP connection.

When you perform an export from the EEM UI or safex and select global users
if your EEM's user store is set to LDAP then the export will NOT contain 
any internal users.  

And the same holds true the other way... 
if your EEM is in internal user store mode the and you select to export users
then you will only see internal users, no ldap users will be listed.

The above is regarding the users' definitions/settings.

if the user is an internal user then you will see something like this
<GlobalUser folder="/" name="localwccuser">
<UserName>localwccuser</UserName>
<PasswordDigest>{SHA512}A+99S8TXV0/Jaag6lGWO5XpK9uc4+/ooBayxdbyaWOlVKS8v9b1mQdi/iHnDInfuEwf9QsGzjvfCjJSzevMtQQ==</PasswordDigest>
<PasswordChangeDate>1649097866</PasswordChangeDate>

If the user is in LDAP then you will see something like this:

<GlobalUser folder="/Users" name="wilma flintstone">
<UserName>wilmaflintstone</UserName>
<FirstName>wilma</FirstName>
<LastName>flintstone</LastName>
<DisplayName>wilma flintstone</DisplayName>
<GroupMembership>Access Control Assistance Operators</GroupMembership>
<GroupMembership>Administrators</GroupMembership>
<GroupMembership>Commander</GroupMembership>
<GroupMembership>Domain Admins</GroupMembership>
<GroupMembership>Enterprise Admins</GroupMembership>
<GroupMembership>Group Policy Creator Owners</GroupMembership>
<GroupMembership>Remote Desktop Users</GroupMembership>
<GroupMembership>Schema Admins</GroupMembership>
<GroupMembership>autosysgroup</GroupMembership>
<GroupMembership>flintstone</GroupMembership>
<GroupMembership>saAutosys456</GroupMembership>
<GroupMembership>sysAutosys456</GroupMembership>
</GlobalUser>

The key difference being that the internal user contains 
<PasswordDigest>
<PasswordChangeDate>
while the LDAP user does not
NOTE - if the user has no password but is internal it still will have 
<PasswordChangeDate> set when the user was created.

If you used the dxdumpdb command to dump the entire EEM db then you will see 
both internal and external users (as long as the external users have some 
direct application group setting associated to them)

Example of one internal user vs one ldap user from dxdumpdb:

dn: cn=localwccuser,cn=Users,cn=Entities,cn=iTechPoz
objectClass: pozObject
cn: localwccuser
pzCreateTimestamp: 20220404184426
pozClass: O_E_U
pzUserName: localwccuser
pzDisableDate: 0
pozId: 7df2c0bc56cd4d3a14ce462fb3744ddc-61fc024b-500e9740-4e9cb
pozLink: cn=localwccuser, cn=Users, cn=Entities, cn=iTechPoz
pzModifyTimestamp: 20220404184426
pzOverridePasswordPolicy: false
userPassword: {SHA512}A+99S8TXV0/Jaag6lGWO5XpK9uc4+/ooBayxdbyaWOlVKS8v9b1mQd
 i/iHnDInfuEwf9QsGzjvfCjJSzevMtQQ==
createTimestamp: 20220404184426.744Z
creatorsName: cn=PozAdmin,cn=Admins,cn=Entities,cn=iTechPoz
pzEnableDate: 0
pzChangePasswordNextLogin: false
pozGeneration: 1
pozLocation: /iTechPoz/Entities/Users
pzIncorrectLoginCount: 0
pzPasswordChangeDate: 1649097866
pzPasswordDigest: {SHA512}A+99S8TXV0/Jaag6lGWO5XpK9uc4+/ooBayxdbyaWOlVKS8v9b
 1mQdi/iHnDInfuEwf9QsGzjvfCjJSzevMtQQ==
pzPasswordExpireTime: 0
pzPasswordTimeToWarn: false
pzSuspended: false
pzSuspendedDate: 0

dn: cn=wilmaflintstone,cn=WorkloadAutomationAE,cn=Store,cn=iTechPoz
objectClass: pozObject
cn: wilmaflintstone
pozId: f563f963a66f1539b6d2c20bbf08197-61fc024b-500e9740-4e9e0
pozClass: O_D
creatorsName: cn=PozAdmin,cn=Admins,cn=Entities,cn=iTechPoz
pzGroupMembership: WorkloadAutomationAEAdmin
pzGroupMembership: WorkloadAutomationAEWebService
pzModifyTimestamp: 20220404185951
pzCreateTimestamp: 20220404185951
pozLocation: /iTechPoz/Store/WorkloadAutomationAE
pozLink: cn=wilmaflintstone, cn=WorkloadAutomationAE, cn=Store, cn=iTechPoz
pozLabel: WorkloadAutomationAE
createTimestamp: 20220404185951.396Z
pozGeneration: 1

Again, the internal user has things like userPassword while the ldap user does not.

As for usernames in policies themselves, there is nothing specific in the exports
that would provide details that would show you if the user was internal or from LDAP.

exported policy excerpt :

 <Policy folder="/" name="WWW">
  <ResourceClassName>as-appl</ResourceClassName>
  <PolicyType>policy</PolicyType>
  <Disabled>False</Disabled>
  <ExplicitDeny>False</ExplicitDeny>
  <PreDeployment>False</PreDeployment>
  <RegexCompare>False</RegexCompare>
   <Identity>wilmaflintstone</Identity>
   <Identity>localwccuser</Identity>
 </Policy>