Is the Credentials tab ignored for EEM-enabled WAAE servers in WCC?
We recently EEM-enabled our 11.3 SP1 WAAE server and have just finished adding it to a brand-new WCC 11.3.6 server. WAAE is running on Solaris 10 and WCC on Win 2008. For the purposes of the discussion I'll say the WAAE server is named SCHED and the AD domain is domain.lan.
When we added the WAAE server to WCC, we checked the EEM checkbox and everything was working great until we started to validate our EEM policies, at which point we realized that the values in the Credentials tab were no longer being applied.
The configuration we've been using prior to EEM was to define a _GLOBAL_ user in Credentials and to secure that userid in EEM by creating a Deny policy that prevented that userid from certain privileged operations like deleting jobs. We kept the default EEM as_job policy in place, so aside from that userid, there were no restrictions on user privileges. For the few users who needed the ability to delete jobs, we gave them access to the Credentials tab and had them plug in their own userid and password as it appeared in /etc/passwd on SCHED. If general user Bob force_started a job from WCC, autotrack would show that the job was force_started by wccusr@SCHED, and if Bob tried to delete a job, his attempt would fail. If privileged user Jim force_started a job (and had updated his Creds accordingly), autotrack would show that the job was force_started by Jim@SCHED. And if Jim tried to delete a job, he'd succeed.
If I were to run wcc_config -x, I would see something like:
(Bob wouldn't appear in the wcc_config output because he'd be using the global wccusr.
Now we have EEM and the plan was to continue using the Credentials tab until we had time to work out the full EEM policy.
The problem is that when Bob force_starts a job now, autotrack says the job was force_started by Bob@domain.lan. It ignores the global credential for wccusr.
And when Jim force_starts a job, autotrack says the job was force_started by Jim@domain.lan. It ignores the fact that Bob has reset his credential to Jim@SCHED.
If this is the new way of the world, that's fine. It will require us to hurry up on our EEM policy since right now the only restrictions apply to the wccusr ID, which seems to be getting bypassed. But we were planning to do this in a matter of weeks anyway.
But I don't see any documentation to that effect and would like to confirm that our environment is working according to spec. If Credentials is supposed to remain in force, I'll open a ticket with CA to find out what the problem is.
I should mention that I've compared the WCC and EEM configs to other WAAE instances and other WCC servers and everything checks out.
This is a nonprod environment.
Without all the info of your environment its hard to give a definitive answer, but based on what you've posted and some assumptions, I would say its working correctly.
You mentioned you are using EEM for WAAE now - is this EEM using an external User Store (e.g. Active Directory)? And if it is, are the (AD) accounts in the User Store valid across both your windows and solaris environments?
If both of these are in place then the set up becomes simplified and the need for Credentials should go away, provided your EEM policies for WCC and more importantly WAAE are in place.
I don't know how many jobs/users/groups you have, or how complex your environment is, but would consider disabling that default wide open as-job policy, copying it and using the copy to start building user/group specific as-job policies (also other policy types such as as-calendar, etc). If you are using Active Directory then you can consider using AD (Global) groups in your policies, the advantage being that once set up, if user Fred needs access to a set of WAAE objects then adding them to the right AD group is all that's needed.
Yes, EEM does use an Active Directory external store (in the example I'm calling it Domain.lan).
No, the AD accounts are not valid on the Solaris server. We've added a couple of userids to /etc/passwd that mirror the AD accounts, but any actions we take from the Solaris CLI are interpreted as being run by <userid@SCHED>, whereas actions we take from WCC are interpreted by EEM as having been run by <firstname.lastname@example.org>.
Interestingly, however, having valid users on the Solaris server does not appear to be a prerequisite for EEM to work, which surprised me. I asked a user Joe who doesn't exist in /etc/passwd to force_start a job from WCC and it ran successfully, even though the job lives on SCHED. autotrack shows that the job was force_started by Joe@domain.lan.
For the moment I have, just as you recommended, disabled the default as-job policy, copied it and removed Create and Delete from the copy, and created a third policy that allows only members of particular AD groups to perform those actions. That takes care of WCC, but Solaris is a little more trouble - I want to tell EEM that any users in a local SCHED security group can perform creates and deletes, but because EEM only understands Application Groups, Global (i.e., AD) Groups and Dynamic Groups (but not local Solaris groups), I had to make a dynamic group policy in which I explicitly added all the users (in the format SCHED\user). And then I added the dynamic group to my as-job policy.
It sounds like you are on the right track
As EEM is now pointing at Active Directory for external Users / Groups, local Solaris users/groups are out of the picture. This is one of the "features" of running AutoSys on Solaris but WCC/EEM on windows, where you are not fortunate enough have a single source of authentication for global users / groups that spans windows and unix.
If you have a reasonably small/static set of Solaris client users, setting up your Dynamic group and adding that to policies is IMO a reasonable approach. I don't know if you have looked at the Unauthenticated User Mode setting too, but may be more tricky and I don't believe it will help with security groups at all.
Hello, the behavior of WCC Credentials is determined whether Autosys is using EEM or native security - but WCC cannot determine it automatically; it is defined in WCC Configuration of particular Autosys instance by the "EEM enabled" attribute. The value of this attribute (checked/unchecked checkbox) tells WCC whether it should try to use EEM authentication to connect to the Autosys (this means, currently logged in user) or whether it will use native authentication which is driven by values in WCC Credentials.
So, in brief - if your Autosys definition in WCC has "EEM enabled" checked, WCC Credentials are ignored. There are only two exceptions where they are still used - WCC Enterprise Command Line and Forecast applications. Those two are using entries from WCC Credentials regardless the EEM is used by Autosys or not.
You sir our my hero! We spent half a day trying to figure out why after changing from native security to EEM that users could not use the Enterprise Command line. CA docs REALLY need major help.
I won't even get started on why CA would say EEM offers complete integration when this clearly shows that not to be the case. Thank you!