1

I try to fetch some data from a Microsoft Dynamics Nav WebService. This service uses the NTML authentication.

If I open the webservice url in a browser and use the given credentials everything works fine.

For setting up the environment for the WebService Client, I used the command line to check whether everything is working fine, I was, at a specific point, unable to authenticate.

Thats the command I am using:

curl --ntlm -u "DOMAIN\USERNAME" -k -v "http://hostname:port/instance/Odata/Company('CompanyName')/Customer"

The command will prompt for the password. I copy in the password and everything is doing fine.

But when I use this command, with the password already included, it stops working and the authentication fails:

curl --ntlm -u "DOMAIN\USERNAME:PASSWORD" -k -v "http://hostname:port/instance/Odata/Company('CompanyName')/Customer"

The password contains some special chars, so I tried to use the percent encoding, which had no effect at all.

It is very difficult to research this kind of issue. Searching for curl + ntlm authentication issues provides a lot of results, but nothing is related to this specific kind of issue.

Does anyone of you guys already had experience with this kind of issue?

AlexB
  • 7,302
  • 12
  • 56
  • 74
sbonath
  • 11
  • 1
  • 3

3 Answers3

2

I had a problem with authentication because of cookies. I solved this containing cookies in txt file and using exactly this file through all requests. For example, after login request I saved this cookies: 

curl -X POST -u username:password https://mysite/login -c cookies.txt

And with next request I used this file like this: 

curl -X POST -u username:password https://mysite/link -b cookies.txt

This solution worked for me, I don't know if your problem is similar, but, I think, you may try this.

Sviatlana
  • 1,728
  • 6
  • 27
  • 55
  • Maybe the issue I have is described a little bit weak, but the issue is not the second request needs another authentication. My issue is, that as soon as I put the password to the initial request, the authentication fails. – sbonath Aug 26 '16 at 15:22
  • the -c solved the issue i was having on a SINGLE request. I spent the better part of 2 days debugging the NTLMSSP exchange using a Java client and cURL not even considering that the HTTP401 had nothing to do with the WWW-Authenticate/Authorization but rather a missing load-balancer "stickiness" cookie (i.e. i was hitting multiple IIS instances behind the load-balancer reverse proxy during the request/challenge/response sequence) – jamey graham May 06 '19 at 17:44
2

I was struggling with similar issue for a long time and finally I found this curl bug report #1253 NTLM authentication fails when password contains special characters (british pound symbol £) .

NTLM authentication in cURL supports only ASCII characters in passwords! This is still the case in version 7.50.1 on Ubuntu but I tested this on many different distributions and it is always the same. This bug also will break curl_init() in PHP (tested on PHP7). The only way to solve that is to avoid non ASCII characters in NTLM authentication passwords.

If you are using Python then you are lucky. Apparently Python developers rewrote cURL implementation and it works with non ASCII characters if you use HttpNtlmAuth package.

Draco
  • 450
  • 7
  • 12
  • ASCII-extended characters also won't work, I had an umlaut in my password and only upon removing it did the handshake work. – Balthasar Mar 13 '23 at 17:19
0

Try with nltm flag.

Something like this:

curl -v --proxy-nltm -u 'username:password' youproxy.com:8080 someURL


from > curl --help

 -x, --proxy [PROTOCOL://]HOST[:PORT] Use proxy on given port
     --proxy-anyauth Pick "any" proxy authentication method (H)
     --proxy-basic   Use Basic authentication on the proxy (H)
     --proxy-digest  Use Digest authentication on the proxy (H)
     --proxy-negotiate Use Negotiate authentication on the proxy (H)
     --proxy-ntlm    Use NTLM authentication on the proxy (H)
z atef
  • 7,138
  • 3
  • 55
  • 50