Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
digichap28
Creator
Creator

Session log: Client Machine Identification

Hi,

Im trying to understand better the Session log and what it contains. I started to test a few things and found out there is a field called "Client Machine Identification" which is supposed to record the identification of the client.

Qlik documentation states the following:

 

The client machine identification.

By default, this is the universally unique identifier (UUID) receiver from the call to the Windows Management Instrumentation (WMI).

If the UUID is unavailable, one of the following IDs may display instead:

  • MAC address of the computer
  • Computer name
  • Unique machine ID (if the browser used in the session was in a private mode)

 

After reading that and importing a few log files (I have my server setup to split them per month) into QV, I found out the UUID doesnt remain the same for each user, even though they are accessing the documents from their same computers using their favorite web browsers.

So, the below questions came up to my head and I couldnt find any detailed documentation that could help me solve them. Could you please help me understanding it ?

1) Isnt Qlikview getting the UUIDs from the OS used by each user when they access the documents ?

2) If the answer is No for the previous question. Where is Qlikview getting the UUIDs from ?

3) Isnt there any way to force Qlikview to log the Mac address instead of the UUID which is the default setting?

 

Thanks

 

Labels (4)
1 Solution

Accepted Solutions
Miguel_Angel_Baeyens

According to what I see, this UUID changes per session: same browser but close and reopen means a new UUID for the length of the session.

If you need to make sure only allowed people is accessing, I would recommend doing so in the web or network layer: either using firewall rules so the server is not exposed to certain networks (e.g.: company VPN/corporate intranet) or via MAC address restriction.

This logs will help you in counting users and sessions per user, and in the web server logs the IP address or host from the client will also be recorded. However I don't think that QlikView (or any other web app for that matter) should take care of such security policies itself.

Unless the access is done via IE Plugin/Desktop and only IE Plugin/Desktop, in which case you can compare the UUID with the inventory of IT for a match. Yet, you will still have to limit that access somehow, if you can see that UUID in the logs means the user has already accessed.

View solution in original post

9 Replies
Miguel_Angel_Baeyens

To get the UUID from the Windows system (WMI) you need to be using a local software which is running on your local computer. Browsers do use UUIDs to identify uniquely users, although those are not the ones from the operating system (which I think it makes sense, given privacy and safety) but product of their own generation (e.g.: the browser is not reading your computer's Windows Registry to obtain such UUID).

I tested on a small VM and depending on the browser I get indeed a different value for UUID (sure it's not the MAC address), but the one for Internet Explorer is always the same string, and the one Chrome returns is also the same string during the same session. 

If I access using QlikView Desktop as client, however, I always see the same value that the wmic command returns.

I have not tested with the IE Plugin.

If all users are using the same browser and the same version of it yet the number is different for each user during their session, I would contact Qlik Support.

digichap28
Creator
Creator
Author

First of all, thanks for taking some time to review,test and respond my post. I really appreciate it.

 

I also ran few tests similar to the ones you did and got the same results.  There is also one thing I havent tested... What would happen if the browser gets updated. Would it keep the same UUID or would it change ? If it changes, I dont see any use for this particular field since the identification wouldnt be the same for one PC when it happens.

 

I need to make sure some employees are only using the devices provided by the company no matter if they are accessing the platform from USA or any other place in the world, thus, I was thinking I could use it to identify which PCs my users were connecting from, using the log files and a spreadsheet containing a User-UUID relation. 

 

Best regards!

Miguel_Angel_Baeyens

According to what I see, this UUID changes per session: same browser but close and reopen means a new UUID for the length of the session.

If you need to make sure only allowed people is accessing, I would recommend doing so in the web or network layer: either using firewall rules so the server is not exposed to certain networks (e.g.: company VPN/corporate intranet) or via MAC address restriction.

This logs will help you in counting users and sessions per user, and in the web server logs the IP address or host from the client will also be recorded. However I don't think that QlikView (or any other web app for that matter) should take care of such security policies itself.

Unless the access is done via IE Plugin/Desktop and only IE Plugin/Desktop, in which case you can compare the UUID with the inventory of IT for a match. Yet, you will still have to limit that access somehow, if you can see that UUID in the logs means the user has already accessed.

digichap28
Creator
Creator
Author

Thanks again Miguel! I will try another thing then.

On the other hand, do you know exactly when the session is logged with the "Socket closed by client" as the exit reason ?

I have been also running some test to see when this happens but seems like Qlik doesnt record the session when the browser  or is closed.

Miguel_Angel_Baeyens

That reason means that the user closed the session (closing the browser or tab, for example) or an intermediate web server (load balancer, proxy) between the user and the server closed that session.

digichap28
Creator
Creator
Author

Thanks Miguel 👍

francescoasaro
Partner - Contributor II
Partner - Contributor II

I'm sorry for bringing this up again but this statement doesn't make sense to me:

According to what I see, this UUID changes per session: same browser but close and reopen means a new UUID for the length of the session.

In my environment I see the same ajax UUID across different months. It cannot be the same session.

UUID must be retrieved somewhere each time and not generated on the fly.

Miguel_Angel_Baeyens

I would have to try and retest to make sure that that statement is still correct in all possible versions of QlikView, with and without intermediate proxies/VPN/router, but this is unlikely to happen in the near future, unfortunately.

Log a case with Qlik Support for clarification if that information is critical for your systems so they can provide a more accurate information on how those UUIDs are generated or where those are retrieved from.

I can confirm that using the same hardware and browser returns different UUIDs for every session in my environments: one is physical (a laptop hosting a Qlik server) and another is virtual (VMs running QlikView).

To my laptop, I don't have any intermediate hardware or software (e.g. proxies) but I do use VPN and proxy for the VMs.

EDIT: Reference URL for clarity (Microsoft WMIC article inside)

Session Log: Client Machine Identification and Session Recovery feature: https://support.qlik.com/articles/000003495

 

francescoasaro
Partner - Contributor II
Partner - Contributor II

First of all, thank you very much for taking the time to answer my question.

I've been doing some testing myself and it seems that if you use the same browser/network configuration to access the access point web page, qlik manages to assign the same UUID across different sessions.

However if you change your browser you are going to get a different UUID each time.

At least this is what happens in my environment.

I will do some more research. Thanks again.