Cyberduck Mountain Duck CLI

#2931 closed defect (thirdparty)

NTLM authentication fails with bad request error

Reported by: jmccauley@… Owned by: dkocher
Priority: normal Milestone: 3.8
Component: webdav Version: 4.4.3
Severity: normal Keywords:
Cc: maratb@…, stefan.doehla@… Architecture: Intel
Platform: Mac OS X 10.6

Description (last modified by dkocher)

IIS 6.0 DAV server. Uploads fail with Bad Request error.

  • Log:
PUT /Logo/BMD_logo_pack.zip HTTP/1.1[\r][\n]
Content-Type: application/zip[\r][\n]
User-Agent: Cyberduck/3.1.1 (4457)[\r][\n]
Expect: 100-continue[\r][\n]
Content-Length: 346160[\r][\n]
Authorization: NTLM TlRMTVNTUAABAAAABlIAAAAAAAA4AAAAGAAYACAAAABKT0hOUy1NQUNCT09LLkNUR1VTQS5DT00=[\r][\n]
Host: central.bmdc.org:8080[\r][\n]
[\r][\n]
HTTP/1.1 400 Bad Request[\r][\n]
HTTP/1.1 400 Bad Request[\r][\n]
Content-Type: text/html[\r][\n]
Date: Thu, 29 Jan 2009 17:32:58 GMT[\r][\n]
Connection: close[\r][\n]
Content-Length: 35[\r][\n]
[\r][\n]


  • IIS log:
2009-01-29 17:24:14 W3SVC1 192.168.0.5 PUT /Logo/BMD_logo_pack.zip - 8080 - 69.17.57.7 Cyberduck/3.1.1+(4457) 401 2 5
2009-01-29 17:24:20 W3SVC1 192.168.0.5 PROPFIND /Logo/ - 8080 - 69.17.57.7 Cyberduck/3.1.1+(4457) 401 2 5
2009-01-29 17:24:20 W3SVC1 192.168.0.5 PROPFIND /Logo/ - 8080 - 69.17.57.7 Cyberduck/3.1.1+(4457) 401 1 0
2009-01-29 17:24:21 W3SVC1 192.168.0.5 PROPFIND /Logo/ - 8080 IGGY\JMCCAULEY 69.17.57.7 Cyberduck/3.1.1+(4457) 207 0 0
2009-01-29 17:24:21 W3SVC1 192.168.0.5 PROPFIND /Logo/ - 8080 - 69.17.57.7 Cyberduck/3.1.1+(4457) 401 2 5
2009-01-29 17:24:21 W3SVC1 192.168.0.5 PROPFIND /Logo/ - 8080 - 69.17.57.7 Cyberduck/3.1.1+(4457) 401 1 0
2009-01-29 17:24:21 W3SVC1 192.168.0.5 PROPFIND /Logo/ - 8080 IGGY\JMCCAULEY 69.17.57.7 Cyberduck/3.1.1+(4457) 207 0 0

  • IIS Error log:
2009-01-29 17:24:20 69.17.57.7 62801 192.168.0.5 8080 HTTP/0.0 Invalid - 400 - Verb -

Change History (8)

comment:1 Changed on Jan 29, 2009 at 6:24:20 PM by anonymous

Problem seems to go away if i turn on basic authentication instead of NTLM.

comment:2 Changed on Mar 20, 2009 at 9:27:06 PM by dkocher

  • Description modified (diff)

comment:3 Changed on Mar 20, 2009 at 9:28:04 PM by dkocher

  • Summary changed from DAV upload fails with "bad Request (400" to NTLM authentication fails with bad request error

comment:4 Changed on Mar 27, 2010 at 6:00:34 PM by dkocher

  • Resolution set to thirdparty
  • Status changed from new to closed

comment:5 Changed on Jul 17, 2010 at 12:21:56 AM by maratb

  • Architecture set to Intel
  • Cc maratb@… added
  • Platform set to Mac OS X 10.6
  • Resolution thirdparty deleted
  • Status changed from closed to reopened
  • Version changed from 3.1.1 to 3.5.1

