I recently installed Qlikview 10 server on a Windows 2008 server. Although Qlikview documents can be seen on the server and on remote PCs (by passing Windows user name and password) using Rich Clien,. However, visiting Accesspoint (http://CTSRV1/qlikview) on the server and on remore PCs , doesn't show any document as shown below. Any idea why?
Also, how can users pass their Windows credential to access Qlikview documents from remote PCs over the Internet? These PCs are in differet work group and can communicate with Qlikview server over the Internet.
Check that anonymous authentication is disabled in the server (QlikView Enterprise Management Console, System, Setup, QlikView Server, click on the server, right pane, Security) and that the site is not listed under the "Intranet" section of Internet Explorer. If so, when the Accesspoint doesn't get any credentials will ask for user and password (similarly as what happens when you access it from any browser than Internet Explorer).
I set "prohibit anonymous authentication" in QEMC and disabled anonymous in IIS admin (I don't have Qlikview Web Server) but still on the local server, I receive below error in IE. Users on remote PCs receive error "You do not have permission to view this directory or page." on their IE. I downloaded IE plugin for remote users but still the error persists.
I have Anonymous authentication, ASP.NET impersonation and Forms Authentication disabled in IIS admin for Qlikview and default web sites.
Server Error in Application "DEFAULT WEB SITE/QLIKVIEW"
Internet Information Services 7.5
HTTP Error 401.2 - Unauthorized
You are not authorized to view this page due to invalid authentication headers.
Detailed Error Information
IIS Web Core
Not yet determined
Not yet determined
Most likely causes:
No authentication protocol (including anonymous) is selected in IIS.
Only integrated authentication is enabled, and a client browser was used that does not support integrated authentication.
Integrated authentication is enabled and the request was sent through a proxy that changed the authentication headers before they reach the Web server.
The Web server is not configured for anonymous access and a required authorization header was not received.
The "configuration/system.webServer/authorization" configuration section may be explicitly denying the user access.
Things you can try:
Verify the authentication setting for the resource and then try requesting the resource using that authentication method.
Verify that the client browser supports Integrated authentication.
Verify that the request is not going through a proxy when Integrated authentication is used.
Verify that the user is not explicitly denied access in the "configuration/system.webServer/authorization" configuration section.
Create a tracing rule to track failed requests for this HTTP status code. For more information about creating a tracing rule for failed requests, click here.
Links and More InformationThis error occurs when the WWW-Authenticate header sent to the Web server is not supported by the server configuration. Check the authentication method for the resource, and verify which authentication method the client used. The error occurs when the authentication methods are different. To determine which type of authentication the client is using, check the authentication settings for the client.
I'm not sure if the original poster resolved his issue, but IIS anonymous authentication must in fact be disabled as Miguel mentioned. If the users are on the same intranet as the QVS, then the default IE security setting will send their Windows credentials automagically. If the users are outside the domain, they will see a Windows login box, where they'll be able to enter their credentials. Either way, it should work.
The first step is to make sure that the users are authenticating, then we can deal with authorization. In the top-right corner of the AccessPoint, you can see the words "Logged in as." If this is followed by nothing, then authentication is failing. Note (!!) if you see nothing here, it does not mean that the user is logged on as Anonymous, but rather that there's a contradiction in your security structure somewhere (for example, if you prohibit Anonymous authentication in the QEMC but have only Anonymous Authentication enabled in IIS). An interesting quirk with Server 2008 is that Windows Authentication is not installed by default--make sure it's installed and enabled on all virtual directories, and Anonymous Authentication is disabled.