[cisco-voip] CUCM LDAP Authentication Redundancy

[Anthony Holloway]

Agreed!  And did you read the part in my email about how I use the same
three servers, in the same order for LDAP Directory, and packet captures
prove that the first server is used.  So, I think that pretty much confirms
that the first server is functional and reachable.  We use the same account
to connect to it, and the same search base, etc.

On Thu, Aug 4, 2016 at 2:28 PM, Brian Meade <bmeade90 at vt.edu> wrote:

> This definitely sounds like new 11.x behavior as I've tested this pretty
> extensively on 10.x and first server in the list is always used for LDAP
> Authentication if there's not some sort of connection problem.
>
> On Thu, Aug 4, 2016 at 3:09 PM, Anthony Holloway <
> avholloway+cisco-voip at gmail.com> wrote:
>
>> That's a good thought, and I'm happy to have this bug in my back pocket,
>> but no it was never first.  In fact, I added this third server as an after
>> thought, to support clustering over the WAN, and WAN outages, for those
>> folks not local to the Publisher, I want them to still be able to login to
>> Jabber and Finesse, etc.  You see, I didn't have a local AD server on each
>> side of the WAN, in my clustering over the WAN design, and our testing of a
>> WAN loss, resulted in no one being able to login.  So, after an email to
>> the cisco-voip mailing list, a PDI case, and trial and error, I figured out
>> that I needed a tertiary server in the far side datacenter to make that
>> scenario work.
>>
>> If I were to be hitting this defect, then my third server shouldn't be
>> working at all, right?  Because it's a new addition to my config, and I
>> haven't restarted Tomcat.
>>
>> As expected, my CUCM version (11.0.1.21900-11) is not listed in either
>> the affected or fixed in versions, so I cannot tell if I'm even impacted or
>> not.
>>
>> On Thu, Aug 4, 2016 at 1:09 PM, Brian Meade <bmeade90 at vt.edu> wrote:
>>
>>> Was the 3rd entry ever the first?  There's a bug where order changes
>>> don't take affect until Tomcat is restarted- https://bst.cloudap
>>> ps.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/6f7e3f3a/attachment.html>