URL and scenario's authenticate correctly on remote hosts
The same scenario fails on local Windows machine (where the Netprobe also runs). The problem only occurs on the localhost to the URL. The issue does not occur on any remote host accessing the URL.
The reason for it occurring is that its a feature of .NET3.5 SP1 and up to stop loopback when using Windows credentials.
Loopback Protection on Windows Server
This problem comes up on Windows Servers and lately also on Windows 10, or on Windows client machines running under custom policies. When attempting to log on locally on a local Web site using Windows account authentication the your username and password always fails when this policy is enabled. For Web Connection this affects the admin pages that rely on Windows authentication for access.
This problem is caused by a policy called Loopback Protection that is enabled on server OSs by default. Loopback Protection disables authenticating against local Windows accounts through HTTP and a Web browser.
Quick Fix: Disable Loopback Check
The work around is a registry hack that disables this policy explicitly.
Starting with Web Connection 6.21 and later you can run the following using the Console running as an Administrator:
c:\> console.exe disableloopbackcheck
To reverse the setting:
c:\> console.exe disableloopbackcheck off
To perform this configuration manually find this key in the registry on the server:
and edit or add a new key:
then sent the value to
1 to disable the loopback check (local authentication works), or to
0 (local authentication is not allowed).
Or more easily you can use Powershell:
New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -Value "1" -PropertyType dword
A workaround would be to specify URL as 127.0.0.1 in the sampler config should the above changes not be sanctioned.
You should consider the security implications of running these actions. Further reading materials can be found on Microsofts website.