cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6910
Views
0
Helpful
8
Replies

Cisco Jabber for Windows: Problem with account type automatic

Mario Oosters
Level 1
Level 1

When I install the application (Cisco Jabber for Windows) for the first time I seem to be getting an error for a known good user when trying to logon with account type : Automatic. -->Your username or password is not correct

I do have the SRV record : _cisco-uds._tcp.yyy.xxx defined. In fact even three times... (2 for both CCM Subscribers and 1 for the publisher)

Looking at the logfiles it does get resolved.

Whenever I change this manually to one of the subscribers (in advanced settings of the jabber client). I can logon

Signing out and placing it back on automatic, no longer gives this message, this makes me thinking that I am then using the cached information...

So, the question is offcourse what am I missing.

The only thing I need is this _cisco-uds SRV record to get Cisco Jabber receive it's config automatic or is it?

1 Accepted Solution

Accepted Solutions

Hi Mario,

Can you please %AppData% folder and then try again.

Stop Jabber.

Go to Run windows type %appdata% hit enter,

then go to Cisco and delete "Unified Communication" folder.

Then start jabber again.

Leszek

View solution in original post

8 Replies 8

Jaime Valencia
Cisco Employee
Cisco Employee

That will depend on the versions that you're using, the Jabber documentation explains which SRV records are used, according to the version being used.

Does nslookup come up with the right information?

You can also look at a PRT to see what is Jabber getting back when doing the SRV search.

HTH

java

if this helps, please rate

We are running CUCM 11.0 here and Cisco Jabber 11.6

nslookup works fine.

Following is excerpt of Cisco Jabber Problem Report. 

Could it be because of the Selfsigned Certificates?

It doesn't seem to be certificate issue it's rather user/pass issue (maybe cause by replication - hard to say for now)

What i can see in the logs that the user tries to authenticate against home UDS:

2016-06-10 09:14:38,920 DEBUG [0x0000aa00] [cert\common\CertificateDataImpl.cpp(206)] [csf.cert] [csf::cert::CertificateDataImpl::parseSubjectCNField] - Subject CN field : SCCM12.groups.local
2016-06-10 09:14:39,157 DEBUG [0x0000aa00] [ces\impl\ucm-config\UdsProvider.cpp(815)] [csf.config] [csf::ucm90::UdsProvider::doHomeUdsQuery] - Result from Home UDS query: HOME_UDS_AUTHENTICATION_FAILED
2016-06-10 09:14:39,157 ERROR [0x0000aa00] [ces\impl\ucm-config\UdsProvider.cpp(892)] [csf.config] [csf::ucm90::UdsProvider::convertHomeUdsResult] - homeUdsResult=[HOME_UDS_AUTHENTICATION_FAILED] ucmConfigResult=[FAILED_TO_AUTHENTICATE_WITH_CALL_MANAGER]

So from some reason CUCM server SCCM12.groups.local is rejecting your user/pass.

What i can see is that you have couple of UDs servers:

SCCM12.groups.local:8443
192.168.250.211:8443
192.168.250.212:8443
192.168.251.213:8443

Any reason only one of them is defined by FQDN?

Can you do the following test, enter to the web browser following URLs one by one and try to authenticate with your user/pass:

https://SCCM12.groups.local:8443/cucm-uds/user/oosterma
https://192.168.250.211:8443/cucm-uds/user/oosterma
https://192.168.250.212:8443/cucm-uds/user/oosterma
https://192.168.251.213:8443/cucm-uds/user/oosterma

After successful authentication you should be getting webpage with the XML configuration.

Please give it a test and attach the results.

Leszek

All four work fine.

The only thing special is the complaining about the certificate of the server. After accepting this all is fine.

This is the reason why I was thinking about the certificates. Although Curl in the PRT does seems to ignore it...

It is in fact only three. SCCM12.groups.local is just the fqdn for 192.168.250.212.

I did one minor change to the result in attachment here.

I just replaced the phone-numbers with the private keyword.

Thanks Mario,

From the logs it looks like authentication failure response comes from CUCM:

Ucm90 Library failed with code FAILED_TO_AUTHENTICATE_WITH_CALL_MANAGER

So what it might be good to get additionally would be Audit logs, Event Viewer, Call manager and USD and Tomcat logs.

With those we should be able to tell why authentication is failing.

Additionally once again matching PRT would be helpful so that we can map events on PC to CUCM events.

Leszek

I did need to look a bit around to know what you needed.

I think I can give you all or at least most.

Something very interesting seems to be happening in the tomcat logs already.

[09/Jun/2016:13:46:45 +0200] 192.136.19.72 192.136.19.72 oosterma - 8443 GET /cucm-uds/user/TESTED HTTP/1.1 401 2183 76

It seems to try to reach the url for user oosterma with the authentication information of user tested!! This fails of course. I do happen to recreate the issue by swapping users and resetting jabber. In order to get a clean config, so this might in fact even be another issue... as this is clearly not clean.

Hi Mario,

Can you please %AppData% folder and then try again.

Stop Jabber.

Go to Run windows type %appdata% hit enter,

then go to Cisco and delete "Unified Communication" folder.

Then start jabber again.

Leszek

This seems to help indeed.

Is this as close as I can get to a clean install?