cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jebeling
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 1 of 6

Why Windows 10 O365 Application Login Failures when Using MCP? - NlaSvc, msftconnecttest & NCSI

Jump to solution

Why do I get O365 application login failures when using MCP on Windows 10? When this happens I get a message stating "We are unable to connect right now" I also notice a warning on the connectivity icon in the bottom right of the task bar.

NCSI.JPG

The system shows a connectivity error even though MCP is allowing me to browse sites through McAfee Web Gateway Cloud Service.

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as a Solution and/or Kudo my reply so we can help other community participants?
5 Solutions

Accepted Solutions
jebeling
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 2 of 6

Re: Why Windows 10 O365 Application Login Failures when Using MCP? - msftconnecttest & NCSI

Jump to solution

The two errors shown (Connectivity Test and login failure in the app) are directly correlated. If connectivity status shows not connected, you won't be able to perform a new login. You will only see the unable to connect message when the network connectivity status shows not connected.

There are multiple possible causes of these errors. The basic issue though is that the MS connectivity test, running as the Network Location Awareness service (NlaSvc) which sets the Network Connectivity Status Indicator (NCSI), is wrong! All O365 applications like outlook.exe completely trust the status reported by this service! If the applications actually tried to reach the login sites they would be able to connect, but they don't even try!

So why is NlaSvc/NCSI reporting that there isn't any network connectivity when there is through MCP? There are two primary possibilities:

1) This problem most commonly occurs with VPNs and is noted by MS and is assumed fixed in the 2004 release of Windows 10. There are patches published for earlier versions 1909 and earlier should be patched if you are experiencing this issue.  https://docs.microsoft.com/en-us/windows/release-information/resolved-issues-windows-10-1903 Patch available for 1903 and 1909 https://support.microsoft.com/en-us/help/4554364/windows-10-update-kb4554364 Patches are also available for earlier versions

2) The network you are connected to doesn't resolve www.msftconnecttest.com or doesn't properly route TCP connections to that site on port 80.  So why wouldn't MCP intercept that redirect it and allow the test to succeed without a route and resolution? That is an excellent question!

Basically its because MS has never considered the possibility of a completely transparent network shim that intercepts and redirects web traffic via an explicit proxy request independent of network proxy settings. In their limited vision, the only possible scenarios are where a proxy is explicitly or automatically configured in the Internet settings, or the transparent proxy is external to the client. As such, their test will try to use a proxy, if one is configured (you don't configure one when using MCP), or it will just make the connection directly via TCP on port 80, but it will do so lower in the stack than where MCP resides.

The simplest solutions to situation 2) is to allow direct connectivity on port 80 to www.msftconnecttest.com with resolution of that FQDN. Alternatively the file connecttest.txt can be hosted locally on your network with DNS manipulation, or you can even go in and modify the registry settings to customize the service parameters. Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet

As per Microsoft it is not recommended to disable the probes because outlook.exe and other apps rely on NCSI.

There is not a lot of good information on NCSI and its operation as it has morphed over the years. In researching this issue I found these articles most useful:

https://support.microsoft.com/en-gb/help/4494446/an-internet-explorer-or-edge-window-opens-when-your...

https://superuser.com/questions/1484601/how-does-windows-ncsi-passive-probing-work

And just last week... July 20, 2020 Windows 10 2004 also has issues:

https://www.bleepingcomputer.com/news/microsoft/microsoft-investigating-windows-10-2004-no-internet-...

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as a Solution and/or Kudo my reply so we can help other community participants?

View solution in original post

jebeling
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 3 of 6

Re: Why Windows 10 O365 Application Login Failures when Using MCP? - msftconnecttest & NCSI

Jump to solution

Note that MS could fix problem 2 simply by having their applications try to login regardless of the status indicator reading, or preferably fixing the test to try higher in the stack even when a proxy isn't explicitly configured, or when the lower level test fails. 

Update 3/23/21.....the problem may be not the level of the stack that the request is made, but could  something else in how the tests flow through the stack. When MCP is deployed it uses the loopback interface and MCP may be processing the test probe and attempting to redirect it to the configured proxy, but for some reason the request might be dropped within the stack. In any case there still seem to be some issues in certain networks. Until this is addressed by Microsoft the best recommendation is to make all networks support resolution of www.msftconnecttest.com and route and allow connections on port 80 to the resolved address.

Further testing indicates that not only must microsoftconnecttest.com be resolved and reachable, but dns.msftncsi.com must also be resolvable! Its possible that caching of the resolution of the latter may account for inconsistent NCSI status reporting on a network change. I also found that leaving the default route completely empty, or having a default route that doesn't at least ARP to a live MAC will also cause issues. 

