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-WAAE
WAAE Agent (WA_AGENT) [ OK ]
Executed waae_agent-WA_AGENT start...............................OK
WAAE Application Server (PRD)
CAUAJM_W_10559 Unable to set groups: Success
[FAILED]
Executed waae_server.PRD start...................................FAIL 1
Skipping CA-WAAE
WAAE 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 sss
group: 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.so
password sufficient pam_sss.so use_authtok
session 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-32bit
sssd-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