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:
insert_global_credential: SCHED
global_user_id: wccusr
global_user_pw: abc
...
insert_credential: SCHED
wcc_user_name: 'domain.lan\\Jim'
job_manager_user_name: Jim
(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.
Thanks.