Log Into Hub or QMC with Test User

[deec]

Is there any way to create a set of TEST users and then log into the hub or qmc as these users?

I know how to import users and properties. I know I should be able to visualize their access per the Audit function as an admin in the QMC. But is there any way to log in as these users to perform actions and test some theories?

I can create local users in the server but creating new AD users comes with A LOT of overhead.

I have access to postman (desktop client, not chrome extension) but not openSSL.

[Giuseppe_Novello]

I think you are looking something like this?

https://developer.qlik.com/garden/5762c5b17648a784afb6f321

BR

Gio

[deec]

thanks @Giuseppe_Novello I have seen this show up from time to time in demos from Qlik.
Unfortunately I work in an environment with very tight security controls, and would need to get any application (however small) that installs on the servers through an approval process. 

We have had little to no luck getting branch items through approval because of the whole "no support"

[Giuseppe_Novello]

Well those tools are just example to build something your own. The only way to access different as different users it is via impersonating it. By impersonating you need you use headers authentication, with that you need a module that performs the authentication and then directory. 

Something simple, you just buy a nice lunch to your AD admin and ask him/her to create some test accounts that you can use in this case. 

BR

Gio

[Levi_Turner]

---

@deec wrote:

Is there any way to create a set of TEST users and then log into the hub or qmc as these users?

...

I have access to postman (desktop client, not chrome extension) but not openSSL.

---

If you have the capability to make RESTful API calls, then yes. If you have not configured Postman to connect to Qlik then do reference this doc: https://support.qlik.com/articles/000045268

At a high level you will need to do the following:

1. Request a QPS ticket using that user's directory and id
2. Get the ticket back
3. Append the ticket to a URL which will allow you to access the hub as this user.

For (1), the API call (https://help.qlik.com/en-US/sense-developer/June2019/Subsystems/ProxyServiceAPI/Content/Sense_ProxyS...) will be:

Host: server.company.com:4243
Method: POST
Endpoint: /qps/{virtual proxy/}ticket

Body:

{ "UserDirectory": "userDirectory", "UserId": "uniqueUserId" }

So for my test system my URL is: https://usral-ltu2.qliktech.com:4243/qps/ticket since I am using the prefixless virtual proxy.

Note: This method will require the virtual proxy that you're using to accept ticketing, which the default Windows one does. You can still emulate a user coming in from another method (e.g. SAML) but you would need to adjust the UserDirectory and UserId values to be appropriate.

Note: Since we are making a request on port 4243, this port needs to be open between where you will make the request and the server.

For (2), you will get a ticket like so:

{
  "UserDirectory": "USERDIRECTORY",
  "UserId": "uniqueuserid",
  "Attributes": [],
  "Ticket": "Z.bhc0nWE9RuKT4R",
  "TargetUri": null
}

At this point for (3), I would form my URL to be  https://usral-ltu2.qliktech.com/hub?qlikticket=Z.bhc0nWE9RuKT4R (notice I have appended the Hub path with ?qlikticket and specified the ticket returned in (2).

Open that in a browser and I am now in as this arbitrary user:

For ease of use, I do have some raw PowerShell code which will handle all of this and open an incognito version of Chrome as that user:

# Build out a blank header
$hdrs = @{}
# Add in the X-Qlik-Xrfkey to form a valid QPS API request
$hdrs.Add("X-Qlik-Xrfkey","examplexrfkey123")
# Add in the X-Qlik-User value to form a valid QPS API request
$hdrs.Add("X-Qlik-User", "UserDirectory=INTERNAL; UserId=sa_api")
# This pulls the Qlik cert from the local store
$cert = Get-ChildItem -Path "Cert:\CurrentUser\My" | Where {$_.Subject -like '*QlikClient*'}
# This is the body of the QPS API
$body = '{"UserDirectory": "userDirectory","UserId": "uniqueUserId"}'
# Now we're doing a PowerShell / .NET method of ignore SSL validation
# This is purely for the ticketing code. If you do not send the QlikClient certificate, QPS will not issue a ticket
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]'Ssl3,Tls,Tls11,Tls12' 
add-type @"
    using System.Net;
    using System.Security.Cryptography.X509Certificates;
    public class TrustAllCertsPolicy : ICertificatePolicy {
        public bool CheckValidationResult(
            ServicePoint srvPoint, X509Certificate certificate,
            WebRequest request, int certificateProblem) {
            return true;
        }
    }
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
<# 
Make the request against the server name 
These other pathways work as well:
Ticket Request: Alias, Ticket Consumption: ServerName
Ticket Request: Alias, Ticket Consumption: Alias
Ticket Request: ServerName, Ticket Consumption ServerName
I am using the default virtual proxy. If you are requesting a ticket on a _different_ virtual proxy then the path will be
https://server:4243/qps/prefix/ticket....
#>
$ticket = Invoke-RestMethod -Uri "https://usral-ltu2.qliktech.com:4243/qps/ticket?xrfkey=examplexrfkey123" -Method Post -Body $body -Headers $hdrs -ContentType 'application/json' -Certificate $cert 
# Construct the URL for push to Chrome to automatically open up
$url = 'https://'
# We're using the alias here, but any value works so long as it's DNS resolvable
$url += 'usral-ltu2.qliktech.com'
$url += '/hub/?qlikTicket='
$url += $($ticket.Ticket)
Set-Location "C:\Program Files (x86)\Google\Chrome\Application\"
# Open Incognito with the ticket appended to the URL for the site. I am using the default virtual proxy here.
# If using a prefix then make sure that line 35 requests from the appropriately prefixed virtual proxy and 
# add the prefix to line 40 (e.g. '/windows/hub/?qlikTicket=')
.\chrome.exe $url -incognito

