Which version (if any) will support using Configurable LDAP (or another LDAP setup in Directory Services Connector), notActiveDir, for QlikView authentication? If yes, how?
(I have internal QV servers setup to use ActiveDir for authentication, and NTFSfor file access. Those systems are working fine.)
I have an Amazon hosted QV instance that I need to use (Sun) LDAP directoriesservices for authentication (, and authorization?).
I’ve installed OpenDS onto my AWS QV instance, configured OpenDS it with objects andattributes, and a couple of test users (one real, one just for test). I don’t have the option to connect from AWSQV instance to my internal (Sun) LDAP directory server, so I expect to exportobjects/attributes to an LDIF file, zip it, use WinSCP to transport it to myAWS QV instance, un-zip it, then import the LDIF into OpenDS. That’s all working fine.
??? Which version of QV (v10 + patch? or v11) allows me to use LDAP (not ActiveDir) as myauthentication agent, and how would I use the existing LDAP objects/attrib (as shown in the picture) to setup QV toprovide user interrogation and authentication, much like ActiveDir does? And, no, I do not want to just query the LDAP from within QV, I want to use non-ActiveDir LDAP as my authentication source, and hopefully, to use it for authorizations as well.
I have seen the statement in the QV v10 Admin Ref concerning not being able touse Configurable LDAP for use in authentication, so maybe a later Service Patchdoes? Or QlikView v11 ?
I do have QV enterprise and Publisher, so I’ve got all the licensing I need. I've reviewed many (all) the various community discussions related to LDAP and DMS, but no working examples (not using ActiveDir). I've also pored over the QV Admin Ref Guides.
listing of LDIF from the OpenDS objects/attributes (via Apache Directory Studio) that aresetup and available on the AWS QV instance.
LDIFexport to CVS, including structural objects, etc…
creatorsName:cn=Directory Manager,cn=Root DNs,cn=config
creatorsName:cn=Directory Manager,cn=Root DNs,cn=config
modifiersName:cn=Directory Manager,cn=Root DNs,cn=config
You need to go with QlikView Enterprise Server. QlikView Server Small Business Edition will not give you this feature.
Yes, that makes sense, but I do have QV Enterprise Server, and Publisher... so that's not the issue, althought I appreciate the question to double check...
Hi Daniel, thanks much for the overview and SSO documents, they're helpful... as an executive I'd be happy with these as the answer. It appears that QV v10x does support, non-AD, security and authentication. Essentially, either use AD (the default, and use NTFS, which is very easy and comes setup out of the box) or use one of several other methods, all of which force you thru many hoops, trial and error to get working by moving QV out of the way so that another technology steps in to conduct/provide authentication. non-AD LDAP authentication is mentioned in both documents, especially the SSO doc, but that (again) means changing from NTFS to DMS leaving behind much of the value (and restrictions?) inherent in Windows env. DMS appears to force the QV admin to assign access by document then domain\user (much like is done when admin DocumentCALs). Although an interesting method, assigning by document by user is very onerous for any but small environments.
Still there is no example (exception within the SSO doc, of using mostly windows components to make the SSO happen). I was hoping for some real world examples of using a non-AD LDAP authentication process that could utilize (in my case SiteMinder, Sun LDAP and the Wiindows server that QV runs on) components not windows centric. After all this time (v10 !) QlicTech still doesn't provide a basic non-AD LDAP authentication to work out of the box?
So what about v11? Does it have a straight forward non-AD LDAP authentication that leverages the Windows NTFS without jumping completely out of the QV env that makes QV Admin useful and intuitive?
Has no one used non-AD LDAP DSC and it's setup form to provide this functionality?
The documents are great, I do appreciate them and will use them during my discussions with others and management.
I'm still hopeful that someone in the QV community has done something similar to what I'm requesting and am a waiting their point of view and example...
Update for me, and others....
Turns out that both v10x and v11x provide the capability to connect to a non-ActiveDir LDAP using 'Configurable LDAP' directory service provider, but that you must engage QlikTech Consulting to work with them to get it configured properly for your environment. This from QlikTech Support as my official word. So it's possible if you can figure it out, else pay $$ to have QlikTech tell you how (or more likely do it for you).
Hopefully this is not the end of this thread, I'm hoping my management will spring for the $$ to have QlikTech setup our 'Sun' based LDAP configurable dsp so that I can use a non-AD LDAP to do authentication.
However, authorization still has to be outside QV... you must turn off NTFS and enable then setup DMS, and use an outside service to provide authorization group membership or functionality (such as SiteMinder, etc).
If I can get this setup I'll come back to write up how we did it....
I am in a similar boat right now and am trying to work through the steps required to make this work. I am documenting my steps as I go, right now I am in the beggining stages so hopefully more info to come soon. How did you end up, did you ever get your configuraiton done?
So the short answer is that QV does NOT support LDAP (non-ActiveDir) for authentication like they do ‘out-of-the-box’ support for ActiveDir. Although ActiveDir is a flavor of LDAP, the difference is very great when it comes to how QV access/parses/consumes and acts on that info.
That’s because the system was always a windows based environment originally only working against ActiveDir. As other customers came on board then QlikTech had to support non-ActiveDir LDAP connections. They chose to do this by connecting to LDAP as a data store (like any other data content connection). The result is that (currently) you can not specify an LDAP profile and have QV do authentication as easily/painlessly as it does AD authentication. Maybe in the future.
What you can do, and have been able to do for a while, is to connect to non-ActiveDir LDAP as a data content data store, pull in all the LDAP info you’re interested in (given LDAP types of search constraints) and then parse the resultant LDAP answer set to build a QVD (or other format) or use that info internally to provide authentication (read as SectionAccess).
So you use a QVW to connect to non-AD LDAP, provide profile and base search parameters, pull all the matching LDAP info from your LDAP datastore, parse the answer set like you would any other data content, and then you can use that info as associative links to the rest of your data model to describe authorization.
For my part I was trying to solve a situation where we have the staff side of the company with AD and our external customers and distributors had regular LDAP for authentication/authorization. QlikView is not setup to do LDAP cascade. I was looking for QV to provide authentication against our regular LDAP like it would against ActiveDir. Does not work that way.
We ended up using SiteMinder to provide the authentication process/setup, setting up IIS to provide the web server and interaction pool environment, and then setup QV for DMS (ignoring NTFS, ACLs, etc) with an HTTP header field to hold the siteminder validated userid. The valid userid is passed into QV AccessPoint that has the responsibility to check if that valid userid is embedded within any of the QVWs’ SectionAccess tables. If yes, then the user can ‘see’ a QVW, and because at least one SectionAccess field is also one of the fields specified within the regular data model then that validated user gains access to their rows within the QVWs they can ‘see’.
I would not call this an elegant authentication / authorization model. It does work, demands a high degree of skill and testing to ensure it’s working correctly. Is a custom solution. A custom solution we paid $$ with QlikTech Global Solutions to provide, and must be kept firmly in front of your upgrade and testing/validation process to ensure stays working.
I remain hopeful that sometime in the future QlikTech decides to implement an agnostic LDAP authentication AND authorization method that can be used equally well (and easily) against any LDAP directory (ActiveDir or other).
Thanks for the detailed response. I agree it is a very custom solution and requires signifigant skill to setup and properly maintain. I have been told to shelve my foray into my poc of this actually working but since I was already about 50% of the way through they are allowing me to finish the 'academic endeavor', so your final notes will certainly come in handy.
Bravo, Jeremy, I do hope you break thru to a solution. Please let me know if I can provide any other details that might help you.