[cisco-voip] CUCM LDAP Authentication Redundancy

[Brian Meade]

Was the 3rd entry ever the first?  There's a bug where order changes don't
take affect until Tomcat is restarted-
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuu55380

On Thu, Aug 4, 2016 at 1: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160804/61a5230e/attachment.html>