Does QVDS override NTFS inheritance?

[rothtd]

Can someone help clarify what I am observing? I'm running QV 12.10 SR6 (12.10.20400.0) and it appears that when QVDS writes a QVW to AccessPoint it explicitly sets the NTFS permissions to be exactly what was set in the distribution properties of the task, and removes any inherited NTFS permissions from the file. Our AccessPoint directory is configured to inherit specific permissions, but these inherited permissions are missing on only the QVW's. If I manually create a text file in the AccessPoint directory the AD Groups from the parent are correctly inherited to the file I created. The *.meta and *.shared files also correctly list NTFS inherited permissions. Only the QVW files, created by the QVDS are missing the permission inheritance. Is this by design, or am I missing something in my configuration options?

For example - this QVDS task is writing three AD groups:

In the NTFS permissions of the QVW written to AccessPoint, I do see those 3 groups and the QV Service account. But, what I don't see is the other groups that should be in the NTFS permissions based on inheritance.

This problem surfaced the first time we tried to archive/delete a application in QV12 and our administrator didn't have permissions to do so. In the above example, given the NTFS permissions, the only ways to delete an app are to login as the QV Service account (which has full permissions on this file) or to take ownership of the file (using an account with Administrative Permissions) and then delete it.

Our QV11 environment didn't work this way - QV admins could easily delete unused applications and I believe it was do to membership in an AD Group granting full control permissions that was being inherited down from the root of the directory to all files in the AccessPoint directory. Also, I thought when Publisher wrote the QVWs it included inherited permissions on the file allowing this to work correctly. Perhaps I am not remembering it correctly though.

Thoughts? Did I miss something when configuring our QV12 environment? Do any of you running QV12 see that QVWs are inheriting permissions - or are they being overridden/removed by QVDS? Thanks in advance for any input.

[rothtd]

Update - I'm working with Qlik Support. They confirmed that QVDS overrides NTFS inheritance. They suggested I used the "document supervisor" and "document administrator" functionality to set specific NTFS permissions to allow deletion of a document in AccessPoint. I configured this and noted that the permissions are not written to the file until after a QVDS Service restart, and after the QVDS task is re-run. Even so, I am seeing the AD group I configured -> but it only has "read" NTFS permissions, so I still can't delete the QVW. Anyone else experience this?

[rwunderlich · Accepted solution]

In my experience, Publisher has always replaced all permissions on the qvw file with the permissions specified in the distribution -- and those are only Read permissions.

Inheritance is ignored because otherwise inheritance would also grant visibility to the document on access point.

Document Supervisor is just a way to easily make all documents in a folder available on Access Point to the supervisor id.  It doesn't grant anything above Read.

I've always had to take ownership with a windows Admin account to delete a file from the distribution (access point) directory. 

Perhaps someone knows of another way around, but this is the way I've done it in QV11 and QV12.  So yes, the QV Administrator needs windows admin on the server to take ownership.

BTW, if you use DMS mode you don't have these issues. In DMS mode, QV maintains a list of authorized users for the document in the .meta file.  The NTFS permissions are irrelevant and are not updated by Publisher

-Rob

[rothtd]

Thanks, Rob. Not what I wanted to hear, but I think you are probably correct. I'll update the notes as I hear back from support.

[rothtd]

Qlik Support has confirmed what Rob stated. QVDS intentionally overrides Windows inherited NTFS permissions, and any permissions it writes will have Read access (except the service account which gets full control permissions). Therefore, when using NTFS permissions a QV admin will need appropriate Windows level permissions to take ownership of a QVW in AccessPoint and delete it (or utilize the QV Service account to do so).

[rothtd]

As a follow up, I modified the AD group granting my permissions to have full control. Once this was done, I was able to delete the QVW without taking ownership, and without being Windows Admin. Basically, there is a AD group granting full control (and all other permissions) to the AccessPoint directory, and even though for QVWs QVDS overrides the NTFS permissions I can still delete the QVW without taking ownership. In case anyone is trying to duplicate this, I'll add that all QVWs include other AD groups setup in QMC which get read-access (all get a QV-Admins group which I'm a member of). Not sure if this would make a difference in duplicating my situation or not.