Petr Vlasek Feb 5, 2015 3:36 PMHello, 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.RegardsPetr
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.
Can somebody please explain to me why this is? CA has been telling us for months that EEM brings all our authentication for both WCC and Autosys together when they are both tied to EEM but this in fact is NOT the case. As the post above points out, there are 2 exceptions which are the Command Line tab in WCC and Forecasting.
We have been using WCC and EEM for some time. Recently we just went from native security with Autosys itself to EEM with the expectation of policy control which we do get but also a single point of authentication which we now clearly see is not the case. Our users are still needing to add their Unix LDAP accounts in the Credentials tab of WCC in order to use either the "Enterprise Command Line" tab or "Forecast" tab in WCC.
I am more frustrated by the fact that we spent half a day trying to find the exact cause for this but I could not find this information anywhere in CA docs. You would think that something like the very valuable information in the post above would be as a footnote on the CA docs explaining how to convert from native to EEM for Autosys.
So basically it boils down to the fact that EEM gives you control over your environment much better due to policies but authentication is not all there yet. Would that be a correct statement?
Hello, LRoberts, since the time I wrote my previous reply, the things have changed a bit. If you are using WCC 11.4 SP1 (and later) and Autosys 11.3.6 (and later) this has been enhanced and brings better user experience, thought not solved completely.
Because of the technical limitation of the architecture, the credentials are still being used to access the AE remote machine from WCC but they are no longer needed for running commands from Enterprise Command Line nor Forecast on that particular remote machine. This simple statement means a big change - you (i.e. administrator) can define one GLOBAL credential used for access to the AE machine. As the credential is defined as GLOBAL it is being propagated to all end users credentials and individual users doesn't need to fill any credentials - the GLOBAL one is used automatically behind the scenes. Additionally, all of the commands are being executed under the context of the WCC user - the GLOBAL credential is used only to open the remote connection to AE machine (and that is the only instance where it is needed), but not for executing of the commands from ECLI or Forecast - they are run on behalf of the user logged in to WCC.
So technically, WCC still needs non-EEM credential to access the AE machine, but it does not bother the end users, it is a single configuration step for administrator who defines this GLOBAL credential.
The only limitation here is that internal policies of your org have to allow you to have a single account for unix you can use as a GLOBAL credential.
The pre-requisities are:
- the versions (11.4 SP1+ for WCC, 11.3.6 for AE)
- AE and WCC using the same EEM (or the same failover cluster of EEM servers)
- EEM security is enabled in the AE server definition in WCC Configuration
- the AE version is properly set in the AE server definition in WCC Configuration.
Great information Petr!
We are on the latest and greatest for WCC, EEM, and Autosys. I highly doubt we would be willing to allow for one global account so it looks like we are stuck still having to use the credentials tab. At least now I have an understanding of why and in great deal! I really appreciate your posts! Thank you!
Hello, LRoberts, I am happy my answer was helpful for you, I am just sad to hear that the single global account is not an option for you. Just to clarify, anything regarding AE in this situation is completely transparent - the single global account is used only to login to the AE machine, not to the AE itself - i.e. all of the AE actions are made in context of the user logged in to WCC - please check the reply to Christri.1 message below.
Petr, please correct me if I am wrong and here is how I understand it.
The Global Credentials are necessary for the use of the CLI and Forecast. However, the Global Credential is used by WCC in the background and the job stream/machine/calendar/sendevent etc access is still controlled by those individual policies.
Which means, a "credentialed" User can only run a command from the CLI against the job stream that this User has the policy entitlements to and this also applies to the "forecast" .
Is this a valid understanding?
On that note, is there a plan to remove the need for the Global Credentials and allow entitled access to every facet of WCC from policies only?
The mechanics of the global credentials is a feature unique for WCC. It is a kind of "hierarchical" structure you can define in credentials. I mean, using global credentials, you can define a single credential that is being pushed for all users and unless they override it by their own credentials, it is used for them. So the global credentials are very useful when you have a single credential you can use for all users. As I mentioned in my previous post, you can use the global credentials with an advantage in the case when AE is using EEM - global credentials will allow you to define single credential globally which will be used to connect to the remote AE machine, but all AE commands are executed in context of the user logged in WCC.
So, for example, suppose AE is using EEM and WCC is using the same EEM as well. GLOBAL credential with user id Glob_User is defined by administrator in Credentials tab. User logged in to WCC is let's say Bob (i.e. the identity from EEM, or AD/LDAP via EEM). Bob did not define anything in his Credentials tab in WCC. Once Bob runs forecast or any command via ECLI, Glob_User account is used (it is GLOBAL credential pushed to Bob's credentials automatically) and it is used just to login to the AE machine (not to the AE itself). Any command (e.g. forecast) is ran under Bob's context, because EEM session token has been passed from WCC to AE along the way - you will see Bob in logs, events, etc. And in addition, it would follow respective AE policies defined in EEM.
I always felt that the credential should ONLY be entitlement not access. If i am logged into WCC and i run the CLI ... it should just look at my id and the eEM policy and not see if I have a login on the AS Server. This was an ask way back during 11.3 ...
If my memory is active the EP/AS server were to just check with eEM if that ID was allowed to run teh command. Nothing more. Being logged into a machine you are credentialed.
Hello Steve, the Credentials system is not convenient and even the UI itself is not very helpful in configuring everything correctly - but unfortunately, the need to define credentials is forced by the underlying architecture and with the changes in AE 11.3.6 and WCC 11.4 SP1 respectively (and supposed EEM is used for AE), the Credentials use might be limited to its very least scope - only to login to the AE machine. All the AE commands entered via ECLI are run on the AE side under the context of user logged in WCC.
I'll try to put some more detail into how the GLOBAL user works. When you issue a command from the ECLI or a forecast report, a request to run the command is send to the Command Sponsor on the application server machine you defined.The command will run as whatever the GLOBAL user is configured for. So, if you were to run a 'ps -ef' command, you would see the GLOBAL user listed. The difference is that the command is issued with anadditional parameter '-saml' with an one time use security ticket that represents the logged on WCC user. What this means is that the application server is doing the security check against the WCC user, NOT the GLOBAL user.So, for example if you were to run an autotrack report for the sendevent that was issued via WCC, you will see the WCC user, not the GLOBAL user.
The saml ticket is only valid for a short period of time and can only be used once, so any attempt to capture them is not going to allow a backdoor into AE.
So, this change allows you to simplify by not requiring lots of users to have access to your server machines and once you have the GLOBAL user defined, I would even recommend that you remove the credentials tab from your end users.
Thanks Michael! HUGE help!!!!!!!!
Hi,Can WCC append -saml parameter to my custom command that I configured in /opt/CA/SharedComponents/iTechnology/AutoSysCommandISponsorFilters.txt at the Command Sponsor end or the saml ticket can only be generated for pre-defined set of autosys binaries.
I need my custom script to authorize the actual WCC user in EEM first and then check the user belongs to a particular group in EEM and then allow or reject execution of the code in the script.