Jabber for Windows Login Fails - "Wrong username/password" with correct credentials

[Jonathan Els]

• CUCM - System version: 9.1.1.20000-5 Unrestricted
• CUCM IM & P - System version: 9.1.1.20000-5
• Jabber for Windows - app-ver:9.2.4.4528
• AD Integration - Connect to GC - Not Over SSL

Scenario:

• Login to /ucmuser - Successful
• Login to /cupuser - Successful
• Login to Jabber for Windows Client - FAILS
• Login is over AnyConnect VPN, but this may be unrelated.  Will test on site and verify asap.

Background Information:

1. This was working 100% prior to a password expiration and password reset. 
2. This is only impacting a limited number of users. 
3. Tested on multiple machines where users have been able to authenticate with different accounts - All authentication with user fails.

Problem Report indicates:

[JabberWerx] [IMPStackCap::Log::log] - [LoginMgr.dll]: CLoginCup::OnLoginFailed, -1, Wrong username/password

[JabberWerx] [IMPStackCap::Log::log] - [LoginMgr.dll]: CLoginContext::ChangeState now:0 auto:0

[plugin-container] [loadplugin] - Successfully loaded plugin Plugins\TelephonyPlugin\TelephonyPlugin.dll

[JabberWerx] [IMPStackCap::Log::log] - [LoginMgr.dll]: conn, canceled due to no needs. supposed:0, signning-on:0, signed-on:0

[JabberWerx] [IMPStackCap::Log::log] - [LoginMgr.dll]: login, OnError, 9

[JabberWerx] [IMPStackCap::Log::log] - [JabberWerxCPP.DLL]: JWLoginSink::OnError, lerr:9

[csf-unified.imp.Login] [IMPStackCap::Login::OnLoginError] - ****************************************************************

[csf-unified.imp.Login] [IMPStackCap::Login::OnLoginError] - OnLoginError: LERR_CUP_AUTH: <9>. data: 0

[csf-unified.imp.Login] [IMPStackCap::Login::OnLoginError] - ****************************************************************

[csf-unified.imp.Login] [IMPStackCap::LoginErrortoErrorCode] -  LoginErrortoErrorCode: 9

[csf-unified.services.system.CredentialsManager] [CredentialsManager::GetCredentialsImplForService] - Found credential object associated with the Authentication Service: Presence

[csf-login-event-listener] [LoginEventListener::OnLoginError] - LoginEventListener::OnLoginError: errCode: AuthenticationFailure

[csf-unified.imp.PresenceAdapter.LifeCycle] [LifeCycle::OnAuthenticated] - LifeCycle::OnAuthenticated: false

[csf-unified.imp.PresenceAdapter.SignOnState] [SignOnState::markAuthenticated] - markAuthenticated

[csf-unified.imp.PresenceAdapter.SignOnState] [SignOnState::isComplete] - isComplete: 0

[csf-unified.imp.PresenceAdapter.SignOnState] [SignOnState::markAuthenticated] - markAuthenticated exit

[csf-unified.imp.PresenceAdapter.LifeCycle] [LifeCycle::OnAuthenticated] - LifeCycle::OnAuthenticated exit

[csf-unified.imp.PresenceAdapter.LifeCycle] [LifeCycle::OnSignOn] - Event received: OnSignOn: false

[csf-unified.imp.PresenceAdapter.LifeCycle] [LifeCycle::OnSignOn] - OnSignOn failed while in starting state...

[services-dispatcher] [ServicesDispatcher::enqueue] - ServicesDispatcher.enqueue: UpdateServerHealthStateTask

[csf-unified.imp.PresenceAdapter.LifeCycle] [LifeCycle::setCapabilities] - IMP LifeCycle::setCapabilities: false

[services-dispatcher] [ServicesDispatcher::enqueue] - ServicesDispatcher.enqueue: class CSFUnified::CapabilityEnablerHandler [03F284F8]

[csf-unified.imp.PresenceAdapter.LifeCycle] [LifeCycle::setCapabilities] - IMP LifeCycle::setCapabilities exit

[csf-unified.imp.PresenceAdapter.LifeCycle] [LifeCycle::OnAuthenticated] - LifeCycle::OnAuthenticated: false

[csf-unified.imp.PresenceAdapter.SignOnState] [SignOnState::markAuthenticated] - markAuthenticated

[csf-unified.imp.PresenceAdapter.SignOnState] [SignOnState::markAuthenticated] - markAuthenticated exit

[csf-unified.imp.PresenceAdapter.LifeCycle] [LifeCycle::OnAuthenticated] - LifeCycle::OnAuthenticated exit

[csf-unified.imp.PresenceAdapter.SignOnState] [SignOnState::markSignedOn] - markSignedOn

[csf-unified.imp.PresenceAdapter.SignOnState] [SignOnState::markAuthenticated] - markAuthenticated

[csf-unified.imp.PresenceAdapter.SignOnState] [SignOnState::markAuthenticated] - markAuthenticated exit

[csf-unified.imp.PresenceAdapter.SignOnState] [SignOnState::isComplete] - isComplete: 1

[csf-unified.imp.PresenceAdapter.SignOnState] [SignOnState::markSignedOn] - markSignedOn exit

[csf-unified.imp.PresenceAdapter.LifeCycle] [LifeCycle::OnSignOn] - OnSignOn exit

[csf-unified.imp.Login] [IMPStackCap::Login::OnLoginError] - OnLoginError exit

Appears similar to:

• https://supportforums.cisco.com/thread/2249013
• https://supportforums.cisco.com/thread/2212276

I have attempted deleting the following without any success:

C:\Users\username\AppData\Roaming\Cisco\Unified Communications

