Jabber Login Question Dual domain

[rchaseling]

UC 11.5 deployment with Jabber MRA deployed and working. Now the customer wants to start using Jabber on prem as well with moving back to office but logins are failing because the customer does not have their external domain as a domain on their internal DNS .....and doesn't want to.

So customer has:

External Domain: external.com

Internal Domain: internal.local

IMP Address Scheme is : Directory URI (which is user@external.com)

Fresh install of Jabber login on Prem fails because Jabber is doing a UPN discovery and getting back user@external.com and can't find the cisco-uds record in this domain as it doesn't exist so tries to go via Expressway which fails (firewall).

I've disabled the UPN discovery parameter but then it asks manually for users email.....but users would need to put in user@internal.local as their email which will cause confusion

I've played with VOICE_SERVICES_DOMAIN=internal.local parameter which works but I assume then this will cause issues when the users take their laptops home ......

Is the only real option here to tell the customer they must create a external.com domain in their internal DNS ??? I understand it is most likely by far the best option but is there a backup option that is as seemless ?

Thanks

[Roger Kallberg]

This document should explain what you need to do, even if it uses older terminology like VCS for MRA. https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway-series/117811-configure-vcs-00.html

Likely there could be newer variants of the document available.

[rchaseling]

Hi,

Using the "voice service domain" as the internal domain works for on-prem but that will cause failures when the user is at home via MRA I would expect.

Is the only way for this to work is to tell users.

1. They must login on-prem first

2. Log in with user@internal.local as their email 

Then configure jabber-config.xml with voice service domain as external.com

The problems with this is users will get confused logging in with a login they don't use anywhere else.. user@internal.local and they mostly have already logged in via MRA so would they need to reset their jabber when they next go to office?

[Roger Kallberg]

The document outlines all your question. Have you read it?

[Roger Kallberg]

You can also read this presentation from Cisco Live as it contains great information on the topic at hand. https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2016/pdf/BRKCOL-2021.pdf

[rchaseling]

Hi Roger,

Thanks for the docs and I am reasonably familiar with all of them - the problem is there is no match to this exact setup. We have the setup in attached screenshot EXCEPT the IM&P domain in this scenario is domain2 (external.com) which is Directory URI (email) and hardcoding the voice services domain to external.com causes internal logins to fail

Unfortunately I don't have an environment with this setup I can test on and due to Covid I can't get into their office to test properly which is not helping

I need to give them the next best solution apart from adding in external.com to their internal DNS with least disruption to existing production MRA users

I was always told that changing the IMP Domain to Directory URI was best practice for various reasons (federation etc) but unless they have their external DNS as a zone on their internal DNS this doesn't seem to be the case

[Sankar Voleti]

Hi,

   Jabber always checks the value of voiceservicesdomain for service discovery during the login - internal or MRA. So when the users login via MRA with the external domain, that's cached as long as Jabber isn't reset. Hence, a forward lookup zone is required in the internal DNS for the MRA domain under which _cisco-uds SRV is created. This avoids the need of a Jabber reset since the client will be able to discover the _cisco-uds._tcp.<external domain> when the users roam from home to office.

1) If the users sign-in via MRA for the first time after installing the client, the voiceservicesdomain will be set as the external domain. You don't have to populate the parameter in the XML file.

2) If they sign-in over the corporate network for the first time, then the above parameter should be set to the external domain in the XML file. It'll be used for MRA login without the need of resetting the app.

Hope this helps!

-Sankar

[Roger Kallberg]

In “short”, set the parameter for voiceservicesdomain to the external domain and create a forwarding zone in the internal DNS for the external domain that has the SRV record _cisco-uds._tcp.external.com for UDS, that contains the records for the CMs that is part of the ILS network, is needed for the OP to solve the issue of users always being able to use user@external.com for login if I fully understood what you wrote.

[Sankar Voleti]

That is correct Roger!

-Sankar

[rchaseling]

Thanks Sankar,

So that gets me back to my original problem description. The customer cannot put in a forwarding zone for their external DNS on their internal DNS without causing other issues. Their UPN is also their external domain.

Is the only option here

1. Disable UPN Discovery when installing Jabber

2. Get users to login on prem first with user@internal.local

3. Configure Jabber XML with Voice Service Domain = external.com

Will the above allow them to move between on prem and MRA without resets?

Thanks

[Sankar Voleti]

Hello,

    I would say users don't have to reset the client while moving from on-prem to MRA since you've set the voiceserivicesdomain to the edge domain. But a reset will be required when they move back to on-prem because of no visibility of UDS service based on the voiceservicesdomain value.

-Sankar

[rchaseling]

Thanks for the replies guys!

@Sankar Voleti- so bottom line is doesn't matter what domain is used for UDS search initially ... if the voiceservicesdomain is configured in the XML this will always take preference for all future logins? Jabber does not hold a record of internal & external domains?

@Roger Kallberg- I'm not actually sure. Its a large corporation and I was told by their AD team that creating a Forwarding lookup zone for their external domain on their internal DNS could cause issues. I assume they use services with FQDN of their external domain that actually route externally and then back in? It sounds like there is no other real option though ........

[Roger Kallberg]

My guess is that the AD team at your customer doesn't know what their talking about. The zones are separated from each other as one is reachable internal and the other is only reachable external, so they should not cause issues it the only thing it contains internally is the SRV record for the UDS lookup. We have our domain both internally and externally in DNS and up to days date we have not had any issues that comes from this that I'm aware of.

[rchaseling]

Yeah I'm thinking so too alright but I assume once they add in that forwarding zone for the external.com domain that internal users will no longer be able to resolve anything on that domain that is normally available externally unless they add in A records with the public IPs in that zone too......

[Roger Kallberg · Accepted solution]

As Sankar and I wrote the only entry that would be required in the internal zone for the external domain should be the SRV record for UDS.