[cisco-voip] CUCM LDAP Authentication Redundancy

[Ki Wi]

Hi Guys,
Anyone know how this LDAP DirSync works?

Besides sync directory (as per their name), does this very same
service does the authentication with the LDAP servers?

Will there be any subscribers be taking over if the publisher is down? Does
the subscribers need the DirSync service to be running?
If so,how do we determine which will be the next one taking over?


Regards,
Ki Wi

On Fri, Aug 5, 2016 at 11:36 PM, Daniel Pagan <dpagan at fidelus.com> wrote:

> 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> 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> 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.
>
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>


-- 
Regards,
Ki Wi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160819/56826731/attachment.html>