Urgent - mistake in section access

[#1]

Now i can not open my own qvw file. Please help!

[#2]

Restoring  from a backup may be your only solution.

Stephen

[#3]

Oh.. no. Does qlikview's NT section access expect all capital NT id? Because my nt id is all small letters.

If this is indeed non-recoverable, qlikview must do something to fix it. Why can't the file 'owner' always be able to open it? Or company's designated 'qlikview master admin' or something?

It seems quite ridiculous that a file gets permanantly locked out due to a dev mistake.

[#4]

Do you have versioning turned on?

[stevedark]

I know this may be a little 'after the event', but the best way to avoid this is to keep the document open in one QlikVIew window, save it from there, open another instance of QlikView, open the newly saved document in the new window.  If you are able to log in then all is fine, if not your original document is still open to be modified to fix the Section Access prior to saving again.

The other thing to do is to keep a 'non Section Access' version of your document saved in a safe place - obviously well away from your Access Point folders.

- Steve

[#6]

Sorry for my ignorance, but as all QlikView seems to do when enforcing section access is compare the result of OSUser() with NTNAME in Section Access Table, isn't the way around simply creating a virtual machine with the same name and username on it as whoever has access to the qvw file and then opening the file? Then section acess bit will be happy that they have some existing user... Or am I missing something?..

[#7]

Just tried it - no, I'm not missing anything, it seems to work. Nice!

[stevedark]

When implementing NTNAME security with Section Access it is best practice to always have DOMAINSID in the security table also.  This ID uniquely identifies the domain or server, and if you build another machine or domain with the same users on then the DOMAINSID would be different - meaning your solution would not work.  That said, I don' know many sites that use this level of security.  They focus more one making sure no-one has the ability to take their document off site to be able to try and get into it by force, or cunning.

Also, it is possible to lock a QVW whilst still having access to an Admin domain account.  If a data load fails and no data is loaded that any user has access to - or no data at all. It is possible that all users can then be locked out.

The advice regarding taking backups is certainly valid (though of course you need to ensure your backup location is secure also) and my tip regarding opening in another instance of QlikView can certainly save pain.  The most important thing is to think through your approach to Section Access carefully.

Steve

http://www.quickintelligence.co.uk/

[#9]

Yes, I'm aware of DOMAINSID. I'm also aware that DOMAINSID is nothing more but a string in registry. In the past, I have successfully changed DOMAINSID of installed virtual machine (during many years in computer security you do all kinds of interesting things).

Funny thing is using my method, it is possible to get into the document offsite by "cunning" - i.e., by creating a virtual machine with the SID of the original server (which is easy to find out), its name and your (or someone else's) username (which is even easier).

Security through checking SID and account name is not really security. It is purely to prevent opportunistic attempts to look into the data, nothing more. If a perpetrator wanted to look into the data in QVW, section access by itself would not stop them.

[stevedark]

Hi - I did not know that about spoofing a Domain SID.  Certainly one to rememeber.  As I said though, it's best to ensure that data can not be removed from the server in a QVW file - as whether or not the person taking it can easily get into it the data is still in there.

In many ways, the bigger threat is from someone walking off with any QVD files stored on the server - as these inherently don't have any security around them.