CUPC DeskPhone Invalid Credentials

[tmoore]

I have an end users that when he tries to set his deskphone for audio get the error notifications

     Device Error. Invalid credentials [801]

The user is able to login to CCMUser on the CM and CUPS without an issue.  We are using LDAP Authentication and have changed the port to use 3268 and restarted CTIManager.  The wireshark  capture shows

     7.1.5.30000-1.Directory login failed - credential has been locked due to no activity

Since we are using LDAP authentication there is no option to unlock credential on the CM and the user is not locked in AD.  Any suggestions?

[Joseph Martini]

Usually the invalid credentials for CUPC deskphone control is due to missing digest credentials on on call manager's end user configuration page.  Even if you see ******* in the field set it to anything you want, it's all used behind the scenes between servers, save it, exit CUPC and log back in.  Let me know if that fixes it for you.  Also if you change the port to the global catalog like you have try restarting the Sync Agent on CUPS to make sure the change is pulled over too.

[tmoore]

Still no go,  I did restart the Sync Agent on CUPS after changing the LDAP port.  I aslo re-entered a digest credential for the user, it already did have ****** but I put in a new string and then restarted the Sync Agent Service but the user is still getting Invalid Credentials and Wireshark capture shows "credential has been locked due to no activity" when trying to use a deskphone.  The user has no issue using the CSF softphone.  I have loaded the latest CUPC v8 client but still can't this this one user to be able to use his deskphone.

[Joseph Martini]

Does this end user happen to have "User Must Change at Next Login" set on their AD account?  Is this only happening for one user?

[tmoore]

No he does not have the option checked under his AD account and this is only user that I'm aware of that is having this problem. We are just starting to deploy CUPC to our end users.

[Joseph Martini]

How's your database replication look on the call manager side?  You follow this to check, using the Cisco Unified Reporting Tool https://supportforums.cisco.com/docs/DOC-13672.

[tmoore]

The CM Replication status is 2 on the Pub and the Subs, doesn't look like there is an issue on the db.

[htluo]

1) This problem has nothing to do with Digest Credentials

Digest Credentials are used for SIP authentication only.  Desk Phone control has nothing to do with SIP.  It's CTI.

2) This problem has nothing do do with Database Replication.

The authentication is between CTIManager and LDAP.

3) This problem has nothing to do with "User Must Change Password On Next Longon".

If this had been enabled on LDAP, you won't be able to authenticate the CUCM/CUPC logon at all.  Since you could log onto CUPC, this is out of the picture.

Ok, then what was the problem?  It's the caveat on CTIManager when using LDAP authentication.  Many people said they had change the port to 3268 and restarted CTIManager.  However, what really happened was:

1) They change the port number on the wrong place.  It's should be at "CUCM > System > LDAP > LDAP Authentication" instead of "CUCM > System > LDAP > LDAP Directory".

or

2) The restarted the CTIManager on the wrong box.  Make sure you restarted the one CUPC was using for Desk Phone control.  If you are not sure which one, restart CTIManager on every box in the CM cluster.

Michael

http://htluo.blogspot.com

[tmoore]

The LDAP port was changed in the correct location, actually we have it set to port 3268 in both locations.  I restarted CTIManager on our 3 CM and restarted the UP Sync Agent on the CUPS.  But this users is still failing with Invalid Credentials and Wireshark capture shows "credential has been locked due to no activity" when trying to use a deskphone.

[htluo]

Where the packet capture was taken?  From the client PC or from the CUCM (CTIManager)?

We need the one who's taken from CUCM.  So we can see the response from LDAP regarding authentication.

Would you mind upload the packet capture here?

Thanks!

Michael

http://htluo.blogspot.com

[tmoore]

Michael - ran a capture from both the client (10.86.80.58) and CUCM Subscriber (10.86.97.131) and attached the files.  I did not see any LDAP queries on the CUCM, should I have run the capture on the Publisher?  CUPC show that the failed credentials is coming from 10.86.97.131.

[htluo]

Ya, I saw that at 14:23:14 CST.

It's very strange that you didn't capture any LDAP traffic on subscriber.  Could you get the CTIManager logs from subscriber around 14:13:14 CST, 11/8/2010?  -/+ 5 minutes should be good enough, assuming CTIManager trace was set to detailed level before.

Let me know the user ID.

Michael

[tmoore]

Attached are the CTIManager logs from the Subscriber,  the user that is having problems is renaghanmg

[htluo]

Per the logs, user renaghanmg was authenticating against local DB instead of LDAP.

You'd better check CUCM > User Management > Application Users.  See if there's a user 'renaghanmg' there.  If yes, please delete it.

Michael

http://htluo.blogspot.com

[tmoore]

Checked all CMs and there is no Application User configured with the name "renaghanmg".

Is there a way to delete a single End User from the database when using LDAP Authentication and then have the End User be recreated automatically on the next sync cycle?   The LDAP Sync Status for this end user is showing Active on the CMs.