I am experiencing this problem as well. The issue *can* be resolved by turning off NTLM authentication on the server; however, this is not an option available to me.

From the trace above (I am getting an identical trace), the problem appears to be a failure in the NTML challenge/response authentication sequence (http://www.innovation.ch/personal/ronald/ntlm.html). Curiously, it only happens on uploads - all other operations (that also require such a sequence) complete successfully - this can be easily observed by tracing those operations. For whatever reason, the response that Cyberduck send to the server once the server requests NTML authentication (during the upload operation) is greeted with Bad Request.

My server is Microsoft-IIS/6.0. This issues is preventing me from using Cyberduck, which is otherwise a very nice tool!

Last edited on Aug 24, 2010 at 6:35:14 AM by dkocher (previous) (diff)

comment:6 Changed on Nov 25, 2010 at 1:39:47 PM by dkocher

  • Milestone set to 4.0
  • Resolution set to duplicate
  • Status changed from reopened to closed

The issue is the file with a name https://central.bmdc.org/cyberduck/bar[.file that is not returned properly as bar%5bfile.

2010-11-25 13:29:30,605 [pool-1-thread-8] WARN  ch.cyberduck.core.dav.DAVPath - Listing directory failed:escaped absolute path not valid

Duplicate for #4527.

comment:7 Changed on Jan 8, 2014 at 1:37:13 PM by stefan döhla

  • Cc stefan.doehla@… added
  • Resolution duplicate deleted
  • Status changed from closed to reopened
  • Version changed from 3.5.1 to 4.4.3

The problem is still there, and it seems to me as a noob that the authentication method does not work for PUT. Other operations seem to work.

HEAD /Users/bla/ HTTP/1.1
Host: bla
Connection: Keep-Alive
User-Agent: Cyberduck/4.4.3 (Mac OS X/10.8.5) (x86_64)
Authorization: Basic bla

HTTP/1.1 401 Unauthorized
Content-Length: 1656
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Wed, 08 Jan 2014 12:01:39 GMT

HEAD /Users/bla/ HTTP/1.1
Host: bla
Connection: Keep-Alive
User-Agent: Cyberduck/4.4.3 (Mac OS X/10.8.5) (x86_64)
Authorization: NTLM blabla==

HTTP/1.1 401 Unauthorized
Content-Length: 1539
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: NTLM blabla==
X-Powered-By: ASP.NET
Date: Wed, 08 Jan 2014 12:01:40 GMT

HEAD /Users/bla/ HTTP/1.1
Host: bla
Connection: Keep-Alive
User-Agent: Cyberduck/4.4.3 (Mac OS X/10.8.5) (x86_64)
Authorization: NTLM blabla==

HTTP/1.1 200 OK
Content-Length: 1686
Content-Type: text/html
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Wed, 08 Jan 2014 12:01:40 GMT

PUT /Users/bla/bla.bla HTTP/1.1
Expect: 100-continue
Content-Length: 136691
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Host: bla
Connection: Keep-Alive
User-Agent: Cyberduck/4.4.3 (Mac OS X/10.8.5) (x86_64)
Authorization: Basic bla

HTTP/1.1 401 Unauthorized
Content-Length: 1656
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Date: Wed, 08 Jan 2014 12:01:40 GMT

PUT /Users/bla/bla.bla HTTP/1.1
Expect: 100-continue
Content-Length: 136691
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Host: blabla
Connection: Keep-Alive
User-Agent: Cyberduck/4.4.3 (Mac OS X/10.8.5) (x86_64)
Authorization: NTLM blabla==

HTTP/1.1 400 Bad Request
Content-Type: text/html
Date: Wed, 08 Jan 2014 12:01:44 GMT
Connection: close
Content-Length: 35

comment:8 Changed on Jan 9, 2014 at 4:59:12 PM by dkocher

  • Resolution set to thirdparty
  • Status changed from reopened to closed

Please look into the IIS error log for possible additional information what part from the request is not understood. The request we send looks sane.

Note: See TracTickets for help on using tickets.
swiss made software