It appears that putting both of the following entries in etc/hosts will work even without external DNS resolution provided there is a route for www.msftconnecttest.com:

131.107.255.255        dns.msftncsi.com

13.107.4.52                 www.msftconnecttest.com

All my latest testing on Windows 10 Enterprise 10.0.17134 

3/25/21 And an additional note. From what I have observed, when a proxy is configured in internet settings with wpad, pac, or just straight settings, NlaSvc still doesn't actively try to use the proxy to pull connecttest.txt. Instead, it doesn't do any active probing and just relies solely on "passive probing" results to change the NCSI status. See my added POST below for more details.

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as a Solution and/or Kudo my reply so we can help other community participants?

View solution in original post

jebeling
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 4 of 6

Re: Why Windows 10 O365 Application Login Failures when Using MCP? - msftconnecttest & NCSI

Jump to solution

Another update. If a proxy is configured (explicitly, by PAC file URL, or by wpad) on the Windows 10 version I'm running, you don't even need to resolve any addresses and you don't even need to be able to reach msftconnecttest.com. All you need is a route to reach the proxy and the PAC file. However, as we've stated previously in this thread, you don't normally even configure a proxy when using MCP, that's the whole point.  Proxy traffic will bypass MCP by default unless (you are proxying on port 80 or intercepting the proxy port) AND you are not bypassing the proxy address in your MCP policy. 

So why did I even bother with this added reply? Another excellent question! Its because if you are clever you can create a PAC file to send almost all HTTP and HTTPS traffic DIRECT and since a PAC file is specified in Internet Settings, NlaSvc doesn't even try the active probes (DNS lookups and retrieving connecttest.txt from www.msftconnecttest.com) instead just looks for successful internet accesses through the proxy (passive probing).  Creating Internet settings using a fixed proxy and exceptions for almost everything to go direct would be a nightmare but is simple to implement in a proxy.pac file.

My Proxy is at 192.168.11.122 and is listening on 9090 and my test PAC file looks like this:

function FindProxyForURL(url, host) {

if (dnsDomainIs(host, "msftconnecttest.com") || dnsDomainIs(host, "www.msftconnecttest.com")){
return "PROXY 192.168.11.122:9090";
}

if (isInNet(dnsResolve(host), "13.107.4.52", "255.255.255.255")){
return "PROXY 192.168.11.122:9090";
}

return "DIRECT";
}

I'm not sure having www.msftconnecttest.com go through the explicit proxy is even required, but it doesn't hurt.

I'm actually hosting the PAC file on port 80 on the same MWG so I can selectively deliver this special PAC file only if MCP is used to make the request. MCP will intercept the request if MCP is installed with my MCP policy that DOES NOT bypass for the MWG destination address. I will add details in another post and link it from here. https://community.mcafee.com/t5/Web-Gateway-Cloud-Service/How-Can-I-Serve-Different-PAC-or-wpad-dat-...

When I set my Internet settings to use the URL http://192.168.11.122/proxy.pac in Internet Settings > Proxy on Windows 10 the registry will set Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet\ManualProxies to: 0http://192.168.11.122/proxy.pac and NlaSvc should stop active probing and should not go into a disconnected NCSI status, or if it does, it should recover to showing connected when is sees other services accessing the Internet. 

If the client is in an environment where it cannot access the PAC file it will fall back to the WPAD generated proxy configuration or if that isn't available everything defaults to DIRECT. 

One thing worthy of note here, if MCP cannot reach mcp.webwasher.com on port 80, or through the proxies configured in the policy, it will stand down, and if it stands down, the request for the PAC file won't get the MCP headers and MWG hosting the PAC file cannot distinguish whether or not the client has MCP. If that happens the client will get the PAC file used by systems that don't have MCP.

 

 

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as a Solution and/or Kudo my reply so we can help other community participants?

View solution in original post

fw_mon
Reliable Contributor
Reliable Contributor
Report Inappropriate Content
Message 5 of 6

Re: Why Windows 10 O365 Application Login Failures when Using MCP? - msftconnecttest & NCSI

Jump to solution

As always very helpful Jeff!

To reduce the latency and external dependencies it is also suggested to avoid dnsResolve function - it works perfectly in a test environment but will lead to problems in some situations.

View solution in original post

jebeling
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 6 of 6

Re: Why Windows 10 O365 Application Login Failures when Using MCP? - msftconnecttest & NCSI

Jump to solution

True. A PAC file that looks like this would also work fine and would be better:

function FindProxyForURL(url, host) {

if (dnsDomainIs(host, "msftconnecttest.com") || dnsDomainIs(host, "www.msftconnecttest.com")){
return "PROXY 192.168.11.122:9090";
}

if (isInNet(host, "13.107.4.52", "255.255.255.255")){
return "PROXY 192.168.11.122:9090";
}

return "DIRECT";
}

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as a Solution and/or Kudo my reply so we can help other community participants?

