[SOLVED] Set up CWA 6.3 - cannot log in - not authenticated

[george.nussbaum]

Hello,

We are using a demo of CWA 6.3.  We set it up using AD authentication.  We go to the http://fqdn:8080/tesclient and launch the java workload automation window.  When we try to log in with the super user we get:

"java.lang.Exception: unauthorizeduser" - this was using the username "name@domain"

When just trying the username we get "User not authenticated!"

Any ideas what we are doing wrong here??

This is on a 2012 R2 server pointing to a SQL server 2014 DB.

[Tyler Theobald]

<domain>\<username>  works for us

[george.nussbaum]

Thanks for the advice but we still get "java.lang.Exception: unauthorizeduser" when using <domain>\<username>

[Tyler Theobald]

Sounds like your CM or master props may not have your AD/LDAP mapped correctly.  You could open a case with Cisco to help diagnose the problem.

[Tyler Theobald]

There is also a bug around authentication with users in multiple AD groups, and TES adapter configuration.   That bug was fixed in the Jan 31 6.3 hotfix - Maybe you are hitting that.

[opsteamprod1]

You may just need to preface the login ID with your domain.  domain\userid

[george.nussbaum]

I see this in the master log:

LoginModule: Failed to connect to LDAP Server [FQDN:389] or query LDAP Server for user attributes and/or group information javax.security.auth.login.LoginException: User does not exist in any Domain.

and

02/17 15:22:31:747[326:RpcServer Session]: (mem=1526507056/2058354688) ServerNode: Unable to authenticated user with error User does not exist in any Domain

[Robert Gardner]

The java client does not support SSL connection to the master.  You mentioned the https://fqdn:8080/tesclient in your url to launch the java client.

There is an open enhancement bug (CSCup85170) for SSL and the java client to the master.  This bug is currently postponed.

Currently only SSL between the master and client manager along with the web browser to client manager.

You should open a TAC case requesting SSL for the java client to master.

If this was a typo and you are not trying to use https then you may have a configuration issue in the master.props with the LDAP/AD configuration.

Either way open a TAC case if you need further assistance.

[george.nussbaum]

Hi Robert,

Thanks for replying.  You are correct.  The "https" was indeed a typo, so we'll investigate more into the master.props although I'm sure the AD section is correct. Oddly, when trying the LDAP option we can't even get the service to start.

[george.nussbaum]

We found the issue.  It was a database issue.  We put in some wrong info so the tables were wrong.

[tickermcse76]

Can you please elaborate on specific table and settings?  We are seeing a similar issue.

[PSP Production]

For us, the problem was in the usrmst table. Our domain was listed as contoso.com, which led to the user being unable to be authorized, since we were logging in with contoso\user to be able to authenticate with the AD.

Changing the domain to Contoso in the usrmst table fixed the issue.