I am trying to authorize with NTLM auth, but can’t seem to get t right. I can authorize with Postman and NTLM auth there, but my script still get 401s…
Here is a simple version of the script:
import http from "k6/http";
import { check, sleep } from "k6";
export default function() {
let res = http.get("http://username:password@URL", {auth: "ntlm"});
console.log("Status code: " + res.status);
check(res, {
"status was 200": (r) => r.status == 200
});
sleep(1);
};
Is it any way to debug the NTML part? How do I know that it actually tried to authorized with NTLM?
Request output:
GET URLENDPOINT HTTP/1.1
Host: BASEURL
User-Agent: k6/0.25.0 (https://k6.io/)
Accept-Encoding: gzip
If removing the NTLM auth from Postman, the response is like the one from the script. If I type wrong password, I get a set-cookie in the response… It seems to me that k6 don’t try the NTLM auth.
Even though this point release didn’t directly touch the NTLM auth handling, there were still some significant changes in the HTTP code, so can you update to that version and see if the problem persists?
I assume you got the HTTP request and response with the --http-debug k6 flag - v0.25.1 fixes some things with it, so it will be helpful to upgrade and share the output of that k6 version.
I see that if I check this tag, I get the similar response in Postman (it needs to be unchecked):
Is it any functionality for this in k6?
I in the Postman console I see that when checked, I get a 401 and Postman runs 1 request. When unchecked, Postman runs 3 request, resulting in successful auth.
Is it any functionality for this in k6?
I in the Postman console I see that when checked, I get a 401 and Postman runs 1 request. When unchecked, Postman runs 3 request, resulting in successful auth.
There’s no such option in k6. I’m not sure about the precise postman NTLM implementation, but k6 should do something like the 3 requests postman would do when the checkbox is unchecked:
k6 sends a request to the remote server
the remote server sends 401 and some values needed in the response
k6 uses these values to construct the proper NTLM Authorization header and re-sends the authenticated request
So, can you run your test with k6 v0.25.1 and the --http-debug flag and post the results here?
I see from the repo that the NTLM support should do thing correctly…
It seems like we have some policy issues which make me unable to install the latest version these days, but I’ll do as soon as the permissions are updated. Meanwhile, can we try to figure something out with the information we currently have?
Thanks for pointing out the issue, I fixed the docs .
Regarding NTLM, the PR you linked is old, but yeah, k6 should handle NTLM auth correctly. We now even use a Microsoft library ( GitHub - Azure/go-ntlmssp: NTLM/Negotiate authentication over HTTP) to do the authentication… But I’m not sure how to proceed without having accurate debug information with your specific case
Sorry for the delay, but I’ve just installed the latest version.
The output now is more useful, and it seems like the cookie from the CHALLENGE request (the second of the three requests) is not set for the third and final.
Unfortunately, there’s no way to control the NTLM auth flow You could try to re-implement the NTLM authentication in a pure JS wrapper around the plain k6 HTTP request making methods, but it’d be prohibitively difficult and CPU-inefficient I see that there are node libraries like https://github.com/SamDecrock/node-http-ntlm/blob/master/ntlm.js for the most complicated bits, but converting them with something like browserify would be quite inefficient…
Difficult to say, sorry. I’ve tagged it for v0.27.0 for now, and we’re aiming to release v0.26.0 in a week… The complication in this case is that from a cursory look, fixing this bug seems to require a substantial refactoring in how we handle NTLM (and maybe digest) authentication, but I might be mistaken.
I have done some more debuging, and I see that the third request dont actually send the value in the set-cookie in Postman either. The major difference is whats sent in the third request:
Other differences:
NTLM vs Negotiate in the Authorization header
The base64 Authorization header is not equal in the first request
The third request has a much shorter Authorization header in Postman
The third request sends the cookie SSOCHALLENGE=NTC_CHALLENGE_DONE; SSOSESSION={session} in Postman
This looks a lot like a bug in the library we used which is from … .azure … so Microsoft. But we can’t confirm or deny it as we need a server to test with and as I commented I had no luck finding something public or running IIS.
Given what you have provided some additional specific configuration will be needed to replicate your case and given that … NTLM is not exactly the most used technology for now we are concentrating on releasing the next version of k6 and pushing forward other features and bug fixes.
At some point I am likely to try again to get an ntlm server working, but it’s unlikely to be in the next couple of months. If you can provide at least a testing environment or would like to try and fix it - we will try to help you, but otherwise it will probably be some months before we get a second try at figuring it out, sorry
.
I’ve created a new GitHub issue to track it: 
