Authentication with IIS10 on localhost not working except with signed on user account

[andrewleith]

Hi Björn,

We just got shiny new laptops with windows 10 and IIS 10 and we seem to be having trouble getting authentication going.

When I run the tests from my new machine against local IIS (10.0) I get a big 401 error. Here are the plugin logs:

    cypress:plugin:ntlm-auth Request to http://127.0.0.1:62972/ - pass on +1m
    cypress:plugin:ntlm-auth Created non-NTLM agent for target http://127.0.0.1:62972/ +1ms
    cypress:plugin:ntlm-auth Received valid config update +2ms
    cypress:plugin:ntlm-auth Request to http://localhost:80/ in registered NTLM Hosts +35ms
    cypress:plugin:ntlm-auth Created NTLM ready agent for client 127.0.0.1:63198 to target http://localhost:80/ +2ms
    cypress:plugin:ntlm-auth Sending  NTLM message type 1 +1ms
    cypress:plugin:ntlm-auth received NTLM message type 2 +7ms
    cypress:plugin:ntlm-auth Sending NTLM message type 3 with initial client request +9ms
    cypress:plugin:ntlm-auth NTLM authentication failed, invalid credentials. +5s
    cypress:plugin:ntlm-auth Removed agent for 127.0.0.1:63198 due to socket.close +2ms

For contrast, here are the logs for the same test run against IIS 8.5:

  cypress:plugin:ntlm-auth Request to http://127.0.0.1:62972/ - pass on +13s
  cypress:plugin:ntlm-auth Created non-NTLM agent for target http://127.0.0.1:62972/ +8s
  cypress:plugin:ntlm-auth Received valid config update +3ms
  cypress:plugin:ntlm-auth Request to http://app-dev.a.ca:80/ in registered NTLM Hosts +29ms
  cypress:plugin:ntlm-auth Created NTLM ready agent for client 127.0.0.1:63106 to target http://app-dev.a.ca:80/ +3ms
  cypress:plugin:ntlm-auth Sending  NTLM message type 1 +1ms
  cypress:plugin:ntlm-auth received NTLM message type 2 +159ms
  cypress:plugin:ntlm-auth Sending NTLM message type 3 with initial client request +4ms
  cypress:plugin:ntlm-auth NTLM authentication successful for host http://app-dev.a.ca:80/ +338ms
  cypress:plugin:ntlm-auth Removed agent for 127.0.0.1:63106 due to socket.close +161ms

Any help would be much appreciated as always :)

Thanks, Andrew

[bjowes]

Hi @andrewleith , I'm looking into this. I will have a backend service deployed on IIS 10 by next week, then I can test it on my side.

• Have you ensured that the authentication settings are identical on both IIS instances?
• I presume they work fine when you access the IIS 10 site with a browser and authenticate manually?

[andrewleith]

Thanks @bjowes.

As far I can tell, yes, the setups are identical. Yes, the app works normally from chrome.

[bjowes]

Hi @andrewleith , I have now successfully validated my plugin against an IIS 10 server. IIS is not locally installed though, but on a separate machine. Unfortunately that doesn't help you much... some ideas:

• use the latest version (0.9.2)
• have you tried accessing an IIS 10 site on another machine?
• make sure you allow NTLM as authentication method in IIS, not only "Negotiate" (Kerberos)
• triple check the credentials
• are you passing in the domain or workstation parameters to cy.ntlm? I haven't tested workstation that much but it shouldn't be required

