Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
Anonymous
Not applicable

Section Access via AD User

Hello,

I am having a problem with Section Access.

Symptoms:

In the Access Point, when I activate "Strict exclusion" in the app before reload and publish I am denied access alltogether. When I deactivate it, I see everything. Tells me that somehow the given section access options don't match properly with the data in the app.

What I tested:

I thus loaded the section access data, but not in the section access area of the script. Thus basically disabling section access and making the user data part of the normal data model for debugging purposes. And then I put the following things in textboxes to see what matched and what didn't:

NTNAME = OSUser()

NTNAME = UPPER(OSUser())

Both are true. What else could be going wrong? I am at a loss for more ideas to debug this.

Is OSUser() not always the NTNAME to use in Section Access?

In the desktop client (with a different NTName on a different computer) it works as expected.

We are using QlikView Publisher and I publish the app for my specific user.

Any ideas? Thanks! 🙂

Sandro

5 Replies
JonnyPoole
Employee
Employee

What security are you using for QlikView Server authorization.  AD ? Header Authentication ? Ticketing ?

i believe OSUSER() = QVUser()    ..(where qvuser is the user in section access) when you are using AD, but not necessarily in other authorization configurations

rwunderlich
Partner Ambassador/MVP
Partner Ambassador/MVP

"Tells me that somehow the given section access options don't match properly with the data in the app."

Yes. If you are getting access denied with Strict Exclusion, that means your userid is not linking to any specific data. So take a look at the reduction field you are using.

-Rob

eduardo_sommer
Partner - Specialist
Partner - Specialist

Is your user (in section access) linked to any data in sectiona application. If it is not, all data will be reduced

Eduardo

Anonymous
Not applicable
Author

Rob, Eduardo:

Yes, it matches up properly. My indication for that is:

1. It works in the desktop version (so the data modell seems to work, the data in the Access Point is the same as in the Desktop version)

2. It works when I deactivate the section access and load the access data as a normal table. Selecting my user leads to what I would expect with Section Access.


Jonathan:

We are not administering the Server ourselves, so I am not 100% sure. All the documentation talks about AD groups for access management though, so I guess that is what the server uses for authorization as well. The QVUser() doesn't deliver any value in the application in the Access Point, so that didn't get me anywhere either.


Thanks so far guys, any more ideas?

Anonymous
Not applicable
Author

Alright guys, we found the solution. I remember having read in other places about some of the facts, that I'll represent, but as I at least wasn't aware of all the implications, I'll post then again here:

1. The Publisher user has to be in the section access as an admin for the whole publishing routine to work. That I had read and the publishing routine _did_ work.

2. While publishing the Publisher will reduce the file to whatever reduction value is given to him in the section access. It had assigned '<ANY>', which is our placeholder for all data, so I didn't expect a problem. (Inspired by Generic keys)

3. BUT if the user is assigned to a concrete value (as I was), the '<ANY>' doesn't match anymore. Yes, all data stays in the application. But the other reduction field values are removed.

That also explains why I hadn't seen the misfit before:

1. In the Access Point, because the reduction hadn't taken place, because section access was off.

2. In the Desktop application, because the reduction hadn't taken place, because there was no publishing step.

The solution:

Have the publisher user in the section access, but assign the * to assign all values, which are mentioned anywhere in the reduction field. This way the reduction field values will be reduced to exactly the relevant fields.

I suspect, that you might run into issues with the *, if you don't use "Strict exclusion". Then the data will be reduced and you'd expect some users to see "everything", the new "everything" being the reduced state.

Thank you for the input and I hope my explanation helps somebody in the future 🙂

Sandro