Security Issue

[#1]

So a customer is having trouble with their security. I was working fine until recently. They are running QV 10 and have

Authentication: Login

Type: Ntlm

Login Address: Alternate login Page

These settings had worked fined when I initially setup the server. Even if I change the authentication to always and default login page, they user is not allowed to login. We modified the  <DefaultUrl>http://_/</DefaultUrl> to port 8080. Any ideas why we are having issues?

[Miguel_Angel_Baeyens]

Alex,

If it's the ports, upgrading won't help at all, you will keep having the same issues. However, having the latest version is always a good idea, since a lot of bugs are fixed every release.

Depending on how complex is your network, determining where the problem is may take some time. If you have access to the IT people, ask tem about new web services, or change the port of the QlikView Web Server to something stranger than 8080.

Hope that helps.

Miguel

[#3]

Okay, so we changed the Web Port 9900. And we are still having the same issues.

Can we change this port?

http://servername:4750/qvws.asmx

[Miguel_Angel_Baeyens]

Yes, you can change it in the Config.xml file in the WebServer folder. However, this port is only for internal use between the Web Server and the Management Service in QlikView, and it's not used for communication between client and Server. You will need to stop services, change the file (back it up first) then restart services.

Make sure you don't have any proxies that might be preventing traffic from or to that server. Test locally in the server if the Web Server (the Accesspoint) is available to the local admin user that is running the services.

Hope that helps.

Miguel

[#5]

I'm not a network guy at all, so how would I test if any proxies might be preventing traffic? They say that there aren't any other web services are running, but I'm a little skeptical.

[Miguel_Angel_Baeyens]

Alex,

The proxy settings are set in the Control Panel, Internet Options, Connections, LAN Settings. Usual proxy ports are 8080, 8088, 3128, 8000 and Google will return a huge list.

Anither option to test whether or not are web services running is to run any telnet application, the one that comes with Windows is OK, and use

telnet servername port

In the screen goes blank, that usually means that there is a service running in that port. To test the Accesspoint, although you won't see anything, once you have entered the above and the blank screen appears, type

HEAD /qlikview/index.htm HTTP/1.0 (enter key) (enter key)

That will return a standard HTTP error (404 if the page is not there, 200 if ok, etc) and some information on the Server that is running.

Hope that helps.

Miguel

[#7]

I will try those. Could these be a license issue at all? I didn't think so, since they can view documents at qvp@servername. The sales rep is questioning whether the licenses are wrong.....

[Miguel_Angel_Baeyens]

Alex,

A licensing issue would make your documents unavailable to the user regardless he or she used the QVP or HTTP protocol, since a license is always assigned to a valid user in the security directory (whether Windows Active Directory or not): if the user gets through QVP the license is assigned. Licenses are not assigned to one particular protocol or client. Both QVP and HTTP support User CALs and Document CALs, and as far as I know, QVP is working fine.

Anyway, it shouldn't take too long to verify that licensing is not an issue, if your sales rep sends you the number or you go yourself to the QEMC, System, Licenses, Server License and click on the Update from Server button. Before that, backup the folder C:\ProgramData\AllUsers\QlikTech that stores licenses information and Server configuration and logs.

Hope that makes sense.

Miguel

[#9]

I've got a ticket open with QlikView Support. This was their response. Wouldn't the Active Directory Connector have to be broken for this option to work?

"It looks like either there was a domain level security change or the service account that accesses the AD lost privileges."

[Miguel_Angel_Baeyens]

Again, that seems difficult since the user must be authenticated to get the license, and the rest of services are running fine (QEMC, reloads, etc.). But the thing is that, for some circumstance, the user cannot log into the Accesspoint. I'd bet on a network, proxy, router, firewall issue rather than a security issue.

It's tricky anyway, because are the users unable to log in because of lack of permissions in the IIS or Web Server (they do have enough permissions to get to the Server) or because the Web Server is not (or does not point) where it's supposed to be (paths)?

Miguel

[#11 · Accepted solution]

So, not a webserver issue at all. The server was not correctly configured to the domain. The client can take the blame for this one.

Thanks for drumming ideas for me, I learned a lot!