What we currently have right now is that we control everything using the QV section access while our file system is open to anonymous. Users see the whole list of applications and are prompted for a user / pass everytime they try to open an application.
What I would like to do is to have the Access Point filter the list of applications based on the user active directory authentification without any password prompt. I think that is possible if we move our QV server into the active directory and I set QVS to NTFS security. That I can arrange and test but if you have any recommendations you are welcome.
What I would like to know is if there is a way to link this with the QV section access in order to filter the data available within the applications while avoiding another user/pass prompt for the user.
I've read the QV Server Manual Reference but it did not give enough details to really understand how I should set it up. It seems to be possible but unclear to me at this point.
Finally, if anyone could explain to me the advantage of DMS security... I really don't get it. The reference manual mention user groups but it seems ankward to manage.
Absolutely, this is possible. But keep in mind that section access would not be necessary, strictly speaking, because you would already have filtered the users ability to view files by their NT identities. Basically, I'm not sure what the point would be of using their Windows usernames to check against section access if they wouldn't have been able to see the file in the first place if the NTFS permissions weren't correct. It would be a different story if you want a separate logon in section access, using a different username/password--that would just be a 2nd level of security, and would make more sense to me.
To answer your question, however, I would recommend using SIDs, since that way you don't run into typos as much. The section access would look like this, for example:
Section Access; Star is *; Load * inline [ACCESS,NTDOMAINSID ADMIN, S-1-5-21-125976590-467238106-1092489882 USER,* ]; Section Application;
The point of DMS...that's a loaded question DMS is very useful to perform functions that are not possible with NTFS security. 2 examples are connecting to non-Windows Directory Services and creating custom directories specifically for use with QlikView.
Thank you for your reply. There seems to be a bit of confusion. Let me express myself properly...
This is what I am aiming for regardless of how it is setup... - Users log on to their computer
- When they reach the QV access point (Via the IE plug-in), they only see the applications that they are allowed.
- When they open an application, they only see the data that they are allowed to.
For example, our sales application will present data for all divisions. However, users of each divisions should only have access to the division they are part of while corporate managers have full access to all divisions.
In that case, use the same section access code style I posted above, but add a field REDUCTION that will control what they can see. See pages 510-11 of the QlikView Reference Manual for more details. Alternatively, you can do this with Loop & Reduce in Publisher Enterprise, but only if your document has the proper field associations between data and username.
Adding the server to your domain you'll have the possibility to use QVS with NTFS security, automatically QVS will add a Directory Service Connector pointed to your AD. Users connecting to Access Point will be recognized automatically from windows authentication, the important thing is that you add in your section access your users enabled to access applications in the NTNAME field, check server manual for examples.
We've moved our QV server into the active directory but although I have access to the QVW folders and files, I still get a password prompt when I reach the Access Point (Before the list of apps opens). If I type in my user id and pass, the list is generated and I can browse fine.
In theory the user is authenticated when he logs onto his computer and since the QV server is now in the same domain, it's authentication should follow due to being in the AD.