View solution in original post

5 Replies
jebeling
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 2 of 6

Re: Why Windows 10 O365 Application Login Failures when Using MCP? - msftconnecttest & NCSI

Jump to solution

The two errors shown (Connectivity Test and login failure in the app) are directly correlated. If connectivity status shows not connected, you won't be able to perform a new login. You will only see the unable to connect message when the network connectivity status shows not connected.

There are multiple possible causes of these errors. The basic issue though is that the MS connectivity test, running as the Network Location Awareness service (NlaSvc) which sets the Network Connectivity Status Indicator (NCSI), is wrong! All O365 applications like outlook.exe completely trust the status reported by this service! If the applications actually tried to reach the login sites they would be able to connect, but they don't even try!

So why is NlaSvc/NCSI reporting that there isn't any network connectivity when there is through MCP? There are two primary possibilities:

1) This problem most commonly occurs with VPNs and is noted by MS and is assumed fixed in the 2004 release of Windows 10. There are patches published for earlier versions 1909 and earlier should be patched if you are experiencing this issue.  https://docs.microsoft.com/en-us/windows/release-information/resolved-issues-windows-10-1903 Patch available for 1903 and 1909 https://support.microsoft.com/en-us/help/4554364/windows-10-update-kb4554364 Patches are also available for earlier versions

2) The network you are connected to doesn't resolve www.msftconnecttest.com or doesn't properly route TCP connections to that site on port 80.  So why wouldn't MCP intercept that redirect it and allow the test to succeed without a route and resolution? That is an excellent question!

Basically its because MS has never considered the possibility of a completely transparent network shim that intercepts and redirects web traffic via an explicit proxy request independent of network proxy settings. In their limited vision, the only possible scenarios are where a proxy is explicitly or automatically configured in the Internet settings, or the transparent proxy is external to the client. As such, their test will try to use a proxy, if one is configured (you don't configure one when using MCP), or it will just make the connection directly via TCP on port 80, but it will do so lower in the stack than where MCP resides.

The simplest solutions to situation 2) is to allow direct connectivity on port 80 to www.msftconnecttest.com with resolution of that FQDN. Alternatively the file connecttest.txt can be hosted locally on your network with DNS manipulation, or you can even go in and modify the registry settings to customize the service parameters. Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet

As per Microsoft it is not recommended to disable the probes because outlook.exe and other apps rely on NCSI.

There is not a lot of good information on NCSI and its operation as it has morphed over the years. In researching this issue I found these articles most useful:

https://support.microsoft.com/en-gb/help/4494446/an-internet-explorer-or-edge-window-opens-when-your...

https://superuser.com/questions/1484601/how-does-windows-ncsi-passive-probing-work

And just last week... July 20, 2020 Windows 10 2004 also has issues:

https://www.bleepingcomputer.com/news/microsoft/microsoft-investigating-windows-10-2004-no-internet-...

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as a Solution and/or Kudo my reply so we can help other community participants?

View solution in original post

jebeling
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 3 of 6

Re: Why Windows 10 O365 Application Login Failures when Using MCP? - msftconnecttest & NCSI

Jump to solution

Note that MS could fix problem 2 simply by having their applications try to login regardless of the status indicator reading, or preferably fixing the test to try higher in the stack even when a proxy isn't explicitly configured, or when the lower level test fails. 

Update 3/23/21.....the problem may be not the level of the stack that the request is made, but could  something else in how the tests flow through the stack. When MCP is deployed it uses the loopback interface and MCP may be processing the test probe and attempting to redirect it to the configured proxy, but for some reason the request might be dropped within the stack. In any case there still seem to be some issues in certain networks. Until this is addressed by Microsoft the best recommendation is to make all networks support resolution of www.msftconnecttest.com and route and allow connections on port 80 to the resolved address.

Further testing indicates that not only must microsoftconnecttest.com be resolved and reachable, but dns.msftncsi.com must also be resolvable! Its possible that caching of the resolution of the latter may account for inconsistent NCSI status reporting on a network change. I also found that leaving the default route completely empty, or having a default route that doesn't at least ARP to a live MAC will also cause issues. 

It appears that putting both of the following entries in etc/hosts will work even without external DNS resolution provided there is a route for www.msftconnecttest.com:

131.107.255.255        dns.msftncsi.com

13.107.4.52                 www.msftconnecttest.com

All my latest testing on Windows 10 Enterprise 10.0.17134 