C:\Users\username\AppData\Local\Cisco\Unified Communications

Problem Report is attached.  Any suggestions appreciated!

[Jonathan Els]

Having reviewed the following trace guide for Jabber (excellent guide):

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/im_presence/deployment/9_1_1/CUP0_BK_D5B4C107_00_deployment-guide-for-imp-91/CUP0_BK_D5B4C107_00_deployment-guide-for-imp-91_chapter_010100.html#CUP0_RF_IB3350DE_00

I reproduced the issue again, and the following log showed results:

Service	Trace Log Filename
Cisco Client Profile Agent (CPA)	/tomcat/logs/epassoap/log4j/EPASSoap*.log

At the affecting timestamp, I've noticed this:

2014-02-19 20:35:15,175 INFO  [http-bio-443-exec-15] soap.SoapServlet - SOAP request URI: /EPASSoap/service/v80

2014-02-19 20:35:15,178 INFO  [http-bio-443-exec-15] soap.SoapServlet - SOAP request for: login, version: v80

2014-02-19 20:35:15,179 INFO  [http-bio-443-exec-15] handlers.LoginHandler - prelogin:queryString=EXECUTE PROCEDURE ucSOAPPreLogin('a-ElsJo@eskom.co.za','MWPCUP-PUB','172.17.5.60','MWPCUP-PUB.eskom.co.za');

2014-02-19 20:35:15,196 WARN  [http-bio-443-exec-15] handlers.LoginHandler - preLogin:PRELOGIN reasoncode=FAILURE. User either not CUP licensed or not found in database

2014-02-19 20:35:15,196 INFO  [http-bio-443-exec-15] handlers.LoginHandler - process:Created session info for userid:a-ElsJo@eskom.co.za| cType:CUPC| client-version: 9.2.4.4528 | force:true | auth-type:USERNAME_PASSWORD

2014-02-19 20:35:15,196 INFO  [http-bio-443-exec-15] handlers.LoginHandler - process:Client requires version check, minVersion is :7.1.0.0

2014-02-19 20:35:15,197 WARN  [http-bio-443-exec-15] handlers.LoginHandler - Process: Failure

What I can note here is that the LDAP sync is on SAMAccountName.

For a login to /cupuser:

• a-ElsJo@eskom.co.za - FAILS
• a-ElsJo - Successful

I've tried the userid only, and through VPN I'm hitting a different issue entirely - another days fun...  It appears that I'll need to go on site to test.

Can anyone please advise what I should be expecting for a 2x3 scenario matrix of:

• VPN Client Login - UPN Login
• VPN Client Login - SAMAccountName Login
• LAN Client Login - UPN Login
• LAN Client Login - SAMAccountName Login
• /cupuser Login - UPN Login
• /cupuser Login - SAMAccountName Login

Thanks again.

[vartakdinesh]

I have recently seen the exact same error - for us it was Jabber 9.6 on Apple IOS devices.

CUPS is deployed in Active-Active mode, so, it should not matter which CUPS server the user is assigned.

However, in my case, it did matter - Cisco TAC asked me to assign the user to the second server in the CUP subcluster and it worked fine. Assigning the user back to the original CUPS node and it continued to work fine.

The 2 CUPS servers were configured via the CUCM end-user's UC service profile.

Cisco's explanation was that CUPS thought the user was not licensed on that node - no other explanation has been offered so far. Attempts to reproduce the issue have been futile.

I am still waiting on Cisco to provide an explanation/root-cause.

[Jonathan Els]

Hi

The issue you describe is similar, but unrelated, to what I experienced.  I confirmed that manually assigning the user to any of the 6 nodes in our cluster resulted in the same error.

I logged a case with TAC, and we managed to resolve this after some detailed investigation.  After going on-site and generating a new Problem Report, I noted the following prior to the login failure:

 [JabberWerx] [IMPStackCap::Log::log] - [LoginMgr.dll]: .\LoginState.cpp(2317):  CLoginCup::OnOneTimePasswd, ASSERT(! "'Presence.Domain' is  empty. we're not able to proceed to login.") failed!

This appeared to be the result of a corrupted DB entry on the presence server.  The user lookup LOCAL to IM and P server did return an expected result, and a result of this filed to populate the user detail back to the Jabber 4 Windows client.

The steps to resolve were to manually delete the user from IM and P server, then re-sync with CUCM with a service restart:

1. Run from CLI - run sql delete from enduser where userid='<userid>’
2. Restart Cisco Sync Agent service on CUCM IM and P PUBLISHER
3. Re-sync user details from CUCM

The user was immediately able to login to the Jabber client after completing this process.

PLEASE NOTE:

• When the Sync Agent service was restarted, the user detail was re-added to the IM and P cluster, but WITHOUT license capacilities.  As a result, I ran "mod" on the CUCM user page to re-sync the information
• When performing this process, ALL user data is removed from IM and P cluster.  I would recommend exporting the user data before beginning, and importing after re-syncing the user account to IM and P cluster

I confirmed after the TAC case that this procedure is TAC supported.

[Frank Perkins]

We had issues with Jabber for Windows not authenticating properly also in certain cases, when it was using a Active Directory synced user. In our case:

Username was typed in as John.Smith in the Jabber login window

Password was password

All credentials correct, but would not log in, or it did log in but could not active softphone et al.

Took a look in Active Directory and the account name was configured as john.smith

Using john.smith and password in the Jabber login window will authenticate and / or solve client issues

May not be the same issue, but worth a try and make sure your account login in AD is the same as you are using in the Jabber client respecting lowercase / uppercase.

[Jonathan Els]

Not the case with my issue (I tested this as well as AD userid was CamelCase as well), but thanks for the heads-up.

Issue has already been resolved as per my previous update.