How to avoid the prompt for USER ID with section access on Qlikview Server?

[erichuang]

My steps are as the followings:

1. Applying section access to document without NTNAME.

2. Saving and the close the document.

3. Putting the document to Qlikview Server.

4. Using ASP.NET with a local account of Qlikview Server to get web tickets.

(https://community.qlik.com/docs/DOC-3614)

5. Using web tickets to access the document on Qlikview Server.

6. while opening the document, there is always a prompt for user id.

My question is that I have used a local account of Qlikview Server to access the document, and the account is listed in the section access(ex: QVAdmin), and why I need to enter user id again? Is there any solution to avoid to enter the user id?

[Gysbert_Wassenaar]

Probably because the user id value in the ticket is not in the section access table. And make sure all the field names and the field values in the section access table are in UPPER case.

[Peter_Cammaert]

I think it's even worse. UserID&Password authentication don't cause some Single Sign-On to be applied. You will always get an authentication dialog when using UserID&Password.

Also be aware that those UserID values have nothing to do with Windows accounts that happen to be identical to the values in Section Access. UserID values only exist inside the QVW document, nowhere else. It is a Qlik Document-only security mechanism (also called "document security" IIRC)

If you want access to be automatic based on a previous authentication or login, use NTNAME with an AD, LDAP or custom domain.

[erichuang]

Thanks a lot! But It didn't work for my case.

[erichuang]

It seems I should disable the section access if I want to pass the prompt for user id.

Is there any mechanism as section access to set up if I disable the section access? Because I need something to filter data and objects by users.

Thanks a lot!

[Peter_Cammaert]

No that's not true. Section Access that uses the NTNAME field exclusively (i.e. without USERID and PASSWORD fields) doesn't need a dialog to ask for authentication information. NTNAME implies that authentication is done by someone else (most probably Windows AD) and this authentication information ("who your are exactly") will be supplied to QlikView by the environment.

• If your NTNAME account is present in Section Access, you will get in - no questions asked (and on condition that Data Reduction with Strict Exclusion leaves relevant data for you in the data model).
• If your account isn't present in Section Access field NTNAME, then you won't get in - also no questions asked. In that case you won't get a second chance to change your account because the system tells the document that you are that particular user with an account that shouldn't get in, every time over and over again.

There is one big additional advantage when using NTNAME instead of USERID for managing access to a document: every critical element in the authentication process (like passwords and rights) are managed by a trusted party (e.g. AD) in a single spot. And it comes with User Groups, something you don't have when using USERID & PASSWORD.

Best,

Peter

[siddharth_kulka]

Just discovered a bug in Qlikview 12.0 which I thought all Qlikies should be made aware of, if not known already.

Case 1 - works without any issues

section access;

temp:
LOAD * INLINE [
ACCESS,NTNAME,REGION
ADMIN,USI\siddharthkulkarni,CANADA
];

Case 2 - user ID prompt (same as above with a resident load)

temp:
LOAD * INLINE [
ACCESS,NTNAME,REGION
ADMIN,USI\siddharthkulkarni,CANADA
];

section access;

temp2:
noconcatenate load
ACCESS,
NTNAME,
REGION
resident temp;

section application;

drop table temp;

Bug:  Mixed case user ID (USI\siddharthkulkarni) works in case 1 but not in case 2. One would except it would pass or fail in both scenarios.

Conclusion- Please ensure all field names and values are in upper case as previously highlighted in this post.

[Brett_Bleess]

This is NOT a bug, the key thing you have missed is the requirement that the Section Access table have all field names and values loaded in UPPERCASE, lowercase and mixed case is NOT allowed if you want things to work properly.  Marcus called this out in his post as well, but folks missed his point there, so I wanted to reiterate it, so it was clear to everyone that runs across this in the future.

https://help.qlik.com/en-US/qlikview/12.0/Subsystems/Client/Content/Security.htm

From link above: All field names used in the transfer described above and all field values in these fields must be upper case, since all field names and field values are by default converted to upper case in section access.

Regards,
Brett