Expressway-C log unable to determine home CUCM

[jgaytan.plannet]

Hi

I am trying to set up mobile remote acces, when I type my user and password Jabber shows me "Your username or password is not correct".

On Expressway-C I see the following log: Detail="Request failed" User="('username', 'testuser')" Reason="Unable to determine home CUCM - Unknown CUCM cluster for node cucmsub".

I review the user and password and are ok, the traversal zone is active and unified communications are active and configured.

I have following versions:

CUCM 10.5.2.12901-1

Expressway C&E: X8.7

IM & P  10.5.2.22900-2

thanks

[Chris Deren]

Is the user able to login to Jabber internally on the network?

How many CUCM clusters are in the environment?

Your best bet is to review the Jabber log which provides very good clues on the reasons client is unable to login.

[Jaime Valencia]

Do you have more than one CUCM cluster configured on Expressway??

[HeribertoVV]

Hello Jaime,

I have the same problem. I have only one cluster (with two CUCMs) configured in Expressway-C.

2016-10-26T13:43:44-05:00	edgeconfigprovisioning: Level="WARN" Service="ECS" Detail="Request failed" User="('username', 'test@domain.com')" Reason="Unable to determine home CUCM - unknown user" UTCTime="2016-10-26 18:43:44,321"
2016-10-26T13:43:44-05:00	edgeconfigprovisioning: Level="WARN" Service="UDSManager" Detail="UDS clusterUser request failed" Reason="Unknown user" UDS="10.126.131.30" Identity="('username', 'test@domain.com')" UTCTime="2016-10-26 18:43:44,320"
2016-10-26T13:43:43-05:00	edgeconfigprovisioning: Level="INFO" Detail="All attempts to authenticate user failed" Username="test" UTCTime="2016-10-26 18:43:43,4"
2016-10-26T13:43:43-05:00	edgeconfigprovisioning: Level="INFO" Detail="Failed to authenticate user against server" Username="test" Server="10.127.11.3" UTCTime="2016-10-26 18:43:43,4"

Do you have any idea to why I am facing this problem?

I see this user in provisioning section, but CUCM is in red color.

[Tanapat Anutarakun]

Hi All,

I also have the same problem. Anyone have an idea to resolve this issue?

Thanks in advance.

Tanapat

[Alok Jaiswal]

The issue could be related to number of reasons. Without looking at the logs can't identify.

-  Try to verify all the dns & srv records

- Exp-E forwards & reverse lookup must get a response

- External SRV records

Recently i found the similar issue for a customer deployment. So when you are internal its all LDAP but when you are on MRA you it has to be UDS (CUCM directory)

When internal i could login as for e.g. ajaiswal@domain.com even though the userid is setup as "alok.jaiswal" but when you go outside and try to login as "ajaiswal" it doesn't use to work. 

Since all the LDAP imported users under CUCM is "firstname.lastname" users must login with that. If i try to login as "ajaiswal" i get an error "home UDS node not found".

So i would suggest you to look at the right login behavior in your case. Also look at the below call flow for MRA login.

https://supportforums.cisco.com/sites/default/files/jabber-mra-call_flow-detailed.pdf 

And then collect logs on Exp-C & E, and see where it is failing.

Or message me the logs and i can check for you and can tell you where is it going wrong.

Regards,

Alok

[waiwai]

Hi,

Is there any solution for this case?

I'm having the same issue as well.

2018-07-06T16:25:26.126+08:00	edgeconfigprovisioning: Level="WARN" Service="OAuth/SSO" Detail="Request failed" User="('username', 'waiwai@test.lancom.com')" Error="unknown user" UTCTime="2018-07-06 08:25:26,126"
2018-07-06T16:25:26.125+08:00	edgeconfigprovisioning: Level="WARN" Service="UDSManager" Detail="UDS clusterUser request failed" Reason="Unknown user" UDS="172.16.10.252" Identity="('username', 'waiwai@test.lancom.com')" UTCTime="2018-07-06 08:25:26,125"

Thank you

[Gpetroski1]

Check DNS for both forward and reverse lookup. I had a similar error where C couldn't do a successful reverse lookup against internal/public DNS for E. Actually, internal DNS had a PTR, but public was missing it. 

Check SRV records on public DNS (you should have cisco-uds and cuplogin INTERNAL only). colab-edge and sips on PUBLIC DNS

Public DNS The public (external) DNS must be configured with _collab-edge._tls. SRV records so that endpoints can discover the VCS Expressways to use for mobile and remote access. SIP service records are also required (for general deployment, not specifically for mobile and remote access). For example, for a cluster of 2 VCS Expressway systems: Domain Service Protocol Priority Weight Port Target host example.com collab-edge tls 10 10 8443 vcse1.example.com example.com collab-edge tls 10 10 8443 vcse2.example.com example.com sips tcp 10 10 5061 vcse1.example.com example.com sips tcp 10 10 5061 vcse2.example.com Local DNS The local (internal) DNS requires _cisco-uds._tcp. and _cuplogin._tcp. SRV records. For example: Domain Service Protocol Priority Weight Port Target host example.com cisco-uds tcp 10 10 8443 cucmserver.example.com example.com cuplogin tcp 10 10 8443 cupserver.example.com Unified Communications Mobile and Remote Access via Cisco VCS Deployment Guide (X8.5) Page 11 of 50 Configuration overview Ensure that the cisco-uds and _cuplogin SRV records are NOT resolvable outside of the internal network, otherwise the Jabber client will not start mobile and remote access negotiation via the VCS Expressway.

[Dennis Mink]

Try adding the CUCM on your VCS-c in under their hostnames and not IP's. Or at least check if that is already the case

Please rate if useful.

[AbteenZ]

I had the same issue.

Adding a DNS A record and PTR record for the newly added member to my CUCM cluster fixed the issue.

[h.hajamor]

the first thing to do :

-Referesh the CUCM server in Expressway  because it could be a problem in Expressway C Allow List (some time a reboot of the server is needed)

-Check out your A, SRV and PTR.

[Merlin Wizard]

Hi

I had this problem with Expressway-C logging 'Unable to determine home CUCM'. I turned on diagnostic logging on the Expressway-C and uploaded the diagnostic log to the Log Analyzer on Cisco's Collaboration Solution Analyzer. It came back with a single error...

Description

Expressway-C failed to do a reverse DNS lookup for IP Address(es) 192.168.xxx.yyy. Starting Expressway version X8.8 PTR records are mandatory for MRA to work correctly.

Action

Create missing PTR records in DNS server used by Expressway-C for the IP address(es) 192.168.xxx.yyy and flush the DNS cache of Expressway-C under System -> DNS.

This seemed strange as we had always previously had a reverse lookup for this IP address as it was the private network IP address of our Expressway-E server. It transpires that because we have 2 levels of DNS infrastructure (parent AD domain and child domain), when an administrator added the 192.168.xxx.0/24 subnet as a Reverse Lookup Zone in the child domain, DNS reverse lookups for that zone were no longer getting passed through to the parent domain DNS server, where the reverse lookup was defined.

We added the reverse IP lookup to the child domain's DNS server Reverse Lookup Zone. Initially there was no change but then we flushed the Expressway-C server's DNS cache and the problem was resolved.

So the lessons here were multiple but the takeaways for Expressway are:

• use diagnostic logging and Cisco's Collaboration Solution Analyzer to help reveal the issue
• ensure you have reverse IP lookups for all your Expressway and CUCM components

I hope this helps someone.