Some notes for this code:

(a): It loads the needed certificate from the local store (Current user > Personal) so either import the certificate (Windows format with the private key) into your local system, adapt the code to read from disk, or run it on the server as the service account)

(b) Again, it assumes that port 4243 is open and available between where this code is run and the server. 

[deec]

---

@Giuseppe_Novello wrote:

...Something simple, you just buy a nice lunch to your AD admin and ask him/her to create some test accounts that you can use in this case. 

BR

Gio

---

I like your thinking, Gio. Honetly, I might go this route.

@Levi_Turner Thanks for the detailed steps. It might take me a few hours set aside to wrap my mind around all this and give it a try. It looks very well thought out, and I definitely appreciate the PS code to expedite the task. My only concern is that I do not have access to OpenSSL, which is one of the prerequisites to set up Postman (Client) to work with Qlik Sense in the article you linked https://support.qlik.com/articles/000045268

[Levi_Turner]

There are two options outlined on the doc, one using OpenSSL and one without. So that should be sufficient. I did notice that modern versions of Postman even accept PFX files, although I have not tried using it. That's another option.

[jchacko_rxsense]

@Levi_Turner 
I reached till the 3rd step.
But when I try to open the link in incognito (after appending the ticket from step 2) the chrome is redirecting me to authentication and asks me to enter credentials.

[jchacko_rxsense]

@Levi_Turner Your steps does work. But it is not stable.
As I mentioned earlier even after appending the ticket number to the link chrome redirects me to authentication and gives me the popup window to enter my creds.

But sometimes it does go through and opens the test users account.

Any idea how can I avoid getting the authentication?

[Levi_Turner]

I would be surprised to hear that the ticket endpoint (https://help.qlik.com/en-US/sense-developer/Subsystems/ProxyServiceAPI/Content/Sense_ProxyServiceAPI...) is not stable. Is the URL that you're calling ($url += 'usral-ltu2.qliktech.com') the same server as where the ticket is issued from ($ticket = Invoke-RestMethod -Uri "https://usral-ltu2.qliktech.com:4243/qps/ticket?xrfkey=examplexrfkey123" -Method Post -Body $body -Headers $hdrs -ContentType 'application/json' -Certificate $cert)? If you, let's say, pointed the URL variable at a DNS alias which is fronted by a network appliance which load balances across multiple nodes in a cluster, this would be potentially expected. The ticket is issued to a specific server and cannot be re-used on another server in the same cluster.