Yes, I think so. But narrowing that down has been the challenge and it's
extremely difficult to put the blame squarely in one corner.
So, my question has been what exactly is the connectivity issue. Is it
W2008, Illiad or LDAP?

Since it works on port 389 I'd like to rule out ILLiad but I'm struck by
how a refresh on the browser allows the authentication.
The windows server and LDAP are managed by different groups, and are
different stacks, windows 2008 server vs Novell on linux.
Since LDAP is binding I assume the problem is with the Windows
configuration or certificate, or store.

To answer your last questions.
The servers are in the same data center, and an ldapadmin test from the
windows server is successful.
This is a new Windows server with the latest version of ILLiad. We bumped
up servers from W2003 to W2008
There's not much revealing in the logs, folks from Atlas System and OCLC
have looked at them.

Thanks



On 3/28/14 1:08 AM, "Riley Childs" <[log in to unmask]> wrote:

>I think it is a connectivity problem, are there servers located in the
>same data center, or on the same server?
>
>Riley Childs
>Student
>Asst. Head of IT Services
>Charlotte United Christian Academy
>(704) 497-2086
>RileyChilds.net
>Sent from my Windows Phone, please excuse mistakes
>________________________________
>From: [log in to unmask]<mailto:[log in to unmask]>
>Sent: ?3/?27/?2014 5:24 PM
>To: [log in to unmask]<mailto:[log in to unmask]>
>Subject: Re: [CODE4LIB] ILLiad and LDAP SSL connection issue
>
>Thanks, Forgot to mention that.
>We have the certificates in a Trusted Certificate store on the W2008
>server that resolved the cert errors we were initially getting.
>
>I'm not sure what 'binding with a service account with Domain Admin
>privileges' means in this case.
>Our LDAP is not AD, but Novell eDirectory (if that matters).
>Also, the bind to LDAP is successful; I would think an error at that level
>would throw an error rather than getting dropped on the response.
>
>
>--
>Programmer Analyst, Virtual Library Services
>
>MSK Research Library
>Memorial Sloan-Kettering Cancer Center
>
>
>
>
>On 3/27/14 4:48 PM, "Riley Childs" <[log in to unmask]> wrote:
>
>>Make sure the Active Directory SSL certificate is in the keystore of
>>whatever Illiad runs on and you are binding with a service account with
>>Domain Admin privs.
>>
>>Riley Childs
>>Student
>>Asst. Head of IT Services
>>Charlotte United Christian Academy
>>(704) 497-2086
>>RileyChilds.net
>>Sent from my Windows Phone, please excuse mistakes
>>________________________________
>>From: [log in to unmask]<mailto:[log in to unmask]>
>>Sent: ?3/?27/?2014 2:11 PM
>>To: [log in to unmask]<mailto:[log in to unmask]>
>>Subject: [CODE4LIB] ILLiad and LDAP SSL connection issue
>>
>>We have a strange problem with ILLiad, LDAP and a Windows 2008 server
>>using SSL on port 636.
>>
>>When I view the illiad logs it's clear the authentication only partially
>>completes as the request is sent, ldap binds/authenticates, but the
>>authentication isn't received by illiad.
>>The illiad log reports a time out. The odd thing is that the user can
>>sometimes click the submit button again, or even just refresh the login
>>page, and the authentication succeeds with the user getting to their
>>ILLiad home page.
>>
>>When I say that LDAP authenticates I mean we see the results on the logs,
>>and of course, that strangeness where hitting the refresh or submit
>>button takes a user to their home page. Had they not hit refresh or
>>re-submit, we'd see the timeout.
>>
>>We have no problems using non-ssl on 389 by the way.
>>Our Ldap server is Novell eDirectory server (now NetIQ) v8.8 sp5 on SLES
>>
>>Any ideas would be really helpful.
>>Thanks
>>Eric
>>
>>
>>
>>     
>>=====================================================================
>>
>>
>>
>>     Please note that this e-mail and any files transmitted from
>>
>>     Memorial Sloan-Kettering Cancer Center may be privileged,
>>confidential,
>>
>>     and protected from disclosure under applicable law. If the reader of
>>
>>     this message is not the intended recipient, or an employee or agent
>>
>>     responsible for delivering this message to the intended recipient,
>>
>>     you are hereby notified that any reading, dissemination,
>>distribution,
>>
>>     copying, or other use of this communication or any of its
>>attachments
>>
>>     is strictly prohibited.  If you have received this communication in
>>
>>     error, please notify the sender immediately by replying to this
>>message
>>
>>     and deleting this message, any attachments, and all copies and
>>backups
>>
>>     from your computer.
>>
>