Can the ZFC in IE be forced to use supplied Ticket rather than Windows user-name? (vladg)

[#1]

Hi QlikTech, VladG, and fellow QlikView developers,

My Question: When running in Internet Explorer (IE), do you know of a way to force the ZFC to use the *supplied Ticket*, rather than the windows authentication data if it is available? For example, is there some configuration or setting (or code-change to an aspx file in the QlikViewAjax folder) that can be made, in order to instruct the ZFC to always ignore the Windows logged in user-name?

Background: We are building a system where the user-authentication in QlikView does not make use of Active Directory (AD), NTFS, Windows Login, etc.. instead, we have a separate single-sign-on (SSO) source of users, and we are relying on DMS to handle authentication on the QlikView side of things. We are using the AJAX zero footprint (ZFC) client. Things are working out mostly very well. We made many attempts and tried various combinations of settings with the hope of resolving this issue on our own, prior to seeking assistance here.

Problem: In an Intranet environment (or same-machine environment), when the browser is IE, our GetTicket/OpenDoc logic works fine and the document renders fine when the user is logged into Windows as a user who is part of the "QlikView Administrators" group... GOOD. Also when the browser is FireFox (FF), the logic works fine when the user logged into Windows is part of the "QlikView Administrators" group... GOOD. Continuing, when the browser is FF, the logic works fine when the user is NOT part of the "QlikView Administrators" group... VERY GOOD. But when the browser is IE and the user is NOT part of the "QlikView Administrators" group, even with a legitimate Ticket supplied, the logic fails and the ZFC fails to display the document in the browser (it is blank)... PROBLEM.

My Comments: I understand that IE behaves differently than FF in that IE supports "Integrated Windows Authentication", where it detects and trusts the user logged into Windows. It seems as though, when IE finds there is a user logged into Windows, the ZFC ignores the supplied Ticket and instead attempts to open the document using the credentials of the logged in user. In our realistic situation where the logged in user running IE is not part of the "QlikView Administrators" group, we need the ZFC to honor the supplied Ticket and use *that* to retrieve the document, rather than the name of the logged in user. (In QEMC, we do not and cannot add to the Document Authorization every possible Windows user-name that may connect to the system; we are adding Document Authorization for only our SSO user-names, and in a separate process retrieving Tickets based on those names.)

Scenarios:

A. IE, Windows logged in user is part of the "QlikView Administrators" group: the document displays.

B. PROBLEM: IE, Windows logged in user is NOT part of the "QlikView Administrators" group: no document displays. (When the user browses from a different machine over IIS to QVWEBSERVER, the document displays the top tabs then error message: "Lost connection to server. Reconnecting…", then "No connection" popup.)

C. FF, Windows logged in user is part of the "QlikView Administrators" group: the document displays.

D. FF, Windows logged in user is NOT part of the "QlikView Administrators" group: the document displays.

Environment: Windows Server 2008 R2, QVSERVER version 10, IE version 8.0, FF version 4.0.

Configuration: Server - DMS Authentication, QlikView Web Server - Authenticate NEVER, GetTicket.aspx/opendoc.htm, Client - AJAX zero footprint.

Many thanks in advance for your time and any ideas you might have!

D.Will, ATP Engineering

[#2]

RESOLVED.

After more research and trial and error, we managed to resolve this issue. It turned out to be a problem with the ZFC running in IE (or just a problem with IE?) when IE was launched with "Run as different user", in the start menu:

In our trials, we were attempting to simulate the QlikView experience of a user who is not a member of the "QlikView Administrators" group. Remote-connection constraints originally prevented us from actually logging into Windows as such user so, as a shortcut, we simply launched IE as the user (while already logged in as local admin).

This approach worked fine in Firefox, but with IE there were the "show-stopper" behaviors and errors mentioned in my message to the forum, above.

When we today abandoned that approach, and established the means to truly connect and log into Windows as the non "QlikView Administrators" user, IE performed well, and the qvw file rendered perfectly. Apparently, the "Run as different user" approach was giving us a false sense of failure, with respect to our GetTicket/OpenDoc architecture.

Update: (We are using GetTicket/OpenDoc)

A. IE, Windows logged in user is part of the "QlikView Administrators" group: the document displays.

B. IE, Windows logged in user is NOT part of the "QlikView Administrators" group: the document displays.

C. FF, Windows logged in user is part of the "QlikView Administrators" group: the document displays.

D. FF, Windows logged in user is NOT part of the "QlikView Administrators" group: the document displays.

Note 1: Interestingly, regarding the "Run as different user" approach, we also discovered that if a second tab in IE is opened then the qvw file renders fine in that! Bizarre. Only the first tab fails with the "Lost connection to server. Reconnecting…" message.

Note 2: I'll also mention that one of the behaviors we observed in one setup was that the document was completely blank, with no error message. In that situation we determined that the "Run as different user" was opening IE with "Active scripting" automatically *disabled* for the Local Intranet zone, thus preventing the AJAX zero footprint javascript code from running.

Going forward, we will not trust IE when it has been launched with the "Run as different user" option.

I hope this helps others that might have wandered down similar paths.

D.Will, ATP Engineering

[vgutkovsky · Accepted solution]

Didn't see this post yesterday, but I'm glad you got it resolved! By default, IE security settings pass Windows credentials if the QVS is on the intranet. This is set in IE >> Security. You can disable this for your users (who I'm assuming are internal?) either manually or through a GPO push. This way you don't need to have IE run as a different user, which is inconvenient for your users to remember.

Regards,

[#4]

That's great information, thank you Vlad.

Reading your responses to other people's past questions here has helped us get to where we are now.

We are relatively new to QlikView but over time hope to be able to do the same and assist others with what we've learned.

D.Will, ATP Engineering

[vgutkovsky]

You're very welcome, glad I could help!