Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
klaus_feldam
Creator II
Creator II

Problems with named user access (NTFS in QlikView 9 SR2)

We have just installed QlikView 9 SR2 (9.0.7320.7 in 64-bit Windows environment). We are coming from a QlikView 8.20 Windows environment.

We have 160+ QlikView files in approx. 50 different folders and have always been using NTFS to control access to individual users. Most users are local on the server and NOT domain users. This has not been a problem until QlikView 9 SR2.

After creating the local user, we give the user Read & Execute access to the folder. See below for CACLS on the folder
D:\Client View\XYZ\XYZ.qvw NT AUTHORITY\SYSTEM:(ID)F
XYZ.COM\feldamk:(ID)F
QTS-SMARTREPTS\SmartTest:(ID)R <--- This is the test user for this example

When the user then opens the Access Point through IE7, IE8 or Mozilla Firefox, he/she first logs in using his/her local account.
After this, the correct QlikView files are displayed.

error loading image

So far so good...

But, when the user clicks on the any of the reports he/she has access to, a second log-in prompt appears and the test user is unable to login.

error loading image

The server log reports the following (first that the document is loaded, and next that the user has no access):

Information The document D:\CLIENT VIEW\NAMB\QLIKVIEW INVENTORY_PURCHASING_NAMB.QVW was loaded.
2010-08-12 21:47:53 2010-08-23 10:00:50 2 110 Warning The document D:\Client View\NAMB\QlikView Inventory_Purchasing_NAMB.qvw failed to load because of no access [15].

2010-08-12 21:47:53 2010-08-23 10:04:40 4 108 Information The document D:\CLIENT VIEW\NAMB\PBD SALES NAMB.QVW was loaded.

2010-08-12 21:47:53 2010-08-23 10:04:42 2 110 Warning The document D:\Client View\NAMB\PBD Sales NAMB.qvw failed to load because of no access [15].

We have checked the security settings on QEMC and QMC and everything appears correctly set up.

QEMC / Setup / QlikView Web Servers / AccessPoint: Authentication: Always

QMC / QlikView Server Settings / Security:

Any idea of why this relatively simple user access using NTFS may be a problem with QlikView 9 SR2?

I would really appreciate any guidance on this.

1 Solution

Accepted Solutions
klaus_feldam
Creator II
Creator II
Author

I found the solution. It's almost embarrassing how simple, but maybe their are other users who would benefit from our ignorance.

Solution:

  • If you are using section access, you need to reload the QlikView document every time we create a new user.
  • As long as you don't reload the QlikView document, the user will be presented with a second log-in prompt.

Thanks to Vlad for his assistance and prompt responses.

View solution in original post

8 Replies
vgutkovsky
Master II
Master II

Klaus,

Have you checked your section access? It's possible that is what's causing the second login prompt...how do you have that set up?

Regards,

klaus_feldam
Creator II
Creator II
Author

Hi Vlad,

I am using NTFS authorization, but have tried both DMS and NTFS, with the same result.

NTFS rights are set individually on the folders and files.

The problems occur only with local users, created on the QlikView server. We are using local users for the external clients.

Domain users can access the QlikView files without any problems.

vgutkovsky
Master II
Master II

So, to confirm, you don't have Section Access in the scripts of the QVWs themselves? Because that would be my first guess as to the problem...

klaus_feldam
Creator II
Creator II
Author

Hi Vlad,

This is what I have in Section Access:

Section Access;

Load
Upper(SERIAL) as SERIAL,
Upper(ACCESS) as ACCESS,
Upper(NTNAME) as NTNAME,
//Upper(PASSWORD) as PASSWORD,
Upper(COMPANY) as COMPANY,
Upper(SHEET) as SHEET
FROM "security.xls" (biff, embedded labels, table is [Security$])
WHERE COMPANY = '$(BusinessUnitLimit)' OR Upper(COMPANY) = 'ALL';

Section Application;

OrderTypeLimit:
Load
[Order Type],
Upper(ORDERTYPELIMIT) as ORDERTYPELIMIT
FROM "security.xls" (biff, embedded labels, table is [Order Type Limit$])
WHERE EXISTS([Order Type]);

SheetSecurity:
Load DISTINCT
SHEET,
SHEET as Sheet
FROM "security.xls" (biff, embedded labels, table is [Security$]);

This is our security.xls (slightly altered for confidentiality purposes):

vgutkovsky
Master II
Master II

Do you have the local users defined in your section access? if not, then you need to do so or access will be denied...To find out the proper format for usernames, I recommend creating a temporary QVW with a text object that contains the osuser() function.

Regards,

klaus_feldam
Creator II
Creator II
Author

Hi Vlad,

The local users are defined in the security.xls spreadsheet. The example in the screen dump above is 'smarttest', a local user who has rights to the test files.

I have tried using the following simple section access and this works after a data reload.

Section Access;
LOAD * INLINE [
ACCESS, USERID, PASSWORD
USER, ABC, ABC
ADMIN, ADMIN, ADMIN
];
Section Application;

That leaves the security.xls. Something is obviously wrong with this file or the data format in some of the columns.
We have used the same format in QlikView 8 for several years, so I am a bit surprised that it's giving us problems at this point. The format of the spreadsheet has not changed.

vgutkovsky
Master II
Master II

Yep, that's what I suspected. Take a look at my wiki article here: http://community.qlik.com/wikis/qlikview-wiki/iphone-clients-amp-section-access.aspx. It was originally written for IPhone clients, but I think you may find it helpful to your situation as well.

Regards,

klaus_feldam
Creator II
Creator II
Author

I found the solution. It's almost embarrassing how simple, but maybe their are other users who would benefit from our ignorance.

Solution:

  • If you are using section access, you need to reload the QlikView document every time we create a new user.
  • As long as you don't reload the QlikView document, the user will be presented with a second log-in prompt.

Thanks to Vlad for his assistance and prompt responses.