Access point login prompt for password requirement

[aj0031724]

Team,

Need your help.

One of my client nned password prompt as authentication whenebver they browse to Qlikview Access point.

But :

Currently, the web server identifys the user's windows login (from AD), and grants access without password prompt.

They only need a password prompt additionally.

From Qlikivew Management console I see different options of Authentication and Security but not sure if this can be solved.

Is there any way by which I can ensure that password prompt are in place and they should not be granted access without that in qlikview.

Please help.

[Peter_Cammaert]

Found it (at least it works on my machine):

Goto QMC->System->Setup->QlikView Web Servers->Select yours->Authentication->Login Address and select "Alternate Login page (web form)". Visitors to the AP will now always face a login page (std QlikView one) and will get a Sign Out option in the top right corner of the AP landing page. If they close their browser session, they will be signed out automatically.

Best,

Peter

[aj0031724]

Peter,

Thanks.

I do not get to see the login address as per steps suggested from QMC.

Snapshot attached.

I AM USING VERSION 11.2 sr7 11.2 sr7

[aj0031724]

Hi Peter,

Pls ignore previous reply.

I followed the steps as suggested and it is working on my machine as well.

Many thanks for your valuable support.

[Peter_Cammaert]

If you feel that you got an answer to your question, please mark an answer as correct. That answer will appear in the same frame as your question, making it easier for visitors to find the the solution they are looking for. Thanks.

Peter

[buzzy996]

try tis, and click apply.

[fmarvnnt]

This is the solution!

[Peter_Cammaert]

Please watch out. With the technique you are referring to, you are handing over security settings to your end-users (in their browser). If you can block them from changing these settings ever again, then it's perfect. Otherwise, you are introducing a concept called "security by obscurity" i.e. you rely on the fact that most users do not know that they can tamper with security settings and where they can do that. Which is not really a good (or secure) practice