topic Re: CUPC DeskPhone Invalid Credentials in Unified Communications Infrastructure

CUPC DeskPhone Invalid Credentials

tmoore — Tue, 19 Mar 2019 08:52:14 GMT

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?

Re: CUPC DeskPhone Invalid Credentials

Joseph Martini — Thu, 04 Nov 2010 22:55:16 GMT

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.

Re: CUPC DeskPhone Invalid Credentials

tmoore — Fri, 05 Nov 2010 10:41:57 GMT

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.

Re: CUPC DeskPhone Invalid Credentials

Joseph Martini — Fri, 05 Nov 2010 15:11:50 GMT

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?

Re: CUPC DeskPhone Invalid Credentials

tmoore — Fri, 05 Nov 2010 15:19:09 GMT

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.

Re: CUPC DeskPhone Invalid Credentials

Joseph Martini — Fri, 05 Nov 2010 15:25:49 GMT

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.

Re: CUPC DeskPhone Invalid Credentials

tmoore — Fri, 05 Nov 2010 16:43:52 GMT

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

Re: CUPC DeskPhone Invalid Credentials

htluo — Sat, 06 Nov 2010 15:31:02 GMT

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".

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

Re: CUPC DeskPhone Invalid Credentials

tmoore — Mon, 08 Nov 2010 17:48:53 GMT

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.

Re: CUPC DeskPhone Invalid Credentials

htluo — Mon, 08 Nov 2010 18:22:01 GMT

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

Re: CUPC DeskPhone Invalid Credentials

tmoore — Mon, 08 Nov 2010 21:11:39 GMT

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.

Re: CUPC DeskPhone Invalid Credentials

htluo — Mon, 08 Nov 2010 22:05:53 GMT

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

Re: CUPC DeskPhone Invalid Credentials

tmoore — Mon, 08 Nov 2010 22:37:34 GMT

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

Re: CUPC DeskPhone Invalid Credentials

htluo — Tue, 09 Nov 2010 03:32:23 GMT

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

Re: CUPC DeskPhone Invalid Credentials

tmoore — Tue, 09 Nov 2010 11:42:58 GMT

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.

Re: CUPC DeskPhone Invalid Credentials

htluo — Tue, 09 Nov 2010 13:24:51 GMT

Try to use the publisher CTIManager for desk phone control. See if you got the same problem?

Michael

Re: CUPC DeskPhone Invalid Credentials

tmoore — Tue, 09 Nov 2010 15:22:43 GMT

On CUPS, changed the CTI Gateway Profile to move the CM Publisher up as the Primary CTI Gateway Server and moved the CM Subscriber as the backup server. Restarted the Sync Agent. But still same problem, the capture is showing the ip address of the Publisher now but same error.

Re: CUPC DeskPhone Invalid Credentials

htluo — Tue, 09 Nov 2010 16:06:40 GMT

Looks like something's wrong with this particular user in the CM database.

Try to run the following SQL query from the CM command line:

run sql select status from enduser where userid='renaghanmg'

Then run it against a good user:

run sql select status from enduser where userid='mooretm'

Michael

Re: CUPC DeskPhone Invalid Credentials

tmoore — Tue, 09 Nov 2010 17:19:02 GMT

Ran the commands on the CM Publisher. The 'mooretm' AD account is in all uppercase so when I ran it in lower case it did not give a status. I ran another userid that I know works which is in all lower case in AD, all report Status=1.

admin:run sql select status from enduser where userid='renaghanmg'
status
======
1
admin:run sql select status from enduser where userid='mooretm'
status
======
admin:run sql select status from enduser where userid='MOORETM'
status
======
1
admin:run sql select status from enduser where userid='perryv'
status
======
1

Re: CUPC DeskPhone Invalid Credentials

htluo — Tue, 09 Nov 2010 17:48:21 GMT

You may tried to disable LDAP, delete the problem user, then re-enable LDAP.

Or you may open a TAC case and quote the following messages from CTIManager SDI logs:

11/08/2010 14:46:39.603 CTI|userid is renaghanmg|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.603 CTI|CCMEncryption::DecryptText:enter|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.603 CTI|CCMEncryption::DecryptText (Exit) (Success))|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.603 CTI|AuthenticationImpl::login (Auth with password. Calling authenticateUserWithPassword)|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.603 CTI|authenticationDB::authenticateUserWithPassword():enter|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.603 CTI|Credential Length is: 32|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.603 CTI|authenticationConnector::getReadDSN:enter|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.603 CTI|authenticationConnector  ReadDSN is:DSN=ccm2;uid=dbims|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.603 CTI|authenticationConnector  WriteDSN is:DSN=ccm;uid=dbims|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.620 CTI|Setting Fields|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.620 CTI|userType is: 1|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.621 CTI|timeOfLockout is: 0|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.621 CTI|timeHackedLockout is: 0|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.621 CTI|hackCount is: 0|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.621 CTI|daysToExpiry is: -216|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.621 CTI|doesNotExpire is: 0|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.621 CTI|useExpiryWarning is: 1|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.621 CTI|isInactive is: 1|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.621 CTI|userMustChange is: 1|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>
11/08/2010 14:46:39.621 CTI|endUserStatus is: 1|<:STANDALONECLUSTER><:10.86.97.131><:ALL><:FFFF>

Michael