11 Replies Latest reply: Nov 27, 2012 1:13 AM by Ben Atmore RSS

    Which QV version supports (non-ActiveDir) LDAP for Authentication

    Ben Atmore

      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…

      bjectClass:top

      objectClass:organization

      o:xxxxxx.com

      entryDN:o=xxxxxx.com

      entryUUID::MDg3M2NmYzgtOWJjMy0zNGU4LWE5YWEtMDI3ZjhmNWY5YmM2

      hasSubordinates:true

      numSubordinates:1

      structuralObjectClass:organization

      subschemaSubentry:cn=schema

       

      dn:ou=customer,o=xxxxxx.com

      objectClass:organizationalUnit

      objectClass:top

      ou:customer

      createTimestamp:20120207022218Z

      creatorsName:cn=Directory Manager,cn=Root DNs,cn=config

      entryDN:ou=customer,o=xxxxxx.com

      entryUUID::ODZmYWZlYmUtMzExOC00ZWY5LThlNTYtNTAzODU5N2YzNjIz

      hasSubordinates:true

      numSubordinates:2

      structuralObjectClass:organizationalUnit

      subschemaSubentry:cn=schema

       

      dn:uid=GURKAN.GOGUS@YYYYY.COM.TR,ou=customer,o=xxxxxx.com

      objectClass:person

      objectClass:organizationalPerson

      objectClass:webuser

      objectClass:top

      cn:Gurkan Gogus

      sn:Gogus

      uid:GURKAN.GOGUS@YYYYY.COM.TR

      givenName:Gurkan

      mail:gurkan.gogus@yyyyy.com.tr

      mgcdistributor:Y

      siteid:15416

      sitename:YYY A.S.

      userPassword::xxxxxxxxxxxxxxxxxxxxxxxxxxx

      Q==

      entryDN:uid=gurkan.gogus@yyyyy.com.tr,ou=customer,o=xxxxxx.com

      entryUUID::YTljZDYwMmItYjcwNC0zOGNjLTk5YzktMDEzN2FkNWJiN2Qw

      hasSubordinates:false

      numSubordinates:0

      structuralObjectClass:webuser

      subschemaSubentry:cn=schema

       

      dn:uid=qvtest,ou=customer,o=xxxxxx.com

      objectClass:person

      objectClass:organizationalPerson

      objectClass:webuser

      objectClass:top

      cn:QVTEST

      sn:qvtest

      uid:qvtest

      givenName:qvtest

      mail:qvtest@xxxxxx.com

      mgcdistributor:Y

      siteid:15415

      sitename:Xxxxxx test

      userPassword::zzzzzzzzzzzzzzzzzzzzzzzzzzzzz

      Q==

      createTimestamp:20120217221305Z

      creatorsName:cn=Directory Manager,cn=Root DNs,cn=config

      entryDN:uid=qvtest,ou=customer,o=xxxxxx.com

      entryUUID::NTgwYTg5NjYtMzdmZC00MWYwLWIzYzktNjFjNmM1ZmNmZjAw

      hasSubordinates:false

      modifiersName:cn=Directory Manager,cn=Root DNs,cn=config

      modifyTimestamp:20120222192758Z

      numSubordinates:0

      pwdChangedTime:20120217223524.622Z

      structuralObjectClass:webuser

      subschemaSubentry:cn=schema

       

       

       

       

       

      ben

        • Which QV version supports (non-ActiveDir) LDAP for Authentication
          Rakesh Mehta

          You need to go with QlikView Enterprise Server. QlikView Server Small Business Edition will not give you this feature.

            • Which QV version supports (non-ActiveDir) LDAP for Authentication
              Ben Atmore

              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...

                  • Re: Which QV version supports (non-ActiveDir) LDAP for Authentication
                    Ben Atmore

                    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...

                     

                     

                    ben

                      • Re: Which QV version supports (non-ActiveDir) LDAP for Authentication
                        Ben Atmore

                        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.... 

                         

                        ben

                          • Re: Which QV version supports (non-ActiveDir) LDAP for Authentication
                            Jeremy Fourman

                            Hi Ben,

                             

                            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?

                             

                            -Jeremy

                              • Re: Which QV version supports (non-ActiveDir) LDAP for Authentication
                                Ben Atmore

                                Hi Jeremy,

                                 

                                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).

                    • Re: Which QV version supports (non-ActiveDir) LDAP for Authentication
                      Bill Britt

                      Please remember that QlikView does not do authentication. Windows does that and pass the information to QlikView where it can do the authorization. If it is non-windows you are trying to authenticate against, you will have to write the code to do the authentication and pass the header information to QlikView for authorization.

                       

                      Bill