Qlik Sense Windows authentication redirect port changed June 2018

[teemusalo]

Hi,

we recently upgraded our qlik senser server from june 2017 to june 2018. After a few weeks we were going through on some of our log files and noticed multiple access denials coming from our Qlik Sense service account. Further examination revealed, that the amount of access denies had spiked after the version upgrade from few cases in a month to over 200 in a day.

This was still happening only on our test server, so we were able to track down the coming connections easily to our scheduled monitoring tasks (Licence, Sessions, Operations etc. logging applications). The best answer was found in our Proxy service log files and more specifically in C:\ProgramData\Qlik\Sense\Log\Proxy\Trace\<computername>_Audit_Proxy.txt.

What was happening, was our service accounts connections were denied with result 'NoAvailableAccessType' after 5 consecutive connections. For some reason the calls were now triggering something in our user access allocations that seem to be limited to a maximum of 5. The loggings task run every hour and because the sessions timeout is 30 minutes in our virtual proxy settings the firsts connections always succeed normally and the following ones fail. Before the version upgrade these allocations were not triggered from monitoring tasks. We were able to verify this by running the same logging applications in our production server (June 2017) and noticed that the user allocation field 'Last Used' timestamp did not update.

The Proxy logfiles also showed that the authentication redirection url had changed after the version upgrade. Previous authentications from internal users were directed to https://localhost:4244/windows_authentication/<parameters> and the new url is https://localhost/internal_windows_authentication/<parameters> so in addition to minor path changes the port number has changed from default windows authentication port 4244 to https port 443.

We could not find any notes from June 2018 Release docs about these changes. Has anyone else stumbled to these changes in any way?

Is there any way to configurate the proxy servers redirect ports and url for windows authentication?

Also, the Qlik Help documentation did not give a clear answer why connections to port 4244 do not trigger the use of user access tokens but connections to 443 do. As far as we know connections to 4244 still have to go through the same authentication with virtual proxies.

Some notes: Our test server only has one node, one virtual proxy (default) and uses windows authentication. Tasks are started through the QMC. We were able to stop the access denials by configuring our QRS REST Data Connections to use exported certificates instead of windows authentication. Now the connections do not even pass through proxy service as far as we know.

Best regards,

Teemu Salo

[balabhaskarqlik]

May be,You wouold need to change the below in the QVManagementService.exe.config that is located at  C:\Program Files\QlikView\Management Service

<add key="QMSFrontendWebServicePort" value="4780"/>

Or

You can change the used port at QMC.If you have to use only one port e.g. you can set up a reverse proxy on the top of Sense (eg. apache).

Or, End up using custom authentication (i.e. Auth0 in a SAML configuration) to resolve this issue.

[balabhaskarqlik]

Refer this:

Reverse Proxy and Authentication port redirect

[balabhaskarqlik]

These too:

https://help.qlik.com/en-US/sense/September2017/Subsystems/ManagementConsole/Content/edit-proxies.ht...

https://community.qlikview.com/thread/154209

[Levi_Turner · Accepted solution]

Hello Teemu,

There are a few elements here.

You're quite right that the ultimate root cause is due to token exhaustion due to the reload of the default assets. In order to accommodate the dual licensing model present in Qlik Sense April 2018 and higher, the license check occurs during the connection to the Qlik Proxy Service. Another consequence is that this work flow does not work:

1. Log into Hub
2. Attempt to open an app > No Access Pass message
3. Go to the QMC > Allocate a license
4. Go to the Hub
5. Attempt to open an app

The needed step would be to logout before (4) to terminate the QPS session.

As for why directly accessing QRS via 4244 does not have similar requirements, it's two-fold: the Proxy service is not involved in the exchange as well as the fact that QRS hasn't ever checked for a license since direct QRS access does not and cannot involve app consumption.

The switch from using 443 > 4244 in Windows authentication was referenced here: https://help.qlik.com/en-US/sense/April2018/Content/WhatsNew/What-is-new-Apr2018.htm and the background for that is that it can produce challenges for a subset of network appliances / devices where defining persistency across ports is impossible or quite difficult.

Hope that helps.

[teemusalo]

Hey Levi,

your post answers my questios so I will mark it as the correct answer.

However, if you are feeling up for it I have a few additional questions if you can answer them.

1. How is this behaviour not considered a bug, if a task makes multiple connections in a row to Proxy why does it create a new session and a token exhaustion for each connection?

2. We ended up using certificates and connecting to Repository on port 4242, so no tokens or sessions are being handled. Could there be some negative effects from using certs in our application connectors?

Also, if you can eloborate what "Dual licencing" means or could link some site it would be most appreciated.

Thank you for your answers!

-Teemu

[Levi_Turner]

> How is this behaviour not considered a bug, if a task makes multiple connections in a row to Proxy why does it create a new session and a token exhaustion for each connection?

Part of this is going to be outside of my zone of control since this was an intentional choice by Product Management and R&D, but re-use of the session, in my estimation, would be non-ideal for surely a number of reasons. To be able to re-use the session, the REST connection(s) would need to share the same underlying REST Connector process. Given that there can be response headers which are provided from the RESTful source which could be re-used to potentially bypass authentication partially or entirely, this obviously creates some security concerns. Again some of this would depend on the RESTful source and the type of responses given back. But this is just my 2 cents on the matter.

> We ended up using certificates and connecting to Repository on port 4242, so no tokens or sessions are being handled. Could there be some negative effects from using certs in our application connectors?

Negative effects? Zero that I could think of. Honestly it would only be beneficial since:

• Default: QPS + QRS
• Your method: QRS

In your method, you are trimming the computational overhead needed by cutting out a service. The gains would be marginal at best, but seem pretty apparent from first principles. The only cost is that it's a bit of a pain for some folks to setup direct connection with certificates.

> Also, if you can eloborate what "Dual licencing" means or could link some site it would be most appreciated.

I am referring to this: https://help.qlik.com/en-US/sense/June2018/Subsystems/PlanningQlikSenseDeployments/Content/Deploymen...

Basically now Qlik Sense supports not only tokens (traditional) but also role based licensing (professional vs. analyzer).

Hope that helps.

[teemusalo]

Thank you! Your help is much appreciated.

-Teemu