WCC- ECLI commands fail with 500 error. Message : Failed to logon using given credentials
search cancel

WCC- ECLI commands fail with 500 error. Message : Failed to logon using given credentials

book

Article ID: 216232

calendar_today

Updated On:

Products

Autosys Workload Automation

Issue/Introduction

The user xxusr is present on the domain as well as available as a local user on Linux

we can login to the server as xxusr and run autoflags -a and it works fine

The xxusr was added in the credentials tab and it validated fine as well

We also ran chkusr from agent with the xxusr and it returned "User and Password okay"

The ECLI still returns 500 error.

commandapp.log

2021-05-24 09:48:45,710 @ecli <      Thread-68> [] ERROR #WebServerCommandClientReq          # Server Error: 
com.ca.wcc.command.client.webserver.WebServerException: Failed to log on using the given credentials.
StatusCode: 500

Environment

Release : 12.0

Component : WORKLOAD CONTROL CENTER

Resolution

To isolate WCC we ran the AutoSysCommandWrapper from autosys/bin and observed that it was working fine when executed as root but not as the autosys user.

$ ls -l AutoSysCommandWrapper
-rwsr-xr-x. 1 root root 36352 Jun  8  2020 AutoSysCommandWrapper

The AutoSysCommandWrapper is owned by root user and has setuid. But autosys user is not able to switch the root suid.

set-user-ID bit that is set on AutosysCommandWrapper is not honored if the underlying filesystem is mounted with nosuid.

output of mount command shows that /opt filesystem is mounted with nosuid

/dev/sda3 on /opt type ext4 (rw,nosuid,nodev,relatime,seclabel,data=ordered)

The filesystem was remounted with suid using the following command 

mount -o remount,suid /opt

This resolved the issue

Additional Information

You refer to this redhat article.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/s1-nfs-client-config-options

  • nosuid — Disables set-user-identifier or set-group-identifier bits. This prevents remote users from gaining higher privileges by running a setuid program.

So it basically prevents the AutoSysCommandWrapper from running with root privilege.

 

When specifying a global credential to be used by the ECLI, that ID must be a valid account on the AutoSys server. The monitor ID only has to exist within EEM and does not have to be a valid local account on the AutoSys server. This is why you could run into a scenario where the monitor ID works fine but doesn't work if it is used as a global credential.

Additionally, check for passwords.  Passwords  ending with "\" may also cause issues.