I have a test environment with a generic installation of WLA AE and WCC r11.3 running on the same Linux server. The EEM server is also Linux and runs a different server. For some reason when I sign on to the WCC with ejmcommander (or any other ejm* installed userid) and try to list a job in QEDIT (or any other app) I get an authentication error "E121103 Invalid user name and/or password". What might I have done in my generic installation to cause that? To make things worse, I've played around with the CRED app, and also autosys_secure and as_safetool to switch between Native Security and EEM security in an attempt to figure this out. How do I get WLA AE to allow access again to ejmcommander though WCC?
Is the E121103 error when you log on to WCC or when you look up a job in QEDIT/QVIEW?
Is your WAAE instance currently using EEM security or NATIVE (autosys_secure should tell)?
Is EEM configured with AD/LDAP or internal user store?
If AutoSys is using the same EEM as WCC, then credentials isn't required, it'd use artifacts to authenticate.
Are you able to Validate the WAAE server in WCC configuration successfully?
Are you able to validate the CRED user without any errors? This KB article might help w/ troubleshooting Credential user validation errors.
Regarding your questions:
1. I get the error when I look up a job in QEDIT. I can sign onto the WCC OK (as ejmcommander).
2. My WAAE instance is using EEM security.
3. By "Internal" do you mean the EEM is running on the same server as WAAE and WCC? The EEM service, though is running on another server. I am not using Active Directory or and LDAP server.
4. Yes, AutoSys and WCC both point to the same EEM. How do I use the artifacts to authenticate? Sounds simpler.
5. Yes, in the WCC, I can go to CONFIG and then select my WAAE in the Edit Server box. It is called "jobserver" in the Server Results box.
6. No, I can't do any user validation in the CRED box. I tried adding "autosys" and "autosys@<myserverdomain>" but I could never get it to validate.
BTW, excellent link to the KB article on troubleshooting validation errors. I test each step and failed in the section, 4. System Agent. I did the ./password <mypassword> creation step and compared it to what I found in the .joblog files. They matched, so I know I had the password correct (or think I do). However, when I proceeded to the ./chkusr step, I failed in ALL of the tests:
[autosys@uspnsvulx289 WA_AGENT]$ ./password <mypassword>Encrypted password: D647EBFAA37187AC[autosys@uspnsvulx289 WA_AGENT]$ ./chkusr autosys D647EBFAA37187ACAuthentication failure[autosys@uspnsvulx289 WA_AGENT]$ ./chkusr autosys D647EBFAA37187AC sshdAuthentication failure[autosys@uspnsvulx289 WA_AGENT]$ ./chkusr autosys D647EBFAA37187AC suAuthentication failure[autosys@uspnsvulx289 WA_AGENT]$ ./chkusr autosys D647EBFAA37187AC loginAuthentication failure
But that section stops there and doesn't tell me what to do when I have failed ALL of those test. So where do I validate that the user "autosys" exists and if it does, where do I update its password? I see "autosys@<myserverdomain>" listed in the WCC Configuration Manager under Monitor ID. Is that the same? I tried updating the Monitor Password and Saving but that didn't fix the issue.
I think I just fixed my own problem.
In WCC>CONFIG>Edit Server, I updated the 'Monitor Password' and checked the 'EEM Enabled' box (it was unchecked), and did a SAVE. Then I saw the Deploy section farther down on the CONFIG page and noticed that the 'jobserver' showed up there. I had not seen it there before. So I did a Validate on the 'jobserver' followed by a Deploy. Finally the WCC told me to restart some services.
After all that, I am able to search and list all of my jobs in WCC QEDIT while signed on as 'ejmcommander'. And when I select the Create... button in QEDIT it shows me options rather than a red logon error box.
Glad you sorted this out.
Yes, the artifact authentication is effective only when you select the EEM Enabled checkbox (ofcourse, AE has to be in EEM mode). Deploy option...has to be WCC release prior to 11.3.6, for the manual deploy was done away with in 11.3.6. I am still not sure why the chkuser fails for all 3 options (sshd, su, login). sshd could fail due to missing 32ibt pam libraries; su - maybe the user can't su directly, have to use sudo su, but login? I am out of ideas there.
About chkuser failures, you'll see the reason of the logon failure in the spool files of the System Agent
Look into the spool files of the Application Server application which are located into the ../spool/*APP*/* directory of the System Agent doing the validation.
This technical document should help as well:
Knowledge Base Articles