[cisco-voip] CUCM LDAP Authentication Redundancy

[Ki Wi]

Hi Ryan,
Thanks for giving the insight on how they actually works!

Regards,
Ki Wi

On Fri, Aug 19, 2016 at 5:24 PM, Ryan Huff <ryanhuff at outlook.com> wrote:

> The DirSync service only runs on the publisher and, as you pointed out,
> handles LDAP directory synchronization. This capability will only issue
> requests from the publisher.
>
> LDAP authentication is a separate component that actually uses the tomcat
> service on the node that issues a bind request the the LDAP authentication
> sever. LDAP authentication BIND requests can potentially come from any node
> (assuming you have LDAP Authentication enabled); although Directory
> Synchronization (DirSync) will only com from the publisher.
>
> Thanks,
>
> Ryan
>
> On Aug 19, 2016, at 3:56 AM, Ki Wi <kiwi.voice at gmail.com> wrote:
>
> 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
>
> _______________________________________________
> 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/20160822/01b1e717/attachment.html>