2 Replies Latest reply: Mar 21, 2011 6:31 PM by DJ Norton RSS

    Switching from USERID to NTNAME in Section Access

      Hi Everyone,

      (I have RTFM and this Forum for this topic and I'm still stuck.)

      I'm converting the Section Access piece of an app from using USERID to NTNAME, as I push closer to launch, and am getting strange results. More specifically, if I set myself up as ADMIN in Section Access, everything works fine, but when I change my access group to USER, the app locks me out.


      What is more strange is that when I leave a password enabled and then load up the app (following reload and save) I'm prompted for a password and not a user login -- as expected. If I mistype the password, I get another try. If I type the password properly, I'm denied access. So, I'm guessing it's something deeper in the settings. Any ideas?


      I've enabled "Initial Data Reduction based on Section Access" and "Strict Exclusion", and am branching the app copies whenever there's the reasonable/expected chance of getting locked out.


      Is NTNAME the same as the result from OSUser()?




        • Switching from USERID to NTNAME in Section Access
          Miguel Angel Baeyens de Arce

          Hello DJ,

          Starting fromt he bottom up yes, NTNAME must match what OSUser() returns, so you will not be prompted for credentials (you may accessing with AJAX or IE, but not with Desktop for development). That leads me to think that you are not deploying for the time being in clients with AJAX or IE plugin, rather than the Desktop app.

          To make tests, I strongly recommend to uncheck the "Strict Exclusion" what is that gets you locked out. Sorry for this bit of theory but I think it's worth taking into account. When you have a section access (fields ACCESS and NTNAME -or USERID and PASSWORD) you are not doing any reduction on the data, so QlikView will only ask for user and password so if you don't have a valid combination you won't be granted. That's ok.

          But when you use a reduction field (checking that option in the Document Properties), section access works as if you select the value correspoding to the logging user, go to File menu, Reduce Data, Keep Possible Values. Try that unchecking reduction in the document properties just to check if everything works fine. My guess is that that reduction will leave some users with zero records. Strict Exclusion means that if for a valid combination of user and password (or valid NTNAME) there are no records (possible values) in the document, access to the document itself is denied, instead of showing an empty document.

          What I'm missing is if that model of security was working fine with USERID and PASSWORD and it started to go wrong when you used NTNAME. Are you using both? It only makes sense when all users have either USERID or NTNAME, but not both. Actually, it may lead to locking users out. For example, you have NTNAME pointing to your DOMAIN\UserName, and some other lines pointing to USERID and PASSWORD. When you load this document from a different computer or session, they document will never open, as it doesn't mach your NTNAME. (Side note, working with NTNAME will make the document to take longer to load, since credentials must validate against the AD instead the document itself).

          ADMIN access is valid when the document is opened for developing in Desktop, not using "Open in server", since all users accessing via clients (even using Desktop with "Open in server") are granted USER access, even when you have stated otherwise in Section Access. That's why you are granted always.

          In short, if you only want user and password, uncheck the strict exclusion and even uncheck the "Initial Data Reduction". Users will be prompted, although all users will be able to see all information in the document.

          Hope that helps.

            • Switching from USERID to NTNAME in Section Access

              Hi Miguel,


              Thanks for your response, and for verifying the NTNAME should equal the result of OSUser(). That was my assumption, but I couldn't find it explicitly in the Help file or forum.


              I just figured out my issue, and it's frighteningly simple:

              I needed to UPPER() my Reduction Field and the corresponding bridge field (back in Section Application). It turns out my NTNAME is just fine. You're exactly right though about Strict Exclusion being the specific piece that was locking me out of the application... when the Reduction Field case mismatch caused the filtering to return a NULL set.

              Ugh... At least it was a simple fix.


              Muchas gracias por su ayuda. Smile