Invalid username/password prompt shows up even though credentials are valid

[szelenka]

TITLE

Invalid username/password prompt shows up even though credentials are valid

SYMPTOMS

When attempting to authenticate to Jabber, you get an error message stating your username/password is invalid.  Further, if you attempt to use the same credentials to authenticate to the Cisco Unified Presence User Options page, it will hang indefinitely and not return any error message.  However, if you use the same credentials to authenticate to the Cisco Unified Communications Manager User Options page it will succeed.

ENVIRONMENT

Cisco Jabber 9.0.1

Cisco Unified Communications Manager

Cisco Unified Presence

Microsoft Active Directory over SSL

CAUSES

Because the integration to AD is over SSL, this requires both the CUCM and CUPS server to have a valid copy of the AD servers security certificate.  Without the security certificate in both the CUCM and CUPS certificate store, those servers will not be able to verify the connection, and it will timeout and fail.  In this scenario, the CUPS server does not have a vaild copy of the AD servers security certificate.

RESOLUTION

1. Verifty the LDAP server configured in CUPS
2. Download the LDAP server security certificate according to its product documentation
3. Upload the certificate in Cisco Unified OS Administration > Security > Certificate Management
4. Restart the Cisco Tomcat service (utils service restart Cisco Tomcat)
5. Relaunch the Jabber application, and attempt to authenticate with the same credentials again

PREVENTION

Verify server configuration according to documentation on Cisco.com

RELATED TOPICS

http://www.cisco.com/en/US/docs/voice_ip_comm/cups/8_6/english/install_upgrade/deployment/guide/dgldap.html#wp1086101

[djr123games]

Hi All,

After searching CCO for a issue I am seeing, this thread is very close,

Can anyone help wih below?

Does Jabber/CUPS have a maximum password policy seperate from LDAP?

I have experienced this same issue but only affecting 1 user , This user has a password with 19 characters :-()

Jabber client works with other users accounts on his pc, and user is able to log into cucmuser.

We are using LDAP authentication, connected to 3 AD's all valid and working?!

Thanks

[Jonathan Els]

I have a similar issue to the above - only affecting limited users

Login to ucmuser - successful

Login to cupuser - successful

Login to Jabber for Windows - fails with username/password error

AD integration not over SSL.

[musamakhan]

Okay I had the same issue. Did every thing mentioned in several forums across internet. In the end found out the users were UNASSIGNED in cups server. Run the diagnostic test. You will see the issue and there is a FIX link next to it. Click the FIX link and you can choose the users and assign them to the cups server.

[David Little]

Thanks for that pointer in the right direction we were just about to put in a TAC case.. this is what we found.

Under Cisco Unified IM and Presence Serviceability: Tools | Network Features

Check to see if the Cisco XCP Sync Agent is running.  Ours was not.  Why it affected 2 users and not others is still a mystery but once started we waited a bit and tried the user again they were able to log in.

Thanks!!

PS another site also suggested which we had done was to Restart the Cisco XCP Authentication Service which we had done as well prior to the above.

[issofunky]

I saw a SIMILAR situation in 10.6 and 11.5 : 

in one case LDAP service account was locked out (TAC tracked to a known bug in 10.6....ick)

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuu01267/?reffering_site=dumpcr

in 11.5, We ran into a reported scenario defy logic:

user already signed into CSF would get "invalid username or password" when clicking on Voicemail....even though their password is SAVED (correctly) and their LDAP account was CERTAINLY not locked out...and the SERVICE account was certainly not locked out.

We TAC'd it and the cause was tracked to the Unity (9.1.2) system and UCCX (9.0.2) appearing to reject new connections. We pulled Detailed traces from RIS/Tomcat/VMRest.....and had very little success getting any further than just a guess.

   Restart of RIS, / VMREST and CuCsMgr seems to have solved it:

       but it was a hard problem to recreate and event TAC states clearly that they are guessing.

We noted some Core's on the UCCX,  and the Backtrace on them were approx. USELESS:

...etc

====================================
 backtrace
===================================
 #0  0x006fd266 in ?? ()
====================================
etc...

  ====================================
 backtrace
 ===================================
 #0  0x00131fdf in ?? ()
 ====================================