01-14-2019 03:29 AM - edited 03-17-2019 07:49 PM
Good morning.
First of all, sorry if this is a duplicated post, but I haven't been able to find any related one.
I have two regions that use the same internal LDAP/DNS domain, but different CUCM cluster. The internal DNS doesn't support geoDNS, so I can't use the SRV record _cisco-uds for Jabber client automatic configuration, because each region will query the same _cisco-uds SRV record, but they must connect to different cluster.
So I need to use manual configuration at each region, and define specifically the CUCM for Jabber client to connect to. My idea for implementing high availability is to create a custom SRV record for each region, pointing to all the subscriber servers of each CUCM cluster; or a common alias (A record) for each region, pointing to each of the subscriber servers of each CUCM cluste, would these two solutions work fine?
Another doubt is about Subject Alternative Name (SAN) in CUCM tomcat certificates, to avoid certificate warnings in Jabber client. I suppose that I will need to include the common alias in the SAN list into the certificate, is that right? In the case I use the SRV record solution, will I need to use the SAN list, too?
Thank you very much. Best regards,
Patricia
Solved! Go to Solution.
01-14-2019 06:42 AM
Hello Patricia,
I have 4 clusters globally deployed. I use SRV records that round robin through each of the publisher servers (CUPS). I have ILS set up on the CUCMs and the CUPS servers are peered. Becase each server knows where a user is "homed", the authentication always works. It does not matter if the UDS login or cups login goes to a server that not the home cluster for the user. The server responses to the jabber client and the client then logs into the server where it is homed.
I hope this helps.
Steve
01-14-2019 09:17 AM
For anyone reading this post later, as Steve said the solution to this issue is to deploy ILS between your CUCM clusters. (Although I understand that Patricia can't implement this.) ILS will cause your CUCM servers to share information about "Home Cluster" information. It is very easy to set up, although the CUCM guide makes it look harder than it is.
Here are the instructions from CUCM 12, but applies to earlier versions:
Here is a great step-by-step guide:
Thank you, Patricia, for saying I should repost this information.
01-22-2019 11:01 AM
SRV records have nothing to do with the certificates presented by CUCM, IM&P, CUC, etc.
SRV records just help the clients locate a service and that's it, they're no longer used in the rest of the process.
01-14-2019 06:42 AM
Hello Patricia,
I have 4 clusters globally deployed. I use SRV records that round robin through each of the publisher servers (CUPS). I have ILS set up on the CUCMs and the CUPS servers are peered. Becase each server knows where a user is "homed", the authentication always works. It does not matter if the UDS login or cups login goes to a server that not the home cluster for the user. The server responses to the jabber client and the client then logs into the server where it is homed.
I hope this helps.
Steve
01-14-2019 07:33 AM - edited 01-14-2019 08:06 AM
Thank you so much for your response, Steve.
I have already read about implementing ILS between clusters to solve the issue with _cisco-uds record, but now this is not an option for us. So, I need to know if creating a custom Alias record, one for each region and pointing to all subscriber IPs in the cluster, and including it at "Use the following server" field, according to the client region, the solution will work.
In case it works, I suppose that I need to include the Alias into the SAN list of the tomcat certificates of the subscribers, right?. It would be necessary for CallManager certificates, too?
Another point, our Jabber clients point to CUCM servers, not CUPS servers directly. But I suppose this is not relevant for the solution.
Finally, I need to confirm if using the SVR record solution with _cisco-uds, it would be necessary to include that record into certificates SAN list.
Best regards,
Patricia
Patricia
01-14-2019 09:17 AM
For anyone reading this post later, as Steve said the solution to this issue is to deploy ILS between your CUCM clusters. (Although I understand that Patricia can't implement this.) ILS will cause your CUCM servers to share information about "Home Cluster" information. It is very easy to set up, although the CUCM guide makes it look harder than it is.
Here are the instructions from CUCM 12, but applies to earlier versions:
Here is a great step-by-step guide:
Thank you, Patricia, for saying I should repost this information.
01-22-2019 02:47 AM
Finally, we are going to implement ILS between both clusters, thanks to Steve and Maren for their support.
The last doubt I have is the following: if we use _cisco-uds SRV record for automatic Jabber configuration, does we need to include a particular name to the Subject Alternative Name list into CUCM certificates?
Thank you very much. Best regards,
Patricia
01-22-2019 07:34 AM
Patricia,
I am still learning the certificates part of MRA and it is no small matter. Read the Cisco documentation and also ask the internet extensively. There are many threads on exactly what you are asking on the discussion boards, and many blog posts elsewhere. Hopefully someone else here will have a definitive resource/answer for you.
(I'll be watching as I am also very interested in this...)
Maren
01-22-2019 09:02 AM
01-22-2019 09:11 AM - edited 01-22-2019 09:11 AM
Hello Salid. Thank you for your support.
My question is focused on what happens in the last step of the following list:
My concern is if Jabber client will show a security warning about the received certificate, if _cisco-uds URL is not included in the SAN list of CUCM01.example.com tomcat certificate.
Best regards.
Patricia
01-22-2019 11:01 AM
SRV records have nothing to do with the certificates presented by CUCM, IM&P, CUC, etc.
SRV records just help the clients locate a service and that's it, they're no longer used in the rest of the process.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide