cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2033
Views
4
Helpful
23
Replies

Your username or password is not correct Jabber & Self Care Portal

dfmg
Level 1
Level 1

I have two users who are getting the "Your username or password is not correct" with Jabber and the Self Care Portal, despite verify that their credentials are correct.

For both of them:
The CUCM Service Profile has all of the required Services such including IMP.

The Service Profile is assigned to the user on the End User account.

On the End-User account all of the Service Settings boxes are checked including the Home Cluster checkbox.

The user is the Owner on the CSF Device configuration page, and the device is in the Controlled Devices of the user.

The DN on the Jabber client is listed as the Primary Extension on the End User account.

We are using AD Sync, and their AD account works fine.  I've attached the log file for one of the users.

 

 

23 Replies 23

Since Selfcare  is not functioning for the user experiencing issues, the problem does not lie within the Jabber configurations. Instead, it appears to be related to the user account itself, which is synchronized from Active Directory (AD). Here are some questions that come to mind:

  1. Does this user appear as an active LDAP-synced user on the CUCM End User page?
  2. Do these users belong to the same search base that you defined on the CUCM LDAP authentication page?


Response Signature


Hello Nithin,

The answer is yes to both questions, however, it does seem like an AD sync issue.  It's odd because the usernames seem to sync from AD to Cisco CUCM, but none of the new users we are adding are able to sign in for one of our domains.  It seems like the usernames get synced, but not the passwords.  There've been no configuration changes to my knowledge, but I'm working with another admin who has more access who can hopefully shed some light on the issue.

Passwords are actually never synced from LDAP to CM. It's used in real time against whatever authentication you define for the LDAP authentication.

image.png

Red arrow points to where you define the sync of user accounts and and green arrow points to where you define the authentication. These are two independent things.

image.png 

 



Response Signature


As Roger Kallberg pointed out in his  response, the password is never synchronized. It is not stored on the Cisco Unified Communications Manager (CUCM); instead, real-time authentication is performed. In this particular scenario, I suspect that the search base configured for LDAP authentication does not encompass these specific users. You might want to consider keeping the authentication at the domain level rather than restricting it to the organizational unit (OU).



Response Signature


dfmg
Level 1
Level 1

The issue for us is now resolved after our sys admin restarted the XCP Connection Manager and XCP Authentication Service on IMP nodes and restarted Cisco User Data Services on the CUCM Publisher and Subscriber.

Thank you for posting your solution! It is helpful to those who are searching later. It is okay for you to mark your own answer as the "Solution" to your problem, and please do so. That is helpful, too.

Maren

Hi,

We started noticing a different issue since our sys admin restarted the XCP Connection Manager and XCP Authentication Service on IMP nodes and restarted Cisco User Data Services on the CUCM Publisher and Subscriber.

For users with Desk Phones that just prior to this were able to use Jabber for Phone Control (to basically find a user click on them, then pick up their phone for the call) is now not working.  They have a red X on the phone icon in the lower left, and get message that connection to the phone service failed.  I'm thinking this is likely not a coincidence, and perhaps there's some other service that is having an issue.  Does anyone have any ideas?

The two services that comes to mind is Call Manager and CTI Services when it comes to phone control.



Response Signature


Regarding the phone control aspect, that issue was resolved after one of our sys admins rebooted our DCs this morning, so I thought I'd update for that too.