When the Workload Automation AE $AUTOUSER directory (default: /opt/CA/WorkloadAutomationAE/autouser.$AUTOSERV) is owned by a user ID (UID) from LDAP or Active Directroy, the following error is produced during startup:
"CAUAJM_W_10559 Unable to set groups: Success"
Example:
# unisrvcntr start CA-WAAEWAAE Agent (WA_AGENT) [ OK ]Executed waae_agent-WA_AGENT start...............................OKWAAE Application Server (PRD)
CAUAJM_W_10559 Unable to set groups: Success [FAILED]Executed waae_server.PRD start...................................FAIL 1Skipping CA-WAAEWAAE Scheduler (PRD) Scheduler started.CAUAJM_W_10559 Unable to set groups: Success [FAILED]Executed waae_sched.PRD start....................................FAIL 1
Similarly, the Workload Automation AE commands executed by a user ID (UID) from LDAP or Active Directroy would fail with error "CAUAJM_E_10106 Failed to determine currently logged in user."
Example:/opt/CA/WorkloadAutomationAE/autouser.PRD > chk_auto_up______________________________________________________________________________CAUAJM_E_10106 Failed to determine currently logged in user.CAUAJM_E_10004 Error retrieving current user and machine.CAUAJM_E_50034 Unable to get event server information______________________________________________________________________________CAUAJM_E_10106 Failed to determine currently logged in user.CAUAJM_I_50042 Cannot check the status of the Scheduler because the Event Server(s) is not available______________________________________________________________________________
Environment:
CA Workload Automation AE R11.3.x on LINUX systems configured with System Security Service Daemon (SSSD) to retrieve and authenticate user information and from LDAP/Active Directory.
Release: ATSYHA99000-11.3.6-Workload Automation AE-High Availability Option
Component:
On a UNIX or Linux based system, the aforementioned errors mean that the getpwuid()/getpwuid_r() system call failed and did not return the user information.
Explanation:
The getpwuid()/getpwuid_r() function shall search the password database (e.g., the local password file /etc/passwd, NIS, and LDAP or Active Directory) for an entry with a matching user ID (uid). The search is in the order of sources for passwd specified in the /etc/nsswitch.conf file.
To confirm if SSSD is being used for Name Service Switch, lookup the passwd and group entries in the /etc/nsswitch.conf file. If you see the following, then SSSD is in use:
passwd: files sssgroup: files sss
Likewise, for PAM authentication using SSSD, lookup the /etc/pam.d/system-auth file (Redhat) or /etc/pam.d/command-* files (SuSE). If you see entries similar to the following, then SSSD is in use:
auth sufficient pam_sss.so use_first_pass
account [default=bad success=ok user_unknown=ignore] pam_sss.sopassword sufficient pam_sss.so use_authtoksession sufficient pam_sss.so
Solution:
To check if 32bit SSSD client module is installed, execute the following commands:
Redhat: rpm -qa | egrep sssd-client.*\.i[0-9]{3}$
Example:
# rpm -qa | egrep sssd-client.*\.i[0-9]{3}$sssd-client-1.9.2-129.el6.i686
SuSE: rpm -qa | grep sssd-32bit
Example:
# rpm -qa | grep sssd-32bitsssd-32bit-1.9.4-0.12.24
To check if the libraries are 32-bit:
# file /lib/libnss_sss.so.2
# file /lib/security/pam_sss.so
Example:
# file /lib/libnss_sss.so.2/lib/libnss_sss.so.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped# file /lib/security/pam_sss.so/lib/security/pam_sss.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
It is recommended that the LD_LIBRARY_PATH is updated in the /etc/profile file so that the setting is available to all users.
The following commands export the LD_LIBRARY_PATH variable to include /lib and /lib/security directories.# LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/lib:/lib/security# export LD_LIBRARY_PATH