NTLM Authentication Fails with TFS 2015

[ankitr42]

Environment

Node version: 8.11.1
Npm version: 5.6.0
OS and version: Windows 10, Build 14393.2007
vsts-node-api version: 6.5.0

Issue Description

Trying to use this API to connect to a TFS 2015 instance with NTLM authentication always fails.

Expected behaviour

NTLM authentication should succeed and WebAPI.create() should return the connection data.

Actual behaviour

I have some test code in a function as:

let serverUrl = "http://myserver:8080/tfs/DefaultCollection"
    consts client = require('vso-node-api')
    let authHandler = client.getNtlmHandler("myusername", "mypassword")
    let webApi = new client.WebApi(serverUrl, authHandler)

   webApi.connect()

The connect() call fails after the server sends a 401 Unauthorized response with the WWW-Authenticate header. I dug into the source code and, please correct me if I'm wrong, I think the typed-rest-client and the http-client libraries embedded in the vso-node-api package do not take into account the authentication handler being used for a request.
I traced the code flow for a connect() call, and I found that there is only 1 call to the handler.prepareRequest() method in httpclient.js. None of the other methods of the handler such as canHandleAuthentication(), handleAuthentication() get called.
Furthermore, the NTLM authentication handler ntlm.ts does not make any additions to the request object in the prepareRequest() method - which I think is correct as it's supposed to handle the authentication flow in the handleAuthentication() method - only that never gets called.

[stephenmichaelf]

Thanks @ankitr42 I will take a look! We may need to update the dependency version for typed-rest-client. There were changes made in that library to make NTLM work and I believe they happened just before the 1.0.4 release.

[ankitr42]

Thanks, @stephenmichaelf.

[ArtGangsta]

@stephenmichaelf I think the problem you're going to run into is that typed-rest-client, uses node-http-ntlm which works for NTLM, but is not truly integrated since it requires the user password. it does not use SSPI to do transparent auth (Integrated Windows Authentication / Negotiate)

I have looked around just a little bit, and the only module I found that works well out of the box for this is node-libcurl. They key there is that when you set curl options (setOpt), USERNAME needs to be set to empty-string and 'HTTPAUTH' to 'Curl.auth.NEGOTIATE'

With node-libcurl you can do anything that REST requires, including custom verbs such (via CUSTOMREQUEST).

The only problem I found with node-libcurl is that it doesn't use the certificate store on the client's machine, which means if you want to access https, you have to tell it to ignore bad certificate. Setting SSL_VERIFYPEER to false. That works almost all the time. One place it doesn't work is when you try to access "visualstudio.com" VSTS and you use a "Personal Access Token". It works fine if you use alternate cred, but if you use a "Personal Access Token", VSTS web site sends this thing in the response header that tells the client, "no, you cannot ignore the certificate" (Strict Transport Security). Actually, I haven't checked if it's always sent -- what I do know is that, curl will complain about it with PAT and not with alternate credentials.

Unfortunately this means node-libcurl cannot be used as the one-stop-shop for solving this problem, and no other solution seems to exist on node for single-sign-on.

It would be cool if node-http-ntlm supported Integrated Windows Authentication. The problem is that it uses node-httpreq internally and exposes that fact to clients so that they can pass-through configuration.

[nadavsinai]

It fails also with TFS 2017, even the latest vso-node-api doesn't have working NTLM support.
see #175

[namankanakiya]

Still failing as of 6.6.0

[damccorm]

Currently investigating. It looks instead of getting a 401 response (which we would expect), we're getting a 302 redirect message, which redirects us to a 203 with an empty response message. I think the only reason we're not getting issues with using PAT here is that it uses preauth - it may be that only preauth is effectively supported on the server side (in which case NTLM would not work). I'll continue to look into it and communicate with the team that owns this.

[damccorm]

It looks like currently, even for a call that returns a 401, like WebApi.getCoreApi() NTLM is not working. This looks like another issue on the server, as the www-authenticate header is not returning NTLM as an option. Not sure if this is because it is not supported at all or they are just missing that in the header response. Regardless, I'll log this with them and continue to communicate any updates here.

UPDATE - not sure if this is actually the issue, digging further.

[damccorm]

@ankitr42 @nadavsinai @namankanakiya we are actively investigating this right now. It would be helpful if you could answer these questions:

1. Was this ever working for you?
2. If it was working, what version of node-api/TFS were you using?

[namankanakiya]

It was never working for me

…

On Thu, Oct 4, 2018, 10:53 AM damccorm ***@***.***> wrote: @ankitr42 <https://github.com/ankitr42> @nadavsinai <https://github.com/nadavsinai> @namankanakiya <https://github.com/namankanakiya> we are actively investigating this right now. It would be helpful if you could answer these questions: 1. Was this ever working for you? 2. If it was working, what version of node-api/TFS were you using? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#172 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQewj7Q5Etd4wrb5NL-RuKgvFFSn_dKIks5uhksQgaJpZM4TRHFi> .