Today we are going to learn one very simple technique for bypassing QlikView Section Access security.
It goes without saying that we do not in any way condone hacking or the unauthorized use of data that does not belong to you. However, there are times when it is essential to bypass security. For example, imagine you have legally acquired control of a QlikView application but it has been locked down by Section Access. Not only are you unable to access it, you don't even know who can! So, with nobody to turn to, should you just throw out what is potentially a huge amount of work and try to rebuild the application from scratch? Not necessarily. Or, at least, not always.
Most folks (especially those that read this blog regularly!) know that QlikView applications are essentially just encrypted XML files. Interestingly, they are not even fully encrypted. We have seen a taste of this in other posts, but for purposes of this workaround, we will be opening the QVW in a notepad window, rather than as a QlikView "table" source. I recommend using Notepad++ for this, as it has much lower overhead than the Notepad that comes pre-installed with Windows. Below is an application that has been locked with Section Access:
Download this QVW and open it in Notepad++. If you scroll down a bit (on line 1,071 in this particular QVW, although that will vary), you will see a section that begins with the XML tag <SectionAccessNames>:
This section, which will exist in every QVW that has NTNAME-style Section Access defined, provides us with a huge advantage over our previous predicament: even though we do not have access to the application, we at least know who does. If that person is still with our organization, we can walk over to his/her desk, ask him/her to open the QVW for us, and save the application in an unlocked state. In many cases, however, we are not so fortunate; either the person is not available, or does not have ADMIN rights within Section Access.
In those cases, we can simply spoof the username. When using NTNAME security, QlikView is operating in a password-agnostic mode. If you have authenticated as User X, then you are User X, period. The next part will most likely be the most cumbersome: finding a user with ADMIN access rights. Some applications may have thousands of users, but only a handful with ADMIN rights. We will eventually need to create the necessary user in either Active Directory or the local Windows directory. Before you do so, however, I recommend using a technique called "Web Ticketing" to quickly find the user. This technique, which is well-documented on QlikCommunity (and which we can set up for you, if you do not want to tackle the task yourself), allows you to authenticate to a QlikView AccessPoint as any user you want. Importantly, this user does not actually need to exist in any directory! You can input any username you like and simply enter the AccessPoint as that user.
Now, you can quickly generate tickets for each of the Section Access usernames, one by one, until you hit one that's an ADMIN. How will you know when that happens? Well, usually Section Access performs a reduction/selection for non-admin users. When you open the application in the AccessPoint and nothing is reduced/selected, you've most likely found an ADMIN. In addition, the XML usernames will be listed in the order in which they are loaded into the data model. In most cases, ADMINs are loaded separately from regular USERS, either first or last. Therefore, if you have a list of 1,000 usernames, it's a safe bet than you can exclude all but the first 100 and last 100. Another good technique is to search for a username that is clearly a service account (something like qliksvc). These accounts are usually added to Section Access so that Publisher tasks are able to run, and almost invariably have ADMIN rights. However you do it, once you find the magic user, you'll need to create this username in either Active Directory or the local Windows directory, so that you can login to Windows with that user account and open the application in QlikView Desktop. At which point, of course, mission accomplished.
Occasionally, you may run into a situation where Section Access Names are provided in domain\username format. This should not deter you. Using the web ticketing approach, a domain can be spoofed just as easily as a username. And when it comes time to open the application in QlikView Desktop, you can simply use a computer that is not joined to a domain and rename that computer to match the domain name. For instance, if you have a user that has been specified in Section Access as mycorpdomain\userx, you can simply rename your local computer "mycorpdomain" and create a local user "userx". Logging in with this user will result in QlikView authenticating you as mycorpdomain\userx, and allowing you access to the application.
I can hear many of your asking the obvious question: why don't we just add our own username to the XML section we found while we have it open in Notepad++? It doesn't work that way—that section is purely informational. Adding/modifying values will have no effect. It is also important to note that this technique is limited to NTNAME security and does not work with USERID (i.e. QlikView login) security, since neither usernames nor passwords will be listed in the XML in that scenario. If you have a USERID-style application that you are truly locked out of and absolutely have to recreate it from scratch, this meta-data discussion will make the task a bit easier. For the majority of enterprise applications, though, the Section Access "bypass" described here can save you from the monumental task of having to recreate an entire QlikView application, so should be a tool you have available in your toolbox for emergencies. Happy Qliking!