Cisco MRA not working *New deployment*

[Jan Slabber]

We are having trouble getting MRA working in our environment and would like some help to identify why it is not working.

We are currently running

CUCM : System version: 11.5.1.15900-18 Unrestricted
Cisco VCS Control: Version: X8.11.4
Cisco VCS Expressway: Version: X8.11.4

Everything seems to be configured correctly but I am not able to work out where this is falling over.

On the VCS Control I can see the user is authenticated:

edgeconfigprovisioning: Level="INFO" Detail="Authenticated user successfully" Username="8130" ClientId="85.255.234.187" UTCTime="2019-03-20 09:48:04,482"

But the Expressway gives the error:
traffic_server[7453]: Event="get_edge_sso" Detail="Access denied" Reason="Only legacy auth supported" Domain="global.com" Src-ip="85.255.234.187" Src-port="17712" UTCTime="2019-03-20 09:47:50,907

I've tried to find more information on the Reason="Only legacy auth supported" but cannot find any further information.

[Jonathan Schulenberg]

This doesn’t directly answer your question but two abnormalities stand out in your post:
1. You have the unrestricted version of CUCM deployed. This is only intended for countries with export restrictions (eg Iran, Syria, North Korea). Unless you are in one of those counties stop now and reinstall the restricted version. There is no way to switch back later and ICE pass through support in x12.5 will not work with the Unrestricted version.
2. Why are you using VCS instead of Expressway-C/-E? This is not the correct choice for a new deployment.

[joemartinez316]

Hi Jan,

I was curious if you were able to resolve this issue as I ran into this as well. In my case I'm running "Authorize by user credential" on the Expressway C and I have no issues with users logging into Jabber on the inside. I get the same errors where it shows Authenticated Successfully on the Core but get's "Access Denied" with "Only legacy auth supported" on the Edge.

Thanks! 

[Edward Noell]

im having the same issue with a x12.5 deployment, this was usually related to authentication policy set for MRA on the C but i made sure it is set to UCM Basic LDAP/Auth

[afzam2002 · Accepted solution]

Did you get solve this problem?

[Jan Slabber]

Thank you for attaching the logs I have checked them and they are pointing to a bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuo83458/?reffering_site=dumpcr There are three ways to fix this: - Change the FQDN configured on VCS/Expressway-E to match the FQDN returned by the _collab-edge SRV record. - Change the FQDN returned by the _collab-edge SRV record to match the FQDN configured on VCS/Expressway-E. - Change the FQDN returned by the _collab-edge SRV record to an alias of the FQDN configured on VCS/Expressway-E, with the requirement that the alias has to be in the same domain as the FQDN

[afzam2002]

Hi Jan, please, let us know, how did you get to resolve this issue?

[Jan Slabber]

Hello,

CSCuo83458

Regards,
Jan

[Jan Slabber]

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuo83458/?reffering_site=dumpcr

There are three ways to fix this:

- Change the FQDN configured on VCS/Expressway-E to match the FQDN returned by the _collab-edge SRV record.

- Change the FQDN returned by the _collab-edge SRV record to match the FQDN configured on VCS/Expressway-E.

- Change the FQDN returned by the _collab-edge SRV record to an alias of the FQDN configured on VCS/Expressway-E, with the requirement that the alias has to be in the same domain as the FQDN

[Sandesh Pawar]

Apart from the point mentioned above ref the SRV record name. Also check the port configured on the SRV record.

in my case the customer had entered 8334, instead of 8443. 

Although it is pretty straightforward it is difficult to spot :)

[Jan Slabber]

Hello,

The problem was resolved but I am unable to post the root cause. Need to get back to my TAC cases to see if I can post what the fix was.

[Chris Huras]

Hi Jan

Were you able to find the root cause? I've got the exact same error and its almost impossible to find a solution to this.

[gfolens]

This bug could also be one of the causes:

CSCvz20720

Symptom: Expressway connections to CUCM over port 6972 failing with "tlsv1 alert unknown ca" and "502 connect failed" errors. Conditions: As of x14.0.2 (due to some improvements in traffic server service), Expressway will send its client certificate whenever a server (CUCM) requests it, for services running on ports other than 8443 (e.g., 6971,6972) even if CUCM is in non-secure mode. Workaround: This improvement, enabled by default in Expressway code, requires Expressway-C certificate signing CA to be added in CUCM tomcat-trust and CallManager-trust list. You must also restart tftp services on each CUCM and issue CUCM command utils service restart Cisco HAProxy

[Chris Huras]

This was my exact problem and how I resolved it.

[Alessandro Bertacco]

Hi Guys, same issue there, errors Only on the Expressway-E side (Dual NIC deployment with NAT1:1 on the outside NIC)

Event="get_edge_sso" Detail="Access denied" Reason="Only legacy auth supported"

Anyone solved?

TAC is opened but no solution in 72 hours