Discussion Board for collaboration related to QlikView Deployment.
I need to setup a AccessPoint so the user could access QV applications from outside the company network. VPN is not an option since different mobile platforms are involved.
I am trying to find a Technical White Paper or other set of documentation that clearly describes the process of setting up the environment that allows this kind of access, but I was not able to locate anything useful and accurate so far.
I would appreciate the exports suggestions.
Vlad, why do you say that VPN is not an option just because different mobile platform are installed? With a correct VPN configuration on the server side, you should be able to use a wide range of client from all sorts of different platforms to connect.
Other than VPN, you're left with 2 options essentially: (1) putting your web server in the DMZ, or (2) putting your web server in the DMZ and using client-side certificates. These certificates are installed on client machines (PCs, iPads, etc) and IIS on the QlikView web server box is configured to only serve up websites to machines that have the certificate installed. An additional benefit of certificates is that users would not have to login manually every time, which is quite annoying (especially from mobile clients).
With both DMZ options, it's highly advisable to have a separate box for the web server and keep the QVS itself behind the corporate firewall.
If you decide not to go the VPN route, you would definitely need an SSL certificate installed and configured. This will, of course, slow down communications. But running without SSL when you're allowing access from outside the company's network is never a good idea.
Thanks for reply!
How are you doing?
I've heard about DMZ options before, but I've never tried to do this kind of setup myself actually. This is why I am looking for some kind of "step-by-step" document so I can review it prior to meeting with the network team. I would like not waste time during the setup looking for answers.
Specifically, the part of SSL certificate is a unknown territory for me..
The non-VPN option was a client request, since they just want to provide a web link to the application's clients.
Will you be able to send me more detailed procedure for the configuration steps I will need?
Thank you for your help.
Not sure why, but the latest version of the Server Reference Manual got rid of a lot of useful stuff (like detailed SSL configuration and Publisher features). The easiest way to configure SSL is to just switch over to IIS as a web server. There are a ton of articles available on how to configure SSL binding on a virtual application. Follow the procedure in one of these articles on the "QlikView" virtual application. I believe you'd also need to check the "Use HTTPS" checkbox under QlikView Web Servers in QMC, and switch the port to 443.
As far as DMZ, the network guys at your client should know how to do this. It's just a matter of making a public web server. It's a router setting, combined with DNS records to create a "friendly" URL. Again, Google will be your friend here.
Splitting out the services is a simple matter. On the DMZ box, just install the QlikView IIS service (called "QlikView Settings Server") and QMS. On the main QVS box that will be behind the firewall, install all services except for a web server. Ensure that the 2 boxes can communicate across TCP ports 4750 and 4747 (not positive, but I think those are the only ports that are needed).
Thanks for reply.
To clarify: to setup the "QlikView IIS service (called "QlikView Settings Server") and QMS on DMZ box" I just need to do the full QV Server installation and disable other services, right? I do not remember that QV install allows me to select these options prior to the installation.
Could you please confirm?
Yes, that's right. There's a button in the bottom-left corner of the installer (something like "Custom") that you can use to install only certain services and features.
What are authentication method are you using? If your DMZ webserver is not attached to a domain then you might need to change it and should probably use certificates for services to talk to each other. (Please find attached a document on how to install them).
At least the following ports should be open between the DMZ Webserver and the QVS (list might be incomplete).
- 4730 (QlikView Directory Service) DMZ -> QVS
- 4747 QVS DMZ -> QVS (+4749 when using certificates).
- 4750 QVS -> DMZ (QlikView WebServer Settings Service)
Thanks, Daniel, forgot about 4730 but I think you're right that you would need that too. Thanks also for the document--very interesting! And you bring up a very good point about DMZ servers: that, by definition, they are not joined to the domain, which generally brings up 2 important issues: (1) user authentication (as users typically log in against the LDAP) and (2) service inter-communication. Both of these issues essentially boil down to the same thing: trust between the 2 servers. There are many schools of thought on how to solve this problem, by people much smarter than myself, ranging from RODCs to LDAP lookups to dedicated AD forests for the DMZ, and I specifically did not want to get into a discussion on the merits of each approach because that's a general networking discussion rather than a QV-specific discussion (and one I'm probably not qualified to hold ). However, I wonder if the certificate solution you suggest would address the 1st issue (seems like it would address the 2nd one)...have you tried it?
Certificates are designed to handle the 2nd issue you mention, services talking to each other. I've recently tried it on a customer and it's pretty simple to configure. We've also solved this by using local windows users with the same name/password on all services regardless of it's on a DMZ or not but certificates seems like the more natural way to handle it.
As for issue 1, authentication, I'm not really a security expert myself but we've recently done a install using ADFS (please find another very interesting document attached) which seems like a very interesting way to handle authentication if the customer is already using it for other applications. Not really sure what's the effort involved/expertise required to configure it if not.
If you're using webticketing and coding the authentication then it will work just as any other install will, provided that you've done the certificates install.