3/25/21 And an additional note. From what I have observed, when a proxy is configured in internet settings with wpad, pac, or just straight settings, NlaSvc still doesn't actively try to use the proxy to pull connecttest.txt. Instead, it doesn't do any active probing and just relies solely on "passive probing" results to change the NCSI status. See my added POST below for more details.

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as a Solution and/or Kudo my reply so we can help other community participants?

View solution in original post

jebeling
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 4 of 6

Re: Why Windows 10 O365 Application Login Failures when Using MCP? - msftconnecttest & NCSI

Jump to solution

Another update. If a proxy is configured (explicitly, by PAC file URL, or by wpad) on the Windows 10 version I'm running, you don't even need to resolve any addresses and you don't even need to be able to reach msftconnecttest.com. All you need is a route to reach the proxy and the PAC file. However, as we've stated previously in this thread, you don't normally even configure a proxy when using MCP, that's the whole point.  Proxy traffic will bypass MCP by default unless (you are proxying on port 80 or intercepting the proxy port) AND you are not bypassing the proxy address in your MCP policy. 

So why did I even bother with this added reply? Another excellent question! Its because if you are clever you can create a PAC file to send almost all HTTP and HTTPS traffic DIRECT and since a PAC file is specified in Internet Settings, NlaSvc doesn't even try the active probes (DNS lookups and retrieving connecttest.txt from www.msftconnecttest.com) instead just looks for successful internet accesses through the proxy (passive probing).  Creating Internet settings using a fixed proxy and exceptions for almost everything to go direct would be a nightmare but is simple to implement in a proxy.pac file.

My Proxy is at 192.168.11.122 and is listening on 9090 and my test PAC file looks like this:

function FindProxyForURL(url, host) {

if (dnsDomainIs(host, "msftconnecttest.com") || dnsDomainIs(host, "www.msftconnecttest.com")){
return "PROXY 192.168.11.122:9090";
}

if (isInNet(dnsResolve(host), "13.107.4.52", "255.255.255.255")){
return "PROXY 192.168.11.122:9090";
}

return "DIRECT";
}

I'm not sure having www.msftconnecttest.com go through the explicit proxy is even required, but it doesn't hurt.

I'm actually hosting the PAC file on port 80 on the same MWG so I can selectively deliver this special PAC file only if MCP is used to make the request. MCP will intercept the request if MCP is installed with my MCP policy that DOES NOT bypass for the MWG destination address. I will add details in another post and link it from here. https://community.mcafee.com/t5/Web-Gateway-Cloud-Service/How-Can-I-Serve-Different-PAC-or-wpad-dat-...

When I set my Internet settings to use the URL http://192.168.11.122/proxy.pac in Internet Settings > Proxy on Windows 10 the registry will set Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet\ManualProxies to: 0http://192.168.11.122/proxy.pac and NlaSvc should stop active probing and should not go into a disconnected NCSI status, or if it does, it should recover to showing connected when is sees other services accessing the Internet. 

If the client is in an environment where it cannot access the PAC file it will fall back to the WPAD generated proxy configuration or if that isn't available everything defaults to DIRECT. 

One thing worthy of note here, if MCP cannot reach mcp.webwasher.com on port 80, or through the proxies configured in the policy, it will stand down, and if it stands down, the request for the PAC file won't get the MCP headers and MWG hosting the PAC file cannot distinguish whether or not the client has MCP. If that happens the client will get the PAC file used by systems that don't have MCP.

 

 

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as a Solution and/or Kudo my reply so we can help other community participants?

View solution in original post

fw_mon
Reliable Contributor
Reliable Contributor
Report Inappropriate Content
Message 5 of 6

Re: Why Windows 10 O365 Application Login Failures when Using MCP? - msftconnecttest & NCSI

Jump to solution

As always very helpful Jeff!

To reduce the latency and external dependencies it is also suggested to avoid dnsResolve function - it works perfectly in a test environment but will lead to problems in some situations.

View solution in original post

jebeling
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 6 of 6

Re: Why Windows 10 O365 Application Login Failures when Using MCP? - msftconnecttest & NCSI

Jump to solution

True. A PAC file that looks like this would also work fine and would be better:

function FindProxyForURL(url, host) {

if (dnsDomainIs(host, "msftconnecttest.com") || dnsDomainIs(host, "www.msftconnecttest.com")){
return "PROXY 192.168.11.122:9090";
}

if (isInNet(host, "13.107.4.52", "255.255.255.255")){
return "PROXY 192.168.11.122:9090";
}

return "DIRECT";
}

Was my reply helpful?

If this information was helpful in any way or answered your question, will you please select Accept as a Solution and/or Kudo my reply so we can help other community participants?

View solution in original post

You Deserve an Award
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community