<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Century Gothic";
        panose-1:2 11 5 2 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
p.ecxmsonormal, li.ecxmsonormal, div.ecxmsonormal
        {mso-style-name:ecxmsonormal;
        mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
p.ecxmsochpdefault, li.ecxmsochpdefault, div.ecxmsochpdefault
        {mso-style-name:ecxmsochpdefault;
        mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
p.ecxmsonormal1, li.ecxmsonormal1, div.ecxmsonormal1
        {mso-style-name:ecxmsonormal1;
        mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
p.ecxmsochpdefault1, li.ecxmsochpdefault1, div.ecxmsochpdefault1
        {mso-style-name:ecxmsochpdefault1;
        mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:10.0pt;
        font-family:"Times New Roman",serif;}
span.ecxmsohyperlink
        {mso-style-name:ecxmsohyperlink;}
span.ecxmsohyperlinkfollowed
        {mso-style-name:ecxmsohyperlinkfollowed;}
span.ecxemailstyle17
        {mso-style-name:ecxemailstyle17;}
span.ecxemailstyle18
        {mso-style-name:ecxemailstyle18;}
span.ecxemailstyle19
        {mso-style-name:ecxemailstyle19;}
span.ecxmsohyperlink1
        {mso-style-name:ecxmsohyperlink1;
        color:#0563C1;
        text-decoration:underline;}
span.ecxmsohyperlinkfollowed1
        {mso-style-name:ecxmsohyperlinkfollowed1;
        color:#954F72;
        text-decoration:underline;}
span.ecxemailstyle171
        {mso-style-name:ecxemailstyle171;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.ecxemailstyle181
        {mso-style-name:ecxemailstyle181;
        font-family:"Calibri",sans-serif;
        color:#404040;
        font-weight:normal;
        font-style:normal;}
span.ecxemailstyle191
        {mso-style-name:ecxemailstyle191;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle32
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.EmailStyle33
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#404040;
        font-weight:normal;
        font-style:normal;
        text-decoration:none none;}
span.EmailStyle34
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040">“</span><span style="font-family:"Calibri",sans-serif">I'm not sure that an ACL would do the trick though, probably would just show up in the traces as a time
 out”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Exactly. The Publisher will simply failover to the next LDAP server in the list if it cannot establish a connection within 5-seconds to the primary LDAP server. Regardless, the node receiving
 the LDAP-user authentication request will source the authentication attempt over Tomcat itself. So if a user browses to the /ccmuser page on a subscriber01 and attempts to authenticate, the authentication request should not be passed to subscriber02 or the
 publisher - it should be handled by that node itself. I doubt this behavior changes with a properly configured LDAPS cluster but I can be wrong. I’m not as familiar with the authentication process for LDAPS.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">It also depends on what platform the authentication request is coming from. Using UCCX as an example again, it sends user authentication to CUCM via AXL API. So successful authentication from
 there is dependent on the AXL server assignments in UCCX - the AXL server (whatever node that might be) receiving the request should use Tomcat to source the LDAP authentication request. However, even with successful LDAP authentication on a subscriber, agent
 logins can of course still fail on the JTAPI/CTI side for other reasons, especially if AXL and CTI server assignments are different.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">@Ryan: For the two lab failures, I’m wondering if this was a pre-existing condition that’s unrelated to the test itself.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">                                                                                                                
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">As for the login failures during the 4-hour window, I can think of a few reasons off the top of my head. Are the LDAP server entered as FQDN or IP addresses? If FQDN, are all your CUCM nodes
 configured with the same DNS servers? Not that it’s a requirement, but if you’re using different DNS server assignments, I would make sure the Subs can resolve the name. If using IP address, can you reach the secondary LDAP server from the Subscriber with
 no issues? Are the port assignments correct for your list of LDAP servers in CUCM? As in… if you’re using port 3268 across the board for all added LDAP servers in CUCM, and the secondary LDAP server is not a Global Catalog, I can see this potentially causing
 a failure when the primary LDAP server is offline. Another thing that comes to mind which I twice ran into is CSCub71123, but this should be resolved in 10.0 and up so you should be good. I’m just thinking as I type here but Tomcat Security logs off the node
 receiving the auth request should reveal more concrete information… but keep in mind the issue can exist earlier in the auth process and might not even be reaching Tomcat. Grab them off your cluster via RTMT and take a quick look - they’re very easy to decipher…
 very straight forward log files IMO.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Hope this helps.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">- Dan<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#404040"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> cisco-voip [mailto:cisco-voip-bounces@puck.nether.net]
<b>On Behalf Of </b>Matthew Collins<br>
<b>Sent:</b> Monday, July 06, 2015 11:24 AM<br>
<b>To:</b> Ryan Huff; Lelio Fulgenzi<br>
<b>Cc:</b> cisco-voip@puck.nether.net<br>
<b>Subject:</b> Re: [cisco-voip] LDAP Authentication when CUCM publisher is down.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Thanks for all your responses.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">In our scenario when we lost one of a DC (planned maintenance) that hosted the CUCM, IM&P, and UCCX Pubs UCCX fineness agents were unable to log
 in. Had to resort to a couple of local back up agent accounts.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">LDAP authentication wasn’t working for any service (Jabber, CUCM Web Gui, UCCX Finesse Web Gui). I wasn’t around to do any testing and as it was
 only a 4 hours maintenance period it wasn’t logged with us and no logs where collected.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:10.0pt;font-family:"Century Gothic",sans-serif;color:#009DB1">Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:10.0pt;font-family:"Century Gothic",sans-serif;color:#009DB1"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:10.0pt;font-family:"Century Gothic",sans-serif;color:#009DB1">Matthew Collins
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> cisco-voip [<a href="mailto:cisco-voip-bounces@puck.nether.net">mailto:cisco-voip-bounces@puck.nether.net</a>]
<b>On Behalf Of </b>Ryan Huff<br>
<b>Sent:</b> 06 July 2015 15:24<br>
<b>To:</b> Lelio Fulgenzi<br>
<b>Cc:</b> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<b>Subject:</b> Re: [cisco-voip] LDAP Authentication when CUCM publisher is down.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif">I'll be interested to hear your results if you try!<br>
<br>
I'm not sure that an ACL would do the trick though, probably would just show up in the traces as a time out. You'd probably have to stop the tomcat service on the pub (something to tell the cluster not to try and use the PUB as a bind source), which is pretty
 destructive on the pub in a working production environment (disclaimer: I do not advocate you do that).<br>
<br>
 <o:p></o:p></span></p>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-GB" style="font-family:"Calibri",sans-serif">
<hr size="2" width="100%" align="center">
</span></div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-GB" style="font-family:"Calibri",sans-serif">Subject: Re: [cisco-voip] LDAP Authentication when CUCM publisher is down.<br>
From: </span><span lang="EN-GB"><a href="mailto:lelio@uoguelph.ca"><span style="font-family:"Calibri",sans-serif">lelio@uoguelph.ca</span></a></span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><br>
Date: Mon, 6 Jul 2015 10:12:53 -0400<br>
To: </span><span lang="EN-GB"><a href="mailto:ryanhuff@outlook.com"><span style="font-family:"Calibri",sans-serif">ryanhuff@outlook.com</span></a></span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><br>
CC: </span><span lang="EN-GB"><a href="mailto:dpagan@fidelus.com"><span style="font-family:"Calibri",sans-serif">dpagan@fidelus.com</span></a></span><span lang="EN-GB" style="font-family:"Calibri",sans-serif">;
</span><span lang="EN-GB"><a href="mailto:cisco-voip@puck.nether.net"><span style="font-family:"Calibri",sans-serif">cisco-voip@puck.nether.net</span></a></span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif">The worst case scenario, which we ran into, was a scenario where the pub is up and accepting auth requests but not able to process them. In our case the cluster was up for almost
 300 days, and there were memory error alerts popping up. It would be nice for the system to understand this issue and go to the next node to try the auth process. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif">Interesting note about LDAPS. We are using that. Not sure if that poses additional issues. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif">Wish there was an easy way to test this out in production. Perhaps a quick ACL to block phone agent and desktop agent access to the pub and see what happens. And then another test
 where the ACL blocks access to the LDAP server temporarily. <br>
<br>
Sent from my iPhone<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><br>
On Jul 6, 2015, at 10:04 AM, Ryan Huff <</span><span lang="EN-GB"><a href="mailto:ryanhuff@outlook.com"><span style="font-family:"Calibri",sans-serif">ryanhuff@outlook.com</span></a></span><span lang="EN-GB" style="font-family:"Calibri",sans-serif">> wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-GB" style="font-family:"Calibri",sans-serif">Hi Dan!<br>
<br>
Thanks for the clarification/correction .... I just happen to have a few 3-node cluster hanging around and I just tried this 5 times in a mix of 9.1.1, 10.0 and 10.5 and here is what I found:<br>
<br>
3 times LDAP auth was a seamless failover to the sub<br>
2 times LDAP auth did not work on the sub until I bounced the tomcat service on the sub, then it worked fine.<br>
<br>
I'm wondering if that, on the times it doesn't work in a failover (because I have experienced it a few times) a simple service bounce is all that is needed?<br>
<br>
I suppose another cause of LDAP auth failover NOT working (but not always intuitive) would be cluster over wan (nodes in the cluster are not all on the same segment) and the sub node that LDAP auth is trying to bind from can't talk to the AD server.<o:p></o:p></span></p>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-GB" style="font-family:"Calibri",sans-serif">
<hr size="2" width="100%" align="center">
</span></div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-GB" style="font-family:"Calibri",sans-serif">From:
</span><span lang="EN-GB"><a href="mailto:dpagan@fidelus.com"><span style="font-family:"Calibri",sans-serif">dpagan@fidelus.com</span></a></span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><br>
To: </span><span lang="EN-GB"><a href="mailto:lelio@uoguelph.ca"><span style="font-family:"Calibri",sans-serif">lelio@uoguelph.ca</span></a></span><span lang="EN-GB" style="font-family:"Calibri",sans-serif">;
</span><span lang="EN-GB"><a href="mailto:cisco-voip@puck.nether.net"><span style="font-family:"Calibri",sans-serif">cisco-voip@puck.nether.net</span></a></span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><br>
Date: Mon, 6 Jul 2015 13:45:08 +0000<br>
Subject: Re: [cisco-voip] LDAP Authentication when CUCM publisher is down.<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#404040">LDAP authentication is used by Tomcat and isn’t just restricted to the Publisher server - Subscriber nodes handle this as well. DirSync is specific to synchronization
 of LDAP attributes and only runs on the Pub, so synchronization would definitely be affected if the Publisher is offline. I suggest to check out the Tomcat Security logs off CUCM for more info on user authentication against LDAP and your source of failure.
</span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#404040"> </span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#404040">So to answer your question, LDAP authentication should still work when the Publisher is offline.</span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#404040"> </span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#404040">For the UCCX agent concern, authentication of agents occur over AXL to CUCM, so if the AXL server is the Publisher, and that’s offline or experiencing issue w/ Tomcat
 during an authentication attempt by the UCCX agent, then I would imagine seeing a failure. AXL and Tomcat Security logs off the UCM side should shed some light on that problem</span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#404040"> </span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#404040">As for SSO, I checked w/ my teammate and, in his experience, SSO can be handled by Subscriber nodes assuming the metadata was imported to those servers - authentication
 occurs against the IdP and not CUCM so this seems logical to me as well.</span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#404040"> </span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#404040">Hope this helps.</span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#404040"> </span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#404040">- Dan</span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#404040"> </span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif;color:#404040"> </span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<div>
<div style="border:none;border-top:solid windowtext 1.0pt;padding:3.0pt 0in 0in 0in;border-color:currentColor currentColor">
<p class="MsoNormal"><b><span lang="EN-GB" style="font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-GB" style="font-family:"Calibri",sans-serif"> cisco-voip [</span><span lang="EN-GB"><a href="mailto:cisco-voip-bounces@puck.nether.net"><span style="font-family:"Calibri",sans-serif">mailto:cisco-voip-bounces@puck.nether.net</span></a></span><span lang="EN-GB" style="font-family:"Calibri",sans-serif">]
<b>On Behalf Of </b>Lelio Fulgenzi<br>
<b>Sent:</b> Monday, July 06, 2015 9:16 AM<br>
<b>To:</b> </span><span lang="EN-GB"><a href="mailto:cisco-voip@puck.nether.net"><span style="font-family:"Calibri",sans-serif">cisco-voip@puck.nether.net</span></a></span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><br>
<b>Subject:</b> Re: [cisco-voip] LDAP Authentication when CUCM publisher is down.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif">This has been our experience as well. Glad you started this thread. It's seems like a huge single point of failure to me for such an integral part of the process. I suspect hunt
 group login would also be affected. <br>
<br>
Sent from my iPhone<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><br>
On Jul 6, 2015, at 5:02 AM, Matthew Collins <</span><span lang="EN-GB"><a href="mailto:mcollins@block.co.uk"><span style="font-family:"Calibri",sans-serif">mcollins@block.co.uk</span></a></span><span lang="EN-GB" style="font-family:"Calibri",sans-serif">> wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif">Hi All,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif">CUCM 10.5
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif">Just trying to get some conformation, When LDAP Synchronization and authentication is enabled this is performed by the DirSync process that only runs on the CUCM Publisher. So
 If we lose the CUCM Publisher for whatever reason it would seem that the Authentication also fails due to the single point of failure of DirSync. Should LDAP authentication still work if the CUCM Publisher is still down.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif">So for LDAP users this would stop them signing in to Jabber clients and UCCX agents who are ldap’ed synced logging into the finesse webpages. Does anyone know is SSO is resilient
 on the CUCM publisher or would SSO still work in a Publisher outage. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:10.0pt;font-family:"Century Gothic",sans-serif;color:#009DB1">Regards</span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:10.0pt;font-family:"Century Gothic",sans-serif;color:#009DB1"> </span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:10.0pt;font-family:"Century Gothic",sans-serif;color:#009DB1">Matthew Collins
</span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif"> <o:p></o:p></span></p>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span lang="EN-GB">_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a></span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><br>
_______________________________________________ cisco-voip mailing list </span><span lang="EN-GB"><a href="mailto:cisco-voip@puck.nether.net"><span style="font-family:"Calibri",sans-serif">cisco-voip@puck.nether.net</span></a></span><span lang="EN-GB" style="font-family:"Calibri",sans-serif">
</span><span lang="EN-GB"><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank"><span style="font-family:"Calibri",sans-serif">https://puck.nether.net/mailman/listinfo/cisco-voip</span></a></span><span lang="EN-GB" style="font-family:"Calibri",sans-serif"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</body>
</html>