I've had this problem in at least one machine in every QlikView project since the past year. The problem seems to be a combination of the version of the operating system and the version of Internet Explorer. Try disabling the Protected Mode in Internet Explorer, but the only 100% sure solution is that the user connects to the server through QlikView Developer.
Thanks for the responses.
Still not sure what is happening. I tried accessing QV via Firefox and IE. Tried put IE into compatibly mode.
I was able to get Firefox and IE to prompt for credentials. It not matter if I typed. The screen just sat at 'Logged in as...'
Tried adding QV as a 'Trusted Site.' Reinstalled IE.
I would start by trying in stand-alone QV on the failing machine and do a direct Open In Server. The reason is that authentication will be done in a slightly different way compared to AP.
If this works, my next step would be to check if you have a Local User Account on the machine named exactly the same as the domain account and with the exact same password. If you do it might be that the NTLM challenge is built for the wrong account. I assume you're using QVWS as a web server so pay attention it does not support Kerberos, only NTLM (as opposed to IIS). If you do run IIS I would create a simple test asp-page, protect it with IWA and try accessing it from the client.
Another thing to look for is the security settings for the zone in Internet Explorer.
Go to Tools->Internet Options->Security and select Local intranet.
First check that the URL is in this zone (by pressing the Sites-buttonm then the Advanced button). If not, add it.
If you customized the security level for this zone I suggest you press "Reset all zones to default level"
If still no joy I suggest running Fiddler to trace the traffic or as a last resort Wireshark (but then you're down to TCP-level communication and it might not be easy to fully analyze the output).
Bjorn thanks for your through response.
I tried the IE security zones in my initial troubleshooting all to no avail. This occurs in Firefox to. I do not believe IE is to blame as much as I want to blame it.
It should be noted the user can access the IIS 'default' page.
The user was able to login into QV in the past. One day it worked. The next day it did not. I did not attempt to change any server side settings simply because I can login into another machine with the user credentials and the user can access QV just fine. This led me to believe it is unique with this users machine.
I have given the end user three options.
- Re image machine
- Use System Restore to before the issue happened
- Remove local user account on local machine. Login as user on domain. Let Windows rebuilt profile.
I am awaiting the end users response. I do not like any of the options but I know 1 will work for sure. 2 and 3 have a chance.
I will let you know which of these options worked.
Good find on the end user on this one. The end user runs Spybot on his machine as part of his routine.
Spybot reported he had a proxy setup on IE. We do not use a proxy...
After the end user turned this off, he was able access QV. This proxy must applied to Fire and IE.
So lesson learned. Check proxy settings.
Thanks for all the help on this issue.
Great that you found the root-cause. Some products "hook" into IE/FF etc by altering the proxy settings (Fiddler does it for example to be able to sniff the traffic between the browser and the network) so this is always a good thing to check.
Thanks for posting the solution to your problem as it might help others reminding the proxy settings :)