[Building Sakai] WebDAV and LDAP configuration

Tue Nov 4 13:26:58 PST 2014

Only one school's LDAP  (among 7 different schools) has been having an
issue to connect webdav in the same Sakai instance after we upgraded Sakai
2.9.3 from Sakai 2.8.X this summer.

We've done some research on this and also posted a question on Sakai dev
list. But didn't get any replies and still no solution.

Below is some of the debug output from the problem LDAP server during the
connections from our development instance. The connection seems to be
successfully established and after that no further communication. Looks
like java abandoned an apparently successful connection. We check the match
between Sakai's SSL and LDAP's cert and they are fine. Sakai tomcat log
showed almost the same result. The successful connection is established and
that [DEBUG] org.sakaiproject.user.impl.AuthenticationCache:88 -
getAuthentication SSJ: replaying authentication failure for
authenticationId=XXXXX  when the user entered the right pwd and user id.

  I hope somebody can shed some light on this issue: why Java abandons the
successful connection for this LDAP only.

132  >>> slap_listener(ldaps:///)

   133  conn=2 fd=14 ACCEPT from IP=XXX.XXX.XX.36:51356(IP=0.0.0.0:636)  <---
sakai dev instance

   134  TLS trace: SSL_accept:before/accept initialization

   135  TLS trace: SSL_accept:SSLv3 read client hello A

   136  TLS trace: SSL_accept:SSLv3 write server hello A

   137  TLS trace: SSL_accept:SSLv3 write certificate A

   138  TLS trace: SSL_accept:SSLv3 write server done A

   139  TLS trace: SSL_accept:SSLv3 flush data

   140  TLS trace: SSL_accept:error in SSLv3 read client certificate A

   141  TLS trace: SSL_accept:error in SSLv3 read client certificate A

   142  TLS trace: SSL_accept:SSLv3 read client key exchange A

   143  TLS trace: SSL_accept:error in SSLv3 read certificate verify A

   144  TLS trace: SSL_accept:SSLv3 read finished A

   145  TLS trace: SSL_accept:SSLv3 write change cipher spec A

   146  TLS trace: SSL_accept:SSLv3 write finished A

   147  TLS trace: SSL_accept:SSLv3 flush data

   148  conn=2 fd=14 TLS established tls_ssf=128 ssf=128 <----- SSL
established. The last we hear from sakai dev instance

   149  >>> slap_listener(ldaps:///)<----- Different connection begins
here. No further from "conn=2 fd=14"

   150  conn=3 fd=15 ACCEPT from IP=YYY.YYY.YYY.246:51353 (IP=0.0.0.0:636)

   [...]

   272  >>> slap_listener(ldaps:///)

   273  conn=4 fd=17 ACCEPT from IP=YYY.YYY.YYY.246:51356 (IP=0.0.0.0:636)
  <--- CAS auth box

   274  TLS trace: SSL_accept:before/accept initialization

   275  TLS trace: SSL_accept:SSLv3 read client hello A

   276  TLS trace: SSL_accept:SSLv3 write server hello A

   277  TLS trace: SSL_accept:SSLv3 write certificate A

   278  TLS trace: SSL_accept:SSLv3 write server done A

   279  TLS trace: SSL_accept:SSLv3 flush data

   280  TLS trace: SSL_accept:error in SSLv3 read client certificate A

   281  TLS trace: SSL_accept:error in SSLv3 read client certificate A

   282  TLS trace: SSL_accept:SSLv3 read client key exchange A

   283  TLS trace: SSL_accept:SSLv3 read finished A

   284  TLS trace: SSL_accept:SSLv3 write change cipher spec A

   285  TLS trace: SSL_accept:SSLv3 write finished A

   286  TLS trace: SSL_accept:SSLv3 flush data

   287  conn=4 fd=17 TLS established tls_ssf=256 ssf=256 <----- After SSL
established, communication ensues

   288  ber_get_next

   289  ldap_read: want=8, got=8

   290  ldap_read: want=55, got=55

   291  ber_get_next: tag 0x30 len 61 contents:

   292  ber_dump: buf=0x098b6c18 ptr=0x098b6c18 end=0x098b6c55 len=61

   293  ber_get_next

   294  ldap_read: want=8 error=Resource temporarily unavailable  <--- Just
reporting non-blocking I/O

   295  do_bind

   [...]

  6449  TLS trace: SSL3 alert write:warning:close notify

  6450  conn=2 fd=14 closed (slapd shutdown)<----- LDAP server finally
closes the abandoned connection during shutdown

  6451  TLS trace: SSL3 alert write:warning:close notify

  6452  conn=3 fd=15 closed (slapd shutdown)

  6453  TLS trace: SSL3 alert write:warning:close notify

  6454  conn=5 fd=17 closed (slapd shutdown)

  6455  TLS trace: SSL3 alert write:warning:close notify

  6456  conn=7 fd=21 closed (slapd shutdown)

  6457  slapd shutdown: waiting for 0 threads to terminate

  6458  slapd shutdown: initiated

  6459  ====> bdb_cache_release_all

  6460  slapd destroy: freeing system resources.

  6461  slapd stopped.

On Fri, Aug 22, 2014 at 4:41 PM, Sanghyun Jeon <euksa99 at gmail.com> wrote:

> Hello All,
>
> It turns out that only certain user group who needs to be authenticated
> with LDAP #A is having difficulty to connect WebDAV.
> Previously, tomcat log showed unknown cert error as follows:
>
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
>
> so we renew the LDAP cert and tomcat no longer shows the cert error. All
> ports are open from both ends. However, if this user group tries to login
> via WebDAV, they are still getting an error message: "There was a problem
> connecting to the server 'sakai.ourCollege.edu'. Contact your system
> administrator for more information".
>
> I hope somebody can point me in the right direction to resolve this issue.
>
> Thank you.
>
>
>
>
> On Tue, Aug 19, 2014 at 8:12 AM, Sanghyun Jeon <euksa99 at gmail.com> wrote:
>
>> Hello All,
>>
>> After Sakai2.9.3 upgrade, we are experiencing WebDAV connection issue
>> from one of app servers. We confirm that there is no firewall issue from
>> both ends. We have three clustered Sakai app nodes behind one apache server
>> as a load balancer. LDAP is used to authenticate WebDAV users, while CAS is
>> for login.
>> I did not configure the current systems so that I would like to revisit
>> the WebDAV connection with Sakai  in order to resolve this issue. However,
>> I cannnot find some useful documentations and I am wondering whether some
>> experienced experts guide me where I can find them or where I need to start
>> to check.
>> Thank you in advance.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20141104/824b9646/attachment.html 