Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
Peter_Cammaert
Partner - Champion III
Partner - Champion III

DMS with AD & custom groups = empty accesspoint

At a customer of ours, we're building a specific authorization mechanism using QVS EE, QVP and DMS (all on same server running QV11IR). Users are authenticated using AD and recognized by way of the Active Directory DSC. A Configurable ODBC provides custom groups for all users that should have access to the documents in the portal.

We can query these users in the QMC Users tab. They appear to belong to both the correct AD groups AND the custom groups that were defined in an Oracle DB.

When we create a distribution task for reloading and distributing a single document to a custom group, the QMC confirms (via the same Users menu) that the document is reloaded and distributed to this custom group. Selecting a single member in the QMC->Users list produces confirmation that the user belongs to the distribution group (Groups tab), has access to the correct test document (Documents tab) and got the necessary rights from the correct task because of being a member of this custom group (Distribution tab).

However, when the same lucky user opens the portal, no documents are available. Just an empty list...

No error messages or warnings are present in the logs. All DSC activity is successful.

The QVWS log contains the only indicator that something is wrong. The GetAdminDocListForUser request consistently returns an empty list.

BTW this user has all necessary NTFS rights to folders and documents, but I don't think that matters when using DMS.

Is there a reason why QMC keeps telling everything's just fine when the published documents remain invisible in the AccessPoint?

Thnx,

Peter

1 Solution

Accepted Solutions
Peter_Cammaert
Partner - Champion III
Partner - Champion III
Author

Apparently, AD users and custom groups cannot be mixed. QMC has no problem resolving custom groups for AD users, but QVWS won't. So you won't get to your documents, unfortunately.

Those who want this to happen in a future release can vote for: http://community.qlik.com/ideas/1851

Thanks for your feedback

Peter

View solution in original post

17 Replies
danielrozental
Master II
Master II

Not really sure what the problem might be but you could check a couple of things, is the directory service connector configured correctly in the QVWS settings?

Have you tried setting the DSC log level to debug? that may offer more information.

Peter_Cammaert
Partner - Champion III
Partner - Champion III
Author

Hi Daniel.

Yes, the DSC is correctly configred. Other users that have been authorized by name can view and open their documents without any problem. Just the authorizations through custom groups fail to work. E.g. a user with 3 documents with domain\user authorization and one document with domain\customgroup authorization sees only 3 documents. The QMC says otherwise (access to four documents).

Yes I have. All logs are either in verbose or in debug mode. But that isn't helping much as QVS isn't aware of any problem whatsoever...

QVWS is simply telling me that there aren't any documents for this user. DSC resolves users and groups, and then... silence.

Peter

danielrozental
Master II
Master II

If you're using an oracle database, can you check the queries that are being done are correct? have you tried the group without the domain?

I'm not really sure you can have groups from one source and users from another. Not sure how that works.

Bill_Britt
Former Employee
Former Employee

You can't use Custom Users with any other directory service. So, you either will have to run Custom Users or AD.

Bill Britt

Bill - Principal Technical Support Engineer at Qlik
To help users find verified answers, please don't forget to use the "Accept as Solution" button on any posts that helped you resolve your problem or question.
danielrozental
Master II
Master II

Bill, I think he's trying to use AD users with groups defined in a Configurable ODBC.

Bill_Britt
Former Employee
Former Employee

Thanks Daniel I read that wrong.

QlikView will use the different LDAP to setup the rights to the documents. This has nothing to do with Authentication. QlikView only support Windows Authentication and if you are using anything else you have to create(write) the SSO pages to pass the header information to QlikView.

Bill Britt

Bill - Principal Technical Support Engineer at Qlik
To help users find verified answers, please don't forget to use the "Accept as Solution" button on any posts that helped you resolve your problem or question.
Peter_Cammaert
Partner - Champion III
Partner - Champion III
Author

Correct Daniel. I know that I cannot mix up AD users and Custom users. But I can use "custom groups" (bad name) from a Configurable ODBC together with AD users and groups.

In QMC Users->Groups, everytime I select an AD user, QMC shows me both the AD groups and the custom groups this user belongs to. "Seems" to work well.

Peter

Peter_Cammaert
Partner - Champion III
Partner - Champion III
Author

Bill, authentication is working correctly everywhere and we don't use anything else than AD.

Even in the AccessPoint an AD user from a custom group is recognized and has his name shown at the top. It's the authorization part that goes numb. No documents shown, while the QMC says I should see at least one QVW because of custom group membership...

It's like in this case the QVWS cannot get QVS to deliver the names and thumbnails of the documents the user is authorized to view.

OR, QMC is telling me stuff that everybody else in the QlikView services family is convinced that it can't be done...

Peter

Peter_Cammaert
Partner - Champion III
Partner - Champion III
Author

Daniel, I'll try the Oracle query trace.

Just to be sure: when using DMS, authorizations for specific documents are stored in meta files alongside the documents themselves. If QVS stores the original authorizations, the name of that single custom group should be there and whenever QVWS asks for authorized documents, DSC must determine group membership for the visiting user at the time of the request, correct?

More info will follow.

Peter