What is the Impact of Distribution Task on Security

[rob_insley]

We are migrating from a standalone server to a  separate Publisher /QVS Deployment. As part of this change we are introducing a Distribution Task as opposed to having The Source Document Refresh in situ (Same Source/Mounted Folder)   

However, when introducing a Distribution Task  it appears to impose some changes on the Security.    Section Access on the document in question is designed to use OS_USER and when just a reload task is defined, Users can gain access to their document according to their Windows Login.  However, when a distribution task is added to distribute to a QVS then the same users now get prompted for user credentials.

Is this expected behaviour and how can I keep the same functionality that existed prior to this change, namely Section Access Data Restriction based on OS_USER.

Thanks in advance.

[Brett_Bleess]

Rob, the most likely issue is the QV Service Account record in Section Access not being setup correctly.  The only real way to troubleshoot this is to load the Section Access table as a normal table instead of Section Access, this will allow you to see the table in the data model and check to see how things align in relation to the data elements you are trying to reduce.  I am including a link to a Design Blog post on Section Access as well, there are some additional blog posts at the bottom of this post, two related to dynamic reduction etc., hopefully these will assist you in figuring out where things are going wrong, but from what you describe, it should be an issue with the Section Access record, or in how you configured the Distribution settings on the task, did you do specific users or what there?

https://community.qlik.com/t5/Qlik-Design-Blog/A-Primer-on-Section-Access/ba-p/1465766

Regards,
Brett

[rob_insley · Accepted solution]

Brett ,

Thank you,  I managed to resolve this .  I didn;t expect a Distribution to behave any differently to a straight reload. But as you describe when Strict Exclusion is enabled on the document it will reduce the document according to the Service Users access, as controlled by Section Access and Section Application.    The section access on our document uses OS_USER and then restricts to the rest of the model via USERNAME.  This was causing the Data reduction.  I amended the section access so that the Service User had a * in USERNAME  and this did the trick.

Thanks for taking the time to reply.

[Brett_Bleess]

Hey Rob, just be careful using * though, what that really means is only the values loaded for other users, so if there are values in the reduction field(s) that do not belong to any users, even the service account will fail to load those, which may screw up the analysis or resulting app etc.  

The only way of which I know to completely work around this issue is to create a 'link' table for the service account that contains all the possible values into a single reduction value which is only used for the service account...  This will allow things to work as well.  Hopefully this makes sense.  I am going to mark your post as the solution though, I just wanted to add this to be sure you do not get bitten by something else.

Regards,
Brett