If you still have no luck, you could try decoding the NTLM messages to ensure that the plugin is sending what you think it is sending. Use a capture tool like wireshark to grab the traffic (should be fairly straight forward since you aren't using https). Then inspect the http header 'Authorization'. The most interesting one should be the type 3 message, which is the second message sent from the plugin to the site. Wireshark provides some decoding, but you can also use this python script. Decoding it will show the actual domain/username sent.

[andrewleith]

Thanks for the update Björn.

My testing project runs without issue against my IIS 8.5 site. The only thing I'm changing to try out IIS10 is the URL, so I don't think credentials or any other coding errors are to blame here.

It's definitely positive that yours works though. I must be missing some IIS setting somewhere. Is it possible for you to show me what your IIS 10 install looks like? For example, mine looks like this:

[andrewleith]

I just noticed something. If I use my own account as the NTML credentials everything works fine. Its only when I use a different account that it doesnt work. That being said, using those other accounts works perfectly well in IIS8.5.

So it looks as though I have some sort of configuration problem on my hands. I'm still investigating.

[andrewleith]

Are you using the same account in your NTML credentials as your currently logged in user in windows? That's the only combination I can get working...

[bjowes]

Make sure you’re running IIS with admin priveliges! I’ve seen issues with IIS Express combined with a different user account than the logged in user if IIS Express isn’t running as admin.

And when I tested against IIS 10 it was with a different user account. But the IIS was on another machine so it’s not really the same thing.

tis 2 apr. 2019 kl. 15:22 skrev Andrew [email protected]:

Are you using the same account in your NTML credentials as your currently logged in user in windows? That's the only combination I can get working...

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/bjowes/cypress-ntlm-auth/issues/25#issuecomment-478992769, or mute the thread https://github.com/notifications/unsubscribe-auth/AER47Cv__urxWqwAwCPiOaPUgGcgvJiAks5vc1l7gaJpZM4cSaFM .

-- /Björn W

Skickat från min iPhone

[andrewleith]

Hmm, OK, I have no idea what's going on here. When i push the app to our new DEV server (also IIS10) it works fine with any credentials. Not sure why it won't locally. Will post back if I ever figure it out.

Thanks for your help.

[bjowes]

Hi @andrewleith, do you ever figure out why NTLM wouldn't work on your local machine?

[andrewleith]

Hey @bjowes - nope. I was playing with this again yesterday to see if I could make it work but it will only work with my own credentials. If I use any other account it gives me a 401. I'm not really sure what else to check.

For now our plan is to just run our tests against DEV, but when developing new tests this will be a huge pain so I am hoping to make some progress on getting things working here!

[bjowes]

Ok, thanks for the update. I intend to experiment with a local IIS 10 setup also. I'll rename this issue to better reflect the case.

[ThreadPitt]

Hi,

same issue here, cypress looks very promising and thanks so much for your work on that plugin!

Unfortunately, I don't get it to work on Win Server 2016 (IIS 10). I read thru all the issues here, and neither with IISExpress (VS 2017) nor the local IIS 10 it works, regardless of the user. I have a two machine setup, with an AD Controller on a separate machine. I use the domain parameter for the plugin, but whatever I do, I always get a 401. More than triple-checked the credentials. The logs look the same ("invalid credentials").

Did you find some time to look at the issue with the local IIS?

From what I understand the final test I could do would be to try out the IIS on another machine...

Thx Eau

[bjowes]

Hi @ThreadPitt , No, I haven't gotten around to dig deeper into this issue yet.

The fact that you are running locally on a Win Server gave me some new input to investigate. Found this interesting article on loopback check. Could you try it out? I would start out with method 2 just to validate that this is really the issue. When verified, enable the loopback check again and add the hostname(s) properly according to method 1.

If that doesn't help - since you already have two machines, could you try running the tests from the AD server?

[andrewleith]

I came across that article as well, unfortunately my machine is locked down. I've asked the admins to try it but nothing back yet. I'd love to hear it this fixes it!

Andrew

On Wed., Sep. 4, 2019, 3:43 p.m. Björn Weström, [email protected] wrote:

Hi @ThreadPitt https://github.com/ThreadPitt , No, I haven't gotten around to dig deeper into this issue yet.

The fact that you are running locally on a Win Server gave me some new input to investigate. Found this interesting article on loopback check https://support.microsoft.com/en-us/help/926642/error-message-when-you-try-to-access-a-server-locally-by-using-its-fqd. Could you try it out? I would start out with method 2 just to validate that this is really the issue. When verified, enable the loopback check again and add the hostname(s) properly according to method 1.

If that doesn't help - since you already have two machines, could you try running the tests from the AD server?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bjowes/cypress-ntlm-auth/issues/25?email_source=notifications&email_token=AAGJDROA6JID3R2VFLM2D33QH76UFA5CNFSM4HCJUFGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD54SGWI#issuecomment-528032601, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGJDRN4WYMHT6ERF3CVG4LQH76UFANCNFSM4HCJUFGA .

[bjowes]

If the machine is locked down, could you try binding your site to localhost:[some port] and run the tests against that address instead? As I understand it, the loopback check feature will not block auth to localhost.

[mattiaskagstrom]

I just noticed something. If I use my own account as the NTML credentials everything works fine. Its only when I use a different account that it doesnt work. That being said, using those other accounts works perfectly well in IIS8.5.

So it looks as though I have some sort of configuration problem on my hands. I'm still investigating.

I seem to have this exact issue. Authenticating with my personal account seems to work just fine, but with any other account i get a 401. (getting the same if i try with a non-existent account or wrong password) I have verified the account by starting chrome as a different user and logging in with the same username/password combo.

[mattiaskagstrom]

Yupp, Authenticating with a server seems to work, but not with localhost. I'm running Windows 10 and not server, I have tried "DisableLoopbackCheck" anyway but to no success.

[bjowes]

Hi @mattiaskagstrom - could you tell me if you are using SSO (Negotiate) or NTLM? I am guessing NTLM since you state you get the issue when using another account, but I wanted to verify since I have some suspicions about Negotiate flags used by SSO.

[mattiaskagstrom]

@bjowes You'll have to excuse my lacking knowledge in this area, I will try to explain but I'll probobly confuse the terminology.

IIS is set up to authenticate using windows accounts and the cororate proxy as well. The proxy responds with a 407 Negotiate. I authenticate using this code: cy.ntlm( ['server.example.local'], user.username, user.password, Cypress.env('domain') ); cy.ntlmSso(['server.example.local']);

[bjowes]

Ah. Corporate proxys that require authentication are not supported by Cypress or my plugin. If the site you are accessing is local, and it doesn't use any resources from the internet, it should work anyway. Otherwise this will be tricky. You can use proxying tools (like https://github.com/genotrance/px) to make cypress work with that, and potentially this plugin too, but I haven't tested such scenarios.

Secondly, you shouldn't call both cy.ntlm and cy.ntlmSso for the same hostname. Decide if you want manual setting of the user (cy.ntlm) or if the logged in user should be used (cy.ntlmSso). When both are set, I believe it will always use cy.ntlm, but I would have to check the source to be sure.

[mattiaskagstrom]

Oh ok. Yeah we have given up on trying to get through the proxy. I have removed the sso line, but i still get unauthorized on localhost.

Command: ntlm cypress_runner.js:199872 Ntlmhosts: Array(1)0: "localhost"length: 1__proto__: Array(0) cypress_runner.js:199872 Username: svcCypressAdm cypress_runner.js:199872 Domain: <redacted> cypress_runner.js:199872 Ntlmversion: 2

[bjowes]

Is this still an issue @mattiaskagstrom

[mattiaskagstrom]

I haven't tinkered with it for a while, but ill take a look during the week :)

[bjowes]

Closing stale issue. Please reopen if still relevant.