[cisco-voip] CUCM LDAP Authentication Redundancy

[Daniel Pagan]

Nice find, Anthony, and a good read.

A while back I worked a case where LDAP synchronizations would not complete when the synchronize button was pressed by the customer. While looking into it, I found it interesting that CUCM would attempt A-record resolution on *all* FQDN server entries before starting the sync task (scheduled and forced), and now it makes even more sense if you’re seeing a three-way TCP handshake and bind request across the board. Seems like CUCM is using the same entry-by-entry verification steps built into a simple click of “Save” during every directory sync job.


From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Anthony Holloway
Sent: Friday, August 05, 2016 9:51 AM
To: Cisco VoIP Group <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] CUCM LDAP Authentication Redundancy

I'll also add that a "show open ports" on the publisher CLI does show the TCP socket switching to a new port every so often, so my theory as to why it was hanging on to this server is squashed.  I should have thought about the life span of a TCP session, before making that hypothesis.

On Fri, Aug 5, 2016 at 8:34 AM, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:
Something small to note for you layer 4 geeks out there.

When CUCM initiates a Directory Sync, a packet capture shows the pub going through a TCP three-way handshake with each of the LDAP servers, in order I might add, and also initiating a simple bind request to each one, finally settling on performing the search request on the first LDAP server.

When CUCM initiates an Authentication, a packet capture shows the pub not going through a TCP three-way handshake, but instead, using an already open TCP connection.  Perhaps the CUCM Auth code is written this way because authentication requests are more frequent than dir sync, and so it saves on overhead to reuse a connection rather than setup/teardown connections for each request.  That might explain why she's stuck using that one server, but of course it doesn't explain why it started using that one server to begin with.



On Thu, Aug 4, 2016 at 12:59 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:
All,

I'm working on an issue where my CUCM 11.0 system is configured with 3 LDAP servers under LDAP Authentication AND LDAP Directory.

What I'm see is, for packet captures of CUCM when a login attempt is made, the CUCM server sends the BIND request to the last server in the list of three servers.  However, when performing a directory sync, CUCM server sends the requests to the first server in the list.

I'm trying to read up on what the expected behavior is, as I've always thought of it as top = primary; middle = secondary; bottom = tertiary.  In fact, a few years ago there was an issue with CAD logins, when the primary server was unreachable and CAD would timeout before CUCM tried the secondary server.

The SRND is no help with only the following passage:

High Availability
Unified CM LDAP Synchronization allows for the configuration of up to three redundant LDAP servers for each directory synchronization agreement. Unified CM LDAP Authentication allows for the configuration of up to three redundant LDAP servers for a single authentication agreement. You should configure a minimum of two LDAP servers for redundancy. The LDAP servers can be configured with IP addresses instead of host names to eliminate dependencies on Domain Name System (DNS) availability.

Source: CUCM 11.0 SRND<http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab11/collab11/directry.html?bookSearch=true#pgfId-1085451>

So, what do you know, or what can you share, that states one way or the other, why CUCM might use a server in the listing, other than the first one, assuming the first server is healthy and accessible?

I did search the bug toolkit and didn't see any defects matching this scenario.

Thanks.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160805/79164ebd/attachment.html>