Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
I have a question about authentication. We have our production environment set up so that all users trying to access Qlik (whether they are internal or external) will hit an external load balancer (HAProxy), which will pass the user on to one of our nodes, which are inside a DMZ. We have our virtual proxies set up for Windows authentication, so their AD creds will authenticate them and pass them right on through without having to manually log in. Of course, if their machine is not set up with an AD (or if they're on a Mac), they will be directed to the login screen and prompted for username and password. Everything works great, except for the scenario we have where users from a recent acquisition are now trying to access Qlik, but their machines are still set up with AD credentials from their old company's Active Directory. To be clear -- they have been given AD creds from our company, but they are still using the old creds to log into their local machines. So they try to access Qlik, and since their machine's AD creds (e.g. "oldcompanydomain\username" and "password") match a windows authentication pattern, those creds are passed on, but once they are checked against my company's AD (which has a domain of, for example, "newcompanydomain\"), they are not found. Instead of directing them to a login screen to put in their credentials from the new company, which is what I would expect to happen, they are simply receiving a browser error saying "This page can't be displayed". So they have no way of putting in their new AD creds, and thus no way of accessing Qlik.
FYI:
I'm probably leaving out some critical information, so feel free to ask for clarifications and I'll do my best to provide any info you might find helpful.
Thanks!
Evan Lancaster
Hi Evan,
if this is a temporary situation and those new users will soon going to move to the newcompany domain, I should go for a temporary solution, which is to dedicate a Virtual Proxy for those users and configuring it as Form Authentication instead Windows Authentication. This force Qlik to ask always for the user credentials
Hi Evan,
if this is a temporary situation and those new users will soon going to move to the newcompany domain, I should go for a temporary solution, which is to dedicate a Virtual Proxy for those users and configuring it as Form Authentication instead Windows Authentication. This force Qlik to ask always for the user credentials
Vincenzo,
Thank you for the suggestion. It's a good one, but the difficulty there is bullet point number 2 in my original post. Everyone is being routed externally, so as a user comes in, there's no way to distinguish whether he is a user from the old company or the new (not that I can figure out, anyway) and point him to the correct proxy.
Is there a way to determine who's who as they hit our HAProxy in this scenario? If so, then your suggestion would be the perfect solution.
You need to deliver 2 different access url to your grups of users.
eg.
https://<your server name>/hub --> To your oldcompany users
https://<your server name>/newCompany/hub --> To your newcompany users
Of course newcompany can't access throught the standard portal.
This of course can be put in place as temporary solution
Thanks again for the input.
Though we were hoping to not have to go this route, it looks like it is our only option right now (short of creating a complicated customized authentication solution), so I started to implement it. I set up another virtual proxy on the central node with the appropriate prefix (and corresponding addition to the session cookie header name), and set the original default virtual proxy to Windows authentication, then set the new virtual proxy to Forms authentication. I linked the new virtual proxy to the central node proxy, and I thought we were off to the races.
Wrong.
The new URL works great -- I type it in and get routed to the login form. I log in, and it sends me right on to https://servername/newCompany/hub. Perfect. But when I try to hit the original https://servername/hub, my AD creds are not being passed on anymore. I only get a blank screen (in Chrome -- in IE, I get a 400 error message). What would be causing that? I see that the URL contains ...:4244/windows_authentication/ticketID=... so it's definitely trying to pass them, but no dice.
Any ideas?
Just make sure you've used a different Session cookie header for the new virtual proxy.
Have a look to the picture
Yes, I had done that. We traced the traffic and found out we had configured HA proxy in such a way that it was redirecting incorrectly. We are going to remove that new virtual proxy from the central node and put it on a different node instead so as not to "confuse" HA proxy. I will be implementing that today and will report back on the progress.
Thanks again for your help!
It took awhile, but we finally got it configured. Now we have two URLs, one of which points to a virtual proxy using Windows authentication, and the other of which points to a virtual proxy using Forms. We have given the acquired company's users the new URL and they are happy, as is our CEO, which is always good.
Thanks again for your help!
Hi Evan,
We have a AWS Load Balancer as our Gateway and quite infrequently we hit a blank login page while connecting to the hub with the same URL resolution that you had shared. Looks like it picks up a session but unable to render the hub. I am not a network expert myself. Could you please explain as to what this indicates and how you got it resolved?
Thanks,
Santhya
Hello sir, may i know how did you handled this case? when you created another virtual proxy with Forms, what are steps you have taken care, i have same kind of situation, and i am getting 404 error when i created anotehr virtual proxy? is there anything with the port conflicts, please let me know your suggestions if you can.
Thanks
SS