Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
May 13, 2024 1:21:30 AM
Jan 11, 2021 8:55:44 AM
This article provides step-by-step instructions for implementing Azure AD as an identify provider for Qlik Cloud. We cover configuring an App registration in Azure AD and configuring group support using MS Graph permissions.
It guides the reader through adding the necessary application configuration in Azure AD and Qlik Sense Enterprise SaaS identity provider configuration so that Qlik Sense Enterprise SaaS users may log into a tenant using their Azure AD credentials.
Content:
Throughout this tutorial, some words will be used interchangeably.
The tenant hostname required in this context is the original hostname provided to the Qlik Enterprise SaaS tenant.
Copy the "value of the client secret" and paste it somewhere safe.After saving the configuration the value will become hidden and unavailable.
In the OpenID permissions section, check email, openid, and profile. In the Users section, check user.read.
Failing to grant consent to GroupMember.Read.All may result in errors authenticating to Qlik using Azure AD. Make sure to complete this step before moving on.
In this example, I had to change the email claim to upn to obtain the user's email address from Azure AD. Your results may vary.
While not hard, configuring Azure AD to work with Qlik Sense Enterprise SaaS is not trivial. Most of the legwork to make this authentication scheme work is on the Azure side. However, it's important to note that without making some small tweaks to the IdP configuration in Qlik Sense you may receive a failure or two during the validation process.
For many of you, adding Azure AD means you potentially have a bunch of clean up you need to do to remove legacy groups. Unfortunately, there is no way to do this in the UI but there is an API endpoint for deleting groups. See Deleting guid group values from Qlik Sense Enterprise SaaS for a guide on how to delete groups from a Qlik Sense Enterprise SaaS tenant.
Qlik Cloud: Configure Azure Active Directory as an IdP
@Carl_Hunter , responding to this item in the thread: https://community.qlik.com/t5/Knowledge-Base/How-To-Configure-Qlik-Sense-Enterprise-SaaS-to-use-Azur...
Have a look at SCIM: http://www.simplecloud.info/
This is the direction we are going re: user directory sync and pre-provisioning users and groups to tenants. Azure AD, Okta, and many other IdPs support this API.
Thanks! Looks v interesting @Jeffrey_Goldberg - is this in the product yet?
Azure has a SCIM endpoint (Azure AD Provisioning Service), which I'll take a look into 👍
This was very helpful in setting up SSO. I've noticed that all of my groups are not in the claim when I sign in. It appears I might be hitting a limit, where only 99-100 groups come through. That would be in line with use of the Microsoft Graph API if you didn't use pagination -- see here.
@Jeffrey_Goldberg -- Is this a known issue, and do you have any idea of how we could limit which groups Azure includes in the claim, or whether Qlik plans to fix the limitation?
Thanks!
Hey @Jeffrey_Goldberg, has there been anymore movement on my SCIM/ user directory sync and automation of Qlik Sense SaaS onboarding query? Wondering if the new Blendr.io app automation functionality will fill this requirement?
Quick follow-up, looks like the automatic provision is not enabled against the Enterprise Application, perhaps something Qlik needs to do to wire this up to Azure AD?
We could write some PowerShell to push users from Azure AD into QS SaaS and schedule from Azure Automation but its a bit janky...
This is an excelent post! Thanks a lot!
But we need your help...
We have a customer with QSEoW with local AD using domain/account login, and we are about to configure SAAS with Azure AD and following your recomendation we will change the sub field to use sAMAccountName and create a custom extension claim that includes the onpremisessamaccountname.
But our problem is that they have 3 domains, so we cant really set the realm to be the domain name.
Do you have any ideas how we can figure this out?
Another tricky thing is that onPremisesDomainName is FQDN while on QSEoW we see users as just domain/user. Not sure if that will be a problem for QLS.
They have +150 users on QSEoW so we dont want them to change login on QSEoW to be email address and loose SSO. We rather prefer them to login to SAAS using domain\user.
Of course the underlying issue is that we dont want licenses to be duplicated and we want login to be the same in both platforms.
Thanks for your help!
Thanks for as very useful guide! Especially the Idp configuration steps helped me to move a customers Qlik Sense site from Qlik accounts to MS accounts on Azure.
It really worked smothly, and the users are now able to log on using their regular Microsoft login credentials.
However, there were no trace of the expected user groups from Azure, and using the /api/v1/diagnose-claims command in the browser did not show any either, as it should. As I didn't configure the Azure part, that was done by someone else, I was not sure it was set up correctly in Azure.
After some hours trying to figure out what was wrong, I sifted through some qlik help documentation and stumbled upon what I missed: I had not enabled the setting for auto-creation of groups under Settings in the Management console!
I flipped the switch, logged out and when logged in again, the user groups appeared in the Add members list - Success!
Here you can read about the auto-creation of groups setting:
Tips: The /api/v1/diagnose-claims command should return a list of whatever groups the user is a member of :
"groups":[*,...
That is if the auto-creation of groups setting is enabled 😉
Hi!
We managed to get the connection working following this instruction. The existing users are ok and can login via the new routine, but we cannot se any other users or groups from the AD, so we cannot add new users. What triggers the sync? What can be wrong?
Anderslinden, I've just hit the same snag, did you get it sorted? I've found a permission in Azure API permissions which is named 'Directory.AccessAsUser.All' and is described 'Access directory as the signed in user', which looks promising. I've just activated it myself, and will find out if it's made a difference tomorrow ( it's hometime for me 😄 ).
@StephenDunn Thanks for replying. We can now see group AllUsers, and I'm just checking with the people administrating the AzureAD if there are more groups. Note that (as an earlier post says) you have to check the box in settings to "allow groups to be crated".
/Anders