[jcifs] Davenport - cannot mount from windows 7

[Michael B Allen]

On Sun, Apr 13, 2014 at 12:19 PM, Vladislav Kurz
<vladislav.kurz at webstep.net> wrote:
> Dear developers,
>
> I'm not sure if I'm asking on the right place, so pleas forgive and redirect
> me if so.
>
> I wanted to offer (seamless) webdav acces to windows clients, and found the
> davenport project. At first glance I have jumped with joy - it was exactly
> what I wanted. But after installing end testing my joy has disappeared.
>
> Browser access works perfectly without even touching any configuration. But
> I was not able to "map drive" from windows. Neither win 7, nor server 2003
> or 2012. I have tried lots of stuff - disabling NTLM auth, allowing
> plaintext basic auth (both in windows registry and davenport), enabling SSL,
> moving jetty to default ports (80, 443). Sometimes windows did not even ask
> for password, and apparently (tcpdump) even did not connect at all. Perhaps
> some caching of failures is at work, or what. Finally I focused on getting
> windows 7 to work. (It seems that server 2012) does not even have a webdav
> client installed by default.).
>
> I have tried other WebDAV clients (cadaver for Linux and BitKinex for windos
> - both work just fine) Finally I got to a point where I could capture some
> commutication between windows and davenport. Plaintext basic auth seems to
> work, and this is the last request and response (formatted to fit on line):
>
> PROPFIND /esix-file HTTP/1.1
> Connection: Keep-Alive
> User-Agent: Microsoft-WebDAV-MiniRedir/6.1.7601
> Depth: 0
> translate: f
> Content-Length: 0
> Host: 192.168.220.136
> Authorization: Basic *******SECRET*******==
> Cookie: JSESSIONID=59hr3uicxp4f
>
>
> HTTP/1.1 207 Multi Status
> Transfer-Encoding: chunked
> Date: Sun, 13 Apr 2014 15:50:47 GMT
> Server: Jetty/4.2.27 (Linux/3.2.0-4-amd64 amd64 java/1.6.0_27)
> Content-Type: text/xml; charset="utf-8"
>
> 352
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <multistatus xmlns="DAV:"
> xmlns:w="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/">
>  <response>
>   <href>http://192.168.220.136/esix-file</href>
>   <propstat>
>    <status>HTTP/1.1 200 MultiStatus</status>
>    <prop>
>     <displayname>esix-file/</displayname>
>     <resourcetype><collection/></resourcetype>
>     <ishidden w:dt="boolean">0</ishidden>
>     <getcontenttype>httpd/unix-directory</getcontenttype>
>     <supportedlock>
>      <lockentry>
>       <lockscope><exclusive/></lockscope>
>       <locktype><write/></locktype>
>      </lockentry>
>      <lockentry>
>       <lockscope><shared/></lockscope>
>       <locktype><write/></locktype>
>      </lockentry>
>     </supportedlock>
>     <lockdiscovery/>
>     <iscollection w:dt="boolean">1</iscollection>
>     <isreadonly w:dt="boolean">1</isreadonly>
>    </prop>
>   </propstat>
>   <propstat>
>    <status>HTTP/1.1 404 MultiStatus</status>
>    <prop><getetag/></prop>
>   </propstat>
>  </response>
> </multistatus>
>
>
> Do you have any idea what might confuse the windows web client? Why is there
> that last part with 404 status? Is there any way how to get it working?

Vladislav

The Davenport project is super old totally dead. And because it used
the old NTLM man-in-the-middle technique, it cannot be fixed. It would
have to use Kerberos and use delegation to use the client's
credentials to access resources at the user. The only reason the
project hasn't been deleted from sourceforge is because it hosts the
documentation about the NTLM protocol by Eric Glass.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/