AD and ODBC DSC

[oknotsen]

We are using QlikView 11.2 (yes... I know... upgrade is being scheduled).

We are using DMS with LDAP as our DSC. All is fine; SSO is working fine.

The customer has requested us to add / switch to an SQL Server database for our authorization, so we added a Configurable ODBC to our DSC. Idea is that we still have SSO to enter the AccessPoint, but that authorization can be arranged by making updates to the SQL Server database instead of LDAP.

Problem is... we currently can't get it to work.

We have managed to get the DSC setup correctly.

We are able to add people and groups to give them access to the QVWs... accept that they don't show up on the AccessPoint.

Our guess is that something between the username used in LDAP (SSO) and the name field used in the view in our new ODBC connection are not matching. We have tested with adding and removing the domain name in the Name field used in the database with no results, so either that's not it or that's not all.

Questions:

Could this setup work at all to begin with?

If so:

What are things we could be doing wrong? What are we possibly overlooking?

[Peter_Cammaert]

Maybe that AFAIK, QlikView uses DSCs for authentication, not for authorization. And if you put them authentications in a configurable ODBC, then you are moving away from everything else.

[oknotsen]

Thank you Peter for your reaction, yet I am not 100% sure I understand you.

We currently have both the LDAP as the Configurable ODBC listed as DSC.

The authentication is still done using LDAP (SSO as you are logged in directly when opening the AccessPoint).

We (think we) have used the same usernames in the views in the ODBC. Added the groups in ODBC to the QVW.

The idea would be that, since the usernames match, the groups usernames and groups in ODBC could now used when authorizing people to QVWs.

But what you are saying is "nice idea, but not going to work".

However... if that is the case, what would be the use of the Configurable ODBC to begin with (as I don't see how it could be used stand-alone by lack of password field in the definition)?

Again: I am not 100% sure I understand you correct, so you might be trying to say something else.

[Leigh_Kennedy]

There is (I have not heard this has changed in 12.x) a limitation with windows/NTLM based logins in that the groups come through with the login therefore the groups from the DSC are ignored.  This sounds like what you are trying to do.

The only way I know of to achieve what you want to do is to use ADFS & SAML to handle the login.  This is not supported out of the box and requires a 3rd party integration like Shiboleth.

This is not a simple thing to do.  If you don't already have ADFS & SAML expertise  I would not go down this path.  My suggestion would be to talk to Qlik or a Qlik Partner about your requirement and what you want to do is not going to be 'in the manual'.

Cheers.

[oknotsen]

Thank you for your reply.

If this won't work without 3rd party software, I do wonder why one would add the Configurable ODBC to the DSC when it can't contain a password (according to the documentation), so you can't use it stand-alone.

Not looking forward to inform the customer that what they had in mind won't work, so hoping someone comes along who does know a way to get this to work ("not in the manual").

[Peter_Cammaert]

Probably because QlikView doesn't really care about passwords and authentication. There is only one exception to that rule: Custom Directory which is governed entirely within QlikView.

All the others (except for AD & Co)  are just Directories that list user IDs and their group membership. And while a directory service *could* include stuff like permissions or ACLs, that is not what QlikView tries to pull through the DSC connection. Pretty boring stuff, huh?

What I remember from my own experiments some years ago was that you can't mix directories. I once thought I could move group management to QlikView so that while still using AD user accounts but without AD groups (imagine having to go and ask an official admin for a group change every day...) we could make document access management more efficient. That was a no-no (DMS with AD & custom groups = empty accesspoint‌) as the group membership resolution seemed to work just fine, but the services that tried to deduce corresponding authorizations didn't agree...

You seem to be fighting a similar fight here. Note that I don't have experience with the mix of DSCs you are trying to patch together. But the results look an awful lot like what I got a while ago.