Qlik Sense deployment in a DMZ Environment

[ksmccann]

HI All

Has anyone seen a good document for Qlik Sense that covers deploying in a DMZ environment and authenticating users with LDAPS? I have the ports document but still trying to figure out how the proxy servers and authentication directories should be configured to work with each other. The user will have an internal proxy server also that authenticates with AD which I already have working on the central node. Now i am trying to configure the RIM node proxy server in the DMZ to authenticate the users

I am trying to clarify where authentication is done in the rim and central configuration. Does the central server do the authentication behind the firewall or does the proxy server in the DMZ do the authentication and therefore needs a RODC or open ports to the AD domain or LDAP server?

Do I need to define 2 user directories (one for the internal proxy server and one for the external proxy server) or will one work for both?

I have looked at the installation guide and numerous posts on the community but have not found a clear description of a best practice for DMZ deployment and Authentication with either LDAPS or AD when running a mixed internal and external environment.

Any insight, documentation or experience in this area would be greatly appreciated.

[#2]

Hi Kevin,

UDCs do not perform identity management services.  If you are using authentication other than windows auth to verify user credentials, you need to create a custom authentication module to reach out to the LDAPS and perform the verification, then do ticketing request to the proxy server in the dmz.

Have a look at this security overview video: https://www.youtube.com/watch?v=vkCh_t1nd40

Then have a look at this branch solution for custom auth to an ldap: Qlik Branch

If you need more help with understanding how to set up ticketing, I have additional videos up on youtube for that subject: Using the Qlik Proxy Service Ticketing API with IIS - YouTube

[rittermd]

We originally put the QS server in the DMZ.  That worked fine as I was loading users through a UDC based on an excel file that I manually created and maintained.  I also had to add each user as a local user on the server.  We don't currently have a lot of users so this worked fine.

We investigated authorization using AD instead.  The problem that we ran into is that out of the box this will not work if you are in the DMZ.  There is no way for the server to connect to the AD to authenticate without creating a new custom authentication module as mentioned above.  We did not want to do that.

So the solution recommended to us was to move the server behind the firewall and add to the Domain.  Then use a reverse proxy in the DMZ.  We have not done this yet so I can't tell you if it worked or what was involved. 

We are also looking at OKTA for authentication.  My understanding is that the setup would be the same.  QS behind the firewall and a reverse proxy in the DMZ that talks to OKTA.

Hope that helps some.

[ksmccann]

Thanks Jeffrey, appreciate the response and I watched the video. Unfortunately the specifics on where authentication is done is still unclear. . Let me ask this slightly differently, since I consider LDAP a windows authentication method and AD is a flavor of LDAP. Lets say I wanted the DMZ proxy server to authenticate through a RODC that is in the DMZ. How does this look from a configuration perspective? I will have one proxy server in the DMZ for the external access and one proxy server behind the firewall for the internal access. External users would be authenticating via the RODC AD controller and the internal users would be authenticating through the corporate AD controller (behind the firewall).

Can you clarify/confirm the following:

1. Would I need to create 2 UDC's, one that references the RODC and one that references the internal AD controller to pick up user attributes or if the RODC is replicated for the corporate domain is only 1 necessary?

2. Where is the actual authentication being done? I am assuming it is at the windows server level using integrated security when the URL is hit, prior to QLIK even being accessed. Is that correct?

3. Is IIS required for a DMZ deployment in this manner or can the proxy server handle this?

4. Is the DNS for the external access the  DMZ proxy server name since there is no web server?

5. Does QLIK require ports to be opened to LDAP or AD in order for this configuration to work, or is that all being done generically by windows integrated security?

6. If the authentication is being done by Windows which support LDAP I am a a little confused why I would need to deploy custom code to make this work with standard network authentication providers.

7. If I look at any standard web app in a DMZ that needs AD authentication, is there anything unique to QLIK that I need to do compared to a generic web app with regards to the security?

8. MY understanding of the need for custom ticketing, etc is when using a generic authentication provider for portal environments, such as SiteMinder. For LDAP and AD I would not expect to have to write custom code, is that correct?

Sorry for all of the questions, but while I understand all of the theory of what is possible, it is not clear what the correct approach is to this. I have looked at all of the QLIK materials and posts on the community and this seems like a very vague area of the product and there are numerous unanswered posts along the same lines. Given this is a web app, deploying in a DMZ should be more clearly documented as to how to do this against standard approaches like AD and LDAPS  in my opinion. 

I appreciate your time on this. If you have any whitepapers on how a DMZ deployment works with AD and how a DMZ deployment works with LDAP I think that would be extremely helpful. I realize that some of this may be outside the scope of QLIK with authentication being done by other providers, but for a successful DMZ deployment this is a critical piece and so it would be in QLIK's best interest to clarify a best practice approach to common deployment scenarios, as many network admins know nothing about QLIK and many QLIK folks are not network security experts.

Thanks again for your help with this.

[ksmccann]

Thanks Mark, I appreciate the input. The fact that you need to do custom code just to make a web app work with AD in a DMZ seems odd to me. This is a standard deployment scenario for a web app and should work out of the box, so my concern is that I am missing something here.  I have a number of clients looking for this same solution so I know this is not atypical. Creating local users on DMZ box or providing through Excel is clearly not a scalable solution when all of the users are already defined in AD. It certainly would work, but I would not consider it a best practice (as I am sure you don't either) .

With regards to the reverse proxy server what I have seen on that is that it requires a web server to be deployed and possibly 3rd party software, was that your understanding also? Putting the entire app behind the firewall seems to defeat the purpose of having a proxy server that can be deployed in the DMZ!

Thanks for the input, I had seen one of your posts when I was researching this. My hope is to help get some clarity around this topic and get some definitive answers as this should be cleaner than what you were told in my opinion. Again, appreciate you taking the time to chime in!

[#6 · Accepted solution]

Kevin,

I'm unclear on what an RODC is.  Sorry about that.

To answer your questions:

1. No, you do not need 2 udcs.  You can use the AD UDC you have already created if the userdirectory (read: domain) value you pass in with the userid during Qlik Sense authentication matches the userdirectory value for the UDC.

For example:  UDC value == foo, userdirectory on credential == foo, then Qlik Sense will use the AD UDC to map attributes to user when userid matches as well.

2. Authentication is really a two step process.  The first step is the identity verification which is handled outside of Qlik.  Whether that's Windows or some other method of identity verification is players choice.  By default windows authentication is used because on port 4244 there is an authentication module that is written into the proxy that performs the ldap authentication to the windows domain the server is a member of.  So, if you are going to use Windows Authentication for identity verification out of the box with Qlik Sense, your proxy server needs to accept inbound connections on port 4244 AND it needs to be a member of an Active Directory domain.

3. IIS is not required.  The video I shared is an example.  Any web server can be used to host a ticketing solution.  I have solutions in .net, php, java, javascript that I can share with you.

4. Yes, the dmz proxy server is where you would point users to.  It handles auth to Qlik Sense (sending id verification to another module either on same server / different port or different webserver.  hostname needs to be placed into the virtual proxy configuration host white list to be allowed entry.

5.UDC work is only performed on the central node, so access to ports 389 or 636 (? for ldaps) needs to be allowed outbound so the central node can talk to those services for acquiring user information.  Your authentication solution will need to have access to those ports as well where ever you put it.

6.  Windows supports windows authentication and stores user credential information in active directory which is exposed as an ldap.  Qlik Sense windows authentication module (@port 4244) is just like the custom module I'm suggesting you create accept it is packaged with Qlik Sense and only works with servers that are members of the Windows domain.  Therefore, if your Qlik Sense proxy node is not a member of the windows domain then it will not be able to authenticate users via windows.

7. The server needs to be a member of the domain in order for windows authentication to work to domain users.  Local users will work, but you probably want to use domain users.

8.  Your assumption is incorrect.  Solutions like Siteminder are often wired up to a SAML identity provider in which case we recommend using SAML virtual proxy config (keep in mind you can still use your AD UDC to sync attributes in this configuration).  Ticketing and session are often used for web portals with custom authentication or database stored credential stores.  Or in DMZ scenarios where LDAP authentication is a requirement.

Now, as for the proxy rim node, we (qlik) are moving away from recommending proxy rim nodes in dmz.  The next best alternative is to use a reverse proxy in the dmz to forward traffic from the outside to the internal Qlik Sense proxy node.  It's not ideal, but we are finding that is a more conventional method to pursue.

To review:  If you are going to continue to have a Qlik Sense proxy node in the DMZ and you want to perform windows authentication, the two requirements are:

1. Port 443 and 4244 open inbound on the proxy node.

2. Proxy node must be a member of the windows domain.

Alternatives using reverse proxy with Qlik Sense proxy node behind firewall:

For windows authentication:

1. open port 443 and 4244 inbound on proxy node, reverse proxy needs to be able to forward to both 443 and 4244.

2. Proxy node must be a member of the windows domain.

For SAML:

1. Only port 443 needs to be opened on the reverse proxy and the proxy rim node.  This is pretty clean and allows you to leverage SAML attributes AND udc imported attributes with a set userdirectory value in the SAML virtual proxy configuration.  This is what I recommended to Mark.

For Header Authentication:

1. Have the reverse proxy persist a user header you define in the header auth virtual proxy configuration.  I do not recommend this solution.

[ksmccann]

Jeffery, first off thank you for the extremely detailed response and bearing with me as I work through my understanding of these options in a Sense world.

As far as RODC, it is a Read Only Domain Controller which can be replicated from the corporate domain controller. The idea would be then that the credentials in the RODC could be accessed in the DMZ without the Proxy server having to punch through the firewall to get to the corporate AD domain controller, keeping things a little more secure. My assumption here is that the Proxy server would then be connected to the RODC domain and authenticate users credentials there than have been synched from the primary controller. I am not an expert in this aspect of network security but I believe this is correct and is how I have advised clients to deploy QV in a DMZ in the past, with the help of their network admin. Since the users would then be authenticated with the same credentials as the internal domain, I am assuming the UDC would work fine and see them as the same user and create authorization accordingly.  Does this seem logical to you?

The clarification that the proxy server has to be attached to the domain for the integrated security to work certainly makes sense. It seems at that point if you want this to work out of the box then you need to either allow the server in the DMZ to access AD through the firewall or replicate the AD into the DMZ using the RODC approach with replication/synchronization. Does this make sense and do you see any other alternatives to making this work without customization or the reverse proxy server.

The statement below is also helpful, although requires more research 😞 . My understanding is the reverse proxy server would require a web server in the DMZ as well as 3rd party software to provide the reverse proxy such as NGINX or using IIS as the reverse proxy server using URL rewrite. In this case I am assuming that the authentication is handled on the proxy server behind the firewall and the reverse proxy is simply passing the traffic through and obscuring where the requests are coming and going from.

"Now, as for the proxy rim node, we (qlik) are moving away from recommending proxy rim nodes in dmz.  The next best alternative is to use a reverse proxy in the dmz to forward traffic from the outside to the internal Qlik Sense proxy node.  It's not ideal, but we are finding that is a more conventional method to pursue."

The point I was not getting was the port 4244 is QLIK written authentication module that comes out of the box to create tickets, but has certain requirements to work seamlessly.

Thanks again for all of your time helping clarify all of this for me. Hopefully this post will be helpful to others that are struggling with the same issues.

[#8]

Thank you for the clarification on RODC.  So if the proxy can be a member server of a domain in the dmz that has a one way trust to read records from the active directory behind the firewall, then Windows auth through a proxy in the dmz "should" work.  However, this type of auth configuration is not something we see often.  What many of our customers have an issue with is the 4244 port redirection for windows auth.  This tends to be the main sticking point because IT security and network teams don't want to open more ports.

All that said, the position change of having a reverse proxy instead of a rim node proxy in the dmz mitigates the above.

jg

[ksmccann]

Makes sense and gives me a much clearer view of how to approach and plan for these kinds of deployments. Thanks for all the time spent!

[Anonymous]

It's really a great explanation. Gives lot of in-sights. Thanks a lot Jeff !!!. Kudos to you !!!